From j.schoenwaelder@jacobs-university.de Mon Jul 2 00:48:56 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1312921F8AB7 for ; Mon, 2 Jul 2012 00:48:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[AWL=-1.251, BAYES_50=0.001, 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 gsj6O1ISK2Lj for ; Mon, 2 Jul 2012 00:48: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 64A3121F8AB6 for ; Mon, 2 Jul 2012 00:48:53 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id DF53420BF1; Mon, 2 Jul 2012 09:48:56 +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 6UEuHGzzJa-s; Mon, 2 Jul 2012 09:48: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 9179020BD7; Mon, 2 Jul 2012 09:48:56 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id B28BB203CD9D; Mon, 2 Jul 2012 09:48:56 +0200 (CEST) Date: Mon, 2 Jul 2012 09:48:56 +0200 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20120702074856.GA44433@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] adoption of draft-lange-netmod-iana-timezones 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, 02 Jul 2012 07:48:56 -0000 Hi, this a quick poll to determine whether the WG wants to adopt the IANA maintained timezone typedef as WG document. The typedef is currently defined in: http://tools.ietf.org/html/draft-lange-netmod-iana-timezones-01 Please respond to the mailing list by 2012-07-08 if you think this is the right way forward or if you have reasons that we should not follow this path. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From jernej.tuljak@mg-soft.si Tue Jul 3 03:03:30 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0C9021F87DE for ; Tue, 3 Jul 2012 03:03:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.109 X-Spam-Level: X-Spam-Status: No, score=-1.109 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, 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 V7hhtaj-D7mM for ; Tue, 3 Jul 2012 03:03:29 -0700 (PDT) Received: from gate.mg-soft.si (gate.mg-soft.si [212.30.73.66]) by ietfa.amsl.com (Postfix) with ESMTP id 32EE921F87AE for ; Tue, 3 Jul 2012 03:03: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 q63A3Zsk024131 for ; Tue, 3 Jul 2012 12:03:35 +0200 Message-ID: <4FF2C373.5040806@mg-soft.com> Date: Tue, 03 Jul 2012 12:03:31 +0200 From: Jernej Tuljak User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: NETMOD Working Group Content-Type: multipart/alternative; boundary="------------010909070909010807040400" Subject: [netmod] Modeling NETCONF Event Notifications 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, 03 Jul 2012 10:03:30 -0000 This is a multi-part message in MIME format. --------------010909070909010807040400 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, I have questions regarding NETCONF Notifications and YANG. Which YANG module is the standard module that models RFC5277 notifications? I've got nc-notifications@2008-07-14 and notifications@2008-07-14 over here, but it's quite evident that they are part of yuma's netconfd. Are these what I'm looking for? More specifically should we generate XML schema for notifications in our generic client based on the root {urn:ietf:params:xml:ns:netconf:notification:1.0}notification container in the latter mentioned module and a combination of all available YANG notification statements which would represent some sort of an undefined merge of YANG statements? Are there rules on how this merge is supposed to happen? What are the XML encoding rules for the result of such a merge? I understand that the root notification container is there so modules can augment nodes to all notifications at once (instead of doing one augment per each available notification) and that netconfd handles this requirement in such a way, but what is the standard way of modeling this? For event notifications in the following module (I hope the pretty printing remains untouched): module augmented-notification { namespace "http://www.example.com/ns/augmented-notification"; prefix an; import notifications { prefix ncEvent; } revision 2012-07-03; notification event { leaf severity { type enumeration { enum major; enum minor; enum critical; enum notice; } } leaf cause { type string; } leaf message { type string; } } augment "/ncEvent:notification" { leaf sequence-id { type int32; } } } how does a generic client determine for a notification like this (represents an instance of the merge): 2012-03-07T11:00:00Z critical this and that Stuff happened. 1 which child element is the actual notification content and which are the augmented nodes? How does it even know that an additional node will be present? Suppose that the above module would add an "event" node instead of "sequence-id". Should such a module still be considered a valid module or not (note that this creates a name conflict). I can see that it can be very useful to have access to the "base" notification, but one should be able to model this within YANG (forget extensions unless they are standardized), not resort to some sort of external hacks, right? --------------010909070909010807040400 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

Hi,

I have questions regarding NETCONF Notifications and YANG. Which YANG module is the standard module that models RFC5277 notifications? I've got nc-notifications@2008-07-14 and notifications@2008-07-14 over here, but it's quite evident that they are part of yuma's netconfd. Are these what I'm looking for?

More specifically should we generate XML schema for notifications in our generic client based on the root {urn:ietf:params:xml:ns:netconf:notification:1.0}notification container in the latter mentioned module and a combination of all available YANG notification statements which would represent some sort of an undefined merge of YANG statements? Are there rules on how this merge is supposed to happen? What are the XML encoding rules for the result of such a merge? I understand that the root notification container is there so modules can augment nodes to all notifications at once (instead of doing one augment per each available notification) and that netconfd handles this requirement in such a way, but what is the standard way of modeling this?

For event notifications in the following module (I hope the pretty printing remains untouched):

module augmented-notification {
    namespace "http://www.example.com/ns/augmented-notification";
    prefix an;
    import notifications {
        prefix ncEvent;
    }
    revision 2012-07-03;
    notification event {
        leaf severity {
            type enumeration {
                enum major;
                enum minor;
                enum critical;
                enum notice;
            }
        }
        leaf cause {
            type string;
        }
        leaf message {
            type string;
        }
    }
    augment "/ncEvent:notification" {
        leaf sequence-id {
            type int32;
        }
    }
}

how does a generic client determine for a notification like this (represents an instance of the merge):

<?xml version="1.0" encoding="utf-8"?>
<notification xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0"
              xmlns:an="http://www.example.com/ns/augmented-notification">
    <eventTime>2012-03-07T11:00:00Z</eventTime>
    <an:event>
        <an:severity>critical</an:severity>
        <an:cause>this and that</an:cause>
        <an:message>Stuff happened.</an:message>
    </an:event>
    <an:sequence-id>1</an:sequence-id>
</notification>

which child element is the actual notification content and which are the augmented nodes? How does it even know that an additional node will be present? Suppose that the above module would add an "event" node instead of "sequence-id". Should such a module still be considered a valid module or not (note that this creates a name conflict).

I can see that it can be very useful to have access to the "base" notification, but one should be able to model this within YANG (forget extensions unless they are standardized), not resort to some sort of external hacks, right?

--------------010909070909010807040400-- From j.schoenwaelder@jacobs-university.de Tue Jul 3 04:58:29 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B22121F87DD for ; Tue, 3 Jul 2012 04:58:29 -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 9xVZElrCDbQU for ; Tue, 3 Jul 2012 04:58: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 9930B21F86B7 for ; Tue, 3 Jul 2012 04:58:28 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id B4C7120BEC; Tue, 3 Jul 2012 13:58: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 eowaATlT9GfX; Tue, 3 Jul 2012 13:58: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 50E8320BDD; Tue, 3 Jul 2012 13:58:35 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 724B920420B3; Tue, 3 Jul 2012 13:58:32 +0200 (CEST) Date: Tue, 3 Jul 2012 13:58:32 +0200 From: Juergen Schoenwaelder To: Jernej Tuljak Message-ID: <20120703115832.GA669@elstar.local> Mail-Followup-To: Jernej Tuljak , NETMOD Working Group References: <4FF2C373.5040806@mg-soft.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4FF2C373.5040806@mg-soft.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: NETMOD Working Group Subject: Re: [netmod] Modeling NETCONF Event Notifications 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, 03 Jul 2012 11:58:29 -0000 On Tue, Jul 03, 2012 at 12:03:31PM +0200, Jernej Tuljak wrote: > I have questions regarding NETCONF Notifications and YANG. Which > YANG module is the standard module that models RFC5277 > notifications? I've got nc-notifications@2008-07-14 > and notifications@2008-07-14 > over here, but it's quite evident > that they are part of yuma's netconfd. Are these what I'm looking > for? RFC 5277 predates the 'yangification' of the NETCONF specification and there likely is a need to update/redo RFC 5277 at some point in time. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From mehmet.ersue@nsn.com Tue Jul 3 07:01:31 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1245111E80D5; Tue, 3 Jul 2012 07:01:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.532 X-Spam-Level: X-Spam-Status: No, score=-106.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RY-1mY0KkjjC; Tue, 3 Jul 2012 07:01:30 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id DF0BC11E807F; Tue, 3 Jul 2012 07:01:29 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q63E1Y7q022810 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 3 Jul 2012 16:01:34 +0200 Received: from DEMUEXC048.nsn-intra.net ([10.159.32.94]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q63E1XIk031477; Tue, 3 Jul 2012 16:01:33 +0200 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by DEMUEXC048.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Tue, 3 Jul 2012 16:01:33 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 3 Jul 2012 16:01:33 +0200 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A6403FCE65B@DEMUEXC006.nsn-intra.net> In-Reply-To: <20120703115832.GA669@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] Modeling NETCONF Event Notifications Thread-Index: Ac1ZEzEsLpP9ABFTTBe+4FVLmJNAKAAEL4YA References: <4FF2C373.5040806@mg-soft.com> <20120703115832.GA669@elstar.local> From: "Ersue, Mehmet (NSN - DE/Munich)" To: "Juergen Schoenwaelder" , "Jernej Tuljak" , X-OriginalArrivalTime: 03 Jul 2012 14:01:33.0824 (UTC) FILETIME=[5AA79800:01CD5924] X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 1383 X-purgate-ID: 151667::1341324094-00003CDD-8717DADA/0-0/0-0 Cc: NETMOD Working Group Subject: Re: [netmod] Modeling NETCONF Event Notifications 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, 03 Jul 2012 14:01:31 -0000 True. Is there any volunteer willing to yangify RFC 5277? Mehmet=20 > -----Original Message----- > From: netmod-bounces@ietf.org [mailto:netmod-bounces@ietf.org] On Behalf Of ext > Juergen Schoenwaelder > Sent: Tuesday, July 03, 2012 1:59 PM > To: Jernej Tuljak > Cc: NETMOD Working Group > Subject: Re: [netmod] Modeling NETCONF Event Notifications >=20 > On Tue, Jul 03, 2012 at 12:03:31PM +0200, Jernej Tuljak wrote: >=20 > > I have questions regarding NETCONF Notifications and YANG. Which > > YANG module is the standard module that models RFC5277 > > notifications? I've got nc-notifications@2008-07-14 > > and notifications@2008-07-14 > > over here, but it's quite evident > > that they are part of yuma's netconfd. Are these what I'm looking > > for? >=20 > RFC 5277 predates the 'yangification' of the NETCONF specification and > there likely is a need to update/redo RFC 5277 at some point in time. >=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 jeffrey.K.lange@ge.com Tue Jul 3 07:09:38 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E05CE21F8810 for ; Tue, 3 Jul 2012 07:09:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.317 X-Spam-Level: X-Spam-Status: No, score=-6.317 tagged_above=-999 required=5 tests=[AWL=0.282, 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 RWovN0HmSsmw for ; Tue, 3 Jul 2012 07:09:38 -0700 (PDT) Received: from exprod5og109.obsmtp.com (exprod5og109.obsmtp.com [64.18.0.188]) by ietfa.amsl.com (Postfix) with ESMTP id 83B4821F871E for ; Tue, 3 Jul 2012 07:09:37 -0700 (PDT) Received: from alpmlip11.e2k.ad.ge.com ([12.43.191.1]) (using TLSv1) by exprod5ob109.postini.com ([64.18.4.12]) with SMTP ID DSNKT/L9KbUZyBlj/eNgXismF9ILIZZ1N4pN@postini.com; Tue, 03 Jul 2012 07:09:45 PDT Received: from unknown (HELO cinmlef09.e2k.ad.ge.com) ([3.159.213.56]) by alpmlip11.e2k.ad.ge.com with ESMTP; 03 Jul 2012 10:09:26 -0400 Received: from alpmlef03.e2k.ad.ge.com ([3.159.18.12]) by cinmlef09.e2k.ad.ge.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 3 Jul 2012 10:09:25 -0400 Received: from cinmlch01.e2k.ad.ge.com ([3.159.212.50]) by alpmlef03.e2k.ad.ge.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 3 Jul 2012 10:09:25 -0400 Received: from CINMBCNA01.e2k.ad.ge.com (3.159.212.55) by cinmlch01.e2k.ad.ge.com (3.159.212.50) with Microsoft SMTP Server (TLS) id 14.2.283.3; Tue, 3 Jul 2012 10:09:24 -0400 Received: from CINMBCNA02.e2k.ad.ge.com ([169.254.2.71]) by CINMBCNA01.e2k.ad.ge.com ([169.254.1.155]) with mapi id 14.02.0283.003; Tue, 3 Jul 2012 10:09:24 -0400 From: "Lange, Jeffrey K (GE Energy)" To: "netmod@ietf.org" Thread-Topic: [netmod] I-D Action: draft-ietf-netmod-system-mgmt-01.txt Thread-Index: AQHNVxDpE2+7QCempUKg0/2zhLTSG5cXmoIQ Date: Tue, 3 Jul 2012 14:09:24 +0000 Message-ID: References: <20120630223627.12013.54961.idtracker@ietfa.amsl.com> In-Reply-To: <20120630223627.12013.54961.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [3.159.212.187] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 03 Jul 2012 14:09:25.0451 (UTC) FILETIME=[73C429B0:01CD5925] Subject: Re: [netmod] I-D Action: draft-ietf-netmod-system-mgmt-01.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, 03 Jul 2012 14:09:39 -0000 Looking over the most recent version of the system-mgmt model I was wonderi= ng if it would make sense to pull the configuration-source identity definit= ion out into a more generic model? I could see this same functionality bei= ng needed for other things. I guess if you wanted to use the configuration= -source type from a separate module you could import the system module, and= use it that way, but then you bring along all the rpcs and everything else= that you might not want to use..=20 -Jeff -----Original Message----- From: netmod-bounces@ietf.org [mailto:netmod-bounces@ietf.org] On Behalf Of= internet-drafts@ietf.org Sent: Saturday, June 30, 2012 6:36 PM To: i-d-announce@ietf.org Cc: netmod@ietf.org Subject: [netmod] I-D Action: draft-ietf-netmod-system-mgmt-01.txt 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 : YANG Data Model for System Management Author(s) : Andy Bierman Martin Bjorklund Filename : draft-ietf-netmod-system-mgmt-01.txt Pages : 31 Date : 2012-06-30 Abstract: This document defines a YANG data model for the configuration and identification of the management system of a device. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-system-mgmt There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-netmod-system-mgmt-01 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-netmod-system-mgmt-01 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 andy@yumaworks.com Tue Jul 3 08:53:53 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8F7411E8119 for ; Tue, 3 Jul 2012 08:53:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.882 X-Spam-Level: X-Spam-Status: No, score=-2.882 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 acWBhPFh18xZ for ; Tue, 3 Jul 2012 08:53:52 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 46EBD11E8154 for ; Tue, 3 Jul 2012 08:53:52 -0700 (PDT) Received: by bkty8 with SMTP id y8so6028852bkt.31 for ; Tue, 03 Jul 2012 08:53:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=OCOhq0uI18FosIfE6vhcY5yL5XOyI9wsgXB4KWj3niw=; b=QOAiiUmF4loHWPqjiqyztsQnJRjUsUEM2dK+c2gs/tbpE2l+o46fhyqGVnlAgj6mtU oxNn2t7Wu0IWDW1d5KwxyUo2QDYagmi6r4ST03q45meXyeZ0wLCH8uQg/z8s0+CyCy5L Ic4fmCvZtdida1ru/CcPeFaNuHIh1qkXTWy6ki66+UX9AIxz6Tkym0KkPKACthvqgq41 POylA6id0YgGKU8ooeRWLKbkHJsA0PYhV3c4z0J/oL1pBB33RetdruqlgAg0XLw6R59q M2q8CefHz41CBC0cKv7hU57cpiZY01Y1fwETR6ijZbFMJFVAyLU+bj0o5VXBpj8sfjIj yLJg== MIME-Version: 1.0 Received: by 10.152.131.68 with SMTP id ok4mr17863652lab.47.1341330839400; Tue, 03 Jul 2012 08:53:59 -0700 (PDT) Received: by 10.114.19.72 with HTTP; Tue, 3 Jul 2012 08:53:59 -0700 (PDT) X-Originating-IP: [75.84.168.164] In-Reply-To: <4FF2C373.5040806@mg-soft.com> References: <4FF2C373.5040806@mg-soft.com> Date: Tue, 3 Jul 2012 08:53:59 -0700 Message-ID: From: Andy Bierman To: Jernej Tuljak Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQlvK21GaiEmee/t3CIrAuIWFysVKwlvb2HICq0+EBlJu5/gQA+pb5Tnng1BhSMGqkYqtcNh Cc: NETMOD Working Group Subject: Re: [netmod] Modeling NETCONF Event Notifications 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, 03 Jul 2012 15:53:54 -0000 On Tue, Jul 3, 2012 at 3:03 AM, Jernej Tuljak wrote: > Hi, > > I have questions regarding NETCONF Notifications and YANG. Which YANG module > is the standard module that models RFC5277 notifications? I've got > nc-notifications@2008-07-14 and notifications@2008-07-14 over here, but it's > quite evident that they are part of yuma's netconfd. Are these what I'm > looking for? These are internal to the yuma server. All the protocol data structures are modeling in YANG and data-driven in the server. I think it represents the standard (with a sequence ID leaf added). There are no YANG modules for the XSDs in RFC 5277. > > More specifically should we generate XML schema for notifications in our > generic client based on the root > {urn:ietf:params:xml:ns:netconf:notification:1.0}notification container in > the latter mentioned module and a combination of all available YANG > notification statements which would represent some sort of an undefined > merge of YANG statements? Are there rules on how this merge is supposed to > happen? What are the XML encoding rules for the result of such a merge? I > understand that the root notification container is there so modules can > augment nodes to all notifications at once (instead of doing one augment per > each available notification) and that netconfd handles this requirement in > such a way, but what is the standard way of modeling this? > This is an internal implementation decision. The notification root is there in yuma for internal parsing. I suggest using YANG for modeling notifications, but if your internal tools use XSD then implement with XSD and advertise the equivalent YANG module. > For event notifications in the following module (I hope the pretty printing > remains untouched): > > module augmented-notification { > namespace "http://www.example.com/ns/augmented-notification"; > prefix an; > import notifications { > prefix ncEvent; > } > revision 2012-07-03; > notification event { > leaf severity { > type enumeration { > enum major; > enum minor; > enum critical; > enum notice; > } > } > leaf cause { > type string; > } > leaf message { > type string; > } > } > augment "/ncEvent:notification" { > leaf sequence-id { > type int32; > } > } > } > Using YANG to model the notification message is an implementation decision. Not sure why you would not just use YANG notification-stmt instead. Andy > how does a generic client determine for a notification like this (represents > an instance of the merge): > > > xmlns:an="http://www.example.com/ns/augmented-notification"> > 2012-03-07T11:00:00Z > > critical > this and that > Stuff happened. > > 1 > > > which child element is the actual notification content and which are the > augmented nodes? How does it even know that an additional node will be > present? Suppose that the above module would add an "event" node instead of > "sequence-id". Should such a module still be considered a valid module or > not (note that this creates a name conflict). > > I can see that it can be very useful to have access to the "base" > notification, but one should be able to model this within YANG (forget > extensions unless they are standardized), not resort to some sort of > external hacks, right? > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From andy@yumaworks.com Tue Jul 3 09:02:29 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DB9311E8170 for ; Tue, 3 Jul 2012 09:02:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.885 X-Spam-Level: X-Spam-Status: No, score=-2.885 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 i1sxsvFgOTH6 for ; Tue, 3 Jul 2012 09:02:28 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id BE00411E8167 for ; Tue, 3 Jul 2012 09:02:27 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so10075993lbb.31 for ; Tue, 03 Jul 2012 09:02:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding:x-gm-message-state; bh=O0lessYZpl+E9gYTWpHHK6cJEk5YaYxaq/0wJP8QXZs=; b=JX8TnS5+hdZkrz4si7wHdMKyuhmWYQYg25DDfeaQidiKaLVnx4NJMWESSdLO28Vnsc IodEc4CkU73Yj2UOTwE5T/MQF6lVnENv4KQBCuZB5DqPTngEIt9gY2ZajfF9bQMqf5eP awaAMmIoML9sRvuMLPqLa6p1tgUQvZqlpbSRJlT8KMEvxOew3naFdgPpacR/kvcWBs5X H0tmr3bbNCD5wWpV0bKsDa+yBYdP7tkHVRQulwZMLUgPaQqC7qbECll5Cfhn47ynwYGG VIc2ez+sM0SYmu3qLnJ1AZUidReQxi4Zk/lwixVfMVnKIpW8eVt7T0dK3Kq4Z3c3sZou YbZA== MIME-Version: 1.0 Received: by 10.112.43.37 with SMTP id t5mr8630258lbl.89.1341331354895; Tue, 03 Jul 2012 09:02:34 -0700 (PDT) Received: by 10.114.19.72 with HTTP; Tue, 3 Jul 2012 09:02:34 -0700 (PDT) X-Originating-IP: [75.84.168.164] In-Reply-To: References: <20120630223627.12013.54961.idtracker@ietfa.amsl.com> Date: Tue, 3 Jul 2012 09:02:34 -0700 Message-ID: From: Andy Bierman To: "Lange, Jeffrey K (GE Energy)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQk4UY/c5eEWFQwnEHbCuf2KJ5TzG6/bXrQ4kBmotcyflLTNRJil2yD/GPKVuJ19/soqqzS0 Cc: "netmod@ietf.org" Subject: Re: [netmod] I-D Action: draft-ietf-netmod-system-mgmt-01.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, 03 Jul 2012 16:02:29 -0000 On Tue, Jul 3, 2012 at 7:09 AM, Lange, Jeffrey K (GE Energy) wrote: > Looking over the most recent version of the system-mgmt model I was wonde= ring if it would make sense to pull the configuration-source identity defin= ition out into a more generic model? I could see this same functionality b= eing needed for other things. I guess if you wanted to use the configurati= on-source type from a separate module you could import the system module, a= nd use it that way, but then you bring along all the rpcs and everything el= se that you might not want to use.. > Yes -- but we could end up with a separate module for every definition if w= e followed this logic to its conclusion. Thanks for bringing up one of the more annoying YANG conformance issues again. ;-) Any vendor who wants to use these identities has to import ietf-system.yang= , and therefore has to advertise ietf-system in the . The client will think the server implements all the mandatory parts of ietf-system. If it is not advertised, then the client has only a string 'ietf-system' which is not even intended to be unique. IMO we either have to split all data and meta-data into separate YANG modul= es, of fix the NETCONF/YANG conformance model so "module set I use" and "objects I implement" are separated. > -Jeff Andy > > > -----Original Message----- > From: netmod-bounces@ietf.org [mailto:netmod-bounces@ietf.org] On Behalf = Of internet-drafts@ietf.org > Sent: Saturday, June 30, 2012 6:36 PM > To: i-d-announce@ietf.org > Cc: netmod@ietf.org > Subject: [netmod] I-D Action: draft-ietf-netmod-system-mgmt-01.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the NETCONF Data Modeling Language Working = Group of the IETF. > > Title : YANG Data Model for System Management > Author(s) : Andy Bierman > Martin Bjorklund > Filename : draft-ietf-netmod-system-mgmt-01.txt > Pages : 31 > Date : 2012-06-30 > > Abstract: > This document defines a YANG data model for the configuration and > identification of the management system of a device. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-netmod-system-mgmt > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-netmod-system-mgmt-01 > > A diff from previous version is available at: > http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-netmod-system-mgmt-01 > > > 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 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From jeffrey.K.lange@ge.com Tue Jul 3 10:52:28 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EBF911E81B3 for ; Tue, 3 Jul 2012 10:52:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.336 X-Spam-Level: X-Spam-Status: No, score=-6.336 tagged_above=-999 required=5 tests=[AWL=0.263, 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 qLb9QkFfCiw6 for ; Tue, 3 Jul 2012 10:52:26 -0700 (PDT) Received: from exprod5og110.obsmtp.com (exprod5og110.obsmtp.com [64.18.0.20]) by ietfa.amsl.com (Postfix) with ESMTP id 01EBB11E81A5 for ; Tue, 3 Jul 2012 10:52:25 -0700 (PDT) Received: from alpmlip12.e2k.ad.ge.com ([12.43.191.1]) (using TLSv1) by exprod5ob110.postini.com ([64.18.4.12]) with SMTP ID DSNKT/MxYUYyFKInf9IDFbQ4Z8KwYRjfmoua@postini.com; Tue, 03 Jul 2012 10:52:34 PDT Received: from unknown (HELO alpmlef01.e2k.ad.ge.com) ([3.159.18.10]) by alpmlip12.e2k.ad.ge.com with ESMTP; 03 Jul 2012 13:52:33 -0400 Received: from alpmlef03.e2k.ad.ge.com ([3.159.18.12]) by alpmlef01.e2k.ad.ge.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 3 Jul 2012 13:52:33 -0400 Received: from cinmlch01.e2k.ad.ge.com ([3.159.212.50]) by alpmlef03.e2k.ad.ge.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 3 Jul 2012 13:52:32 -0400 Received: from CINMBCNA05.e2k.ad.ge.com (3.159.212.59) by cinmlch01.e2k.ad.ge.com (3.159.212.50) with Microsoft SMTP Server (TLS) id 14.2.283.3; Tue, 3 Jul 2012 13:52:32 -0400 Received: from CINMBCNA02.e2k.ad.ge.com ([169.254.2.71]) by CINMBCNA05.e2k.ad.ge.com ([169.254.5.129]) with mapi id 14.02.0283.003; Tue, 3 Jul 2012 13:52:32 -0400 From: "Lange, Jeffrey K (GE Energy)" To: "netmod@ietf.org" Thread-Topic: [netmod] I-D Action: draft-ietf-netmod-system-mgmt-01.txt Thread-Index: AQHNVxDpE2+7QCempUKg0/2zhLTSG5cX2mTg Date: Tue, 3 Jul 2012 17:52:31 +0000 Message-ID: References: <20120630223627.12013.54961.idtracker@ietfa.amsl.com> In-Reply-To: <20120630223627.12013.54961.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [3.159.212.187] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 03 Jul 2012 17:52:32.0858 (UTC) FILETIME=[9F485BA0:01CD5944] Subject: Re: [netmod] I-D Action: draft-ietf-netmod-system-mgmt-01.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, 03 Jul 2012 17:52:28 -0000 I would like to suggest changing the newly added iburst and prefer ntp bool= ean leafs to have a default value of 'false' Currently they do not have a = default value, and I would assume that most implementations would take a la= ck of value to mean false, but for something as simple as a Boolean, it wou= ld make things a lot clearer if it was just stated up front that the defaul= t is false. -Jeff -----Original Message----- From: netmod-bounces@ietf.org [mailto:netmod-bounces@ietf.org] On Behalf Of= internet-drafts@ietf.org Sent: Saturday, June 30, 2012 6:36 PM To: i-d-announce@ietf.org Cc: netmod@ietf.org Subject: [netmod] I-D Action: draft-ietf-netmod-system-mgmt-01.txt 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 : YANG Data Model for System Management Author(s) : Andy Bierman Martin Bjorklund Filename : draft-ietf-netmod-system-mgmt-01.txt Pages : 31 Date : 2012-06-30 Abstract: This document defines a YANG data model for the configuration and identification of the management system of a device. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-system-mgmt There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-netmod-system-mgmt-01 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-netmod-system-mgmt-01 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 jernej.tuljak@mg-soft.si Wed Jul 4 00:43:45 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A789021F87C7 for ; Wed, 4 Jul 2012 00:43:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.854 X-Spam-Level: X-Spam-Status: No, score=-1.854 tagged_above=-999 required=5 tests=[AWL=0.745, 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 ML8CdGzw1n-R for ; Wed, 4 Jul 2012 00:43:44 -0700 (PDT) Received: from gate.mg-soft.si (gate.mg-soft.si [212.30.73.66]) by ietfa.amsl.com (Postfix) with ESMTP id 71E2521F85FB for ; Wed, 4 Jul 2012 00:43:43 -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 q647hoEH012882; Wed, 4 Jul 2012 09:43:51 +0200 Message-ID: <4FF3F434.1040704@mg-soft.com> Date: Wed, 04 Jul 2012 09:43:48 +0200 From: Jernej Tuljak User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Andy Bierman References: <4FF2C373.5040806@mg-soft.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: NETMOD Working Group Subject: Re: [netmod] Modeling NETCONF Event Notifications 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, 04 Jul 2012 07:43:45 -0000 Dne 3.7.2012 17:53, piše Andy Bierman: > On Tue, Jul 3, 2012 at 3:03 AM, Jernej Tuljak wrote: >> Hi, >> >> I have questions regarding NETCONF Notifications and YANG. Which YANG module >> is the standard module that models RFC5277 notifications? I've got >> nc-notifications@2008-07-14 and notifications@2008-07-14 over here, but it's >> quite evident that they are part of yuma's netconfd. Are these what I'm >> looking for? > > These are internal to the yuma server. > All the protocol data structures are modeling in YANG and data-driven > in the server. > I think it represents the standard (with a sequence ID leaf added). > There are no YANG modules for the XSDs in RFC 5277. > >> More specifically should we generate XML schema for notifications in our >> generic client based on the root >> {urn:ietf:params:xml:ns:netconf:notification:1.0}notification container in >> the latter mentioned module and a combination of all available YANG >> notification statements which would represent some sort of an undefined >> merge of YANG statements? Are there rules on how this merge is supposed to >> happen? What are the XML encoding rules for the result of such a merge? I >> understand that the root notification container is there so modules can >> augment nodes to all notifications at once (instead of doing one augment per >> each available notification) and that netconfd handles this requirement in >> such a way, but what is the standard way of modeling this? >> > > This is an internal implementation decision. > The notification root is there in yuma for internal parsing. > > I suggest using YANG for modeling notifications, > but if your internal tools use XSD then implement with XSD > and advertise the equivalent YANG module. > > >> For event notifications in the following module (I hope the pretty printing >> remains untouched): >> >> module augmented-notification { >> namespace "http://www.example.com/ns/augmented-notification"; >> prefix an; >> import notifications { >> prefix ncEvent; >> } >> revision 2012-07-03; >> notification event { >> leaf severity { >> type enumeration { >> enum major; >> enum minor; >> enum critical; >> enum notice; >> } >> } >> leaf cause { >> type string; >> } >> leaf message { >> type string; >> } >> } >> augment "/ncEvent:notification" { >> leaf sequence-id { >> type int32; >> } >> } >> } >> > Using YANG to model the notification message is an implementation decision. > Not sure why you would not just use YANG notification-stmt instead. I'd be glad to do that if the YANG notifications could express the model of notifications sent by netconfd and potentially others. I consider netconfd as the next best thing to a reference implementation of a NETCONF server. I was quite surprised to receive notifications from it that could not possibly be expressed through YANG without some additional knowledge (at least not through the module set advertised by it). So I assumed there had to be something behind this. As I said once before, a generic client must know the exact structure of every possible payload that could be formed and sent by the server. And the model of these payloads is expressed through YANG (also if I understood correctly from previous discussions the plan for the future is to integrate YANG into NETCONF?). RFC6020 suggests so in 5.6.1. [ The model defines a contract between the NETCONF client and server, which allows both parties to have faith the other knows the syntax and semantics behind the modeled data. The strength of YANG lies in the strength of this contract. ]. A client should therefore require only YANG and nothing else to be able to understand what the server is saying. Our client could easily consider sequence-id as a breach of this contract and simply refuse to accept such notifications. But I don't think this is the answer to the problem at hand. I agree that RFC5277 should be revisited. It should be possible to add server specific information to each notification in a way which makes the client aware of it. Jernej > > Andy > >> how does a generic client determine for a notification like this (represents >> an instance of the merge): >> >> >> > xmlns:an="http://www.example.com/ns/augmented-notification"> >> 2012-03-07T11:00:00Z >> >> critical >> this and that >> Stuff happened. >> >> 1 >> >> >> which child element is the actual notification content and which are the >> augmented nodes? How does it even know that an additional node will be >> present? Suppose that the above module would add an "event" node instead of >> "sequence-id". Should such a module still be considered a valid module or >> not (note that this creates a name conflict). >> >> I can see that it can be very useful to have access to the "base" >> notification, but one should be able to model this within YANG (forget >> extensions unless they are standardized), not resort to some sort of >> external hacks, right? >> >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >> From andy@yumaworks.com Wed Jul 4 07:05:29 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67C4621F8821 for ; Wed, 4 Jul 2012 07:05:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.887 X-Spam-Level: X-Spam-Status: No, score=-2.887 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 y6ahcvqkFETc for ; Wed, 4 Jul 2012 07:05:28 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id F342521F881D for ; Wed, 4 Jul 2012 07:05:27 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so11499091lbb.31 for ; Wed, 04 Jul 2012 07:05:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding:x-gm-message-state; bh=By/85c1Glli6NWiZ3GaBqUd2sTdFzGQBkBgSlAc8VPc=; b=MomlRRe+eFjnY/SPiIHKL517CJUNrz0/Cy5qXEJtPLNvo3Y1c+fo6QCMHO4E1qMPLu 1yH+M1eoRiBIzuG6xUBisAOMzszFHT9ixr4JjuIVjlIshrfdEhhv4Jk8bentdu++nFRW +r1C0tMykgUUTuB7t1RZaZBh+R0A7wq/X38FuAmrFDDS3eLuFUwkyPytVc1Jsnc8erj5 tKyMNdwntBwZvBHrgpJuis0HFT3gdPotbSRQEPHgdQES8iX6ERyurlR3CUDk+Q/jppXB 1HBGBKc5IQ9fMZkFalWV1ayvQuQ6H/ZvN1BymATkc9LLZDWwnbsnueDC8RfNG7xDqP9L TjpA== MIME-Version: 1.0 Received: by 10.152.144.99 with SMTP id sl3mr21894955lab.44.1341410737855; Wed, 04 Jul 2012 07:05:37 -0700 (PDT) Received: by 10.114.19.72 with HTTP; Wed, 4 Jul 2012 07:05:37 -0700 (PDT) X-Originating-IP: [75.84.168.164] In-Reply-To: <4FF3F434.1040704@mg-soft.com> References: <4FF2C373.5040806@mg-soft.com> <4FF3F434.1040704@mg-soft.com> Date: Wed, 4 Jul 2012 07:05:37 -0700 Message-ID: From: Andy Bierman To: Jernej Tuljak Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmV96C7VkksckDFbz1AYbe4gKTnTZVDd6RBqji58JW7f8ydRoXYPrNf/ZsZopdJ0ECnC19Z Cc: NETMOD Working Group Subject: Re: [netmod] Modeling NETCONF Event Notifications 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, 04 Jul 2012 14:05:29 -0000 On Wed, Jul 4, 2012 at 12:43 AM, Jernej Tuljak w= rote: > Dne 3.7.2012 17:53, pi=C5=A1e Andy Bierman: > >> On Tue, Jul 3, 2012 at 3:03 AM, Jernej Tuljak >> wrote: >>> >>> Hi, >>> >>> I have questions regarding NETCONF Notifications and YANG. Which YANG >>> module >>> is the standard module that models RFC5277 notifications? I've got >>> nc-notifications@2008-07-14 and notifications@2008-07-14 over here, but >>> it's >>> quite evident that they are part of yuma's netconfd. Are these what I'm >>> looking for? >> >> >> These are internal to the yuma server. >> All the protocol data structures are modeling in YANG and data-driven >> in the server. >> I think it represents the standard (with a sequence ID leaf added). >> There are no YANG modules for the XSDs in RFC 5277. >> >>> More specifically should we generate XML schema for notifications in ou= r >>> generic client based on the root >>> {urn:ietf:params:xml:ns:netconf:notification:1.0}notification container >>> in >>> the latter mentioned module and a combination of all available YANG >>> notification statements which would represent some sort of an undefined >>> merge of YANG statements? Are there rules on how this merge is supposed >>> to >>> happen? What are the XML encoding rules for the result of such a merge?= I >>> understand that the root notification container is there so modules can >>> augment nodes to all notifications at once (instead of doing one augmen= t >>> per >>> each available notification) and that netconfd handles this requirement >>> in >>> such a way, but what is the standard way of modeling this? >>> >> >> This is an internal implementation decision. >> The notification root is there in yuma for internal parsing. >> >> I suggest using YANG for modeling notifications, >> but if your internal tools use XSD then implement with XSD >> and advertise the equivalent YANG module. >> >> >>> For event notifications in the following module (I hope the pretty >>> printing >>> remains untouched): >>> >>> module augmented-notification { >>> namespace "http://www.example.com/ns/augmented-notification"; >>> prefix an; >>> import notifications { >>> prefix ncEvent; >>> } >>> revision 2012-07-03; >>> notification event { >>> leaf severity { >>> type enumeration { >>> enum major; >>> enum minor; >>> enum critical; >>> enum notice; >>> } >>> } >>> leaf cause { >>> type string; >>> } >>> leaf message { >>> type string; >>> } >>> } >>> augment "/ncEvent:notification" { >>> leaf sequence-id { >>> type int32; >>> } >>> } >>> } >>> >> Using YANG to model the notification message is an implementation >> decision. >> Not sure why you would not just use YANG notification-stmt instead. > > > I'd be glad to do that if the YANG notifications could express the model = of > notifications sent by netconfd and potentially others. I consider netconf= d > as the next best thing to a reference implementation of a NETCONF server.= I > was quite surprised to receive notifications from it that could not possi= bly > be expressed through YANG without some additional knowledge (at least not > through the module set advertised by it). So I assumed there had to be > something behind this. > > As I said once before, a generic client must know the exact structure of > every possible payload that could be formed and sent by the server. And t= he > model of these payloads is expressed through YANG (also if I understood > correctly from previous discussions the plan for the future is to integra= te > YANG into NETCONF?). RFC6020 suggests so in 5.6.1. [ > > The model defines a contract between the NETCONF client and server, > which allows both parties to have faith the other knows the syntax > and semantics behind the modeled data. The strength of YANG lies in > the strength of this contract. > > ]. A client should therefore require only YANG and nothing else to be abl= e > to understand what the server is saying. > No -- this was not the charter of the NETMOD WG to create YANG. YANG very explicitly covers the NETCONF content and operation layers. The original proposal did not even cover RPCs and notifications -- just the database. Yuma uses YANG internally for more layers but that is just an implementation choice. > Our client could easily consider sequence-id as a breach of this contract > and simply refuse to accept such notifications. I have to check the XSD again, but I thought it was extensible. YANG only covers the event element payload. I guess I should add a CLI parameter to netconfd to disable sequence-id if it conflicts with the XSD in RFC 5277. But I don't think this is > the answer to the problem at hand. I agree that RFC5277 should be revisit= ed. > It should be possible to add server specific information to each > notification in a way which makes the client aware of it. > I think XSD or RelaxNG has to be used for this purpose, not YANG. YANG allows only the event payload to be augmented, not the message. Standards often leave out features like sequence-id that would help operators and developers determine if access control and notification filters are doing what is expected or not. The sequence-id is an easy way to debug this sort of issue. At the time, the NETCONF WG did not think notifications needed any sort of diagnostic support, so it was included in the standard. > Jernej > > Andy >> >> Andy >> >>> how does a generic client determine for a notification like this >>> (represents >>> an instance of the merge): >>> >>> >>> >> >>> xmlns:an=3D"http://www.example.com/ns/augmented-notification"> >>> 2012-03-07T11:00:00Z >>> >>> critical >>> this and that >>> Stuff happened. >>> >>> 1 >>> >>> >>> which child element is the actual notification content and which are th= e >>> augmented nodes? How does it even know that an additional node will be >>> present? Suppose that the above module would add an "event" node instea= d >>> of >>> "sequence-id". Should such a module still be considered a valid module = or >>> not (note that this creates a name conflict). >>> >>> I can see that it can be very useful to have access to the "base" >>> notification, but one should be able to model this within YANG (forget >>> extensions unless they are standardized), not resort to some sort of >>> external hacks, right? >>> >>> >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >>> > From lhotka@nic.cz Wed Jul 4 11:38:53 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0814A21F871E for ; Wed, 4 Jul 2012 11:38:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.959 X-Spam-Level: X-Spam-Status: No, score=-1.959 tagged_above=-999 required=5 tests=[AWL=0.040, 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 S9zsdx7nv0gR for ; Wed, 4 Jul 2012 11:38:52 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 1D5F421F871A for ; Wed, 4 Jul 2012 11:38:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id AF55F5403DE for ; Wed, 4 Jul 2012 20:39:01 +0200 (CEST) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LhJWvSRv1w-N for ; Wed, 4 Jul 2012 20:38:56 +0200 (CEST) Received: from localhost (birdie-w.lhotkovi.cz [172.29.2.202]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id CC96C540333 for ; Wed, 4 Jul 2012 20:38:56 +0200 (CEST) From: Ladislav Lhotka To: netmod@ietf.org In-Reply-To: References: <4FF2C373.5040806@mg-soft.com> <4FF3F434.1040704@mg-soft.com> User-Agent: Notmuch/0.12+113~gde05574 (http://notmuchmail.org) Emacs/23.3.50.1 (i386-apple-darwin9.8.0) Mail-Followup-To: netmod@ietf.org Date: Wed, 04 Jul 2012 20:38:56 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [netmod] Modeling NETCONF Event Notifications 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, 04 Jul 2012 18:38:53 -0000 Andy Bierman writes: > > No -- this was not the charter of the NETMOD WG to create YANG. > YANG very explicitly covers the NETCONF content and operation layers. Hmm, I would say that YANG very explicitly covers the NETCONF content layer and it was also (mis)used for the operations layer in RFC 6241. Note that in order to model XML attributes, the "ietf-netconf" module had to introduce an extension. > The original proposal did not even cover RPCs and notifications -- > just the database. > > Yuma uses YANG internally for more layers but that is just an > implementation choice. No wonder people are misled into thinking that YANG is just another XML schema language. ... > But I don't think this is >> the answer to the problem at hand. I agree that RFC5277 should be revisited. >> It should be possible to add server specific information to each >> notification in a way which makes the client aware of it. >> > > I think XSD or RelaxNG has to be used for this purpose, not YANG. A set of extensible RELAX NG schemas covering base NETCONF can be found in my long-expired draft http://tools.ietf.org/id/draft-lhotka-netconf-relaxng-00.txt. Extensible schemas for notifications (as well as other optional capabilities) could be easily added in a similar vein. Lada > YANG allows only the event payload to be augmented, not the message. > Standards often leave out features like sequence-id that would help > operators and developers > determine if access control and notification filters are doing what is > expected or not. > The sequence-id is an easy way to debug this sort of issue. At the > time, the NETCONF > WG did not think notifications needed any sort of diagnostic support, so it > was included in the standard. > >> Jernej >> >> > > > Andy > > > >>> >>> Andy >>> >>>> how does a generic client determine for a notification like this >>>> (represents >>>> an instance of the merge): >>>> >>>> >>>> >>> >>>> xmlns:an="http://www.example.com/ns/augmented-notification"> >>>> 2012-03-07T11:00:00Z >>>> >>>> critical >>>> this and that >>>> Stuff happened. >>>> >>>> 1 >>>> >>>> >>>> which child element is the actual notification content and which are the >>>> augmented nodes? How does it even know that an additional node will be >>>> present? Suppose that the above module would add an "event" node instead >>>> of >>>> "sequence-id". Should such a module still be considered a valid module or >>>> not (note that this creates a name conflict). >>>> >>>> I can see that it can be very useful to have access to the "base" >>>> notification, but one should be able to model this within YANG (forget >>>> extensions unless they are standardized), not resort to some sort of >>>> external hacks, right? >>>> >>>> >>>> _______________________________________________ >>>> netmod mailing list >>>> netmod@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netmod >>>> >> > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From jernej.tuljak@mg-soft.si Thu Jul 5 02:54:59 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDBFB21F861B for ; Thu, 5 Jul 2012 02:54:59 -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.373, 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 5cxJNQKR113T for ; Thu, 5 Jul 2012 02:54:59 -0700 (PDT) Received: from gate.mg-soft.si (gate.mg-soft.si [212.30.73.66]) by ietfa.amsl.com (Postfix) with ESMTP id D9DA021F8608 for ; Thu, 5 Jul 2012 02:54:58 -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 q659t9oG026462 for ; Thu, 5 Jul 2012 11:55:10 +0200 Message-ID: <4FF56479.7090203@mg-soft.com> Date: Thu, 05 Jul 2012 11:55:05 +0200 From: Jernej Tuljak User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: netmod@ietf.org References: <4FF2C373.5040806@mg-soft.com> <4FF3F434.1040704@mg-soft.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [netmod] Modeling NETCONF Event Notifications 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, 05 Jul 2012 09:54:59 -0000 Dne 4.7.2012 20:38, piše Ladislav Lhotka: > Andy Bierman writes: >> No -- this was not the charter of the NETMOD WG to create YANG. >> YANG very explicitly covers the NETCONF content and operation layers. > Hmm, I would say that YANG very explicitly covers the NETCONF content layer and it was also (mis)used for the operations layer in RFC 6241. Note that in order to model XML attributes, the "ietf-netconf" module had to introduce an extension. Even if this was not the WG intention, the current RFCs suggest the following. Notifications are part of operations layer and have _no_ representation in the RPC layer. Take a look at RFC5277 (1. Introduction) and compare the diagram of NETCONF protocol layers to the one in RFC6241. The diagram in the first document clearly allows RPC layer to be "bypassed" for the sole purpose of notifications. RFC6020 states that it models notifications. Therefore YANG simply must handle the entire model of a notification payload, not just the event (especially if we are talking about server-specific information, eventTime leaf is not an issue as examples of XML encoding for notification-stmt indicate). This would be quite simple if an additional restriction would be put in there which would require that the event always appears after eventTime leaf and that garbage might follow. Yuma's netconfd server violates the YANG contract by adding stuff where it currently cannot be added. It doesn't matter if RFC5277 has an extensible schema since you have no way of telling the client what's going on. Which is the event and which is the appended information? Not without hacking around (or by augmenting to every notification-stmt). What you did here is an attempt of augmentation of the RPC layer which does not exist for notifications. It would be different if notifications where in the RPC layer, so a custom wrapper around the event could be easily identified. But i think YANG handling this in a future version would be a better way to go. Why make RPC and transport layers which are well known for everyone, as not such? Let YANG handle the rest. I don't really care if the server sends debug information along with a notification. But I must be able to unambiguously determine what the event was and what the added information is. There's no well known way to determine/inform of this in a hello message or a notification itself. Therefore it should not be done. Jernej From j.schoenwaelder@jacobs-university.de Thu Jul 5 03:07:33 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87BC621F855B for ; Thu, 5 Jul 2012 03:07:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.192 X-Spam-Level: X-Spam-Status: No, score=-103.192 tagged_above=-999 required=5 tests=[AWL=0.057, 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 m9-pwiaUinq5 for ; Thu, 5 Jul 2012 03:07:32 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 4A2AF21F84D5 for ; Thu, 5 Jul 2012 03:07:32 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0C0A820C47; Thu, 5 Jul 2012 12:07: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 waPBuOpJczEm; Thu, 5 Jul 2012 12:07:44 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 596D020D1C; Thu, 5 Jul 2012 12:07:44 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 30284204683E; Thu, 5 Jul 2012 12:07:43 +0200 (CEST) Date: Thu, 5 Jul 2012 12:07:43 +0200 From: Juergen Schoenwaelder To: Jernej Tuljak Message-ID: <20120705100743.GA25426@elstar.local> Mail-Followup-To: Jernej Tuljak , netmod@ietf.org References: <4FF2C373.5040806@mg-soft.com> <4FF3F434.1040704@mg-soft.com> <4FF56479.7090203@mg-soft.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4FF56479.7090203@mg-soft.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] Modeling NETCONF Event Notifications 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, 05 Jul 2012 10:07:33 -0000 On Thu, Jul 05, 2012 at 11:55:05AM +0200, Jernej Tuljak wrote: > Dne 4.7.2012 20:38, piše Ladislav Lhotka: > >Andy Bierman writes: > >>No -- this was not the charter of the NETMOD WG to create YANG. > >>YANG very explicitly covers the NETCONF content and operation layers. > >Hmm, I would say that YANG very explicitly covers the NETCONF content layer and it was also (mis)used for the operations layer in RFC 6241. Note that in order to model XML attributes, the "ietf-netconf" module had to introduce an extension. > > Even if this was not the WG intention, the current RFCs suggest the > following. Notifications are part of operations layer and have _no_ > representation in the RPC layer. Take a look at RFC5277 (1. > Introduction) and compare the diagram of NETCONF protocol layers to > the one in RFC6241. The diagram in the first document clearly allows > RPC layer to be "bypassed" for the sole purpose of notifications. > RFC6020 states that it models notifications. Therefore YANG simply > must handle the entire model of a notification payload, not just the > event (especially if we are talking about server-specific > information, eventTime leaf is not an issue as examples of XML > encoding for notification-stmt indicate). This would be quite simple > if an additional restriction would be put in there which would > require that the event always appears after eventTime leaf and that > garbage might follow. > > Yuma's netconfd server violates the YANG contract by adding stuff > where it currently cannot be added. It doesn't matter if RFC5277 has > an extensible schema since you have no way of telling the client > what's going on. Which is the event and which is the appended > information? Not without hacking around (or by augmenting to every > notification-stmt). What you did here is an attempt of augmentation > of the RPC layer which does not exist for notifications. > > It would be different if notifications where in the RPC layer, so a > custom wrapper around the event could be easily identified. But i > think YANG handling this in a future version would be a better way > to go. Why make RPC and transport layers which are well known for > everyone, as not such? Let YANG handle the rest. > > I don't really care if the server sends debug information along with > a notification. But I must be able to unambiguously determine what > the event was and what the added information is. There's no well > known way to determine/inform of this in a hello message or a > notification itself. Therefore it should not be done. I think it is important to keep in mind the history of these documents. The event notifications addition to NETCONF was published in July 2008, the YANG working group got established in April 2008. The idea to redo the NETCONF base specification in YANG was born even much later. Hence, it is no wonder that things might not align as well as they perhaps could. I think your real issue is that RFC 5277 kind of hard codes what the basic information is that goes into the notification. But then there was no YANG when this was done (and the authors/editors of that document believed that XSD is anyway the industry solution to data modeling and perhaps the XSD is extensible... ;-). My take is that RFC 5277 may need a revision. But that would be the job of the NETCONF working group, not the job of the NETMOD working group (this list). /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 Jul 5 07:38:19 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21B5321F8522 for ; Thu, 5 Jul 2012 07:38:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.201 X-Spam-Level: X-Spam-Status: No, score=-3.201 tagged_above=-999 required=5 tests=[AWL=0.398, 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 bCXhjR7p6yKG for ; Thu, 5 Jul 2012 07:38:18 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2D56021F86DB for ; Thu, 5 Jul 2012 07:38:18 -0700 (PDT) Received: by yhq56 with SMTP id 56so9855256yhq.31 for ; Thu, 05 Jul 2012 07:38:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding :x-gm-message-state; bh=urjO5Y2uJQO9Tp0IZGz8lOtZeMfrHHQDPXITaNxjToA=; b=bMciQA/cm4r8upedXgnlCYY7cxIJvotkcU1f1UoHRc+LsTbSBgz7oSNcYiMrWpKfpy BugbjKpX5pxE7xU5zn5duC7EfsdjNeLHgTe1F/q4I9nfu3Z5WYnW367UC4O0sR5Vmwgn h+A3vKuq8BXFouRC79QRPB8xRloWHeI27q4ck6bdAlRT21rA5/Bylrhm8CvlwpLE4LQn +sJZ5kHtGSWHRexNEDEcqaMH2lzxc7oW2/HcHhVdQwIJvTInaSk4dlIWaqixbHVEP5bu JglMIt7DJIldDwukn8MIm4wX1Ybg7Wy/i9OEFpWlJu5CERIXwQhnk7shnpu3KiFRbIwY O0KQ== Received: by 10.66.85.231 with SMTP id k7mr37705720paz.76.1341499111182; Thu, 05 Jul 2012 07:38:31 -0700 (PDT) Received: from [192.168.0.18] (cpe-75-84-168-164.socal.res.rr.com. [75.84.168.164]) by mx.google.com with ESMTPS id ru10sm9524555pbc.50.2012.07.05.07.38.28 (version=SSLv3 cipher=OTHER); Thu, 05 Jul 2012 07:38:29 -0700 (PDT) Message-ID: <4FF5A6EA.9070209@yumaworks.com> Date: Thu, 05 Jul 2012 07:38:34 -0700 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: Jernej Tuljak References: <4FF2C373.5040806@mg-soft.com> <4FF3F434.1040704@mg-soft.com> <4FF56479.7090203@mg-soft.com> In-Reply-To: <4FF56479.7090203@mg-soft.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Gm-Message-State: ALoCoQkeFublSXkiUcpUAc919nV8yDXfzQH52T53IxaRhuu1ggyREtN4+Y/9twu7jKy9hvkHb2Rq Cc: netmod@ietf.org Subject: Re: [netmod] Modeling NETCONF Event Notifications 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, 05 Jul 2012 14:38:19 -0000 On 07/05/2012 02:55 AM, Jernej Tuljak wrote: > Dne 4.7.2012 20:38, piše Ladislav Lhotka: >> Andy Bierman writes: >>> No -- this was not the charter of the NETMOD WG to create YANG. >>> YANG very explicitly covers the NETCONF content and operation layers. >> Hmm, I would say that YANG very explicitly covers the NETCONF content layer and it was also (mis)used for the operations layer in RFC 6241. Note that in order to model XML attributes, the >> "ietf-netconf" module had to introduce an extension. > > Even if this was not the WG intention, the current RFCs suggest the following. Notifications are part of operations layer and have _no_ representation in the RPC layer. Take a look at RFC5277 (1. > Introduction) and compare the diagram of NETCONF protocol layers to the one in RFC6241. The diagram in the first document clearly allows RPC layer to be "bypassed" for the sole purpose of > notifications. RFC6020 states that it models notifications. Therefore YANG simply must handle the entire model of a notification payload, not just the event (especially if we are talking about > server-specific information, eventTime leaf is not an issue as examples of XML encoding for notification-stmt indicate). This would be quite simple if an additional restriction would be put in > there which would require that the event always appears after eventTime leaf and that garbage might follow. > > Yuma's netconfd server violates the YANG contract by adding stuff where it currently cannot be added. It doesn't matter if RFC5277 has an extensible schema since you have no way of telling the > client what's going on. Which is the event and which is the appended information? Not without hacking around (or by augmenting to every notification-stmt). What you did here is an attempt of > augmentation of the RPC layer which does not exist for notifications. > I don't agree -- it violates the XSD in RFC 5277, not YANG. I will change netconfd to disable this extension by default. There are problems with NETCONF notifications that can't be fixed by tweaking RFC 5277, such as the call-home problem and the open session to every server. From a modeling POV, it is incorrect to augment each event payload with meta-data related to the notification itself. I don't know if YANG needs to support augmenting the notification element. IMO, a really low priority. > It would be different if notifications where in the RPC layer, so a custom wrapper around the event could be easily identified. But i think YANG handling this in a future version would be a better > way to go. Why make RPC and transport layers which are well known for everyone, as not such? Let YANG handle the rest. > > I don't really care if the server sends debug information along with a notification. But I must be able to unambiguously determine what the event was and what the added information is. There's no > well known way to determine/inform of this in a hello message or a notification itself. Therefore it should not be done. > > Jernej Andy From lhotka@nic.cz Thu Jul 5 09:08:54 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B500C21F86BE for ; Thu, 5 Jul 2012 09:08:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.961 X-Spam-Level: X-Spam-Status: No, score=-1.961 tagged_above=-999 required=5 tests=[AWL=0.038, 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 Lqxhe7LhD4PH for ; Thu, 5 Jul 2012 09:08:53 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 4C36021F86C7 for ; Thu, 5 Jul 2012 09:08:53 -0700 (PDT) Received: from [172.29.2.202] (unknown [77.48.224.120]) by mail.nic.cz (Postfix) with ESMTPSA id E2B91140467; Thu, 5 Jul 2012 18:09:05 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1341504545; bh=hJUOYOd1kc/jHDteqCABHOtSQ+AGOALRLY/sDXyEhl4=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=JiotWB9V4Qj5TogPr3ZUwIHDsRCJezZf0cQ8jN46ZGe9x7Fz6Fal8JlrOrLXmgwcj ejKv5gzig5dP4jWsvh7rHwPVfo0E9WIKOL+wntn9Z8g3jCvklj0DP4LuPP51nFKKy/ ug8sOTltKNum3dF962PmDRypTUBPpdCiJc7wlxz4= Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=windows-1252 From: Ladislav Lhotka In-Reply-To: <4FF56479.7090203@mg-soft.com> Date: Thu, 5 Jul 2012 18:09:09 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <068BB86C-0F56-4A5A-B018-C1914841F918@nic.cz> References: <4FF2C373.5040806@mg-soft.com> <4FF3F434.1040704@mg-soft.com> <4FF56479.7090203@mg-soft.com> To: Jernej Tuljak X-Mailer: Apple Mail (2.1278) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] Modeling NETCONF Event Notifications 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, 05 Jul 2012 16:08:54 -0000 On Jul 5, 2012, at 11:55 AM, Jernej Tuljak wrote: > Dne 4.7.2012 20:38, pi=9Ae Ladislav Lhotka: >> Andy Bierman writes: >>> No -- this was not the charter of the NETMOD WG to create YANG. >>> YANG very explicitly covers the NETCONF content and operation = layers. >> Hmm, I would say that YANG very explicitly covers the NETCONF content = layer and it was also (mis)used for the operations layer in RFC 6241. = Note that in order to model XML attributes, the "ietf-netconf" module = had to introduce an extension. >=20 > Even if this was not the WG intention, the current RFCs suggest the = following. Notifications are part of operations layer and have _no_ = representation in the RPC layer. Take a look at RFC5277 (1. = Introduction) and compare the diagram of NETCONF protocol layers to the = one in RFC6241. The diagram in the first document clearly allows RPC = layer to be "bypassed" for the sole purpose of notifications. RFC6020 = states that it models notifications. Therefore YANG simply must handle = the entire model of a notification payload, not just the event = (especially if we are talking about server-specific information, = eventTime leaf is not an issue as examples of XML encoding for = notification-stmt indicate). This would be quite simple if an additional = restriction would be put in there which would require that the event = always appears after eventTime leaf and that garbage might follow. >=20 > Yuma's netconfd server violates the YANG contract by adding stuff = where it currently cannot be added. It doesn't matter if RFC5277 has an = extensible schema since you have no way of telling the client what's = going on. Why not? You could use additional capabilities. Lada > Which is the event and which is the appended information? Not without = hacking around (or by augmenting to every notification-stmt). What you = did here is an attempt of augmentation of the RPC layer which does not = exist for notifications. >=20 > It would be different if notifications where in the RPC layer, so a = custom wrapper around the event could be easily identified. But i think = YANG handling this in a future version would be a better way to go. Why = make RPC and transport layers which are well known for everyone, as not = such? Let YANG handle the rest. >=20 > I don't really care if the server sends debug information along with a = notification. But I must be able to unambiguously determine what the = event was and what the added information is. There's no well known way = to determine/inform of this in a hello message or a notification itself. = Therefore it should not be done. >=20 > Jernej > _______________________________________________ > 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 Thu Jul 5 09:39:03 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5574E21F87C8 for ; Thu, 5 Jul 2012 09:39:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.211 X-Spam-Level: X-Spam-Status: No, score=-3.211 tagged_above=-999 required=5 tests=[AWL=0.388, 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 EIZWWmzSxHTF for ; Thu, 5 Jul 2012 09:39:02 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2DF9921F87CB for ; Thu, 5 Jul 2012 09:39:01 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so13374458pbc.31 for ; Thu, 05 Jul 2012 09:39:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding :x-gm-message-state; bh=iN479hWHB4HbVIOiqSgY7eChzYRL7En2zBZDdWSplj0=; b=Uv9iaOJvg2bmqHwswiJojNlUmqQjp1Rp0CtBDXZEKMddJirUPypfevUWB9z+afd7Hn CLmqZUspdG01zP5kaViXl6SWTwuKQDLZ93TghL+6ps0a078UDvZgsJ61zfYN3TtB2/Qz Bj8UGL3YmSdEZ7LcBWCjzsdHG9F9snyl+cL6M30nxb9s9l8bAv00Rs82Ez5jY6QqZgxv G2zd0UCgoTxFw1FsYBVTYLUHwXXSsxkCbmrF2pRxPRV4ULrfnuzbVYeAmlNR1rGsYV/D N7/zOrnNQ6uLbPTZkd3llM0YtoW8meqDZXgtW/hn1UHjVsVBlI/6LN+IJEpQ7QYFEFlh dHMA== Received: by 10.68.200.232 with SMTP id jv8mr28776496pbc.161.1341506354876; Thu, 05 Jul 2012 09:39:14 -0700 (PDT) Received: from [192.168.0.18] (cpe-75-84-168-164.socal.res.rr.com. [75.84.168.164]) by mx.google.com with ESMTPS id qa5sm20056567pbb.19.2012.07.05.09.39.12 (version=SSLv3 cipher=OTHER); Thu, 05 Jul 2012 09:39:13 -0700 (PDT) Message-ID: <4FF5C337.6010102@yumaworks.com> Date: Thu, 05 Jul 2012 09:39:19 -0700 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: Ladislav Lhotka References: <4FF2C373.5040806@mg-soft.com> <4FF3F434.1040704@mg-soft.com> <4FF56479.7090203@mg-soft.com> <068BB86C-0F56-4A5A-B018-C1914841F918@nic.cz> In-Reply-To: <068BB86C-0F56-4A5A-B018-C1914841F918@nic.cz> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Gm-Message-State: ALoCoQniEE6DhetbCNbKCH9zH1IhcF2q+I06Gx5ve/RnypwwyEyOCI0aGThzsXbpolBkKDLUzBsf Cc: netmod@ietf.org Subject: Re: [netmod] Modeling NETCONF Event Notifications 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, 05 Jul 2012 16:39:03 -0000 On 07/05/2012 09:09 AM, Ladislav Lhotka wrote: > On Jul 5, 2012, at 11:55 AM, Jernej Tuljak wrote: > >> Dne 4.7.2012 20:38, piše Ladislav Lhotka: >>> Andy Bierman writes: >>>> No -- this was not the charter of the NETMOD WG to create YANG. >>>> YANG very explicitly covers the NETCONF content and operation layers. >>> Hmm, I would say that YANG very explicitly covers the NETCONF content layer and it was also (mis)used for the operations layer in RFC 6241. Note that in order to model XML attributes, the "ietf-netconf" module had to introduce an extension. >> Even if this was not the WG intention, the current RFCs suggest the following. Notifications are part of operations layer and have _no_ representation in the RPC layer. Take a look at RFC5277 (1. Introduction) and compare the diagram of NETCONF protocol layers to the one in RFC6241. The diagram in the first document clearly allows RPC layer to be "bypassed" for the sole purpose of notifications. RFC6020 states that it models notifications. Therefore YANG simply must handle the entire model of a notification payload, not just the event (especially if we are talking about server-specific information, eventTime leaf is not an issue as examples of XML encoding for notification-stmt indicate). This would be quite simple if an additional restriction would be put in there which would require that the event always appears after eventTime leaf and that garbage might follow. >> >> Yuma's netconfd server violates the YANG contract by adding stuff where it currently cannot be added. It doesn't matter if RFC5277 has an extensible schema since you have no way of telling the client what's going on. > Why not? You could use additional capabilities. You could rewrite a lot of things, but right now, the XSD in RFC 5277 does not allow extensions (no element in the sequence). > Lada > Andy From alex@cisco.com Thu Jul 5 13:29:16 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B27111E80D9 for ; Thu, 5 Jul 2012 13:29:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[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 2VO7WafWKzrV for ; Thu, 5 Jul 2012 13:29:15 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id C497811E80D0 for ; Thu, 5 Jul 2012 13:29:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=alex@cisco.com; l=2518; q=dns/txt; s=iport; t=1341520170; x=1342729770; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=CB69q/kF/OTfTDTdFeNxrBgbRPYjDFb/a4tVWbZFKXI=; b=XSimRWi1bBqghzNK9LXrbo5oBkHkIXPjTLvgmvgbjASPvUR8y+BjNz8X S9SPHPmTGYytfTKV3NhwfKDR3aeaYxrZbh3gKA0LzQ4ypNyokkS8vB3GX yDD1+kyUmW8mZ1YnRXwB0OIvPI+WFiXs69Yu4Tc1U+TpPM56UOnwK1LZ7 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAOj39U+tJV2Z/2dsb2JhbABCA4VfsDiBGYEHghgBAQEEAQEBDwEQETgCCQIMAgICAQgOAgEEAQEBAgIGHQMCAgIZDAsUAQgIAgQBDQUIEweHaQuZUI0ZknoEgRyKGYMdgg8yYAOjVIFmgl8 X-IronPort-AV: E=Sophos;i="4.77,532,1336348800"; d="scan'208";a="99124341" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-2.cisco.com with ESMTP; 05 Jul 2012 20:29:30 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q65KTTGM007544 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 5 Jul 2012 20:29:29 GMT Received: from xmb-rcd-x05.cisco.com ([169.254.15.144]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.02.0298.004; Thu, 5 Jul 2012 15:29:29 -0500 From: "Alexander Clemm (alex)" To: Juergen Schoenwaelder , "Jernej Tuljak" Thread-Topic: [netmod] Modeling NETCONF Event Notifications Thread-Index: AQHNWQMg61hBKVq1IUia4jTbR4bYoJcYCemAgAEJYACAAGqugIAATF0AgAD/+ICAAAOIgIAAVfsQ Date: Thu, 5 Jul 2012 20:29:29 +0000 Message-ID: References: <4FF2C373.5040806@mg-soft.com> <4FF3F434.1040704@mg-soft.com> <4FF56479.7090203@mg-soft.com> <20120705100743.GA25426@elstar.local> In-Reply-To: <20120705100743.GA25426@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.154.200.126] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19022.000 x-tm-as-result: No--50.004600-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "netmod@ietf.org" Subject: Re: [netmod] Modeling NETCONF Event Notifications 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, 05 Jul 2012 20:29:16 -0000 UmVnYXJkaW5nIHNvbWUgYmFzaWMgaW5mb3JtYXRpb24gaW4gTmV0Y29uZiBldmVudCBub3RpZmlj YXRpb25zLCAgSSBhbSBub3Qgc3VyZSB3aHkgaXQgd291bGQgbmVlZCB0byBiZSBkZWZpbmVkIHZp YSBZQU5HLiAgQXNwZWN0cyB0aGF0IGNvdmVyIGluZm9ybWF0aW9uIHN1Y2ggYXMgdGltZSBzdGFt cCwgc2V2ZXJpdHksIGV2ZW50IHR5cGUsIHJlcG9ydGluZyBlbnRpdHkgLSBiYXNpY2FsbHksIHRo ZSB0eXBlIG9mIGluZm9ybWF0aW9uIGZvciB3aGljaCB0aGUgZm9ybWF0IGlzIGFsc28gZGVmaW5l ZCBpbiBzeXNsb2csIGFuZCB3aGljaCBpcyBjb21tb24gdG8gYW55IGtpbmQgb2YgZXZlbnQgLSBj b3VsZCBJTUhPIHZlcnkgd2VsbCBiZSAiaGFyZCBjb2RlZCIgYXMgbm90aWZpY2F0aW9uIHBhcmFt ZXRlcnMsIGp1c3QgbGlrZSBvcGVyYXRpb24gcGFyYW1ldGVycyBmb3Igb3RoZXIgTmV0Y29uZiBv cGVyYXRpb25zLiBJdCBpcyBub3QgY2xlYXIgdG8gbWUgd2hhdCB3b3VsZCBiZSBnYWluZWQgYnkg ZGVmaW5pbmcgc3VjaCBwYXJhbWV0ZXJzIGFzIFlBTkcgbW9kdWxlcy4gIA0KLS0tIEFsZXggIA0K DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogbmV0bW9kLWJvdW5jZXNAaWV0Zi5v cmcgW21haWx0bzpuZXRtb2QtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEp1ZXJnZW4g U2Nob2Vud2FlbGRlcg0KU2VudDogVGh1cnNkYXksIEp1bHkgMDUsIDIwMTIgMzowOCBBTQ0KVG86 IEplcm5laiBUdWxqYWsNCkNjOiBuZXRtb2RAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbbmV0bW9k XSBNb2RlbGluZyBORVRDT05GIEV2ZW50IE5vdGlmaWNhdGlvbnMNCg0KT24gVGh1LCBKdWwgMDUs IDIwMTIgYXQgMTE6NTU6MDVBTSArMDIwMCwgSmVybmVqIFR1bGphayB3cm90ZToNCj4gRG5lIDQu Ny4yMDEyIDIwOjM4LCBwacWhZSBMYWRpc2xhdiBMaG90a2E6DQo+ID5BbmR5IEJpZXJtYW48YW5k eUB5dW1hd29ya3MuY29tPiAgd3JpdGVzOg0KLi4uLi4NCg0KSSB0aGluayB5b3VyIHJlYWwgaXNz dWUgaXMgdGhhdCBSRkMgNTI3NyBraW5kIG9mIGhhcmQgY29kZXMgd2hhdCB0aGUNCmJhc2ljIGlu Zm9ybWF0aW9uIGlzIHRoYXQgZ29lcyBpbnRvIHRoZSBub3RpZmljYXRpb24uIEJ1dCB0aGVuIHRo ZXJlDQp3YXMgbm8gWUFORyB3aGVuIHRoaXMgd2FzIGRvbmUgKGFuZCB0aGUgYXV0aG9ycy9lZGl0 b3JzIG9mIHRoYXQNCmRvY3VtZW50IGJlbGlldmVkIHRoYXQgWFNEIGlzIGFueXdheSB0aGUgaW5k dXN0cnkgc29sdXRpb24gdG8gZGF0YQ0KbW9kZWxpbmcgYW5kIHBlcmhhcHMgdGhlIFhTRCBpcyBl eHRlbnNpYmxlLi4uIDstKS4NCg0KTXkgdGFrZSBpcyB0aGF0IFJGQyA1Mjc3IG1heSBuZWVkIGEg cmV2aXNpb24uIEJ1dCB0aGF0IHdvdWxkIGJlIHRoZQ0Kam9iIG9mIHRoZSBORVRDT05GIHdvcmtp bmcgZ3JvdXAsIG5vdCB0aGUgam9iIG9mIHRoZSBORVRNT0Qgd29ya2luZw0KZ3JvdXAgKHRoaXMg bGlzdCkuDQoNCi9qcw0KDQotLSANCkp1ZXJnZW4gU2Nob2Vud2FlbGRlciAgICAgICAgICAgSmFj b2JzIFVuaXZlcnNpdHkgQnJlbWVuIGdHbWJIDQpQaG9uZTogKzQ5IDQyMSAyMDAgMzU4NyAgICAg ICAgIENhbXB1cyBSaW5nIDEsIDI4NzU5IEJyZW1lbiwgR2VybWFueQ0KRmF4OiAgICs0OSA0MjEg MjAwIDMxMDMgICAgICAgICA8aHR0cDovL3d3dy5qYWNvYnMtdW5pdmVyc2l0eS5kZS8+DQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbmV0bW9kIG1haWxp bmcgbGlzdA0KbmV0bW9kQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL25ldG1vZA0K From j.schoenwaelder@jacobs-university.de Thu Jul 5 14:51:09 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A23B511E80D0 for ; Thu, 5 Jul 2012 14:51:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.193 X-Spam-Level: X-Spam-Status: No, score=-103.193 tagged_above=-999 required=5 tests=[AWL=0.056, 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 JFpRsw0ttKbO for ; Thu, 5 Jul 2012 14:51: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 3F37C11E80CD for ; Thu, 5 Jul 2012 14:51:04 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id D92B420DD9; Thu, 5 Jul 2012 23:51:17 +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 0iKMX-9AuThW; Thu, 5 Jul 2012 23:51: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 669B920DD8; Thu, 5 Jul 2012 23:51:17 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 96AC52047888; Thu, 5 Jul 2012 23:51:16 +0200 (CEST) Date: Thu, 5 Jul 2012 23:51:15 +0200 From: Juergen Schoenwaelder To: "Alexander Clemm (alex)" Message-ID: <20120705215115.GA27587@elstar.local> Mail-Followup-To: "Alexander Clemm (alex)" , Jernej Tuljak , "netmod@ietf.org" References: <4FF2C373.5040806@mg-soft.com> <4FF3F434.1040704@mg-soft.com> <4FF56479.7090203@mg-soft.com> <20120705100743.GA25426@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] Modeling NETCONF Event Notifications 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, 05 Jul 2012 21:51:10 -0000 On Thu, Jul 05, 2012 at 08:29:29PM +0000, Alexander Clemm (alex) wrote: > Regarding some basic information in Netconf event notifications, I am not sure why it would need to be defined via YANG. Aspects that cover information such as time stamp, severity, event type, reporting entity - basically, the type of information for which the format is also defined in syslog, and which is common to any kind of event - could IMHO very well be "hard coded" as notification parameters, just like operation parameters for other Netconf operations. It is not clear to me what would be gained by defining such parameters as YANG modules. I think the thread started because someone found the things currently hard coded not sufficient and there is no easy way to augment things. If you are fine with what is there, feel happy. ;-) /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 Jul 5 18:52:49 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE51811E811D for ; Thu, 5 Jul 2012 18:52:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.239 X-Spam-Level: X-Spam-Status: No, score=-3.239 tagged_above=-999 required=5 tests=[AWL=0.360, 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 VU7+NP8mulnB for ; Thu, 5 Jul 2012 18:52:49 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 34D1F11E810E for ; Thu, 5 Jul 2012 18:52:49 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so14030749pbc.31 for ; Thu, 05 Jul 2012 18:53:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding :x-gm-message-state; bh=zF9O+mJy9m24VO+aokzVQROkcWJGnFv/rNXrhoCt4S8=; b=CZk2RQh0upDVQUyvtLpr3JcIzsUfFE07+gbxoWpku0ISsHmCgngl9/YPKPNufn96ij Ys5z+O+Z25dJxX/8pAVFMAbx7XMIl6bVDgHefiTm01WH8+qt6jmJw6XPSwCb7ymW9phL nfvQApbnZ1dcHJYbWfNiWmhbE+xCY0fQhbkZL7TQ1JIyo6A2+RPcavKolVaSkVTWbXCh 7NNOy6jnEs/3yMznVzYsdhnogtjgtKRK/hl286xr+TMa8u/Vb5UE3WNofWe74KYNe0Zq zMP/0ZaRi+1Ui2Nscs48bjzNfA4MaKNzUUFOs4yABOiChDVG1GuzM2M/wd0I1y8qjze/ Ty5Q== Received: by 10.68.221.74 with SMTP id qc10mr32179556pbc.31.1341539584089; Thu, 05 Jul 2012 18:53:04 -0700 (PDT) Received: from [192.168.0.18] (cpe-75-84-168-164.socal.res.rr.com. [75.84.168.164]) by mx.google.com with ESMTPS id wf7sm20819879pbc.34.2012.07.05.18.53.01 (version=SSLv3 cipher=OTHER); Thu, 05 Jul 2012 18:53:02 -0700 (PDT) Message-ID: <4FF64504.6000909@yumaworks.com> Date: Thu, 05 Jul 2012 18:53:08 -0700 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: "Ersue, Mehmet (NSN - DE/Munich)" References: <4FF2C373.5040806@mg-soft.com> <20120703115832.GA669@elstar.local> <80A0822C5E9A4440A5117C2F4CD36A6403FCE65B@DEMUEXC006.nsn-intra.net> In-Reply-To: <80A0822C5E9A4440A5117C2F4CD36A6403FCE65B@DEMUEXC006.nsn-intra.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQlacwrJe5WFhw8VrdH53Du0018HUCL6Pet+3fiUA7/ta3Yd3cru0PdMP0l9JKihDUXFduUq Cc: netconf@ietf.org, NETMOD Working Group Subject: Re: [netmod] [Netconf] Modeling NETCONF Event Notifications 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, 06 Jul 2012 01:52:49 -0000 On 07/03/2012 07:01 AM, Ersue, Mehmet (NSN - DE/Munich) wrote: > True. Is there any volunteer willing to yangify RFC 5277? Yes -- since I already started with notifications.yang and nc-notifications.yang. > > Mehmet Andy > > >> -----Original Message----- >> From: netmod-bounces@ietf.org [mailto:netmod-bounces@ietf.org] On > Behalf Of ext >> Juergen Schoenwaelder >> Sent: Tuesday, July 03, 2012 1:59 PM >> To: Jernej Tuljak >> Cc: NETMOD Working Group >> Subject: Re: [netmod] Modeling NETCONF Event Notifications >> >> On Tue, Jul 03, 2012 at 12:03:31PM +0200, Jernej Tuljak wrote: >> >>> I have questions regarding NETCONF Notifications and YANG. Which >>> YANG module is the standard module that models RFC5277 >>> notifications? I've got nc-notifications@2008-07-14 >>> and notifications@2008-07-14 >>> over here, but it's quite evident >>> that they are part of yuma's netconfd. Are these what I'm looking >>> for? >> RFC 5277 predates the 'yangification' of the NETCONF specification and >> there likely is a need to update/redo RFC 5277 at some point in time. >> >> /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 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From andy@yumaworks.com Thu Jul 5 19:08:08 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E63B11E812B for ; Thu, 5 Jul 2012 19:08:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.255 X-Spam-Level: X-Spam-Status: No, score=-3.255 tagged_above=-999 required=5 tests=[AWL=0.344, 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 pMyfZ3dPd8KG for ; Thu, 5 Jul 2012 19:08:07 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5988B11E810B for ; Thu, 5 Jul 2012 19:08:07 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so14049494pbc.31 for ; Thu, 05 Jul 2012 19:08:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding :x-gm-message-state; bh=Fm/DHvw0XFeA91/fgBxRQ/bPgXPIcNUlGLtoSzoJ3Kw=; b=iEkWzP4/LwRBkjW3++Xib/VBvP73RMJ5cTnT04e0yVkYQOa5MV8wk/IdFfDPOEDLyW 8LLncwjkr5nDM5Bn1E/i9OWnV/XsxxGQwS3vh2PEacxgx3x+x4EAlVzkktdE3gg4IsTm Xfc9FdsPNnEVrA0cjvaXHww+414/hqrZU77dJ4pnAkgLmtLebkrkdfuJQkpuRn0RF600 i0Cziz81UvWxRPw7314b+Nrt+DbjFLL8vmoCVwOripTD8832gA45GMJRdPY7bYvmBjOF rYNMAogzxjvul/QfoffZBklT/hzEZGvczSXvPhqePm00XmErDuWB6QFsvH/brWVGgSUP i8bw== Received: by 10.68.223.129 with SMTP id qu1mr32090976pbc.165.1341540498711; Thu, 05 Jul 2012 19:08:18 -0700 (PDT) Received: from [192.168.0.18] (cpe-75-84-168-164.socal.res.rr.com. [75.84.168.164]) by mx.google.com with ESMTPS id iu6sm20842761pbc.35.2012.07.05.19.08.16 (version=SSLv3 cipher=OTHER); Thu, 05 Jul 2012 19:08:17 -0700 (PDT) Message-ID: <4FF64897.5090804@yumaworks.com> Date: Thu, 05 Jul 2012 19:08:23 -0700 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: "Alexander Clemm (alex)" References: <4FF2C373.5040806@mg-soft.com> <4FF3F434.1040704@mg-soft.com> <4FF56479.7090203@mg-soft.com> <20120705100743.GA25426@elstar.local> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Gm-Message-State: ALoCoQkVu5II8T0m5nZh6WEOPdvzTSprCzXU+bsIsgMMhUa8blYhVwB6YzDDYExKwwMyE4TlvYxq Cc: "netmod@ietf.org" Subject: Re: [netmod] Modeling NETCONF Event Notifications 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, 06 Jul 2012 02:08:08 -0000 On 07/05/2012 01:29 PM, Alexander Clemm (alex) wrote: > Regarding some basic information in Netconf event notifications, I am not sure why it would need to be defined via YANG. Aspects that cover information such as time stamp, severity, event type, reporting entity - basically, the type of information for which the format is also defined in syslog, and which is common to any kind of event - could IMHO very well be "hard coded" as notification parameters, just like operation parameters for other Netconf operations. It is not clear to me what would be gained by defining such parameters as YANG modules. At 1 level, it is the same. You could either advertise a special capability, like notification:1.0, interleave:1.0, etc., or you could advertise a YANG module capability instead (ietf-netconf-notifications.yang). The difference is in the tool automation. Every little foo:1.x has hard-wired semantics. The hack in ietf-netconf.yang is the YANG version the same thing. But using plain standard YANG with augmentations is not hard-wired. That's why Jernej is right, and there should either be no vendor/WG extensibility at all to the header, or it should be done in a standard way, preferably YANG. We may also need to support multiple encodings, so I prefer not to rely on undocumented XML attributes, ala header attributes. > --- Alex Andy > > -----Original Message----- > From: netmod-bounces@ietf.org [mailto:netmod-bounces@ietf.org] On Behalf Of Juergen Schoenwaelder > Sent: Thursday, July 05, 2012 3:08 AM > To: Jernej Tuljak > Cc: netmod@ietf.org > Subject: Re: [netmod] Modeling NETCONF Event Notifications > > On Thu, Jul 05, 2012 at 11:55:05AM +0200, Jernej Tuljak wrote: >> Dne 4.7.2012 20:38, piše Ladislav Lhotka: >>> Andy Bierman writes: > ..... > > I think your real issue is that RFC 5277 kind of hard codes what the > basic information is that goes into the notification. But then there > was no YANG when this was done (and the authors/editors of that > document believed that XSD is anyway the industry solution to data > modeling and perhaps the XSD is extensible... ;-). > > My take is that RFC 5277 may need a revision. But that would be the > job of the NETCONF working group, not the job of the NETMOD working > group (this list). > > /js > From chelliot@gmail.com Thu Jul 5 19:37:14 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C29D11E813E for ; Thu, 5 Jul 2012 19:37:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[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 BSiWQq4PKObG for ; Thu, 5 Jul 2012 19:37:13 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3016C11E813F for ; Thu, 5 Jul 2012 19:37:13 -0700 (PDT) Received: by ggnc4 with SMTP id c4so8948394ggn.31 for ; Thu, 05 Jul 2012 19:37:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:message-id:in-reply-to:references:subject :x-mailer:mime-version:content-type; bh=pM0fGp5JV2qQLT2Ety3OuG3jkk/zPkjx+NcSxyPzSpc=; b=085gS5FcKFQp1pgeLCPQLHur7T/+cvam9qGUoYBIqjWx0EjHxmTZUqepIMgn0vc+jT vZauz2DgWGt+VbU20Y7Mg8dyYVUmlF8qDGHaMzurF1LjeZno5o0DxalcxuoDYZGMHL7I aOpte3ERkTYqRnQTdfur4nixZPZjz6E3FdQvAr+mE0KinN6IzV0ZLFUzoskTIOpoQVKp nQkDwbbXV+lDX9d4S/Puf4J9P5pmJ2OwrUaX/tCdsc8aCW4H3XrqxsppMEVvSPE9YNwj kQHCfjYGyQmzHZgwGuMx9uBBapblQ80npBnlWqjJkfNz1helCoMSgEVez71oNH2ZwTiK iXmQ== Received: by 10.236.189.104 with SMTP id b68mr33730498yhn.70.1341542248037; Thu, 05 Jul 2012 19:37:28 -0700 (PDT) Received: from [10.0.1.9] (cpe-024-211-184-116.nc.res.rr.com. [24.211.184.116]) by mx.google.com with ESMTPS id i65sm33425505yhb.3.2012.07.05.19.37.26 (version=SSLv3 cipher=OTHER); Thu, 05 Jul 2012 19:37:27 -0700 (PDT) Sender: Chris Elliott Date: Thu, 5 Jul 2012 22:37:26 -0400 From: Chris Elliott To: Andy Bierman Message-ID: <468B99C83624487AA6497DFD6E2565B5@pobox.com> In-Reply-To: <4FF64897.5090804@yumaworks.com> References: <4FF2C373.5040806@mg-soft.com> <4FF3F434.1040704@mg-soft.com> <4FF56479.7090203@mg-soft.com> <20120705100743.GA25426@elstar.local> <4FF64897.5090804@yumaworks.com> X-Mailer: sparrow 1.3 (build 495) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="4ff64f66_b03e0c6_aa5" Cc: "=?utf-8?Q?netmod=40ietf.org?=" Subject: Re: [netmod] Modeling NETCONF Event Notifications 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, 06 Jul 2012 02:37:14 -0000 --4ff64f66_b03e0c6_aa5 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Thursday, July 5, 2012 at 10:08 PM, Andy Bierman wrote: > On 07/05/2012 01:29 PM, Alexander Clemm (alex) wrote: > > Regarding some basic information in Netconf event notifications, I am= not sure why it would need to be defined via YANG. Aspects that cover in= formation such as time stamp, severity, event type, reporting entity - ba= sically, the type of information for which the format is also defined in = syslog, and which is common to any kind of event - could IMHO very well b= e =22hard coded=22 as notification parameters, just like operation parame= ters for other Netconf operations. It is not clear to me what would be ga= ined by defining such parameters as YANG modules. > =20 > =20 > =20 > At 1 level, it is the same. You could either advertise a special capabi= lity, > like notification:1.0, interleave:1.0, etc., or you could advertise a Y= ANG module > capability instead (ietf-netconf-notifications.yang). > =20 > The difference is in the tool automation. > Every little foo:1.x has hard-wired semantics. > The hack in ietf-netconf.yang is the YANG version the same thi= ng. > =20 > But using plain standard YANG with augmentations is not hard-wired. > That's why Jernej is right, and there should either be no vendor/WG ext= ensibility > at all to the header, =20 > =20 > =20 In which case we're just duplicating syslog functionality and we might as= well not do notifications at all, in my opinion. =20 > or it should be done in a standard way, preferably YANG. > =20 > =20 I strongly prefer using YANG and making notifications extensible. Chris. =20 > We may also need to support multiple encodings, so I prefer not to rely= on undocumented > XML attributes, ala header attributes. > =20 > =20 > > --- Alex > =20 > Andy > =20 > > =20 > > -----Original Message----- > > =46rom: netmod-bounces=40ietf.org =5Bmailto:netmod-bounces=40ietf.org= =5D On Behalf Of Juergen Schoenwaelder > > Sent: Thursday, July 05, 2012 3:08 AM > > To: Jernej Tuljak > > Cc: netmod=40ietf.org > > Subject: Re: =5Bnetmod=5D Modeling NETCON=46 Event Notifications > > =20 > > On Thu, Jul 05, 2012 at 11:55:05AM +0200, Jernej Tuljak wrote: > > > Dne 4.7.2012 20:38, pi=C5=A1e Ladislav Lhotka: > > > > Andy Bierman writes: > > > =20 > > > =20 > > =20 > > ..... > > =20 > > I think your real issue is that R=46C 5277 kind of hard codes what th= e > > basic information is that goes into the notification. But then there > > was no YANG when this was done (and the authors/editors of that > > document believed that XSD is anyway the industry solution to data > > modeling and perhaps the XSD is extensible... ;-). > > =20 > > My take is that R=46C 5277 may need a revision. But that would be the= > > job of the NETCON=46 working group, not the job of the NETMOD working= > > group (this list). > > =20 > > /js =20 --4ff64f66_b03e0c6_aa5 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
On Thursday, July 5, 2012 at 10:08 PM, Andy Bierman w= rote:
On 07/05/2012 01= :29 PM, Alexander Clemm (alex) wrote:
=
Regarding some basic information in Netconf event notifications, I = am not sure why it would need to be defined via YANG. Aspects that cover= information such as time stamp, severity, event type, reporting entity -= basically, the type of information for which the format is also defined = in syslog, and which is common to any kind of event - could IMHO very wel= l be =22hard coded=22 as notification parameters, just like operation par= ameters for other Netconf operations. It is not clear to me what would be= gained by defining such parameters as YANG modules.


At 1 level, it is the same. You could e= ither advertise a special capability,
like notification:1.0, in= terleave:1.0, etc., or you could advertise a YANG module
capabi= lity instead (ietf-netconf-notifications.yang).

= The difference is in the tool automation.
Every little foo:1.x = has hard-wired semantics.
The <filter> hack in ietf-netco= nf.yang is the YANG version the same thing.

But = using plain standard YANG with augmentations is not hard-wired.
That's why Jernej is right, and there should either be no vendor/WG exte= nsibility
at all to the <notification> header,

In which case we're just duplica= ting syslog functionality and we might as well not do notifications at al= l, in my opinion.
 
or it shou= ld be done in a standard way, preferably YANG.

I strongly prefer using YANG and making notificat= ions extensible.

Chris.
 
We may also need to support multiple encodings, so I= prefer not to rely on undocumented
XML attributes, ala <rpc= > header attributes.


--- Alex

Andy<= /div>


-----Original Message-----
=46rom: netmod-bounces=40ietf.org = =5Bmailto:netmod-bounces=40ietf.org=5D On Behalf Of Juergen Schoenwaelder=
Sent: Thursday, July 05, 2012 3:08 AM
To: Jernej Tul= jak
Cc: netmod=40ietf.org
Subject: Re: =5Bnetmod=5D M= odeling NETCON=46 Event Notifications

On Thu, Ju= l 05, 2012 at 11:55:05AM +0200, Jernej Tuljak wrote:
Dne 4.7.2012 20:38, pi=C5=A1e Ladislav Lhotka:
Andy Bierman<andy=40yumaworks.c= om> writes:
.....

I think your real issue is that R=46C 5277 kind of hard c= odes what the
basic information is that goes into the notificat= ion. But then there
was no YANG when this was done (and the aut= hors/editors of that
document believed that XSD is anyway the i= ndustry solution to data
modeling and perhaps the XSD is extens= ible... ;-).

My take is that R=46C 5277 may need= a revision. But that would be the
job of the NETCON=46 working= group, not the job of the NETMOD working
group (this list).

/js
=20 =20 =20 =20 =20

--4ff64f66_b03e0c6_aa5-- From randy_presuhn@mindspring.com Thu Jul 5 21:50:03 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 409FA21F871C for ; Thu, 5 Jul 2012 21:50:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.185 X-Spam-Level: X-Spam-Status: No, score=-100.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, 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 A2KsQXM8s2g3 for ; Thu, 5 Jul 2012 21:50:01 -0700 (PDT) Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by ietfa.amsl.com (Postfix) with ESMTP id 252A021F86D8 for ; Thu, 5 Jul 2012 21:49:42 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=XIVwYj8M46tCn5NHG08J28bN2PItNTS/nJYFyvmcyNub+V0NLL1XfqrxE2JjxdVQ; h=Message-ID:Date:From:Reply-To:To:Subject:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.45] (helo=elwamui-polski.atl.sa.earthlink.net) by elasmtp-curtail.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Sn0UQ-0002sW-0O for netmod@ietf.org; Fri, 06 Jul 2012 00:49:58 -0400 Received: from 99.38.144.250 by webmail.earthlink.net with HTTP; Fri, 6 Jul 2012 00:49:57 -0400 Message-ID: <28072589.1341550197957.JavaMail.root@elwamui-polski.atl.sa.earthlink.net> Date: Thu, 5 Jul 2012 21:49:57 -0700 (GMT-07:00) From: Randy Presuhn To: netmod@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888b7f3a87d4e9c50f13a8ecb1aa7bc22c39ef81fba1941bb97350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.45 Subject: Re: [netmod] Modeling NETCONF Event Notifications X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Randy Presuhn List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2012 04:50:04 -0000 Hi - More lessons learned with CMIP and SNMP: There are some real advantages to making some generic pieces of notifications effectively mandatory *and* encoding them at an outer level. Specifically: - doing so makes very basic notification discrimination (both at sender and receiver) easier. This is an especially big win for generic logging facilities that need to figure out what to do with a notification when they're not able to fetch the necessary schema at the moment - this in turn makes basic throttling easier - it allows basic and "fancy" filtering / logging / etc. to be handled as distinct sets of conformance requirements - extensibility at the outer level can end up being more trouble than it's worth - the choice of things to include in the outer level needs to be made very carefully Randy From j.schoenwaelder@jacobs-university.de Fri Jul 6 00:04:55 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 607AB11E8097 for ; Fri, 6 Jul 2012 00:04:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.194 X-Spam-Level: X-Spam-Status: No, score=-103.194 tagged_above=-999 required=5 tests=[AWL=0.055, 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 jQG-XP8Y2r6R for ; Fri, 6 Jul 2012 00:04:53 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 7960A11E8079 for ; Fri, 6 Jul 2012 00:04:51 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id A703320DD8; Fri, 6 Jul 2012 09:05:05 +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 v2isJhWzfd6g; Fri, 6 Jul 2012 09:05: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 15F3320DE2; Fri, 6 Jul 2012 09:05:05 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 5A9222047E6A; Fri, 6 Jul 2012 09:05:04 +0200 (CEST) Date: Fri, 6 Jul 2012 09:05:04 +0200 From: Juergen Schoenwaelder To: Randy Presuhn Message-ID: <20120706070504.GD28365@elstar.local> Mail-Followup-To: Randy Presuhn , netmod@ietf.org References: <28072589.1341550197957.JavaMail.root@elwamui-polski.atl.sa.earthlink.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <28072589.1341550197957.JavaMail.root@elwamui-polski.atl.sa.earthlink.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] Modeling NETCONF Event Notifications 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, 06 Jul 2012 07:04:55 -0000 On Thu, Jul 05, 2012 at 09:49:57PM -0700, Randy Presuhn wrote: > Hi - > > More lessons learned with CMIP and SNMP: There are some real > advantages to making some generic pieces of notifications > effectively mandatory *and* encoding them at an outer level. > > Specifically: > - doing so makes very basic notification discrimination (both > at sender and receiver) easier. This is an especially > big win for generic logging facilities that need to figure > out what to do with a notification when they're not able > to fetch the necessary schema at the moment > - this in turn makes basic throttling easier > - it allows basic and "fancy" filtering / logging / etc. to > be handled as distinct sets of conformance requirements > - extensibility at the outer level can end up being more trouble > than it's worth > - the choice of things to include in the outer level needs > to be made very carefully Well, this is what we have. The problem is that there is not way to add stuff to it, things that go into every notification. Can you elaborate why "extensibility at the outer level can end up being more trouble than it's worth"? /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 Fri Jul 6 00:08:07 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B2EC21F85D5 for ; Fri, 6 Jul 2012 00:08:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.194 X-Spam-Level: X-Spam-Status: No, score=-103.194 tagged_above=-999 required=5 tests=[AWL=0.055, 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 O5OPxRRB623F for ; Fri, 6 Jul 2012 00:08: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 9B31B21F85BB for ; Fri, 6 Jul 2012 00:08:03 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id CFBEB20DE5; Fri, 6 Jul 2012 09:08:18 +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 KfGUjmLHWepK; Fri, 6 Jul 2012 09:08: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 7319C20DE4; Fri, 6 Jul 2012 09:08:18 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 6A8562047EF8; Fri, 6 Jul 2012 09:08:18 +0200 (CEST) Date: Fri, 6 Jul 2012 09:08:18 +0200 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20120706070818.GA28508@elstar.local> Mail-Followup-To: netmod@ietf.org References: <20120702074856.GA44433@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120702074856.GA44433@elstar.local> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [netmod] adoption of draft-lange-netmod-iana-timezones 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, 06 Jul 2012 07:08:07 -0000 On Mon, Jul 02, 2012 at 09:48:56AM +0200, Juergen Schoenwaelder wrote: > Hi, > this a quick poll to determine whether the WG wants to adopt the > IANA maintained timezone typedef as WG document. The typedef is > currently defined in: > > http://tools.ietf.org/html/draft-lange-netmod-iana-timezones-01 > > Please respond to the mailing list by 2012-07-08 if you think > this is the right way forward or if you have reasons that we > should not follow this path. This is a friendly reminder that people should air their opinion about using an IANA module for timezones. /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 Jul 6 10:16:02 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FE2421F8601 for ; Fri, 6 Jul 2012 10:16:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.952 X-Spam-Level: X-Spam-Status: No, score=-2.952 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 FKiBqnslWc9r for ; Fri, 6 Jul 2012 10:16:01 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0C0DE21F85EA for ; Fri, 6 Jul 2012 10:16:00 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so14761842lbb.31 for ; Fri, 06 Jul 2012 10:16:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:content-type:x-gm-message-state; bh=bQsMWZXt/OLOG9FSI8EPeKwJvfMnmgusqGqr0YVoRzc=; b=pFptPoYkfhRoczxUdbNgkQ8wmxiptMdXqEBBoMCilPvwSUZFDm1mXsVPIIVFxIejBW h/lA7pzq2BX4hkAQydyuUZTZvW9CvbYfPn/nM10cSorrNticwO/ZpNLptNvN1rbj+c4w PDU8oJk8gM+ihwuhre3tB3aYmretVKFvPgfWB/NCK7tyui55TB6b5SfRa3TWBGfWWBGf 8jdKPMaON/WqrsJm2DY5FjGpUO63INmZYGIHckDp6nH4GPhI4kKDEFdGykY1AQXkcU5S L+loQnFmPnqjnkByhqcvzqBYH4sI+Uocn0jWF9S5hqQsRyDvlYt5TxU0sp3WpEerARpm ypkQ== MIME-Version: 1.0 Received: by 10.112.36.132 with SMTP id q4mr14100825lbj.63.1341594976881; Fri, 06 Jul 2012 10:16:16 -0700 (PDT) Received: by 10.114.19.72 with HTTP; Fri, 6 Jul 2012 10:16:16 -0700 (PDT) X-Originating-IP: [75.84.168.164] In-Reply-To: <20120706070818.GA28508@elstar.local> References: <20120702074856.GA44433@elstar.local> <20120706070818.GA28508@elstar.local> Date: Fri, 6 Jul 2012 10:16:16 -0700 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , netmod@ietf.org Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQmgp3iVKbLFhGdLpQ5MIuEUj02OQ/Eq5kFcdOBtPtzDEP4y7ICWplRRbm5vv188BX5etIFv Subject: Re: [netmod] adoption of draft-lange-netmod-iana-timezones 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, 06 Jul 2012 17:16:02 -0000 I support adopting this draft. IMO it is already covered by the ietf-system charter. We just want to make this typedef easier to reuse. Andy On Fri, Jul 6, 2012 at 12:08 AM, Juergen Schoenwaelder wrote: > On Mon, Jul 02, 2012 at 09:48:56AM +0200, Juergen Schoenwaelder wrote: >> Hi, >> this a quick poll to determine whether the WG wants to adopt the >> IANA maintained timezone typedef as WG document. The typedef is >> currently defined in: >> >> http://tools.ietf.org/html/draft-lange-netmod-iana-timezones-01 >> >> Please respond to the mailing list by 2012-07-08 if you think >> this is the right way forward or if you have reasons that we >> should not follow this path. > > This is a friendly reminder that people should air their opinion about > using an IANA module for timezones. > > /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 randy_presuhn@mindspring.com Fri Jul 6 10:16:41 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1C4521F86BD for ; Fri, 6 Jul 2012 10:16:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.09 X-Spam-Level: X-Spam-Status: No, score=-101.09 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_05=-1.11, 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 Uc5NVIHzHEue for ; Fri, 6 Jul 2012 10:16:41 -0700 (PDT) Received: from elasmtp-galgo.atl.sa.earthlink.net (elasmtp-galgo.atl.sa.earthlink.net [209.86.89.61]) by ietfa.amsl.com (Postfix) with ESMTP id 6C92D21F8601 for ; Fri, 6 Jul 2012 10:16:41 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=kyYThyvmWztKpEVNb5+ETaYaMLd3wDULTbihSxrZ5YBbV++vT/Z1HjSbrwGQs3wS; 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 [99.38.144.250] (helo=oemcomputer) by elasmtp-galgo.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1SnC9J-0003Jh-QI for netmod@ietf.org; Fri, 06 Jul 2012 13:16:58 -0400 Message-ID: <001f01cd5b9b$be31b6c0$6b01a8c0@oemcomputer> From: "Randy Presuhn" To: References: <28072589.1341550197957.JavaMail.root@elwamui-polski.atl.sa.earthlink.net> <20120706070504.GD28365@elstar.local> Date: Fri, 6 Jul 2012 10:21:11 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888b7f3a87d4e9c50f165c7f1d0f26f9ed106a67a482c979b6c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.38.144.250 Subject: Re: [netmod] Modeling NETCONF Event Notifications 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, 06 Jul 2012 17:16:42 -0000 Hi - > From: "Juergen Schoenwaelder" > To: "Randy Presuhn" > Cc: > Sent: Friday, July 06, 2012 12:05 AM > Subject: Re: [netmod] Modeling NETCONF Event Notifications ... > The problem is that there is not way to > add stuff to it, things that go into every notification. >From a compatibility perspective, this is a feature, not a bug, IMO. > Can you > elaborate why "extensibility at the outer level can end up being more > trouble than it's worth"? Netconf and CMIP are similar in effectively requiring a generic notification receiver to be able to dynamically learn schemas to *understand* payloads from hitherto unheard-of devices. Even if the entity processing a notification has the necessary code in place, network connectivity issues (for example) may prevent it from acquiring those schema definitions in a timely manner. This is the core of the argument for separating the "outer" stuff from the "inner" stuff syntactically. Adding an extensibility requirement to the "outer" stuff negates the advantages of the separation. Randy From andy@yumaworks.com Fri Jul 6 10:36:34 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23D9311E807F for ; Fri, 6 Jul 2012 10:36:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.952 X-Spam-Level: X-Spam-Status: No, score=-2.952 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 6a2CAMmpe6vd for ; Fri, 6 Jul 2012 10:36:33 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 388C821F8462 for ; Fri, 6 Jul 2012 10:36:33 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so14784426lbb.31 for ; Fri, 06 Jul 2012 10: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-originating-ip:in-reply-to:references:date :message-id:subject:from:to:content-type:x-gm-message-state; bh=u1n/D6jXwd8Zvf7LtPglBAsqG458FYRjQs6ZGqn7nAw=; b=Ecv2NSB0ajOshagjlF4WDJuWPLyIWhOPyVKXT3ZQyKZaFHoqoykpKvZmxA/s7biDUt UonvFCscADp6wMvFTGXvK5RuVsGYEXQyGJI/qSiH78ERoDZ7QJztPUxpYVGk4YdWP2jc HAzYCT3sbVJas4J6OZwn3XqYt+Qfc1Uqm6KHfa3QgeDQ6GjShqbeTMo2i7rfRBnj1lcV uY4uAaVbGCS5pHGWHeEgPe52T9G3Y/bs4YIh0ZQ2Xl7UXundjOdVSu5IZtcp5cAdCXYa 0GrOWShJdsTaMnsMPHHwTmNPPmv1bBheg00qH/Ahiwnrl5C7Osw6yMsddU7qMEXhDZxn d7Tw== MIME-Version: 1.0 Received: by 10.112.86.166 with SMTP id q6mr14018062lbz.6.1341596209174; Fri, 06 Jul 2012 10:36:49 -0700 (PDT) Received: by 10.114.19.72 with HTTP; Fri, 6 Jul 2012 10:36:49 -0700 (PDT) X-Originating-IP: [75.84.168.164] In-Reply-To: <20120706070504.GD28365@elstar.local> References: <28072589.1341550197957.JavaMail.root@elwamui-polski.atl.sa.earthlink.net> <20120706070504.GD28365@elstar.local> Date: Fri, 6 Jul 2012 10:36:49 -0700 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , Randy Presuhn , netmod@ietf.org Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQmTxUbLKlsAA+1kxg/oAzS9uCTmi4OHJ9nPGFZ46nTbDDaGmgCwYLnD+XYDvAcmPeoWKci/ Subject: Re: [netmod] Modeling NETCONF Event Notifications 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, 06 Jul 2012 17:36:34 -0000 On Fri, Jul 6, 2012 at 12:05 AM, Juergen Schoenwaelder wrote: > On Thu, Jul 05, 2012 at 09:49:57PM -0700, Randy Presuhn wrote: >> Hi - >> >> More lessons learned with CMIP and SNMP: There are some real >> advantages to making some generic pieces of notifications >> effectively mandatory *and* encoding them at an outer level. >> >> Specifically: >> - doing so makes very basic notification discrimination (both >> at sender and receiver) easier. This is an especially >> big win for generic logging facilities that need to figure >> out what to do with a notification when they're not able >> to fetch the necessary schema at the moment >> - this in turn makes basic throttling easier >> - it allows basic and "fancy" filtering / logging / etc. to >> be handled as distinct sets of conformance requirements >> - extensibility at the outer level can end up being more trouble >> than it's worth >> - the choice of things to include in the outer level needs >> to be made very carefully > > Well, this is what we have. The problem is that there is not way to > add stuff to it, things that go into every notification. Can you > elaborate why "extensibility at the outer level can end up being more > trouble than it's worth"? > I agree. It was probably an oversight that the XSD is not extensible. Some header fields like sequence-id, severity, class, etc. were considered at the time, but the WG only agreed on 1 timestamp. The original issue is still the key -- no matter how the notification content is defined, the client needs some way of knowing what content to expect. That could be done with a hard-wired capability URI, like notification:1.1. The notification format to use would need to be negotiated in the , similar to base:1.0 and base:1.1. It would be much more work to extend YANG to support augmentation of the notification element. IMO, there is no rush to update YANG to support this, but it should be considered in the future. This approach would break the contract implied by the notification:1.0 capability, so it doesn't really work unless a notification:1.1 capability is also defined. > /js Andy From randy_presuhn@mindspring.com Fri Jul 6 11:23:45 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FA1721F86A8 for ; Fri, 6 Jul 2012 11:23:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.841 X-Spam-Level: X-Spam-Status: No, score=-101.841 tagged_above=-999 required=5 tests=[AWL=0.758, 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 M-3UbQU91E9J for ; Fri, 6 Jul 2012 11:23:44 -0700 (PDT) Received: from elasmtp-galgo.atl.sa.earthlink.net (elasmtp-galgo.atl.sa.earthlink.net [209.86.89.61]) by ietfa.amsl.com (Postfix) with ESMTP id C793D21F86A2 for ; Fri, 6 Jul 2012 11:23:44 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=bjFz/uXHgE7JcDWaj8M4WfM5d4yJtw1Fvw8uN5r5wsBLwOsEqCWieYBKEGoJRadf; 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 [99.38.144.250] (helo=oemcomputer) by elasmtp-galgo.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1SnDCD-0006qe-Gw for netmod@ietf.org; Fri, 06 Jul 2012 14:24:01 -0400 Message-ID: <000401cd5ba5$1ddd8280$6b01a8c0@oemcomputer> From: "Randy Presuhn" To: References: <28072589.1341550197957.JavaMail.root@elwamui-polski.atl.sa.earthlink.net><20120706070504.GD28365@elstar.local> Date: Fri, 6 Jul 2012 11:28:17 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" 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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888b7f3a87d4e9c50f1288322243a1950a2d51666a97e1fd8d9350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.38.144.250 Subject: Re: [netmod] Modeling NETCONF Event Notifications 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, 06 Jul 2012 18:23:45 -0000 Hi - > From: "Andy Bierman" ... > >> - the choice of things to include in the outer level needs > >> to be made very carefully > > > > Well, this is what we have. The problem is that there is not way to > > add stuff to it, things that go into every notification. Can you > > elaborate why "extensibility at the outer level can end up being more > > trouble than it's worth"? > > > > I agree. It was probably an oversight that the XSD is not extensible. > Some header fields like sequence-id, severity, class, etc. were considered > at the time, but the WG only agreed on 1 timestamp. The experience reported so far suggests that timestamp is not enough. Otherwise we wounldn't be having this discussion. > The original issue is still the key -- no matter how the notification > content is defined, > the client needs some way of knowing what content to expect. That could be done > with a hard-wired capability URI, like notification:1.1. The > notification format > to use would need to be negotiated in the , similar to base:1.0 > and base:1.1. An alternative (too late now, though) is for the syntax of those mandatory "outer" elements to be part of the base protocol. One of the subtler consequences (something SNMP got mostly right and CMIP got slightly less right) is that the base protocol needs to knw about the naming architecture (structure and syntax, not necessarily the semantics of instance names, unless you add ad hoc matching rules, the latter being a big mistake IMO). Randy From lhotka@nic.cz Fri Jul 6 11:58:16 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9D2511E80A5 for ; Fri, 6 Jul 2012 11:58:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.962 X-Spam-Level: X-Spam-Status: No, score=-1.962 tagged_above=-999 required=5 tests=[AWL=0.037, 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 VUzIICesS-tu for ; Fri, 6 Jul 2012 11:58: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 EAD0211E8079 for ; Fri, 6 Jul 2012 11:58:15 -0700 (PDT) Received: from [172.29.2.202] (unknown [77.48.224.120]) by mail.nic.cz (Postfix) with ESMTPSA id 9F8BD140ECB; Fri, 6 Jul 2012 20:58:30 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1341601110; bh=jtH6M8qhtPvsp3oZxCk4mAfCO1BWD/IIHKJJiL2Gq0I=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=f1Io9zvBqmYGwvzsPqVA3qBc7/d0RQS1eyLlOjxQa4DOoGdGdlD52+VD+t9rZPMmH a+DrkT0HHtivhLtlPgrXFrW8u/CfoNkP2Z+Y7mYa0rEUcWBQxbTrWLWNrNQg4HNnAE PTEZKwN3pv904a+bvJKFQnBhi7nZLcqJb5iZHFsE= Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Ladislav Lhotka In-Reply-To: Date: Fri, 6 Jul 2012 20:58:31 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <07B164E8-CB03-4F45-9E65-2D1219F5C116@nic.cz> References: <20120702074856.GA44433@elstar.local> <20120706070818.GA28508@elstar.local> To: Andy Bierman X-Mailer: Apple Mail (2.1278) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] adoption of draft-lange-netmod-iana-timezones 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, 06 Jul 2012 18:58:17 -0000 On Jul 6, 2012, at 7:16 PM, Andy Bierman wrote: > I support adopting this draft. > IMO it is already covered by the ietf-system charter. > We just want to make this typedef easier to reuse. I also support adopting the draft. It is very reasonable to have the = IANA-controlled stuff as separate documents. Lada >=20 > Andy >=20 >=20 > On Fri, Jul 6, 2012 at 12:08 AM, Juergen Schoenwaelder > wrote: >> On Mon, Jul 02, 2012 at 09:48:56AM +0200, Juergen Schoenwaelder = wrote: >>> Hi, >>> this a quick poll to determine whether the WG wants to adopt the >>> IANA maintained timezone typedef as WG document. The typedef is >>> currently defined in: >>>=20 >>> http://tools.ietf.org/html/draft-lange-netmod-iana-timezones-01 >>>=20 >>> Please respond to the mailing list by 2012-07-08 if you think >>> this is the right way forward or if you have reasons that we >>> should not follow this path. >>=20 >> This is a friendly reminder that people should air their opinion = about >> using an IANA module for timezones. >>=20 >> /js >>=20 >> -- >> Juergen Schoenwaelder Jacobs University Bremen gGmbH >> Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany >> Fax: +49 421 200 3103 >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From chelliot@gmail.com Fri Jul 6 12:11:21 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 787AE11E80AD for ; Fri, 6 Jul 2012 12:11:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.298 X-Spam-Level: X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZCLjOmIBan6q for ; Fri, 6 Jul 2012 12:11:20 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 40C3311E809F for ; Fri, 6 Jul 2012 12:11:20 -0700 (PDT) Received: by yenq13 with SMTP id q13so9810214yen.31 for ; Fri, 06 Jul 2012 12:11:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:message-id:in-reply-to:references:subject :x-mailer:mime-version:content-type; bh=9q6I1iWsGIxmgGnUD7MkzWujjVDm5zm+HmffCb1iksI=; b=Y9+tfSrajHKPcVwn9ocr1YLS4zyJXotqQ1kyDqbzE/3KN6m2xL8Kz+OcSU9bLf21jE rVLAbgtaILAL+lEO94Xh5rLiON8VP0ZsJlisxAP3pACaL7PhtuS+1jPf9nqkMMu8D6YE ag/9/Fr7RbyPZyFjR7POVhogzYuZDz/04HYjVwFqXiRthYPVg8+6EDHjXeLdYUHuyI2I dv/Y8FIT+Bx66GW/Hds2kApGeXmz437mUvP2559JyjRwAO66cG3RXf2OWGaDvwlxH6n0 xcwMlzCMDnCNtDf8zFtYrZUoqX1iROg+kNDiorMjbgnVvfwxxcKLq1AwTbvYE7ineRfP wYlg== Received: by 10.236.173.135 with SMTP id v7mr36621352yhl.19.1341601897066; Fri, 06 Jul 2012 12:11:37 -0700 (PDT) Received: from [10.0.1.9] (cpe-024-211-184-116.nc.res.rr.com. [24.211.184.116]) by mx.google.com with ESMTPS id n43sm48957669yhm.7.2012.07.06.12.11.35 (version=SSLv3 cipher=OTHER); Fri, 06 Jul 2012 12:11:36 -0700 (PDT) Sender: Chris Elliott Date: Fri, 6 Jul 2012 15:11:34 -0400 From: Chris Elliott To: Ladislav Lhotka Message-ID: In-Reply-To: <07B164E8-CB03-4F45-9E65-2D1219F5C116@nic.cz> References: <20120702074856.GA44433@elstar.local> <20120706070818.GA28508@elstar.local> <07B164E8-CB03-4F45-9E65-2D1219F5C116@nic.cz> X-Mailer: sparrow 1.3 (build 495) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="4ff73866_3352255a_12ba" Cc: netmod@ietf.org Subject: Re: [netmod] adoption of draft-lange-netmod-iana-timezones 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, 06 Jul 2012 19:11:21 -0000 --4ff73866_3352255a_12ba Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline I would rather simply keep everything in UTC/GMT. However, given that that's not going to happen, I support IANA maintaining this for us. Chris. -- Chris Elliott On Friday, July 6, 2012 at 2:58 PM, Ladislav Lhotka wrote: > > On Jul 6, 2012, at 7:16 PM, Andy Bierman wrote: > > > I support adopting this draft. > > IMO it is already covered by the ietf-system charter. > > We just want to make this typedef easier to reuse. > > > > > I also support adopting the draft. It is very reasonable to have the IANA-controlled stuff as separate documents. > > Lada > > > > > Andy > > > > > > On Fri, Jul 6, 2012 at 12:08 AM, Juergen Schoenwaelder > > wrote: > > > On Mon, Jul 02, 2012 at 09:48:56AM +0200, Juergen Schoenwaelder wrote: > > > > Hi, > > > > this a quick poll to determine whether the WG wants to adopt the > > > > IANA maintained timezone typedef as WG document. The typedef is > > > > currently defined in: > > > > > > > > http://tools.ietf.org/html/draft-lange-netmod-iana-timezones-01 > > > > > > > > Please respond to the mailing list by 2012-07-08 if you think > > > > this is the right way forward or if you have reasons that we > > > > should not follow this path. > > > > > > > > > > > > > This is a friendly reminder that people should air their opinion about > > > using an IANA module for timezones. > > > > > > /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 > > > > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > > > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > --4ff73866_3352255a_12ba Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
I would rather simply keep everything in UTC/GMT. However, given = that that's not going to happen, I support IANA maintaining this for us.

Chris.


-= -
Chris Elliott

=20

On =46riday, July 6, 2012 at 2:58 = PM, Ladislav Lhotka wrote:


O= n Jul 6, 2012, at 7:16 PM, Andy Bierman wrote:

I support adopting this draft.
IMO it is already covered by the ietf-system charter.
We just= want to make this typedef easier to reuse.
=
I also support adopting the draft. It is very reasonable t= o have the IANA-controlled stuff as separate documents.

Lada

=
Andy


On =46ri, Jul= 6, 2012 at 12:08 AM, Juergen Schoenwaelder
<j.schoenwaelder= =40jacobs-university.de> wrote:
On Mon, Jul 02, 2012 at 09:48:56AM +0200, Juergen Schoenwaelder wr= ote:
Hi,
this a qu= ick poll to determine whether the WG wants to adopt the
IANA ma= intained timezone typedef as WG document. The typedef is
curren= tly defined in:

http://tools.ietf.org/html/draf= t-lange-netmod-iana-timezones-01

Please respond = to the mailing list by 2012-07-08 if you think
this is the righ= t way forward or if you have reasons that we
should not follow = this path.

This is a friendly= reminder that people should air their opinion about
using an I= ANA module for timezones.

/js

--
Juergen Schoenwaelder Jacobs University Bre= men gGmbH
Phone: +49 421 200 3587 Campus Ring 1, 28759 = Bremen, Germany
=46ax: +49 421 200 3103 <http://ww= w.jacobs-university.de/>
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
netmod mailing list
ne= tmod=40ietf.org
https://www.ietf.org/mailman/listinfo/netmod
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F
netmod mailing list
netmod=40ietf.= org
https://www.ietf.org/mailman/listinfo/netmod

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



=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F
netmod mailing list
netmod=40ietf.= org
https://www.ietf.org/mailman/listinfo/netmod
=20 =20 =20 =20
=20

--4ff73866_3352255a_12ba-- From internet-drafts@ietf.org Mon Jul 9 01:41:56 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67C7E21F8814; Mon, 9 Jul 2012 01:41:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.572 X-Spam-Level: X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.027, 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 AqUge09TrkjQ; Mon, 9 Jul 2012 01:41:55 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E275421F8686; Mon, 9 Jul 2012 01:41:55 -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.30p2 Message-ID: <20120709084155.21414.15195.idtracker@ietfa.amsl.com> Date: Mon, 09 Jul 2012 01:41:55 -0700 Cc: netmod@ietf.org Subject: [netmod] I-D Action: draft-ietf-netmod-routing-cfg-04.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, 09 Jul 2012 08:41:56 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the NETCONF Data Modeling Language Working Gr= oup of the IETF. Title : A YANG Data Model for Routing Configuration Author(s) : Ladislav Lhotka Filename : draft-ietf-netmod-routing-cfg-04.txt Pages : 62 Date : 2012-07-09 Abstract: This document contains a specification of three YANG modules. Together they form the core routing data model which serves as a framework for configuring a routing subsystem. It is therefore expected that these modules will be augmented by additional YANG modules defining data models for individual routing protocols and other related functions. The core routing data model provides common building blocks for such configurations - router instances, routes, routing tables, routing protocols and route filters. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-routing-cfg There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-netmod-routing-cfg-04 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-netmod-routing-cfg-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From j.schoenwaelder@jacobs-university.de Mon Jul 9 03:17:49 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84D0521F863C for ; Mon, 9 Jul 2012 03:17:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.196 X-Spam-Level: X-Spam-Status: No, score=-103.196 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E4Ot6v1CvrVO for ; Mon, 9 Jul 2012 03:17: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 B86AD21F8627 for ; Mon, 9 Jul 2012 03:17:48 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id C460620D8F; Mon, 9 Jul 2012 12:18:12 +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 xXlFxjReTRG4; Mon, 9 Jul 2012 12:18:12 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5A07620D8B; Mon, 9 Jul 2012 12:18:12 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 6FBB4204BAAB; Mon, 9 Jul 2012 12:18:10 +0200 (CEST) Date: Mon, 9 Jul 2012 12:18:09 +0200 From: Juergen Schoenwaelder To: netmod@ietf.org, Jeffrey Lange Message-ID: <20120709101808.GA9640@elstar.local> Mail-Followup-To: netmod@ietf.org, Jeffrey Lange References: <20120702074856.GA44433@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120702074856.GA44433@elstar.local> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [netmod] adoption of draft-lange-netmod-iana-timezones 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, 09 Jul 2012 10:17:49 -0000 On Mon, Jul 02, 2012 at 09:48:56AM +0200, Juergen Schoenwaelder wrote: > Hi, > this a quick poll to determine whether the WG wants to adopt the > IANA maintained timezone typedef as WG document. The typedef is > currently defined in: > > http://tools.ietf.org/html/draft-lange-netmod-iana-timezones-01 > > Please respond to the mailing list by 2012-07-08 if you think > this is the right way forward or if you have reasons that we > should not follow this path. Andy, Ladislav, and Chris have expressed their support. As technical contributor, I support it as well. There were no dissenting voices. So we will make this a WG document. Jeffrey, if you manage, please submit a -00 working group document (draft-ietf-netmod-iana-timezones-00) before the cutoff today at 17:00 PT (UTC -7). /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From internet-drafts@ietf.org Mon Jul 9 07:05:05 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B43CF11E8097; Mon, 9 Jul 2012 07:05:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.57 X-Spam-Level: X-Spam-Status: No, score=-102.57 tagged_above=-999 required=5 tests=[AWL=0.029, 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 JZT579MeQRGa; Mon, 9 Jul 2012 07:05:05 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F345621F85EA; Mon, 9 Jul 2012 07:05:04 -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.30p2 Message-ID: <20120709140504.26246.73843.idtracker@ietfa.amsl.com> Date: Mon, 09 Jul 2012 07:05:04 -0700 Cc: netmod@ietf.org Subject: [netmod] I-D Action: draft-ietf-netmod-iana-timezones-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2012 14:05:05 -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 : IANA Timezone Database YANG Module Author(s) : Jeffrey Lange Filename : draft-ietf-netmod-iana-timezones-00.txt Pages : 40 Date : 2012-07-09 Abstract: This document defines the initial version of the iana-timezones YANG module. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-iana-timezones There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-netmod-iana-timezones-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From jeffrey.K.lange@ge.com Mon Jul 9 10:21:10 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76CAE11E8173 for ; Mon, 9 Jul 2012 10:21:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.352 X-Spam-Level: X-Spam-Status: No, score=-6.352 tagged_above=-999 required=5 tests=[AWL=0.246, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ppZ9TR1aIjgz for ; Mon, 9 Jul 2012 10:21:09 -0700 (PDT) Received: from exprod5og104.obsmtp.com (exprod5og104.obsmtp.com [64.18.0.178]) by ietfa.amsl.com (Postfix) with ESMTP id 5268911E816F for ; Mon, 9 Jul 2012 10:21:08 -0700 (PDT) Received: from alpmlip14.e2k.ad.ge.com ([165.156.5.1]) (using TLSv1) by exprod5ob104.postini.com ([64.18.4.12]) with SMTP ID DSNKT/sTHcRCiqiKkTXw5/gMOxGGu1IxNkqr@postini.com; Mon, 09 Jul 2012 10:21:33 PDT Received: from unknown (HELO cinmlef07.e2k.ad.ge.com) ([3.159.213.38]) by alpmlip14.e2k.ad.ge.com with ESMTP; 09 Jul 2012 13:21:31 -0400 Received: from alpmlef03.e2k.ad.ge.com ([3.159.18.12]) by cinmlef07.e2k.ad.ge.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 9 Jul 2012 13:21:31 -0400 Received: from cinmlch01.e2k.ad.ge.com ([3.159.212.50]) by alpmlef03.e2k.ad.ge.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 9 Jul 2012 13:21:31 -0400 Received: from CINMBCNA06.e2k.ad.ge.com (3.159.212.61) by cinmlch01.e2k.ad.ge.com (3.159.212.50) with Microsoft SMTP Server (TLS) id 14.2.283.3; Mon, 9 Jul 2012 13:21:30 -0400 Received: from CINMBCNA02.e2k.ad.ge.com ([169.254.2.71]) by CINMBCNA06.e2k.ad.ge.com ([169.254.6.116]) with mapi id 14.02.0283.003; Mon, 9 Jul 2012 13:21:30 -0400 From: "Lange, Jeffrey K (GE Energy)" To: "netmod@ietf.org" Thread-Topic: ietf-routing-cfg Thread-Index: Ac1d9XdonbgOpcHxRjKkqlZcHcsIwg== Date: Mon, 9 Jul 2012 17:21:30 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [3.159.212.187] Content-Type: multipart/alternative; boundary="_000_B0FB1FAC2C7B234D87DCEBF309F703C51BAA75B4CINMBCNA02e2kad_" MIME-Version: 1.0 X-OriginalArrivalTime: 09 Jul 2012 17:21:31.0345 (UTC) FILETIME=[48368410:01CD5DF7] Subject: [netmod] ietf-routing-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: Mon, 09 Jul 2012 17:21:10 -0000 --_000_B0FB1FAC2C7B234D87DCEBF309F703C51BAA75B4CINMBCNA02e2kad_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I know there has been a lot of back-and-forth in the past over whether or n= ot to have a more simplistic routing configuration YANG model, but as I'm l= ooking at the ietf-routing-cfg model, I think it would be useful to have th= e whole concept of transferring routes between tables hidden behind an if-f= eature. Looking at how I would implement this for our products, which do not suppor= t any dynamic routing protocols, but do have many different interfaces that= might need routing capabilities, I would leave out: - route-filters - recipient-routing-tables - connected-routing-tables I think the model as it stands is perfectly usable without those additional= items for the simple static and direct route use cases. Without having this disabled via a feature, I would simply reject any attem= pts to set those items, but this clearly isn't the best solution. -Jeff Lange --_000_B0FB1FAC2C7B234D87DCEBF309F703C51BAA75B4CINMBCNA02e2kad_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I know there has been a lot of back-and-forth in the= past over whether or not to have a more simplistic routing configuration Y= ANG model, but as I’m looking at the ietf-routing-cfg model, I think = it would be useful to have the whole concept of transferring routes between tables hidden behind an if-feature.

 

Looking at how I would implement this for our produc= ts, which do not support any dynamic routing protocols, but do have many di= fferent interfaces that might need routing capabilities, I would leave out:=

        &nbs= p;       - route-filters

        &nbs= p;       - recipient-routing-tables

        &nbs= p;       - connected-routing-tables

I think the model as it stands is perfectly usable w= ithout those additional items for the simple static and direct route use ca= ses.

 

Without having this disabled via a feature, I would = simply reject any attempts to set those items, but this clearly isn’t= the best solution.

 

-Jeff Lange

 

 

--_000_B0FB1FAC2C7B234D87DCEBF309F703C51BAA75B4CINMBCNA02e2kad_-- From wwwrun@rfc-editor.org Mon Jul 9 17:07:02 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E5F711E80EE; Mon, 9 Jul 2012 17:07:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.902 X-Spam-Level: X-Spam-Status: No, score=-101.902 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, 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 d1ft8wTGTI4T; Mon, 9 Jul 2012 17:07:02 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 3A16E11E80DC; Mon, 9 Jul 2012 17:07:02 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 8EFA5621A1; Mon, 9 Jul 2012 17:07:24 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20120710000724.8EFA5621A1@rfc-editor.org> Date: Mon, 9 Jul 2012 17:07:24 -0700 (PDT) Cc: netmod@ietf.org, rfc-editor@rfc-editor.org Subject: [netmod] RFC 6643 on Translation of Structure of Management Information Version 2 (SMIv2) MIB Modules to YANG Modules 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, 10 Jul 2012 00:07:02 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6643 Title: Translation of Structure of Management Information Version 2 (SMIv2) MIB Modules to YANG Modules Author: J. Schoenwaelder Status: Standards Track Stream: IETF Date: July 2012 Mailbox: j.schoenwaelder@jacobs-university.de Pages: 36 Characters: 69140 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-netmod-smi-yang-05.txt URL: http://www.rfc-editor.org/rfc/rfc6643.txt YANG is a data modeling language used to model configuration and state data manipulated by the Network Configuration Protocol (NETCONF), NETCONF remote procedure calls, and NETCONF notifications. The Structure of Management Information (SMIv2) defines fundamental data types, an object model, and the rules for writing and revising MIB modules for use with the Simple Network Management Protocol (SNMP). This document defines a translation of SMIv2 MIB modules into YANG modules, enabling read-only (config false) access to data objects defined in SMIv2 MIB modules via NETCONF. [STANDARDS-TRACK] This document is a product of the NETCONF Data Modeling Language Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From lhotka@nic.cz Tue Jul 10 02:58:04 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC81B21F8606 for ; Tue, 10 Jul 2012 02:58:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.963 X-Spam-Level: X-Spam-Status: No, score=-1.963 tagged_above=-999 required=5 tests=[AWL=0.036, 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 PUA3h7VthTRr for ; Tue, 10 Jul 2012 02:58:04 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id C8B5321F854A for ; Tue, 10 Jul 2012 02:58:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 9679354058D for ; Tue, 10 Jul 2012 11:58:29 +0200 (CEST) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xwaFnrayGsp3 for ; Tue, 10 Jul 2012 11:58:24 +0200 (CEST) Received: from localhost (birdie-w.lhotkovi.cz [172.29.2.202]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 1A76F5401A4 for ; Tue, 10 Jul 2012 11:58:23 +0200 (CEST) From: Ladislav Lhotka To: netmod@ietf.org In-Reply-To: References: User-Agent: Notmuch/0.12+113~gde05574 (http://notmuchmail.org) Emacs/23.3.50.1 (i386-apple-darwin9.8.0) Mail-Followup-To: netmod@ietf.org Date: Tue, 10 Jul 2012 11:58:23 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [netmod] ietf-routing-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: Tue, 10 Jul 2012 09:58:04 -0000 "Lange, Jeffrey K (GE Energy)" writes: > I know there has been a lot of back-and-forth in the past over whether or not to have a more simplistic routing configuration YANG model, but as I'm looking at the ietf-routing-cfg model, I think it would be useful to have the whole concept of transferring routes between tables hidden behind an if-feature. > > Looking at how I would implement this for our products, which do not support any dynamic routing protocols, but do have many different interfaces that might need routing capabilities, I would leave out: > - route-filters > - recipient-routing-tables > - connected-routing-tables > I think the model as it stands is perfectly usable without those additional items for the simple static and direct route use cases. > > Without having this disabled via a feature, I would simply reject any attempts to set those items, but this clearly isn't the best solution. The draft allows implementations to restrict the number of routing tables to just one per address family, and with one table and static routing there isn't really much to do, because the only valid recipient/connected routing table can be the same main routing table, so configuring them has no effect. As for filters, the only sensible thing that can be done is to block all configured static routes from appearing in the main routing table, which might occassionaly be useful (and easy to implement). An implementation that is not willing to implement even this trivial filtering may declare a deviation. Lada > > -Jeff Lange > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From jeffrey.K.lange@ge.com Tue Jul 10 06:44:23 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2E4921F8701 for ; Tue, 10 Jul 2012 06:44:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.367 X-Spam-Level: X-Spam-Status: No, score=-6.367 tagged_above=-999 required=5 tests=[AWL=0.232, 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 wQgbvUN0kY7J for ; Tue, 10 Jul 2012 06:44:23 -0700 (PDT) Received: from exprod5og105.obsmtp.com (exprod5og105.obsmtp.com [64.18.0.180]) by ietfa.amsl.com (Postfix) with ESMTP id E600E21F86F5 for ; Tue, 10 Jul 2012 06:44:18 -0700 (PDT) Received: from alpmlip12.e2k.ad.ge.com ([12.43.191.1]) (using TLSv1) by exprod5ob105.postini.com ([64.18.4.12]) with SMTP ID DSNKT/wxzUyEOhfJzGEdQkUIFzA1589OfkGO@postini.com; Tue, 10 Jul 2012 06:44:47 PDT Received: from unknown (HELO cinmlef07.e2k.ad.ge.com) ([3.159.213.38]) by alpmlip12.e2k.ad.ge.com with ESMTP; 10 Jul 2012 09:44:44 -0400 Received: from cinmlch01.e2k.ad.ge.com ([3.159.212.50]) by cinmlef07.e2k.ad.ge.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 10 Jul 2012 09:44:44 -0400 Received: from CINMBCNA03.e2k.ad.ge.com (3.159.212.57) by cinmlch01.e2k.ad.ge.com (3.159.212.50) with Microsoft SMTP Server (TLS) id 14.2.283.3; Tue, 10 Jul 2012 09:44:43 -0400 Received: from CINMBCNA02.e2k.ad.ge.com ([169.254.2.71]) by CINMBCNA03.e2k.ad.ge.com ([169.254.3.14]) with mapi id 14.02.0283.003; Tue, 10 Jul 2012 09:44:43 -0400 From: "Lange, Jeffrey K (GE Energy)" To: Ladislav Lhotka , "netmod@ietf.org" Thread-Topic: [netmod] ietf-routing-cfg Thread-Index: Ac1d9XdonbgOpcHxRjKkqlZcHcsIwgArppmAAADWyGA= Date: Tue, 10 Jul 2012 13:44:42 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [3.159.212.187] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 10 Jul 2012 13:44:44.0160 (UTC) FILETIME=[29BD5800:01CD5EA2] Subject: Re: [netmod] ietf-routing-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: Tue, 10 Jul 2012 13:44:24 -0000 > The draft allows implementations to restrict the number of routing tables= to just one per address family, and with one table and static routing ther= e isn't really much to do, because > the only valid recipient/connected rou= ting table can be the same main routing table, so configuring them has no e= ffect.=20 >=20 > As for filters, the only sensible thing that can be done is to block all = configured static routes from appearing in the main routing table, which mi= ght occassionaly be useful (and easy to implement). >=20 > An implementation that is not willing to implement even this trivial filt= ering may declare a deviation. >=20 > Lada I'm trying to understand how the connected-routing-tables would work in a s= imple real-world case. The description of connected-routing-tables in the = YANG model states: If no connected routing table is defined for an address family, the routing protocol should be connected by default to the main routing table for that address family. But connected-routing-tables is a child-node of routing-protocol, which is = not related at all to an address-family. Only the routing-table container = defines an address-family (uses afn-safi). Is this description wrong? Or am I just missing something? -Jeff From lhotka@nic.cz Tue Jul 10 07:05:28 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD55921F877C for ; Tue, 10 Jul 2012 07:05:28 -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 qbl2jndhkc+h for ; Tue, 10 Jul 2012 07:05:28 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 14AF421F85FF for ; Tue, 10 Jul 2012 07:05:28 -0700 (PDT) Received: from [172.20.26.113] (fw.nic.cz [217.31.207.1]) by mail.nic.cz (Postfix) with ESMTPSA id 16F6C14118B; Tue, 10 Jul 2012 16:05:55 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1341929155; bh=mltT0zqTnfIvvH/ZkFGzQdFK4kZRtBU1V3cSC3YsqUQ=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=Z9/VZ3CHIG/oZZxJbhgfuXJ6GcVkMU/LB1uzJHP+MybMktM4RPynReXi+P/5H5/MS v5SWWkNwEmVJniZ1IfG5zBvmucre7QdvYxPuglOvMb6wTyi9YyyqAZQHalgrNsHLsJ D/8hONxjBgZ1P/Yfv2to9xfG0bzWAPWxE5AFGlIs= Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Ladislav Lhotka In-Reply-To: Date: Tue, 10 Jul 2012 16:05:55 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <703CC6BA-0B6C-4E46-80A9-E7C4DDE050D8@nic.cz> References: To: "Lange, Jeffrey K (GE Energy)" X-Mailer: Apple Mail (2.1278) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: "netmod@ietf.org" Subject: Re: [netmod] ietf-routing-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: Tue, 10 Jul 2012 14:05:29 -0000 On Jul 10, 2012, at 3:44 PM, Lange, Jeffrey K (GE Energy) wrote: >> The draft allows implementations to restrict the number of routing = tables to just one per address family, and with one table and static = routing there isn't really much to do, because > the only valid = recipient/connected routing table can be the same main routing table, so = configuring them has no effect.=20 >>=20 >> As for filters, the only sensible thing that can be done is to block = all configured static routes from appearing in the main routing table, = which might occassionaly be useful (and easy to implement). >>=20 >> An implementation that is not willing to implement even this trivial = filtering may declare a deviation. >>=20 >> Lada >=20 > I'm trying to understand how the connected-routing-tables would work = in a simple real-world case. The description of = connected-routing-tables in the YANG model states: >=20 > If no connected routing table is defined for an > address family, the routing protocol should be > connected by default to the main routing table for > that address family. >=20 > But connected-routing-tables is a child-node of routing-protocol, = which is not related at all to an address-family. Only the = routing-table container defines an address-family (uses afn-safi). This is because one protocol instance can be used for several address = families. The idea is that for every such address family either (i) a = routing table is explicitly configured as the connected routing table, = or (ii) the main routing table for that address family is used. The = formidable 'must' expression under = "connected-routing-tables/routing-table" ensures that no more than one = connected routing table is configured for each address family. In other words, the list "connected-routing-tables/routing-table" may = contain an entry for each address family supported by the routing = protocol instance, and for missing entries the main routing table is = used by default. >=20 > Is this description wrong? Or am I just missing something? I think it is correct but maybe not clear enough. Can you suggest a = better formulation? Thanks, Lada >=20 > -Jeff -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From jonathan@hansfords.net Wed Jul 11 02:14:43 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E22A721F86A7 for ; Wed, 11 Jul 2012 02:14:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[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 3BUc1xl1HE-S for ; Wed, 11 Jul 2012 02:14:42 -0700 (PDT) Received: from avasout02.plus.net (avasout02.plus.net [212.159.14.17]) by ietfa.amsl.com (Postfix) with ESMTP id CB33121F8552 for ; Wed, 11 Jul 2012 02:14:40 -0700 (PDT) Received: from webmail.plus.net ([212.159.8.87]) by avasout02 with smtp id YxF81j0081sg6PG01xF9eA; Wed, 11 Jul 2012 10:15:09 +0100 X-CM-Score: 0.00 X-CNFS-Analysis: v=2.0 cv=A+nuztqG c=1 sm=1 a=w/v6d3Yw9YqO0eqsxHCYQw==:17 a=HaVFzea3niEA:10 a=fIUNk3G47tUA:10 a=0B8HqoTn75oA:10 a=6bkCdLdQAAAA:8 a=0Bzu9jTXAAAA:8 a=gqNrbdtdUPJW-UwNGiAA:9 a=QEXdDO2ut3YA:10 a=v_UebO9QNw78yfH_fGIA:9 a=_W_S_7VecoQA:10 a=w/v6d3Yw9YqO0eqsxHCYQw==:117 X-AUTH: hansfords+us:2500 Received: from host81-136-210-16.in-addr.btopenworld.com ([81.136.210.16]) by webmail.plus.net with HTTP (HTTP/1.1 POST); Wed, 11 Jul 2012 10:15:08 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_0dfa9d4ac67406da63c7248bf27d7154" Date: Wed, 11 Jul 2012 10:15:08 +0100 From: Jonathan Hansford To: Message-ID: <7ad77079d736bb536206251696d70e6e@imap.plus.net> X-Sender: Jonathan@hansfords.net User-Agent: Roundcube Webmail/0.7.2 X-Originating-IP: [81.136.210.16] Subject: [netmod] WBEM/CIM v. NETCONF/YANG 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, 11 Jul 2012 09:14:43 -0000 --=_0dfa9d4ac67406da63c7248bf27d7154 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=UTF-8 This will probably be so obvious to most of you, I almost feel like not sending this, but I just want to confirm something rather fundamental that only struck me yesterday. CIM, as described on the DMTF web site, "provides a common definition of management information for systems, networks, applications and services, and allows for vendor extensions". The CIM Concepts White Paper identifies CIM's goal as "to model all the various aspects of the managed environment, not just a single problem space". In other words CIM provides an information model of the whole system, it is system-centric. In contrast, YANG data models are intended to be device-centric. Consequently there is typically no YANG system model and relationships between entities only need to make sense within the scope of the device being configured. Have I got that right? The reason I ask is that, if that is the case, I am over-complicating my YANG modules in an attempt to capture system relationships that are never visible at the device level. Jonathan --=_0dfa9d4ac67406da63c7248bf27d7154 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8

This will probably be so obvious to most of you, I almost feel like not = sending this, but I just want to confirm something rather fundamental that = only struck me yesterday.

CIM, as described on the DMTF web site, "provides a common definit= ion of management information for systems, networks, applications and servi= ces, and allows for vendor extensions". The CIM Concepts White Paper= identifies CIM's goal as "to model all the various aspects of the managed = environment, not just a single problem space". In other words CIM= provides an information model of the whole system, it is system-centric. I= n contrast, YANG data models are intended to be device-centric. Consequentl= y there is typically no YANG system model and relationships between entitie= s only need to make sense within the scope of the device being configured= =2E Have I got that right?

The reason I ask is that, if that is the case, I am over-complicating my= YANG modules in an attempt to capture system relationships that are never = visible at the device level.

Jonathan

 
 
--=_0dfa9d4ac67406da63c7248bf27d7154-- From j.schoenwaelder@jacobs-university.de Wed Jul 11 02:34:00 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0D7321F864C for ; Wed, 11 Jul 2012 02:34:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.2 X-Spam-Level: X-Spam-Status: No, score=-103.2 tagged_above=-999 required=5 tests=[AWL=0.049, 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 VyQLWhQM-Vvf for ; Wed, 11 Jul 2012 02:33: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 A72B921F8554 for ; Wed, 11 Jul 2012 02:33:59 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 01EDB20A01; Wed, 11 Jul 2012 11:34: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 PkYF5bGK99Ao; Wed, 11 Jul 2012 11:34: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 9C6AF209D7; Wed, 11 Jul 2012 11:34:26 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id EFB3B2051D19; Wed, 11 Jul 2012 11:34:25 +0200 (CEST) Date: Wed, 11 Jul 2012 11:34:25 +0200 From: Juergen Schoenwaelder To: Jonathan Hansford Message-ID: <20120711093425.GB18153@elstar.local> Mail-Followup-To: Jonathan Hansford , netmod@ietf.org References: <7ad77079d736bb536206251696d70e6e@imap.plus.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7ad77079d736bb536206251696d70e6e@imap.plus.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] WBEM/CIM v. NETCONF/YANG 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, 11 Jul 2012 09:34:00 -0000 On Wed, Jul 11, 2012 at 10:15:08AM +0100, Jonathan Hansford wrote: > > This will probably be so obvious to most of you, I almost feel like > not sending this, but I just want to confirm something rather > fundamental that only struck me yesterday. > > CIM, as described on the > DMTF web site, "provides a common definition of management information > for systems, networks, applications and services, and allows for vendor > extensions". The CIM Concepts White Paper identifies CIM's goal as "to > model all the various aspects of the managed environment, not just a > single problem space". In other words CIM provides an information model > of the whole system, it is system-centric. In contrast, YANG data models > are intended to be device-centric. Consequently there is typically no > YANG system model and relationships between entities only need to make > sense within the scope of the device being configured. Have I got that > right? The word "system" has way too many meanings. I am not even sure the CIM's usage of system has the meaning you seem to associate with it. In the telco world, people talk about element managers (managing elements = devices) and network managers (managing whole networks, that is a collection of elements = devices and links). While the IETF work is currently focussed on managing devices, it seems some people use NETCONF/YANG technology as well to manage whole networks, that is YANG/NETCONF is used as an interface to a network manager instead of a device interface. A few IETFs back, we even had a bar bof discussion about this. > The reason I ask is that, if that is the case, I am > over-complicating my YANG modules in an attempt to capture system > relationships that are never visible at the device level. Not sure what you are doing but it might be a good idea to separate network-wide data models from device specific data models. For managing a network, you need to have information about topologies (likely even at different layers) and only then you can do something useful. Sure, it would be nice if there were a common (IETF) data model for this (or at least IP layer topologies) but I assume, if this happens at all, it will take time. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From janl@tail-f.com Wed Jul 11 02:40:16 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AE7721F864F for ; Wed, 11 Jul 2012 02:40:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.045 X-Spam-Level: X-Spam-Status: No, score=-2.045 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 0GV7df4OTNkH for ; Wed, 11 Jul 2012 02:40:15 -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 74C6821F84FD for ; Wed, 11 Jul 2012 02:40:15 -0700 (PDT) Received: from [192.168.1.137] (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 223601200D63; Wed, 11 Jul 2012 11:40:44 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/alternative; boundary="Apple-Mail=_4ABD7C8E-1007-4087-BC31-5BB2FF76C442" From: Jan Lindblad In-Reply-To: <7ad77079d736bb536206251696d70e6e@imap.plus.net> Date: Wed, 11 Jul 2012 11:40:43 +0200 Message-Id: References: <7ad77079d736bb536206251696d70e6e@imap.plus.net> To: Jonathan Hansford X-Mailer: Apple Mail (2.1278) Cc: netmod@ietf.org Subject: Re: [netmod] WBEM/CIM v. NETCONF/YANG 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, 11 Jul 2012 09:40:16 -0000 --Apple-Mail=_4ABD7C8E-1007-4087-BC31-5BB2FF76C442 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Jonathan, > This will probably be so obvious to most of you, I almost feel like = not sending this, but I just want to confirm something rather = fundamental that only struck me yesterday. >=20 > CIM, as described on the DMTF web site, "provides a common definition = of management information for systems, networks, applications and = services, and allows for vendor extensions". The CIM Concepts White = Paper identifies CIM's goal as "to model all the various aspects of the = managed environment, not just a single problem space". In other words = CIM provides an information model of the whole system, it is = system-centric. In contrast, YANG data models are intended to be = device-centric. Consequently there is typically no YANG system model and = relationships between entities only need to make sense within the scope = of the device being configured. Have I got that right? >=20 > The reason I ask is that, if that is the case, I am over-complicating = my YANG modules in an attempt to capture system relationships that are = never visible at the device level. >=20 If you look at the actual CIM classes, I think you'll find that the DMTF = definition of a "system" above is pretty much one machine, e.g. one = "server" or desktop machine. Not a cluster or network of machines. For good and bad, there is a fundamental difference in how the CIM set = of classes/data models are treated by DMTF and how YAMs and MIBs are = treated by IETF. The CIM model is based on UML, and therefore uses = concepts like inheritance heavily. This gives a high cohesion among all = the various classes. Therefore DMTF releases the CIM model as one unit, = with a version number for the entire model with all 1,100+ classes. This = ensures good alignment between models, but is very different from how = IETF version handles RFCs separately. Vendor extensions and version = handling in the field becomes very tricky business. /Jan Lindblad -- Jan Lindblad, janl@tail-f.com, +46 702855728 Principal Solutions Architect, Tail-f Systems, www.tail-f.com --Apple-Mail=_4ABD7C8E-1007-4087-BC31-5BB2FF76C442 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

This will = probably be so obvious to most of you, I almost feel like not sending = this, but I just want to confirm something rather fundamental that only = struck me yesterday.

CIM, as described on the DMTF web site, = "provides a common definition of management information for = systems, networks, applications and services, and allows for vendor = extensions". The CIM Concepts White Paper identifies CIM's goal = as "to model all the various aspects of the managed = environment, not just a single problem space". In other words = CIM provides an information model of the whole system, it is = system-centric. In contrast, YANG data models are intended to be = device-centric. Consequently there is typically no YANG system model and = relationships between entities only need to make sense within the scope = of the device being configured. Have I got that right?

The reason = I ask is that, if that is the case, I am over-complicating my YANG = modules in an attempt to capture system relationships that are never = visible at the device level.

If you look at = the actual CIM classes, I think you'll find that the DMTF definition of = a "system" above is pretty much one machine, e.g. one "server" or = desktop machine. Not a cluster or network of = machines.

For good and bad, there is a = fundamental difference in how the CIM set of classes/data models are = treated by DMTF and how YAMs and MIBs are treated by IETF. The CIM model = is based on UML, and therefore uses concepts like inheritance heavily. = This gives a high cohesion among all the various classes. Therefore DMTF = releases the CIM model as one unit, with a version number for the entire = model with all 1,100+ classes. This ensures good alignment between = models, but is very different from how IETF version handles RFCs = separately. Vendor extensions and version handling in the field becomes = very tricky business.

/Jan Lindblad
--
Jan Lindblad, janl@tail-f.com, +46 = 702855728
www.tail-f.com

= --Apple-Mail=_4ABD7C8E-1007-4087-BC31-5BB2FF76C442-- From jonathan@hansfords.net Wed Jul 11 02:44:19 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 843A321F8627 for ; Wed, 11 Jul 2012 02:44:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[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 gegD1snIyZSz for ; Wed, 11 Jul 2012 02:44:18 -0700 (PDT) Received: from avasout02.plus.net (avasout02.plus.net [212.159.14.17]) by ietfa.amsl.com (Postfix) with ESMTP id CF8D221F8672 for ; Wed, 11 Jul 2012 02:44:17 -0700 (PDT) Received: from webmail.plus.net ([212.159.8.87]) by avasout02 with smtp id Yxke1j0031sg6PG01xkfFl; Wed, 11 Jul 2012 10:44:39 +0100 X-CM-Score: 0.00 X-CNFS-Analysis: v=2.0 cv=A+nuztqG c=1 sm=1 a=w/v6d3Yw9YqO0eqsxHCYQw==:17 a=HaVFzea3niEA:10 a=fIUNk3G47tUA:10 a=3OO1fqKhKbMA:10 a=0B8HqoTn75oA:10 a=6bkCdLdQAAAA:8 a=0Bzu9jTXAAAA:8 a=wCsqtYi0KpZPJ8zVm2cA:9 a=QEXdDO2ut3YA:10 a=PatkZkjuc7kdJ1xw:21 a=kqhyPoP6-foa36ho:21 a=FfRibk0Qgu8E8yqHaR4A:9 a=_W_S_7VecoQA:10 a=w/v6d3Yw9YqO0eqsxHCYQw==:117 X-AUTH: hansfords+us:2500 Received: from host81-136-210-16.in-addr.btopenworld.com ([81.136.210.16]) by webmail.plus.net with HTTP (HTTP/1.1 POST); Wed, 11 Jul 2012 10:44:38 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_b15835bb6ffa6e03243be2111d0ab791" Date: Wed, 11 Jul 2012 10:44:38 +0100 From: Jonathan Hansford To: Jonathan Hansford , In-Reply-To: <20120711093425.GB18153@elstar.local> References: <7ad77079d736bb536206251696d70e6e@imap.plus.net> <20120711093425.GB18153@elstar.local> Message-ID: X-Sender: Jonathan@hansfords.net User-Agent: Roundcube Webmail/0.7.2 X-Originating-IP: [81.136.210.16] Subject: Re: [netmod] WBEM/CIM v. NETCONF/YANG 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, 11 Jul 2012 09:44:19 -0000 --=_b15835bb6ffa6e03243be2111d0ab791 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=UTF-8 On 11.07.2012 10:34, Juergen Schoenwaelder wrote: > On Wed, Jul 11, 2012 at 10:15:08AM +0100, Jonathan Hansford wrote: > >> This will probably be so obvious to most of you, I almost feel like not sending this, but I just want to confirm something rather fundamental that only struck me yesterday. CIM, as described on the DMTF web site, "provides a common definition of management information for systems, networks, applications and services, and allows for vendor extensions". The CIM Concepts White Paper identifies CIM's goal as "to model all the various aspects of the managed environment, not just a single problem space". In other words CIM provides an information model of the whole system, it is system-centric. In contrast, YANG data models are intended to be device-centric. Consequently there is typically no YANG system model and relationships between entities only need to make sense within the scope of the device being configured. Have I got that right? > > The word "system" has way too many meanings. I am not even sure the > CIM's usage of system has the meaning you seem to associate with it. > > In the telco world, people talk about element managers (managing > elements = devices) and network managers (managing whole networks, > that is a collection of elements = devices and links). While the IETF > work is currently focussed on managing devices, it seems some people > use NETCONF/YANG technology as well to manage whole networks, that is > YANG/NETCONF is used as an interface to a network manager instead of a > device interface. A few IETFs back, we even had a bar bof discussion > about this. I'm not sure I understand the client/server model in such a situation. Does that mean a NETCONF server is on the network manager as well as having servers on the devices? Or is there a hierarchy of clients and servers such that the devices are servers to the element manager clients and the element managers are servers to the network manager client? /jh >> The reason I ask is that, if that is the case, I am over-complicating my YANG modules in an attempt to capture system relationships that are never visible at the device level. > > Not sure what you are doing but it might be a good idea to separate > network-wide data models from device specific data models. For > managing a network, you need to have information about topologies > (likely even at different layers) and only then you can do something > useful. Sure, it would be nice if there were a common (IETF) data > model for this (or at least IP layer topologies) but I assume, if this > happens at all, it will take time. > > /js --=_b15835bb6ffa6e03243be2111d0ab791 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8

 

On 11.07.2012 10:34, Juergen Schoenwaelder wrote:

On Wed, Jul 11, 2012 at 10:15:08AM +0100, Jonathan Hansford wrote:

This will probably be so obvious to m=
ost of you, I almost feel like not sending this, but I just want to confirm=
 something rather fundamental that only struck me yesterday. CIM, as descri=
bed on the DMTF web site, "provides a common definition of management infor=
mation for systems, networks, applications and services, and allows for ven=
dor extensions". The CIM Concepts White Paper identifies CIM's goal as "to =
model all the various aspects of the managed environment, not just a single=
 problem space". In other words CIM provides an information model of the wh=
ole system, it is system-centric. In contrast, YANG data models are intende=
d to be device-centric. Consequently there is typically no YANG system mode=
l and relationships between entities only need to make sense within the sco=
pe of the device being configured. Have I got that right?


The word "system" has way too many meanings. I am not even sure the
CIM's usage of system has the meaning you seem to associate with it.

In the telco world, people talk about element managers (managing
elements =3D devices) and network managers (managing whole networks,
that is a collection of elements =3D devices and links). While the IETF
work is currently focussed on managing devices, it seems some people
use NETCONF/YANG technology as well to manage whole networks, that is
YANG/NETCONF is used as an interface to a network manager instead of a
device interface. A few IETFs back, we even had a bar bof discussion
about this.


I'm not sure I understand the client/server model in such a situation=
=2E Does that mean a NETCONF server is on the network manager as well as ha=
ving servers on the devices? Or is there a hierarchy of clients and servers=
 such that the devices are servers to the element manager clients and the e=
lement managers are servers to the network manager client?
 
/jh
The reason I ask is that, if that is = the case, I am over-complicating my YANG modules in an attempt to capture s= ystem relationships that are never visible at the device level. 
Not sure what you are doing but it might be a good idea to separate
network-wide data models from device specific data models. For
managing a network, you need to have information about topologies
(likely even at different layers) and only then you can do something
useful. Sure, it would be nice if there were a common (IETF) data
model for this (or at least IP layer topologies) but I assume, if this
happens at all, it will take time.

/js
 
--=_b15835bb6ffa6e03243be2111d0ab791-- From j.schoenwaelder@jacobs-university.de Wed Jul 11 03:00:10 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 877F721F8673 for ; Wed, 11 Jul 2012 03:00:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.201 X-Spam-Level: X-Spam-Status: No, score=-103.201 tagged_above=-999 required=5 tests=[AWL=0.048, 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 3Df7nQ-yJHBG for ; Wed, 11 Jul 2012 03:00: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 AA6C921F8663 for ; Wed, 11 Jul 2012 03:00:09 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4E5C620A13; Wed, 11 Jul 2012 12:00:39 +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 dsAWzNv9q2VU; Wed, 11 Jul 2012 12:00:39 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id E4EDD20A1F; Wed, 11 Jul 2012 12:00:38 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 8CAEB205216B; Wed, 11 Jul 2012 12:00:37 +0200 (CEST) Date: Wed, 11 Jul 2012 12:00:36 +0200 From: Juergen Schoenwaelder To: Jonathan Hansford Message-ID: <20120711100036.GD18153@elstar.local> Mail-Followup-To: Jonathan Hansford , netmod@ietf.org References: <7ad77079d736bb536206251696d70e6e@imap.plus.net> <20120711093425.GB18153@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] WBEM/CIM v. NETCONF/YANG 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, 11 Jul 2012 10:00:10 -0000 On Wed, Jul 11, 2012 at 10:44:38AM +0100, Jonathan Hansford wrote: > > In the > telco world, people talk about element managers (managing > > elements = > devices) and network managers (managing whole networks, > > that is a > collection of elements = devices and links). While the IETF > > work is > currently focussed on managing devices, it seems some people > > use > NETCONF/YANG technology as well to manage whole networks, that is > > > YANG/NETCONF is used as an interface to a network manager instead of a > > > device interface. A few IETFs back, we even had a bar bof discussion > > > about this. > > I'm not sure I understand the client/server model in such a > situation. Does that mean a NETCONF server is on the network manager as > well as having servers on the devices? Or is there a hierarchy of > clients and servers such that the devices are servers to the element > manager clients and the element managers are servers to the network > manager client? As far as I understood things, there is a NETCONF server interface to the piece of software acting as a network manager. And devices might have their device specific NETCONF server. Whether there are element managers in-between or not, I have no clue. As said before, in order to manage the network, you need lots of topology information etc. The devices usually don't need this or only a rather small part of it. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From mehmet.ersue@nsn.com Wed Jul 11 03:27:44 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E38921F84E1 for ; Wed, 11 Jul 2012 03:27:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.564 X-Spam-Level: X-Spam-Status: No, score=-106.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v1nwd6ph23dw for ; Wed, 11 Jul 2012 03:27:44 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id C0E5B21F857D for ; Wed, 11 Jul 2012 03:27:43 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q6BASBGo022913 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 11 Jul 2012 12:28:11 +0200 Received: from DEMUEXC048.nsn-intra.net ([10.159.32.94]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q6BASBdq024037; Wed, 11 Jul 2012 12:28:11 +0200 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by DEMUEXC048.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 11 Jul 2012 12:28:11 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 11 Jul 2012 12:28:09 +0200 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A640401AA06@DEMUEXC006.nsn-intra.net> In-Reply-To: <20120711093425.GB18153@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] WBEM/CIM v. NETCONF/YANG Thread-Index: Ac1fSGVXJMnEr1F9SDuYGKH/O2lQPgABd6wg References: <7ad77079d736bb536206251696d70e6e@imap.plus.net> <20120711093425.GB18153@elstar.local> From: "Ersue, Mehmet (NSN - DE/Munich)" To: "Juergen Schoenwaelder" , "Jonathan Hansford" X-OriginalArrivalTime: 11 Jul 2012 10:28:11.0099 (UTC) FILETIME=[DEF0CAB0:01CD5F4F] X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 1949 X-purgate-ID: 151667::1342002491-00003CDD-A506BBF3/0-0/0-0 Cc: netmod@ietf.org Subject: Re: [netmod] WBEM/CIM v. NETCONF/YANG 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, 11 Jul 2012 10:27:44 -0000 > > CIM, as described on the > > DMTF web site, "provides a common definition of management information > > for systems, networks, applications and services, and allows for vendor > > extensions". The CIM Concepts White Paper identifies CIM's goal as "to > > model all the various aspects of the managed environment, not just a > > single problem space". In other words CIM provides an information model > > of the whole system, it is system-centric. In contrast, YANG data models > > are intended to be device-centric. Consequently there is typically no > > YANG system model and relationships between entities only need to make > > sense within the scope of the device being configured. Have I got that > > right? >=20 > The word "system" has way too many meanings. I am not even sure the > CIM's usage of system has the meaning you seem to associate with it. >=20 > In the telco world, people talk about element managers (managing > elements =3D devices) and network managers (managing whole networks, > that is a collection of elements =3D devices and links). While the = IETF > work is currently focussed on managing devices, it seems some people > use NETCONF/YANG technology as well to manage whole networks, that is > YANG/NETCONF is used as an interface to a network manager instead of a > device interface. A few IETFs back, we even had a bar bof discussion > about this. DMTF CIM can be seen as an information model for the IT world, where=20 TM Forum SID is an information model for the telecommunication world. Both are very comprehensive and too big for an implementation. IETF=20 traditionally did not provide high level information models, except a few=20 single cases focused on particular technologies, e.g. RFC5102 Information=20 Model for IPFIX.=20 Yang and MIB modules are rather data models. See RFC3444 "On the=20 Difference between Information Models and Data Models". Mehmet From j.schoenwaelder@jacobs-university.de Wed Jul 11 03:39:27 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D992A21F8562 for ; Wed, 11 Jul 2012 03:39:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.201 X-Spam-Level: X-Spam-Status: No, score=-103.201 tagged_above=-999 required=5 tests=[AWL=0.048, 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 4JpDpWwE+M0M for ; Wed, 11 Jul 2012 03:39:26 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 9B54A21F8631 for ; Wed, 11 Jul 2012 03:39:26 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 170F020A1F; Wed, 11 Jul 2012 12:39:53 +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 Z8F32jYsW4HZ; Wed, 11 Jul 2012 12:39:52 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A91F52095C; Wed, 11 Jul 2012 12:39:52 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 127C0205B260; Wed, 11 Jul 2012 12:39:50 +0200 (CEST) Date: Wed, 11 Jul 2012 12:39:50 +0200 From: Juergen Schoenwaelder To: "Ersue, Mehmet (NSN - DE/Munich)" Message-ID: <20120711103950.GA63567@elstar.local> Mail-Followup-To: "Ersue, Mehmet (NSN - DE/Munich)" , Jonathan Hansford , netmod@ietf.org References: <7ad77079d736bb536206251696d70e6e@imap.plus.net> <20120711093425.GB18153@elstar.local> <80A0822C5E9A4440A5117C2F4CD36A640401AA06@DEMUEXC006.nsn-intra.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <80A0822C5E9A4440A5117C2F4CD36A640401AA06@DEMUEXC006.nsn-intra.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] WBEM/CIM v. NETCONF/YANG 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, 11 Jul 2012 10:39:28 -0000 On Wed, Jul 11, 2012 at 12:28:09PM +0200, Ersue, Mehmet (NSN - DE/Munich) wrote: > IETF traditionally did not provide high level information models, > except a few single cases focused on particular technologies, > e.g. RFC5102 Information Model for IPFIX. I do not consider RFC5102 to provide an information model. The RFC title is IMHO an unfortunate misnomer. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From mehmet.ersue@nsn.com Wed Jul 11 04:07:48 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B83621F8685 for ; Wed, 11 Jul 2012 04:07:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.566 X-Spam-Level: X-Spam-Status: No, score=-106.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gfFZKql6dS+x for ; Wed, 11 Jul 2012 04:07:48 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id CB47721F8674 for ; Wed, 11 Jul 2012 04:07:47 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q6BB8EX8031234 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 11 Jul 2012 13:08:14 +0200 Received: from DEMUEXC047.nsn-intra.net ([10.159.32.93]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q6BB8BHl000881; Wed, 11 Jul 2012 13:08:11 +0200 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by DEMUEXC047.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 11 Jul 2012 13:08:11 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 11 Jul 2012 13:08:10 +0200 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A640401AA46@DEMUEXC006.nsn-intra.net> In-Reply-To: <20120711103950.GA63567@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] WBEM/CIM v. NETCONF/YANG Thread-Index: Ac1fUYIWNzIvs6wUTaihewVZ9vxTggAA6ZZA References: <7ad77079d736bb536206251696d70e6e@imap.plus.net> <20120711093425.GB18153@elstar.local> <80A0822C5E9A4440A5117C2F4CD36A640401AA06@DEMUEXC006.nsn-intra.net> <20120711103950.GA63567@elstar.local> From: "Ersue, Mehmet (NSN - DE/Munich)" To: "Juergen Schoenwaelder" X-OriginalArrivalTime: 11 Jul 2012 11:08:11.0206 (UTC) FILETIME=[75840E60:01CD5F55] X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 481 X-purgate-ID: 151667::1342004894-0000425E-34F2AE0E/0-0/0-0 Cc: netmod@ietf.org Subject: Re: [netmod] WBEM/CIM v. NETCONF/YANG 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, 11 Jul 2012 11:07:48 -0000 > > IETF traditionally did not provide high level information models, > > except a few single cases focused on particular technologies, > > e.g. RFC5102 Information Model for IPFIX. >=20 > I do not consider RFC5102 to provide an information model. The RFC > title is IMHO an unfortunate misnomer. Yeah, this is a bad example. Though, there are not many examples. May be http://tools.ietf.org/html/draft-ietf-ipfix-configuration-model-11 is a better one.=20 Mehmet From internet-drafts@ietf.org Wed Jul 11 18:20:55 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0E7C11E80C9; Wed, 11 Jul 2012 18:20:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.517 X-Spam-Level: X-Spam-Status: No, score=-102.517 tagged_above=-999 required=5 tests=[AWL=0.082, 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 ZOhKWpzpnVbe; Wed, 11 Jul 2012 18:20:54 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A19E11E80E5; Wed, 11 Jul 2012 18:20:54 -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.30p3 Message-ID: <20120712012054.20923.90098.idtracker@ietfa.amsl.com> Date: Wed, 11 Jul 2012 18:20:54 -0700 Cc: netmod@ietf.org Subject: [netmod] I-D Action: draft-ietf-netmod-system-mgmt-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: Thu, 12 Jul 2012 01:20:55 -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 : YANG Data Model for System Management Author(s) : Andy Bierman Martin Bjorklund Filename : draft-ietf-netmod-system-mgmt-02.txt Pages : 31 Date : 2012-07-11 Abstract: This document defines a YANG data model for the configuration and identification of the management system of a device. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-system-mgmt There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-netmod-system-mgmt-02 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-netmod-system-mgmt-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Fri Jul 13 15:45:30 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9631611E812C; Fri, 13 Jul 2012 15:45:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.513 X-Spam-Level: X-Spam-Status: No, score=-102.513 tagged_above=-999 required=5 tests=[AWL=0.086, 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 DLn9kvtXs3rp; Fri, 13 Jul 2012 15:45:29 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD6B911E80EC; Fri, 13 Jul 2012 15:45:29 -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.30p3 Message-ID: <20120713224529.20879.56219.idtracker@ietfa.amsl.com> Date: Fri, 13 Jul 2012 15:45:29 -0700 Cc: netmod@ietf.org Subject: [netmod] I-D Action: draft-ietf-netmod-interfaces-cfg-05.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, 13 Jul 2012 22:45:30 -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 Configuration Author(s) : Martin Bjorklund Filename : draft-ietf-netmod-interfaces-cfg-05.txt Pages : 24 Date : 2012-07-13 Abstract: This document defines a YANG data model for the configuration of network interfaces. It is expected that interface type specific configuration data models augment the generic interfaces data model defined in this document. 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-05 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-netmod-interfaces-cfg-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Fri Jul 13 15:49:38 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B779F11E812F; Fri, 13 Jul 2012 15:49:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.515 X-Spam-Level: X-Spam-Status: No, score=-102.515 tagged_above=-999 required=5 tests=[AWL=0.084, 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 DSiyhd4AJ33P; Fri, 13 Jul 2012 15:49:38 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0233B11E8134; Fri, 13 Jul 2012 15:49:38 -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.30p3 Message-ID: <20120713224938.26132.47839.idtracker@ietfa.amsl.com> Date: Fri, 13 Jul 2012 15:49:38 -0700 Cc: netmod@ietf.org Subject: [netmod] I-D Action: draft-ietf-netmod-ip-cfg-04.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, 13 Jul 2012 22:49:39 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the NETCONF Data Modeling Language Working Gr= oup of the IETF. Title : A YANG Data Model for IP Configuration Author(s) : Martin Bjorklund Filename : draft-ietf-netmod-ip-cfg-04.txt Pages : 19 Date : 2012-07-13 Abstract: This document defines a YANG data model for configuration of IP implementations. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-ip-cfg There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-netmod-ip-cfg-04 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-netmod-ip-cfg-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From mbj@tail-f.com Sun Jul 15 02:26:48 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EC5D21F85AE for ; Sun, 15 Jul 2012 02:26:48 -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 uI3Dl0AaOVee for ; Sun, 15 Jul 2012 02:26:47 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 730AC21F85AC for ; Sun, 15 Jul 2012 02:26:47 -0700 (PDT) Received: from localhost (213-65-181-96-no181.tbcn.telia.com [213.65.181.96]) by mail.tail-f.com (Postfix) with ESMTPSA id 478F31200D64; Sun, 15 Jul 2012 11:27:28 +0200 (CEST) Date: Sun, 15 Jul 2012 11:27:27 +0200 (CEST) Message-Id: <20120715.112727.359846057.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20120711100036.GD18153@elstar.local> References: <20120711093425.GB18153@elstar.local> <20120711100036.GD18153@elstar.local> X-Mailer: Mew version 6.3.51 on Emacs 23.3 / 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] WBEM/CIM v. NETCONF/YANG 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, 15 Jul 2012 09:26:48 -0000 Juergen Schoenwaelder wrote: > On Wed, Jul 11, 2012 at 10:44:38AM +0100, Jonathan Hansford wrote: > > > > In the > > telco world, people talk about element managers (managing > > > elements = > > devices) and network managers (managing whole networks, > > > that is a > > collection of elements = devices and links). While the IETF > > > work is > > currently focussed on managing devices, it seems some people > > > use > > NETCONF/YANG technology as well to manage whole networks, that is > > > > > YANG/NETCONF is used as an interface to a network manager instead of a > > > > > device interface. A few IETFs back, we even had a bar bof discussion > > > > > about this. > > > > I'm not sure I understand the client/server model in such a > > situation. Does that mean a NETCONF server is on the network manager as > > well as having servers on the devices? Or is there a hierarchy of > > clients and servers such that the devices are servers to the element > > manager clients and the element managers are servers to the network > > manager client? > > As far as I understood things, there is a NETCONF server interface to > the piece of software acting as a network manager. And devices might > have their device specific NETCONF server. Here's a paper describing such an implementation: http://static.usenix.org/events/lisa11/tech/full_papers/Wallin.pdf /martin From internet-drafts@ietf.org Mon Jul 16 00:51:10 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 631AB21F8526; Mon, 16 Jul 2012 00:51:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.518 X-Spam-Level: X-Spam-Status: No, score=-102.518 tagged_above=-999 required=5 tests=[AWL=0.081, 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 017E9lp0KgrG; Mon, 16 Jul 2012 00:51:09 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9DDA21F8611; Mon, 16 Jul 2012 00:51:09 -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.30p3 Message-ID: <20120716075109.20455.83236.idtracker@ietfa.amsl.com> Date: Mon, 16 Jul 2012 00:51:09 -0700 Cc: netmod@ietf.org Subject: [netmod] I-D Action: draft-ietf-netmod-ip-cfg-05.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, 16 Jul 2012 07:51:10 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the NETCONF Data Modeling Language Working Gr= oup of the IETF. Title : A YANG Data Model for IP Configuration Author(s) : Martin Bjorklund Filename : draft-ietf-netmod-ip-cfg-05.txt Pages : 20 Date : 2012-07-16 Abstract: This document defines a YANG data model for configuration of IP implementations. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-ip-cfg There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-netmod-ip-cfg-05 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-netmod-ip-cfg-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From j.schoenwaelder@jacobs-university.de Mon Jul 16 04:48:56 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D71521F8776 for ; Mon, 16 Jul 2012 04:48:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.206 X-Spam-Level: X-Spam-Status: No, score=-103.206 tagged_above=-999 required=5 tests=[AWL=0.043, 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 ramu--Lj5bhV for ; Mon, 16 Jul 2012 04:48: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 7BCD221F8737 for ; Mon, 16 Jul 2012 04:48:55 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5FE7020BF2; Mon, 16 Jul 2012 13:49:39 +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 c1OyDrEUuK1X; Mon, 16 Jul 2012 13:49:39 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A88CC20BE9; Mon, 16 Jul 2012 13:49:38 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id CE443208CFA8; Mon, 16 Jul 2012 13:49:33 +0200 (CEST) Date: Mon, 16 Jul 2012 13:49:32 +0200 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20120716114924.GC28076@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] wg last call on interfaces / ip / routing data models 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, 16 Jul 2012 11:48:56 -0000 Hi, I like to start a WG last call on the following set of documents: http://tools.ietf.org/html/draft-ietf-netmod-iana-if-type-04 http://tools.ietf.org/html/draft-ietf-netmod-interfaces-cfg-05 http://tools.ietf.org/html/draft-ietf-netmod-ip-cfg-05 http://tools.ietf.org/html/draft-ietf-netmod-routing-cfg-04 Please review the documents and raise any issues you might discover by opening a thread on the mailing list. Editorial fixes can be sent directly to the document editors. Please indicate your support by Monday, July 30, 2012. This allows us to discuss any issues coming up during the reviews at the IETF WG meeting, currently scheduled for Tuesday, July 31, 2012. If you need more time to review the documents, please contact the WG chairs. We are not only interested in receiving defect reports, we are equally interested in statements of the form: "I have reviewed I-D XYZ and I found no issues." "I have implemented the data model in I-D XYZ" "I am implementing the data model in I-D XYZ" "I am considering to implement the data model in I-D XYZ" /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From yihuan@cisco.com Mon Jul 16 14:32:43 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A321B21F8732 for ; Mon, 16 Jul 2012 14:32:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n1Tdp08U-udI for ; Mon, 16 Jul 2012 14:32:42 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id D21E021F8575 for ; Mon, 16 Jul 2012 14:32:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=yihuan@cisco.com; l=2679; q=dns/txt; s=iport; t=1342474408; x=1343684008; h=from:to:subject:date:message-id:mime-version; bh=qDWpqTQsCyUM87+wKlAESW4qdx9eBU/zZw1SB7ilHBw=; b=HtdtJx7FL6b+04R3/0qegXcGrzfZ7roTHIwP2AS2BedZP2TVInzGcdWW 7JY/bzttnYLl2toPKDQN9ZgD956MpeYcsOtham0k6E13nsvX1FFPn5ZPo 6gli8G5vjmUL8I/J/8Strh/0HHCHCs8x6Z8/y8lT4QbF+XpnpsF3p6XFQ M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EABSIBFCtJV2c/2dsb2JhbABFgkq3B4EHgicSAXgBDHQnBDWHa5sIgSigGJIHA5U7jiCBZoJf X-IronPort-AV: E=Sophos;i="4.77,596,1336348800"; d="scan'208,217";a="102181172" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-1.cisco.com with ESMTP; 16 Jul 2012 21:33:28 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id q6GLXSM2005565 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 16 Jul 2012 21:33:28 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.20]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.02.0298.004; Mon, 16 Jul 2012 16:33:28 -0500 From: "Lisa Huang (yihuan)" To: "netmod@ietf.org" Thread-Topic: How to use type that does not have standard yang typedef yet Thread-Index: AQHNY5qj45kBn3+xsESwINyJqkWevg== Date: Mon, 16 Jul 2012 21:33:27 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.2.120421 x-originating-ip: [10.154.203.136] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19042.007 x-tm-as-result: No--33.412600-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_CC29D6B612EC1yihuanciscocom_" MIME-Version: 1.0 Subject: [netmod] How to use type that does not have standard yang typedef yet 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, 16 Jul 2012 21:32:43 -0000 --_000_CC29D6B612EC1yihuanciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I would like to find out what is the best practice to use a type that shoul= d be defined in another module but that module is not available yet. Here i= s the scenario: My yang module B has a leaf L which type T is a reference (for example, v= lan id, IP Protocol) to the id of a container/list in module A (for example= VLAN, IP). However, module A is not defined yet. Should I define type T in= B and then deprecate it when module A is available? Should I use descripti= on to indicate type T and leaf L may be deprecate after module A or type T = is available in some standard? Thanks, Lisa --_000_CC29D6B612EC1yihuanciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <2C7158391151DC4480033B3B096D17B6@cisco.com> Content-Transfer-Encoding: quoted-printable
Hi,

I would like to find out what is the b= est practice to use a type that should be defined in another module but tha= t module is not available yet. Here is the scenario:

My yang module B has a leaf L which ty= pe  T is a reference  (for example, vlan id, IP Protocol) to the = id of a container/list in module A (for example VLAN, IP). However, module = A is not defined yet. Should I define type T in B and then deprecate it when module A is available? Should I use descri= ption to indicate type T and leaf L may be deprecate after module A or type= T is available in some standard?

Thanks,


Lisa

--_000_CC29D6B612EC1yihuanciscocom_-- From dromasca@avaya.com Mon Jul 16 15:11:58 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D04211E80DC for ; Mon, 16 Jul 2012 15:11:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.958 X-Spam-Level: X-Spam-Status: No, score=-102.958 tagged_above=-999 required=5 tests=[AWL=-0.359, 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 7j4m9NBAbvMx for ; Mon, 16 Jul 2012 15:11:57 -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 4F7B911E8112 for ; Mon, 16 Jul 2012 15:11:57 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAG2RBFDGmAcF/2dsb2JhbABCA7lQgQeCIAEBAQEDAQEBDx4KNAsMAgICAQgNAQIBBAEBCwYMCwEGARoMHwkIAQEEARIIGodrC58XnR0EizyDJoJBYAOWTYRmig6CYYFUBg X-IronPort-AV: E=Sophos;i="4.77,597,1336363200"; d="scan'208";a="18404822" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 16 Jul 2012 18:08:12 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.13]) by co300216-co-erhwest-out.avaya.com with ESMTP; 16 Jul 2012 18:09:07 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 17 Jul 2012 00:12:38 +0200 Message-ID: In-Reply-To: <20120716114924.GC28076@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] wg last call on interfaces / ip / routing data models Thread-Index: Ac1jSSKkDffMWnm4SDiNHMJ4a1dFegAVsU/A References: <20120716114924.GC28076@elstar.local> From: "Romascanu, Dan (Dan)" To: "Juergen Schoenwaelder" , Cc: adrian@olddog.co.uk Subject: Re: [netmod] wg last call on interfaces / ip / routing data models 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, 16 Jul 2012 22:11:58 -0000 Should we forward this LC to RTGAREA? (especially the last document)=20 Dan > -----Original Message----- > From: netmod-bounces@ietf.org [mailto:netmod-bounces@ietf.org] On Behalf > Of Juergen Schoenwaelder > Sent: Monday, July 16, 2012 2:50 PM > To: netmod@ietf.org > Subject: [netmod] wg last call on interfaces / ip / routing data models >=20 > Hi, >=20 > I like to start a WG last call on the following set of documents: >=20 > http://tools.ietf.org/html/draft-ietf-netmod-iana-if-type-04 > http://tools.ietf.org/html/draft-ietf-netmod-interfaces-cfg-05 > http://tools.ietf.org/html/draft-ietf-netmod-ip-cfg-05 > http://tools.ietf.org/html/draft-ietf-netmod-routing-cfg-04 >=20 > Please review the documents and raise any issues you might discover by > opening a thread on the mailing list. Editorial fixes can be sent > directly to the document editors. >=20 > Please indicate your support by Monday, July 30, 2012. This allows us > to discuss any issues coming up during the reviews at the IETF WG > meeting, currently scheduled for Tuesday, July 31, 2012. If you need > more time to review the documents, please contact the WG chairs. >=20 > We are not only interested in receiving defect reports, we are > equally interested in statements of the form: >=20 > "I have reviewed I-D XYZ and I found no issues." > "I have implemented the data model in I-D XYZ" > "I am implementing the data model in I-D XYZ" > "I am considering to implement the data model in I-D XYZ" >=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 j.schoenwaelder@jacobs-university.de Mon Jul 16 15:30:35 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82CEF11E831B for ; Mon, 16 Jul 2012 15:30:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.207 X-Spam-Level: X-Spam-Status: No, score=-103.207 tagged_above=-999 required=5 tests=[AWL=0.042, 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 xOa98hq1CoG1 for ; Mon, 16 Jul 2012 15:30:33 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 026E111E831A for ; Mon, 16 Jul 2012 15:30:33 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id D080020BC1; Tue, 17 Jul 2012 00:31:17 +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 psYtEbvqV1xZ; Tue, 17 Jul 2012 00:31: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 B82BF20BF3; Tue, 17 Jul 2012 00:31:16 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 842232090AB6; Tue, 17 Jul 2012 00:31:14 +0200 (CEST) Date: Tue, 17 Jul 2012 00:31:14 +0200 From: Juergen Schoenwaelder To: "Romascanu, Dan (Dan)" Message-ID: <20120716223113.GA62806@elstar.local> Mail-Followup-To: "Romascanu, Dan (Dan)" , netmod@ietf.org, adrian@olddog.co.uk References: <20120716114924.GC28076@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: adrian@olddog.co.uk, netmod@ietf.org Subject: Re: [netmod] wg last call on interfaces / ip / routing data models 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, 16 Jul 2012 22:30:35 -0000 Dan, this is for sure a good idea. In fact, I plan to notify all those who helped so far with reviewing. Tomorrow, when the deadline is over... /js On Tue, Jul 17, 2012 at 12:12:38AM +0200, Romascanu, Dan (Dan) wrote: > Should we forward this LC to RTGAREA? (especially the last document) > > Dan > > > > > -----Original Message----- > > From: netmod-bounces@ietf.org [mailto:netmod-bounces@ietf.org] On > Behalf > > Of Juergen Schoenwaelder > > Sent: Monday, July 16, 2012 2:50 PM > > To: netmod@ietf.org > > Subject: [netmod] wg last call on interfaces / ip / routing data > models > > > > Hi, > > > > I like to start a WG last call on the following set of documents: > > > > http://tools.ietf.org/html/draft-ietf-netmod-iana-if-type-04 > > http://tools.ietf.org/html/draft-ietf-netmod-interfaces-cfg-05 > > http://tools.ietf.org/html/draft-ietf-netmod-ip-cfg-05 > > http://tools.ietf.org/html/draft-ietf-netmod-routing-cfg-04 > > > > Please review the documents and raise any issues you might discover by > > opening a thread on the mailing list. Editorial fixes can be sent > > directly to the document editors. > > > > Please indicate your support by Monday, July 30, 2012. This allows us > > to discuss any issues coming up during the reviews at the IETF WG > > meeting, currently scheduled for Tuesday, July 31, 2012. If you need > > more time to review the documents, please contact the WG chairs. > > > > We are not only interested in receiving defect reports, we are > > equally interested in statements of the form: > > > > "I have reviewed I-D XYZ and I found no issues." > > "I have implemented the data model in I-D XYZ" > > "I am implementing the data model in I-D XYZ" > > "I am considering to implement the data model in I-D XYZ" > > > > /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 -- 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 Mon Jul 16 15:42:40 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35A1311E8341 for ; Mon, 16 Jul 2012 15:42:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.207 X-Spam-Level: X-Spam-Status: No, score=-103.207 tagged_above=-999 required=5 tests=[AWL=0.042, 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 KsU1hd0wHjow for ; Mon, 16 Jul 2012 15:42:39 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 25E4611E8340 for ; Mon, 16 Jul 2012 15:42:39 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 71F2520A6D; Tue, 17 Jul 2012 00:43: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 yAeiTInkymWt; Tue, 17 Jul 2012 00:43: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 BC7BD209DC; Tue, 17 Jul 2012 00:43:23 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 7152A2090D38; Tue, 17 Jul 2012 00:43:22 +0200 (CEST) Date: Tue, 17 Jul 2012 00:43:22 +0200 From: Juergen Schoenwaelder To: "Lisa Huang (yihuan)" Message-ID: <20120716224322.GC62806@elstar.local> Mail-Followup-To: "Lisa Huang (yihuan)" , "netmod@ietf.org" References: 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] How to use type that does not have standard yang typedef yet 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, 16 Jul 2012 22:42:40 -0000 On Mon, Jul 16, 2012 at 09:33:27PM +0000, Lisa Huang (yihuan) wrote: > Hi, > > I would like to find out what is the best practice to use a type that should be defined in another module but that module is not available yet. Here is the scenario: > > My yang module B has a leaf L which type T is a reference (for example, vlan id, IP Protocol) to the id of a container/list in module A (for example VLAN, IP). However, module A is not defined yet. Should I define type T in B and then deprecate it when module A is available? Should I use description to indicate type T and leaf L may be deprecate after module A or type T is available in some standard? > Are you saying T is a leafref? Or what does "T is a reference to the id of a container/list" mean? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From yihuan@cisco.com Mon Jul 16 17:35:25 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6994911E8073 for ; Mon, 16 Jul 2012 17:35:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[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 KYIZ0fKwDUe6 for ; Mon, 16 Jul 2012 17:35:24 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 796AE11E809B for ; Mon, 16 Jul 2012 17:35:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1235; q=dns/txt; s=iport; t=1342485370; x=1343694970; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=2FQsjR8IXb390oWDnc6nBUnOdYFnu5fpAMwDVGQAWRs=; b=Lj96sy4NVn7rNGR4GLOvK6Pq6N2KEwMjYYXB8+9X0YVblYlDXteRq8Ga TEGts6AD2C7RkZ/9tRh0mgMBOPWVMClEQhT07gHZPgdvMAevNEYHntKfh +MhgRF/7AcvIZWPGmuLCWBiXkx3HjK/83LJZGIN7/WKGh7C0NfoK/vPA5 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAFWyBFCtJXG//2dsb2JhbABCA7lWgQeCIAEBAQQSASc/DgQBCA4CCB4rFyUCBA4FIodrnFCgIgSLPIMmgyEDlTuOIIFmgl8 X-IronPort-AV: E=Sophos;i="4.77,598,1336348800"; d="scan'208";a="99437701" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-9.cisco.com with ESMTP; 17 Jul 2012 00:36:10 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id q6H0aAnv006013 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 17 Jul 2012 00:36:10 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.20]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.02.0298.004; Mon, 16 Jul 2012 19:36:09 -0500 From: "Lisa Huang (yihuan)" To: Juergen Schoenwaelder Thread-Topic: [netmod] How to use type that does not have standard yang typedef yet Thread-Index: AQHNY5qj45kBn3+xsESwINyJqkWevpcs1WoA//+qJwA= Date: Tue, 17 Jul 2012 00:36:09 +0000 Message-ID: In-Reply-To: <20120716224322.GC62806@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.2.120421 x-originating-ip: [10.154.203.136] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19042.007 x-tm-as-result: No--43.385500-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <61ED0E396A08834D91907508E4416C9C@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "netmod@ietf.org" Subject: Re: [netmod] How to use type that does not have standard yang typedef yet 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, 17 Jul 2012 00:35:25 -0000 Good comments. Obviously I could not use leafref since the leaf and its container module is not present. On 7/16/12 3:43 PM, "Juergen Schoenwaelder" wrote: >On Mon, Jul 16, 2012 at 09:33:27PM +0000, Lisa Huang (yihuan) wrote: >> Hi, >>=20 >> I would like to find out what is the best practice to use a type that >>should be defined in another module but that module is not available >>yet. Here is the scenario: >>=20 >> My yang module B has a leaf L which type T is a reference (for >>example, vlan id, IP Protocol) to the id of a container/list in module A >>(for example VLAN, IP). However, module A is not defined yet. Should I >>define type T in B and then deprecate it when module A is available? >>Should I use description to indicate type T and leaf L may be deprecate >>after module A or type T is available in some standard? >>=20 > >Are you saying T is a leafref? Or what does "T is a reference to the >id of a container/list" mean? > >/js > >--=20 >Juergen Schoenwaelder Jacobs University Bremen gGmbH >Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany >Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Mon Jul 16 23:41:24 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 493BF21F85C9 for ; Mon, 16 Jul 2012 23:41:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.208 X-Spam-Level: X-Spam-Status: No, score=-103.208 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y9HYPvFTGrFe for ; Mon, 16 Jul 2012 23:41:23 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 6A62621F85C7 for ; Mon, 16 Jul 2012 23:41:23 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5BDAB20B6C; Tue, 17 Jul 2012 08:42:09 +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 wcxopdQCTj4m; Tue, 17 Jul 2012 08:42:09 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D816120A13; Tue, 17 Jul 2012 08:42:08 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 1C06C2093592; Tue, 17 Jul 2012 08:42:06 +0200 (CEST) Date: Tue, 17 Jul 2012 08:42:06 +0200 From: Juergen Schoenwaelder To: "Lisa Huang (yihuan)" Message-ID: <20120717064206.GA11391@elstar.local> Mail-Followup-To: "Lisa Huang (yihuan)" , "netmod@ietf.org" References: <20120716224322.GC62806@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] How to use type that does not have standard yang typedef yet 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, 17 Jul 2012 06:41:24 -0000 Hi, I still do not understand what precisely your question is hence it is difficult to say something useful. Are you trying to import and use a type that does not exist yet? Are you trying to use a leafref for something that does not exist yet? And what does "use" mean - specify, implement or deploy? /js On Tue, Jul 17, 2012 at 12:36:09AM +0000, Lisa Huang (yihuan) wrote: > Good comments. Obviously I could not use leafref since the leaf and its > container module is not present. > > On 7/16/12 3:43 PM, "Juergen Schoenwaelder" > wrote: > > >On Mon, Jul 16, 2012 at 09:33:27PM +0000, Lisa Huang (yihuan) wrote: > >> Hi, > >> > >> I would like to find out what is the best practice to use a type that > >>should be defined in another module but that module is not available > >>yet. Here is the scenario: > >> > >> My yang module B has a leaf L which type T is a reference (for > >>example, vlan id, IP Protocol) to the id of a container/list in module A > >>(for example VLAN, IP). However, module A is not defined yet. Should I > >>define type T in B and then deprecate it when module A is available? > >>Should I use description to indicate type T and leaf L may be deprecate > >>after module A or type T is available in some standard? > >> > > > >Are you saying T is a leafref? Or what does "T is a reference to the > >id of a container/list" mean? > > > >/js > > > >-- > >Juergen Schoenwaelder Jacobs University Bremen gGmbH > >Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > >Fax: +49 421 200 3103 > -- 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 Jul 17 02:58:31 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34BA321F85C5 for ; Tue, 17 Jul 2012 02:58:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.035 X-Spam-Level: X-Spam-Status: No, score=-1.035 tagged_above=-999 required=5 tests=[AWL=-0.895, BAYES_20=-0.74, 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 umrI4CAMqJ2n for ; Tue, 17 Jul 2012 02:58:30 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id B310C21F859A for ; Tue, 17 Jul 2012 02:58:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 232E954029B for ; Tue, 17 Jul 2012 11:59:16 +0200 (CEST) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FHA0RFr11dPC for ; Tue, 17 Jul 2012 11:59:13 +0200 (CEST) Received: from localhost (birdie-w.lhotkovi.cz [172.29.2.202]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 341605401EC for ; Tue, 17 Jul 2012 11:59:12 +0200 (CEST) From: Ladislav Lhotka To: netmod@ietf.org User-Agent: Notmuch/0.13.2+77~g39beeb2 (http://notmuchmail.org) Emacs/23.3.50.1 (i386-apple-darwin9.8.0) Mail-Followup-To: netmod@ietf.org Date: Tue, 17 Jul 2012 11:59:12 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [netmod] LL review of iana-if-type-04 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, 17 Jul 2012 09:58:31 -0000 Hi, I reviewed the draft and YANG modules, and verified the enumerations against the current contents of corresponding IANA registries. One typo appearing twice on p. 45: s/Familiy/Family/ Otherwise I found no issues. Lada -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From yihuan@cisco.com Tue Jul 17 10:45:43 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3296321F8665 for ; Tue, 17 Jul 2012 10:45:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 4WGfd+WmYZbH for ; Tue, 17 Jul 2012 10:45:42 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 2C6B521F866C for ; Tue, 17 Jul 2012 10:45:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=yihuan@cisco.com; l=2840; q=dns/txt; s=iport; t=1342547190; x=1343756790; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=rAf+T67NZ7XJqK2VmzobN6mn0a2+8cDq+uXOqhPUMg4=; b=P4l0ZA2lEec55H92eHau+yyc+2XgIOMemwVdot0nRFW0FACIEDcjsO8x +CaEEituUL00KwgUxcn2NoQPvYdWKrYNMTfdA6zcrTns7NUqhHj/GQc5V iGzAkuSKwPdYWw34/wR3RtUKhkiHlqFAs6E9Oy/kQlcvFdjdOtgZrLF80 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAP+jBVCtJV2a/2dsb2JhbABCA7krgQeCIAEBAQQSASc/DgQBCA4CCB4rFyUCBA4FIodrnRCgOgSLPIMugyEDlT2OIoFmgl8 X-IronPort-AV: E=Sophos;i="4.77,604,1336348800"; d="scan'208";a="102516238" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-1.cisco.com with ESMTP; 17 Jul 2012 17:46:30 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q6HHkTQi013248 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 17 Jul 2012 17:46:29 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.20]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.02.0298.004; Tue, 17 Jul 2012 12:46:29 -0500 From: "Lisa Huang (yihuan)" To: Juergen Schoenwaelder Thread-Topic: [netmod] How to use type that does not have standard yang typedef yet Thread-Index: AQHNY5qj45kBn3+xsESwINyJqkWevpcs1WoA//+qJwCAANubAIAAREiA Date: Tue, 17 Jul 2012 17:46:29 +0000 Message-ID: In-Reply-To: <20120717064206.GA11391@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.2.120421 x-originating-ip: [10.154.203.136] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19046.000 x-tm-as-result: No--43.666600-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <6C667567FCBA6C458A593D7667D8492E@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "netmod@ietf.org" Subject: Re: [netmod] How to use type that does not have standard yang typedef yet 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, 17 Jul 2012 17:45:43 -0000 Here is one example. I have the following in B module: Module B { ... typedef vlan-id { type uint16 { range "1 .. 4095"; } Description "vlan id "; } =20 Container B { Leaf vlanId { type vlan-id; } } } Module B has a leaf which type is vlan-id. Ideally, vlan-id typedef should be defined in vlan module or some other ietf types module, which is not existing yet. What is the right process to define vlan-id? Should I propose the vlan-id typedef to ietf types module or define my own. If I define my own, whenever the vlan ietf standard module defined, the only way for module B to align with the standard is to deprecate both vlan-id and leaf vlanId.=20 Thanks,=20 Lisa However On 7/16/12 11:42 PM, "Juergen Schoenwaelder" wrote: >Hi, > >I still do not understand what precisely your question is hence it is >difficult to say something useful. Are you trying to import and use a >type that does not exist yet? Are you trying to use a leafref for >something that does not exist yet? And what does "use" mean - specify, >implement or deploy? > >/js > >On Tue, Jul 17, 2012 at 12:36:09AM +0000, Lisa Huang (yihuan) wrote: >> Good comments. Obviously I could not use leafref since the leaf and its >> container module is not present. >>=20 >> On 7/16/12 3:43 PM, "Juergen Schoenwaelder" >> wrote: >>=20 >> >On Mon, Jul 16, 2012 at 09:33:27PM +0000, Lisa Huang (yihuan) wrote: >> >> Hi, >> >>=20 >> >> I would like to find out what is the best practice to use a type that >> >>should be defined in another module but that module is not available >> >>yet. Here is the scenario: >> >>=20 >> >> My yang module B has a leaf L which type T is a reference (for >> >>example, vlan id, IP Protocol) to the id of a container/list in >>module A >> >>(for example VLAN, IP). However, module A is not defined yet. Should I >> >>define type T in B and then deprecate it when module A is available? >> >>Should I use description to indicate type T and leaf L may be >>deprecate >> >>after module A or type T is available in some standard? >> >>=20 >> > >> >Are you saying T is a leafref? Or what does "T is a reference to the >> >id of a container/list" mean? >> > >> >/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 >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 Jul 17 12:48:17 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A05D321F861C for ; Tue, 17 Jul 2012 12:48:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.208 X-Spam-Level: X-Spam-Status: No, score=-103.208 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yB0DKgJn9upV for ; Tue, 17 Jul 2012 12:48: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 CBC5321F85F7 for ; Tue, 17 Jul 2012 12:48:16 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 22159209D7; Tue, 17 Jul 2012 21:49:04 +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 gS5EqbFCYUPy; Tue, 17 Jul 2012 21:49: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 98A4020979; Tue, 17 Jul 2012 21:49:03 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 7D07020A217A; Tue, 17 Jul 2012 21:49:01 +0200 (CEST) Date: Tue, 17 Jul 2012 21:49:01 +0200 From: Juergen Schoenwaelder To: "Lisa Huang (yihuan)" Message-ID: <20120717194900.GB17029@elstar.local> Mail-Followup-To: "Lisa Huang (yihuan)" , "netmod@ietf.org" References: <20120717064206.GA11391@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] How to use type that does not have standard yang typedef yet 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, 17 Jul 2012 19:48:17 -0000 On Tue, Jul 17, 2012 at 05:46:29PM +0000, Lisa Huang (yihuan) wrote: > Here is one example. I have the following in B module: > > Module B { > ... > typedef vlan-id { > type uint16 { > range "1 .. 4095"; > } > Description "vlan id "; > } > > > > Container B { > Leaf vlanId { > type vlan-id; > } > } > > } > > Module B has a leaf which type is vlan-id. Ideally, vlan-id typedef should > be defined in vlan module or some other ietf types module, which is not > existing yet. What is the right process to define vlan-id? Should I > propose the vlan-id typedef to ietf types module or define my own. If I > define my own, whenever the vlan ietf standard module defined, the only > way for module B to align with the standard is to deprecate both vlan-id > and leaf vlanId. In the SMI world, we usually allowed to replace an inline type (syntax) definition with a textual convention (type) definition if both were 100% semantically identical. As a matter for fact, it often happened that inline definitions were later turned into TCs in order to reuse them (or to move maintenance over to IANA). The hard part is semantic equivalence. If for whatever reason the finally published type differes from your best guess, you indeed have to deprecate the object(s) and create new one(s) or you stick with your own definition. Concerning the process, the simple answer is we do not really have one. Right now, the recommendation is to write up concrete proposals and to send them to the mailing list. I am trying to collect them and at some point we need to decide what to do with them, e.g., revising RFC 6021 and adding definitions or even more modules. (Ideally, a vlan-id typedef would be defined by the IEEE but this is unlikely to happen anytime soon.) /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From andy@yumaworks.com Tue Jul 17 12:53:24 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D6EA21F84E1 for ; Tue, 17 Jul 2012 12:53:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.954 X-Spam-Level: X-Spam-Status: No, score=-2.954 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 5BIi4bvgZByf for ; Tue, 17 Jul 2012 12:53:23 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1A85F21F84DF for ; Tue, 17 Jul 2012 12:53:22 -0700 (PDT) Received: by bkty7 with SMTP id y7so779139bkt.31 for ; Tue, 17 Jul 2012 12: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-originating-ip:in-reply-to:references:date :message-id:subject:from:to:content-type:x-gm-message-state; bh=Os6xv/dN4U4YCz8FAtMl1mdzFcY4/NKS1JkCIoDu6aM=; b=mg7at5D4dEIj8MWlZpN9pUCjZHpGGJXbovVSYMOCywvdJDHUTXxvn1+8OjSQpQJgSp 3bt7xtPBS+lrxVALIXFHNlfh/2RO0qgOtQGxiQvxJ8cN47GjPttvIZyhN/JN2c76kMPF +Pjo4e8m9kMb27DPneOFzJfhIYz1SYwFsI8RcqSvhz8fx4D32wFsm3GpZaAKKoaUgv1g YMir7l1h1L1GLbOyuoKY76dNrs6bwIwTSAn4ZQ8+4RlyFnjeyEyNyV/+0PrR3d3lNvEZ CLP22b57bAPQaB18mXtk6EzdyOhqvcKialjkRvwEr1jl0VLgcm10QOnoBjZ8VTiCBNxT kMDQ== MIME-Version: 1.0 Received: by 10.152.106.233 with SMTP id gx9mr162354lab.48.1342554850380; Tue, 17 Jul 2012 12:54:10 -0700 (PDT) Received: by 10.114.19.72 with HTTP; Tue, 17 Jul 2012 12:54:10 -0700 (PDT) X-Originating-IP: [75.84.168.164] In-Reply-To: <20120717194900.GB17029@elstar.local> References: <20120717064206.GA11391@elstar.local> <20120717194900.GB17029@elstar.local> Date: Tue, 17 Jul 2012 12:54:10 -0700 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , "Lisa Huang (yihuan)" , "netmod@ietf.org" Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQnYBjRkeWgd0tABFCQAZg3ad6tW31QeiPRWW9X/aP5sGwW0l9zWGa6Say/a4p0Os+nsYBp6 Subject: Re: [netmod] How to use type that does not have standard yang typedef yet 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, 17 Jul 2012 19:53:24 -0000 See RFC 6020, page 136: o A "type" statement may be replaced with another "type" statement that does not change the syntax or semantics of the type. For example, an inline type definition may be replaced with a typedef, but an int8 type cannot be replaced by an int16, since the syntax would change. Andy On Tue, Jul 17, 2012 at 12:49 PM, Juergen Schoenwaelder wrote: > On Tue, Jul 17, 2012 at 05:46:29PM +0000, Lisa Huang (yihuan) wrote: >> Here is one example. I have the following in B module: >> >> Module B { >> ... >> typedef vlan-id { >> type uint16 { >> range "1 .. 4095"; >> } >> Description "vlan id "; >> } >> >> >> >> Container B { >> Leaf vlanId { >> type vlan-id; >> } >> } >> >> } >> >> Module B has a leaf which type is vlan-id. Ideally, vlan-id typedef should >> be defined in vlan module or some other ietf types module, which is not >> existing yet. What is the right process to define vlan-id? Should I >> propose the vlan-id typedef to ietf types module or define my own. If I >> define my own, whenever the vlan ietf standard module defined, the only >> way for module B to align with the standard is to deprecate both vlan-id >> and leaf vlanId. > > In the SMI world, we usually allowed to replace an inline type > (syntax) definition with a textual convention (type) definition if > both were 100% semantically identical. As a matter for fact, it often > happened that inline definitions were later turned into TCs in order > to reuse them (or to move maintenance over to IANA). > > The hard part is semantic equivalence. If for whatever reason the > finally published type differes from your best guess, you indeed have > to deprecate the object(s) and create new one(s) or you stick with > your own definition. > > Concerning the process, the simple answer is we do not really have > one. Right now, the recommendation is to write up concrete proposals > and to send them to the mailing list. I am trying to collect them and > at some point we need to decide what to do with them, e.g., revising > RFC 6021 and adding definitions or even more modules. (Ideally, a > vlan-id typedef would be defined by the IEEE but this is unlikely to > happen anytime soon.) > > /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 yihuan@cisco.com Tue Jul 17 14:27:58 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38DA211E80B8 for ; Tue, 17 Jul 2012 14:27:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[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 DMQhmLXAL0Fp for ; Tue, 17 Jul 2012 14:27:56 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 773F711E80A4 for ; Tue, 17 Jul 2012 14:27:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=yihuan@cisco.com; l=3728; q=dns/txt; s=iport; t=1342560525; x=1343770125; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=t0MlsQUbZ1QaHmSOmyppAzEufvedUY6PDf6jYsy8lGQ=; b=SaR+m0Oe1kasqaEL5Qapy+bVjcFhzVpkWWfUyTRFu+B0l2lSnqeM7Lol vx90FJHt77+h57obKtD0e6jQe/GLVCbd+evPt3dHIoZFbbQehnXefDh9h gGNeVMjNMeOaI0yMldf9kGbHLZHnm9Oaz+GNAyaxng5IL82uDdHby084G o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAAnYBVCtJXG8/2dsb2JhbABCA7kEgQeCIAEBAQQBAQEPASc0GQQBCBAIHisMCyUCBAESIodrC50XoCoEizyDLoMhA5U9jiKBZoJf X-IronPort-AV: E=Sophos;i="4.77,604,1336348800"; d="scan'208";a="102805169" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-8.cisco.com with ESMTP; 17 Jul 2012 21:28:44 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id q6HLSiJ7005391 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 17 Jul 2012 21:28:44 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.20]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.02.0283.003; Tue, 17 Jul 2012 16:28:44 -0500 From: "Lisa Huang (yihuan)" To: Andy Bierman , Juergen Schoenwaelder , "netmod@ietf.org" Thread-Topic: [netmod] How to use type that does not have standard yang typedef yet Thread-Index: AQHNY5qj45kBn3+xsESwINyJqkWevpcs1WoA//+qJwCAANubAIAAREiAgACXlYCAAAFwAP//pRKA Date: Tue, 17 Jul 2012 21:28:44 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.2.120421 x-originating-ip: [10.154.203.136] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19046.004 x-tm-as-result: No--44.693300-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [netmod] How to use type that does not have standard yang typedef yet 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, 17 Jul 2012 21:27:58 -0000 Andy,=20 Thanks for the comments. Does it mean the following change is allowed? Before: Module B { revision 2012-01-08 ... typedef vlan-id { type uint16 { range "1 .. 4095"; } Description "vlan id "; } Container B { Leaf vlanId { type vlan-id; } } } After: Module B { Import A { prefix a ;} revision 2012-08-08 <--- change the revision ... Container B { Leaf vlanId { type a:vlan-identifier <---change to the type from import } } } Module A { typedef vlan-identifier { <---typedef name changes type uint16 { range "1 .. 4095"; } Description "This type denotes a VLAN tag. "; <--- description is not exactly the same. } } Thanks, Lisa On 7/17/12 12:54 PM, "Andy Bierman" wrote: >See RFC 6020, page 136: > > o A "type" statement may be replaced with another "type" statement > that does not change the syntax or semantics of the type. For > example, an inline type definition may be replaced with a typedef, > but an int8 type cannot be replaced by an int16, since the syntax > would change. > >Andy > > >On Tue, Jul 17, 2012 at 12:49 PM, Juergen Schoenwaelder > wrote: >> On Tue, Jul 17, 2012 at 05:46:29PM +0000, Lisa Huang (yihuan) wrote: >>> Here is one example. I have the following in B module: >>> >>> Module B { >>> ... >>> typedef vlan-id { >>> type uint16 { >>> range "1 .. 4095"; >>> } >>> Description "vlan id "; >>> } >>> >>> >>> >>> Container B { >>> Leaf vlanId { >>> type vlan-id; >>> } >>> } >>> >>> } >>> >>> Module B has a leaf which type is vlan-id. Ideally, vlan-id typedef >>>should >>> be defined in vlan module or some other ietf types module, which is not >>> existing yet. What is the right process to define vlan-id? Should I >>> propose the vlan-id typedef to ietf types module or define my own. If I >>> define my own, whenever the vlan ietf standard module defined, the only >>> way for module B to align with the standard is to deprecate both >>>vlan-id >>> and leaf vlanId. >> >> In the SMI world, we usually allowed to replace an inline type >> (syntax) definition with a textual convention (type) definition if >> both were 100% semantically identical. As a matter for fact, it often >> happened that inline definitions were later turned into TCs in order >> to reuse them (or to move maintenance over to IANA). >> >> The hard part is semantic equivalence. If for whatever reason the >> finally published type differes from your best guess, you indeed have >> to deprecate the object(s) and create new one(s) or you stick with >> your own definition. >> >> Concerning the process, the simple answer is we do not really have >> one. Right now, the recommendation is to write up concrete proposals >> and to send them to the mailing list. I am trying to collect them and >> at some point we need to decide what to do with them, e.g., revising >> RFC 6021 and adding definitions or even more modules. (Ideally, a >> vlan-id typedef would be defined by the IEEE but this is unlikely to >> happen anytime soon.) >> >> /js >> >> -- >> Juergen Schoenwaelder Jacobs University Bremen gGmbH >> Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany >> Fax: +49 421 200 3103 >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod From andy@yumaworks.com Tue Jul 17 15:07:50 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A5A211E80C8 for ; Tue, 17 Jul 2012 15:07:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.955 X-Spam-Level: X-Spam-Status: No, score=-2.955 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 E-ommlRZnrUt for ; Tue, 17 Jul 2012 15:07:49 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1E88611E80BD for ; Tue, 17 Jul 2012 15:07:48 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so1377828lbb.31 for ; Tue, 17 Jul 2012 15:08:36 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=ga+Br4L7XANmNB4tvPOSOPIsvQGNUi6wpZ+7qXjWkZM=; b=IRmA4mD3iloa1BVZbv7uBeNe53gTCMtdf4ZQcgm1jk7icvN3nAQnVBYtvmJjDzhrPV tOgPy+tZsC/t1UAitvjKCOXVge2MqINR1d5RU1zr86H5AnReKOAeUSKvKcE1HF41U7Oe ff6rQ5ShYA/AeM5hupKIxHufS2IQrcatSdCm10kdRKhVlW8Hb6I4H4j6/xeDZFalh0BX LSu2B5YJu4PD1S287aIgQP/qahDrIIX+E/0k9Mhwqo52JnSSvLVyvVQ1ak6OMlB/rt5B BEP/n92lqc+0ao/GgSneiT/YfTws73l3Fpo6wSBIxEUdjHHV7FLH5Q8m+fh8agQH5MDo wNHQ== MIME-Version: 1.0 Received: by 10.112.86.166 with SMTP id q6mr607186lbz.6.1342562916363; Tue, 17 Jul 2012 15:08:36 -0700 (PDT) Received: by 10.114.19.72 with HTTP; Tue, 17 Jul 2012 15:08:36 -0700 (PDT) X-Originating-IP: [75.84.168.164] In-Reply-To: References: Date: Tue, 17 Jul 2012 15:08:36 -0700 Message-ID: From: Andy Bierman To: "Lisa Huang (yihuan)" Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQl+zgUV4A1e4o+fzaG5GnHEVS1orwZ+WPgG3cniMmbPfjsvMBOf0ghXpjTQrWaie6ovNUdw Cc: "netmod@ietf.org" Subject: Re: [netmod] How to use type that does not have standard yang typedef yet 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, 17 Jul 2012 22:07:50 -0000 On Tue, Jul 17, 2012 at 2:28 PM, Lisa Huang (yihuan) wrote: > Andy, > > Thanks for the comments. > > Does it mean the following change is allowed? > yes. The syntax and semantics cannot change. The packaging can change, including wrapper types; typedef new-vlan-id { type vlan-identifier; } Andy > Before: > > Module B { > revision 2012-01-08 > ... > typedef vlan-id { > type uint16 { > range "1 .. 4095"; > } > Description "vlan id "; > } > > Container B { > Leaf vlanId { > type vlan-id; > } > } > > } > > > After: > > > Module B { > Import A { prefix a ;} > revision 2012-08-08 <--- change the revision > ... > > Container B { > Leaf vlanId { > type a:vlan-identifier <---change to the type from import > } > } > } > Module A { > > typedef vlan-identifier { <---typedef name changes > type uint16 { > range "1 .. 4095"; > } > Description "This type denotes a VLAN tag. "; <--- description is not > exactly the same. > } > } > > Thanks, > > Lisa > > On 7/17/12 12:54 PM, "Andy Bierman" wrote: > >>See RFC 6020, page 136: >> >> o A "type" statement may be replaced with another "type" statement >> that does not change the syntax or semantics of the type. For >> example, an inline type definition may be replaced with a typedef, >> but an int8 type cannot be replaced by an int16, since the syntax >> would change. >> >>Andy >> >> >>On Tue, Jul 17, 2012 at 12:49 PM, Juergen Schoenwaelder >> wrote: >>> On Tue, Jul 17, 2012 at 05:46:29PM +0000, Lisa Huang (yihuan) wrote: >>>> Here is one example. I have the following in B module: >>>> >>>> Module B { >>>> ... >>>> typedef vlan-id { >>>> type uint16 { >>>> range "1 .. 4095"; >>>> } >>>> Description "vlan id "; >>>> } >>>> >>>> >>>> >>>> Container B { >>>> Leaf vlanId { >>>> type vlan-id; >>>> } >>>> } >>>> >>>> } >>>> >>>> Module B has a leaf which type is vlan-id. Ideally, vlan-id typedef >>>>should >>>> be defined in vlan module or some other ietf types module, which is not >>>> existing yet. What is the right process to define vlan-id? Should I >>>> propose the vlan-id typedef to ietf types module or define my own. If I >>>> define my own, whenever the vlan ietf standard module defined, the only >>>> way for module B to align with the standard is to deprecate both >>>>vlan-id >>>> and leaf vlanId. >>> >>> In the SMI world, we usually allowed to replace an inline type >>> (syntax) definition with a textual convention (type) definition if >>> both were 100% semantically identical. As a matter for fact, it often >>> happened that inline definitions were later turned into TCs in order >>> to reuse them (or to move maintenance over to IANA). >>> >>> The hard part is semantic equivalence. If for whatever reason the >>> finally published type differes from your best guess, you indeed have >>> to deprecate the object(s) and create new one(s) or you stick with >>> your own definition. >>> >>> Concerning the process, the simple answer is we do not really have >>> one. Right now, the recommendation is to write up concrete proposals >>> and to send them to the mailing list. I am trying to collect them and >>> at some point we need to decide what to do with them, e.g., revising >>> RFC 6021 and adding definitions or even more modules. (Ideally, a >>> vlan-id typedef would be defined by the IEEE but this is unlikely to >>> happen anytime soon.) >>> >>> /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 Wed Jul 18 07:30:49 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68D0021F86B9 for ; Wed, 18 Jul 2012 07:30:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.209 X-Spam-Level: X-Spam-Status: No, score=-103.209 tagged_above=-999 required=5 tests=[AWL=0.040, 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 EJVFc421tca1 for ; Wed, 18 Jul 2012 07:30: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 703B421F8678 for ; Wed, 18 Jul 2012 07:30:48 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6EAB620BD8; Wed, 18 Jul 2012 16:31:38 +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 F6XU-iolkTNc; Wed, 18 Jul 2012 16:31: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 0B5D620979; Wed, 18 Jul 2012 16:31:38 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id D74BF20A8468; Wed, 18 Jul 2012 16:31:35 +0200 (CEST) Date: Wed, 18 Jul 2012 16:31:35 +0200 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20120718143135.GA54574@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] draft agenda for the NETMOD WG session in Vancouver 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, 18 Jul 2012 14:30:49 -0000 Hi, here is a first draft of the agenda for the upcoming meeting in Vancouver: https://datatracker.ietf.org/meeting/84/agenda/netmod/ /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From wwwrun@rfc-editor.org Fri Jul 20 07:38:01 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02C3F21F849C for ; Fri, 20 Jul 2012 07:38:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.242 X-Spam-Level: X-Spam-Status: No, score=-102.242 tagged_above=-999 required=5 tests=[AWL=0.358, 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 HYG3PrhbGIkc for ; Fri, 20 Jul 2012 07:38:00 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 1C38021F866B for ; Fri, 20 Jul 2012 07:38:00 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 9F753621A1; Fri, 20 Jul 2012 07:38:13 -0700 (PDT) To: mbj@tail-f.com, rbonica@juniper.net, bclaise@cisco.com, j.schoenwaelder@jacobs-university.de, david.kessens@nsn.com From: RFC Errata System Message-Id: <20120720143813.9F753621A1@rfc-editor.org> Date: Fri, 20 Jul 2012 07:38:13 -0700 (PDT) Cc: netmod@ietf.org, rfc-editor@rfc-editor.org Subject: [netmod] [Technical Errata Reported] RFC6020 (3288) 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, 20 Jul 2012 14:38:01 -0000 The following errata report has been submitted for RFC6020, "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6020&eid=3288 -------------------------------------- Type: Technical Reported by: Martin Björklund Section: 7.12.1 Original Text ------------- +--------------+---------+-------------+ | substatement | section | cardinality | +--------------+---------+-------------+ | augment | 7.15 | 0..1 | | description | 7.19.3 | 0..1 | | if-feature | 7.18.2 | 0..n | | refine | 7.12.2 | 0..1 | | reference | 7.19.4 | 0..1 | | status | 7.19.2 | 0..1 | | when | 7.19.5 | 0..1 | +--------------+---------+-------------+ Corrected Text -------------- +--------------+---------+-------------+ | substatement | section | cardinality | +--------------+---------+-------------+ | augment | 7.15 | 0..n | | description | 7.19.3 | 0..1 | | if-feature | 7.18.2 | 0..n | | refine | 7.12.2 | 0..n | | reference | 7.19.4 | 0..1 | | status | 7.19.2 | 0..1 | | when | 7.19.5 | 0..1 | +--------------+---------+-------------+ Notes ----- The cardinality for 'augment' and 'refine' is '0..n' Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6020 (draft-ietf-netmod-yang-13) -------------------------------------- Title : YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF) Publication Date : October 2010 Author(s) : M. Bjorklund, Ed. Category : PROPOSED STANDARD Source : NETCONF Data Modeling Language Area : Operations and Management Stream : IETF Verifying Party : IESG From wwwrun@rfc-editor.org Fri Jul 20 07:41:52 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25CBA21F8596 for ; Fri, 20 Jul 2012 07:41:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.244 X-Spam-Level: X-Spam-Status: No, score=-102.244 tagged_above=-999 required=5 tests=[AWL=0.356, 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 iVgtiGy4DAoM for ; Fri, 20 Jul 2012 07:41:51 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id E2E8D21F8530 for ; Fri, 20 Jul 2012 07:41:50 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id A5490621A1; Fri, 20 Jul 2012 07:42:04 -0700 (PDT) To: mbj@tail-f.com, rbonica@juniper.net, bclaise@cisco.com, j.schoenwaelder@jacobs-university.de, david.kessens@nsn.com From: RFC Errata System Message-Id: <20120720144204.A5490621A1@rfc-editor.org> Date: Fri, 20 Jul 2012 07:42:04 -0700 (PDT) Cc: netmod@ietf.org, rfc-editor@rfc-editor.org Subject: [netmod] [Technical Errata Reported] RFC6020 (3289) 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, 20 Jul 2012 14:41:52 -0000 The following errata report has been submitted for RFC6020, "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6020&eid=3289 -------------------------------------- Type: Technical Reported by: Martin Björklund Section: 12 Original Text ------------- descendant-schema-nodeid = node-identifier absolute-schema-nodeid Corrected Text -------------- descendant-schema-nodeid = node-identifier [absolute-schema-nodeid] Notes ----- A single node identifier is a valid descendant-schema-nodeid. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6020 (draft-ietf-netmod-yang-13) -------------------------------------- Title : YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF) Publication Date : October 2010 Author(s) : M. Bjorklund, Ed. Category : PROPOSED STANDARD Source : NETCONF Data Modeling Language Area : Operations and Management Stream : IETF Verifying Party : IESG From wwwrun@rfc-editor.org Fri Jul 20 07:45:12 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E6D521F857D for ; Fri, 20 Jul 2012 07:45:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.247 X-Spam-Level: X-Spam-Status: No, score=-102.247 tagged_above=-999 required=5 tests=[AWL=0.353, 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 FLqqM+cqfg3x for ; Fri, 20 Jul 2012 07:45:11 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 5A2C021F8552 for ; Fri, 20 Jul 2012 07:45:11 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 881F3621A1; Fri, 20 Jul 2012 07:45:25 -0700 (PDT) To: mbj@tail-f.com, rbonica@juniper.net, bclaise@cisco.com, j.schoenwaelder@jacobs-university.de, david.kessens@nsn.com From: RFC Errata System Message-Id: <20120720144525.881F3621A1@rfc-editor.org> Date: Fri, 20 Jul 2012 07:45:25 -0700 (PDT) Cc: netmod@ietf.org, rfc-editor@rfc-editor.org Subject: [netmod] [Technical Errata Reported] RFC6020 (3290) 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, 20 Jul 2012 14:45:12 -0000 The following errata report has been submitted for RFC6020, "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6020&eid=3290 -------------------------------------- Type: Technical Reported by: Martin Björklund Section: 12 Original Text ------------- decimal64-specification = fraction-digits-stmt Corrected Text -------------- decimal64-specification = ;; these stmts can appear in any order fraction-digits-stmt [range-stmt stmtsep] Notes ----- A decimal64 type can be restricted with the "range" statement. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6020 (draft-ietf-netmod-yang-13) -------------------------------------- Title : YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF) Publication Date : October 2010 Author(s) : M. Bjorklund, Ed. Category : PROPOSED STANDARD Source : NETCONF Data Modeling Language Area : Operations and Management Stream : IETF Verifying Party : IESG From jmh@joelhalpern.com Fri Jul 20 09:52:54 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87DD321F85E4 for ; Fri, 20 Jul 2012 09:52:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.356 X-Spam-Level: X-Spam-Status: No, score=-102.356 tagged_above=-999 required=5 tests=[AWL=-0.091, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 HXzWoM3tYNjU for ; Fri, 20 Jul 2012 09:52:53 -0700 (PDT) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 121D321F85E1 for ; Fri, 20 Jul 2012 09:52:53 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by morbo.tigertech.net (Postfix) with ESMTP id 374C4A63A4 for ; Fri, 20 Jul 2012 09:53:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id B12F412041B for ; Fri, 20 Jul 2012 09:53:48 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [10.10.10.105] (pool-71-161-52-60.clppva.btas.verizon.net [71.161.52.60]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 57CE412041A for ; Fri, 20 Jul 2012 09:53:48 -0700 (PDT) Message-ID: <50098D11.5030305@joelhalpern.com> Date: Fri, 20 Jul 2012 12:53:37 -0400 From: Joel Halpern User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: NETMOD Working Group Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [netmod] NetMod routing 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, 20 Jul 2012 16:52:54 -0000 In looking at the spec, and comparing with MIBs in the space, one thing appeared to be missing. I could not see an equivalent of the route-info field used to represent tagging that is carried between routing protocols by the RIB. Yours, Joel From j.schoenwaelder@jacobs-university.de Wed Jul 25 01:17:18 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02F4B21F8564 for ; Wed, 25 Jul 2012 01:17:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.281 X-Spam-Level: X-Spam-Status: No, score=-102.281 tagged_above=-999 required=5 tests=[AWL=-0.891, BAYES_20=-0.74, 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 H25yYD0yRp9z for ; Wed, 25 Jul 2012 01:17: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 AF30E21F8552 for ; Wed, 25 Jul 2012 01:17:16 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6ADAC20BE8; Wed, 25 Jul 2012 10:17:15 +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 yawG2yF4C1z6; Wed, 25 Jul 2012 10:17:15 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 15A20208C6; Wed, 25 Jul 2012 10:17:14 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id D5BA620E5467; Wed, 25 Jul 2012 10:17:13 +0200 (CEST) Date: Wed, 25 Jul 2012 10:17:13 +0200 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20120725081713.GA50389@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] RFC 6020 errata 3288, 3289, 3290 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, 25 Jul 2012 08:17:18 -0000 Hi, Martin has posted errata 3288, 3289, 3290: http://www.rfc-editor.org/errata_search.php?rfc=6020 Can people review and comment? Is there agreement that these are valid technical errata? Speaking as technical contributor, it seems 3289 and 3290 are relatively clear cut fixes. I am not so sure about 3288, in particular the augment case and the meaningful usage of (multiple) augments in a uses substatement. I do note that the errata brings the table in section 7.12.1 inline with the grammar of uses-stmt. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From jernej.tuljak@mg-soft.si Wed Jul 25 02:00:57 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F92821F84FB for ; Wed, 25 Jul 2012 02:00:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.351 X-Spam-Level: X-Spam-Status: No, score=-2.351 tagged_above=-999 required=5 tests=[AWL=0.248, 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 OiiOgKcnph3E for ; Wed, 25 Jul 2012 02:00:57 -0700 (PDT) Received: from gate.mg-soft.si (gate.mg-soft.si [212.30.73.66]) by ietfa.amsl.com (Postfix) with ESMTP id B3B4421F84F2 for ; Wed, 25 Jul 2012 02:00:56 -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 q6P90r5n031097 for ; Wed, 25 Jul 2012 11:00:54 +0200 Message-ID: <500FB5B8.1010001@mg-soft.com> Date: Wed, 25 Jul 2012 11:00:40 +0200 From: Jernej Tuljak User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: netmod@ietf.org References: <20120725081713.GA50389@elstar.local> In-Reply-To: <20120725081713.GA50389@elstar.local> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [netmod] RFC 6020 errata 3288, 3289, 3290 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, 25 Jul 2012 09:00:57 -0000 Dne 25.7.2012 10:17, piše Juergen Schoenwaelder: > Hi, > > Martin has posted errata 3288, 3289, 3290: > > http://www.rfc-editor.org/errata_search.php?rfc=6020 > > Can people review and comment? Is there agreement that these are valid > technical errata? > > Speaking as technical contributor, it seems 3289 and 3290 are > relatively clear cut fixes. > > I am not so sure about 3288, in particular the augment case and the > meaningful usage of (multiple) augments in a uses substatement. I do > note that the errata brings the table in section 7.12.1 inline with > the grammar of uses-stmt. I agree with Martin. Both augment and refine statements under a uses statement should have a cardinality of 0..n. Imagine a grouping with multiple container statements. A cardinality of 0..1 would mean that the user may choose to augment only one of them during uses expansion. What if the requirement is to add statements to two of such containers? Same goes for refine. Note that this is the only way for a grouping or rather it's content to get augmented. And I can't imagine groupings with multiple subtrees being uncommon. From my perspective these are only typos. YANG grammar confirms it. Jernej > > /js > From lhotka@nic.cz Wed Jul 25 04:29:17 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C274621F85B6 for ; Wed, 25 Jul 2012 04:29:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[AWL=0.064, 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 5-IdSoYacByE for ; Wed, 25 Jul 2012 04:29:17 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 2EC0421F85BB for ; Wed, 25 Jul 2012 04:29:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 6A29E5405AB; Wed, 25 Jul 2012 13:29:14 +0200 (CEST) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iYfursrZd8vL; Wed, 25 Jul 2012 13:29:07 +0200 (CEST) Received: from localhost (birdie-w.lhotkovi.cz [172.29.2.202]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 658625400F9; Wed, 25 Jul 2012 13:29:05 +0200 (CEST) From: Ladislav Lhotka To: Joel Halpern , NETMOD Working Group In-Reply-To: <50098D11.5030305@joelhalpern.com> References: <50098D11.5030305@joelhalpern.com> User-Agent: Notmuch/0.13.2+77~g39beeb2 (http://notmuchmail.org) Emacs/23.3.50.1 (i386-apple-darwin9.8.0) Mail-Followup-To: Joel Halpern , NETMOD Working Group Date: Wed, 25 Jul 2012 13:29:05 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [netmod] NetMod routing 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: Wed, 25 Jul 2012 11:29:17 -0000 Joel Halpern writes: > In looking at the spec, and comparing with MIBs in the space, one thing > appeared to be missing. I could not see an equivalent of the route-info Do you mean this (from RFC 1213)? ipRouteInfo OBJECT-TYPE SYNTAX OBJECT IDENTIFIER ACCESS read-only STATUS mandatory DESCRIPTION "A reference to MIB definitions specific to the particular routing protocol which is responsible for this route, as determined by the value specified in the route's ipRouteProto value. If this information is not present, its value should be set to the OBJECT IDENTIFIER { 0 0 }, which is a syntatically valid object identifier, and any conformant implementation of ASN.1 and BER must be able to generate and recognize this value." ::= { ipRouteEntry 13 } I thought it wasn't relevant to a YANG data model. How could it be used in our context? > field used to represent tagging that is carried between routing > protocols by the RIB. As I understand it, route tags are specific to protocols, e.g., OSPF has the 32-bit "External Route Tag" while RIP uses a 16-bit "Route Tag". Thanks, Lada > > Yours, > Joel > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From jmh.direct@joelhalpern.com Wed Jul 25 06:15:42 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 859FC21F852E for ; Wed, 25 Jul 2012 06:15:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.664 X-Spam-Level: X-Spam-Status: No, score=-1.664 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, 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 RDSUftNsURAp for ; Wed, 25 Jul 2012 06:15:41 -0700 (PDT) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id B284521F8540 for ; Wed, 25 Jul 2012 06:15:41 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by morbo.tigertech.net (Postfix) with ESMTP id 1E62655854A for ; Wed, 25 Jul 2012 06:15:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 608221BC9046; Wed, 25 Jul 2012 06:15:40 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from localhost (207.47.24.2.static.nextweb.net [207.47.24.2]) by mailc2.tigertech.net (Postfix) with ESMTPA id 1C3F61BC9043; Wed, 25 Jul 2012 06:15:40 -0700 (PDT) Date: Wed, 25 Jul 2012 06:15:37 -0700 Message-ID: Importance: low From: "Jmh.direct" To: lhotka@nic.cz, jmh@joelhalpern.com, netmod@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--_com.android.email_96345284650572" X-Mailman-Approved-At: Wed, 25 Jul 2012 06:39:32 -0700 Subject: Re: [netmod] NetMod routing 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: Wed, 25 Jul 2012 13:15:42 -0000 ----_com.android.email_96345284650572 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 WWVzLCB0aGF0IGlzIHdoYXQgSSBtZWFudC4gwqBUaG9zZSBhdGUgdXNlZCBvZnRlbiB0byBjYXJ0 eSBpbmZvcm1zdGlvbiBicnR3ZWVuIHJvdXRpbmcgcHJvdG9jb2xzLiDCoEEgbWFuYWdlbWVudCBz dGF0aW9uIG5lZWRzIGF0IGxlYWR0IHRvIGJlIGFibGUgdG8gcmVhZiB0aHN0IGluZm9ybWF0aW9u LiDCoFRoZSBzaW1wbGVzdCBleGFtcGxlIG9mIHdoeSBpcyB3aGVuIHRoYXQgaW5mbyBpcyBpbiBl cnJvciBhbmQgY2F1c2VzIHByb2JsZW1zLgpZb3VycywKSm9lbAoKClNlbnQgZnJvbSBteSBTYW1z dW5nIHNtYXJ0cGhvbmUgb24gQVQmVAoKLS0tLS0tLS0gT3JpZ2luYWwgbWVzc2FnZSAtLS0tLS0t LQpTdWJqZWN0OiBSZTogW25ldG1vZF0gTmV0TW9kIHJvdXRpbmcgY2ZnIApGcm9tOiBMYWRpc2xh diBMaG90a2EgPGxob3RrYUBuaWMuY3o+IApUbzogSm9lbCBIYWxwZXJuIDxqbWhAam9lbGhhbHBl cm4uY29tPixORVRNT0QgV29ya2luZyBHcm91cCA8bmV0bW9kQGlldGYub3JnPiAKQ0M6ICAKCkpv ZWwgSGFscGVybiA8am1oQGpvZWxoYWxwZXJuLmNvbT4gd3JpdGVzOgoKPiBJbiBsb29raW5nIGF0 IHRoZSBzcGVjLCBhbmQgY29tcGFyaW5nIHdpdGggTUlCcyBpbiB0aGUgc3BhY2UsIG9uZSB0aGlu ZyAKPiBhcHBlYXJlZCB0byBiZSBtaXNzaW5nLsKgIEkgY291bGQgbm90IHNlZSBhbiBlcXVpdmFs ZW50IG9mIHRoZSByb3V0ZS1pbmZvCgpEbyB5b3UgbWVhbiB0aGlzIChmcm9tIFJGQyAxMjEzKT8K CsKgIGlwUm91dGVJbmZvIE9CSkVDVC1UWVBFCsKgwqDCoMKgwqAgU1lOVEFYwqAgT0JKRUNUIElE RU5USUZJRVIKwqDCoMKgwqDCoCBBQ0NFU1PCoCByZWFkLW9ubHkKwqDCoMKgwqDCoCBTVEFUVVPC oCBtYW5kYXRvcnkKwqDCoMKgwqDCoCBERVNDUklQVElPTgrCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoCAiQSByZWZlcmVuY2UgdG8gTUlCIGRlZmluaXRpb25zIHNwZWNpZmljIHRvIHRoZQrCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBwYXJ0aWN1bGFyIHJvdXRpbmcgcHJvdG9jb2wgd2hpY2gg aXMgcmVzcG9uc2libGUKwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgZm9yIHRoaXMgcm91dGUs IGFzIGRldGVybWluZWQgYnkgdGhlIHZhbHVlCsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHNw ZWNpZmllZCBpbiB0aGUgcm91dGUncyBpcFJvdXRlUHJvdG8gdmFsdWUuwqAgSWYKwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqAgdGhpcyBpbmZvcm1hdGlvbiBpcyBub3QgcHJlc2VudCwgaXRzIHZh bHVlIHNob3VsZArCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBiZSBzZXQgdG8gdGhlIE9CSkVD VCBJREVOVElGSUVSIHsgMCAwIH0sIHdoaWNoIGlzCsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg IGEgc3ludGF0aWNhbGx5IHZhbGlkIG9iamVjdCBpZGVudGlmaWVyLCBhbmQgYW55CsKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgIGNvbmZvcm1hbnQgaW1wbGVtZW50YXRpb24gb2YgQVNOLjEgYW5k IEJFUiBtdXN0IGJlCsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIGFibGUgdG8gZ2VuZXJhdGUg YW5kIHJlY29nbml6ZSB0aGlzIHZhbHVlLiIKwqDCoMKgwqDCoCA6Oj0geyBpcFJvdXRlRW50cnkg MTMgfQoKSSB0aG91Z2h0IGl0IHdhc24ndCByZWxldmFudCB0byBhIFlBTkcgZGF0YSBtb2RlbC4g SG93IGNvdWxkIGl0IGJlIHVzZWQgaW4gb3VyIGNvbnRleHQ/Cgo+IGZpZWxkIHVzZWQgdG8gcmVw cmVzZW50IHRhZ2dpbmcgdGhhdCBpcyBjYXJyaWVkIGJldHdlZW4gcm91dGluZyAKPiBwcm90b2Nv bHMgYnkgdGhlIFJJQi4KCkFzIEkgdW5kZXJzdGFuZCBpdCwgcm91dGUgdGFncyBhcmUgc3BlY2lm aWMgdG8gcHJvdG9jb2xzLCBlLmcuLCBPU1BGIGhhcyB0aGUgMzItYml0ICJFeHRlcm5hbCBSb3V0 ZSBUYWciIHdoaWxlIFJJUCB1c2VzIGEgMTYtYml0ICJSb3V0ZSBUYWciLgoKVGhhbmtzLCBMYWRh Cgo+Cj4gWW91cnMsCj4gSm9lbAo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fCj4gbmV0bW9kIG1haWxpbmcgbGlzdAo+IG5ldG1vZEBpZXRmLm9yZwo+IGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kCgotLSAKTGFkaXNsYXYg TGhvdGthLCBDWi5OSUMgTGFicwpQR1AgS2V5IElEOiBFNzRFOEMwQwo= ----_com.android.email_96345284650572 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjwvaGVhZD48Ym9keT5ZZXMsIHRoYXQgaXMgd2hhdCBJIG1l YW50LiAmbmJzcDtUaG9zZSBhdGUgdXNlZCBvZnRlbiB0byBjYXJ0eSBpbmZvcm1zdGlvbiBicnR3 ZWVuIHJvdXRpbmcgcHJvdG9jb2xzLiAmbmJzcDtBIG1hbmFnZW1lbnQgc3RhdGlvbiBuZWVkcyBh dCBsZWFkdCB0byBiZSBhYmxlIHRvIHJlYWYgdGhzdCBpbmZvcm1hdGlvbi4gJm5ic3A7VGhlIHNp bXBsZXN0IGV4YW1wbGUgb2Ygd2h5IGlzIHdoZW4gdGhhdCBpbmZvIGlzIGluIGVycm9yIGFuZCBj YXVzZXMgcHJvYmxlbXMuPGRpdj5Zb3Vycyw8L2Rpdj48ZGl2PkpvZWw8YnI+PGJyPjxicj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjg3JSI+U2VudCBmcm9tIG15IFNhbXN1bmcgc21hcnRwaG9uZSBv biBBVCZhbXA7VDwvc3Bhbj4gPC9kaXY+PGJyPjxicj48YnI+LS0tLS0tLS0gT3JpZ2luYWwgbWVz c2FnZSAtLS0tLS0tLTxicj5TdWJqZWN0OiBSZTogW25ldG1vZF0gTmV0TW9kIHJvdXRpbmcgY2Zn IDxicj5Gcm9tOiBMYWRpc2xhdiBMaG90a2EgJmx0O2xob3RrYUBuaWMuY3omZ3Q7IDxicj5Ubzog Sm9lbCBIYWxwZXJuICZsdDtqbWhAam9lbGhhbHBlcm4uY29tJmd0OyxORVRNT0QgV29ya2luZyBH cm91cCAmbHQ7bmV0bW9kQGlldGYub3JnJmd0OyA8YnI+Q0M6ICA8YnI+PGJyPjxicj48ZGl2IHN0 eWxlPSJ3b3JkLWJyZWFrOmJyZWFrLWFsbDsiPkpvZWwgSGFscGVybiAmbHQ7am1oQGpvZWxoYWxw ZXJuLmNvbSZndDsgd3JpdGVzOjxicj48YnI+Jmd0OyBJbiBsb29raW5nIGF0IHRoZSBzcGVjLCBh bmQgY29tcGFyaW5nIHdpdGggTUlCcyBpbiB0aGUgc3BhY2UsIG9uZSB0aGluZyA8YnI+Jmd0OyBh cHBlYXJlZCB0byBiZSBtaXNzaW5nLiZuYnNwOyBJIGNvdWxkIG5vdCBzZWUgYW4gZXF1aXZhbGVu dCBvZiB0aGUgcm91dGUtaW5mbzxicj48YnI+RG8geW91IG1lYW4gdGhpcyAoZnJvbSBSRkMgMTIx Myk/PGJyPjxicj4mbmJzcDsgaXBSb3V0ZUluZm8gT0JKRUNULVRZUEU8YnI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IFNZTlRBWCZuYnNwOyBPQkpFQ1QgSURFTlRJRklFUjxicj4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgQUNDRVNTJm5ic3A7IHJlYWQtb25seTxicj4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgU1RBVFVTJm5ic3A7IG1hbmRhdG9yeTxicj4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgREVTQ1JJUFRJT048YnI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7ICJBIHJlZmVyZW5jZSB0byBNSUIgZGVmaW5pdGlvbnMgc3BlY2lmaWMgdG8gdGhlPGJy PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBwYXJ0aWN1bGFyIHJvdXRpbmcgcHJvdG9jb2wgd2hpY2gg aXMgcmVzcG9uc2libGU8YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGZvciB0aGlzIHJvdXRlLCBh cyBkZXRlcm1pbmVkIGJ5IHRoZSB2YWx1ZTxicj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgc3BlY2lm aWVkIGluIHRoZSByb3V0ZSdzIGlwUm91dGVQcm90byB2YWx1ZS4mbmJzcDsgSWY8YnI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IHRoaXMgaW5mb3JtYXRpb24gaXMgbm90IHByZXNlbnQsIGl0cyB2YWx1 ZSBzaG91bGQ8YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGJlIHNldCB0byB0aGUgT0JKRUNUIElE RU5USUZJRVIgeyAwIDAgfSwgd2hpY2ggaXM8YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGEgc3lu dGF0aWNhbGx5IHZhbGlkIG9iamVjdCBpZGVudGlmaWVyLCBhbmQgYW55PGJyPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBjb25mb3JtYW50IGltcGxlbWVudGF0aW9uIG9mIEFTTi4xIGFuZCBCRVIgbXVz dCBiZTxicj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYWJsZSB0byBnZW5lcmF0ZSBhbmQgcmVjb2du aXplIHRoaXMgdmFsdWUuIjxicj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgOjo9IHsg aXBSb3V0ZUVudHJ5IDEzIH08YnI+PGJyPkkgdGhvdWdodCBpdCB3YXNuJ3QgcmVsZXZhbnQgdG8g YSBZQU5HIGRhdGEgbW9kZWwuIEhvdyBjb3VsZCBpdCBiZSB1c2VkIGluIG91ciBjb250ZXh0Pzxi cj4gPGJyPiZndDsgZmllbGQgdXNlZCB0byByZXByZXNlbnQgdGFnZ2luZyB0aGF0IGlzIGNhcnJp ZWQgYmV0d2VlbiByb3V0aW5nIDxicj4mZ3Q7IHByb3RvY29scyBieSB0aGUgUklCLjxicj48YnI+ QXMgSSB1bmRlcnN0YW5kIGl0LCByb3V0ZSB0YWdzIGFyZSBzcGVjaWZpYyB0byBwcm90b2NvbHMs IGUuZy4sIE9TUEYgaGFzIHRoZSAzMi1iaXQgIkV4dGVybmFsIFJvdXRlIFRhZyIgd2hpbGUgUklQ IHVzZXMgYSAxNi1iaXQgIlJvdXRlIFRhZyIuPGJyPjxicj5UaGFua3MsIExhZGE8YnI+PGJyPiZn dDs8YnI+Jmd0OyBZb3Vycyw8YnI+Jmd0OyBKb2VsPGJyPiZndDsgX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+Jmd0OyBuZXRtb2QgbWFpbGluZyBsaXN0 PGJyPiZndDsgbmV0bW9kQGlldGYub3JnPGJyPiZndDsgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9uZXRtb2Q8YnI+PGJyPi0tIDxicj5MYWRpc2xhdiBMaG90a2EsIENaLk5J QyBMYWJzPGJyPlBHUCBLZXkgSUQ6IEU3NEU4QzBDPGJyPjwvZGl2PiA8L2JvZHk+ ----_com.android.email_96345284650572-- From jernej.tuljak@mg-soft.si Wed Jul 25 07:04:23 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C81C21F8582 for ; Wed, 25 Jul 2012 07:04:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.413 X-Spam-Level: X-Spam-Status: No, score=-2.413 tagged_above=-999 required=5 tests=[AWL=0.186, 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 MuE+rTLHi7kT for ; Wed, 25 Jul 2012 07:04:22 -0700 (PDT) Received: from gate.mg-soft.si (gate.mg-soft.si [212.30.73.66]) by ietfa.amsl.com (Postfix) with ESMTP id 7263121F8568 for ; Wed, 25 Jul 2012 07:04:21 -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 q6PE4JPx002240; Wed, 25 Jul 2012 16:04:19 +0200 Message-ID: <500FFCD5.7040704@mg-soft.com> Date: Wed, 25 Jul 2012 16:04:05 +0200 From: Jernej Tuljak User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Jernej Tuljak References: <20120725081713.GA50389@elstar.local> <500FB5B8.1010001@mg-soft.com> In-Reply-To: <500FB5B8.1010001@mg-soft.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] RFC 6020 errata 3288, 3289, 3290 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, 25 Jul 2012 14:04:23 -0000 Dne 25.7.2012 11:00, piše Jernej Tuljak: > Dne 25.7.2012 10:17, piše Juergen Schoenwaelder: >> Hi, >> >> Martin has posted errata 3288, 3289, 3290: >> >> http://www.rfc-editor.org/errata_search.php?rfc=6020 >> >> Can people review and comment? Is there agreement that these are valid >> technical errata? >> >> Speaking as technical contributor, it seems 3289 and 3290 are >> relatively clear cut fixes. >> >> I am not so sure about 3288, in particular the augment case and the >> meaningful usage of (multiple) augments in a uses substatement. I do >> note that the errata brings the table in section 7.12.1 inline with >> the grammar of uses-stmt. > > I agree with Martin. Both augment and refine statements under a uses > statement should have a cardinality of 0..n. Imagine a grouping with > multiple container statements. A cardinality of 0..1 would mean that > the user may choose to augment only one of them during uses expansion. > What if the requirement is to add statements to two of such > containers? Same goes for refine. > Note that this is the only way for a grouping or rather it's content > to get augmented. And I can't imagine groupings with multiple subtrees > being uncommon. Correction. You could just use a toplevel augment, but I think it's good to be able to do it from where the uses is. Perhaps it makes some cases more readable even though it's redundant. module uses-augment { namespace "http://ns.example.com/uses-augment"; prefix ua; revision 2012-07-25; grouping common { container one; container two; } container stuff { uses common { augment "two" { leaf leafy-leaf { type int32; } } augment "one" { leaf leafy-leaf { type int32; } } } } container redundant { uses common; } augment "/ua:redundant/ua:one" { leaf leafy-leaf { type int32; } } augment "/ua:redundant/ua:two" { leaf leafy-leaf { type int32; } } } Jernej > > From my perspective these are only typos. YANG grammar confirms it. > > Jernej > >> >> /js >> > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From lhotka@nic.cz Wed Jul 25 07:06:10 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49C3621F85B4 for ; Wed, 25 Jul 2012 07:06:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.637 X-Spam-Level: X-Spam-Status: No, score=-1.637 tagged_above=-999 required=5 tests=[AWL=-0.238, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, J_CHICKENPOX_36=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 8Yl6FuFswrow for ; Wed, 25 Jul 2012 07:06:09 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 6DEE221F8596 for ; Wed, 25 Jul 2012 07:06:09 -0700 (PDT) Received: from [172.29.2.201] (unknown [77.48.224.120]) by mail.nic.cz (Postfix) with ESMTPSA id 427D913FAA1; Wed, 25 Jul 2012 16:06:08 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1343225168; bh=AczVVJqx2XNPTp5uk53FuweBAFrHbU7KA5fmag0fqGw=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=k1Ru/yvf0nMMR3+rm/h3EO/ClkZpTfAITWyle5NY1RtW9bLuoufYy0P5OBHesx9oC Wj5g6Kn+IIfB8g2tUonG8JTTPxbUx0t2JqUUQm5y26hFkpDfig7V90aB6b2P9TCjTJ 7STzYcXYPhp5e8aXfs1k+1ul19ovukZSSjaBZbLQ= Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Ladislav Lhotka In-Reply-To: Date: Wed, 25 Jul 2012 16:06:07 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <942370E6-E33E-43A9-A16F-6C8DF0840AAE@nic.cz> References: To: "Jmh.direct" X-Mailer: Apple Mail (2.1278) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] NetMod routing 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: Wed, 25 Jul 2012 14:06:10 -0000 On Jul 25, 2012, at 3:15 PM, Jmh.direct wrote: > Yes, that is what I meant. Those ate used often to carty informstion = brtween routing protocols. A management station needs at leadt to be = able to reaf thst information. The simplest example of why is when that = info is in error and causes problems. I am not able to find any examples of how this mechanism is used in = practice and what value that field may contain - other than the default = zeroDotZero. What can be a typical non-default value?=20 In YANG terms, the "route-info" leaf would have the = "instance-identifier" type, right?=20 Lada > Yours, > Joel >=20 >=20 > Sent from my Samsung smartphone on AT&T >=20 >=20 >=20 > -------- Original message -------- > Subject: Re: [netmod] NetMod routing cfg=20 > From: Ladislav Lhotka =20 > To: Joel Halpern ,NETMOD Working Group = =20 > CC:=20 >=20 >=20 > Joel Halpern writes: >=20 > > In looking at the spec, and comparing with MIBs in the space, one = thing=20 > > appeared to be missing. I could not see an equivalent of the = route-info >=20 > Do you mean this (from RFC 1213)? >=20 > ipRouteInfo OBJECT-TYPE > SYNTAX OBJECT IDENTIFIER > ACCESS read-only > STATUS mandatory > DESCRIPTION > "A reference to MIB definitions specific to the > particular routing protocol which is responsible > for this route, as determined by the value > specified in the route's ipRouteProto value. If > this information is not present, its value should > be set to the OBJECT IDENTIFIER { 0 0 }, which is > a syntatically valid object identifier, and any > conformant implementation of ASN.1 and BER must be > able to generate and recognize this value." > ::=3D { ipRouteEntry 13 } >=20 > I thought it wasn't relevant to a YANG data model. How could it be = used in our context? >=20 > > field used to represent tagging that is carried between routing=20 > > protocols by the RIB. >=20 > As I understand it, route tags are specific to protocols, e.g., OSPF = has the 32-bit "External Route Tag" while RIP uses a 16-bit "Route Tag". >=20 > Thanks, Lada >=20 > > > > Yours, > > Joel > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod >=20 > --=20 > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From andy@yumaworks.com Wed Jul 25 07:16:18 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAA6621F85D1 for ; Wed, 25 Jul 2012 07:16:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.958 X-Spam-Level: X-Spam-Status: No, score=-2.958 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 4ymmOHKrH6fO for ; Wed, 25 Jul 2012 07:16:17 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4ABBC21F8585 for ; Wed, 25 Jul 2012 07:16:10 -0700 (PDT) Received: by lagv3 with SMTP id v3so610616lag.31 for ; Wed, 25 Jul 2012 07:16:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:content-type:x-gm-message-state; bh=bAQ1sKrk6eWuwbSRWMSQfGybJPKriP8e3jX2HpdKN6A=; b=mBqd/k40dx4saL564zfsZJItFa5nCro4VtV+PwAIOPFwek42PWh0XTi8UFwY5IrWir HE/B9i3c9yh/iPGtWV+uK37lD1MeLuorGWKNMn0mWDcpSev2FnPFmkYUUwXdtS6i/nvS tgdT1F/4fb2KI5/l6tlYzNqsVF3x7BcIHFmUx0dm1/KvJCNKBVsAn02QDvxwRkjwz2nU JGX1KEblsO0IaQYbDUR/TYShoDa+y/N4KvjLPBy0aFzzqqbZfUsQGa0WESdzhVYRWXkB j5rCmbw0f+RT8X1z6dT8qxRaLcsvgLFSn+8b31dpjBZuxsxyRf3lzR5S4KjhBKj35EqN MZDw== MIME-Version: 1.0 Received: by 10.152.106.233 with SMTP id gx9mr26043897lab.48.1343225769172; Wed, 25 Jul 2012 07:16:09 -0700 (PDT) Received: by 10.114.19.72 with HTTP; Wed, 25 Jul 2012 07:16:09 -0700 (PDT) X-Originating-IP: [75.84.168.164] In-Reply-To: <20120725081713.GA50389@elstar.local> References: <20120725081713.GA50389@elstar.local> Date: Wed, 25 Jul 2012 07:16:09 -0700 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , netmod@ietf.org Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQkIjbuFYDZchfRXfZjdF26IjykuwQ81+w3Zzd/pZNit/XRAJfLNotejl4zd54/1Ad8Tt1Uk Subject: Re: [netmod] RFC 6020 errata 3288, 3289, 3290 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, 25 Jul 2012 14:16:19 -0000 On Wed, Jul 25, 2012 at 1:17 AM, Juergen Schoenwaelder wrote: > Hi, > > Martin has posted errata 3288, 3289, 3290: > > http://www.rfc-editor.org/errata_search.php?rfc=6020 > > Can people review and comment? Is there agreement that these are valid > technical errata? > It looks fine to me. I think yuma already implements all these corrections. Multiple augment-stmts for the same target is not that hard to implement. You have to do that anyway because a top-level augment from somewhere else can also add nodes. > Speaking as technical contributor, it seems 3289 and 3290 are > relatively clear cut fixes. > > I am not so sure about 3288, in particular the augment case and the > meaningful usage of (multiple) augments in a uses substatement. I do > note that the errata brings the table in section 7.12.1 inline with > the grammar of uses-stmt. > > /js Andy From andy@yumaworks.com Wed Jul 25 07:28:07 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EB9B21F85A5 for ; Wed, 25 Jul 2012 07:28:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.958 X-Spam-Level: X-Spam-Status: No, score=-2.958 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 x7XE9iw6WcRB for ; Wed, 25 Jul 2012 07:28:06 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7D4C121F84FF for ; Wed, 25 Jul 2012 07:28:06 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so731465lbb.31 for ; Wed, 25 Jul 2012 07:28:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=OsGVPEvPM+LnABA2IAbUEKlRUHkss7+rnsqT3OeS12Q=; b=kNRuF2y+eT5AhH094gpM7c7hbr72PJhdxpw5Lf64fIecqwmyiNqq+uUkbzV8R4VqDc jMmmBBMVGD5S/kA1oZbEnsEQovhKwubRBBwbjvtuY0mCm4xMP78oWpCT2qNKnvxNz5Vs QYWZE2X3xI8uTSq/Oisdn9Q/Vl4zZAp0oPWFOGQfAYdtr5mCsQAoD224UChEYVUHVXDm rxQ5i/H8zXtJ+5tAQZF9D++pgeMOinKDC9perDbqnIQY3EbmFlypocxHTZPrnhwWm9er mitN5NKYgVmsnvmoSL/MRoYpJEIL4ujpk9k3wsDxG9ZlMaVNwGtmumfTnRceHSZk9Fqw cAVw== MIME-Version: 1.0 Received: by 10.152.131.68 with SMTP id ok4mr25920299lab.47.1343226485382; Wed, 25 Jul 2012 07:28:05 -0700 (PDT) Received: by 10.114.19.72 with HTTP; Wed, 25 Jul 2012 07:28:05 -0700 (PDT) X-Originating-IP: [75.84.168.164] In-Reply-To: <500FFCD5.7040704@mg-soft.com> References: <20120725081713.GA50389@elstar.local> <500FB5B8.1010001@mg-soft.com> <500FFCD5.7040704@mg-soft.com> Date: Wed, 25 Jul 2012 07:28:05 -0700 Message-ID: From: Andy Bierman To: Jernej Tuljak Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQlysnoOMSxmMwuBmSmQsgMIMv4Au8n1yZ1GcpyG2pu380ll8oOgILU3bHxqaTxIEx1ca/1N Cc: netmod@ietf.org Subject: Re: [netmod] RFC 6020 errata 3288, 3289, 3290 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, 25 Jul 2012 14:28:07 -0000 ... You don't even need an example of multiple augments this complicated. Just add the when-stmt, that's complicated enough :-) container foo { uses common { augment one { when "../two/some-leaf = 4"; leaf mode4 { type string; } } augment one { leaf leafy-leaf { type string; } } } } > module uses-augment { > namespace "http://ns.example.com/uses-augment"; > prefix ua; > revision 2012-07-25; > grouping common { > container one; > container two; > } > container stuff { > uses common { > augment "two" { > leaf leafy-leaf { > type int32; > } > } > augment "one" { > leaf leafy-leaf { > type int32; > } > } > } > } > container redundant { > uses common; > } > augment "/ua:redundant/ua:one" { > leaf leafy-leaf { > type int32; > } > } > augment "/ua:redundant/ua:two" { > leaf leafy-leaf { > type int32; > } > } > } > > Jernej > >> >> From my perspective these are only typos. YANG grammar confirms it. >> >> Jernej >> >>> >>> /js >>> Andy From j.schoenwaelder@jacobs-university.de Wed Jul 25 07:45:03 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A0F621F847A for ; Wed, 25 Jul 2012 07:45:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.202 X-Spam-Level: X-Spam-Status: No, score=-103.202 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JLVUglOtElQY for ; Wed, 25 Jul 2012 07:45: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 A98C421F849B for ; Wed, 25 Jul 2012 07:45:02 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9D06920BED; Wed, 25 Jul 2012 16:45:01 +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 7AMGrXfLTzI8; Wed, 25 Jul 2012 16:45: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 B028C20BF8; Wed, 25 Jul 2012 16:45:00 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id EE87220E8B85; Wed, 25 Jul 2012 16:44:58 +0200 (CEST) Date: Wed, 25 Jul 2012 16:44:58 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20120725144458.GA5437@elstar.local> Mail-Followup-To: Andy Bierman , Jernej Tuljak , netmod@ietf.org References: <20120725081713.GA50389@elstar.local> <500FB5B8.1010001@mg-soft.com> <500FFCD5.7040704@mg-soft.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] RFC 6020 errata 3288, 3289, 3290 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, 25 Jul 2012 14:45:03 -0000 On Wed, Jul 25, 2012 at 07:28:05AM -0700, Andy Bierman wrote: > ... > > You don't even need an example of multiple augments > this complicated. Just add the when-stmt, that's > complicated enough :-) > > container foo { > uses common { > augment one { > when "../two/some-leaf = 4"; > leaf mode4 { type string; } > } > augment one { > leaf leafy-leaf { type string; } > } > } > } > Yep, I have been confused. Speaking as technical contributor, it seems all three erratas are valid. /js -- 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 Wed Jul 25 08:44:23 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B12721F865E for ; Wed, 25 Jul 2012 08:44:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.065 X-Spam-Level: X-Spam-Status: No, score=-101.065 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_23=0.6, J_CHICKENPOX_36=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 VuiAeSizGs7C for ; Wed, 25 Jul 2012 08:44:23 -0700 (PDT) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 2495321F864C for ; Wed, 25 Jul 2012 08:44:23 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by morbo.tigertech.net (Postfix) with ESMTP id AE40755812C for ; Wed, 25 Jul 2012 08:44:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 2C4161BCC0FB; Wed, 25 Jul 2012 08:44:22 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [128.107.30.76] (unknown [128.107.30.76]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 042A31BCC0F6; Wed, 25 Jul 2012 08:44:21 -0700 (PDT) Message-ID: <50101453.1010405@joelhalpern.com> Date: Wed, 25 Jul 2012 11:44:19 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Ladislav Lhotka References: <942370E6-E33E-43A9-A16F-6C8DF0840AAE@nic.cz> In-Reply-To: <942370E6-E33E-43A9-A16F-6C8DF0840AAE@nic.cz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] NetMod routing 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: Wed, 25 Jul 2012 15:44:23 -0000 The basic model is that routing protocol one, when adding information to the RIB includes tag. Routing protocol 2 carries that route information, with the tag. In another router, the process is reversed so that the tag is preserved across the domain. There are also other cases. The point is that there were good reasons why the MIB included visibility to this information. As such, it seems to me pretty odd for NetMod to unilaterally decide that it is NOT useful information. Yours, Joel On 7/25/2012 10:06 AM, Ladislav Lhotka wrote: > > On Jul 25, 2012, at 3:15 PM, Jmh.direct wrote: > >> Yes, that is what I meant. Those ate used often to carty informstion brtween routing protocols. A management station needs at leadt to be able to reaf thst information. The simplest example of why is when that info is in error and causes problems. > > I am not able to find any examples of how this mechanism is used in practice and what value that field may contain - other than the default zeroDotZero. What can be a typical non-default value? > > In YANG terms, the "route-info" leaf would have the "instance-identifier" type, right? > > Lada > >> Yours, >> Joel >> >> >> Sent from my Samsung smartphone on AT&T >> >> >> >> -------- Original message -------- >> Subject: Re: [netmod] NetMod routing cfg >> From: Ladislav Lhotka >> To: Joel Halpern ,NETMOD Working Group >> CC: >> >> >> Joel Halpern writes: >> >>> In looking at the spec, and comparing with MIBs in the space, one thing >>> appeared to be missing. I could not see an equivalent of the route-info >> >> Do you mean this (from RFC 1213)? >> >> ipRouteInfo OBJECT-TYPE >> SYNTAX OBJECT IDENTIFIER >> ACCESS read-only >> STATUS mandatory >> DESCRIPTION >> "A reference to MIB definitions specific to the >> particular routing protocol which is responsible >> for this route, as determined by the value >> specified in the route's ipRouteProto value. If >> this information is not present, its value should >> be set to the OBJECT IDENTIFIER { 0 0 }, which is >> a syntatically valid object identifier, and any >> conformant implementation of ASN.1 and BER must be >> able to generate and recognize this value." >> ::= { ipRouteEntry 13 } >> >> I thought it wasn't relevant to a YANG data model. How could it be used in our context? >> >>> field used to represent tagging that is carried between routing >>> protocols by the RIB. >> >> As I understand it, route tags are specific to protocols, e.g., OSPF has the 32-bit "External Route Tag" while RIP uses a 16-bit "Route Tag". >> >> Thanks, Lada >> >>> >>> Yours, >>> Joel >>> _______________________________________________ >>> 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 Wed Jul 25 09:07:28 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1A8321F86DA for ; Wed, 25 Jul 2012 09:07:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.929 X-Spam-Level: X-Spam-Status: No, score=-1.929 tagged_above=-999 required=5 tests=[AWL=0.070, 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 vaA1r-nUIuTo for ; Wed, 25 Jul 2012 09:07:28 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 24A0321F86D9 for ; Wed, 25 Jul 2012 09:07:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 1C0FC54060E for ; Wed, 25 Jul 2012 18:07:26 +0200 (CEST) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NRbPVPG1SVwL for ; Wed, 25 Jul 2012 18:07:18 +0200 (CEST) Received: from localhost (birdie.lhotkovi.cz [172.29.2.201]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 12121540609 for ; Wed, 25 Jul 2012 18:07:17 +0200 (CEST) From: Ladislav Lhotka To: netmod@ietf.org In-Reply-To: <20120725081713.GA50389@elstar.local> References: <20120725081713.GA50389@elstar.local> User-Agent: Notmuch/0.13.2+77~g39beeb2 (http://notmuchmail.org) Emacs/23.3.50.1 (i386-apple-darwin9.8.0) Mail-Followup-To: netmod@ietf.org Date: Wed, 25 Jul 2012 18:07:16 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [netmod] RFC 6020 errata 3288, 3289, 3290 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, 25 Jul 2012 16:07:29 -0000 Juergen Schoenwaelder writes: > Hi, > > Martin has posted errata 3288, 3289, 3290: > > http://www.rfc-editor.org/errata_search.php?rfc=6020 > > Can people review and comment? Is there agreement that these are valid > technical errata? I agree with all three changes. I also checked that 3288 does not affect the DSDL mapping procedure from RFC 6110. Lada > > Speaking as technical contributor, it seems 3289 and 3290 are > relatively clear cut fixes. > > I am not so sure about 3288, in particular the augment case and the > meaningful usage of (multiple) augments in a uses substatement. I do > note that the errata brings the table in section 7.12.1 inline with > the grammar of uses-stmt. > > /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 Wed Jul 25 14:21:47 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED75C21F865D for ; Wed, 25 Jul 2012 14:21:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.632 X-Spam-Level: X-Spam-Status: No, score=-1.632 tagged_above=-999 required=5 tests=[AWL=-0.233, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, J_CHICKENPOX_36=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 mn6ciDWObxy2 for ; Wed, 25 Jul 2012 14:21:47 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id DF6BC21F864F for ; Wed, 25 Jul 2012 14:21:46 -0700 (PDT) Received: from [172.29.2.201] (unknown [77.48.224.120]) by mail.nic.cz (Postfix) with ESMTPSA id B80AB13F652; Wed, 25 Jul 2012 23:21:43 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1343251303; bh=xoKJBE3+L1UQwtNpWlrNkldHT56gwCDLuLHTbNaRpTM=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=blK8+EJfI4J425sstlg0FltuMWGc89X9P3oefsaoIyk3f0GGUkm1K6Tf30TCIRvpE K04P1vDhX/arf3xTuVgm6uB9y1P/yCWnpKYzCTrvsWgBQr+05YinLZ5IwdfKRUmWgN PDzcSUCzTZKxgmju8pGCEVKUM6NZKhcEacRRmj1E= Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Ladislav Lhotka In-Reply-To: <50101453.1010405@joelhalpern.com> Date: Wed, 25 Jul 2012 23:21:43 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <942370E6-E33E-43A9-A16F-6C8DF0840AAE@nic.cz> <50101453.1010405@joelhalpern.com> To: "Joel M. Halpern" X-Mailer: Apple Mail (2.1278) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] NetMod routing 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: Wed, 25 Jul 2012 21:21:48 -0000 On Jul 25, 2012, at 5:44 PM, Joel M. Halpern wrote: > The basic model is that routing protocol one, when adding information = to the RIB includes tag. Routing protocol 2 carries that route = information, with the tag. In another router, the process is reversed = so that the tag is preserved across the domain. There are also other = cases. In my opinion, this is the role for route tags that are defined by some = routing protocols and carried in their PDUs. I assume data models for = such routing protocols will augment the set of route attributes with = these tags and define means for configuring them, and data models for = route filters will define means for using the tags when manipulating = routes. I must admit I don't get the connection between route tags and "a = reference to MIB definitions specific to the particular routing = protocol". Anyway, RFC 1213 also says in Sec. 3.7 that "ipRouteInfo" is = IP routing protocol-specific. =20 >=20 > The point is that there were good reasons why the MIB included = visibility to this information. As such, it seems to me pretty odd for = NetMod to unilaterally decide that it is NOT useful information. There was no such decision, the truth is that this issue has never been = raised before. In my personal view, this parameter can be left to be = defined by routing protocol data models, analogically to the five route = metrics that are also defined by RFC1213-MIB, essentially as = placeholders to be adopted by individual routing protocols. I believe these generic placeholders are not needed in YANG. Thanks, Lada >=20 > Yours, > Joel >=20 > On 7/25/2012 10:06 AM, Ladislav Lhotka wrote: >>=20 >> On Jul 25, 2012, at 3:15 PM, Jmh.direct wrote: >>=20 >>> Yes, that is what I meant. Those ate used often to carty = informstion brtween routing protocols. A management station needs at = leadt to be able to reaf thst information. The simplest example of why = is when that info is in error and causes problems. >>=20 >> I am not able to find any examples of how this mechanism is used in = practice and what value that field may contain - other than the default = zeroDotZero. What can be a typical non-default value? >>=20 >> In YANG terms, the "route-info" leaf would have the = "instance-identifier" type, right? >>=20 >> Lada >>=20 >>> Yours, >>> Joel >>>=20 >>>=20 >>> Sent from my Samsung smartphone on AT&T >>>=20 >>>=20 >>>=20 >>> -------- Original message -------- >>> Subject: Re: [netmod] NetMod routing cfg >>> From: Ladislav Lhotka >>> To: Joel Halpern ,NETMOD Working Group = >>> CC: >>>=20 >>>=20 >>> Joel Halpern writes: >>>=20 >>>> In looking at the spec, and comparing with MIBs in the space, one = thing >>>> appeared to be missing. I could not see an equivalent of the = route-info >>>=20 >>> Do you mean this (from RFC 1213)? >>>=20 >>> ipRouteInfo OBJECT-TYPE >>> SYNTAX OBJECT IDENTIFIER >>> ACCESS read-only >>> STATUS mandatory >>> DESCRIPTION >>> "A reference to MIB definitions specific to the >>> particular routing protocol which is responsible >>> for this route, as determined by the value >>> specified in the route's ipRouteProto value. If >>> this information is not present, its value should >>> be set to the OBJECT IDENTIFIER { 0 0 }, which is >>> a syntatically valid object identifier, and any >>> conformant implementation of ASN.1 and BER must be >>> able to generate and recognize this value." >>> ::=3D { ipRouteEntry 13 } >>>=20 >>> I thought it wasn't relevant to a YANG data model. How could it be = used in our context? >>>=20 >>>> field used to represent tagging that is carried between routing >>>> protocols by the RIB. >>>=20 >>> As I understand it, route tags are specific to protocols, e.g., OSPF = has the 32-bit "External Route Tag" while RIP uses a 16-bit "Route Tag". >>>=20 >>> Thanks, Lada >>>=20 >>>>=20 >>>> Yours, >>>> Joel >>>> _______________________________________________ >>>> netmod mailing list >>>> netmod@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netmod >>>=20 >>> -- >>> Ladislav Lhotka, CZ.NIC Labs >>> PGP Key ID: E74E8C0C >>=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 jmh@joelhalpern.com Wed Jul 25 14:28:46 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3109E11E807F for ; Wed, 25 Jul 2012 14:28:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.598 X-Spam-Level: X-Spam-Status: No, score=-101.598 tagged_above=-999 required=5 tests=[AWL=-0.533, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_23=0.6, J_CHICKENPOX_36=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 ZdJvdzFWUyd4 for ; Wed, 25 Jul 2012 14:28:45 -0700 (PDT) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 94E3811E8073 for ; Wed, 25 Jul 2012 14:28:45 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by morbo.tigertech.net (Postfix) with ESMTP id 74D9E557F49 for ; Wed, 25 Jul 2012 14:28:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id D6D2C1C9E22; Wed, 25 Jul 2012 14:28:43 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [128.107.30.76] (unknown [128.107.30.76]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id A32A41C9E20; Wed, 25 Jul 2012 14:28:43 -0700 (PDT) Message-ID: <50106507.2030904@joelhalpern.com> Date: Wed, 25 Jul 2012 17:28:39 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Ladislav Lhotka References: <942370E6-E33E-43A9-A16F-6C8DF0840AAE@nic.cz> <50101453.1010405@joelhalpern.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] NetMod routing 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: Wed, 25 Jul 2012 21:28:46 -0000 The whole point is that this RIB information is used to carry information between two instances of routing protocols (usually distinct protocols). If there are problems with the information not being propagated properly, the network administrator will need to be able to check each step of the process. That requires the ability to read this information from the RIB. If you have specific evidence that this management information is no longer needed, I am willing to listen. The information I have seen suggests it is still useful. Yours, Joel On 7/25/2012 5:21 PM, Ladislav Lhotka wrote: > > On Jul 25, 2012, at 5:44 PM, Joel M. Halpern wrote: > >> The basic model is that routing protocol one, when adding information to the RIB includes tag. Routing protocol 2 carries that route information, with the tag. In another router, the process is reversed so that the tag is preserved across the domain. There are also other cases. > > In my opinion, this is the role for route tags that are defined by some routing protocols and carried in their PDUs. I assume data models for such routing protocols will augment the set of route attributes with these tags and define means for configuring them, and data models for route filters will define means for using the tags when manipulating routes. > > I must admit I don't get the connection between route tags and "a reference to MIB definitions specific to the particular routing protocol". Anyway, RFC 1213 also says in Sec. 3.7 that "ipRouteInfo" is IP routing protocol-specific. > >> >> The point is that there were good reasons why the MIB included visibility to this information. As such, it seems to me pretty odd for NetMod to unilaterally decide that it is NOT useful information. > > There was no such decision, the truth is that this issue has never been raised before. In my personal view, this parameter can be left to be defined by routing protocol data models, analogically to the five route metrics that are also defined by RFC1213-MIB, essentially as placeholders to be adopted by individual routing protocols. > > I believe these generic placeholders are not needed in YANG. > > Thanks, Lada > >> >> Yours, >> Joel >> >> On 7/25/2012 10:06 AM, Ladislav Lhotka wrote: >>> >>> On Jul 25, 2012, at 3:15 PM, Jmh.direct wrote: >>> >>>> Yes, that is what I meant. Those ate used often to carty informstion brtween routing protocols. A management station needs at leadt to be able to reaf thst information. The simplest example of why is when that info is in error and causes problems. >>> >>> I am not able to find any examples of how this mechanism is used in practice and what value that field may contain - other than the default zeroDotZero. What can be a typical non-default value? >>> >>> In YANG terms, the "route-info" leaf would have the "instance-identifier" type, right? >>> >>> Lada >>> >>>> Yours, >>>> Joel >>>> >>>> >>>> Sent from my Samsung smartphone on AT&T >>>> >>>> >>>> >>>> -------- Original message -------- >>>> Subject: Re: [netmod] NetMod routing cfg >>>> From: Ladislav Lhotka >>>> To: Joel Halpern ,NETMOD Working Group >>>> CC: >>>> >>>> >>>> Joel Halpern writes: >>>> >>>>> In looking at the spec, and comparing with MIBs in the space, one thing >>>>> appeared to be missing. I could not see an equivalent of the route-info >>>> >>>> Do you mean this (from RFC 1213)? >>>> >>>> ipRouteInfo OBJECT-TYPE >>>> SYNTAX OBJECT IDENTIFIER >>>> ACCESS read-only >>>> STATUS mandatory >>>> DESCRIPTION >>>> "A reference to MIB definitions specific to the >>>> particular routing protocol which is responsible >>>> for this route, as determined by the value >>>> specified in the route's ipRouteProto value. If >>>> this information is not present, its value should >>>> be set to the OBJECT IDENTIFIER { 0 0 }, which is >>>> a syntatically valid object identifier, and any >>>> conformant implementation of ASN.1 and BER must be >>>> able to generate and recognize this value." >>>> ::= { ipRouteEntry 13 } >>>> >>>> I thought it wasn't relevant to a YANG data model. How could it be used in our context? >>>> >>>>> field used to represent tagging that is carried between routing >>>>> protocols by the RIB. >>>> >>>> As I understand it, route tags are specific to protocols, e.g., OSPF has the 32-bit "External Route Tag" while RIP uses a 16-bit "Route Tag". >>>> >>>> Thanks, Lada >>>> >>>>> >>>>> Yours, >>>>> Joel >>>>> _______________________________________________ >>>>> 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 >>> >>> >>> >>> >>> > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > From lhotka@nic.cz Thu Jul 26 00:59:23 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5299621F86D5 for ; Thu, 26 Jul 2012 00:59:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.625 X-Spam-Level: X-Spam-Status: No, score=-1.625 tagged_above=-999 required=5 tests=[AWL=-0.226, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, J_CHICKENPOX_36=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 rLl5rqm0nHHq for ; Thu, 26 Jul 2012 00:59:22 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 2E22021F86BD for ; Thu, 26 Jul 2012 00:59:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id E3C5354033D; Thu, 26 Jul 2012 09:59:19 +0200 (CEST) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3bCd05ufHAyY; Thu, 26 Jul 2012 09:59:15 +0200 (CEST) Received: from localhost (birdie.lhotkovi.cz [172.29.2.201]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 3BF6554013B; Thu, 26 Jul 2012 09:59:14 +0200 (CEST) From: Ladislav Lhotka To: "Joel M. Halpern" In-Reply-To: <50106507.2030904@joelhalpern.com> References: <942370E6-E33E-43A9-A16F-6C8DF0840AAE@nic.cz> <50101453.1010405@joelhalpern.com> <50106507.2030904@joelhalpern.com> User-Agent: Notmuch/0.13.2+77~g39beeb2 (http://notmuchmail.org) Emacs/23.3.50.1 (i386-apple-darwin9.8.0) Mail-Followup-To: "Joel M. Halpern" , netmod@ietf.org Date: Thu, 26 Jul 2012 09:59:14 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: netmod@ietf.org Subject: Re: [netmod] NetMod routing 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: Thu, 26 Jul 2012 07:59:23 -0000 "Joel M. Halpern" writes: > The whole point is that this RIB information is used to carry > information between two instances of routing protocols (usually distinct > protocols). If there are problems with the information not being > propagated properly, the network administrator will need to be able to > check each step of the process. That requires the ability to read this > information from the RIB. Every protocol may create such information on its own (and in its own namespace), be it metrics, tags or whatever. If this information is passed between two instances of different protocols (more precisely between routing tables connected to either instance), then a reasonable default behaviour is to leave this information untouched. > > If you have specific evidence that this management information is no > longer needed, I am willing to listen. The information I have seen > suggests it is still useful. I am not saying this information is not needed, only that it is not necessary to pre-allocate the slot in the generic routing module, if the contents is to be generated in a specific way by routing protocols. Maybe the difference lies in the fact that "ipRouteTable" is modelled as a table (one size fits all) in the MIB while the contents of each "route" entry in the YANG data model may be (partly) protocol-specific. The "ipRouteInfo" field is intended (I assume) as a pointer to an additional object containing the protocol-specific information. In YANG, this information can be put directly to the particular "route" entry. The example RIP module in Appendix A adds its own "metric" and "tag" nodes, which are however valid only if "source-protocol" equals to "rip". Lada > > Yours, > Joel > > On 7/25/2012 5:21 PM, Ladislav Lhotka wrote: >> >> On Jul 25, 2012, at 5:44 PM, Joel M. Halpern wrote: >> >>> The basic model is that routing protocol one, when adding information to the RIB includes tag. Routing protocol 2 carries that route information, with the tag. In another router, the process is reversed so that the tag is preserved across the domain. There are also other cases. >> >> In my opinion, this is the role for route tags that are defined by some routing protocols and carried in their PDUs. I assume data models for such routing protocols will augment the set of route attributes with these tags and define means for configuring them, and data models for route filters will define means for using the tags when manipulating routes. >> >> I must admit I don't get the connection between route tags and "a reference to MIB definitions specific to the particular routing protocol". Anyway, RFC 1213 also says in Sec. 3.7 that "ipRouteInfo" is IP routing protocol-specific. >> >>> >>> The point is that there were good reasons why the MIB included visibility to this information. As such, it seems to me pretty odd for NetMod to unilaterally decide that it is NOT useful information. >> >> There was no such decision, the truth is that this issue has never been raised before. In my personal view, this parameter can be left to be defined by routing protocol data models, analogically to the five route metrics that are also defined by RFC1213-MIB, essentially as placeholders to be adopted by individual routing protocols. >> >> I believe these generic placeholders are not needed in YANG. >> >> Thanks, Lada >> >>> >>> Yours, >>> Joel >>> >>> On 7/25/2012 10:06 AM, Ladislav Lhotka wrote: >>>> >>>> On Jul 25, 2012, at 3:15 PM, Jmh.direct wrote: >>>> >>>>> Yes, that is what I meant. Those ate used often to carty informstion brtween routing protocols. A management station needs at leadt to be able to reaf thst information. The simplest example of why is when that info is in error and causes problems. >>>> >>>> I am not able to find any examples of how this mechanism is used in practice and what value that field may contain - other than the default zeroDotZero. What can be a typical non-default value? >>>> >>>> In YANG terms, the "route-info" leaf would have the "instance-identifier" type, right? >>>> >>>> Lada >>>> >>>>> Yours, >>>>> Joel >>>>> >>>>> >>>>> Sent from my Samsung smartphone on AT&T >>>>> >>>>> >>>>> >>>>> -------- Original message -------- >>>>> Subject: Re: [netmod] NetMod routing cfg >>>>> From: Ladislav Lhotka >>>>> To: Joel Halpern ,NETMOD Working Group >>>>> CC: >>>>> >>>>> >>>>> Joel Halpern writes: >>>>> >>>>>> In looking at the spec, and comparing with MIBs in the space, one thing >>>>>> appeared to be missing. I could not see an equivalent of the route-info >>>>> >>>>> Do you mean this (from RFC 1213)? >>>>> >>>>> ipRouteInfo OBJECT-TYPE >>>>> SYNTAX OBJECT IDENTIFIER >>>>> ACCESS read-only >>>>> STATUS mandatory >>>>> DESCRIPTION >>>>> "A reference to MIB definitions specific to the >>>>> particular routing protocol which is responsible >>>>> for this route, as determined by the value >>>>> specified in the route's ipRouteProto value. If >>>>> this information is not present, its value should >>>>> be set to the OBJECT IDENTIFIER { 0 0 }, which is >>>>> a syntatically valid object identifier, and any >>>>> conformant implementation of ASN.1 and BER must be >>>>> able to generate and recognize this value." >>>>> ::= { ipRouteEntry 13 } >>>>> >>>>> I thought it wasn't relevant to a YANG data model. How could it be used in our context? >>>>> >>>>>> field used to represent tagging that is carried between routing >>>>>> protocols by the RIB. >>>>> >>>>> As I understand it, route tags are specific to protocols, e.g., OSPF has the 32-bit "External Route Tag" while RIP uses a 16-bit "Route Tag". >>>>> >>>>> Thanks, Lada >>>>> >>>>>> >>>>>> Yours, >>>>>> Joel >>>>>> _______________________________________________ >>>>>> 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 >>>> >>>> >>>> >>>> >>>> >> >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C >> >> >> >> >> -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From j.schoenwaelder@jacobs-university.de Thu Jul 26 01:11:25 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEC0721F850C for ; Thu, 26 Jul 2012 01:11:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.202 X-Spam-Level: X-Spam-Status: No, score=-103.202 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WMoejmklVilb for ; Thu, 26 Jul 2012 01:11:23 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 0D86021F84C5 for ; Thu, 26 Jul 2012 01:11:23 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3427620C02; Thu, 26 Jul 2012 10:11:22 +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 ZCA8x82XDugO; Thu, 26 Jul 2012 10:11: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 947502090B; Thu, 26 Jul 2012 10:11:21 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 82F0520E9835; Thu, 26 Jul 2012 10:11:20 +0200 (CEST) Date: Thu, 26 Jul 2012 10:11:20 +0200 From: Juergen Schoenwaelder To: "Joel M. Halpern" , netmod@ietf.org Message-ID: <20120726081120.GA7512@elstar.local> Mail-Followup-To: "Joel M. Halpern" , netmod@ietf.org References: <942370E6-E33E-43A9-A16F-6C8DF0840AAE@nic.cz> <50101453.1010405@joelhalpern.com> <50106507.2030904@joelhalpern.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) Subject: Re: [netmod] NetMod routing 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: Thu, 26 Jul 2012 08:11:25 -0000 On Thu, Jul 26, 2012 at 09:59:14AM +0200, Ladislav Lhotka wrote: > "Joel M. Halpern" writes: > > > The whole point is that this RIB information is used to carry > > information between two instances of routing protocols (usually distinct > > protocols). If there are problems with the information not being > > propagated properly, the network administrator will need to be able to > > check each step of the process. That requires the ability to read this > > information from the RIB. > > Every protocol may create such information on its own (and in its own namespace), be it metrics, tags or whatever. If this information is passed between two instances of different protocols (more precisely between routing tables connected to either instance), then a reasonable default behaviour is to leave this information untouched. > > > > > If you have specific evidence that this management information is no > > longer needed, I am willing to listen. The information I have seen > > suggests it is still useful. > > I am not saying this information is not needed, only that it is not necessary to pre-allocate the slot in the generic routing module, if the contents is to be generated in a specific way by routing protocols. > > Maybe the difference lies in the fact that "ipRouteTable" is modelled as a table (one size fits all) in the MIB while the contents of each "route" entry in the YANG data model may be (partly) protocol-specific. > > The "ipRouteInfo" field is intended (I assume) as a pointer to an additional object containing the protocol-specific information. In YANG, this information can be put directly to the particular "route" entry. The example RIP module in Appendix A adds its own "metric" and "tag" nodes, which are however valid only if "source-protocol" equals to "rip". > A few comments from the SNMP MIB side. The current IP routing table MIB is in the IP-FORWARD-MIB published as part of RFC 4292. The various ipCidrRouteInfo object is actually deprecated (and RFC 1213 routing tables can't do CIDR, thus are pretty much de factor historic for a long time). The latest set of routing table MIB objects do not have a *Info object anymore but only inetCidrRouteProto. In other words, the routing table records information which routing protocol provided the routing table entry and assume that a management application knows how to retrieve further information if needed. This brings me to my main question: Are we discussing how to expose and track the information where a routing entry originates from or are we discussing how information attached to a routing entry can be passed between protocol instances? These are two different things and I am not sure we keep them separated. (But perhaps I am also just a bit confused. ;-) /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 Jul 26 05:11:16 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94DBB21F8767 for ; Thu, 26 Jul 2012 05:11:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.918 X-Spam-Level: X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[AWL=0.081, 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 ldhjz0EFHhMS for ; Thu, 26 Jul 2012 05:11:16 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id C0C2621F85E5 for ; Thu, 26 Jul 2012 05:11:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id DE98454033D; Thu, 26 Jul 2012 14:11:13 +0200 (CEST) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l2vo0Fppc83B; Thu, 26 Jul 2012 14:11:08 +0200 (CEST) Received: from localhost (birdie.lhotkovi.cz [172.29.2.201]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id BEA2D54013B; Thu, 26 Jul 2012 14:11:06 +0200 (CEST) From: Ladislav Lhotka To: Juergen Schoenwaelder , "Joel M. Halpern" , netmod@ietf.org In-Reply-To: <20120726081120.GA7512@elstar.local> References: <942370E6-E33E-43A9-A16F-6C8DF0840AAE@nic.cz> <50101453.1010405@joelhalpern.com> <50106507.2030904@joelhalpern.com> <20120726081120.GA7512@elstar.local> User-Agent: Notmuch/0.13.2+77~g39beeb2 (http://notmuchmail.org) Emacs/23.3.50.1 (i386-apple-darwin9.8.0) Mail-Followup-To: Juergen Schoenwaelder , "Joel M. Halpern" , netmod@ietf.org Date: Thu, 26 Jul 2012 14:11:06 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [netmod] NetMod routing 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: Thu, 26 Jul 2012 12:11:16 -0000 Juergen Schoenwaelder writes: > > A few comments from the SNMP MIB side. The current IP routing table Yes, thanks. ;-) > MIB is in the IP-FORWARD-MIB published as part of RFC 4292. The > various ipCidrRouteInfo object is actually deprecated (and RFC 1213 > routing tables can't do CIDR, thus are pretty much de factor historic > for a long time). The latest set of routing table MIB objects do not > have a *Info object anymore but only inetCidrRouteProto. In other > words, the routing table records information which routing protocol > provided the routing table entry and assume that a management > application knows how to retrieve further information if needed. It is certainly possible with our YANG data model because each route contains mandatory "source-protocol". But in YANG we have the option to put the additional protocol-specific information straight into route entries via augmentation, and make the new nodes conditionally valid only for a particular protocol type. The advantage of this approach is that all route information is nicely packed, hence easily available to route filters. > > This brings me to my main question: Are we discussing how to expose > and track the information where a routing entry originates from or are > we discussing how information attached to a routing entry can be > passed between protocol instances? These are two different things and > I am not sure we keep them separated. (But perhaps I am also just a > bit confused. ;-) Every single route must contain the information about the source protocol instance so the former is not an issue. All information encapsulated in a route, including protocol-specific stuff, can be passed between routing tables (i.e. also between routing protocol instances), subject to route filters. I don't see any limitation here either. 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 Thu Jul 26 05:52:55 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACBCA21F876C for ; Thu, 26 Jul 2012 05:52:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[AWL=0.079, 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 94s0DJYGWZvq for ; Thu, 26 Jul 2012 05:52:54 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id B571421F876A for ; Thu, 26 Jul 2012 05:52:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 05A9654033D for ; Thu, 26 Jul 2012 14:52:47 +0200 (CEST) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I7zRRNA+4vZU for ; Thu, 26 Jul 2012 14:52:37 +0200 (CEST) Received: from localhost (birdie.lhotkovi.cz [172.29.2.201]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 122F154013B for ; Thu, 26 Jul 2012 14:52:36 +0200 (CEST) From: Ladislav Lhotka To: netmod@ietf.org User-Agent: Notmuch/0.13.2+77~g39beeb2 (http://notmuchmail.org) Emacs/23.3.50.1 (i386-apple-darwin9.8.0) Mail-Followup-To: netmod@ietf.org Date: Thu, 26 Jul 2012 14:52:35 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [netmod] LL review of {interfaces,ip}-cfg-05 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, 26 Jul 2012 12:52:56 -0000 Hi, I read both drafts and I think overall they are in a good shape. My issues are mostly common to both drafts so I will deal with them together. *** Technical My main concern is the lack of operational state data. For an effective management, it is necessary to have operational info at least in the extent provided by the "ip" command in Linux. I am not sure whether the intention is (i) to develop other module(s) with this stuff later, or (ii) to rely on SNMP for this purpose. *** Formal 1. The sections containing YANG code start with a sentence like "This YANG module imports a typedef from ...". Strictly speaking, this is not correct because the 'import' statement imports entire modules and not only selected items. On the other hand, this sentence is redundant because 'import' statements have a prominent place at the beginning of each module. I propose to remove these sentences and start each section right away with . 2. Section 6. ("Security Considerations") of ip-cfg-05, in the paragraph about "ipv4/ip-forwarding" and "ipv6/ip-forwarding": I propose to change both occurrences of "routing functions" to "forwarding functions", because other routing functions such as routing protocol exchange may be performed even on interfaces with disabled forwarding. Lada -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From jmh@joelhalpern.com Thu Jul 26 07:06:09 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACCD521F8776 for ; Thu, 26 Jul 2012 07:06:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 6hdgl1sUUGG9 for ; Thu, 26 Jul 2012 07:06:09 -0700 (PDT) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 0D05621F876E for ; Thu, 26 Jul 2012 07:06:09 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by morbo.tigertech.net (Postfix) with ESMTP id E4B52A62FB for ; Thu, 26 Jul 2012 07:06:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 078731BCCE89 for ; Thu, 26 Jul 2012 07:06:03 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [172.17.141.180] (207.47.24.2.static.nextweb.net [207.47.24.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id D53381BCCE88 for ; Thu, 26 Jul 2012 07:06:02 -0700 (PDT) Message-ID: <50114EC5.70504@joelhalpern.com> Date: Thu, 26 Jul 2012 10:05:57 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: netmod@ietf.org References: <942370E6-E33E-43A9-A16F-6C8DF0840AAE@nic.cz> <50101453.1010405@joelhalpern.com> <50106507.2030904@joelhalpern.com> <20120726081120.GA7512@elstar.local> In-Reply-To: <20120726081120.GA7512@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [netmod] NetMod routing 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: Thu, 26 Jul 2012 14:06:09 -0000 It appears that I have confused myself by mixing information I thought was still visibly modeled. Apologies to Lada and the working group. Given that it appears to have been dropped from the MIBs, I don't have a leg to stand on to ask for it to be in the generic table. (The information I was looking for was generic, not protocol specific, and could not be handled by protocol specific extensions.) I am surprised the information is gone, but that is not this WGs problem at this point. I presume that fields like nextHopAS would be handled in protocol specific extension, since that would apply only to routes inserted by BGP? I also presume that metric information, being specific to the individual routing protocols, would go in those extensions, rather than in the main table as done in RFC 4292? The ability to modularize the information seems powerful. To be useful for management, we are going to need those other pieces. Yours, Joel On 7/26/2012 4:11 AM, Juergen Schoenwaelder wrote: > On Thu, Jul 26, 2012 at 09:59:14AM +0200, Ladislav Lhotka wrote: >> "Joel M. Halpern" writes: >> >>> The whole point is that this RIB information is used to carry >>> information between two instances of routing protocols (usually distinct >>> protocols). If there are problems with the information not being >>> propagated properly, the network administrator will need to be able to >>> check each step of the process. That requires the ability to read this >>> information from the RIB. >> >> Every protocol may create such information on its own (and in its own namespace), be it metrics, tags or whatever. If this information is passed between two instances of different protocols (more precisely between routing tables connected to either instance), then a reasonable default behaviour is to leave this information untouched. >> >>> >>> If you have specific evidence that this management information is no >>> longer needed, I am willing to listen. The information I have seen >>> suggests it is still useful. >> >> I am not saying this information is not needed, only that it is not necessary to pre-allocate the slot in the generic routing module, if the contents is to be generated in a specific way by routing protocols. >> >> Maybe the difference lies in the fact that "ipRouteTable" is modelled as a table (one size fits all) in the MIB while the contents of each "route" entry in the YANG data model may be (partly) protocol-specific. >> >> The "ipRouteInfo" field is intended (I assume) as a pointer to an additional object containing the protocol-specific information. In YANG, this information can be put directly to the particular "route" entry. The example RIP module in Appendix A adds its own "metric" and "tag" nodes, which are however valid only if "source-protocol" equals to "rip". >> > > A few comments from the SNMP MIB side. The current IP routing table > MIB is in the IP-FORWARD-MIB published as part of RFC 4292. The > various ipCidrRouteInfo object is actually deprecated (and RFC 1213 > routing tables can't do CIDR, thus are pretty much de factor historic > for a long time). The latest set of routing table MIB objects do not > have a *Info object anymore but only inetCidrRouteProto. In other > words, the routing table records information which routing protocol > provided the routing table entry and assume that a management > application knows how to retrieve further information if needed. > > This brings me to my main question: Are we discussing how to expose > and track the information where a routing entry originates from or are > we discussing how information attached to a routing entry can be > passed between protocol instances? These are two different things and > I am not sure we keep them separated. (But perhaps I am also just a > bit confused. ;-) > > /js > From jeffrey.K.lange@ge.com Thu Jul 26 07:20:25 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50D9921F875C for ; Thu, 26 Jul 2012 07:20:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.379 X-Spam-Level: X-Spam-Status: No, score=-6.379 tagged_above=-999 required=5 tests=[AWL=0.219, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HtxQeEHew7iE for ; Thu, 26 Jul 2012 07:20:24 -0700 (PDT) Received: from exprod5og107.obsmtp.com (exprod5og107.obsmtp.com [64.18.0.184]) by ietfa.amsl.com (Postfix) with ESMTP id 4B21921F86EE for ; Thu, 26 Jul 2012 07:20:23 -0700 (PDT) Received: from cinmlip11.e2k.ad.ge.com ([12.71.149.1]) (using TLSv1) by exprod5ob107.postini.com ([64.18.4.12]) with SMTP ID DSNKUBFSJJ0eTAnKA6ekJRv8UrgqJVXo0uDO@postini.com; Thu, 26 Jul 2012 07:20:23 PDT Received: from unknown (HELO cinmlef07.e2k.ad.ge.com) ([3.159.213.38]) by cinmlip11.e2k.ad.ge.com with ESMTP; 26 Jul 2012 10:20:17 -0400 Received: from cinmlch01.e2k.ad.ge.com ([3.159.212.50]) by cinmlef07.e2k.ad.ge.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 26 Jul 2012 10:20:16 -0400 Received: from CINMBCNA06.e2k.ad.ge.com (3.159.212.61) by cinmlch01.e2k.ad.ge.com (3.159.212.50) with Microsoft SMTP Server (TLS) id 14.2.283.3; Thu, 26 Jul 2012 10:20:15 -0400 Received: from CINMBCNA02.e2k.ad.ge.com ([169.254.2.214]) by CINMBCNA06.e2k.ad.ge.com ([169.254.6.103]) with mapi id 14.02.0283.003; Thu, 26 Jul 2012 10:20:16 -0400 From: "Lange, Jeffrey K (GE Energy)" To: "netmod@ietf.org" Thread-Topic: ietf-interfaces & vendor specific types Thread-Index: Ac1rOL4GcE2G9FPITNGjmmn1PX00ew== Date: Thu, 26 Jul 2012 14:20:15 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [3.159.212.187] Content-Type: multipart/alternative; boundary="_000_B0FB1FAC2C7B234D87DCEBF309F703C51BAB1626CINMBCNA02e2kad_" MIME-Version: 1.0 X-OriginalArrivalTime: 26 Jul 2012 14:20:16.0270 (UTC) FILETIME=[C72F82E0:01CD6B39] Subject: [netmod] ietf-interfaces & vendor specific types 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, 26 Jul 2012 14:20:25 -0000 --_000_B0FB1FAC2C7B234D87DCEBF309F703C51BAB1626CINMBCNA02e2kad_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I've run into a bit of a snag when trying to implement the ietf-interfaces = model on our products, we have some vendor specific interface types that ar= e not covered by the iana enumeration, yet we need to be able to convey the= interface type in the data model.. I propose that a new leaf be added tha= t allows for an identity-ref for a type when the iana iftype is 'other' I'= ve tested this in my environment, and it works well. In ietf-interfaces: identity interface-type { description "Base identity from which vendor specific interface types are derived."; } ... leaf type { type ianaift:iana-if-type; ... } leaf other-type { type identityref { base interface-type; } when "../type=3D'other'"; description "When an interface type is not specified by the iana-if-type enumeration, this leaf may be populated with a vendor- specific interface type"; } Then in my vendor-specific data model I can define the following: identity cellular-lte { base if:interface-type; description "A 4G LTE cellular radio"; } Does anyone else see merit in this approach? I think it would make vendor = specific extensions much easier to handle in a standard way. -Jeff --_000_B0FB1FAC2C7B234D87DCEBF309F703C51BAB1626CINMBCNA02e2kad_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’ve run into a bit of a snag when trying to i= mplement the ietf-interfaces model on our products, we have some vendor spe= cific interface types that are not covered by the iana enumeration, yet we = need to be able to convey the interface type in the data model..  I propose that a new leaf be added that all= ows for an identity-ref for a type when the iana iftype is ‘otherR= 17;  I’ve tested this in my environment, and it works well.=

 

In ietf-interfaces:

  identity interface-type {

    description

      "Base identity f= rom which vendor specific interface types are

       derived.";=

  }

 

…

 

    leaf type {

        type iana= ift:iana-if-type;

         = 230;

      }

      leaf other-type {

        type iden= tityref {

        &nbs= p; base interface-type;

        }

       when "= ;../type=3D'other'";

        descripti= on

        &nbs= p; "When an interface type is not specified by the iana-if-type

        &nbs= p;  enumeration, this leaf may be populated with a vendor-<= /p>

        &nbs= p;  specific interface type";

      }

 

Then in my vendor-specific data model I can define t= he following:

 

  identity cellular-lte {

    base if:interface-type;

    description

      "A 4G LTE cellul= ar radio";

  }

 

Does anyone else see merit in this approach?  I= think it would make vendor specific extensions much easier to handle in a = standard way.

 

-Jeff

 

--_000_B0FB1FAC2C7B234D87DCEBF309F703C51BAB1626CINMBCNA02e2kad_-- From pgili@cisco.com Thu Jul 26 07:38:47 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E01721F877E for ; Thu, 26 Jul 2012 07:38:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ai0YzitILx3P for ; Thu, 26 Jul 2012 07:38:45 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 9930921F85D1 for ; Thu, 26 Jul 2012 07:38:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9613; q=dns/txt; s=iport; t=1343313525; x=1344523125; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=yB4sbRpwMwVWLKv4/NMPeGwv4CFVB8CL8tneX+4fm8Y=; b=V2OcCN7Ecqtlbno54nCQeX/NkPYToTU1zEaAHmFT7Gc8JrIIBMrKUy7v s6viD5xOyYTCDZtk+Gqau4EK0MbKjDkoagcJbWFIzu00eDhtb3ChIUWAq c4vaS+2p/gPT7qIWQzWvm1R4T3HR/HOSxn9FKjYsEz2Rs4jsR8OU48Ucz U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAChWEVCtJXG//2dsb2JhbAA8CYJKtnGBB4IgAQEBBBIBGlwCAQgRBAEBCx0HMhQJCAEBBAESCBqHa5tsoEOLTxGGA2ADo2+BZoJf X-IronPort-AV: E=Sophos;i="4.77,659,1336348800"; d="scan'208,217";a="102599755" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-9.cisco.com with ESMTP; 26 Jul 2012 14:38:45 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id q6QEchvI024004 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 26 Jul 2012 14:38:44 GMT Received: from xmb-aln-x14.cisco.com ([169.254.8.138]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.02.0298.004; Thu, 26 Jul 2012 09:38:43 -0500 From: "Patrick Gili (pgili)" To: "Lange, Jeffrey K (GE Energy)" , "netmod@ietf.org" Thread-Topic: ietf-interfaces & vendor specific types Thread-Index: Ac1rOL4GcE2G9FPITNGjmmn1PX00ewAAvpWg Date: Thu, 26 Jul 2012 14:38:42 +0000 Message-ID: <50E64ADF99EAEE4CACEC18958F0FC0AB01C707@xmb-aln-x14.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.251.80] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19064.005 x-tm-as-result: No--29.270700-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_50E64ADF99EAEE4CACEC18958F0FC0AB01C707xmbalnx14ciscocom_" MIME-Version: 1.0 Subject: Re: [netmod] ietf-interfaces & vendor specific types 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, 26 Jul 2012 14:38:47 -0000 --_000_50E64ADF99EAEE4CACEC18958F0FC0AB01C707xmbalnx14ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Historically, I have had no difficulties using the web page IANA makes avai= lable to register new interface types. However, it brings up a relevant point. Wouldn't an identityref better repr= esent the notion of "interface type", thereby allowing vendors to have vend= or-specific interface types? It would somewhat simplify the administrative = of interface types, as the IANA interface types have been littered througho= ut the ages with interfaces types that were ultimately vendor specific in n= ature. Patrick Gili From: netmod-bounces@ietf.org [mailto:netmod-bounces@ietf.org] On Behalf Of= Lange, Jeffrey K (GE Energy) Sent: Thursday, July 26, 2012 10:20 AM To: netmod@ietf.org Subject: [netmod] ietf-interfaces & vendor specific types I've run into a bit of a snag when trying to implement the ietf-interfaces = model on our products, we have some vendor specific interface types that ar= e not covered by the iana enumeration, yet we need to be able to convey the= interface type in the data model.. I propose that a new leaf be added tha= t allows for an identity-ref for a type when the iana iftype is 'other' I'= ve tested this in my environment, and it works well. In ietf-interfaces: identity interface-type { description "Base identity from which vendor specific interface types are derived."; } ... leaf type { type ianaift:iana-if-type; ... } leaf other-type { type identityref { base interface-type; } when "../type=3D'other'"; description "When an interface type is not specified by the iana-if-type enumeration, this leaf may be populated with a vendor- specific interface type"; } Then in my vendor-specific data model I can define the following: identity cellular-lte { base if:interface-type; description "A 4G LTE cellular radio"; } Does anyone else see merit in this approach? I think it would make vendor = specific extensions much easier to handle in a standard way. -Jeff --_000_50E64ADF99EAEE4CACEC18958F0FC0AB01C707xmbalnx14ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Historically, I have h= ad no difficulties using the web page IANA makes available to register new = interface types.

 

However, it brings up = a relevant point. Wouldn’t an identityref better represent the notion= of “interface type”, thereby allowing vendors to have vendor-s= pecific interface types? It would somewhat simplify the administrative of interface types, as the IANA interface types have been l= ittered throughout the ages with interfaces types that were ultimately vend= or specific in nature.

 

Patrick Gili

 

From: netmod-b= ounces@ietf.org [mailto:netmod-bounces@ietf.org] On Behalf Of Lange, Jeffrey K (GE Energy)
Sent: Thursday, July 26, 2012 10:20 AM
To: netmod@ietf.org
Subject: [netmod] ietf-interfaces & vendor specific types

 

I’ve run into a bit of a snag when trying to i= mplement the ietf-interfaces model on our products, we have some vendor spe= cific interface types that are not covered by the iana enumeration, yet we = need to be able to convey the interface type in the data model..  I propose that a new leaf be added that all= ows for an identity-ref for a type when the iana iftype is ‘otherR= 17;  I’ve tested this in my environment, and it works well.=

 

In ietf-interfaces:

  identity interface-type {

    description

      "Base identity f= rom which vendor specific interface types are

       derived.";=

  }

 

…

 

    leaf type {

        type iana= ift:iana-if-type;

         = 230;

      }

      leaf other-type {

        type iden= tityref {

        &nbs= p; base interface-type;

        }

       when "= ;../type=3D'other'";

        descripti= on

        &nbs= p; "When an interface type is not specified by the iana-if-type

        &nbs= p;  enumeration, this leaf may be populated with a vendor-<= /p>

        &nbs= p;  specific interface type";

      }

 

Then in my vendor-specific data model I can define t= he following:

 

  identity cellular-lte {

    base if:interface-type;

    description

      "A 4G LTE cellul= ar radio";

  }

 

Does anyone else see merit in this approach?  I= think it would make vendor specific extensions much easier to handle in a = standard way.

 

-Jeff

 

--_000_50E64ADF99EAEE4CACEC18958F0FC0AB01C707xmbalnx14ciscocom_-- From andy@yumaworks.com Thu Jul 26 08:07:10 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EC4B21F8787 for ; Thu, 26 Jul 2012 08:07:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.958 X-Spam-Level: X-Spam-Status: No, score=-2.958 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 xdGwzhXCZ+my for ; Thu, 26 Jul 2012 08:07:09 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1C45621F8782 for ; Thu, 26 Jul 2012 08:07:08 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so1581139lbb.31 for ; Thu, 26 Jul 2012 08:07:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding:x-gm-message-state; bh=oRorkPWNFEtl8rKH/LOGJW2kg3U+akgv7skqV+GMnlM=; b=czNQsqbiTRN7YkSVL7PISnSP7X8nmQafiaR35QDZlZt3/YeAoYxV2b4wD+psJZ0qoN leKmIbGepKsTdsb7lebJ1kH9a27Ak095vaN6AB7bs/n6+UctE9Qcb+2zdXuxBXIUHsAe cSFWnvi0zfUhZkRlXRcFdZK6iUaBt7R2zr9qpmzHjgXy5ImEt9OzeVBjM/kgopA4wSm+ lxnofCMWekNedZO10IQaKasPgt0kEix/jjuyJG/85POhGKvsG+eXcLjU1b1aJoC9bGFI mIUVXmsVopV3e4WYgIYU3fY0ysaqDwvAcnYi3rUzP12vo1UvzbG9F/uJCj0I0aoiW4ZR yCtA== MIME-Version: 1.0 Received: by 10.112.36.132 with SMTP id q4mr13674881lbj.63.1343315227943; Thu, 26 Jul 2012 08:07:07 -0700 (PDT) Received: by 10.114.19.72 with HTTP; Thu, 26 Jul 2012 08:07:07 -0700 (PDT) X-Originating-IP: [75.84.168.164] In-Reply-To: <50E64ADF99EAEE4CACEC18958F0FC0AB01C707@xmb-aln-x14.cisco.com> References: <50E64ADF99EAEE4CACEC18958F0FC0AB01C707@xmb-aln-x14.cisco.com> Date: Thu, 26 Jul 2012 08:07:07 -0700 Message-ID: From: Andy Bierman To: "Patrick Gili (pgili)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQnGmOurmwXNQN73wcSEICWZfALef4Wnt6BH3kQfHLq7ZexVK1A/OI/oS4rlaOZRWUbc6Im3 Cc: "netmod@ietf.org" Subject: Re: [netmod] ietf-interfaces & vendor specific types 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, 26 Jul 2012 15:07:10 -0000 On Thu, Jul 26, 2012 at 7:38 AM, Patrick Gili (pgili) wro= te: > Historically, I have had no difficulties using the web page IANA makes > available to register new interface types. > > > > However, it brings up a relevant point. Wouldn=E2=80=99t an identityref b= etter > represent the notion of =E2=80=9Cinterface type=E2=80=9D, thereby allowin= g vendors to have > vendor-specific interface types? It would somewhat simplify the > administrative of interface types, as the IANA interface types have been > littered throughout the ages with interfaces types that were ultimately > vendor specific in nature. > > I think there is more standards value if the interface types are assigned f= rom a single naming authority. Otherwise, we will end up will vendor-specific versions of the IANA registered types. I think a separate leaf for this purpose wou= ld be better. > > Patrick Gili > Andy > > > From: netmod-bounces@ietf.org [mailto:netmod-bounces@ietf.org] On Behalf = Of > Lange, Jeffrey K (GE Energy) > Sent: Thursday, July 26, 2012 10:20 AM > To: netmod@ietf.org > Subject: [netmod] ietf-interfaces & vendor specific types > > > > I=E2=80=99ve run into a bit of a snag when trying to implement the ietf-i= nterfaces > model on our products, we have some vendor specific interface types that = are > not covered by the iana enumeration, yet we need to be able to convey the > interface type in the data model.. I propose that a new leaf be added th= at > allows for an identity-ref for a type when the iana iftype is =E2=80=98ot= her=E2=80=99 I=E2=80=99ve > tested this in my environment, and it works well. > > > > In ietf-interfaces: > > identity interface-type { > > description > > "Base identity from which vendor specific interface types are > > derived."; > > } > > > > =E2=80=A6 > > > > leaf type { > > type ianaift:iana-if-type; > > =E2=80=A6 > > } > > leaf other-type { > > type identityref { > > base interface-type; > > } > > when "../type=3D'other'"; > > description > > "When an interface type is not specified by the iana-if-type > > enumeration, this leaf may be populated with a vendor- > > specific interface type"; > > } > > > > Then in my vendor-specific data model I can define the following: > > > > identity cellular-lte { > > base if:interface-type; > > description > > "A 4G LTE cellular radio"; > > } > > > > Does anyone else see merit in this approach? I think it would make vendo= r > specific extensions much easier to handle in a standard way. > > > > -Jeff > > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From lhotka@nic.cz Thu Jul 26 08:28:22 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84CDD21F875E for ; Thu, 26 Jul 2012 08:28:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.923 X-Spam-Level: X-Spam-Status: No, score=-1.923 tagged_above=-999 required=5 tests=[AWL=0.076, 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 fCkm2ZgMQauL for ; Thu, 26 Jul 2012 08:28: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 6E0E821F866B for ; Thu, 26 Jul 2012 08:28:21 -0700 (PDT) Received: from [172.29.2.201] (unknown [77.48.224.120]) by mail.nic.cz (Postfix) with ESMTPSA id F198113F633; Thu, 26 Jul 2012 17:28:18 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1343316499; bh=zbKYyJHAPez+pc6NWicWVp0Tn9rOZ3X7zwDcyxHuE44=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=DVjsXO67w/b6baeGwMGiaJEWJKEO9418xsDgS2saDQ6hs8nqHaRHQhLjh9NqleImk SNKZ24rrS/1KJYQdSUGuLV1XpOO4AQfwGF/kP/HITMKjuW02Eo5QuKxBcYJEsV32+g dr26eNZlfmVZ9JGaVe0x2kpvZdop4yiGvkYy6kZw= Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Ladislav Lhotka In-Reply-To: <50114EC5.70504@joelhalpern.com> Date: Thu, 26 Jul 2012 17:28:18 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8ACA864E-61E6-44E3-BC77-B1BDE5F6F8EE@nic.cz> References: <942370E6-E33E-43A9-A16F-6C8DF0840AAE@nic.cz> <50101453.1010405@joelhalpern.com> <50106507.2030904@joelhalpern.com> <20120726081120.GA7512@elstar.local> <50114EC5.70504@joelhalpern.com> To: "Joel M. Halpern" X-Mailer: Apple Mail (2.1278) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] NetMod routing 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: Thu, 26 Jul 2012 15:28:22 -0000 On Jul 26, 2012, at 4:05 PM, Joel M. Halpern wrote: > It appears that I have confused myself by mixing information I thought = was still visibly modeled. Apologies to Lada and the working group. = Given that it appears to have been dropped from the MIBs, I don't have a = leg to stand on to ask for it to be in the generic table. (The = information I was looking for was generic, not protocol specific, and = could not be handled by protocol specific extensions.) I am surprised = the information is gone, but that is not this WGs problem at this point. I am glad it's been clarified - thanks, Juergen! >=20 > I presume that fields like nextHopAS would be handled in protocol = specific extension, since that would apply only to routes inserted by = BGP? Yes. >=20 > I also presume that metric information, being specific to the = individual routing protocols, would go in those extensions, rather than = in the main table as done in RFC 4292? Yes. >=20 > The ability to modularize the information seems powerful. To be = useful for management, we are going to need those other pieces. Right. I actually expect that data models for the more complicated stuff = (protocols, filter) will reveal some shortcomings of the core routing = model, so I guess we have to be prepared for some iterations. Thanks, Lada >=20 > Yours, > Joel >=20 > On 7/26/2012 4:11 AM, Juergen Schoenwaelder wrote: >> On Thu, Jul 26, 2012 at 09:59:14AM +0200, Ladislav Lhotka wrote: >>> "Joel M. Halpern" writes: >>>=20 >>>> The whole point is that this RIB information is used to carry >>>> information between two instances of routing protocols (usually = distinct >>>> protocols). If there are problems with the information not being >>>> propagated properly, the network administrator will need to be able = to >>>> check each step of the process. That requires the ability to read = this >>>> information from the RIB. >>>=20 >>> Every protocol may create such information on its own (and in its = own namespace), be it metrics, tags or whatever. If this information is = passed between two instances of different protocols (more precisely = between routing tables connected to either instance), then a reasonable = default behaviour is to leave this information untouched. >>>=20 >>>>=20 >>>> If you have specific evidence that this management information is = no >>>> longer needed, I am willing to listen. The information I have seen >>>> suggests it is still useful. >>>=20 >>> I am not saying this information is not needed, only that it is not = necessary to pre-allocate the slot in the generic routing module, if the = contents is to be generated in a specific way by routing protocols. >>>=20 >>> Maybe the difference lies in the fact that "ipRouteTable" is = modelled as a table (one size fits all) in the MIB while the contents of = each "route" entry in the YANG data model may be (partly) = protocol-specific. >>>=20 >>> The "ipRouteInfo" field is intended (I assume) as a pointer to an = additional object containing the protocol-specific information. In YANG, = this information can be put directly to the particular "route" entry. = The example RIP module in Appendix A adds its own "metric" and "tag" = nodes, which are however valid only if "source-protocol" equals to = "rip". >>>=20 >>=20 >> A few comments from the SNMP MIB side. The current IP routing table >> MIB is in the IP-FORWARD-MIB published as part of RFC 4292. The >> various ipCidrRouteInfo object is actually deprecated (and RFC 1213 >> routing tables can't do CIDR, thus are pretty much de factor historic >> for a long time). The latest set of routing table MIB objects do not >> have a *Info object anymore but only inetCidrRouteProto. In other >> words, the routing table records information which routing protocol >> provided the routing table entry and assume that a management >> application knows how to retrieve further information if needed. >>=20 >> This brings me to my main question: Are we discussing how to expose >> and track the information where a routing entry originates from or = are >> we discussing how information attached to a routing entry can be >> passed between protocol instances? These are two different things and >> I am not sure we keep them separated. (But perhaps I am also just a >> bit confused. ;-) >>=20 >> /js >>=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 Jul 26 08:47:39 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E15A21F8650 for ; Thu, 26 Jul 2012 08:47:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.925 X-Spam-Level: X-Spam-Status: No, score=-1.925 tagged_above=-999 required=5 tests=[AWL=0.074, 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 DDmOf-Re6kMV for ; Thu, 26 Jul 2012 08:47:38 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 6D5A121F85EA for ; Thu, 26 Jul 2012 08:47:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 6015F54033D for ; Thu, 26 Jul 2012 17:47:37 +0200 (CEST) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8EwG5rpU+Oc1 for ; Thu, 26 Jul 2012 17:47:32 +0200 (CEST) Received: from localhost (birdie.lhotkovi.cz [172.29.2.201]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 463EF54013B for ; Thu, 26 Jul 2012 17:47:31 +0200 (CEST) From: Ladislav Lhotka To: netmod@ietf.org In-Reply-To: <50E64ADF99EAEE4CACEC18958F0FC0AB01C707@xmb-aln-x14.cisco.com> References: <50E64ADF99EAEE4CACEC18958F0FC0AB01C707@xmb-aln-x14.cisco.com> User-Agent: Notmuch/0.13.2+77~g39beeb2 (http://notmuchmail.org) Emacs/23.3.50.1 (i386-apple-darwin9.8.0) Mail-Followup-To: netmod@ietf.org Date: Thu, 26 Jul 2012 17:47:31 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [netmod] ietf-interfaces & vendor specific types 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, 26 Jul 2012 15:47:39 -0000 "Patrick Gili (pgili)" writes: > Historically, I have had no difficulties using the web page IANA makes available to register new interface types. > > However, it brings up a relevant point. Wouldn't an identityref better represent the notion of "interface type", thereby allowing vendors to have vendor-specific interface types? It would somewhat simplify the administrative of interface types, as the IANA interface types have been littered throughout the ages with interfaces types that were ultimately vendor specific in nature. This has already been discussed: http://www.ietf.org/mail-archive/web/netmod/current/msg05913.html In short: We need support for YANG identities in XPath expressions, otherwise the migration from enumerations to identities makes little sense. To this end, an XPath extension function (derived-from()) is already waiting in the pipe, but unfortunately this requires an update to the YANG spec. Lada > > Patrick Gili > > From: netmod-bounces@ietf.org [mailto:netmod-bounces@ietf.org] On Behalf Of Lange, Jeffrey K (GE Energy) > Sent: Thursday, July 26, 2012 10:20 AM > To: netmod@ietf.org > Subject: [netmod] ietf-interfaces & vendor specific types > > I've run into a bit of a snag when trying to implement the ietf-interfaces model on our products, we have some vendor specific interface types that are not covered by the iana enumeration, yet we need to be able to convey the interface type in the data model.. I propose that a new leaf be added that allows for an identity-ref for a type when the iana iftype is 'other' I've tested this in my environment, and it works well. > > In ietf-interfaces: > identity interface-type { > description > "Base identity from which vendor specific interface types are > derived."; > } > > ... > > leaf type { > type ianaift:iana-if-type; > ... > } > leaf other-type { > type identityref { > base interface-type; > } > when "../type='other'"; > description > "When an interface type is not specified by the iana-if-type > enumeration, this leaf may be populated with a vendor- > specific interface type"; > } > > Then in my vendor-specific data model I can define the following: > > identity cellular-lte { > base if:interface-type; > description > "A 4G LTE cellular radio"; > } > > Does anyone else see merit in this approach? I think it would make vendor specific extensions much easier to handle in a standard way. > > -Jeff > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From jeffrey.K.lange@ge.com Thu Jul 26 10:10:43 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A34321F8643 for ; Thu, 26 Jul 2012 10:10:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.391 X-Spam-Level: X-Spam-Status: No, score=-6.391 tagged_above=-999 required=5 tests=[AWL=0.208, 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 EWnA7jt4WxzV for ; Thu, 26 Jul 2012 10:10:42 -0700 (PDT) Received: from exprod5og113.obsmtp.com (exprod5og113.obsmtp.com [64.18.0.26]) by ietfa.amsl.com (Postfix) with ESMTP id 29F8621F8631 for ; Thu, 26 Jul 2012 10:10:42 -0700 (PDT) Received: from alpmlip12.e2k.ad.ge.com ([165.156.5.1]) (using TLSv1) by exprod5ob113.postini.com ([64.18.4.12]) with SMTP ID DSNKUBF6EX/hKKJXjw9mLs9b2m6vurctdknk@postini.com; Thu, 26 Jul 2012 10:10:42 PDT Received: from unknown (HELO alpmlef06.e2k.ad.ge.com) ([3.159.18.15]) by alpmlip12.e2k.ad.ge.com with ESMTP; 26 Jul 2012 13:10:39 -0400 Received: from alpmlef03.e2k.ad.ge.com ([3.159.18.12]) by alpmlef06.e2k.ad.ge.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 26 Jul 2012 13:10:39 -0400 Received: from CINMLCH02.e2k.ad.ge.com ([3.159.212.51]) by alpmlef03.e2k.ad.ge.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 26 Jul 2012 13:10:38 -0400 Received: from CINMBCNA01.e2k.ad.ge.com (3.159.212.55) by CINMLCH02.e2k.ad.ge.com (3.159.212.51) with Microsoft SMTP Server (TLS) id 14.2.283.3; Thu, 26 Jul 2012 13:10:38 -0400 Received: from CINMBCNA02.e2k.ad.ge.com ([169.254.2.214]) by CINMBCNA01.e2k.ad.ge.com ([169.254.1.38]) with mapi id 14.02.0283.003; Thu, 26 Jul 2012 13:10:38 -0400 From: "Lange, Jeffrey K (GE Energy)" To: Ladislav Lhotka , "netmod@ietf.org" Thread-Topic: [netmod] ietf-interfaces & vendor specific types Thread-Index: Ac1rOL4GcE2G9FPITNGjmmn1PX00ewAAvpWgAArxgoAABbiIQA== Date: Thu, 26 Jul 2012 17:10:36 +0000 Message-ID: References: <50E64ADF99EAEE4CACEC18958F0FC0AB01C707@xmb-aln-x14.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [3.159.212.187] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 26 Jul 2012 17:10:38.0889 (UTC) FILETIME=[94576190:01CD6B51] Subject: Re: [netmod] ietf-interfaces & vendor specific types 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, 26 Jul 2012 17:10:43 -0000 > > Historically, I have had no difficulties using the web page IANA makes > available to register new interface types. > > > > However, it brings up a relevant point. Wouldn't an identityref better > represent the notion of "interface type", thereby allowing vendors to hav= e > vendor-specific interface types? It would somewhat simplify the > administrative of interface types, as the IANA interface types have been > littered throughout the ages with interfaces types that were ultimately v= endor > specific in nature. >=20 > This has already been discussed: >=20 > http://www.ietf.org/mail-archive/web/netmod/current/msg05913.html >=20 > In short: We need support for YANG identities in XPath expressions, > otherwise the migration from enumerations to identities makes little sens= e. >=20 > To this end, an XPath extension function (derived-from()) is already wait= ing in > the pipe, but unfortunately this requires an update to the YANG spec. >=20 I agree that having the derived-from would be a cleaner approach, but what = I'm suggesting is 1) possible today, and 2) creates a standard way to deal = with the already defined "other" iana-iftype enum value. I clearly could a= ugment the interfaces model to add this capability in my own vendor specifi= c extensions, but I think that this is something that other people would al= so benefit from. And I would like to try to keep my models as close to the= standards as possible for obvious reasons. And I don't think that asking IANA to add a truly vendor specific interface= type, that no other manufacturer in the world would be using, to the publ= ic enumeration is a very good idea either. -Jeff > Lada >=20 > > > > Patrick Gili > > From j.schoenwaelder@jacobs-university.de Thu Jul 26 12:08:10 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 836B021F8622 for ; Thu, 26 Jul 2012 12:08:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.203 X-Spam-Level: X-Spam-Status: No, score=-103.203 tagged_above=-999 required=5 tests=[AWL=0.046, 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 7ipMR31qtEtP for ; Thu, 26 Jul 2012 12:08: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 6A81521F8621 for ; Thu, 26 Jul 2012 12:07:55 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1676C20C1C; Thu, 26 Jul 2012 21:07:54 +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 xx3Ml9A9tb6P; Thu, 26 Jul 2012 21:07:53 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 121EC20C11; Thu, 26 Jul 2012 21:07:53 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 873DA20EA103; Thu, 26 Jul 2012 21:07:51 +0200 (CEST) Date: Thu, 26 Jul 2012 21:07:51 +0200 From: Juergen Schoenwaelder To: "Patrick Gili (pgili)" Message-ID: <20120726190751.GA8248@elstar.local> Mail-Followup-To: "Patrick Gili (pgili)" , "Lange, Jeffrey K (GE Energy)" , "netmod@ietf.org" References: <50E64ADF99EAEE4CACEC18958F0FC0AB01C707@xmb-aln-x14.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50E64ADF99EAEE4CACEC18958F0FC0AB01C707@xmb-aln-x14.cisco.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "netmod@ietf.org" Subject: Re: [netmod] ietf-interfaces & vendor specific types 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, 26 Jul 2012 19:08:10 -0000 On Thu, Jul 26, 2012 at 02:38:42PM +0000, Patrick Gili (pgili) wrote: > Historically, I have had no difficulties using the web page IANA makes available to register new interface types. > > However, it brings up a relevant point. Wouldn't an identityref better represent the notion of "interface type", thereby allowing vendors to have vendor-specific interface types? It would somewhat simplify the administrative of interface types, as the IANA interface types have been littered throughout the ages with interfaces types that were ultimately vendor specific in nature. I think we had this discussion before. The last time we went through this, I believe the WG favored a controlled central registry for interface types since this promotes interoperability. Is it really useful if every vendor comes up with his own interface types for say LTE 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 j.schoenwaelder@jacobs-university.de Thu Jul 26 12:14:01 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1AFD11E809C for ; Thu, 26 Jul 2012 12:14:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.203 X-Spam-Level: X-Spam-Status: No, score=-103.203 tagged_above=-999 required=5 tests=[AWL=0.046, 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 I6ZOlLdXC8FU for ; Thu, 26 Jul 2012 12:14: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 18C6621F85A8 for ; Thu, 26 Jul 2012 12:14:01 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6CFCC20C1C; Thu, 26 Jul 2012 21:14:00 +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 zdSlZ0gTYQk5; Thu, 26 Jul 2012 21:14: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 BCE0920C11; Thu, 26 Jul 2012 21:13:59 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id D639820EA1A8; Thu, 26 Jul 2012 21:13:58 +0200 (CEST) Date: Thu, 26 Jul 2012 21:13:58 +0200 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20120726191358.GB8248@elstar.local> Mail-Followup-To: netmod@ietf.org References: 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) Subject: Re: [netmod] LL review of {interfaces,ip}-cfg-05 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, 26 Jul 2012 19:14:02 -0000 On Thu, Jul 26, 2012 at 02:52:35PM +0200, Ladislav Lhotka wrote: > Hi, > > I read both drafts and I think overall they are in a good shape. My issues are mostly common to both drafts so I will deal with them together. > > *** Technical > My main concern is the lack of operational state data. For an effective management, it is necessary to have operational info at least in the extent provided by the "ip" command in Linux. I am not sure whether the intention is (i) to develop other module(s) with this stuff later, or (ii) to rely on SNMP for this purpose. Since there is no general plan, the decision was to focus this work on configuration at this point in time. > *** Formal > 1. The sections containing YANG code start with a sentence like > "This YANG module imports a typedef from ...". Strictly speaking, > this is not correct because the 'import' statement imports entire > modules and not only selected items. On the other hand, this > sentence is redundant because 'import' statements have a prominent > place at the beginning of each module. I propose to remove these > sentences and start each section right away with . These sentence are there so that we have citations of the normative references in the text (otherwise IETF tools yell at you). While it is true that a YANG import imports a module, I think the current text is not wrong - it actually adds additional clarity by stating what is used from the module(s). > 2. Section 6. ("Security Considerations") of ip-cfg-05, in the > paragraph about "ipv4/ip-forwarding" and "ipv6/ip-forwarding": I > propose to change both occurrences of "routing functions" to > "forwarding functions", because other routing functions such as > routing protocol exchange may be performed even on interfaces with > disabled forwarding. I agree. It seems also the text starting with "=ipv6/autoconf" should have been a separate paragraph. /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 Thu Jul 26 12:21:11 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57C8D21F85EA for ; Thu, 26 Jul 2012 12:21:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.402 X-Spam-Level: X-Spam-Status: No, score=-6.402 tagged_above=-999 required=5 tests=[AWL=0.197, 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 EhaHlbhN9wBS for ; Thu, 26 Jul 2012 12:21:10 -0700 (PDT) Received: from exprod5og117.obsmtp.com (exprod5og117.obsmtp.com [64.18.0.149]) by ietfa.amsl.com (Postfix) with ESMTP id 5111B21F85C3 for ; Thu, 26 Jul 2012 12:21:10 -0700 (PDT) Received: from alpmlip10.e2k.ad.ge.com ([12.43.191.1]) (using TLSv1) by exprod5ob117.postini.com ([64.18.4.12]) with SMTP ID DSNKUBGYpW/odhcjfhJPeh/bFNGbFKaIL6RA@postini.com; Thu, 26 Jul 2012 12:21:10 PDT Received: from unknown (HELO ALPMLEF02.e2k.ad.ge.com) ([3.159.18.11]) by alpmlip10.e2k.ad.ge.com with ESMTP; 26 Jul 2012 15:21:09 -0400 Received: from alpmlef03.e2k.ad.ge.com ([3.159.18.12]) by ALPMLEF02.e2k.ad.ge.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 26 Jul 2012 15:21:09 -0400 Received: from cinmlch01.e2k.ad.ge.com ([3.159.212.50]) by alpmlef03.e2k.ad.ge.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 26 Jul 2012 15:21:08 -0400 Received: from CINMBCNA05.e2k.ad.ge.com (3.159.212.59) by cinmlch01.e2k.ad.ge.com (3.159.212.50) with Microsoft SMTP Server (TLS) id 14.2.283.3; Thu, 26 Jul 2012 15:21:07 -0400 Received: from CINMBCNA02.e2k.ad.ge.com ([169.254.2.214]) by CINMBCNA05.e2k.ad.ge.com ([169.254.5.17]) with mapi id 14.02.0283.003; Thu, 26 Jul 2012 15:21:08 -0400 From: "Lange, Jeffrey K (GE Energy)" To: Juergen Schoenwaelder , "Patrick Gili (pgili)" Thread-Topic: [netmod] ietf-interfaces & vendor specific types Thread-Index: Ac1rOL4GcE2G9FPITNGjmmn1PX00ewAAvpWgABHwoYAACDHDIA== Date: Thu, 26 Jul 2012 19:21:07 +0000 Message-ID: References: <50E64ADF99EAEE4CACEC18958F0FC0AB01C707@xmb-aln-x14.cisco.com> <20120726190751.GA8248@elstar.local> In-Reply-To: <20120726190751.GA8248@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [3.159.212.187] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 26 Jul 2012 19:21:08.0699 (UTC) FILETIME=[CF4592B0:01CD6B63] Cc: "netmod@ietf.org" Subject: Re: [netmod] ietf-interfaces & vendor specific types 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, 26 Jul 2012 19:21:11 -0000 > I think we had this discussion before. The last time we went through this= , I > believe the WG favored a controlled central registry for interface types = since > this promotes interoperability. Is it really useful if every vendor comes= up with > his own interface types for say LTE interfaces? >=20 Yes, I agree that things like LTE should be maintained by a central registr= y, however we have many proprietary radio interfaces on our products that w= ould make absolutely no sense to have maintained by a central registry. I= contend that this is the purpose of the "other" value in the iftypes enum. -Jeff > /js >=20 > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 From lhotka@nic.cz Thu Jul 26 13:27:49 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C78211E80A4 for ; Thu, 26 Jul 2012 13:27:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.926 X-Spam-Level: X-Spam-Status: No, score=-1.926 tagged_above=-999 required=5 tests=[AWL=0.073, 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 mxp0pedM+oAa for ; Thu, 26 Jul 2012 13:27:48 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 846F011E8080 for ; Thu, 26 Jul 2012 13:27:48 -0700 (PDT) Received: from [172.29.2.201] (unknown [77.48.224.120]) by mail.nic.cz (Postfix) with ESMTPSA id A7CF313F633; Thu, 26 Jul 2012 22:27:47 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1343334467; bh=WO/V/SYx5yQGxqu6i4ILNJ2JIO+qkBy+3rLS1NFgTUg=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=bqOx6EUbjHuTX1c4n51smWXIcmsPmKss8LbZ9BnE9/7vq/shS9ZO6548I5x1yUkGq pm4H4uzzMZ1+CrimjfItF/gbtNocp8Pr1JQyvEyx4UWTQUeL3XaeYPOWNbTEA1cHL6 P8wg9rXDEIrCOr6GxPKqWJKiLZOfaJlDT+E30hCc= Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=windows-1252 From: Ladislav Lhotka In-Reply-To: <20120726191358.GB8248@elstar.local> Date: Thu, 26 Jul 2012 22:27:47 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <9720D470-1A60-4606-B4D4-061BFFF43352@nic.cz> References: <20120726191358.GB8248@elstar.local> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.1278) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] LL review of {interfaces,ip}-cfg-05 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, 26 Jul 2012 20:27:49 -0000 On Jul 26, 2012, at 9:13 PM, Juergen Schoenwaelder wrote: > On Thu, Jul 26, 2012 at 02:52:35PM +0200, Ladislav Lhotka wrote: >> Hi, >>=20 >> I read both drafts and I think overall they are in a good shape. My = issues are mostly common to both drafts so I will deal with them = together. >>=20 >> *** Technical >> My main concern is the lack of operational state data. For an = effective management, it is necessary to have operational info at least = in the extent provided by the "ip" command in Linux. I am not sure = whether the intention is (i) to develop other module(s) with this stuff = later, or (ii) to rely on SNMP for this purpose. >=20 > Since there is no general plan, the decision was to focus this work on > configuration at this point in time. I think the WG should come up with a general plan. >=20 >> *** Formal >> 1. The sections containing YANG code start with a sentence like >> "This YANG module imports a typedef from ...". Strictly speaking, >> this is not correct because the 'import' statement imports entire >> modules and not only selected items. On the other hand, this >> sentence is redundant because 'import' statements have a prominent >> place at the beginning of each module. I propose to remove these >> sentences and start each section right away with . >=20 > These sentence are there so that we have citations of the normative > references in the text (otherwise IETF tools yell at you). While it is > true that a YANG import imports a module, I think the current text is > not wrong - it actually adds additional clarity by stating what is > used from the module(s). Then it may be changed to: "This YANG module uses typedef XY from the = imported module =85". Lada >=20 >> 2. Section 6. ("Security Considerations") of ip-cfg-05, in the >> paragraph about "ipv4/ip-forwarding" and "ipv6/ip-forwarding": I >> propose to change both occurrences of "routing functions" to >> "forwarding functions", because other routing functions such as >> routing protocol exchange may be performed even on interfaces with >> disabled forwarding. >=20 > I agree. It seems also the text starting with "=3Dipv6/autoconf" = should > have been a separate paragraph. >=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 dromasca@avaya.com Thu Jul 26 21:29:43 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76A5211E80A3 for ; Thu, 26 Jul 2012 21:29:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.435 X-Spam-Level: X-Spam-Status: No, score=-103.435 tagged_above=-999 required=5 tests=[AWL=0.164, 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 l0BXEqRE3hZk for ; Thu, 26 Jul 2012 21:29:42 -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 5007911E8073 for ; Thu, 26 Jul 2012 21:29:41 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAL8YElCHCzI1/2dsb2JhbABCA7kzgQeCIAEBAQEDAQEBDx4KNAsMAgICAQgNAwEEAQELBgwLAQYBGgwfCQgBAQQBEggah2sLniOdQASLS4NTgkFgA5tFihCCYQ X-IronPort-AV: E=Sophos;i="4.77,664,1336363200"; d="scan'208";a="316556107" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 27 Jul 2012 00:25:27 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.13]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 27 Jul 2012 00:10:04 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 27 Jul 2012 06:29:35 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] ietf-interfaces & vendor specific types Thread-Index: Ac1rOL4GcE2G9FPITNGjmmn1PX00ewAAvpWgABHwoYAACDHDIAAC7XJQ References: <50E64ADF99EAEE4CACEC18958F0FC0AB01C707@xmb-aln-x14.cisco.com><20120726190751.GA8248@elstar.local> From: "Romascanu, Dan (Dan)" To: "Lange, Jeffrey K (GE Energy)" , "Juergen Schoenwaelder" , "PatrickGili (pgili)" Cc: netmod@ietf.org Subject: Re: [netmod] ietf-interfaces & vendor specific types 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, 27 Jul 2012 04:29:43 -0000 This is exactly why the 'other' value in the ifTypes enum occupies one and only one value. As advisor for IANA for the ifType registry I believe that defining vendor specific interfaces should remain the sole responsibility of vendors.=20 Regards, Dan > -----Original Message----- > From: netmod-bounces@ietf.org [mailto:netmod-bounces@ietf.org] On Behalf > Of Lange, Jeffrey K (GE Energy) > Sent: Thursday, July 26, 2012 10:21 PM > To: Juergen Schoenwaelder; PatrickGili (pgili) > Cc: netmod@ietf.org > Subject: Re: [netmod] ietf-interfaces & vendor specific types >=20 > > I think we had this discussion before. The last time we went through > > this, I believe the WG favored a controlled central registry for > > interface types since this promotes interoperability. Is it really > > useful if every vendor comes up with his own interface types for say > LTE interfaces? > > >=20 >=20 > Yes, I agree that things like LTE should be maintained by a central > registry, however we have many proprietary radio interfaces on our > products that would make absolutely no sense to have maintained by a > central registry. I contend that this is the purpose of the "other" > value in the iftypes enum. >=20 > -Jeff >=20 > > /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 Thu Jul 26 22:26:09 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78C5511E80CB for ; Thu, 26 Jul 2012 22:26:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.204 X-Spam-Level: X-Spam-Status: No, score=-103.204 tagged_above=-999 required=5 tests=[AWL=0.045, 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 P75jpj8WdBxM for ; Thu, 26 Jul 2012 22:26: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 1571711E80C9 for ; Thu, 26 Jul 2012 22:26:08 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id F395B20C17; Fri, 27 Jul 2012 07:26: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 49SC9tVIU4hK; Fri, 27 Jul 2012 07:26: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 4D67F20C13; Fri, 27 Jul 2012 07:26:06 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 9AAF020F59D0; Fri, 27 Jul 2012 07:26:04 +0200 (CEST) Date: Fri, 27 Jul 2012 07:26:04 +0200 From: Juergen Schoenwaelder To: "Romascanu, Dan (Dan)" Message-ID: <20120727052604.GA70066@elstar.local> Mail-Followup-To: "Romascanu, Dan (Dan)" , "Lange, Jeffrey K (GE Energy)" , "PatrickGili (pgili)" , netmod@ietf.org References: <50E64ADF99EAEE4CACEC18958F0FC0AB01C707@xmb-aln-x14.cisco.com> <20120726190751.GA8248@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] ietf-interfaces & vendor specific types 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, 27 Jul 2012 05:26:09 -0000 On Fri, Jul 27, 2012 at 06:29:35AM +0200, Romascanu, Dan (Dan) wrote: > This is exactly why the 'other' value in the ifTypes enum occupies one > and only one value. As advisor for IANA for the ifType registry I > believe that defining vendor specific interfaces should remain the sole > responsibility of vendors. But then we have rather recent additions of interface types such as vmwareNicTeam or vmwareVirtualNic. ;-) My concern is that many vendors might believe they have rather vendor specific interface types while this for some interfaces might just not be true. Like in the early days, people thought that an Ethernet interface running at different speeds needs to have different ifTypes values (and that got fixed in RFC 3635). I guess one of the problems with the IANA ifType registry is that the definition of what those allocated interface types are is somewhat lacking (usually just an expansion of the allocated name with some other acronyms in the comments). For me, a vendor specific interface is one that will never ever communicate with something built by a different vendor. /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 Jul 26 22:46:15 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3F4A21F842B for ; Thu, 26 Jul 2012 22:46:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.435 X-Spam-Level: X-Spam-Status: No, score=-103.435 tagged_above=-999 required=5 tests=[AWL=0.164, 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 YL49djb+A-EL for ; Thu, 26 Jul 2012 22:46:13 -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 1B24F21F842C for ; Thu, 26 Jul 2012 22:46:12 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAE8qElDGmAcF/2dsb2JhbABCA7k0gQeCIAEBAQEDEh4KPwwCAgIBCA0BAgEEAQEBCgYMCwEGARorCQgBAQQTCBqHa54snTwEi0uDU4JBYAOWXIRpihCCYQ X-IronPort-AV: E=Sophos;i="4.77,665,1336363200"; d="scan'208";a="316560308" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 27 Jul 2012 01:41:58 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.13]) by co300216-co-erhwest-out.avaya.com with ESMTP; 27 Jul 2012 01:42:00 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 27 Jul 2012 07:46:06 +0200 Message-ID: In-Reply-To: <20120727052604.GA70066@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] ietf-interfaces & vendor specific types Thread-Index: Ac1ruFPrHc0S8oomQra+ukLmOoCNMgAAl9ew References: <50E64ADF99EAEE4CACEC18958F0FC0AB01C707@xmb-aln-x14.cisco.com> <20120726190751.GA8248@elstar.local> <20120727052604.GA70066@elstar.local> From: "Romascanu, Dan (Dan)" To: "Juergen Schoenwaelder" Cc: netmod@ietf.org Subject: Re: [netmod] ietf-interfaces & vendor specific types 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, 27 Jul 2012 05:46:15 -0000 To get a new ifType assignment a vendor needs to show a specification that describes the layering model and the specific and presumably unique characteristics of the interface type, as well as the meaningful filling of the ifTable objects as per RFC 2863.=20 Dan > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs- > university.de] > Sent: Friday, July 27, 2012 8:26 AM > To: Romascanu, Dan (Dan) > Cc: Lange, Jeffrey K (GE Energy); PatrickGili (pgili); netmod@ietf.org > Subject: Re: [netmod] ietf-interfaces & vendor specific types >=20 > On Fri, Jul 27, 2012 at 06:29:35AM +0200, Romascanu, Dan (Dan) wrote: > > This is exactly why the 'other' value in the ifTypes enum occupies one > > and only one value. As advisor for IANA for the ifType registry I > > believe that defining vendor specific interfaces should remain the > > sole responsibility of vendors. >=20 > But then we have rather recent additions of interface types such as > vmwareNicTeam or vmwareVirtualNic. ;-) >=20 > My concern is that many vendors might believe they have rather vendor > specific interface types while this for some interfaces might just not > be true. Like in the early days, people thought that an Ethernet > interface running at different speeds needs to have different ifTypes > values (and that got fixed in RFC 3635). I guess one of the problems > with the IANA ifType registry is that the definition of what those > allocated interface types are is somewhat lacking (usually just an > expansion of the allocated name with some other acronyms in the > comments). For me, a vendor specific interface is one that will never > ever communicate with something built by a different vendor. >=20 > /js >=20 > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Thu Jul 26 23:33:42 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD5EC11E80D2 for ; Thu, 26 Jul 2012 23:33:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.204 X-Spam-Level: X-Spam-Status: No, score=-103.204 tagged_above=-999 required=5 tests=[AWL=0.045, 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 VSHepKCaBlmF for ; Thu, 26 Jul 2012 23:33:42 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 07D6411E80CD for ; Thu, 26 Jul 2012 23:33:42 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5E96620C12; Fri, 27 Jul 2012 08:33:41 +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 nLHtY_xjl9Bw; Fri, 27 Jul 2012 08:33:41 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C2D4B20BFA; Fri, 27 Jul 2012 08:33:40 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id D4CBC20F5BD3; Fri, 27 Jul 2012 08:33:39 +0200 (CEST) Date: Fri, 27 Jul 2012 08:33:39 +0200 From: Juergen Schoenwaelder To: "Romascanu, Dan (Dan)" Message-ID: <20120727063339.GA70211@elstar.local> Mail-Followup-To: "Romascanu, Dan (Dan)" , "Lange, Jeffrey K (GE Energy)" , "PatrickGili (pgili)" , netmod@ietf.org References: <50E64ADF99EAEE4CACEC18958F0FC0AB01C707@xmb-aln-x14.cisco.com> <20120726190751.GA8248@elstar.local> <20120727052604.GA70066@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] ietf-interfaces & vendor specific types 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, 27 Jul 2012 06:33:42 -0000 On Fri, Jul 27, 2012 at 07:46:06AM +0200, Romascanu, Dan (Dan) wrote: > To get a new ifType assignment a vendor needs to show a specification > that describes the layering model and the specific and presumably unique > characteristics of the interface type, as well as the meaningful filling > of the ifTable objects as per RFC 2863. This is good but unfortunately this useful information does not seem to be recorded in the IANA registry. (This comment applies to many allocations, whether initiated by a vendor or not - and allocated by a vendor may not be the same as vendor-specific allocation.) /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 Jul 27 06:44:23 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D59C821F86B4 for ; Fri, 27 Jul 2012 06:44:23 -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 ILqreF4ZvTja for ; Fri, 27 Jul 2012 06:44:23 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 202C221F86A4 for ; Fri, 27 Jul 2012 06:44:23 -0700 (PDT) Received: from dhcp-232.office.nic.cz (fw.nic.cz [217.31.207.1]) by mail.nic.cz (Postfix) with ESMTPSA id BDC81140892; Fri, 27 Jul 2012 15:44:21 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1343396661; bh=khrMRRzrNprBaoXRz9JqxQvV6kDOIwbsmZfspT1JmGU=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=suVyhIcq5w5VtdW5M8hAMiuBhqNsRfffBOmPv8wqjfuXdknVCJ+Wu7IXS0p3Q6FEU Et8/001DUTJSBTViDzJk3Mz2STOaZOvGx2QD/MTirs2mg59VEDw8x0SgyVEjYgbY7/ k2zNAQdx4H5rRGRbmiv5zguxHt2o4005rWGOjUIc= Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Ladislav Lhotka In-Reply-To: Date: Fri, 27 Jul 2012 15:44:20 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <50E64ADF99EAEE4CACEC18958F0FC0AB01C707@xmb-aln-x14.cisco.com> To: "Lange, Jeffrey K (GE Energy)" X-Mailer: Apple Mail (2.1278) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: "netmod@ietf.org" Subject: Re: [netmod] ietf-interfaces & vendor specific types 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, 27 Jul 2012 13:44:23 -0000 On Jul 26, 2012, at 7:10 PM, Lange, Jeffrey K (GE Energy) wrote: >>> Historically, I have had no difficulties using the web page IANA = makes >> available to register new interface types. >>>=20 >>> However, it brings up a relevant point. Wouldn't an identityref = better >> represent the notion of "interface type", thereby allowing vendors to = have >> vendor-specific interface types? It would somewhat simplify the >> administrative of interface types, as the IANA interface types have = been >> littered throughout the ages with interfaces types that were = ultimately vendor >> specific in nature. >>=20 >> This has already been discussed: >>=20 >> http://www.ietf.org/mail-archive/web/netmod/current/msg05913.html >>=20 >> In short: We need support for YANG identities in XPath expressions, >> otherwise the migration from enumerations to identities makes little = sense. >>=20 >> To this end, an XPath extension function (derived-from()) is already = waiting in >> the pipe, but unfortunately this requires an update to the YANG spec. >>=20 >=20 >=20 > I agree that having the derived-from would be a cleaner approach, but = what I'm suggesting is 1) possible today, and 2) creates a standard way = to deal with the already defined "other" iana-iftype enum value. I = clearly could Well, I guess the absence of derived-from() XPath function will have the = same consequences, e.g., if you wanted to add some nodes that are valid = only for certain if-types: qualified identity names won't work and the = derivation relations cannot be used. Lada=20 > augment the interfaces model to add this capability in my own vendor = specific extensions, but I think that this is something that other = people would also benefit from. And I would like to try to keep my = models as close to the standards as possible for obvious reasons. >=20 > And I don't think that asking IANA to add a truly vendor specific = interface type, that no other manufacturer in the world would be using, = to the public enumeration is a very good idea either. >=20 > -Jeff >=20 >> Lada >>=20 >>>=20 >>> Patrick Gili >>>=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From jeffrey.K.lange@ge.com Fri Jul 27 06:51:27 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA84021F86AA for ; Fri, 27 Jul 2012 06:51:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.41 X-Spam-Level: X-Spam-Status: No, score=-6.41 tagged_above=-999 required=5 tests=[AWL=0.188, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 52GUL9brKkWA for ; Fri, 27 Jul 2012 06:51:25 -0700 (PDT) Received: from exprod5og115.obsmtp.com (exprod5og115.obsmtp.com [64.18.0.246]) by ietfa.amsl.com (Postfix) with ESMTP id F0F8F21F865D for ; Fri, 27 Jul 2012 06:51:24 -0700 (PDT) Received: from cinmlip14.e2k.ad.ge.com ([12.71.149.1]) (using TLSv1) by exprod5ob115.postini.com ([64.18.4.12]) with SMTP ID DSNKUBKc2UyJysMAJ7rTjW4U6BwrFM6fodWL@postini.com; Fri, 27 Jul 2012 06:51:25 PDT Received: from unknown (HELO alpmlef01.e2k.ad.ge.com) ([3.159.18.10]) by cinmlip14.e2k.ad.ge.com with ESMTP; 27 Jul 2012 09:51:19 -0400 Received: from alpmlef03.e2k.ad.ge.com ([3.159.18.12]) by alpmlef01.e2k.ad.ge.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 27 Jul 2012 09:51:19 -0400 Received: from CINMLCH02.e2k.ad.ge.com ([3.159.212.51]) by alpmlef03.e2k.ad.ge.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 27 Jul 2012 09:46:15 -0400 Received: from CINMBCNA06.e2k.ad.ge.com (3.159.212.61) by CINMLCH02.e2k.ad.ge.com (3.159.212.51) with Microsoft SMTP Server (TLS) id 14.2.283.3; Fri, 27 Jul 2012 09:46:14 -0400 Received: from CINMBCNA02.e2k.ad.ge.com ([169.254.2.214]) by CINMBCNA06.e2k.ad.ge.com ([169.254.6.103]) with mapi id 14.02.0283.003; Fri, 27 Jul 2012 09:46:14 -0400 From: "Lange, Jeffrey K (GE Energy)" To: "netmod@ietf.org" Thread-Topic: ietf-ip and DHCP Thread-Index: Ac1r/N7aSPXzKcBmQBGV+frD8aJs+g== Date: Fri, 27 Jul 2012 13:46:13 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [3.159.212.187] Content-Type: multipart/alternative; boundary="_000_B0FB1FAC2C7B234D87DCEBF309F703C51BAB17AACINMBCNA02e2kad_" MIME-Version: 1.0 X-OriginalArrivalTime: 27 Jul 2012 13:46:15.0163 (UTC) FILETIME=[31010CB0:01CD6BFE] Subject: [netmod] ietf-ip and DHCP 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, 27 Jul 2012 13:51:28 -0000 --_000_B0FB1FAC2C7B234D87DCEBF309F703C51BAB17AACINMBCNA02e2kad_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I know in the past there was talk of creating a separate DHCP model. The m= ore I thought about it, the less it seemed to me like it should be a separa= te model rather than just some minor changes to the existing ip model. I h= ave taken a stab at what this modified model would look like. I borrowed t= he "configuration-source" grouping from the system model, as it already dea= lt with getting information from DHCP and/or local config. I added a simpl= e enable-dhcp Boolean to both the ipv4 and ipv6 containers, as well as a co= nfiguration-source. I also thought that a "dhcp-renew" RPC would be useful= as well. I debated a DHCP release RPC, but figured that just setting "ena= ble-dhcp" to false would serve the same purpose. If people think that is a valid approach, and is useful, it seems like the = duplication of the configuration-source between the system model and the ip= model could be eliminated by moving that into some common model. Here is the changes that I made to accomplish this. diff --git a/data_model/ietf-ip@2012-04-29.yang b/data_model/ietf-ip@2012-0= 4-29.yang index 9a42256..1e4ce06 100644 --- a/data_model/ietf-ip@2012-04-29.yang +++ b/data_model/ietf-ip@2012-04-29.yang @@ -51,12 +51,39 @@ module ietf-ip { subnet masks."; } + identity configuration-source { + description "Base for all configuration sources."; + } + + identity local-config { + base configuration-source; + description "Local configuration source."; + } + + identity dhcp { + base configuration-source; + description "DHCP configuration source."; + } + + grouping configuration-source { + leaf-list configuration-source { + ordered-by user; + type identityref { + base configuration-source; + } + description + "Indicates the ordered list of configuration source(s) + that should use for address information."; + } + } + augment "/if:interfaces/if:interface" { description "Parameters for configuring IP on interfaces. If an interface is not capable of running IP, the server must not allow the client to configure these parameters."; + container ipv4 { description "Parameters for the IPv4 address family."; @@ -67,6 +94,13 @@ module ietf-ip { "Controls if IPv4 is enabled or disabled on this interface."; } + leaf enable-dhcp { + type boolean; + default "false"; + description + "Controls if the DHCPv4 protocol will be used to obtain an + IPv4 Address on this interface."; + } leaf ip-forwarding { type boolean; default "false"; @@ -74,6 +108,9 @@ module ietf-ip { "Controls if IPv4 packet forwarding is enabled or disabled on this interface."; } + + uses configuration-source; + list address { key "ip"; description @@ -119,6 +156,13 @@ module ietf-ip { "Controls if IPv6 is enabled or disabled on this interface."; } + leaf enable-dhcp { + type boolean; + default "false"; + description + "Controls if the DHCPv6 protocol will be used to obtain an + IPv6 Address on this interface."; + } leaf ip-forwarding { type boolean; default "false"; @@ -129,6 +173,9 @@ module ietf-ip { "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) Section 6.2.1, IsRouter"; } + + uses configuration-source; + list address { key "ip"; description @@ -208,4 +255,21 @@ module ietf-ip { } } } + + rpc dhcp-renew { + description + "Manually renew the DHCP lease on the specified interface. + + If DHCP is not enabled on the specified interface,then this + operation will fail with error-tag 'invalid-value', + and error-app-tag value of 'dhcp-disabled'"; + input { + leaf interface { + type if:interface-ref; + mandatory true; + description + "The interface who's lease is to be renewed."; + } + } + } } -Jeff --_000_B0FB1FAC2C7B234D87DCEBF309F703C51BAB17AACINMBCNA02e2kad_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I know in the past there was talk of creating a sepa= rate DHCP model.  The more I thought about it, the less it seemed to m= e like it should be a separate model rather than just some minor changes to= the existing ip model.  I have taken a stab at what this modified model would look like.  I borrowed the = 220;configuration-source” grouping from the system model, as it alrea= dy dealt with getting information from DHCP and/or local config.  I ad= ded a simple enable-dhcp Boolean to both the ipv4 and ipv6 containers, as well as a configuration-source.  I also thought t= hat a “dhcp-renew” RPC would be useful as well.  I debated= a DHCP release RPC, but figured that just setting “enable-dhcp”= ; to false would serve the same purpose.

 

If people think that is a valid approach, and is use= ful, it seems like the duplication of the configuration-source between the = system model and the ip model could be eliminated by moving that into some = common model.

 

Here is the changes that I made to accomplish this.<= o:p>

 

diff --git a/data_model/ietf-ip@2012-04-29.yang b/da= ta_model/ietf-ip@2012-04-29.yang

index 9a42256..1e4ce06 100644

--- a/data_model/ietf-ip@2012-04-29.yang<= /p>

+++ b/data_model/ietf-ip@2012-04-29.yang=

@@ -51,12 +51,39 @@ module ietf-ip {<= /p>

        subnet ma= sks.";

   }

+  identity configuration-source {

+     description "Base= for all configuration sources.";

+  }

+

+  identity local-config {

+     base configuration-sou= rce;

+     description "Loca= l configuration source.";

+  }

+

+  identity dhcp {

+     base configuration-sou= rce;

+     description "DHCP= configuration source.";

+  }

+

+  grouping configuration-source {

+    leaf-list configuration-sour= ce {

+      ordered-by user;=

+      type identityref= {

+        = ; base configuration-source;

+      }

+      description=

+        &quo= t;Indicates the ordered list of configuration source(s)

+        = ; that should use for address information.";

+    }

+  }

+

   augment "/if:interfaces/if:interfa= ce" {

     description

       "Parameter= s for configuring IP on interfaces.

       

        If a= n interface is not capable of running IP, the server

        must not = allow the client to configure these parameters.";

+

     container ipv4 {=

       description

         &qu= ot;Parameters for the IPv4 address family.";

@@ -67,6 +94,13 @@ module ietf-ip {

        &nbs= p;  "Controls if IPv4 is enabled or disabled on this

        &nbs= p;   interface.";

       }

+      leaf enable-dhcp= {

+        type= boolean;

+        defa= ult "false";

+        desc= ription

+        = ;  "Controls if the DHCPv4 protocol will be used to obtain an

+        = ;   IPv4 Address on this interface.";

+      }

       leaf ip-forward= ing {

         typ= e boolean;

         def= ault "false";

@@ -74,6 +108,9 @@ module ietf-ip {

        &nbs= p;  "Controls if IPv4 packet forwarding is enabled or disabled

        &nbs= p;   on this interface.";

       }

+

+      uses configurati= on-source;

+

       list address {<= o:p>

         key= "ip";

         des= cription

@@ -119,6 +156,13 @@ module ietf-ip {=

        &nbs= p;  "Controls if IPv6 is enabled or disabled on this

        &nbs= p;   interface.";

       }

+      leaf enable-dhcp= {

+        type= boolean;

+        defa= ult "false";

+        desc= ription

+        = ;  "Controls if the DHCPv6 protocol will be used to obtain an

+        = ;   IPv6 Address on this interface.";

+      }

       leaf ip-forward= ing {

         typ= e boolean;

         def= ault "false";

@@ -129,6 +173,9 @@ module ietf-ip {<= /p>

        &nbs= p;  "RFC 4861: Neighbor Discovery for IP version 6 (IPv6)

        &nbs= p;             = Section 6.2.1, IsRouter";

       }

+

+      uses configurati= on-source;

+

       list address {<= o:p>

         key= "ip";

         des= cription

@@ -208,4 +255,21 @@ module ietf-ip {=

       }

     }

   }

+

+  rpc dhcp-renew {

+    description

+      "Manually r= enew the DHCP lease on the specified interface.

+

+       If DHCP is= not enabled on the specified interface,then this

+       operation = will fail with error-tag 'invalid-value',

+       and error-= app-tag value of 'dhcp-disabled'";

+    input {

+      leaf interface {=

+        type= if:interface-ref;

+        mand= atory true;

+        desc= ription

+        = ;  "The interface who's lease is to be renewed.";=

+      }

+    }

+  }

}

 

-Jeff

 

--_000_B0FB1FAC2C7B234D87DCEBF309F703C51BAB17AACINMBCNA02e2kad_-- From jeffrey.K.lange@ge.com Fri Jul 27 06:51:28 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 815D721F865D for ; Fri, 27 Jul 2012 06:51:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.12 X-Spam-Level: X-Spam-Status: No, score=-6.12 tagged_above=-999 required=5 tests=[AWL=-0.121, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jzMeEriXxfkZ for ; Fri, 27 Jul 2012 06:51:27 -0700 (PDT) Received: from exprod5og115.obsmtp.com (exprod5og115.obsmtp.com [64.18.0.246]) by ietfa.amsl.com (Postfix) with ESMTP id 7DAC221F8690 for ; Fri, 27 Jul 2012 06:51:27 -0700 (PDT) Received: from cinmlip14.e2k.ad.ge.com ([12.71.149.1]) (using TLSv1) by exprod5ob115.postini.com ([64.18.4.12]) with SMTP ID DSNKUBKc3TnHb0CMxH1tjalfmUbZ0utmXjm9@postini.com; Fri, 27 Jul 2012 06:51:27 PDT Received: from unknown (HELO alpmlef01.e2k.ad.ge.com) ([3.159.18.10]) by cinmlip14.e2k.ad.ge.com with ESMTP; 27 Jul 2012 09:51:20 -0400 Received: from alpmlef03.e2k.ad.ge.com ([3.159.18.12]) by alpmlef01.e2k.ad.ge.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 27 Jul 2012 09:51:19 -0400 Received: from CINMLCH02.e2k.ad.ge.com ([3.159.212.51]) by alpmlef03.e2k.ad.ge.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 27 Jul 2012 09:49:26 -0400 Received: from CINMBCNA04.e2k.ad.ge.com (3.159.212.58) by CINMLCH02.e2k.ad.ge.com (3.159.212.51) with Microsoft SMTP Server (TLS) id 14.2.283.3; Fri, 27 Jul 2012 09:49:25 -0400 Received: from CINMBCNA02.e2k.ad.ge.com ([169.254.2.214]) by CINMBCNA04.e2k.ad.ge.com ([169.254.4.115]) with mapi id 14.02.0283.003; Fri, 27 Jul 2012 09:49:25 -0400 From: "Lange, Jeffrey K (GE Energy)" To: Ladislav Lhotka Thread-Topic: [netmod] ietf-interfaces & vendor specific types Thread-Index: Ac1rOL4GcE2G9FPITNGjmmn1PX00ewAAvpWgAArxgoAABbiIQAAoRLsAAAhJW/A= Date: Fri, 27 Jul 2012 13:49:25 +0000 Message-ID: References: <50E64ADF99EAEE4CACEC18958F0FC0AB01C707@xmb-aln-x14.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [3.159.212.187] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 27 Jul 2012 13:49:26.0520 (UTC) FILETIME=[A30FCF80:01CD6BFE] Cc: "netmod@ietf.org" Subject: Re: [netmod] ietf-interfaces & vendor specific types 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, 27 Jul 2012 13:51:28 -0000 Well after much debate on this topic I guess I'll retreat and just implemen= t this in a vendor-specific model. =3D) -Jeff > -----Original Message----- > From: Ladislav Lhotka [mailto:lhotka@nic.cz] > Sent: Friday, July 27, 2012 9:44 AM > To: Lange, Jeffrey K (GE Energy) > Cc: netmod@ietf.org > Subject: Re: [netmod] ietf-interfaces & vendor specific types >=20 >=20 > On Jul 26, 2012, at 7:10 PM, Lange, Jeffrey K (GE Energy) wrote: >=20 > >>> Historically, I have had no difficulties using the web page IANA > >>> makes > >> available to register new interface types. > >>> > >>> However, it brings up a relevant point. Wouldn't an identityref > >>> better > >> represent the notion of "interface type", thereby allowing vendors to > >> have vendor-specific interface types? It would somewhat simplify the > >> administrative of interface types, as the IANA interface types have > >> been littered throughout the ages with interfaces types that were > >> ultimately vendor specific in nature. > >> > >> This has already been discussed: > >> > >> http://www.ietf.org/mail-archive/web/netmod/current/msg05913.html > >> > >> In short: We need support for YANG identities in XPath expressions, > >> otherwise the migration from enumerations to identities makes little s= ense. > >> > >> To this end, an XPath extension function (derived-from()) is already > >> waiting in the pipe, but unfortunately this requires an update to the = YANG > spec. > >> > > > > > > I agree that having the derived-from would be a cleaner approach, but > > what I'm suggesting is 1) possible today, and 2) creates a standard > > way to deal with the already defined "other" iana-iftype enum value. > > I clearly could >=20 > Well, I guess the absence of derived-from() XPath function will have the = same > consequences, e.g., if you wanted to add some nodes that are valid only f= or > certain if-types: qualified identity names won't work and the derivation > relations cannot be used. >=20 > Lada >=20 > > augment the interfaces model to add this capability in my own vendor > specific extensions, but I think that this is something that other people= would > also benefit from. And I would like to try to keep my models as close to= the > standards as possible for obvious reasons. > > > > And I don't think that asking IANA to add a truly vendor specific inter= face > type, that no other manufacturer in the world would be using, to the pub= lic > enumeration is a very good idea either. > > > > -Jeff > > > >> Lada > >> > >>> > >>> Patrick Gili > >>> >=20 > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C >=20 >=20 >=20 From andy@yumaworks.com Fri Jul 27 06:54:41 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4965521F86D4 for ; Fri, 27 Jul 2012 06:54:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.959 X-Spam-Level: X-Spam-Status: No, score=-2.959 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 R3bvNzfbUeim for ; Fri, 27 Jul 2012 06:54:40 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6AC2D21F86D7 for ; Fri, 27 Jul 2012 06:54:40 -0700 (PDT) Received: by lagv3 with SMTP id v3so2198788lag.31 for ; Fri, 27 Jul 2012 06:54:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=xZIhrljB624fjdMje/NkTcCZeEqUHhaBBP9EFfa2T5o=; b=cw0DBIZCGbbPpOM5+/i/qjIzu0jerA3mpntaSSC57pCL+s2hf6gFUxL8ADD7KPfoQS yPmLUuMm1FOjurEzNAHQi2l9ZtMRXW5V3sxREO3B7WwAg+wBgU6ne9UnLjnnDuh4D6dk 4AN4916VPwCzBRe6t5mjC/2hnNwuFz4xbh5Gbx5EstQTogjGhcPTo/F0AysC0SevGAoB 8ZyVUfXlB44EfuFagCwnO9YS2ePNYw7n9qWjEUxzM0+Yfdc+4bJZWexS3agHBH7C0sgf 1g7j57YnD41MKSiSaEqBdzMThqhQCe76L1zNBe1X6RbeOhDqSxcyB30NSfciaVRd20qJ txDw== MIME-Version: 1.0 Received: by 10.112.32.35 with SMTP id f3mr1443226lbi.47.1343397279305; Fri, 27 Jul 2012 06:54:39 -0700 (PDT) Received: by 10.114.19.72 with HTTP; Fri, 27 Jul 2012 06:54:39 -0700 (PDT) X-Originating-IP: [75.84.168.164] In-Reply-To: References: <50E64ADF99EAEE4CACEC18958F0FC0AB01C707@xmb-aln-x14.cisco.com> Date: Fri, 27 Jul 2012 06:54:39 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQk0rsKEba+k5+Nrr9HPKG6l+X5i34rhvQbR0n4z5A0Y/37mOanbOKld4ZqUNhKFicU3TJv2 Cc: "netmod@ietf.org" Subject: Re: [netmod] ietf-interfaces & vendor specific types 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, 27 Jul 2012 13:54:41 -0000 On Fri, Jul 27, 2012 at 6:44 AM, Ladislav Lhotka wrote: > > On Jul 26, 2012, at 7:10 PM, Lange, Jeffrey K (GE Energy) wrote: > >>>> Historically, I have had no difficulties using the web page IANA makes >>> available to register new interface types. >>>> >>>> However, it brings up a relevant point. Wouldn't an identityref better >>> represent the notion of "interface type", thereby allowing vendors to have >>> vendor-specific interface types? It would somewhat simplify the >>> administrative of interface types, as the IANA interface types have been >>> littered throughout the ages with interfaces types that were ultimately vendor >>> specific in nature. >>> >>> This has already been discussed: >>> >>> http://www.ietf.org/mail-archive/web/netmod/current/msg05913.html >>> >>> In short: We need support for YANG identities in XPath expressions, >>> otherwise the migration from enumerations to identities makes little sense. >>> >>> To this end, an XPath extension function (derived-from()) is already waiting in >>> the pipe, but unfortunately this requires an update to the YANG spec. >>> >> >> >> I agree that having the derived-from would be a cleaner approach, but what I'm suggesting is 1) possible today, and 2) creates a standard way to deal with the already defined "other" iana-iftype enum value. I clearly could > > Well, I guess the absence of derived-from() XPath function will have the same consequences, e.g., if you wanted to add some nodes that are valid only for certain if-types: qualified identity names won't work and the derivation relations cannot be used. > I'm not sure about the details of this new 'derived-from' function, but adding that feature to a server is new code no matter how it is done. For example, Yuma XPath knows about identityrefs and accepts local-name or YANG-prefix:local-name for an identityref leaf value. YANG-prefixes are the same for all QNodes specified in a must or when expr. This approach seems easier than creating new XPath functions. (BTW, not in a hurry to make any changes to YANG). > Lada Andy From lhotka@nic.cz Fri Jul 27 07:06:39 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F01B821F86C5 for ; Fri, 27 Jul 2012 07:06:39 -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 lL23-PaYaEwT for ; Fri, 27 Jul 2012 07:06:39 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 515DA21F87F5 for ; Fri, 27 Jul 2012 07:06:37 -0700 (PDT) Received: from dhcp-232.office.nic.cz (fw.nic.cz [217.31.207.1]) by mail.nic.cz (Postfix) with ESMTPSA id F40E7140892; Fri, 27 Jul 2012 16:06:34 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1343397995; bh=h069dEnHutBVdwUqStPScd1QuaNGN+qPssX768IsyfY=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=Bu0ZsO9dWe+C0IZEXilTtqdf8P8fhsbHS0X7awjU+kvtc7wX4VwZ8/MUSSt7omM49 NBeRRcgR7DakQGejnMFS4ydJbdJYiPqglDLscfQLxP30XcgNG5Ic91eQQ3bz/onjRI 8nFQr97GqXebpWHdBDz6rGsBdZzuw1PlbzRW+A8g= Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Ladislav Lhotka In-Reply-To: Date: Fri, 27 Jul 2012 16:06:34 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <2A72F737-5B3B-42CA-A0CA-DA263A7A1CE8@nic.cz> References: <50E64ADF99EAEE4CACEC18958F0FC0AB01C707@xmb-aln-x14.cisco.com> To: Andy Bierman X-Mailer: Apple Mail (2.1278) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: "netmod@ietf.org" Subject: Re: [netmod] ietf-interfaces & vendor specific types 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, 27 Jul 2012 14:06:40 -0000 On Jul 27, 2012, at 3:54 PM, Andy Bierman wrote: > On Fri, Jul 27, 2012 at 6:44 AM, Ladislav Lhotka = wrote: >>=20 >> On Jul 26, 2012, at 7:10 PM, Lange, Jeffrey K (GE Energy) wrote: >>=20 >>>>> Historically, I have had no difficulties using the web page IANA = makes >>>> available to register new interface types. >>>>>=20 >>>>> However, it brings up a relevant point. Wouldn't an identityref = better >>>> represent the notion of "interface type", thereby allowing vendors = to have >>>> vendor-specific interface types? It would somewhat simplify the >>>> administrative of interface types, as the IANA interface types have = been >>>> littered throughout the ages with interfaces types that were = ultimately vendor >>>> specific in nature. >>>>=20 >>>> This has already been discussed: >>>>=20 >>>> http://www.ietf.org/mail-archive/web/netmod/current/msg05913.html >>>>=20 >>>> In short: We need support for YANG identities in XPath expressions, >>>> otherwise the migration from enumerations to identities makes = little sense. >>>>=20 >>>> To this end, an XPath extension function (derived-from()) is = already waiting in >>>> the pipe, but unfortunately this requires an update to the YANG = spec. >>>>=20 >>>=20 >>>=20 >>> I agree that having the derived-from would be a cleaner approach, = but what I'm suggesting is 1) possible today, and 2) creates a standard = way to deal with the already defined "other" iana-iftype enum value. I = clearly could >>=20 >> Well, I guess the absence of derived-from() XPath function will have = the same consequences, e.g., if you wanted to add some nodes that are = valid only for certain if-types: qualified identity names won't work and = the derivation relations cannot be used. >>=20 >=20 > I'm not sure about the details of this new 'derived-from' function, > but adding that feature to a server is new code no matter how it is = done. > For example, Yuma XPath knows about identityrefs and accepts = local-name > or YANG-prefix:local-name for an identityref leaf value. = YANG-prefixes are > the same for all QNodes specified in a must or when expr. This = approach > seems easier than creating new XPath functions. (BTW, not in a hurry > to make any changes to YANG). But it also means that Yuma XPath is not XPath anymore, and different = YANG implementations can give different results. In contrast, extension = functions are a well-established concept in XPath (and YANG already uses = one - current()), so I think it is a much cleaner approach. For one, new = functions make the deviation from standard XPath explicit. Lada >=20 >=20 >> Lada >=20 > Andy -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From lhotka@nic.cz Fri Jul 27 07:49:24 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F74A21F87C8 for ; Fri, 27 Jul 2012 07:49:24 -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 eBaE9gBQefUX for ; Fri, 27 Jul 2012 07:49:23 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 926B621F87C1 for ; Fri, 27 Jul 2012 07:49:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id BE7B3540648 for ; Fri, 27 Jul 2012 16:49:21 +0200 (CEST) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YnHHHiUbET2f for ; Fri, 27 Jul 2012 16:49:17 +0200 (CEST) Received: from localhost (fw.nic.cz [217.31.207.1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 3466C5401EC for ; Fri, 27 Jul 2012 16:49:16 +0200 (CEST) From: Ladislav Lhotka To: netmod@ietf.org In-Reply-To: <20120726191358.GB8248@elstar.local> References: <20120726191358.GB8248@elstar.local> User-Agent: Notmuch/0.13.2+77~g39beeb2 (http://notmuchmail.org) Emacs/23.3.50.1 (i386-apple-darwin9.8.0) Mail-Followup-To: netmod@ietf.org Date: Fri, 27 Jul 2012 16:49:15 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [netmod] LL review of {interfaces,ip}-cfg-05 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, 27 Jul 2012 14:49:24 -0000 Juergen Schoenwaelder writes: >> *** Formal >> 1. The sections containing YANG code start with a sentence like >> "This YANG module imports a typedef from ...". Strictly speaking, >> this is not correct because the 'import' statement imports entire >> modules and not only selected items. On the other hand, this >> sentence is redundant because 'import' statements have a prominent >> place at the beginning of each module. I propose to remove these >> sentences and start each section right away with . > > These sentence are there so that we have citations of the normative > references in the text (otherwise IETF tools yell at you). While it is In the routing draft, I (unintentionally) implemented another workaround: a table in sec. 2.2 showing the correspondence between prefixes and module names, with references to the normative documents. This seems more useful than the introductory sequences, especially if some of the prefixes are used in the main text. Lada > true that a YANG import imports a module, I think the current text is > not wrong - it actually adds additional clarity by stating what is > used from the module(s). > >> 2. Section 6. ("Security Considerations") of ip-cfg-05, in the >> paragraph about "ipv4/ip-forwarding" and "ipv6/ip-forwarding": I >> propose to change both occurrences of "routing functions" to >> "forwarding functions", because other routing functions such as >> routing protocol exchange may be performed even on interfaces with >> disabled forwarding. > > I agree. It seems also the text starting with "=ipv6/autoconf" should > have been a separate paragraph. > > /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 andy@yumaworks.com Fri Jul 27 07:53:18 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71AE421F87CC for ; Fri, 27 Jul 2012 07:53:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.659 X-Spam-Level: X-Spam-Status: No, score=-2.659 tagged_above=-999 required=5 tests=[AWL=-0.282, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 UxqjlEYHVOEB for ; Fri, 27 Jul 2012 07:53:17 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 65CB521F87C7 for ; Fri, 27 Jul 2012 07:53:17 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so2356039lbb.31 for ; Fri, 27 Jul 2012 07:53:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding:x-gm-message-state; bh=wlw6IZEfBwyLAfw4nlF1RIpJq8n/n9+DHDSb9KTb7cw=; b=QzGiiwbklSQFEnudxlimtLKD9P++IFMQJyjOX+Fi2sb5Pz7g1qWrxE+eYfALpO1f1z D4cSef6jeRYqH4e0c2FpKBHuAuD7xZVHM4twVQvcevlD2BbyNjH+Q8ne5HI7BYxzbZAd EeXok+xakkXZ5v6unBP8UOVmaA1l8EA8UB8AlsUequLCrmCGfcCHSDGVX/gmsPxhqlZM eyul3fBTlBZ5FYKeqH60r4vMpixQOjovM1xs1rKkvki28qT2LfFSieDh/6Ojfw0IfoLj NhNBKR2wjdwbHpMswo/Fs7uXRXoOR2St2bmTATi/JE6TAalVseEF/OQ9kcXlQuKvX5/k QlXw== MIME-Version: 1.0 Received: by 10.152.132.233 with SMTP id ox9mr2845432lab.25.1343400796321; Fri, 27 Jul 2012 07:53:16 -0700 (PDT) Received: by 10.114.19.72 with HTTP; Fri, 27 Jul 2012 07:53:16 -0700 (PDT) X-Originating-IP: [75.84.168.164] In-Reply-To: <2A72F737-5B3B-42CA-A0CA-DA263A7A1CE8@nic.cz> References: <50E64ADF99EAEE4CACEC18958F0FC0AB01C707@xmb-aln-x14.cisco.com> <2A72F737-5B3B-42CA-A0CA-DA263A7A1CE8@nic.cz> Date: Fri, 27 Jul 2012 07:53:16 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQn6ikUOHTTKxuOiSeazB/sj3noTTcamV5GdosvEzXISxK4HzS/bg5AA/Z62OEJW4bQ0rsfw Cc: "netmod@ietf.org" Subject: Re: [netmod] ietf-interfaces & vendor specific types 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, 27 Jul 2012 14:53:18 -0000 On Fri, Jul 27, 2012 at 7:06 AM, Ladislav Lhotka wrote: > > On Jul 27, 2012, at 3:54 PM, Andy Bierman wrote: > >> On Fri, Jul 27, 2012 at 6:44 AM, Ladislav Lhotka wrote: >>> >>> On Jul 26, 2012, at 7:10 PM, Lange, Jeffrey K (GE Energy) wrote: >>> >>>>>> Historically, I have had no difficulties using the web page IANA mak= es >>>>> available to register new interface types. >>>>>> >>>>>> However, it brings up a relevant point. Wouldn't an identityref bett= er >>>>> represent the notion of "interface type", thereby allowing vendors to= have >>>>> vendor-specific interface types? It would somewhat simplify the >>>>> administrative of interface types, as the IANA interface types have b= een >>>>> littered throughout the ages with interfaces types that were ultimate= ly vendor >>>>> specific in nature. >>>>> >>>>> This has already been discussed: >>>>> >>>>> http://www.ietf.org/mail-archive/web/netmod/current/msg05913.html >>>>> >>>>> In short: We need support for YANG identities in XPath expressions, >>>>> otherwise the migration from enumerations to identities makes little = sense. >>>>> >>>>> To this end, an XPath extension function (derived-from()) is already = waiting in >>>>> the pipe, but unfortunately this requires an update to the YANG spec. >>>>> >>>> >>>> >>>> I agree that having the derived-from would be a cleaner approach, but = what I'm suggesting is 1) possible today, and 2) creates a standard way to = deal with the already defined "other" iana-iftype enum value. I clearly co= uld >>> >>> Well, I guess the absence of derived-from() XPath function will have th= e same consequences, e.g., if you wanted to add some nodes that are valid o= nly for certain if-types: qualified identity names won't work and the deriv= ation relations cannot be used. >>> >> >> I'm not sure about the details of this new 'derived-from' function, >> but adding that feature to a server is new code no matter how it is done= . >> For example, Yuma XPath knows about identityrefs and accepts local-name >> or YANG-prefix:local-name for an identityref leaf value. YANG-prefixes = are >> the same for all QNodes specified in a must or when expr. This approach >> seems easier than creating new XPath functions. (BTW, not in a hurry >> to make any changes to YANG). > > But it also means that Yuma XPath is not XPath anymore, and different YAN= G implementations can give different results. In contrast, extension functi= ons are a well-established concept in XPath (and YANG already uses one - cu= rrent()), so I think it is a much cleaner approach. For one, new functions = make the deviation from standard XPath explicit. > You are probably right, but the common thing to do is just use the local-na= me and reference an identity defined in the module. So the QName version is not used very often. (Also yuma treats XPath prefixes in YANG stmts as module prefixes but the XPath select parameter always uses XML prefixes. Don't we need more than an XPath function? What about comparing nodes (when "/foo/idref1 =3D /foo/idref2";) We want 'foo:bar1' and 'bar1' to compare equal (bar1 defined in the foo mod= ule). (e.g., when "idref(/foo/bar1) =3D idref(/foo/bar2)";) The nodeset may not be derived from a simple path-expr like this. It may not be possible to always wrap an idref value in this special XPath function. Either the XPath parser knows it is dealing with an identityref, or some times these nodes will be compared as simple strings. The values come from the internal database, not the XPath expr. > Lada > Andy >> >> >>> Lada >> >> Andy > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > From dromasca@avaya.com Fri Jul 27 09:58:31 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AD9611E80D6 for ; Fri, 27 Jul 2012 09:58:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.436 X-Spam-Level: X-Spam-Status: No, score=-103.436 tagged_above=-999 required=5 tests=[AWL=0.163, 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 fPy821-Z3+yV for ; Fri, 27 Jul 2012 09:58:30 -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 9DD7311E80BF for ; Fri, 27 Jul 2012 09:58:29 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAL7HElCHCzI1/2dsb2JhbABFuU+BB4IgAQEBAQMSHgo/DAQCAQgNAQIBBAEBAQoGDAsBBgFFCQgBAQQTCBqHa503nWKLUIYUYAOWXIRpihCCYQ X-IronPort-AV: E=Sophos;i="4.77,668,1336363200"; d="scan'208";a="359255966" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 27 Jul 2012 12:54:39 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.13]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 27 Jul 2012 12:38:52 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 27 Jul 2012 18:58:24 +0200 Message-ID: In-Reply-To: <20120727063339.GA70211@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] ietf-interfaces & vendor specific types Thread-Index: Ac1rwcXeWWoidmvKSsiGnX7YY0w0cwAVr3+w References: <50E64ADF99EAEE4CACEC18958F0FC0AB01C707@xmb-aln-x14.cisco.com> <20120726190751.GA8248@elstar.local> <20120727052604.GA70066@elstar.local> <20120727063339.GA70211@elstar.local> From: "Romascanu, Dan (Dan)" To: "Juergen Schoenwaelder" Cc: netmod@ietf.org Subject: Re: [netmod] ietf-interfaces & vendor specific types 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, 27 Jul 2012 16:58:31 -0000 > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs- > university.de] > Sent: Friday, July 27, 2012 9:34 AM > To: Romascanu, Dan (Dan) > Cc: Lange, Jeffrey K (GE Energy); PatrickGili (pgili); netmod@ietf.org > Subject: Re: [netmod] ietf-interfaces & vendor specific types >=20 > On Fri, Jul 27, 2012 at 07:46:06AM +0200, Romascanu, Dan (Dan) wrote: > > To get a new ifType assignment a vendor needs to show a specification > > that describes the layering model and the specific and presumably > > unique characteristics of the interface type, as well as the > > meaningful filling of the ifTable objects as per RFC 2863. >=20 > This is good but unfortunately this useful information does not seem to > be recorded in the IANA registry. (This comment applies to many > allocations, whether initiated by a vendor or not - and allocated by a > vendor may not be the same as vendor-specific allocation.) >=20 > /js >=20 > Well, the IANA registry is actually a MIB module containing the TC with the enumeration, as you know. We can ask IANA to record as comments or separately a pointer to the specification and/or contact information to the owners Dan From lhotka@nic.cz Fri Jul 27 11:26:09 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10EB211E8096 for ; Fri, 27 Jul 2012 11:26:09 -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 Kb9Pv3glUKAG for ; Fri, 27 Jul 2012 11:26: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 4EFA311E808C for ; Fri, 27 Jul 2012 11:26:08 -0700 (PDT) Received: from [10.0.0.3] (128.211.broadband6.iol.cz [88.101.211.128]) by mail.nic.cz (Postfix) with ESMTPSA id 72AAD14035C; Fri, 27 Jul 2012 20:26:06 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1343413567; bh=7CxsNr6yaZS7ODQfcGI8y7atA82sBnfwJY8IldAfNO4=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=xroEeRWF+GQyJmE1ipyemJyzc/z/+URhHLIJDZxpIPZ1wfhGrBKvhFyehPy3pFIUi 7zoJIy4jW6ElSXJbdZhBye3jMDcQn7HaAi8g30wX+kKaKN0GGuaN3lUTWIN1MYRTUV WL51siZztuCWCCzuNCnZo2u2eNKREoeMWUHJW4Dw= Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Ladislav Lhotka In-Reply-To: Date: Fri, 27 Jul 2012 20:26:06 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <50E64ADF99EAEE4CACEC18958F0FC0AB01C707@xmb-aln-x14.cisco.com> <20120726190751.GA8248@elstar.local> <20120727052604.GA70066@elstar.local> <20120727063339.GA70211@elstar.local> To: "Romascanu, Dan (Dan)" X-Mailer: Apple Mail (2.1278) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] ietf-interfaces & vendor specific types 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, 27 Jul 2012 18:26:09 -0000 On Jul 27, 2012, at 6:58 PM, Romascanu, Dan (Dan) wrote: >=20 >=20 >=20 >> -----Original Message----- >> From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs- >> university.de] >> Sent: Friday, July 27, 2012 9:34 AM >> To: Romascanu, Dan (Dan) >> Cc: Lange, Jeffrey K (GE Energy); PatrickGili (pgili); = netmod@ietf.org >> Subject: Re: [netmod] ietf-interfaces & vendor specific types >>=20 >> On Fri, Jul 27, 2012 at 07:46:06AM +0200, Romascanu, Dan (Dan) wrote: >>> To get a new ifType assignment a vendor needs to show a > specification >>> that describes the layering model and the specific and presumably >>> unique characteristics of the interface type, as well as the >>> meaningful filling of the ifTable objects as per RFC 2863. >>=20 >> This is good but unfortunately this useful information does not seem > to >> be recorded in the IANA registry. (This comment applies to many >> allocations, whether initiated by a vendor or not - and allocated by = a >> vendor may not be the same as vendor-specific allocation.) >>=20 >> /js >>=20 >>=20 >=20 > Well, the IANA registry is actually a MIB module containing the TC = with > the enumeration, as you know. We can ask IANA to record as comments or > separately a pointer to the specification and/or contact information = to > the owners I don't know about ifType but I found out that = IANA-ADDRESS-FAMILY-NUMBERS-MIB is not kept in sync with the list = published on IANA web: = http://www.iana.org/assignments/address-family-numbers/address-family-numb= ers.xml So I assume the web list is the authoritative resource. Lada >=20 >=20 > Dan >=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 yiya@cisco.com Fri Jul 27 11:49:55 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAE8721F8437 for ; Fri, 27 Jul 2012 11:49:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[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 wtWYEUlr7XrK for ; Fri, 27 Jul 2012 11:49:55 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id F10D721F866D for ; Fri, 27 Jul 2012 11:49:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=yiya@cisco.com; l=522; q=dns/txt; s=iport; t=1343414995; x=1344624595; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=Y2tL6cHb5EGNljf2NnXg47d+8Vy1ua2Fvj/oLNNwI8o=; b=VQiM2L9ryPuV9MR64S47uPf/AEf+Msysqn+HP2k+vUPgEhTe0NnnOF1e XGcr2QaiLJbdW9jHJgEJFLZXByWfqOQR4F/fVVfnDeVWrVY+wCcbEa48S RPPmwn4dU6zGtjsORS2j6Hl7mzOIlpTVoyWVBZu6aTdGqwJiR+6V2HqQJ s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAE7iElCtJV2a/2dsb2JhbABFuVCBB4InEgEnUQE+QicEATSHa5pKoFqRZGADlUiOJ4Fmgl+BViM X-IronPort-AV: E=Sophos;i="4.77,668,1336348800"; d="scan'208";a="106074365" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-5.cisco.com with ESMTP; 27 Jul 2012 18:49:54 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q6RInsr6008674 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 27 Jul 2012 18:49:54 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.91]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.02.0298.004; Fri, 27 Jul 2012 13:49:54 -0500 From: "Yi Yang (yiya)" To: "netmod@ietf.org" , "lhotka@nic.cz" Thread-Topic: comments on draft-ietf-netmod-routing-cfg-04 Thread-Index: AQHNbCicgjImo6D/hUmbbdTBxQ8JeQ== Date: Fri, 27 Jul 2012 18:49:53 +0000 Message-ID: <45BE39D9-2E92-4139-B579-B125649CD287@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.75.7] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19066.004 x-tm-as-result: No--26.022300-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <162CC73563BDEC4EAE433D8BC8F02B19@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [netmod] comments on draft-ietf-netmod-routing-cfg-04 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, 27 Jul 2012 18:49:56 -0000 Hi Lavislav, Here are my comments for the current draft: 1. How about to add a leaf "enabled" (default "true") under routing-protoco= l? Administrator may choose to temporarily disable a routing protocol insta= nce for troubleshooting. 2. Add a leaf "isActive" under route -- The value should be true if the rou= te is being used for forwarding. An reply to the NETCONF (like the ex= ample in the appendix B) will not only give the whole routing table but als= o shows which routes are active. Yi= From j.schoenwaelder@jacobs-university.de Fri Jul 27 15:15:59 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A87B21F861E for ; Fri, 27 Jul 2012 15:15:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.204 X-Spam-Level: X-Spam-Status: No, score=-103.204 tagged_above=-999 required=5 tests=[AWL=0.045, 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 xp3rdDcq4PTf for ; Fri, 27 Jul 2012 15:15: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 2C58D21F861D for ; Fri, 27 Jul 2012 15:15:58 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7176720BED; Sat, 28 Jul 2012 00:15:56 +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 RfFDwc8BJgLk; Sat, 28 Jul 2012 00:15: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 9D20120BEA; Sat, 28 Jul 2012 00:15:55 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 21B8020F7CF5; Sat, 28 Jul 2012 00:15:53 +0200 (CEST) Date: Sat, 28 Jul 2012 00:15:53 +0200 From: Juergen Schoenwaelder To: "Romascanu, Dan (Dan)" Message-ID: <20120727221553.GA71797@elstar.local> Mail-Followup-To: "Romascanu, Dan (Dan)" , "Lange, Jeffrey K (GE Energy)" , "PatrickGili (pgili)" , netmod@ietf.org References: <50E64ADF99EAEE4CACEC18958F0FC0AB01C707@xmb-aln-x14.cisco.com> <20120726190751.GA8248@elstar.local> <20120727052604.GA70066@elstar.local> <20120727063339.GA70211@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] ietf-interfaces & vendor specific types 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, 27 Jul 2012 22:15:59 -0000 On Fri, Jul 27, 2012 at 06:58:24PM +0200, Romascanu, Dan (Dan) wrote: > > > > > -----Original Message----- > > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs- > > university.de] > > Sent: Friday, July 27, 2012 9:34 AM > > To: Romascanu, Dan (Dan) > > Cc: Lange, Jeffrey K (GE Energy); PatrickGili (pgili); netmod@ietf.org > > Subject: Re: [netmod] ietf-interfaces & vendor specific types > > > > On Fri, Jul 27, 2012 at 07:46:06AM +0200, Romascanu, Dan (Dan) wrote: > > > To get a new ifType assignment a vendor needs to show a > specification > > > that describes the layering model and the specific and presumably > > > unique characteristics of the interface type, as well as the > > > meaningful filling of the ifTable objects as per RFC 2863. > > > > This is good but unfortunately this useful information does not seem > to > > be recorded in the IANA registry. (This comment applies to many > > allocations, whether initiated by a vendor or not - and allocated by a > > vendor may not be the same as vendor-specific allocation.) > > > > /js > > > > > > Well, the IANA registry is actually a MIB module containing the TC with > the enumeration, as you know. We can ask IANA to record as comments or > separately a pointer to the specification and/or contact information to > the owners My understanding is that the IANA registry is here http://www.iana.org/assignments/smi-numbers (you have to scroll a bit) and the MIB module is a machine readable serialization of it (and the YANG module would be another serialization). While IANA seems to maintain data internally in an XML format these days, there is no automated generation of derived serializations, at least this was true when we talked to IANA. At that time (some IETFs ago), IANA said updates are rare enough that automating things is not necessary. The registry actually contains a pointer who requested the entry. But that is all, no additional information seems to be linked (except allocations described in RFCs). /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 Jul 27 16:43:49 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CEF521F8685; Fri, 27 Jul 2012 16:43:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.398 X-Spam-Level: X-Spam-Status: No, score=-10.398 tagged_above=-999 required=5 tests=[AWL=0.200, 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 bMgmpn9tRTzD; Fri, 27 Jul 2012 16:43:47 -0700 (PDT) Received: from av-tac-sj.cisco.com (av-tac-sj.cisco.com [171.68.227.119]) by ietfa.amsl.com (Postfix) with ESMTP id 9C9A721F8682; Fri, 27 Jul 2012 16:43:47 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from fire.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-sj.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q6RNhk7E014746; Fri, 27 Jul 2012 16:43:46 -0700 (PDT) Received: from [10.21.64.247] (sjc-vpn3-247.cisco.com [10.21.64.247]) by fire.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q6RNhkA2019072; Fri, 27 Jul 2012 16:43:46 -0700 (PDT) Message-ID: <501327B2.6040208@cisco.com> Date: Fri, 27 Jul 2012 16:43:46 -0700 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: attendees <84attendees@ietf.org>, NETCONF , NETMOD Working Group Content-Type: multipart/alternative; boundary="------------000101040303070403030704" Subject: [netmod] Network Configuration Management with NETCONF and YANG Tutorial this Sunday 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, 27 Jul 2012 23:43:49 -0000 This is a multi-part message in MIME format. --------------000101040303070403030704 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear all, The "NETCONF and YANG" tutorial was added late to the agenda. So if you registered early, maybe you missed this tutorial announcement. Hence this email: 1300-1450 Network Configuration Management with NETCONF and YANG Tutorial - Regency E Regards, Benoit. --------------000101040303070403030704 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear all,

The "NETCONF and YANG" tutorial was added late to the agenda.
So if you registered early, maybe you missed this tutorial announcement.
Hence this email:
1300-1450 Network Configuration Management with NETCONF and YANG Tutorial - Regency E

Regards, Benoit.

--------------000101040303070403030704-- From andy@yumaworks.com Sat Jul 28 16:34:03 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C99D621F86AB for ; Sat, 28 Jul 2012 16:34:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 O0JpqMWzrW-d for ; Sat, 28 Jul 2012 16:34:03 -0700 (PDT) Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2D18721F8499 for ; Sat, 28 Jul 2012 16:34:03 -0700 (PDT) Received: by qadz3 with SMTP id z3so345289qad.10 for ; Sat, 28 Jul 2012 16:34:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=ECwYtMwBInYdIDVdqRhQblEkGFZn2Qg3tFfstEsE5gM=; b=ljPaQFKsNTmpwmbQhhAyUcbw3+PUtoBxexUESSlZPCK8gHkK2noWFxipEpUe9Q4mhZ 22p9lvWsqHoluMfMVwJOPhIekDp88KHL1fbz/iMIlPXCtECCgR+A0Z4rsNS9ttNYXVKB fg1CTdTs3/0G76ocF7GmSvbk4inaBLE09bnmfnRSUvHDGAS2Lz/OTrGSWPaR3J0+Ov5T mkieSxZm2wxMUc4DkPVNdGiuWvBRnUXcJyBgz2I6lcM9GgQXx0p1W2nzMdNXK+UdMPZs oynIeCz6ygtFcNNE695Drgvry7Zz3RWR13xz+vaYgp74Xu5vCfzXyvEd+bzWntdZXYJo B/zw== MIME-Version: 1.0 Received: by 10.224.185.70 with SMTP id cn6mr16072939qab.16.1343518442388; Sat, 28 Jul 2012 16:34:02 -0700 (PDT) Received: by 10.49.51.163 with HTTP; Sat, 28 Jul 2012 16:34:02 -0700 (PDT) X-Originating-IP: [2001:df8:0:64:4000:84e7:d33d:37e5] Date: Sat, 28 Jul 2012 16:34:02 -0700 Message-ID: From: Andy Bierman To: netmod@ietf.org Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQnTG8n4N/FStVeqNnpfaIB7uDDKd0o38hjmoacu1har+EUPmvah8y+hVC+J22ZC+M7vKQjU Subject: [netmod] XPath errors in ietf-snmp.yang 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, 28 Jul 2012 23:34:03 -0000 Hi, I am getting lots of XPath errors reported from yangdump: *** Generated by yangdump 5.0.da08cd7 *** Copyright (c) 2008-2012, Andy Bierman, All Rights Reserved. Warning: no child nodes found in XPath expr '../type = read or ../type = write' ietf-snmp-proxy.yang:114.24: warning(432): no child node available Warning: no child nodes found in XPath expr '../type = read or ../type = write' ietf-snmp-proxy.yang:114.42: warning(432): no child node available Warning: no child nodes found in XPath expr '../type = trap or ../type = inform' ietf-snmp-proxy.yang:123.24: warning(432): no child node available Warning: no child nodes found in XPath expr '../type = trap or ../type = inform' ietf-snmp-proxy.yang:123.42: warning(432): no child node available These errors in ietf-snmp-proxy.yang are because the strings need to be quoted. When unquoted, they are XPath node names, not strings. e.g.: ../type = 'trap' or ../type = 'inform' Warning: no child nodes found in XPath expr 'snmp:params/snmp:v1 or snmp:params/snmp:v2c' ietf-snmp-community.yang:196.12: warning(432): no child node available Warning: no child nodes found in XPath expr 'snmp:params/snmp:v1 or snmp:params/snmp:v2c' ietf-snmp-community.yang:196.35: warning(432): no child node available There is a missing '/' so XPath this is supposed to be a child node e.g. /snmp:params/snmp:v1 Warning: no child nodes found in XPath expr '/snmp/usm/remote[engine-id=current()]/user[name=current()/../usm/user-name]' ietf-snmp-usm.yang:194.13: warning(432): no child node available Warning: no child nodes found in XPath expr '/snmp/usm/remote[engine-id=current()]/user[name=current()/../usm/user-name]' ietf-snmp-usm.yang:194.29: warning(432): no child node available Warning: no child nodes found in XPath expr '/snmp/usm/remote[engine-id=current()]/user[name=current()/../usm/user-name]' ietf-snmp-usm.yang:194.55: warning(432): no child node available Not sure if the 3 errors above are yangdump problems or due to restrictions on what can be referenced within an augment-stmt. The XPath and combination of uses and augments is complicated to follow, so not sure if it is correct yet. Warning: no child nodes found in XPath expr '../map-type = snmp:specified' ietf-snmp-tls.yang:174.30: warning(432): no child node available Not sure what snmp:specified is -- XPath thinks it is a node name because this is an unquoted string. There is no child 'specified' under this leaf. *** /usr/share/yuma/modules/ietf/ietf-snmp.yang *** 0 Errors, 10 Warnings From dromasca@avaya.com Sat Jul 28 17:36:37 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40E1821F86AB for ; Sat, 28 Jul 2012 17:36:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.426 X-Spam-Level: X-Spam-Status: No, score=-103.426 tagged_above=-999 required=5 tests=[AWL=0.173, 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 u5hUwaqpwFxx for ; Sat, 28 Jul 2012 17:36:36 -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 4683F21F8599 for ; Sat, 28 Jul 2012 17:36:36 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAKODFFCHCzI1/2dsb2JhbABCA7lfgQeCIAEBAQEDEh4KPwwCAgIBCA0BAgEEAQEBCgYMCwEGARorCQgBAQQTCAEZh2sLnHCcMwSLTINBgkFgA5ZdhGmKEIJh X-IronPort-AV: E=Sophos;i="4.77,673,1336363200"; d="scan'208";a="317184468" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 28 Jul 2012 20:32:14 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.13]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 28 Jul 2012 20:16:45 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 29 Jul 2012 02:36:22 +0200 Message-ID: In-Reply-To: <20120727221553.GA71797@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] ietf-interfaces & vendor specific types Thread-Index: Ac1sRWkeC0IJCwtvQUm2fW5tbKCqnAA2/uSQ References: <50E64ADF99EAEE4CACEC18958F0FC0AB01C707@xmb-aln-x14.cisco.com> <20120726190751.GA8248@elstar.local> <20120727052604.GA70066@elstar.local> <20120727063339.GA70211@elstar.local> <20120727221553.GA71797@elstar.local> From: "Romascanu, Dan (Dan)" To: "Juergen Schoenwaelder" Cc: netmod@ietf.org Subject: Re: [netmod] ietf-interfaces & vendor specific types 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, 29 Jul 2012 00:36:37 -0000 > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs- > university.de] > Sent: Saturday, July 28, 2012 1:16 AM > To: Romascanu, Dan (Dan) > Cc: Lange, Jeffrey K (GE Energy); PatrickGili (pgili); netmod@ietf.org > Subject: Re: [netmod] ietf-interfaces & vendor specific types >=20 > On Fri, Jul 27, 2012 at 06:58:24PM +0200, Romascanu, Dan (Dan) wrote: > > > > > > > > > -----Original Message----- > > > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs- > > > university.de] > > > Sent: Friday, July 27, 2012 9:34 AM > > > To: Romascanu, Dan (Dan) > > > Cc: Lange, Jeffrey K (GE Energy); PatrickGili (pgili); > > > netmod@ietf.org > > > Subject: Re: [netmod] ietf-interfaces & vendor specific types > > > > > > On Fri, Jul 27, 2012 at 07:46:06AM +0200, Romascanu, Dan (Dan) > wrote: > > > > To get a new ifType assignment a vendor needs to show a > > specification > > > > that describes the layering model and the specific and presumably > > > > unique characteristics of the interface type, as well as the > > > > meaningful filling of the ifTable objects as per RFC 2863. > > > > > > This is good but unfortunately this useful information does not seem > > to > > > be recorded in the IANA registry. (This comment applies to many > > > allocations, whether initiated by a vendor or not - and allocated by > > > a vendor may not be the same as vendor-specific allocation.) > > > > > > /js > > > > > > > > > > Well, the IANA registry is actually a MIB module containing the TC > > with the enumeration, as you know. We can ask IANA to record as > > comments or separately a pointer to the specification and/or contact > > information to the owners >=20 > My understanding is that the IANA registry is here >=20 > http://www.iana.org/assignments/smi-numbers >=20 > (you have to scroll a bit) and the MIB module is a machine readable > serialization of it (and the YANG module would be another > serialization). While IANA seems to maintain data internally in an XML > format these days, there is no automated generation of derived > serializations, at least this was true when we talked to IANA. At that > time (some IETFs ago), IANA said updates are rare enough that automating > things is not necessary. >=20 > The registry actually contains a pointer who requested the entry. But > that is all, no additional information seems to be linked (except > allocations described in RFCs). >=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 [[DR]]=20 Right, this changed with the introduction of the XML format. Actually all latest entries include either a [contact] or a [reference] field, in many cases both. We could easily automate the generation of comments that would include the information with the MIB and YANG generated modules.=20 Dan From bclaise@cisco.com Sat Jul 28 22:07:02 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0D1521F8564 for ; Sat, 28 Jul 2012 22:07:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.46 X-Spam-Level: X-Spam-Status: No, score=-10.46 tagged_above=-999 required=5 tests=[AWL=0.139, 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 KdNtni7m-1Yd for ; Sat, 28 Jul 2012 22:07:02 -0700 (PDT) Received: from av-tac-sj.cisco.com (av-tac-sj.cisco.com [171.68.227.119]) by ietfa.amsl.com (Postfix) with ESMTP id 45E3121F8562 for ; Sat, 28 Jul 2012 22:07:02 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from fire.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-sj.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q6T571EF019945; Sat, 28 Jul 2012 22:07:02 -0700 (PDT) Received: from [10.21.68.45] (sjc-vpn3-1069.cisco.com [10.21.68.45]) by fire.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q6T56wDF027247; Sat, 28 Jul 2012 22:06:58 -0700 (PDT) Message-ID: <5014C4F2.2050908@cisco.com> Date: Sat, 28 Jul 2012 22:06:58 -0700 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: "Yi Yang (yiya)" References: <45BE39D9-2E92-4139-B579-B125649CD287@cisco.com> In-Reply-To: <45BE39D9-2E92-4139-B579-B125649CD287@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "netmod@ietf.org" Subject: Re: [netmod] comments on draft-ietf-netmod-routing-cfg-04 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, 29 Jul 2012 05:07:03 -0000 Thanks mister YANG. Sorry Yi, I could not resist ;-) Regards, Benoit. > Hi Lavislav, > > Here are my comments for the current draft: > > 1. How about to add a leaf "enabled" (default "true") under routing-protocol? Administrator may choose to temporarily disable a routing protocol instance for troubleshooting. > > 2. Add a leaf "isActive" under route -- The value should be true if the route is being used for forwarding. An reply to the NETCONF (like the example in the appendix B) will not only give the whole routing table but also shows which routes are active. > > Yi > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > From lhotka@nic.cz Sun Jul 29 05:11:43 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A501321F86B4 for ; Sun, 29 Jul 2012 05:11:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_23=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VtSvPRFzECpG for ; Sun, 29 Jul 2012 05:11:43 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id EAA6221F86AB for ; Sun, 29 Jul 2012 05:11:42 -0700 (PDT) Received: from [IPv6:2001:df8::64:ddb1:6ab:8012:11fa] (unknown [IPv6:2001:df8:0:64:ddb1:6ab:8012:11fa]) by mail.nic.cz (Postfix) with ESMTPSA id 919C414086D; Sun, 29 Jul 2012 14:11:28 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1343563889; bh=2WkQGegSXPdTzsTiX9iejMzpzpFNleozo4j3AymPqdc=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=h4NpJlX3QcI80ImQshAyTN+U0mugARIYu5dFTeC23r5Qr+Pm9qykhuwTPR+PZ1Xsb VktOKz2juE4UMzU18PE9LDUQiS2lhWfNhmXXMJKxyerFzr4ThukU6v9x/jLM+AviAi 6KaFRe/NkGWR8k2+a00R1zUwYHisMcyuz6TfHd9Y= Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Ladislav Lhotka In-Reply-To: <45BE39D9-2E92-4139-B579-B125649CD287@cisco.com> Date: Sun, 29 Jul 2012 05:11:26 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <45BE39D9-2E92-4139-B579-B125649CD287@cisco.com> To: Yi Yang (yiya) X-Mailer: Apple Mail (2.1278) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: "netmod@ietf.org" Subject: Re: [netmod] comments on draft-ietf-netmod-routing-cfg-04 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, 29 Jul 2012 12:11:43 -0000 On Jul 27, 2012, at 11:49 AM, Yi Yang (yiya) wrote: > Hi Lavislav, >=20 > Here are my comments for the current draft: >=20 > 1. How about to add a leaf "enabled" (default "true") under = routing-protocol? Administrator may choose to temporarily disable a = routing protocol instance for troubleshooting. Good point, this should be added. >=20 > 2. Add a leaf "isActive" under route -- The value should be true if = the route is being used for forwarding. An reply to the NETCONF = (like the example in the appendix B) will not only give the whole = routing table but also shows which routes are active. Some implementations would have hard time maintaining this flag. = Implementations that use a forwarding table (where all routes are active = by definition) may allow the client to inspect this table. Moreover, in routing tables other than "main", the "isActive" flag makes = no sense. I added a new RPC method that returns the active route (or routes, in = the case of multi-path routing) for a given address. Thanks, Lada >=20 > Yi -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From mbj@tail-f.com Sun Jul 29 14:59:36 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F7F321F86AD for ; Sun, 29 Jul 2012 14:59:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.977 X-Spam-Level: X-Spam-Status: No, score=-0.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, 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 xXEnoUqiSsQV for ; Sun, 29 Jul 2012 14:59:35 -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 8944821F866E for ; Sun, 29 Jul 2012 14:59:35 -0700 (PDT) Received: from localhost (unknown [130.129.21.151]) by mail.tail-f.com (Postfix) with ESMTPSA id 238FC12008E8; Sun, 29 Jul 2012 23:59:33 +0200 (CEST) Date: Sun, 29 Jul 2012 16:38:16 +0200 (CEST) Message-Id: <20120729.163816.338581205.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: References: <20120726191358.GB8248@elstar.local> X-Mailer: Mew version 6.3.51 on Emacs 23.3 / 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] LL review of {interfaces,ip}-cfg-05 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, 29 Jul 2012 21:59:36 -0000 Ladislav Lhotka wrote: > Juergen Schoenwaelder writes: > > >> *** Formal > >> 1. The sections containing YANG code start with a sentence like > >> "This YANG module imports a typedef from ...". Strictly speaking, > >> this is not correct because the 'import' statement imports entire > >> modules and not only selected items. On the other hand, this > >> sentence is redundant because 'import' statements have a prominent > >> place at the beginning of each module. I propose to remove these > >> sentences and start each section right away with . > > > > These sentence are there so that we have citations of the normative > > references in the text (otherwise IETF tools yell at you). While it is > > In the routing draft, I (unintentionally) implemented another workaround: a > table in sec. 2.2 showing the correspondence between prefixes and module > names, with references to the normative documents. This seems more useful than > the introductory sequences, especially if some of the prefixes are used in the > main text. But this doesn't really work if the main text doesn't use these prefixes. The current technique is not new - it is used for MIBs in several RFCs. /martin From mbj@tail-f.com Sun Jul 29 14:59:36 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EB9021F8666 for ; Sun, 29 Jul 2012 14:59:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.977 X-Spam-Level: X-Spam-Status: No, score=-0.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, 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 gaJYY6yfzdXd for ; Sun, 29 Jul 2012 14:59:35 -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 8949D21F867F for ; Sun, 29 Jul 2012 14:59:35 -0700 (PDT) Received: from localhost (unknown [130.129.21.151]) by mail.tail-f.com (Postfix) with ESMTPSA id 0141C1200050; Sun, 29 Jul 2012 23:59:32 +0200 (CEST) Date: Sun, 29 Jul 2012 16:36:24 +0200 (CEST) Message-Id: <20120729.163624.365978165.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20120726191358.GB8248@elstar.local> References: <20120726191358.GB8248@elstar.local> X-Mailer: Mew version 6.3.51 on Emacs 23.3 / 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] LL review of {interfaces,ip}-cfg-05 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, 29 Jul 2012 21:59:36 -0000 Juergen Schoenwaelder wrote: > > 2. Section 6. ("Security Considerations") of ip-cfg-05, in the > > paragraph about "ipv4/ip-forwarding" and "ipv6/ip-forwarding": I > > propose to change both occurrences of "routing functions" to > > "forwarding functions", because other routing functions such as > > routing protocol exchange may be performed even on interfaces with > > disabled forwarding. > > I agree. Fixed. > It seems also the text starting with "=ipv6/autoconf" should > have been a separate paragraph. Yes. Typo in the source. Also fixed. /martin From lhotka@nic.cz Sun Jul 29 15:19:11 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AF9D11E80DC for ; Sun, 29 Jul 2012 15:19:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_23=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sXcOcIaZkVlF for ; Sun, 29 Jul 2012 15:19: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 A19F611E80D6 for ; Sun, 29 Jul 2012 15:19:10 -0700 (PDT) Received: from [IPv6:2001:df8::16:1419:18a3:122:57c6] (unknown [IPv6:2001:df8:0:16:1419:18a3:122:57c6]) by mail.nic.cz (Postfix) with ESMTPSA id DD4BA14050B; Mon, 30 Jul 2012 00:19:08 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1343600349; bh=MdZbj4LLm2F6kYHNNJPXUE7f2QWRYgZD9NilDQ/RL48=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=E3TJi43P3t1Y6O5YeFEORDgrub5vwFnNpnZY3L4T1BN5uagNeATgban5Fm28v2K16 wxj+0PAqVwiX66pzQXbhdSwi15IPpQcMPuUw68JYF22L9Dkrq1XzOvmF20DLqThia3 lgK696+UrDYjiOSdwnmsSnvB3BOmjyIvIFZvivpI= Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Ladislav Lhotka In-Reply-To: <20120729.163816.338581205.mbj@tail-f.com> Date: Sun, 29 Jul 2012 15:19:07 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <6F988DD7-1756-4349-89EB-2F1E25CF401A@nic.cz> References: <20120726191358.GB8248@elstar.local> <20120729.163816.338581205.mbj@tail-f.com> To: Martin Bjorklund X-Mailer: Apple Mail (2.1278) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] LL review of {interfaces,ip}-cfg-05 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, 29 Jul 2012 22:19:11 -0000 On Jul 29, 2012, at 7:38 AM, Martin Bjorklund wrote: > Ladislav Lhotka wrote: >> Juergen Schoenwaelder writes: >>=20 >>>> *** Formal >>>> 1. The sections containing YANG code start with a sentence like >>>> "This YANG module imports a typedef from ...". Strictly speaking, >>>> this is not correct because the 'import' statement imports entire >>>> modules and not only selected items. On the other hand, this >>>> sentence is redundant because 'import' statements have a = prominent >>>> place at the beginning of each module. I propose to remove these >>>> sentences and start each section right away with . >>>=20 >>> These sentence are there so that we have citations of the normative >>> references in the text (otherwise IETF tools yell at you). While it = is >>=20 >> In the routing draft, I (unintentionally) implemented another = workaround: a >> table in sec. 2.2 showing the correspondence between prefixes and = module >> names, with references to the normative documents. This seems more = useful than >> the introductory sequences, especially if some of the prefixes are = used in the >> main text. >=20 > But this doesn't really work if the main text doesn't use these > prefixes. Well, it does work in that it pulls the normative references into the = text body. >=20 > The current technique is not new - it is used for MIBs in several > RFCs. Yes, but MIBs - unlike YANG - really specify the individual object = definitions that are imported from other MIBs, so that's why I think the = formulation for YANG modules should be at least slightly adjusted. Lada >=20 >=20 > /martin -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From yiya@cisco.com Sun Jul 29 18:59:09 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F31EF21F8671 for ; Sun, 29 Jul 2012 18:59:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[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 SFeKZphmPGLW for ; Sun, 29 Jul 2012 18:59:08 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 59EB221F866C for ; Sun, 29 Jul 2012 18:59:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2559; q=dns/txt; s=iport; t=1343613548; x=1344823148; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=EGkJdfLRreT0UE4j2S146aRgsKhDU10JgqqdN4cbxnQ=; b=SIVSxzWM93Plk2RDRAKsqp6Sn5AnpW68+t0t+4xIEYTygpZWb36J9s10 5WLFfS3ef7VRRZZ74vU6Xr8zwCXhkrTxvJeHJSutmtQRi9iBusTB1P8PM 5J5ZcSZ2ElBwPUYLPsDzrnJp+GAp5ZagY6h4iFQuzsT394ZW2XXtth68R 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAAzqFVCtJV2a/2dsb2JhbABFuVuBB4IgAQEBAwESASc/BQsCAQg2EDIlAgQOJ4dlBpl+nyORUmADlUmOJ4Fmgl+BViM X-IronPort-AV: E=Sophos;i="4.77,675,1336348800"; d="scan'208";a="103462126" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-9.cisco.com with ESMTP; 30 Jul 2012 01:59:08 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q6U1x7A0020312 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 30 Jul 2012 01:59:07 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.33]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.02.0298.004; Sun, 29 Jul 2012 20:59:07 -0500 From: "Yi Yang (yiya)" To: Ladislav Lhotka Thread-Topic: comments on draft-ietf-netmod-routing-cfg-04 Thread-Index: AQHNbCicgjImo6D/hUmbbdTBxQ8JeZdAgg4AgADnagA= Date: Mon, 30 Jul 2012 01:59:07 +0000 Message-ID: <1157C259-DE00-4DD9-870D-2E58CD188ED8@cisco.com> References: <45BE39D9-2E92-4139-B579-B125649CD287@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.75.7] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19072.001 x-tm-as-result: No--39.467800-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "netmod@ietf.org" Subject: Re: [netmod] comments on draft-ietf-netmod-routing-cfg-04 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, 30 Jul 2012 01:59:09 -0000 Hi Ladislav, >> Hi Lavislav, >>=20 >> Here are my comments for the current draft: >>=20 >> 1. How about to add a leaf "enabled" (default "true") under routing-prot= ocol? Administrator may choose to temporarily disable a routing protocol in= stance for troubleshooting. >=20 > Good point, this should be added. >=20 >>=20 >> 2. Add a leaf "isActive" under route -- The value should be true if the = route is being used for forwarding. An reply to the NETCONF (like the= example in the appendix B) will not only give the whole routing table but = also shows which routes are active. >=20 > Some implementations would have hard time maintaining this flag. Actually, in practice, when a user want to show a routing table, they are e= xpecting a list of active routes. They could get a full table with inactive= routes with adding some extra key words, such as "all" or "detail", but by= default, they are more interested what system is using right now.=20 > Implementations that use a forwarding table (where all routes are active = by definition) may allow the client to inspect this table. Does this mandate a separated routing table? In addition, I am confused by = the term "forwarding table". A forwarding table is normally referred to som= ething different to a routing table, as the former is optimized for fast lo= okup. For example, it may not care about the age/source of the route. > Moreover, in routing tables other than "main", the "isActive" flag makes = no sense. Why? > I added a new RPC method that returns the active route (or routes, in the= case of multi-path routing) for a given address. This seems opposite to current practice. In daily operation, people are int= erested in the active routes in most cases, and "show detail" if they want = to know more. I have two more questions/comments about the draft. 1. If an option node is missed in the reply to the NETCONF message, w= hat does it mean? Does it mean the device doesn't not support the option no= de, or does it mean the device supports such a option but with a default va= lue? 2. For the interaction between routing protocol and routing table, "routes = appearing in a routing table are passed to all routing protocols connected = to the table". Such a behaviors is called redistribution, which is off by d= efault. If a routing table by default passes the routes to all routing prot= ocols, this sounds we have to have a deny-all export filter for each =20 routing protocol by default? Yi From jernej.tuljak@mg-soft.si Mon Jul 30 03:19:27 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8712A21F876C for ; Mon, 30 Jul 2012 03:19:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[AWL=0.149, 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 DtnkLc0KvdMN for ; Mon, 30 Jul 2012 03:19:26 -0700 (PDT) Received: from gate.mg-soft.si (gate.mg-soft.si [212.30.73.66]) by ietfa.amsl.com (Postfix) with ESMTP id 7BC2421F8769 for ; Mon, 30 Jul 2012 03:19:25 -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 q6UAJMW3015379; Mon, 30 Jul 2012 12:19:23 +0200 Message-ID: <50165FAA.4040700@mg-soft.com> Date: Mon, 30 Jul 2012 12:19:22 +0200 From: Jernej Tuljak User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Andy Bierman References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] XPath errors in ietf-snmp.yang 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, 30 Jul 2012 10:19:27 -0000 Dne 29.7.2012 1:34, piše Andy Bierman: > Hi, > > I am getting lots of XPath errors reported from yangdump: > > > > *** Generated by yangdump 5.0.da08cd7 > *** Copyright (c) 2008-2012, Andy Bierman, All Rights Reserved. > > Warning: no child nodes found in XPath expr '../type = read or ../type = write' > ietf-snmp-proxy.yang:114.24: warning(432): no child node available > > Warning: no child nodes found in XPath expr '../type = read or ../type = write' > ietf-snmp-proxy.yang:114.42: warning(432): no child node available > > Warning: no child nodes found in XPath expr '../type = trap or ../type = inform' > ietf-snmp-proxy.yang:123.24: warning(432): no child node available > > Warning: no child nodes found in XPath expr '../type = trap or ../type = inform' > ietf-snmp-proxy.yang:123.42: warning(432): no child node available > > These errors in ietf-snmp-proxy.yang are because the strings need to > be quoted. When unquoted, they are XPath node names, not strings. > > e.g.: > > ../type = 'trap' or ../type = 'inform' I agree. These should be quoted. > > Warning: no child nodes found in XPath expr 'snmp:params/snmp:v1 or > snmp:params/snmp:v2c' > ietf-snmp-community.yang:196.12: warning(432): no child node available > > Warning: no child nodes found in XPath expr 'snmp:params/snmp:v1 or > snmp:params/snmp:v2c' > ietf-snmp-community.yang:196.35: warning(432): no child node available > > > There is a missing '/' so XPath this is supposed to be a child node > > e.g. > /snmp:params/snmp:v1 No. There is no toplevel params node in this module. These should probably be "../snmp:v1 or ../snmp:v2c". They appear to be refering to nodes of the params choice inside /snmp:snmp/snmp:target. > > Warning: no child nodes found in XPath expr > '/snmp/usm/remote[engine-id=current()]/user[name=current()/../usm/user-name]' > ietf-snmp-usm.yang:194.13: warning(432): no child node available > > Warning: no child nodes found in XPath expr > '/snmp/usm/remote[engine-id=current()]/user[name=current()/../usm/user-name]' > ietf-snmp-usm.yang:194.29: warning(432): no child node available > > Warning: no child nodes found in XPath expr > '/snmp/usm/remote[engine-id=current()]/user[name=current()/../usm/user-name]' > ietf-snmp-usm.yang:194.55: warning(432): no child node available > > > Not sure if the 3 errors above are yangdump problems or due to > restrictions on what can be > referenced within an augment-stmt. The XPath and combination of uses > and augments > is complicated to follow, so not sure if it is correct yet. I don't think these are errors. I can "manually" resolve them by browsing this module's expanded schema tree and by validating content based on this module via RFC6110. Example config instance: test jernej auth-priv 01:af:b6:c8:2b 01:af:b6:c8:2b jernej andy returns a single validation error in our tool (snmp:target is incomplete) which means that the when statement's XPath for snmp:engine-id evaluated to true during Schematron asserts. Changing the snmp:user-name to an invalid value is correctly reported as an error. I think this is a bug in yangdump and that it has something to do with current() being used. Perhaps the context is not set properly while evaluating the expression. I'm not sure how syntax of XPath expressions is validated within yangdump, but using current() would require an instance document to test (like the one I posted above). > > Warning: no child nodes found in XPath expr '../map-type = snmp:specified' > ietf-snmp-tls.yang:174.30: warning(432): no child node available > > Not sure what snmp:specified is -- XPath thinks it is a node name because this > is an unquoted string. There is no child 'specified' under this leaf. snmp:specified appears to be an identity in ietf-snmp-tls (base cert-to-tm-security-name). This should also be quoted, it's a QName value. > > *** /usr/share/yuma/modules/ietf/ietf-snmp.yang > *** 0 Errors, 10 Warnings > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod Jernej From jeffrey.K.lange@ge.com Mon Jul 30 05:41:24 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 075C021F8714 for ; Mon, 30 Jul 2012 05:41:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.414 X-Spam-Level: X-Spam-Status: No, score=-6.414 tagged_above=-999 required=5 tests=[AWL=0.184, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W25Ro+MdRFkm for ; Mon, 30 Jul 2012 05:41:23 -0700 (PDT) Received: from exprod5og101.obsmtp.com (exprod5og101.obsmtp.com [64.18.0.141]) by ietfa.amsl.com (Postfix) with ESMTP id E7C4721F870E for ; Mon, 30 Jul 2012 05:41:22 -0700 (PDT) Received: from alpmlip13.e2k.ad.ge.com ([12.43.191.1]) (using TLSv1) by exprod5ob101.postini.com ([64.18.4.12]) with SMTP ID DSNKUBaA8kyMXyrsLjU26a7Hp6XrUcKRCMfO@postini.com; Mon, 30 Jul 2012 05:41:23 PDT Received: from unknown (HELO cinmlef09.e2k.ad.ge.com) ([3.159.213.56]) by alpmlip13.e2k.ad.ge.com with ESMTP; 30 Jul 2012 08:40:16 -0400 Received: from alpmlef03.e2k.ad.ge.com ([3.159.18.12]) by cinmlef09.e2k.ad.ge.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 30 Jul 2012 08:40:16 -0400 Received: from CINMLCH02.e2k.ad.ge.com ([3.159.212.51]) by alpmlef03.e2k.ad.ge.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 30 Jul 2012 08:40:15 -0400 Received: from CINMBCNA06.e2k.ad.ge.com (3.159.212.61) by CINMLCH02.e2k.ad.ge.com (3.159.212.51) with Microsoft SMTP Server (TLS) id 14.2.283.3; Mon, 30 Jul 2012 08:40:15 -0400 Received: from CINMBCNA02.e2k.ad.ge.com ([169.254.2.214]) by CINMBCNA06.e2k.ad.ge.com ([169.254.6.103]) with mapi id 14.02.0283.003; Mon, 30 Jul 2012 08:40:15 -0400 From: "Lange, Jeffrey K (GE Energy)" To: "netmod@ietf.org" Thread-Topic: draft-lange-netmod-iana-timezones Thread-Index: AQHNbPW6Fd7IBt4FQUutD+p+VrFodZdBxgPg Date: Mon, 30 Jul 2012 12:40:14 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [3.159.212.187] Content-Type: multipart/alternative; boundary="_000_B0FB1FAC2C7B234D87DCEBF309F703C51BAB1A5FCINMBCNA02e2kad_" MIME-Version: 1.0 X-OriginalArrivalTime: 30 Jul 2012 12:40:15.0513 (UTC) FILETIME=[781BA890:01CD6E50] Subject: [netmod] FW: draft-lange-netmod-iana-timezones 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, 30 Jul 2012 12:41:24 -0000 --_000_B0FB1FAC2C7B234D87DCEBF309F703C51BAB1A5FCINMBCNA02e2kad_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSByZWNlaXZlZCB0aGlzIGNvbW1lbnQgdGhpcyBtb3JuaW5nIG9uIHRoZSB0aW1lem9uZXMgZGF0 YSBtb2RlbC4gIEFzIHRoaXMgZG9jdW1lbnQgaXMgbm93IGluIHRoZSBoYW5kcyBvZiB0aGUgd29y a2luZyBncm91cCBJIHRob3VnaHQgSSB3b3VsZCBwYXNzIGFsb25nIHRoaXMgY29tbWVudCB0byB0 aGUgZ3JvdXAuDQoNClNob3VsZCBlbnVtIHZhbHVlIDAgYmUgYSDigJx1bmtub3du4oCdIHN0YXRl PyAgVGhlcmUgaXMgbm8gc3VjaCB2YWx1ZSBpbiB0aGUgaWFuYSB0aW1lem9uZSBkYXRhYmFzZSwg YW5kIGluIG5ldGNvbmYsIGlmIHRoZSBub2RlIGlzIG5vdCBjb25maWd1cmVkLCBpdCBqdXN0IHdv dWxkbuKAmXQgYmUgcHJlc2VudCBjb3JyZWN0Pw0KDQpUaGFua3MNCi1KZWZmDQoNCg0KRnJvbTog SmVmZnJleSBTYXJub2ZmIFttYWlsdG86amVmZnJleS5zYXJub2ZmQGdtYWlsLmNvbV0NClNlbnQ6 IFNhdHVyZGF5LCBKdWx5IDI4LCAyMDEyIDM6MTcgUE0NClRvOiBkcmFmdC1sYW5nZS1uZXRtb2Qt aWFuYS10aW1lem9uZXNAdG9vbHMuaWV0Zi5vcmcNClN1YmplY3Q6IGRyYWZ0LWxhbmdlLW5ldG1v ZC1pYW5hLXRpbWV6b25lcw0KDQpSZTogaHR0cDovL3Rvb2xzLmlldGYub3JnL2lkL2RyYWZ0LWxh bmdlLW5ldG1vZC1pYW5hLXRpbWV6b25lcy0wMS50eHQNCg0KSW4gdGhlIGRvY3VtZW50LCB0aGUg ZW51bWVyYXRpb24gdmFsdWUgb2YgemVybyBpcyBhc3NpZ25lZCAoQW5kb3JyYSBoYWQgYmVlbiB2 YWx1ZWQgMSkuDQpJIHdvdWxkIHByZWZlciB0aGF0IHRoZSB6ZXJvIHZhbHVlZCBlbnVtZXJhdGlv biByZW1haW4gdW5hc3NpZ25lZCB0byBhIHNwZWNpZmljIHRpbWV6b25lIGxvY2F0aW9uLg0KSXQg aGFzIGJlZW4gYSBjb252ZW5pZW50IGFuZCBzZW5zaWJsZSB3YXkgdG8gaW5kaWNhdGUgJ3RoZSBs b2NhbCB0aW1lem9uZScgaW4gc2l0dWF0aW9ucyB3aGVyZSB0aGUgc3BlY2lmaWMgbG9jYWxpemF0 aW9uIGlzIGFzIHlldCB1bmtub3duIG9yIG90aGVyd2lzZSB1bnJlc29sdmVkLg0KDQpSZXNwZWN0 ZnVsbHksDQoNCkplZmZyZXkgU2Fybm9mZg0KPGplZmZyZXkgZG90IHNhcm5vZmYsIGdtYWlsPg0K DQoNCg0K --_000_B0FB1FAC2C7B234D87DCEBF309F703C51BAB1A5FCINMBCNA02e2kad_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAx LjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVy cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSByZWNlaXZlZCB0aGlz IGNvbW1lbnQgdGhpcyBtb3JuaW5nIG9uIHRoZSB0aW1lem9uZXMgZGF0YSBtb2RlbC4mbmJzcDsg QXMgdGhpcyBkb2N1bWVudCBpcyBub3cgaW4gdGhlIGhhbmRzIG9mIHRoZSB3b3JraW5nIGdyb3Vw IEkgdGhvdWdodCBJIHdvdWxkIHBhc3MgYWxvbmcgdGhpcw0KIGNvbW1lbnQgdG8gdGhlIGdyb3Vw LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+U2hvdWxkIGVudW0gdmFsdWUgMCBiZSBhIOKAnHVua25vd27igJ0gc3RhdGU/ Jm5ic3A7IFRoZXJlIGlzIG5vIHN1Y2ggdmFsdWUgaW4gdGhlIGlhbmEgdGltZXpvbmUgZGF0YWJh c2UsIGFuZCBpbiBuZXRjb25mLCBpZiB0aGUgbm9kZSBpcyBub3QgY29uZmlndXJlZCwgaXQganVz dCB3b3VsZG7igJl0DQogYmUgcHJlc2VudCBjb3JyZWN0PzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhhbmtzPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPi1KZWZmPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gSmVm ZnJleSBTYXJub2ZmIFttYWlsdG86amVmZnJleS5zYXJub2ZmQGdtYWlsLmNvbV0NCjxicj4NCjxi PlNlbnQ6PC9iPiBTYXR1cmRheSwgSnVseSAyOCwgMjAxMiAzOjE3IFBNPGJyPg0KPGI+VG86PC9i PiBkcmFmdC1sYW5nZS1uZXRtb2QtaWFuYS10aW1lem9uZXNAdG9vbHMuaWV0Zi5vcmc8YnI+DQo8 Yj5TdWJqZWN0OjwvYj4gZHJhZnQtbGFuZ2UtbmV0bW9kLWlhbmEtdGltZXpvbmVzPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5SZToNCjxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9y Zy9pZC9kcmFmdC1sYW5nZS1uZXRtb2QtaWFuYS10aW1lem9uZXMtMDEudHh0Ij5odHRwOi8vdG9v bHMuaWV0Zi5vcmcvaWQvZHJhZnQtbGFuZ2UtbmV0bW9kLWlhbmEtdGltZXpvbmVzLTAxLnR4dDwv YT48YnI+DQo8YnI+DQpJbiB0aGUgZG9jdW1lbnQsIHRoZSBlbnVtZXJhdGlvbiB2YWx1ZSBvZiB6 ZXJvIGlzIGFzc2lnbmVkIChBbmRvcnJhIGhhZCBiZWVuIHZhbHVlZCAxKS48YnI+DQpJIHdvdWxk IHByZWZlciB0aGF0IHRoZSB6ZXJvIHZhbHVlZCBlbnVtZXJhdGlvbiByZW1haW4gdW5hc3NpZ25l ZCB0byBhIHNwZWNpZmljIHRpbWV6b25lIGxvY2F0aW9uLjxicj4NCkl0IGhhcyBiZWVuIGEgY29u dmVuaWVudCBhbmQgc2Vuc2libGUgd2F5IHRvIGluZGljYXRlICd0aGUgbG9jYWwgdGltZXpvbmUn IGluIHNpdHVhdGlvbnMgd2hlcmUgdGhlIHNwZWNpZmljIGxvY2FsaXphdGlvbiBpcyBhcyB5ZXQg dW5rbm93biBvciBvdGhlcndpc2UgdW5yZXNvbHZlZC48YnI+DQo8YnI+DQpSZXNwZWN0ZnVsbHks IDxicj4NCjxicj4NCkplZmZyZXkgU2Fybm9mZjxicj4NCiZsdDtqZWZmcmV5IGRvdCBzYXJub2Zm LCBnbWFpbCZndDs8YnI+DQombmJzcDs8L3NwYW4+PGI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48YnI+DQo8YnI+DQo8 YnI+DQo8L3NwYW4+PC9iPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+ DQo= --_000_B0FB1FAC2C7B234D87DCEBF309F703C51BAB1A5FCINMBCNA02e2kad_-- From andy@yumaworks.com Mon Jul 30 07:15:25 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A942321F8611 for ; Mon, 30 Jul 2012 07:15:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.288 X-Spam-Level: X-Spam-Status: No, score=-3.288 tagged_above=-999 required=5 tests=[AWL=-0.311, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 dliyHE6T2Osf for ; Mon, 30 Jul 2012 07:15:25 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id E81AD21F8567 for ; Mon, 30 Jul 2012 07:15:24 -0700 (PDT) Received: by ghbg16 with SMTP id g16so5258669ghb.31 for ; Mon, 30 Jul 2012 07:15:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding:x-gm-message-state; bh=9EkrM3t571DCorZU2HnBTcfZRkK9uGxtQ8qpznTYoQY=; b=IQ/Pwg+w99iRkXqSuaqlYCAPmLDJSqUOdWiIaYIWwDkyGJjhnbFF5ou6cyfwTSIF7R gxV7vjCq4t4DtF8snzF3+MqiLEywKUJrOpC5PbgoxK5t3iNWabHFSXGf3M9rTi48oLbe 3ZzRs+6znoARTmJU/FLtIS45R4d8E3yFa3Fy+Lmogq6344hysaCF6v78Zk81UvVqqco0 8QODRqR5ZOa3Qi6eeoHCWNPP2yWnKP9qY9/hOnlReT5Y/39Y9iWlmYM5aye4PuTub8PF RVg3MJv47DYeHfQuz77wCBAwAoQkziVt3nJTLPbiJIKLp8zw6SVj7ivWN9RgtIXJiX3s UesQ== MIME-Version: 1.0 Received: by 10.50.179.74 with SMTP id de10mr8258839igc.61.1343657703657; Mon, 30 Jul 2012 07:15:03 -0700 (PDT) Received: by 10.50.109.167 with HTTP; Mon, 30 Jul 2012 07:15:03 -0700 (PDT) X-Originating-IP: [130.129.65.206] In-Reply-To: References: Date: Mon, 30 Jul 2012 07:15:03 -0700 Message-ID: From: Andy Bierman To: "Lange, Jeffrey K (GE Energy)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQlA/AUQyNoOWrIMU7phVfdHhOtMcnTsxD2fOnTg1dzb2xWQfTwCLAHTlHSX4m8X6myVjcxg Cc: "netmod@ietf.org" Subject: Re: [netmod] FW: draft-lange-netmod-iana-timezones 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, 30 Jul 2012 14:15:25 -0000 NETCONF enums use the label on the wire. The enum value is a meaningless field that never appears on the wire. (This is not SNMP). But no, this typedef needs to match the official version. It is not a clone to be reinvented by this WG. Andy On Mon, Jul 30, 2012 at 5:40 AM, Lange, Jeffrey K (GE Energy) wrote: > I received this comment this morning on the timezones data model. As thi= s > document is now in the hands of the working group I thought I would pass > along this comment to the group. > > > > Should enum value 0 be a =E2=80=9Cunknown=E2=80=9D state? There is no su= ch value in the > iana timezone database, and in netconf, if the node is not configured, it > just wouldn=E2=80=99t be present correct? > As with all leafs, there is no value returned for a missing leaf (without a default). > > > Thanks > > -Jeff > > > > > > From: Jeffrey Sarnoff [mailto:jeffrey.sarnoff@gmail.com] > Sent: Saturday, July 28, 2012 3:17 PM > To: draft-lange-netmod-iana-timezones@tools.ietf.org > Subject: draft-lange-netmod-iana-timezones > > > > Re: http://tools.ietf.org/id/draft-lange-netmod-iana-timezones-01.txt > > In the document, the enumeration value of zero is assigned (Andorra had b= een > valued 1). > I would prefer that the zero valued enumeration remain unassigned to a > specific timezone location. > It has been a convenient and sensible way to indicate 'the local timezone= ' > in situations where the specific localization is as yet unknown or otherw= ise > unresolved. > > Respectfully, > > Jeffrey Sarnoff > > > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From lhotka@nic.cz Mon Jul 30 07:27:38 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BF6221F8764 for ; Mon, 30 Jul 2012 07:27:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[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 5sepaBdOI1fm for ; Mon, 30 Jul 2012 07:27:30 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 8BF2421F8673 for ; Mon, 30 Jul 2012 07:27:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id D672B540307; Mon, 30 Jul 2012 16:27:27 +0200 (CEST) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EUI834xMfaE0; Mon, 30 Jul 2012 16:27:22 +0200 (CEST) Received: from localhost (dhcp-1072.meeting.ietf.org [130.129.16.114]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 874DB540052; Mon, 30 Jul 2012 16:27:21 +0200 (CEST) From: Ladislav Lhotka To: "Yi Yang \(yiya\)" In-Reply-To: <1157C259-DE00-4DD9-870D-2E58CD188ED8@cisco.com> References: <45BE39D9-2E92-4139-B579-B125649CD287@cisco.com> <1157C259-DE00-4DD9-870D-2E58CD188ED8@cisco.com> User-Agent: Notmuch/0.13.2+77~g39beeb2 (http://notmuchmail.org) Emacs/23.3.50.1 (i386-apple-darwin9.8.0) Mail-Followup-To: "Yi Yang \(yiya\)" , "netmod\@ietf.org" Date: Mon, 30 Jul 2012 07:27:19 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "netmod@ietf.org" Subject: Re: [netmod] comments on draft-ietf-netmod-routing-cfg-04 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, 30 Jul 2012 14:27:38 -0000 "Yi Yang (yiya)" writes: >>> 2. Add a leaf "isActive" under route -- The value should be true if the route is being used for forwarding. An reply to the NETCONF (like the example in the appendix B) will not only give the whole routing table but also shows which routes are active. >> >> Some implementations would have hard time maintaining this flag. > > Actually, in practice, when a user want to show a routing table, they are expecting a list of active routes. They could get a full table with inactive routes with adding some extra key words, such as "all" or "detail", but by default, they are more interested what system is using right now. > >> Implementations that use a forwarding table (where all routes are active by definition) may allow the client to inspect this table. > > Does this mandate a separated routing table? In addition, I am confused by the term "forwarding table". A forwarding table is normally referred to something different to a routing table, as the former is optimized for fast lookup. For example, it may not care about the age/source of the route. > I think there is a terminology mismatch here. Let me cite from Junos documentation (http://www.juniper.net/techpubs/en_US/junos12.1/topics/concept/routing-protocols-routing-databases-overview.html#id-10137188): The Junos OS installs all active routes from the routing table into the forwarding table. The active routes are used to forward packets to their destinations. The Junos OS kernel maintains a master copy of the forwarding table. It copies the forwarding table to the Packet Forwarding Engine, which is the part of the router responsible for forwarding packets. So it seems "forwarding table" in Junos terms is "routing table" in IOS terms, because IOS only accepts active routes into the routing table based on prefix length, administrative distance and protocol-specific metrics. But both platforms maintain this "table with active routes", and in this case I would indeed recommend to have a separate routing table playing this role (see the proposed setup at the end of my mail). So one can just use on this table to obtain the active routes. Linux, in contrast, doesn't keep this "table with active routes". Its routing table may contain routes that are clearly inactive, as in this example where two otherwise identical routes differ in the metric: $ ip route default via 1.2.3.129 dev eth0 metric 100 default via 1.2.3.129 dev eth0 metric 200 1.2.3.128/27 dev eth0 proto kernel scope link src 1.2.3.143 Linux uses a route cache, which however contains only /32 (or /128) routes. In the case of a route cache miss, a lookup in the (main) routing table must be performed. >> Moreover, in routing tables other than "main", the "isActive" flag makes no sense. > > Why? Because all routes may be subject to one or more route filters before they reach the main routing table (or, in general, the place from which active routes are selected). > >> I added a new RPC method that returns the active route (or routes, in the case of multi-path routing) for a given address. > > This seems opposite to current practice. In daily operation, people are interested in the active routes in most cases, and "show detail" if they want to know more. > > I have two more questions/comments about the draft. > > 1. If an option node is missed in the reply to the NETCONF message, what does it mean? Does it mean the device doesn't not support the option node, or does it mean the device supports such a option but with a default value? > If the node has a default value defined in the data model, then it means that the default value is used - see also RFC 6243. > 2. For the interaction between routing protocol and routing table, "routes appearing in a routing table are passed to all routing protocols connected to the table". Such a behaviors is called redistribution, which is off by default. If a routing table by default passes the routes to all routing protocols, this sounds we have to have a deny-all export filter for each > routing protocol by default? I would use this setup for IOS emulation: 1. Make a separate routing table for each protocol instance. 2. Make the main routing table a recipient of the routing tables of all protocol instances, and state in the data model documentation that incoming routes are processed so that only active routes appear in the main table. 3. If you want routes from protocol A to be redistributed to protocol B, define the B routing table as a recipient routing table of A. ASCII art: +---------+ +---------+ | proto A | | proto B | +---------+ +---------+ | ^ | ^ v | v | +---------+ +---------+ | table A |--------->| table B | +---------+ +---------+ | | | +------------+ | +-->| main table |<--+ +------------+ Thanks, Lada > > Yi > > -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From j.schoenwaelder@jacobs-university.de Mon Jul 30 07:31:21 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3489F21F86F8 for ; Mon, 30 Jul 2012 07:31:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.205 X-Spam-Level: X-Spam-Status: No, score=-103.205 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GoalL6UVnYg5 for ; Mon, 30 Jul 2012 07:31: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 6B12421F86F3 for ; Mon, 30 Jul 2012 07:31:20 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8943620BF6; Mon, 30 Jul 2012 16:31:19 +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 tsAY67hGg3Vc; Mon, 30 Jul 2012 16:31:19 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 301C22096B; Mon, 30 Jul 2012 16:31:18 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 99CAA20FA4D8; Mon, 30 Jul 2012 16:31:16 +0200 (CEST) Date: Mon, 30 Jul 2012 16:31:16 +0200 From: Juergen Schoenwaelder To: "Lange, Jeffrey K (GE Energy)" Message-ID: <20120730143116.GA75760@elstar.local> Mail-Followup-To: "Lange, Jeffrey K (GE Energy)" , "netmod@ietf.org" References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "netmod@ietf.org" Subject: Re: [netmod] FW: draft-lange-netmod-iana-timezones 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, 30 Jul 2012 14:31:21 -0000 On Mon, Jul 30, 2012 at 12:40:14PM +0000, Lange, Jeffrey K (GE Energy) wrote: > I received this comment this morning on the timezones data model. As this document is now in the hands of the working group I thought I would pass along this comment to the group. > > Should enum value 0 be a “unknown” state? There is no such value in the iana timezone database, and in netconf, if the node is not configured, it just wouldn’t be present correct? > For NETCONF, the enum's value does not matter much since the enum's label is shipped on the wire. That said, it has been useful practice for many IANA registries to assign numbers starting from 1 with 0 being reserved for a future use. But note that reserved means that the number remains simply unassigned. Following that practice, we could indeed start numbering with 1 and leave 0 unassigned. However, it might not give the requestor what he is looking for and I agree that if the timezone is not configured, it is not configured. If the goal is to support something outside of the standard, then the proposer of this change should note that the timezone in draft-ietf-netmod-system-mgmt-02 is defined as a choice - it is possible to augment that choice. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From andy@yumaworks.com Mon Jul 30 07:36:32 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05BAE21F8803 for ; Mon, 30 Jul 2012 07:36:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.133 X-Spam-Level: X-Spam-Status: No, score=-3.133 tagged_above=-999 required=5 tests=[AWL=-0.155, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 ojkGYSzKYe4W for ; Mon, 30 Jul 2012 07:36:31 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1EDD611E808E for ; Mon, 30 Jul 2012 07:36:31 -0700 (PDT) Received: by yenq13 with SMTP id q13so5290397yen.31 for ; Mon, 30 Jul 2012 07:36:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding:x-gm-message-state; bh=Uife74JZWluzA0+EliqdC44+6x4AaOLS+AN5u5j8Oj0=; b=XADHOiPIp0HGtKjx1Xi4QiTVL48+n2PHoinzIRxKd60rx8TSQGLjWuCUAFlCXw9znh 6czzdeUKDjqcCU9AroDF9SHrttS/c8O45+7Eo49rXdXzYswyJRD5aQI/eLTlwcWbrjcC iozoVYAIkXR+I6HW2jRsB4ALqoWi+BvFETF70uDioo2KN8VR6FebFMeMXqCxN1vL5Dqd vP8uKEeZM5qqiIxgP1ut01ky4b520BBP2fslThnQwkZTgwWZknCTNiI+rDwP4hy0VaI9 DF6G3elsttbbGEAz5vqSnbNQ5jqElr9K571QAtpl6o0keakYVmkkhRwMmOHF0pw9QnTE 2Pyw== MIME-Version: 1.0 Received: by 10.50.85.230 with SMTP id k6mr10961887igz.49.1343658990461; Mon, 30 Jul 2012 07:36:30 -0700 (PDT) Received: by 10.50.109.167 with HTTP; Mon, 30 Jul 2012 07:36:30 -0700 (PDT) X-Originating-IP: [130.129.65.206] In-Reply-To: <50165FAA.4040700@mg-soft.com> References: <50165FAA.4040700@mg-soft.com> Date: Mon, 30 Jul 2012 07:36:30 -0700 Message-ID: From: Andy Bierman To: Jernej Tuljak Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQlw5DhAcVU8hXCrML+WiaYOt6GGtrGNJbOcxWjfMRp+cQ0ZQiTlYzszZ5za/gjdXfsExV9c Cc: netmod@ietf.org Subject: Re: [netmod] XPath errors in ietf-snmp.yang 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, 30 Jul 2012 14:36:32 -0000 On Mon, Jul 30, 2012 at 3:19 AM, Jernej Tuljak w= rote: > Dne 29.7.2012 1:34, pi=C5=A1e Andy Bierman: >> >> Hi, >> >> I am getting lots of XPath errors reported from yangdump: >> >> >> >> *** Generated by yangdump 5.0.da08cd7 >> *** Copyright (c) 2008-2012, Andy Bierman, All Rights Reserved. >> >> Warning: no child nodes found in XPath expr '../type =3D read or ../type= =3D >> write' >> ietf-snmp-proxy.yang:114.24: warning(432): no child node available >> >> Warning: no child nodes found in XPath expr '../type =3D read or ../type= =3D >> write' >> ietf-snmp-proxy.yang:114.42: warning(432): no child node available >> >> Warning: no child nodes found in XPath expr '../type =3D trap or ../type= =3D >> inform' >> ietf-snmp-proxy.yang:123.24: warning(432): no child node available >> >> Warning: no child nodes found in XPath expr '../type =3D trap or ../type= =3D >> inform' >> ietf-snmp-proxy.yang:123.42: warning(432): no child node available >> >> These errors in ietf-snmp-proxy.yang are because the strings need to >> be quoted. When unquoted, they are XPath node names, not strings. >> >> e.g.: >> >> ../type =3D 'trap' or ../type =3D 'inform' > > > I agree. These should be quoted. > >> >> Warning: no child nodes found in XPath expr 'snmp:params/snmp:v1 or >> snmp:params/snmp:v2c' >> ietf-snmp-community.yang:196.12: warning(432): no child node available >> >> Warning: no child nodes found in XPath expr 'snmp:params/snmp:v1 or >> snmp:params/snmp:v2c' >> ietf-snmp-community.yang:196.35: warning(432): no child node available >> >> >> There is a missing '/' so XPath this is supposed to be a child node >> >> e.g. >> /snmp:params/snmp:v1 > > > No. There is no toplevel params node in this module. These should probabl= y > be > "../snmp:v1 or ../snmp:v2c". They appear to be refering to nodes of the > params choice inside /snmp:snmp/snmp:target. > >> >> Warning: no child nodes found in XPath expr >> >> '/snmp/usm/remote[engine-id=3Dcurrent()]/user[name=3Dcurrent()/../usm/us= er-name]' >> ietf-snmp-usm.yang:194.13: warning(432): no child node available >> >> Warning: no child nodes found in XPath expr >> >> '/snmp/usm/remote[engine-id=3Dcurrent()]/user[name=3Dcurrent()/../usm/us= er-name]' >> ietf-snmp-usm.yang:194.29: warning(432): no child node available >> >> Warning: no child nodes found in XPath expr >> >> '/snmp/usm/remote[engine-id=3Dcurrent()]/user[name=3Dcurrent()/../usm/us= er-name]' >> ietf-snmp-usm.yang:194.55: warning(432): no child node available >> >> >> Not sure if the 3 errors above are yangdump problems or due to >> restrictions on what can be >> referenced within an augment-stmt. The XPath and combination of uses >> and augments >> is complicated to follow, so not sure if it is correct yet. > > > I don't think these are errors. I can "manually" resolve them by browsing > this module's expanded schema tree and by validating content based on thi= s > module via RFC6110. > You mean by manually inspecting them? Because pyang and other tools completely ignore XPath expressions and make no attempt whatsoever to validate their contents as correct for the data model module. AFAIK, only yangdump attempts to validate XPath= . The code does this against the object tree, and there is a different code path for evaluating real expressions against a data tree. I thought RFC 6020 made some restrictions about referencing nodes outside the 'augment' subtree, but probably not. It was discussed (around the time we ended up restricting where augment-stmt can be used). Andy > Example config instance: > > > > > > test > > jernej > auth-priv > > 01:af:b6:c8:2b > > > > 01:af:b6:c8:2b > > jernej > > > andy > > > > > > > returns a single validation error in our tool (snmp:target is incomplete) > which means that the when statement's XPath for snmp:engine-id evaluated = to > true during Schematron asserts. Changing the snmp:user-name to an invalid > value is correctly reported as an error. > > I think this is a bug in yangdump and that it has something to do with > current() being used. Perhaps the context is not set properly while > evaluating the expression. I'm not sure how syntax of XPath expressions i= s > validated within yangdump, but using current() would require an instance > document to test (like the one I posted above). > >> >> Warning: no child nodes found in XPath expr '../map-type =3D snmp:specif= ied' >> ietf-snmp-tls.yang:174.30: warning(432): no child node available >> >> Not sure what snmp:specified is -- XPath thinks it is a node name becaus= e >> this >> is an unquoted string. There is no child 'specified' under this leaf. > > > snmp:specified appears to be an identity in ietf-snmp-tls (base > cert-to-tm-security-name). This should also be quoted, it's a QName value= . > >> >> *** /usr/share/yuma/modules/ietf/ietf-snmp.yang >> *** 0 Errors, 10 Warnings >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod > > > Jernej From lhotka@nic.cz Mon Jul 30 07:49:36 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6608C11E80FA for ; Mon, 30 Jul 2012 07:49:36 -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 z8tqwGDoAQG7 for ; Mon, 30 Jul 2012 07:49:35 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 5B58B11E80A4 for ; Mon, 30 Jul 2012 07:49:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 8890E540307 for ; Mon, 30 Jul 2012 16:49:34 +0200 (CEST) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nhvmlPmHSt+m for ; Mon, 30 Jul 2012 16:49:29 +0200 (CEST) Received: from localhost (dhcp-1072.meeting.ietf.org [130.129.16.114]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id E9F90540052 for ; Mon, 30 Jul 2012 16:49:28 +0200 (CEST) From: Ladislav Lhotka To: netmod@ietf.org In-Reply-To: References: <50165FAA.4040700@mg-soft.com> User-Agent: Notmuch/0.13.2+77~g39beeb2 (http://notmuchmail.org) Emacs/23.3.50.1 (i386-apple-darwin9.8.0) Mail-Followup-To: netmod@ietf.org Date: Mon, 30 Jul 2012 07:49:26 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [netmod] XPath errors in ietf-snmp.yang 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, 30 Jul 2012 14:49:36 -0000 Andy Bierman writes: >> I don't think these are errors. I can "manually" resolve them by browsing >> this module's expanded schema tree and by validating content based on this >> module via RFC6110. >> > > You mean by manually inspecting them? > Because pyang and other tools completely ignore XPath expressions > and make no attempt whatsoever to validate their contents as correct > for the data model module. AFAIK, only yangdump attempts to validate XPath. > The code does this against the object tree, and there is a different > code path for evaluating real expressions against a data tree. Schematron will mostly detect XPath errors, except cases like must "not(nonsense)"; This is how I debug my XPath expressions. > > I thought RFC 6020 made some restrictions about referencing > nodes outside the 'augment' subtree, but probably not. It was > discussed (around the time we ended up restricting where > augment-stmt can be used). Right, but it's not in 6020. Lada > > > Andy > > >> Example config instance: >> >> >> >> >> >> test >> >> jernej >> auth-priv >> >> 01:af:b6:c8:2b >> >> >> >> 01:af:b6:c8:2b >> >> jernej >> >> >> andy >> >> >> >> >> >> >> returns a single validation error in our tool (snmp:target is incomplete) >> which means that the when statement's XPath for snmp:engine-id evaluated to >> true during Schematron asserts. Changing the snmp:user-name to an invalid >> value is correctly reported as an error. >> >> I think this is a bug in yangdump and that it has something to do with >> current() being used. Perhaps the context is not set properly while >> evaluating the expression. I'm not sure how syntax of XPath expressions is >> validated within yangdump, but using current() would require an instance >> document to test (like the one I posted above). >> >>> >>> Warning: no child nodes found in XPath expr '../map-type = snmp:specified' >>> ietf-snmp-tls.yang:174.30: warning(432): no child node available >>> >>> Not sure what snmp:specified is -- XPath thinks it is a node name because >>> this >>> is an unquoted string. There is no child 'specified' under this leaf. >> >> >> snmp:specified appears to be an identity in ietf-snmp-tls (base >> cert-to-tm-security-name). This should also be quoted, it's a QName value. >> >>> >>> *** /usr/share/yuma/modules/ietf/ietf-snmp.yang >>> *** 0 Errors, 10 Warnings >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >> >> >> Jernej > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From jernej.tuljak@mg-soft.si Mon Jul 30 07:53:37 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF7B021F8807 for ; Mon, 30 Jul 2012 07:53:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.475 X-Spam-Level: X-Spam-Status: No, score=-2.475 tagged_above=-999 required=5 tests=[AWL=0.124, 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 wzlRmUmIC8me for ; Mon, 30 Jul 2012 07:53:37 -0700 (PDT) Received: from gate.mg-soft.si (gate.mg-soft.si [212.30.73.66]) by ietfa.amsl.com (Postfix) with ESMTP id B119321F8802 for ; Mon, 30 Jul 2012 07:53:36 -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 q6UErY7c019601; Mon, 30 Jul 2012 16:53:34 +0200 Message-ID: <50169FED.3000801@mg-soft.com> Date: Mon, 30 Jul 2012 16:53:33 +0200 From: Jernej Tuljak User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Andy Bierman References: <50165FAA.4040700@mg-soft.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] XPath errors in ietf-snmp.yang 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, 30 Jul 2012 14:53:37 -0000 Dne 30.7.2012 16:36, piše Andy Bierman: > On Mon, Jul 30, 2012 at 3:19 AM, Jernej Tuljak wrote: >> Dne 29.7.2012 1:34, piše Andy Bierman: >>> Hi, >>> >>> I am getting lots of XPath errors reported from yangdump: >>> >>> >>> >>> *** Generated by yangdump 5.0.da08cd7 >>> *** Copyright (c) 2008-2012, Andy Bierman, All Rights Reserved. >>> >>> Warning: no child nodes found in XPath expr '../type = read or ../type = >>> write' >>> ietf-snmp-proxy.yang:114.24: warning(432): no child node available >>> >>> Warning: no child nodes found in XPath expr '../type = read or ../type = >>> write' >>> ietf-snmp-proxy.yang:114.42: warning(432): no child node available >>> >>> Warning: no child nodes found in XPath expr '../type = trap or ../type = >>> inform' >>> ietf-snmp-proxy.yang:123.24: warning(432): no child node available >>> >>> Warning: no child nodes found in XPath expr '../type = trap or ../type = >>> inform' >>> ietf-snmp-proxy.yang:123.42: warning(432): no child node available >>> >>> These errors in ietf-snmp-proxy.yang are because the strings need to >>> be quoted. When unquoted, they are XPath node names, not strings. >>> >>> e.g.: >>> >>> ../type = 'trap' or ../type = 'inform' >> >> I agree. These should be quoted. >> >>> Warning: no child nodes found in XPath expr 'snmp:params/snmp:v1 or >>> snmp:params/snmp:v2c' >>> ietf-snmp-community.yang:196.12: warning(432): no child node available >>> >>> Warning: no child nodes found in XPath expr 'snmp:params/snmp:v1 or >>> snmp:params/snmp:v2c' >>> ietf-snmp-community.yang:196.35: warning(432): no child node available >>> >>> >>> There is a missing '/' so XPath this is supposed to be a child node >>> >>> e.g. >>> /snmp:params/snmp:v1 >> >> No. There is no toplevel params node in this module. These should probably >> be >> "../snmp:v1 or ../snmp:v2c". They appear to be refering to nodes of the >> params choice inside /snmp:snmp/snmp:target. >> >>> Warning: no child nodes found in XPath expr >>> >>> '/snmp/usm/remote[engine-id=current()]/user[name=current()/../usm/user-name]' >>> ietf-snmp-usm.yang:194.13: warning(432): no child node available >>> >>> Warning: no child nodes found in XPath expr >>> >>> '/snmp/usm/remote[engine-id=current()]/user[name=current()/../usm/user-name]' >>> ietf-snmp-usm.yang:194.29: warning(432): no child node available >>> >>> Warning: no child nodes found in XPath expr >>> >>> '/snmp/usm/remote[engine-id=current()]/user[name=current()/../usm/user-name]' >>> ietf-snmp-usm.yang:194.55: warning(432): no child node available >>> >>> >>> Not sure if the 3 errors above are yangdump problems or due to >>> restrictions on what can be >>> referenced within an augment-stmt. The XPath and combination of uses >>> and augments >>> is complicated to follow, so not sure if it is correct yet. >> >> I don't think these are errors. I can "manually" resolve them by browsing >> this module's expanded schema tree and by validating content based on this >> module via RFC6110. >> > You mean by manually inspecting them? > Because pyang and other tools completely ignore XPath expressions > and make no attempt whatsoever to validate their contents as correct > for the data model module. AFAIK, only yangdump attempts to validate XPath. > The code does this against the object tree, and there is a different > code path for evaluating real expressions against a data tree. By loading them in our tool and inspecting them. You are wrong about pyang ignoring XPath expressions. True that they are not checked during YANG validation thoroughly but are later used within it's DSDL plugin to validate instance documents. This represents one way of debugging XPath used within YANG. I'm quite familiar with pyang since I ported major parts of it to Java. Jernej > > I thought RFC 6020 made some restrictions about referencing > nodes outside the 'augment' subtree, but probably not. It was > discussed (around the time we ended up restricting where > augment-stmt can be used). > > > Andy > > >> Example config instance: >> >> >> >> >> >> test >> >> jernej >> auth-priv >> >> 01:af:b6:c8:2b >> >> >> >> 01:af:b6:c8:2b >> >> jernej >> >> >> andy >> >> >> >> >> >> >> returns a single validation error in our tool (snmp:target is incomplete) >> which means that the when statement's XPath for snmp:engine-id evaluated to >> true during Schematron asserts. Changing the snmp:user-name to an invalid >> value is correctly reported as an error. >> >> I think this is a bug in yangdump and that it has something to do with >> current() being used. Perhaps the context is not set properly while >> evaluating the expression. I'm not sure how syntax of XPath expressions is >> validated within yangdump, but using current() would require an instance >> document to test (like the one I posted above). >> >>> Warning: no child nodes found in XPath expr '../map-type = snmp:specified' >>> ietf-snmp-tls.yang:174.30: warning(432): no child node available >>> >>> Not sure what snmp:specified is -- XPath thinks it is a node name because >>> this >>> is an unquoted string. There is no child 'specified' under this leaf. >> >> snmp:specified appears to be an identity in ietf-snmp-tls (base >> cert-to-tm-security-name). This should also be quoted, it's a QName value. >> >>> *** /usr/share/yuma/modules/ietf/ietf-snmp.yang >>> *** 0 Errors, 10 Warnings >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >> >> Jernej From lhotka@nic.cz Mon Jul 30 08:49:03 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF8AC11E808E for ; Mon, 30 Jul 2012 08:49:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_23=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WYMdvz2aX03G for ; Mon, 30 Jul 2012 08:49:03 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 41DFA21F86B0 for ; Mon, 30 Jul 2012 08:49:03 -0700 (PDT) Received: from [IPv6:2001:df8::64:cc92:3286:4439:7a01] (unknown [IPv6:2001:df8:0:64:cc92:3286:4439:7a01]) by mail.nic.cz (Postfix) with ESMTPSA id 9E84013FD88; Mon, 30 Jul 2012 17:49:01 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1343663342; bh=fdwPM+GZpCdlLfXKarpZl574GoIB1OVwva6X/RBo/yI=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=X7Jsz84NlNWi41VjLdPX82ipTfhnKNKVKZ2IilniF0L2nEM7pKueQS+ygpTnIbKFH x3BsLTtMgPG6W7wCnFV51fytq+yRFCVfdPlHHq/8MLlzjgFBc5T1Q+ZYTn4vAmzpX3 gikjIRKrSyb5HzcmhJjQb4/7iAvTb/JQOef7O/9Q= Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Ladislav Lhotka In-Reply-To: <50169FED.3000801@mg-soft.com> Date: Mon, 30 Jul 2012 08:48:58 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <3D0FFE5C-3D88-4BB5-862E-66A9B01A96FA@nic.cz> References: <50165FAA.4040700@mg-soft.com> <50169FED.3000801@mg-soft.com> To: Jernej Tuljak X-Mailer: Apple Mail (2.1278) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] XPath errors in ietf-snmp.yang 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, 30 Jul 2012 15:49:04 -0000 On Jul 30, 2012, at 7:53 AM, Jernej Tuljak wrote: > You are wrong about pyang ignoring XPath expressions. True that they = are not checked during YANG validation thoroughly but are later used = within it's DSDL plugin to validate instance documents. This represents = one way of debugging XPath used within YANG. I'm quite familiar with = pyang since I ported major parts of it to Java. Interesting. Regarding DSDL, does it mean that you generate the hybrid = schema in Java and then use the XSLT stylesheets from pyang? Lada -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From j.schoenwaelder@jacobs-university.de Mon Jul 30 11:50:04 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0660321F85D4; Mon, 30 Jul 2012 11:50:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.206 X-Spam-Level: X-Spam-Status: No, score=-103.206 tagged_above=-999 required=5 tests=[AWL=0.043, 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 x1hzU6rN8txE; Mon, 30 Jul 2012 11:50: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 4E95621F85D1; Mon, 30 Jul 2012 11:50:03 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7D8EB20BD4; Mon, 30 Jul 2012 20:50:02 +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 ohLl6jXJeJWh; Mon, 30 Jul 2012 20:50: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 124A920BDE; Mon, 30 Jul 2012 20:50:02 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 8B41420FAD8C; Mon, 30 Jul 2012 20:50:00 +0200 (CEST) Date: Mon, 30 Jul 2012 20:50:00 +0200 From: Juergen Schoenwaelder To: attendees <84attendees@ietf.org>, NETCONF , NETMOD Working Group Message-ID: <20120730185000.GB76317@elstar.local> Mail-Followup-To: attendees <84attendees@ietf.org>, NETCONF , NETMOD Working Group References: <501327B2.6040208@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <501327B2.6040208@cisco.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [netmod] [Netconf] Network Configuration Management with NETCONF and YANG Tutorial this Sunday 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, 30 Jul 2012 18:50:04 -0000 On Fri, Jul 27, 2012 at 04:43:46PM -0700, Benoit Claise wrote: > Dear all, > > The "NETCONF and YANG" tutorial was added late to the agenda. > So if you registered early, maybe you missed this tutorial announcement. > Hence this email: > 1300-1450 Network Configuration Management with NETCONF and YANG > Tutorial - Regency E > Since the slides are not on any IETF web pages yet, I have put them up for download here: http://cnds.eecs.jacobs-university.de/slides/2012-ietf-84-netconf-yang.pdf /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 Mon Jul 30 12:08:03 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54A2D11E8152 for ; Mon, 30 Jul 2012 12:08:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.206 X-Spam-Level: X-Spam-Status: No, score=-103.206 tagged_above=-999 required=5 tests=[AWL=0.043, 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 bc9sxNW6633C for ; Mon, 30 Jul 2012 12:08: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 3E3BB11E819E for ; Mon, 30 Jul 2012 12:08:02 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 94AD920BE5; Mon, 30 Jul 2012 21:08:01 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id diITAYdh_d6e; Mon, 30 Jul 2012 21:08: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 2623B20A13; Mon, 30 Jul 2012 21:08:01 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id D5B4B20FAEC9; Mon, 30 Jul 2012 21:07:59 +0200 (CEST) Date: Mon, 30 Jul 2012 21:07:59 +0200 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20120730190759.GB76399@elstar.local> Mail-Followup-To: netmod@ietf.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="+HP7ph2BbKc20aGI" Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [netmod] FWD: Need volunteers for the NomCom 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, 30 Jul 2012 19:08:03 -0000 --+HP7ph2BbKc20aGI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, please consider volunteering for the NomCom. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 --+HP7ph2BbKc20aGI Content-Type: message/rfc822 Content-Disposition: inline Received: from hermes.jacobs-university.de (212.201.44.23) by SHUBCAS01.jacobs.jacobs-university.de (10.70.0.128) with Microsoft SMTP Server id 14.2.298.4; Mon, 30 Jul 2012 18:38:44 +0200 Received: from atlas2.jacobs-university.de (atlas2a.jacobs-university.de [212.201.44.15]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8795920BEC for ; Mon, 30 Jul 2012 18:38:46 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by atlas2.jacobs-university.de (Postfix) with ESMTP id 83E6132E for ; Mon, 30 Jul 2012 18:38:46 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-100 required=6.2 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Authentication-Results: demetrius3.jacobs-university.de (amavisd-new); dkim=pass (1024-bit key) header.d=ietf.org 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 rZZrlGRANnBg for ; Mon, 30 Jul 2012 18:38:45 +0200 (CEST) X-JacobsISPWhiteListed: med ietf.org DNSWLId 1703 Received: from mail.ietf.org (mail.ietf.org [12.22.58.30]) by atlas2a.jacobs-university.de (Postfix) with ESMTP for ; Mon, 30 Jul 2012 18:38:45 +0200 (CEST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 119CC11E80A4; Mon, 30 Jul 2012 09:38:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1343666324; bh=V1/Lh13xCgFVckioZjA+x8OGQHibuYuqDRY5TT03s4U=; h=MIME-Version:Content-Type:Content-Transfer-Encoding:From:To: Subject:Message-ID:Date:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe:Sender; b=u1gv5uwVLr7tHLFiCiQg9+yX3uEtmJj2f9V82P0LiU7dREF9sJtG7KBmiuH1Kc3wI +7hbq5yP7M7fQoqlmb9mO0lkhCj5Ojh1zsM0TBdX8QDlySM8a0knz50hGCDPYQpgA/ hYgiupn7u29ROTWk8OXul+vVi/FEPdkLgp8uK7gU= X-Original-To: wgchairs@ietfa.amsl.com Delivered-To: wgchairs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 864E721F8460 for ; Sun, 29 Jul 2012 20:22:34 -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 J4UGwI1ztCyl for ; Sun, 29 Jul 2012 20:22:33 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD08521F8446 for ; Sun, 29 Jul 2012 20:22:33 -0700 (PDT) Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: NomCom Chair To: Working Group Chairs Subject: Need volunteers for the NomCom X-Test-IDTracker: no X-IETF-IDTracker: 4.32 Message-ID: <20120730032233.17770.35790.idtracker@ietfa.amsl.com> Date: Sun, 29 Jul 2012 20:22:33 -0700 X-Mailman-Approved-At: Mon, 30 Jul 2012 09:38:40 -0700 X-BeenThere: wgchairs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Working Group Chairs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: Errors-To: wgchairs-bounces@ietf.org Return-Path: wgchairs-bounces@ietf.org X-MS-Exchange-Organization-AuthSource: SHUBCAS01.jacobs.jacobs-university.de X-MS-Exchange-Organization-AuthAs: Anonymous X-MS-Exchange-Organization-AVStamp-Mailbox: MSFTFF;1;0;0 0 0 MIME-Version: 1.0 We are currently looking for volunteers to serve on the 2012-2013 NomCom. As you know, the success of the NomCom process depends crucially on=20 having a large pool of volunteers from throughout the IETF community.=20 In particular, it is valuable for the pool of volunteers to have strong=20 representation from all of the technical areas within the IETF.=20 I understand that not all IETF participants read the IETF announce list=20 frequently. Therefore, if you would be willing to inform active participant= s=20 in your working groups about this year's call for NomCom volunteers, I=20 would greatly appreciate it.=20 The NomCom 2012-2013 Call for Volunteers is open until this Sunday,=20 August 5. Details can be found at: https://datatracker.ietf.org/ann/nomcom/= 49851/ Thank you for your help, - Matt Lepinski mlepinski.ietf@gmail.com nomcom-chair@ietf.org --+HP7ph2BbKc20aGI-- From yiya@cisco.com Mon Jul 30 12:21:01 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EA0711E80E8 for ; Mon, 30 Jul 2012 12:21:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, J_CHICKENPOX_74=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kbMHDzBqXk5j for ; Mon, 30 Jul 2012 12:21:00 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 543A211E8158 for ; Mon, 30 Jul 2012 12:20:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=yiya@cisco.com; l=7635; q=dns/txt; s=iport; t=1343676059; x=1344885659; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=gjoN+hX0h6jrJDFMtxVwlSOM7/RMKHbK60uT5K5U0nY=; b=NDTa0aWxzKLEcHm2db0s+pgC9n01YGhKPSHMBtua2h1u4OK7a8GRvh1w 1Q5JSO7eojQVgfpSzaGGy3nfk/es1Nk9Wf7Ls7aqgT5uQraBffjzk/ccc 9zo3I+e1IsheWSpwOa31Ae/Sj32FV8kFkw7S6tlN/MlZRYTb8Gj2SZjYV 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAFHdFlCtJXHA/2dsb2JhbABFuVOBB4IgAQEBAwESARQTMQ4FCwIBCBgeEDIlAgQOBSKHZQYLmmGgCYtQGoYPYAOVSY4ngWaCX4Ff X-IronPort-AV: E=Sophos;i="4.77,681,1336348800"; d="scan'208";a="106755111" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-3.cisco.com with ESMTP; 30 Jul 2012 19:20:58 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id q6UJKwHX005884 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 30 Jul 2012 19:20:58 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.33]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.02.0298.004; Mon, 30 Jul 2012 14:20:58 -0500 From: "Yi Yang (yiya)" To: Ladislav Lhotka Thread-Topic: comments on draft-ietf-netmod-routing-cfg-04 Thread-Index: AQHNbCicgjImo6D/hUmbbdTBxQ8JeZdAgg4AgADnagCAANDigIAAUjsA Date: Mon, 30 Jul 2012 19:20:56 +0000 Message-ID: <5E5D58D7-824A-433A-87F1-53E08B80F991@cisco.com> References: <45BE39D9-2E92-4139-B579-B125649CD287@cisco.com> <1157C259-DE00-4DD9-870D-2E58CD188ED8@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.75.7] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19074.001 x-tm-as-result: No--58.731400-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <08F0460C05850E4D83BCE82C65D9C888@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "netmod@ietf.org" Subject: Re: [netmod] comments on draft-ietf-netmod-routing-cfg-04 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, 30 Jul 2012 19:21:01 -0000 Hi Ladiskav, On Jul 30, 2012, at 10:27 AM, Ladislav Lhotka wrote: > "Yi Yang (yiya)" writes: >>>> 2. Add a leaf "isActive" under route -- The value should be true if th= e route is being used for forwarding. An reply to the NETCONF (like t= he example in the appendix B) will not only give the whole routing table bu= t also shows which routes are active. >>>=20 >>> Some implementations would have hard time maintaining this flag. >>=20 >> Actually, in practice, when a user want to show a routing table, they ar= e expecting a list of active routes. They could get a full table with inact= ive routes with adding some extra key words, such as "all" or "detail", but= by default, they are more interested what system is using right now. >>=20 >>> Implementations that use a forwarding table (where all routes are activ= e by definition) may allow the client to inspect this table. >>=20 >> Does this mandate a separated routing table? In addition, I am confused = by the term "forwarding table". A forwarding table is normally referred to = something different to a routing table, as the former is optimized for fast= lookup. For example, it may not care about the age/source of the route. >>=20 >=20 > I think there is a terminology mismatch here. Let me cite from Junos docu= mentation (http://www.juniper.net/techpubs/en_US/junos12.1/topics/concept/r= outing-protocols-routing-databases-overview.html#id-10137188): >=20 > > The Junos OS installs all active routes from the routing table into the f= orwarding table. The active routes are used to forward packets to their des= tinations. >=20 > The Junos OS kernel maintains a master copy of the forwarding table. It c= opies the forwarding table to the Packet Forwarding Engine, which is the pa= rt of the router responsible for forwarding packets. > I am not an expert on Junos, but here is the output of "show route forwardi= ng-table", from http://www.juniper.net/techpubs/en_US/junos12.1/topics/refe= rence/command-summary/show-route-forwarding-table-mpls-ex-series.html user@switch> show route forwarding-table Routing table: default.inet Internet: Destination Type RtRef Next hop Type Index NhRef Netif default user 2 0:12:f2:21:cf:0 ucst 333 5 me0.0 default perm 0 rjct 36 2 0.0.0.0/32 perm 0 dscd 34 1 2.2.2.0/24 intf 0 rslv 1309 1 ae0.0 ....... Compared to the output of "show route", from http://www.juniper.net/techpubs/en_US/junos12.1/topics/reference/command-su= mmary/show-route.html user@host> show route inet.0: 10 destinations, 10 routes (9 active, 0 holddown, 1 hidden) + =3D Active Route, - =3D Last Active, * =3D Both 0.0.0.0/0 *[Static/5] 1w5d 20:30:29 Discard 10.255.245.51/32 *[Direct/0] 2w4d 13:11:14 > via lo0.0 172.16.0.0/12 *[Static/5] 2w4d 13:11:14 > to 192.168.167.254 via fxp0.0 192.168.0.0/18 *[Static/5] 1w5d 20:30:29 > to 192.168.167.254 via fxp0.0 As mentioned earlier, source/age are not shown in the forwarding table, unl= ess they are hidden intentionally? Maybe someone familiar with Junos can co= mment on this? > So it seems "forwarding table" in Junos terms is "routing table" in IOS t= erms, because IOS only accepts active routes into the routing table based o= n prefix length, administrative distance and protocol-specific metrics. >=20 > But both platforms maintain this "table with active routes", and in this = case I would indeed recommend to have a separate routing table playing this= role (see the proposed setup at the end of my mail). So one can just use <= get> on this table to obtain the active routes. >=20 > Linux, in contrast, doesn't keep this "table with active routes". Its rou= ting table may contain routes that are clearly inactive, as in this example= where two otherwise identical routes differ in the metric: >=20 > $ ip route > default via 1.2.3.129 dev eth0 metric 100 > default via 1.2.3.129 dev eth0 metric 200 > 1.2.3.128/27 dev eth0 proto kernel scope link src 1.2.3.143 >=20 > Linux uses a route cache, which however contains only /32 (or /128) route= s. In the case of a route cache miss, a lookup in the (main) routing table = must be performed. >=20 >>> Moreover, in routing tables other than "main", the "isActive" flag make= s no sense. >>=20 >> Why? >=20 > Because all routes may be subject to one or more route filters before the= y reach the main routing table (or, in general, the place from which active= routes are selected). What's the definition of main routing table? Previously, I was thinking the= default routing table, but now it seems a superset of all the routing tabl= es (default + VRFs) for a specific AF. >>> I added a new RPC method that returns the active route (or routes, in t= he case of multi-path routing) for a given address. >>=20 >> This seems opposite to current practice. In daily operation, people are = interested in the active routes in most cases, and "show detail" if they wa= nt to know more. >>=20 >> I have two more questions/comments about the draft. >>=20 >> 1. If an option node is missed in the reply to the NETCONF message= , what does it mean? Does it mean the device doesn't not support the option= node, or does it mean the device supports such a option but with a default= value? >>=20 >=20 > If the node has a default value defined in the data model, then it means = that the default value is used - see also RFC 6243. In the appendix B, under , is not shown and it shou= ld be interpreted as router "A" supports and has a default val= ue "true". But if router "A" doesn't support (which is an opti= onal node), how will it reply? Yi >> 2. For the interaction between routing protocol and routing table, "rout= es appearing in a routing table are passed to all routing protocols connect= ed to the table". Such a behaviors is called redistribution, which is off b= y default. If a routing table by default passes the routes to all routing p= rotocols, this sounds we have to have a deny-all export filter for each >> routing protocol by default? >=20 > I would use this setup for IOS emulation: >=20 > 1. Make a separate routing table for each protocol instance. >=20 > 2. Make the main routing table a recipient of the routing tables of all p= rotocol instances, and state in the data model documentation that incoming = routes are processed so that only active routes appear in the main table. >=20 > 3. If you want routes from protocol A to be redistributed to protocol B, = define the B routing table as a recipient routing table of A. >=20 > ASCII art: >=20 > +---------+ +---------+ > | proto A | | proto B | > +---------+ +---------+ > | ^ | ^ > v | v | > +---------+ +---------+ > | table A |--------->| table B | > +---------+ +---------+ > | | > | +------------+ | > +-->| main table |<--+ > +------------+ >=20 > Thanks, Lada >=20 >>=20 >> Yi >>=20 >>=20 >=20 > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C From andy@yumaworks.com Mon Jul 30 13:59:41 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5914C11E81AD for ; Mon, 30 Jul 2012 13:59:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 pUFBGBG5Lv22 for ; Mon, 30 Jul 2012 13:59:40 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6B03311E818E for ; Mon, 30 Jul 2012 13:59:40 -0700 (PDT) Received: by qcac10 with SMTP id c10so3563227qca.31 for ; Mon, 30 Jul 2012 13:59:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=zGn1FmRSsOpfTW3LjUy0yj0YQwQB2tSbP4eAI7zwP84=; b=n03FfylFSRJCwh/6Yg4+P8jwW4/cw5hcFxvQvjT093odWbF/ovlmPt5LCs038+4oSX CYORAgBUP/UR+x+7/lqj5RLsUgJhYZYT6q8akOkSjWVCd9bg8JPJxSKnHOl1T4k3Zz0n 6H8aVF36cevZ1TFD+U1ljtfQbXUrtIHEO6ZrU63QDiOxD0AzmaQP2KLTiI/YkF0TedQF LWG6l5e7jNwK6ywNU8TUq7EV+rYwHe2wo0QCKpFbub0qkV6Uzde9voJWlwEEKAsHZLke scS8kVIphTcTKbl08aXC/uY+k3O+zaO0y9VtBuqkUJjpJc4nZkxeV1S18jB+a7wtrfKp b0mQ== MIME-Version: 1.0 Received: by 10.229.105.205 with SMTP id u13mr6417312qco.9.1343681979911; Mon, 30 Jul 2012 13:59:39 -0700 (PDT) Received: by 10.49.26.168 with HTTP; Mon, 30 Jul 2012 13:59:39 -0700 (PDT) X-Originating-IP: [2001:df8:0:16:90e8:1d7:63e4:b566] Date: Mon, 30 Jul 2012 13:59:39 -0700 Message-ID: From: Andy Bierman To: netmod@ietf.org Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQnQCg2IHnNm8EKLhR9AuRunoAntqVLpB0fhVwiFBYHZcI2Ji6TrQvsxEBKnNJfOOXKVHJWS Subject: [netmod] comment on ietf-interfaces module 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, 30 Jul 2012 20:59:41 -0000 Hi, I re-read this draft and I do not understand why there is no generic equivalent to the ifStackTable. There is no way to describe that 1 interface is layering above or below another interface. There is an example in Appendix B for ethernet bonding. I understand that different interface types may want to augment the interface entry with specific fields. This is not an adequate replacement for a data structure that describes the general interface layering. Andy From j.schoenwaelder@jacobs-university.de Mon Jul 30 14:14:17 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3BD421F855D for ; Mon, 30 Jul 2012 14:14:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.206 X-Spam-Level: X-Spam-Status: No, score=-103.206 tagged_above=-999 required=5 tests=[AWL=0.043, 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 97fo+0PrmoUr for ; Mon, 30 Jul 2012 14:14: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 D9A2C21F8562 for ; Mon, 30 Jul 2012 14:14:16 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3C3FD20BF1; Mon, 30 Jul 2012 23:14:16 +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 X9E2sF5WQ1L4; Mon, 30 Jul 2012 23:14: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 C8DFA20BEC; Mon, 30 Jul 2012 23:14:15 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 847DB20FB281; Mon, 30 Jul 2012 23:14:14 +0200 (CEST) Date: Mon, 30 Jul 2012 23:14:14 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20120730211414.GA76670@elstar.local> Mail-Followup-To: Andy Bierman , netmod@ietf.org References: 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] comment on ietf-interfaces module 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, 30 Jul 2012 21:14:17 -0000 On Mon, Jul 30, 2012 at 01:59:39PM -0700, Andy Bierman wrote: > Hi, > > I re-read this draft and I do not understand why there is no generic > equivalent to the ifStackTable. There is no way to describe that > 1 interface is layering above or below another interface. > There is an example in Appendix B for ethernet bonding. > > I understand that different interface types may want to augment > the interface entry with specific fields. This is not an adequate > replacement for a data structure that describes the general interface layering. > The document focuses on configuration. It seems the way to configure bondings etc. is technology specific. Are you asking for addition of operational state (config false) objects to report the layering? Or are you asking for a generic mechanism to configure interface layering? /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 Jul 30 14:14:37 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F0E121F8562 for ; Mon, 30 Jul 2012 14:14:37 -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_74=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 kO9CDQqCVYxK for ; Mon, 30 Jul 2012 14:14:36 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 047C321F855D for ; Mon, 30 Jul 2012 14:14:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 5E8F95403B9; Mon, 30 Jul 2012 23:14:34 +0200 (CEST) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HOjbnCGl8Dtn; Mon, 30 Jul 2012 23:14:30 +0200 (CEST) Received: from localhost (dhcp-4753.meeting.ietf.org [130.129.71.83]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id DC8AE5400CB; Mon, 30 Jul 2012 23:14:25 +0200 (CEST) From: Ladislav Lhotka To: "Yi Yang \(yiya\)" In-Reply-To: <5E5D58D7-824A-433A-87F1-53E08B80F991@cisco.com> References: <45BE39D9-2E92-4139-B579-B125649CD287@cisco.com> <1157C259-DE00-4DD9-870D-2E58CD188ED8@cisco.com> <5E5D58D7-824A-433A-87F1-53E08B80F991@cisco.com> User-Agent: Notmuch/0.13.2+77~g39beeb2 (http://notmuchmail.org) Emacs/23.3.50.1 (i386-apple-darwin9.8.0) Mail-Followup-To: "Yi Yang \(yiya\)" , "netmod\@ietf.org" Date: Mon, 30 Jul 2012 14:14:17 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "netmod@ietf.org" Subject: Re: [netmod] comments on draft-ietf-netmod-routing-cfg-04 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, 30 Jul 2012 21:14:37 -0000 "Yi Yang (yiya)" writes: > I am not an expert on Junos, but here is the output of "show route forwarding-table", from http://www.juniper.net/techpubs/en_US/junos12.1/topics/reference/command-summary/show-route-forwarding-table-mpls-ex-series.html > > user@switch> show route forwarding-table > Routing table: default.inet > Internet: > Destination Type RtRef Next hop Type Index NhRef Netif > default user 2 0:12:f2:21:cf:0 ucst 333 5 me0.0 > default perm 0 rjct 36 2 > 0.0.0.0/32 perm 0 dscd 34 1 > 2.2.2.0/24 intf 0 rslv 1309 1 ae0.0 > ....... > > Compared to the output of "show route", from > http://www.juniper.net/techpubs/en_US/junos12.1/topics/reference/command-summary/show-route.html > > user@host> show route > inet.0: 10 destinations, 10 routes (9 active, 0 holddown, 1 hidden) > + = Active Route, - = Last Active, * = Both > 0.0.0.0/0 *[Static/5] 1w5d 20:30:29 > Discard > 10.255.245.51/32 *[Direct/0] 2w4d 13:11:14 > > via lo0.0 > 172.16.0.0/12 *[Static/5] 2w4d 13:11:14 > > to 192.168.167.254 via fxp0.0 > 192.168.0.0/18 *[Static/5] 1w5d 20:30:29 > > to 192.168.167.254 via fxp0.0 > > As mentioned earlier, source/age are not shown in the forwarding table, unless they are hidden intentionally? Maybe someone familiar with Junos can comment on this? Would it help if "age" and "source-protocol" were not mandatory? >> >>>> Moreover, in routing tables other than "main", the "isActive" flag makes no sense. >>> >>> Why? >> >> Because all routes may be subject to one or more route filters before they reach the main routing table (or, in general, the place from which active routes are selected). > > What's the definition of main routing table? Previously, I was thinking the default routing table, but now it seems a superset of all the routing tables (default + VRFs) for a specific AF. > >From the point of view of the core routing model, every implementation has to have at least one routing table per address family, which is called main. However, its role in routing/forwarding is not predetermined, so implementations can combine the components in different ways and specify additional semantics and/or restrictions. >>>> I added a new RPC method that returns the active route (or routes, in the case of multi-path routing) for a given address. >>> >>> This seems opposite to current practice. In daily operation, people are interested in the active routes in most cases, and "show detail" if they want to know more. >>> >>> I have two more questions/comments about the draft. >>> >>> 1. If an option node is missed in the reply to the NETCONF message, what does it mean? Does it mean the device doesn't not support the option node, or does it mean the device supports such a option but with a default value? >>> >> >> If the node has a default value defined in the data model, then it means that the default value is used - see also RFC 6243. > > In the appendix B, under , is not shown and it should be interpreted as router "A" supports and has a default value "true". But if router "A" doesn't support (which is an optional node), how will it reply? > It's optional in the sense that it needn't appear in a reply. But every server implementing the "ietf-routing" module must allow the client to set this leaf to "false". Lada -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From andy@yumaworks.com Mon Jul 30 14:23:17 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E7AA11E8087 for ; Mon, 30 Jul 2012 14:23:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.377 X-Spam-Level: X-Spam-Status: No, score=-2.377 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r+aCrMb0xVir for ; Mon, 30 Jul 2012 14:23:15 -0700 (PDT) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id 4B40111E80DF for ; Mon, 30 Jul 2012 14:23:15 -0700 (PDT) Received: by qaea16 with SMTP id a16so1278391qae.10 for ; Mon, 30 Jul 2012 14:23:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:content-type:x-gm-message-state; bh=UFqgxnyokYb1RsMJTJY8BnL5p7KjbSiIy4BbSSMtBTI=; b=plmaUIxlie4/UZ+Vh24++2MarDp62EJJ/8F2Ed4Sn4/bG8Q1qk6xmygO+mRzLkq6Ew keXCXMmuVuvcm1tUrAVOCBabh7H9/L1lWqJZDzkmnokFB5BkcelPnE8gwUVCRAu0ps6Y kDnBjXB7ma5WiC4YS6noa+xj8hinVkYSD4J05N2pyH+Pc5epe78NRCew4cneGTbSljde 7vtnSaXenr2yw6Nk5clx7eeWfXpHiyG+R3Uujfn2g8GyHJ2KkSsX03YwuyaBiuwv02d2 FOc2vcTYrJXI7KXrzwaJlrgehp870jtVo5n45F9B+Dlp20WUmttgUq0rs7TMg1nt6Vtz 9m9Q== MIME-Version: 1.0 Received: by 10.224.175.6 with SMTP id v6mr2255924qaz.36.1343683394792; Mon, 30 Jul 2012 14:23:14 -0700 (PDT) Received: by 10.49.26.168 with HTTP; Mon, 30 Jul 2012 14:23:14 -0700 (PDT) X-Originating-IP: [2001:df8:0:16:90e8:1d7:63e4:b566] In-Reply-To: <20120730211414.GA76670@elstar.local> References: <20120730211414.GA76670@elstar.local> Date: Mon, 30 Jul 2012 14:23:14 -0700 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , Andy Bierman , netmod@ietf.org Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQlnjQh/pp0LZb+VuwMtc/lCSEFwMzOtB2qLClTdqcLwkf1N+EMDLiij2qInLhf8b8PjsH7O Subject: Re: [netmod] comment on ietf-interfaces module 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, 30 Jul 2012 21:23:17 -0000 I think there is value in knowing that 1 interface is conceptually layered on top of another 1. Focusing on configuration is near-sighted if actual operational deployment requires that some basic information be retrievable in order to properly modify a device configuration. If you are arguing that the ifStackTable has no value and therefore there is no reason to use something like it in NETCONF, that is one thing, but config=true vs. config=false is an artificial distinction. Andy On Mon, Jul 30, 2012 at 2:14 PM, Juergen Schoenwaelder wrote: > On Mon, Jul 30, 2012 at 01:59:39PM -0700, Andy Bierman wrote: >> Hi, >> >> I re-read this draft and I do not understand why there is no generic >> equivalent to the ifStackTable. There is no way to describe that >> 1 interface is layering above or below another interface. >> There is an example in Appendix B for ethernet bonding. >> >> I understand that different interface types may want to augment >> the interface entry with specific fields. This is not an adequate >> replacement for a data structure that describes the general interface layering. >> > > The document focuses on configuration. It seems the way to configure > bondings etc. is technology specific. Are you asking for addition of > operational state (config false) objects to report the layering? Or > are you asking for a generic mechanism to configure interface > layering? > > /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 Jul 30 14:23:59 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A88511E808E for ; Mon, 30 Jul 2012 14:23:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.512 X-Spam-Level: X-Spam-Status: No, score=-1.512 tagged_above=-999 required=5 tests=[AWL=0.534, 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 Q+vM025HdhI1 for ; Mon, 30 Jul 2012 14:23: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 EB12211E810B for ; Mon, 30 Jul 2012 14:23:57 -0700 (PDT) Received: from localhost (dhcp-469a.meeting.ietf.org [130.129.70.154]) by mail.tail-f.com (Postfix) with ESMTPSA id 2DD971200048; Mon, 30 Jul 2012 23:23:54 +0200 (CEST) Date: Mon, 30 Jul 2012 13:38:38 -0700 (PDT) Message-Id: <20120730.133838.190655144.mbj@tail-f.com> To: yiya@cisco.com From: Martin Bjorklund In-Reply-To: <5E5D58D7-824A-433A-87F1-53E08B80F991@cisco.com> References: <1157C259-DE00-4DD9-870D-2E58CD188ED8@cisco.com> <5E5D58D7-824A-433A-87F1-53E08B80F991@cisco.com> X-Mailer: Mew version 6.3.51 on Emacs 23.3 / 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] comments on draft-ietf-netmod-routing-cfg-04 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, 30 Jul 2012 21:23:59 -0000 Hi, "Yi Yang (yiya)" wrote: > >> 1. If an option node is missed in the reply to the NETCONF message, > >> what does it mean? Does it mean the device doesn't not support the option > >> node, or does it mean the device supports such a option but with a default > >> value? > >> > > > > If the node has a default value defined in the data model, then it means > > that the default value is used - see also RFC 6243. > > In the appendix B, under , is not shown and it should > be interpreted as router "A" supports and has a default value > "true". Yes. > But if router "A" doesn't support (which is an optional > node), how will it reply? Note that an "optional" leaf (i.e., mandatory false) does NOT mean that the server doesn't have to implement it. It means that it is optional / non-mandatory in the configuration, i.e., the user doesn't have to give the leaf a value. /martin From mbj@tail-f.com Mon Jul 30 14:23:59 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F1B111E808E for ; Mon, 30 Jul 2012 14:23:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.645 X-Spam-Level: X-Spam-Status: No, score=-1.645 tagged_above=-999 required=5 tests=[AWL=0.401, 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 LMHgFkub5CTi for ; Mon, 30 Jul 2012 14:23:59 -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 F2CBB11E8113 for ; Mon, 30 Jul 2012 14:23:57 -0700 (PDT) Received: from localhost (dhcp-469a.meeting.ietf.org [130.129.70.154]) by mail.tail-f.com (Postfix) with ESMTPSA id 899561200D1E; Mon, 30 Jul 2012 23:23:56 +0200 (CEST) Date: Mon, 30 Jul 2012 14:03:37 -0700 (PDT) Message-Id: <20120730.140337.420946621.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: X-Mailer: Mew version 6.3.51 on Emacs 23.3 / 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] comment on ietf-interfaces module 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, 30 Jul 2012 21:23:59 -0000 Andy Bierman wrote: > Hi, > > I re-read this draft and I do not understand why there is no generic > equivalent to the ifStackTable. There is no way to describe that > 1 interface is layering above or below another interface. > There is an example in Appendix B for ethernet bonding. > > I understand that different interface types may want to augment > the interface entry with specific fields. This is not an adequate > replacement for a data structure that describes the general interface > layering. Do you mean a config false data structure, in order to view the layering? This goes back to the question how much non-config stuff do we put in this module, when it is available in IF-MIB. /martin From chelliot@gmail.com Mon Jul 30 14:29:21 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02A2521F8607 for ; Mon, 30 Jul 2012 14:29:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pqm2RWOmzvTn for ; Mon, 30 Jul 2012 14:29:20 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id CBA8D21F85F9 for ; Mon, 30 Jul 2012 14:29:19 -0700 (PDT) Received: by weyu54 with SMTP id u54so4365215wey.31 for ; Mon, 30 Jul 2012 14:29:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:content-type; bh=0Weu6Qr37yNg5TR53FhvfuHJfNbAhcJ/aP3KJOdKUTE=; b=xYgm45n16RGSaOje6UQ4U1kKmMXL9tREGiWeyU0KFODWZZFvSpJIm8AdnjHXhA7FIy XrOUswRfL6TtzgNrhX//rMvy99bH8BrDCm4LBpaSZUjJPNaBACGie7rdFvgEjb60E1VN uBxUL64HYAjaaeHYO1BdtLjk+td1t/ONsKIm9FQ/nlcJFS4dddku9e9pNJRUavpGdunM 3UoSMWvMD/rnB34bo+So1/KSEMJlnYb56q7+yDzboe2YaFfPzcNJ9+ssXD5qvjvsy/Er b4ISuzIbnVO9LUMSKcX7aGBInIrxldD2qh3F/CuuFKAkY9gUIQp6CPvxX1WpppXtpPR3 qsfw== Received: by 10.216.132.25 with SMTP id n25mr5980594wei.25.1343683758849; Mon, 30 Jul 2012 14:29:18 -0700 (PDT) MIME-Version: 1.0 Sender: chelliot@gmail.com Received: by 10.194.37.197 with HTTP; Mon, 30 Jul 2012 14:23:41 -0700 (PDT) In-Reply-To: <20120730211414.GA76670@elstar.local> References: <20120730211414.GA76670@elstar.local> From: Chris Elliott Date: Mon, 30 Jul 2012 14:23:41 -0700 X-Google-Sender-Auth: pAXkJ-Tl1Bpdzcpae4uwgfh9xiA Message-ID: To: Juergen Schoenwaelder , Andy Bierman , netmod@ietf.org Content-Type: multipart/alternative; boundary=0016e6dd8d6922fd1a04c612c117 Subject: Re: [netmod] comment on ietf-interfaces module X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: chelliot@pobox.com List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 21:29:21 -0000 --0016e6dd8d6922fd1a04c612c117 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Jul 30, 2012 at 2:14 PM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Mon, Jul 30, 2012 at 01:59:39PM -0700, Andy Bierman wrote: > > Hi, > > > > I re-read this draft and I do not understand why there is no generic > > equivalent to the ifStackTable. There is no way to describe that > > 1 interface is layering above or below another interface. > > There is an example in Appendix B for ethernet bonding. > > > > I understand that different interface types may want to augment > > the interface entry with specific fields. This is not an adequate > > replacement for a data structure that describes the general interface > layering. > > > > The document focuses on configuration. It seems the way to configure > bondings etc. is technology specific. Are you asking for addition of > operational state (config false) objects to report the layering? Or > are you asking for a generic mechanism to configure interface > layering? > Without knowledge of layering, it will be rather difficult to correctly configure interfaces, so I question the usefulness of a model that basically requires you to use another channel (SNMP, screen scraping) to gather the information you need to use the model. Chris. /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 > -- Chris Elliott chelliot@pobox.com --0016e6dd8d6922fd1a04c612c117 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, Jul 30, 2012 at 2:14 PM, Juergen Schoenwaelder &l= t;j.schoenwaelder@jacobs-university.de> wrote:
On Mon, Jul 30, 2012 at 01= :59:39PM -0700, Andy Bierman wrote:
> Hi,
>
> I re-read this draft and I do not understand why there is no generic > equivalent to the ifStackTable. =A0There is no way to describe that > 1 interface is layering above or below another interface.
> There is an example in Appendix B for ethernet bonding.
>
> I understand that different interface types may want to augment
> the interface entry with specific fields. =A0This is not an adequate > replacement for a data structure that describes the general interface = layering.
>

The document focuses on configuration. It seems the way to configure<= br> bondings etc. is technology specific. Are you asking for addition of
operational state (config false) objects to report the layering? =A0Or
are you asking for a generic mechanism to configure interface
layering?

Without knowledge of layering= , it will be rather difficult to correctly configure interfaces, so I quest= ion the usefulness of a model that basically requires you to use another ch= annel (SNMP, screen scraping) to gather the information you need to use the= model.



Chris.

/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, Germany
Fax: =A0 += 49 421 200 3103 =A0 =A0 =A0 =A0 <http://www.jacobs-university.de/>
_____________________= __________________________
netmod mailing list
netmod@ietf.org
= https://www.ietf.org/mailman/listinfo/netmod



--
= Chris Elliott
chelliot@pobox.com

--0016e6dd8d6922fd1a04c612c117-- From pgili@cisco.com Mon Jul 30 14:32:22 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA72011E809A for ; Mon, 30 Jul 2012 14:32:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[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 alcpZnxQi3K9 for ; Mon, 30 Jul 2012 14:32:22 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id E826E21F85ED for ; Mon, 30 Jul 2012 14:32:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pgili@cisco.com; l=1804; q=dns/txt; s=iport; t=1343683942; x=1344893542; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=6mlnSShgEME6YljeECytJQwoUw7EbgCt9eEn9gVn0RA=; b=Xdx/Ab2WGzoa3nG0Q5JVIS0UVDfaqyiJM85d3x3KxsTGLIzZLYHKuXo4 jgcdWl7whwS3FDoQ5OxxlvwMxbudmv6daoBmG4UMCujIKDYbnq6KHpZGH vAKMi4VRObFKrS+A98Et7Gl3yNZEsPaVy4oh/egmUYDo3KdJhQzwwSGNK s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAIL8FlCtJXG9/2dsb2JhbABCA7lZgQeCIAEBAQQBAQEPASc0CwwCAgIBCA4CAQQBAQEKFAkHGwwLFAkIAgQBDQUIGodrC5pqoBgEi0yDaIJBYAOjcIFmgl8 X-IronPort-AV: E=Sophos;i="4.77,681,1336348800"; d="scan'208";a="106742645" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-2.cisco.com with ESMTP; 30 Jul 2012 21:32:21 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id q6ULWLDi015132 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 30 Jul 2012 21:32:21 GMT Received: from xmb-aln-x14.cisco.com ([169.254.8.145]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.02.0298.004; Mon, 30 Jul 2012 16:32:21 -0500 From: "Patrick Gili (pgili)" To: Juergen Schoenwaelder , Andy Bierman Thread-Topic: [netmod] comment on ietf-interfaces module Thread-Index: AQHNbpZApLzaXn+U8UWilvWloQKDDJdCpy8A//+tPBA= Date: Mon, 30 Jul 2012 21:32:20 +0000 Message-ID: <50E64ADF99EAEE4CACEC18958F0FC0AB028A46@xmb-aln-x14.cisco.com> References: <20120730211414.GA76670@elstar.local> In-Reply-To: <20120730211414.GA76670@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.254.154] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19074.001 x-tm-as-result: No--41.667000-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "netmod@ietf.org" Subject: Re: [netmod] comment on ietf-interfaces module 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, 30 Jul 2012 21:32:22 -0000 If you're going to use that argument, then why do we allow the creation/des= truction of interfaces through this model? The IF-MIB doesn't allow the cre= ation/destruction of interfaces, as the authors of that MIB thought the pro= cess of creating and destroying interfaces was technology-specific. Patrick -----Original Message----- From: netmod-bounces@ietf.org [mailto:netmod-bounces@ietf.org] On Behalf Of= Juergen Schoenwaelder Sent: Monday, July 30, 2012 5:14 PM To: Andy Bierman Cc: netmod@ietf.org Subject: Re: [netmod] comment on ietf-interfaces module On Mon, Jul 30, 2012 at 01:59:39PM -0700, Andy Bierman wrote: > Hi, >=20 > I re-read this draft and I do not understand why there is no generic=20 > equivalent to the ifStackTable. There is no way to describe that > 1 interface is layering above or below another interface. > There is an example in Appendix B for ethernet bonding. >=20 > I understand that different interface types may want to augment the=20 > interface entry with specific fields. This is not an adequate=20 > replacement for a data structure that describes the general interface lay= ering. >=20 The document focuses on configuration. It seems the way to configure bondin= gs etc. is technology specific. Are you asking for addition of operational = state (config false) objects to report the layering? Or are you asking for= a generic mechanism to configure interface layering? /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 andy@yumaworks.com Mon Jul 30 14:38:02 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7129E11E8150 for ; Mon, 30 Jul 2012 14:38:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.477 X-Spam-Level: X-Spam-Status: No, score=-2.477 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MDwKAR-iq6Wy for ; Mon, 30 Jul 2012 14:38:01 -0700 (PDT) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id ACD7D11E812C for ; Mon, 30 Jul 2012 14:38:01 -0700 (PDT) Received: by qaea16 with SMTP id a16so1285375qae.10 for ; Mon, 30 Jul 2012 14:38:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding:x-gm-message-state; bh=pxNmdzIwBFUg4fUyfrdtMisgsP5QDVLVPnf5VdTcYNc=; b=XlMe60O9QcGAdfqsY8wcLbN90YUK+yw8+cSLeRPpNa8PJtKWJLEldN/5WEz7OQNnnf 4cnj5boyIBL08erRiDJBoGpyAKwfhA7UmXdSoYWJweblIPplo1HdA8wFb7GZbc6LYAJH 19jnZdI7Hqko61sqEgp1j++y3P7JCgKVmsJ/rfyanZz5SpxJwPpPHf9t4IiKiYT4cYbz 0M+Xnw/VmbD4pyDiHcCWyHjxON/11qN9bPI5gcnrSex9/hxm1eH0NR8YysAf69CrDkxE 1ynm12JOp5aJYFUZVtmF/WE0weaL6HsWJD9TYO8HC/9HwCMIq6+FNPL5AKDgGvL15Zji Bmtg== MIME-Version: 1.0 Received: by 10.224.106.201 with SMTP id y9mr25435932qao.97.1343684281216; Mon, 30 Jul 2012 14:38:01 -0700 (PDT) Received: by 10.49.26.168 with HTTP; Mon, 30 Jul 2012 14:38:01 -0700 (PDT) X-Originating-IP: [2001:df8:0:16:90e8:1d7:63e4:b566] In-Reply-To: <50E64ADF99EAEE4CACEC18958F0FC0AB028A46@xmb-aln-x14.cisco.com> References: <20120730211414.GA76670@elstar.local> <50E64ADF99EAEE4CACEC18958F0FC0AB028A46@xmb-aln-x14.cisco.com> Date: Mon, 30 Jul 2012 14:38:01 -0700 Message-ID: From: Andy Bierman To: "Patrick Gili (pgili)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkvFk7tgDkyWCpZeSRjH+d6JGlQl/zoiZOs9/Ni4+OnkveYvU8RVIclZSpUjDMeIGF1Wkdv Cc: "netmod@ietf.org" Subject: Re: [netmod] comment on ietf-interfaces module 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, 30 Jul 2012 21:38:02 -0000 I was asking for config=3Dfalse objects. I think configuration of layering will probably require augmenting the interface entry with some interface type specific fields. E.g., if I enable an interface that is layered on top of a disabled interface, then it would be useful to know that when wondering why enabling the interface didn't seem to do anything wrt/ device behavior. Andy On Mon, Jul 30, 2012 at 2:32 PM, Patrick Gili (pgili) wro= te: > If you're going to use that argument, then why do we allow the creation/d= estruction of interfaces through this model? The IF-MIB doesn't allow the c= reation/destruction of interfaces, as the authors of that MIB thought the p= rocess of creating and destroying interfaces was technology-specific. > > Patrick > > -----Original Message----- > From: netmod-bounces@ietf.org [mailto:netmod-bounces@ietf.org] On Behalf = Of Juergen Schoenwaelder > Sent: Monday, July 30, 2012 5:14 PM > To: Andy Bierman > Cc: netmod@ietf.org > Subject: Re: [netmod] comment on ietf-interfaces module > > On Mon, Jul 30, 2012 at 01:59:39PM -0700, Andy Bierman wrote: >> Hi, >> >> I re-read this draft and I do not understand why there is no generic >> equivalent to the ifStackTable. There is no way to describe that >> 1 interface is layering above or below another interface. >> There is an example in Appendix B for ethernet bonding. >> >> I understand that different interface types may want to augment the >> interface entry with specific fields. This is not an adequate >> replacement for a data structure that describes the general interface la= yering. >> > > The document focuses on configuration. It seems the way to configure bond= ings etc. is technology specific. Are you asking for addition of operationa= l state (config false) objects to report the layering? Or are you asking f= or a generic mechanism to configure interface layering? > > /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 Mon Jul 30 14:43:15 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 246BF11E8155 for ; Mon, 30 Jul 2012 14:43:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.607 X-Spam-Level: X-Spam-Status: No, score=-102.607 tagged_above=-999 required=5 tests=[AWL=-0.558, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=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 B489QzGCmZIV for ; Mon, 30 Jul 2012 14:43:14 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 88C1E11E8101 for ; Mon, 30 Jul 2012 14:43:14 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id D738E20BF1; Mon, 30 Jul 2012 23:43:13 +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 eURv7Mo4XcNR; Mon, 30 Jul 2012 23:43: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 7012020BEC; Mon, 30 Jul 2012 23:43:13 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id F0BD120FB410; Mon, 30 Jul 2012 23:43:11 +0200 (CEST) Date: Mon, 30 Jul 2012 23:43:11 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20120730214311.GA76720@elstar.local> Mail-Followup-To: Andy Bierman , netmod@ietf.org References: <20120730211414.GA76670@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] comment on ietf-interfaces module 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, 30 Jul 2012 21:43:15 -0000 On Mon, Jul 30, 2012 at 02:23:14PM -0700, Andy Bierman wrote: > I think there is value in knowing that 1 interface is conceptually > layered on top of another 1. Focusing on configuration > is near-sighted if actual operational deployment requires > that some basic information be retrievable in order to > properly modify a device configuration. > > If you are arguing that the ifStackTable has no value and > therefore there is no reason to use something like it in NETCONF, that > is one thing, but config=true vs. config=false is an artificial > distinction. I really wonder how you read "ifStackTable has no value" out of my message. Anyway, I conclude that your answer to my two questions is this: Are you asking for addition of operational state (config false) objects to report the layering? No. Or are you asking for a generic mechanism to configure interface layering? yes I will ignore the rest. /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 Jul 30 14:45:58 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7087611E81A3 for ; Mon, 30 Jul 2012 14:45:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.425 X-Spam-Level: X-Spam-Status: No, score=-1.425 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_45=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 GsB-TKiSKGm7 for ; Mon, 30 Jul 2012 14:45: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 E757711E814E for ; Mon, 30 Jul 2012 14:45:57 -0700 (PDT) Received: from localhost (dhcp-469a.meeting.ietf.org [130.129.70.154]) by mail.tail-f.com (Postfix) with ESMTPSA id 2FEC21200048; Mon, 30 Jul 2012 23:45:56 +0200 (CEST) Date: Mon, 30 Jul 2012 14:44:58 -0700 (PDT) Message-Id: <20120730.144458.521399411.mbj@tail-f.com> To: chelliot@pobox.com From: Martin Bjorklund In-Reply-To: References: <20120730211414.GA76670@elstar.local> X-Mailer: Mew version 6.3.51 on Emacs 23.3 / 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] comment on ietf-interfaces module 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, 30 Jul 2012 21:45:58 -0000 Chris Elliott wrote: > Without knowledge of layering, it will be rather difficult to correctly > configure interfaces, so I question the usefulness of a model that > basically requires you to use another channel (SNMP, screen scraping) to > gather the information you need to use the model. I don't think anyone suggested you'd have to use SNMP. One option is to apply RFC 6643 and read the data over NETCONF. I agree that this is not optimal, but the alternative of copy&paste all counters etc from the MIBs into new YANG modules does not seem very attractive either. Maybe it has to be done on a case-by-case basis - and maybe this is one such case. /martin From chelliot@gmail.com Mon Jul 30 14:53:55 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19B9511E81C9 for ; Mon, 30 Jul 2012 14:53:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.676 X-Spam-Level: X-Spam-Status: No, score=-2.676 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_45=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 JQsvFq6G02rL for ; Mon, 30 Jul 2012 14:53:54 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2631011E81BD for ; Mon, 30 Jul 2012 14:53:52 -0700 (PDT) Received: by weyu54 with SMTP id u54so4378131wey.31 for ; Mon, 30 Jul 2012 14:53:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=C37zii9BgkEuVjDEn3PbQkBu6512DpOHbHZJ3prbmH0=; b=XVE93WieDXSTeEvbMQoa8UshLvWkiqkjzgxtNwLl/VgKYc6IIjGVCafY2cUICsWaDk 6FPT2SrMRmjmSYbPyT0u3MW/xSX+z4/bZ83YWHfYQxDa7O2/3R5AA7DhjrXqw92bgtwL X27lVWOBsLdkYIpi4a4+BdOGwOAOnuKDtllvsImQmdwoVC6vi6hY9WDt9BzIUUk6pXhG eWU5Ql7/N8HfhRWQ5icigFULwh05dAImsVLH9cKkeiQz+O6LUQa/jeUnqTrkEOvaL4A4 G3gIELtrgkvqzSY/VhY2k7taEFEKIetghr9H9KhO+RCGznLcYI6VW0/GZvFz5V9ruCtd v/Kg== Received: by 10.180.96.3 with SMTP id do3mr1366689wib.5.1343685232304; Mon, 30 Jul 2012 14:53:52 -0700 (PDT) MIME-Version: 1.0 Sender: chelliot@gmail.com Received: by 10.194.37.197 with HTTP; Mon, 30 Jul 2012 14:53:31 -0700 (PDT) In-Reply-To: <20120730.144458.521399411.mbj@tail-f.com> References: <20120730211414.GA76670@elstar.local> <20120730.144458.521399411.mbj@tail-f.com> From: Chris Elliott Date: Mon, 30 Jul 2012 14:53:31 -0700 X-Google-Sender-Auth: k6FVeUxFM4ApPxXMnrHPkahCyRg Message-ID: To: Martin Bjorklund Content-Type: multipart/alternative; boundary=f46d04448135f6226304c61318b0 Cc: netmod@ietf.org Subject: Re: [netmod] comment on ietf-interfaces module X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: chelliot@pobox.com List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 21:53:55 -0000 --f46d04448135f6226304c61318b0 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Jul 30, 2012 at 2:44 PM, Martin Bjorklund wrote: > Chris Elliott wrote: > > Without knowledge of layering, it will be rather difficult to correctly > > configure interfaces, so I question the usefulness of a model that > > basically requires you to use another channel (SNMP, screen scraping) to > > gather the information you need to use the model. > > I don't think anyone suggested you'd have to use SNMP. One option is > to apply RFC 6643 and read the data over NETCONF. I agree that this > is not optimal, but the alternative of copy&paste all counters etc > from the MIBs into new YANG modules does not seem very attractive > either. Maybe it has to be done on a case-by-case basis - and maybe > this is one such case. > It seems to me, with my limited experience with YANG, that it can do a much better job of modeling interface layering than ifStackMIB, and that using 6643 for this instance will not end well. That said, I haven't tried Juergen's tool for applying such a conversion to said MIB yet...I'll give it a shot. Chris. > /martin > -- Chris Elliott chelliot@pobox.com --f46d04448135f6226304c61318b0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, Jul 30, 2012 at 2:44 PM, Martin Bjorklund <mbj@tail-f.com> wrote:
Chris Elliott <c= helliot@pobox.com> wrote:
> Without knowledge of layering, it will be rather difficult to correctl= y
> configure interfaces, so I question the usefulness of a model that
> basically requires you to use another channel (SNMP, screen scraping) = to
> gather the information you need to use the model.

I don't think anyone suggested you'd have to use SNMP. =A0One= option is
to apply RFC 6643 and read the data over NETCONF. =A0I agree that this
is not optimal, but the alternative of copy&paste all counters etc
from the MIBs into new YANG modules does not seem very attractive
either. =A0Maybe it has to be done on a case-by-case basis - and maybe
this is one such case.

It seems to me, = with my limited experience with YANG, that it can do a much better job of m= odeling interface layering than ifStackMIB, and that using 6643 for this in= stance will not end well.

That said, I haven't tried Juergen's tool for a= pplying such a conversion to said MIB yet...I'll give it a shot.
<= div>
Chris.
=A0
/martin



-- Chris Elliott
chelliot@pobox.com=

--f46d04448135f6226304c61318b0-- From andy@yumaworks.com Mon Jul 30 15:03:27 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7D7121F8668 for ; Mon, 30 Jul 2012 15:03:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.152 X-Spam-Level: X-Spam-Status: No, score=-2.152 tagged_above=-999 required=5 tests=[AWL=-0.375, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JbYstwGKUeIG for ; Mon, 30 Jul 2012 15:03:25 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6B8A121F8650 for ; Mon, 30 Jul 2012 15:03:18 -0700 (PDT) Received: by qcac10 with SMTP id c10so3593001qca.31 for ; Mon, 30 Jul 2012 15:03:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:content-type:x-gm-message-state; bh=MCTRopCS4EjbDzYJGHAJ97diRF+w6pTZmN3sAzQmXaw=; b=BkD/xI2mdfCe2f9HBAXD1bnplXzVZ5sRaTM5EomEra80fgXhxWs0Urvq6KKrQGKOAY XStfyFONuMtQKDwjVH3uZ9CpAnJV7GxJP1HBW2EdyEsIZ8zk8jMfz9YZvdSELfbDFJ9r adHUybTpeFW1W/TBrQn4pDSmgVooN3LJX662cl3s4eIZfa8zeRbVEB/1skYR4UilSqqj 63nxEFzaBbCBQhjP0iFrIJvWr4xU2j56/GVjEmH72QgeSgZNuLUKYgt1VaU29oUrnRfc 3fnsyjwfhzgKtCv1KPqnlnhvg5l6W13pkc+XF1mo1Mk/O5XvNEMmfMZOBgJsZMTHRUF8 QCPA== MIME-Version: 1.0 Received: by 10.224.42.76 with SMTP id r12mr14881834qae.96.1343685798362; Mon, 30 Jul 2012 15:03:18 -0700 (PDT) Received: by 10.49.26.168 with HTTP; Mon, 30 Jul 2012 15:03:18 -0700 (PDT) X-Originating-IP: [2001:df8:0:16:90e8:1d7:63e4:b566] In-Reply-To: <20120730214311.GA76720@elstar.local> References: <20120730211414.GA76670@elstar.local> <20120730214311.GA76720@elstar.local> Date: Mon, 30 Jul 2012 15:03:18 -0700 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , Andy Bierman , netmod@ietf.org Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQnAI+MfkunE4YaVJOBqZu2VmejkYsiY241219UfsPAEqM+0CiWftXzimAL/E6Lh1cxc6TX5 Subject: Re: [netmod] comment on ietf-interfaces module 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, 30 Jul 2012 22:03:27 -0000 You got it backwards. I think the monitoring info provided by interface layering is useful. Andy On Mon, Jul 30, 2012 at 2:43 PM, Juergen Schoenwaelder wrote: > On Mon, Jul 30, 2012 at 02:23:14PM -0700, Andy Bierman wrote: >> I think there is value in knowing that 1 interface is conceptually >> layered on top of another 1. Focusing on configuration >> is near-sighted if actual operational deployment requires >> that some basic information be retrievable in order to >> properly modify a device configuration. >> >> If you are arguing that the ifStackTable has no value and >> therefore there is no reason to use something like it in NETCONF, that >> is one thing, but config=true vs. config=false is an artificial >> distinction. > > I really wonder how you read "ifStackTable has no value" out of my > message. Anyway, I conclude that your answer to my two questions is > this: > > Are you asking for addition of operational state (config false) > objects to report the layering? No. > > Or are you asking for a generic mechanism to configure interface > layering? yes > > I will ignore the rest. > > /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 Mon Jul 30 15:06:49 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23BB411E81E1 for ; Mon, 30 Jul 2012 15:06:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.602 X-Spam-Level: X-Spam-Status: No, score=-102.602 tagged_above=-999 required=5 tests=[AWL=-0.553, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=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 ZzNqrk4oJk0c for ; Mon, 30 Jul 2012 15:06: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 138EF11E81AE for ; Mon, 30 Jul 2012 15:06:48 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 61A0020BE5; Tue, 31 Jul 2012 00:06:47 +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 8kzDUj5sfIwI; Tue, 31 Jul 2012 00:06: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 E93B320BE2; Tue, 31 Jul 2012 00:06:46 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 1548120FB6D2; Tue, 31 Jul 2012 00:06:46 +0200 (CEST) Date: Tue, 31 Jul 2012 00:06:46 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20120730220646.GB76848@elstar.local> Mail-Followup-To: Andy Bierman , netmod@ietf.org References: <20120730211414.GA76670@elstar.local> <20120730214311.GA76720@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] comment on ietf-interfaces module 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, 30 Jul 2012 22:06:49 -0000 I give up. /js On Mon, Jul 30, 2012 at 03:03:18PM -0700, Andy Bierman wrote: > You got it backwards. > I think the monitoring info provided by interface layering is useful. > > Andy > > > On Mon, Jul 30, 2012 at 2:43 PM, Juergen Schoenwaelder > wrote: > > On Mon, Jul 30, 2012 at 02:23:14PM -0700, Andy Bierman wrote: > >> I think there is value in knowing that 1 interface is conceptually > >> layered on top of another 1. Focusing on configuration > >> is near-sighted if actual operational deployment requires > >> that some basic information be retrievable in order to > >> properly modify a device configuration. > >> > >> If you are arguing that the ifStackTable has no value and > >> therefore there is no reason to use something like it in NETCONF, that > >> is one thing, but config=true vs. config=false is an artificial > >> distinction. > > > > I really wonder how you read "ifStackTable has no value" out of my > > message. Anyway, I conclude that your answer to my two questions is > > this: > > > > Are you asking for addition of operational state (config false) > > objects to report the layering? No. > > > > Or are you asking for a generic mechanism to configure interface > > layering? yes > > > > I will ignore the rest. > > > > /js > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > > Fax: +49 421 200 3103 -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From chelliot@gmail.com Mon Jul 30 16:54:03 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF10111E8072 for ; Mon, 30 Jul 2012 16:54:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.526 X-Spam-Level: X-Spam-Status: No, score=-2.526 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_45=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 00cfsS1LW-57 for ; Mon, 30 Jul 2012 16:54:03 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id BCAFE11E80D5 for ; Mon, 30 Jul 2012 16:54:02 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so3601717wgb.13 for ; Mon, 30 Jul 2012 16:54:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=63d1XBpGaBL0Q/+z+OPCUgb6CJhFgLi9+AChuWapqOU=; b=XyvqVPTWLPEGnnLeGkidC+au6NlQE2dPpAvCYGAE90itPQfAebFqDk9eGoQVhlNn0W ZFGXU4F1k5t4P6mAYJIiigOvQWAsTmsD7D7VaEg0OmCwpi6JdJ+M+ksdV8XF3iuTIm4d gZBckMPXdd+ccQaKZ821BM3uEwLeiC3067a7ZuumVuAQpXpIOL7K1YmxCR/Zo+7IaeIq D70hKBKK9WXB+OGK98WAI6n0hFt/tmT9ZFjVO4PGvX+qPwrjZvsIcuSY+jsyEv8tNuCu UD1UyfU4NW0bG4w+WuIsxWQRDaJJVArjsL5wZx3Ww46XXxYyOaKap23lCOOVzx4w5Xwv Cqjw== Received: by 10.180.96.3 with SMTP id do3mr2032783wib.5.1343692441749; Mon, 30 Jul 2012 16:54:01 -0700 (PDT) MIME-Version: 1.0 Sender: chelliot@gmail.com Received: by 10.194.37.197 with HTTP; Mon, 30 Jul 2012 16:53:41 -0700 (PDT) In-Reply-To: References: <20120730211414.GA76670@elstar.local> <20120730.144458.521399411.mbj@tail-f.com> From: Chris Elliott Date: Mon, 30 Jul 2012 16:53:41 -0700 X-Google-Sender-Auth: I1XCGKwL1jRebYDTQmwUWKuJu9s Message-ID: To: Martin Bjorklund Content-Type: multipart/alternative; boundary=f46d04448135ad896a04c614c644 Cc: netmod@ietf.org Subject: Re: [netmod] comment on ietf-interfaces module X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: chelliot@pobox.com List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 23:54:04 -0000 --f46d04448135ad896a04c614c644 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Jul 30, 2012 at 2:53 PM, Chris Elliott wrote: > On Mon, Jul 30, 2012 at 2:44 PM, Martin Bjorklund wrote: > >> Chris Elliott wrote: >> > Without knowledge of layering, it will be rather difficult to correctly >> > configure interfaces, so I question the usefulness of a model that >> > basically requires you to use another channel (SNMP, screen scraping) to >> > gather the information you need to use the model. >> >> I don't think anyone suggested you'd have to use SNMP. One option is >> to apply RFC 6643 and read the data over NETCONF. I agree that this >> is not optimal, but the alternative of copy&paste all counters etc >> from the MIBs into new YANG modules does not seem very attractive >> either. Maybe it has to be done on a case-by-case basis - and maybe >> this is one such case. >> > > It seems to me, with my limited experience with YANG, that it can do a > much better job of modeling interface layering than ifStackMIB, and that > using 6643 for this instance will not end well. > > That said, I haven't tried Juergen's tool for applying such a conversion > to said MIB yet...I'll give it a shot. > Juergen's tool's interpretation of the ifStackTable ends up with a module that is not compatible with this YANG interface module: ... typedef InterfaceIndexOrZero { type int32 { ... list ifStackEntry { key "ifStackHigherLayer ifStackLowerLayer"; ... leaf ifStackHigherLayer { type if-mib:InterfaceIndexOrZero; ... vs. this YANG interfaces module: ... list interface { key "name"; unique "type location"; ... leaf if-index { if-feature snmp-if-mib; type int32 { ... It seems to me that, if we want to represent stacking that's compatible with the draft YANG interfaces module, then we should not use the ifIndex, whatever it's called, to represent stacking, if it's to be useful. It seems to me that the only things needed are to add is one new leaf, "slave-if", to use the name from Appendix B of this YANG module. That seems much easier to use than how it's done in SMI. Then, Appendix B could be modified to show how "slave-if" could be constrained for Ethernet LAG interfaces (ieee8023adLag), for example. I also think that these objects must be configurable. This YANG module allows one to create interfaces, unless I don't understand the purpose of this YANG module, which makes sense for virtual interfaces, for example, that are often layered on other interfaces. Interface Eth0.1 can't be successfully created without configuring that it's a sub-interface of Eth0. I also think that layering of interfaces is this simple, and this model can represent all cases of layering and we should not implement layering in the interface type-specific modules. This capability could be used to move a virtual interface to another physical interface, for example, instead of deleting and recreating the interface or whole stack of interfaces. This seems to me to be a free and rather interesting additional capability that could be useful in many instances, and Appendix B shows an excellent example of the need for this--binding multiple physical interfaces into one LAG. Chris. > Chris. > > >> /martin >> > > > > -- > Chris Elliott > chelliot@pobox.com > > -- Chris Elliott chelliot@pobox.com --f46d04448135ad896a04c614c644 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, Jul 30, 2012 at 2:53 PM, Chris Elliott <chelliot@pobox.com>= ; wrote:
On Mon, Jul 30, 2012 at 2:44 PM, Ma= rtin Bjorklund <mbj@tail-f.com> wrote:
Chris Elliott <chelliot@pobox.com> wrote:
> Without knowledge of layering, it will be rather difficult to correctl= y
> configure interfaces, so I question the usefulness of a model that
> basically requires you to use another channel (SNMP, screen scraping) = to
> gather the information you need to use the model.

I don't think anyone suggested you'd have to use SNMP. =A0One= option is
to apply RFC 6643 and read the data over NETCONF. =A0I agree that this
is not optimal, but the alternative of copy&paste all counters etc
from the MIBs into new YANG modules does not seem very attractive
either. =A0Maybe it has to be done on a case-by-case basis - and maybe
this is one such case.

It s= eems to me, with my limited experience with YANG, that it can do a much bet= ter job of modeling interface layering than ifStackMIB, and that using 6643= for this instance will not end well.

That said, I haven't tried Juergen's tool for a= pplying such a conversion to said MIB yet...I'll give it a shot.
<= /div>

Juergen's tool's interpretati= on of the ifStackTable ends up with a module that is not compatible with th= is YANG interface module:
...
=A0 typedef InterfaceIndexOrZero {
=A0= =A0 type int32 {
...
=A0 =A0 list ifStackEntry {
=A0 =A0 =A0 k= ey "ifStackHigherLayer ifStackLowerLayer";=A0
...
=A0 =A0 =A0 leaf ifStackHigherLayer {
=A0 =A0 =A0 =A0 type if-mib:Interf= aceIndexOrZero;
...

vs. this YANG interfaces module:
...
=A0 list interface {
=A0 =A0 =A0 =A0 =A0key &= quot;name";
=A0 =A0 =A0 =A0 =A0unique "type location";...
=A0 =A0 leaf if-index {
=A0 =A0 =A0 =A0 =A0 =A0if-feature snmp= -if-mib;
=A0 =A0 =A0 =A0 =A0 =A0type int32 {
...

It seems to me that, if we want to represent stackin= g that's compatible with the draft YANG interfaces module, then we shou= ld not use the ifIndex, whatever it's called, to represent stacking, if= it's to be useful. It seems to me that the only things needed are to a= dd is one new leaf, "slave-if", to use the name from Appendix B o= f this YANG module. That seems much easier to use than how it's done in= SMI. Then, Appendix B could be modified to show how "slave-if" c= ould be constrained for Ethernet LAG interfaces (ieee8023adLag), for example.

I also think that these objects must be configurable. T= his YANG module allows one to create interfaces, unless I don't underst= and the purpose of this YANG module, which makes sense for virtual interfac= es, for example, that are often layered on other interfaces. Interface Eth0= .1 can't be successfully created without configuring that it's a su= b-interface of Eth0. I also think that layering of interfaces is this simpl= e, and this model can represent all cases of layering and we should not imp= lement layering in the interface type-specific modules.

This capability could be used to move a virtual interfa= ce =A0to another physical interface, for example, instead of deleting and r= ecreating the interface or whole stack of interfaces. This seems to me to b= e a free and rather interesting additional capability that could be useful = in many instances, and Appendix B shows an excellent example of the need fo= r this--binding multiple physical interfaces into one LAG.

Chris.
=A0
Chris= .
=A0
/martin



--
Chris Elliot= t
chelliot@pobox= .com




-- Chris Elliott
chelliot@pobox.com=

--f46d04448135ad896a04c614c644-- From yiya@cisco.com Mon Jul 30 18:28:00 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43CDA11E80E9 for ; Mon, 30 Jul 2012 18:27:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.099 X-Spam-Level: X-Spam-Status: No, score=-10.099 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, J_CHICKENPOX_74=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CwJmNW6A2SnF for ; Mon, 30 Jul 2012 18:27:57 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 3B83A11E80E4 for ; Mon, 30 Jul 2012 18:27:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=yiya@cisco.com; l=1954; q=dns/txt; s=iport; t=1343698077; x=1344907677; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=92J5kYQyMt4JVuITyI+As5GDIEIj3nNVhUdzPQ3bOfQ=; b=iBijshKtic4q72RcU0vyF8Z21I/Uw0bygrvGFxFapih2HHe2eS9u5xyh Khn/vPQoyTP0JhX5x79gVqTljUIbEU0VcRZmFAobf1uwoeufUvjM65zkT 9I0Uhyn+6OF1bNLNTPA+aUzO/JzLiut8v1RU+yYyvReQrPgHWLRoCXHyN E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EABE0F1CtJXHA/2dsb2JhbABFuWCBB4IhAQEEEgEnMQ4QAgEINhAyJQIEDgUih2sLmnqgRItOhilgA5VIjieBZoJf X-IronPort-AV: E=Sophos;i="4.77,681,1336348800"; d="scan'208";a="106839950" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-4.cisco.com with ESMTP; 31 Jul 2012 01:27:54 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id q6V1Rs2t009141 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 31 Jul 2012 01:27:54 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.33]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.02.0298.004; Mon, 30 Jul 2012 20:27:54 -0500 From: "Yi Yang (yiya)" To: Ladislav Lhotka Thread-Topic: comments on draft-ietf-netmod-routing-cfg-04 Thread-Index: AQHNbCicgjImo6D/hUmbbdTBxQ8JeZdAgg4AgADnagCAANDigIAAUjsAgAAfeYCAAEcVAA== Date: Tue, 31 Jul 2012 01:27:53 +0000 Message-ID: <8D98A55A-A05D-41B5-9C82-616F9CB0EE51@cisco.com> References: <45BE39D9-2E92-4139-B579-B125649CD287@cisco.com> <1157C259-DE00-4DD9-870D-2E58CD188ED8@cisco.com> <5E5D58D7-824A-433A-87F1-53E08B80F991@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.75.7] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19074.001 x-tm-as-result: No--43.311800-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <015BE296CBC2EA4A8A496EAB864C0597@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "netmod@ietf.org" Subject: Re: [netmod] comments on draft-ietf-netmod-routing-cfg-04 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, 31 Jul 2012 01:28:00 -0000 Hi Ladislav, On Jul 30, 2012, at 5:14 PM, Ladislav Lhotka wrote: > "Yi Yang (yiya)" writes: >> I am not an expert on Junos, but here is the output of "show route forwa= rding-table", from http://www.juniper.net/techpubs/en_US/junos12.1/topics/r= eference/command-summary/show-route-forwarding-table-mpls-ex-series.html >>=20 >> user@switch> show route forwarding-table >> Routing table: default.inet >> Internet: >> Destination Type RtRef Next hop Type Index NhRef Netif >> default user 2 0:12:f2:21:cf:0 ucst 333 5 me0.0 >> default perm 0 rjct 36 2 >> 0.0.0.0/32 perm 0 dscd 34 1 >> 2.2.2.0/24 intf 0 rslv 1309 1 ae0.0 >> ....... >>=20 >> Compared to the output of "show route", from >> http://www.juniper.net/techpubs/en_US/junos12.1/topics/reference/command= -summary/show-route.html >>=20 >> user@host> show route >> inet.0: 10 destinations, 10 routes (9 active, 0 holddown, 1 hidden) >> + =3D Active Route, - =3D Last Active, * =3D Both >> 0.0.0.0/0 *[Static/5] 1w5d 20:30:29 >> Discard >> 10.255.245.51/32 *[Direct/0] 2w4d 13:11:14 >>> via lo0.0 >> 172.16.0.0/12 *[Static/5] 2w4d 13:11:14 >>> to 192.168.167.254 via fxp0.0 >> 192.168.0.0/18 *[Static/5] 1w5d 20:30:29 >>> to 192.168.167.254 via fxp0.0 >>=20 >> As mentioned earlier, source/age are not shown in the forwarding table, = unless they are hidden intentionally? Maybe someone familiar with Junos can= comment on this? >=20 > Would it help if "age" and "source-protocol" were not mandatory? I am inclined to separate forwarding table from routing table. The forwardi= ng table is so special that it has a different data structure, doesn't inte= ract with routing protocol directly, and doesn't support export filters... Yi= From lhotka@nic.cz Mon Jul 30 18:45:23 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3335921F8517 for ; Mon, 30 Jul 2012 18:45:23 -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, J_CHICKENPOX_74=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 l-78hAvTvaLv for ; Mon, 30 Jul 2012 18:45:22 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 6285E21F8512 for ; Mon, 30 Jul 2012 18:45:22 -0700 (PDT) Received: from [IPv6:2001:df8::16:159e:a3f9:b7d2:714f] (unknown [IPv6:2001:df8:0:16:159e:a3f9:b7d2:714f]) by mail.nic.cz (Postfix) with ESMTPSA id 3757513F9C4; Tue, 31 Jul 2012 03:45:20 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1343699120; bh=4paBGlITd4heIeih9j4FWbAU0ralPovyzH0e/K9MbO0=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=hqgYB6FNdrZq7JYXcpGUALbyoSU3BUkqAWTBsyqOFdd17ubJIppcnRk26MwmVZRN+ 9va8DDHJ1AHVx7QBIyr2q07wxwNF3KttLxz+aTZEIs8a6ubo2RUryqoeXoWQVQWoiF 4aI9N8oRqPRdBPx0tBfarE1VrSLlwFpRICIYKLMA= Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=windows-1252 From: Ladislav Lhotka In-Reply-To: <8D98A55A-A05D-41B5-9C82-616F9CB0EE51@cisco.com> Date: Mon, 30 Jul 2012 18:45:18 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <63AD2EEF-E8EC-42F4-82E9-19D248DA9904@nic.cz> References: <45BE39D9-2E92-4139-B579-B125649CD287@cisco.com> <1157C259-DE00-4DD9-870D-2E58CD188ED8@cisco.com> <5E5D58D7-824A-433A-87F1-53E08B80F991@cisco.com> <8D98A55A-A05D-41B5-9C82-616F9CB0EE51@cisco.com> To: "Yi Yang (yiya)" X-Mailer: Apple Mail (2.1278) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: "netmod@ietf.org" Subject: Re: [netmod] comments on draft-ietf-netmod-routing-cfg-04 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, 31 Jul 2012 01:45:23 -0000 On Jul 30, 2012, at 6:27 PM, Yi Yang (yiya) wrote: > Hi Ladislav, >=20 > On Jul 30, 2012, at 5:14 PM, Ladislav Lhotka wrote: >=20 >> "Yi Yang (yiya)" writes: >>> I am not an expert on Junos, but here is the output of "show route = forwarding-table", from = http://www.juniper.net/techpubs/en_US/junos12.1/topics/reference/command-s= ummary/show-route-forwarding-table-mpls-ex-series.html >>>=20 >>> user@switch> show route forwarding-table >>> Routing table: default.inet >>> Internet: >>> Destination Type RtRef Next hop Type Index NhRef = Netif >>> default user 2 0:12:f2:21:cf:0 ucst 333 5 = me0.0 >>> default perm 0 rjct 36 2 >>> 0.0.0.0/32 perm 0 dscd 34 1 >>> 2.2.2.0/24 intf 0 rslv 1309 1 = ae0.0 >>> ....... >>>=20 >>> Compared to the output of "show route", from >>> = http://www.juniper.net/techpubs/en_US/junos12.1/topics/reference/command-s= ummary/show-route.html >>>=20 >>> user@host> show route >>> inet.0: 10 destinations, 10 routes (9 active, 0 holddown, 1 hidden) >>> + =3D Active Route, - =3D Last Active, * =3D Both >>> 0.0.0.0/0 *[Static/5] 1w5d 20:30:29 >>> Discard >>> 10.255.245.51/32 *[Direct/0] 2w4d 13:11:14 >>>> via lo0.0 >>> 172.16.0.0/12 *[Static/5] 2w4d 13:11:14 >>>> to 192.168.167.254 via fxp0.0 >>> 192.168.0.0/18 *[Static/5] 1w5d 20:30:29 >>>> to 192.168.167.254 via fxp0.0 >>>=20 >>> As mentioned earlier, source/age are not shown in the forwarding = table, unless they are hidden intentionally? Maybe someone familiar with = Junos can comment on this? >>=20 >> Would it help if "age" and "source-protocol" were not mandatory? >=20 > I am inclined to separate forwarding table from routing table. The = forwarding table is so special that it has a different data structure, = doesn't interact with routing protocol directly, and doesn't support = export filters=85 This is certainly an option - somebody can write such an extension as a = separate module. But, as I said, some implementations do not use a = forwarding table. Lada >=20 > Yi -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From jernej.tuljak@mg-soft.si Mon Jul 30 23:25:47 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9309721F8620 for ; Mon, 30 Jul 2012 23:25:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.193 X-Spam-Level: X-Spam-Status: No, score=-2.193 tagged_above=-999 required=5 tests=[AWL=-0.194, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M5nq50L6MyeT for ; Mon, 30 Jul 2012 23:25:47 -0700 (PDT) Received: from gate.mg-soft.si (gate.mg-soft.si [212.30.73.66]) by ietfa.amsl.com (Postfix) with ESMTP id C766C21F8533 for ; Mon, 30 Jul 2012 23:25:45 -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 q6V6PgJT032240; Tue, 31 Jul 2012 08:25:42 +0200 Message-ID: <50177A64.1020907@mg-soft.com> Date: Tue, 31 Jul 2012 08:25:40 +0200 From: Jernej Tuljak User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Ladislav Lhotka References: <50165FAA.4040700@mg-soft.com> <50169FED.3000801@mg-soft.com> <3D0FFE5C-3D88-4BB5-862E-66A9B01A96FA@nic.cz> In-Reply-To: <3D0FFE5C-3D88-4BB5-862E-66A9B01A96FA@nic.cz> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] XPath errors in ietf-snmp.yang 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, 31 Jul 2012 06:25:47 -0000 Yes. Modified pyang XSLT stylesheets. That's also why I've been sending bug reports. Learned a lot while doing all this and it wasn't easy but now we got a working YANG-aware XML editor as a result. Jernej Dne 30.7.2012 17:48, piše Ladislav Lhotka: > On Jul 30, 2012, at 7:53 AM, Jernej Tuljak wrote: > >> You are wrong about pyang ignoring XPath expressions. True that they are not checked during YANG validation thoroughly but are later used within it's DSDL plugin to validate instance documents. This represents one way of debugging XPath used within YANG. I'm quite familiar with pyang since I ported major parts of it to Java. > > Interesting. Regarding DSDL, does it mean that you generate the hybrid schema in Java and then use the XSLT stylesheets from pyang? > > Lada > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > From pgili@cisco.com Tue Jul 31 03:33:18 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEA7421F86AA for ; Tue, 31 Jul 2012 03:33:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=-0.301, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r5LQtROZhYmg for ; Tue, 31 Jul 2012 03:33:15 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id DF97921F869E for ; Tue, 31 Jul 2012 03:33:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pgili@cisco.com; l=19431; q=dns/txt; s=iport; t=1343730795; x=1344940395; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=0vg+LOeu3fbAc4cXRjrZh8XkTCaD+NvfmpdEDlXle6c=; b=N22uRaW0SZYFNNQIJ+AljFuQd/+23lWKeepoBO5reJd3sIzzI/oeM3kd lbfxLuWUuXR4moNVcqtoiL/K4vqag4iVJGCj/50a7ePVWyo+j+UJlRlmh 6jsu+o+shlZUUL6C4AhlZbmDF3hZT0qdHKCZeVEai19T3089jBZPY+lnl Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAFKzF1CtJV2Y/2dsb2JhbABFgkq3K4EHgiABAQEEEgEaTBACAQgRBAEBAQodBzIUCQgCBAENBQgah2ubS6Bki0kUhhVgA6NugWaCX4FW X-IronPort-AV: E=Sophos;i="4.77,682,1336348800"; d="scan'208,217";a="106945323" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-5.cisco.com with ESMTP; 31 Jul 2012 10:33:14 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q6VAXEFg011902 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 31 Jul 2012 10:33:14 GMT Received: from xmb-aln-x14.cisco.com ([169.254.8.145]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.02.0298.004; Tue, 31 Jul 2012 05:33:13 -0500 From: "Patrick Gili (pgili)" To: "chelliot@pobox.com" , Martin Bjorklund Thread-Topic: [netmod] comment on ietf-interfaces module Thread-Index: AQHNbpZApLzaXn+U8UWilvWloQKDDJdCpy8AgAACpICAAAXyAIAAAmSAgAAhk4CAAF1OIA== Date: Tue, 31 Jul 2012 10:33:12 +0000 Message-ID: <50E64ADF99EAEE4CACEC18958F0FC0AB028FEB@xmb-aln-x14.cisco.com> References: <20120730211414.GA76670@elstar.local> <20120730.144458.521399411.mbj@tail-f.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.254.154] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19074.004 x-tm-as-result: No--48.260100-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_50E64ADF99EAEE4CACEC18958F0FC0AB028FEBxmbalnx14ciscocom_" MIME-Version: 1.0 Cc: "netmod@ietf.org" Subject: Re: [netmod] comment on ietf-interfaces module 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, 31 Jul 2012 10:33:18 -0000 --_000_50E64ADF99EAEE4CACEC18958F0FC0AB028FEBxmbalnx14ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Chris, I like your idea, but have two nits: - Can we not invent new terminology? For decades we have used the = terms "subordinate" and "superior", rather "slave" and "master". - This "slave-if" would need to be a leaf-list, as there exists th= e potential for an interface to sit atop more than one interface, such as t= he Ethernet LAG example or other forms of interface bonding. Also, it is convenient to traverse interface stacks bottom-up, rather than = top-down. This is the reason why RFC 2864 came about. Patrick From: netmod-bounces@ietf.org [mailto:netmod-bounces@ietf.org] On Behalf Of= Chris Elliott Sent: Monday, July 30, 2012 7:54 PM To: Martin Bjorklund Cc: netmod@ietf.org Subject: Re: [netmod] comment on ietf-interfaces module On Mon, Jul 30, 2012 at 2:53 PM, Chris Elliott > wrote: On Mon, Jul 30, 2012 at 2:44 PM, Martin Bjorklund > wrote: Chris Elliott > wrote: > Without knowledge of layering, it will be rather difficult to correctly > configure interfaces, so I question the usefulness of a model that > basically requires you to use another channel (SNMP, screen scraping) to > gather the information you need to use the model. I don't think anyone suggested you'd have to use SNMP. One option is to apply RFC 6643 and read the data over NETCONF. I agree that this is not optimal, but the alternative of copy&paste all counters etc from the MIBs into new YANG modules does not seem very attractive either. Maybe it has to be done on a case-by-case basis - and maybe this is one such case. It seems to me, with my limited experience with YANG, that it can do a much= better job of modeling interface layering than ifStackMIB, and that using = 6643 for this instance will not end well. That said, I haven't tried Juergen's tool for applying such a conversion to= said MIB yet...I'll give it a shot. Juergen's tool's interpretation of the ifStackTable ends up with a module t= hat is not compatible with this YANG interface module: ... typedef InterfaceIndexOrZero { type int32 { ... list ifStackEntry { key "ifStackHigherLayer ifStackLowerLayer"; ... leaf ifStackHigherLayer { type if-mib:InterfaceIndexOrZero; ... vs. this YANG interfaces module: ... list interface { key "name"; unique "type location"; ... leaf if-index { if-feature snmp-if-mib; type int32 { ... It seems to me that, if we want to represent stacking that's compatible wit= h the draft YANG interfaces module, then we should not use the ifIndex, wha= tever it's called, to represent stacking, if it's to be useful. It seems to= me that the only things needed are to add is one new leaf, "slave-if", to = use the name from Appendix B of this YANG module. That seems much easier to= use than how it's done in SMI. Then, Appendix B could be modified to show = how "slave-if" could be constrained for Ethernet LAG interfaces (ieee8023ad= Lag), for example. I also think that these objects must be configurable. This YANG module allo= ws one to create interfaces, unless I don't understand the purpose of this = YANG module, which makes sense for virtual interfaces, for example, that ar= e often layered on other interfaces. Interface Eth0.1 can't be successfully= created without configuring that it's a sub-interface of Eth0. I also thin= k that layering of interfaces is this simple, and this model can represent = all cases of layering and we should not implement layering in the interface= type-specific modules. This capability could be used to move a virtual interface to another physi= cal interface, for example, instead of deleting and recreating the interfac= e or whole stack of interfaces. This seems to me to be a free and rather in= teresting additional capability that could be useful in many instances, and= Appendix B shows an excellent example of the need for this--binding multip= le physical interfaces into one LAG. Chris. Chris. /martin -- Chris Elliott chelliot@pobox.com -- Chris Elliott chelliot@pobox.com --_000_50E64ADF99EAEE4CACEC18958F0FC0AB028FEBxmbalnx14ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Chris,

 <= /p>

I like your idea, but hav= e two nits:

- =          Can we not invent= new terminology? For decades we have used the terms “subordinateR= 21; and “superior”, rather “slave” and “maste= r”.

- =          This “slave= -if” would need to be a leaf-list, as there exists the potential for = an interface to sit atop more than one interface, such as the Ethernet LAG example or other forms of interface bonding.

 <= /p>

Also, it is convenient to= traverse interface stacks bottom-up, rather than top-down. This is the rea= son why RFC 2864 came about.

 <= /p>

Patrick=

 

From: netmod-b= ounces@ietf.org [mailto:netmod-bounces@ietf.org] On Behalf Of Chris Elliott
Sent: Monday, July 30, 2012 7:54 PM
To: Martin Bjorklund
Cc: netmod@ietf.org
Subject: Re: [netmod] comment on ietf-interfaces module

 

On Mon, Jul 30, 2012 at 2:53 PM, Chris Elliott <<= a href=3D"mailto:chelliot@pobox.com" target=3D"_blank">chelliot@pobox.com> wrote:

On Mon, Jul 30, 2012 at 2:44 PM, Martin Bjorklund &l= t;mbj@tail-f.com>= ; wrote:

Chris Elliott <chelliot@pobox.com= > wrote:
> Without knowledge of layering, it will be rather difficult to correctl= y
> configure interfaces, so I question the usefulness of a model that
> basically requires you to use another channel (SNMP, screen scraping) = to
> gather the information you need to use the model.

I don't think anyone suggested you'd have to use SNM= P.  One option is
to apply RFC 6643 and read the data over NETCONF.  I agree that this is not optimal, but the alternative of copy&paste all counters etc
from the MIBs into new YANG modules does not seem very attractive
either.  Maybe it has to be done on a case-by-case basis - and maybe this is one such case.

 

It seems to me, with my limited experience with YANG= , that it can do a much better job of modeling interface layering than ifSt= ackMIB, and that using 6643 for this instance will not end well.=

 

That said, I haven't tried Juergen's tool for applyi= ng such a conversion to said MIB yet...I'll give it a shot.

 

Juergen's tool's interpretation of the ifStackTable = ends up with a module that is not compatible with this YANG interface modul= e:

...
  typedef InterfaceIndexOrZero {
    type int32 {
...

    list ifStackEntry {
      key "ifStackHigherLayer ifStackLowerLayer";&= nbsp;

...
      leaf ifStackHigherLayer {
        type if-mib:InterfaceIndexOrZero;
...

 

vs. this YANG interfaces module:

...

  list interface {
         key "name";
         unique "type location";
...

    leaf if-index {
           if-feature snmp-if-mib;
           type int32 {
...

 

It seems to me that, if we want to represent stackin= g that's compatible with the draft YANG interfaces module, then we should n= ot use the ifIndex, whatever it's called, to represent stacking, if it's to= be useful. It seems to me that the only things needed are to add is one new leaf, "slave-if", to us= e the name from Appendix B of this YANG module. That seems much easier to u= se than how it's done in SMI. Then, Appendix B could be modified to show ho= w "slave-if" could be constrained for Ethernet LAG interfaces (ieee8023adLag), for example.

 

I also think that these objects must be configurable= . This YANG module allows one to create interfaces, unless I don't understa= nd the purpose of this YANG module, which makes sense for virtual interface= s, for example, that are often layered on other interfaces. Interface Eth0.1 can't be successfully created withou= t configuring that it's a sub-interface of Eth0. I also think that layering= of interfaces is this simple, and this model can represent all cases of la= yering and we should not implement layering in the interface type-specific modules.

 

This capability could be used to move a virtual inte= rface  to another physical interface, for example, instead of deleting= and recreating the interface or whole stack of interfaces. This seems to m= e to be a free and rather interesting additional capability that could be useful in many instances, and Appendix B shows an= excellent example of the need for this--binding multiple physical interfac= es into one LAG.

 

Chris.

 

Chris.

 

/martin



 

--
Chris Elliott
chelliot@pobox.com



 

--
Chris Elliott
chelliot@pobox.com

--_000_50E64ADF99EAEE4CACEC18958F0FC0AB028FEBxmbalnx14ciscocom_-- From mbj@tail-f.com Tue Jul 31 06:41:25 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48D2F21F86B3 for ; Tue, 31 Jul 2012 06:41:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.233 X-Spam-Level: X-Spam-Status: No, score=-1.233 tagged_above=-999 required=5 tests=[AWL=-0.179, BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, 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 o2iBHojg5APX for ; Tue, 31 Jul 2012 06:41:24 -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 205F821F86B4 for ; Tue, 31 Jul 2012 06:41:23 -0700 (PDT) Received: from localhost (dhcp-4088.meeting.ietf.org [130.129.64.136]) by mail.tail-f.com (Postfix) with ESMTPSA id AB57112008E8 for ; Tue, 31 Jul 2012 15:41:21 +0200 (CEST) Date: Mon, 30 Jul 2012 15:26:29 -0700 (PDT) Message-Id: <20120730.152629.378501941.mbj@tail-f.com> To: netmod@ietf.org From: Martin Bjorklund X-Mailer: Mew version 6.3.51 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [netmod] mbj review of draft-ietf-netmod-routing-cfg-04 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, 31 Jul 2012 13:41:25 -0000 Hi, I have reviewed this document and here are my comments. o 4. bullet 1 (after Figure 2) o Along with the main routing table, which must always be present, an additional routing table is configured. What does "must always be present mean"? This needs to be clarified. In my world, it should not be necessary to configure this, so I assume it means that it always exists operationally, even if it is not explicitly configured. o 4.1. It would be useful with a paragraph that explains that an implementation doesn't have to support more than a single router (i.e., no logical routers). It would also be useful to include the text you wrote in http://www.ietf.org/mail-archive/web/netmod/current/msg06845.html. o 4.3. Why is the main routing table's name only a SHOULD? If it not a MUST, how will a client know which table is main? o 4.3. The naming scheme for additional routing tables, as well as restrictions on the number and configurability of routing tables are implementation-specific. What does "restrictions on configurability" mean? o 4.4 Each routing protocol instance is connected to exactly one routing table for each address family that the routing protocol instance supports. How do I know which address families a routing protocol instance supports? o 4.4.1 OLD: Every router instance MUST contain exactly one instance of the "direct" pseudo-protocol type. The name of this instance MUST also be "direct". NEW: Every router instance MUST contain exactly one "routing-protocol" instance of the "direct" pseudo-protocol type. The name of this instance MUST also be "direct". What does this MUST mean? Do I have to configure this routing-protocol instance? What happens if I try to delete it? Why is the name important? Isn't it better to state that if no routing-protocol instance of type "direct" is configured, then all routes are sent to the main routing table. o 4.4.1 A pseudo-protocol of the type "static" allows for specifying routes manually. It MAY be configured in zero or multiple instances, although a typical implementation will have exactly one instance per logical router. Do you mean "typical configuration"? o 4.5 The default value for the route filter type is the identity "deny-all-route-filter". I still think this is confusing and not necessary. If I define a filter and leave out the type, the filter will block everything. I think the result will be much more clear if the type is mandatory. I.e., when a filter is defined, the type must also be specified. o 4.6. I think we should stop using the semi-formal notation of specifying new rpcs. The YANG definition is supposed to capture all this information in a more strict way. This only leads to duplicate text and the opportunity for errors. In fact, the text, but not the YANG module, was updated with the "error-tag" fix. I suggest you remove 4.6.1 and 4.6.2, and just provide a short descrioption of these operations in 4.6. (and fix the text in the YANG module). You also use the term "FIB" here, but "forwarding table" earlier. Also, the rpc active-route says that is reads the route from the FIB, but earlier you wrote that the FIB was optional. So this should probably be rephrased. o 5.2 identity direct Move text from 4.4.1 to the description. Same for "static". o 5.2 identity deny-all-route-filter Should it be called "deny-all-routes"? o 5.2. grouping afn-safi leaf address-family { type ianaaf:address-family; default "ipv4"; Is this default really appropriate? Isn't it better w/ no default? o 5.2. There are some single-qouted strings in descriptions that should be changed to double-quoted strings (in all three modules). o 5.2. leaf name { type string; description "The unique router name."; } NEW: "An arbitrary name of the router instance."; o 5.2 leaf name { type string; description "The name of the routing protocol instance."; } NEW: "An arbitrary name of the routing protocol instance."; OR: state that an implementation MAY restrict the allowed values of this name (if this is what you meant). o 5.2. Currently you have: +--rw connected-routing-tables | +--rw routing-table [name] Should the latter list be called "connected-routing-table" for consistency with the rest of the model? The impressive "must" expression in this list uses a "rt:" prefix on some nodes, but not all. I suggest you remove it from all nodes for consistency. o 5.2. container static-routes { must "../type='rt:static'" { This should be "when", not "must". See also 4.4.2 bullet 4! o 5.2. list routing-table { key "name"; description "Each entry represents a routing table identified by the 'name' key. All routes in a routing table must have the same AFN and SAFI."; The last sentence has a "must" that doesn't make much sense, since a route doesn't "uses afn-safi". NEW: 'name' key. All routes in a routing table have the same AFN and SAFI."; o 5.2 list route { description "A routing table entry. This data node must augmented s/must augmented/must be augmented/ o 5.2. leaf source-protocol { type leafref { path "/routing/router/routing-protocols/" + "routing-protocol/name"; } I think the leafref should be relative - otherwise you can point to protocols in other logical routers. The text says: This routing protocol must be configured (automatically or manually) in the device." so what happens if the routing protocol instance is removed? Will all its routes be removed? o 5.2 list recipient-routing-table { ... leaf name { type leafref { path "/routing/router/routing-tables/" + "routing-table/name"; } This should also be a relative path. o 7 Every implementation must preconfigure a routing table with the name 'main-ipv4-unicast', which is the main routing table for IPv4 unicast. This contraditcs the SHOULD on page 12. o 7 list route { ... leaf id { type uint32 { range "1..max"; } Why do you have a numeric id if it is arbitrary? Why not a string? o 8 NOTE: Parameter 'is-router' is not included, it is expected that it will be implemented by the 'ietf-ip' module. Remove this sentence, or rephrase. o 8 leaf min-rtr-adv-interval { ... description "The minimum time allowed between sending unsolicited multicast Router Advertisements from the interface. Must be no greater than 0.75 * max-rtr-adv-interval. Make a "must" statement out if this constraint. o 8 leaf cur-hop-limit { default "64"; description ... The default should be set to the value specified in IANA Assigned Numbers that was in effect at the time of implementation. Either remove the default statement, or change the text. o 8 leaf default-lifetime { ... The default value is dynamic and should be set to 3 * max-rtr-adv-interval. I prefer to not use the term "dynamic default". I suggest this: If this leaf is not configured, the server uses the value 3 * max-rtr-adv-interval. /martin From mbj@tail-f.com Tue Jul 31 07:23:15 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AA8D21F8604 for ; Tue, 31 Jul 2012 07:23:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.703 X-Spam-Level: X-Spam-Status: No, score=-1.703 tagged_above=-999 required=5 tests=[AWL=0.343, 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 jvckmoPqQPXq for ; Tue, 31 Jul 2012 07:23:14 -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 6FF5121F85D5 for ; Tue, 31 Jul 2012 07:23:14 -0700 (PDT) Received: from localhost (dhcp-4088.meeting.ietf.org [130.129.64.136]) by mail.tail-f.com (Postfix) with ESMTPSA id B25AF1200048; Tue, 31 Jul 2012 16:23:12 +0200 (CEST) Date: Tue, 31 Jul 2012 07:21:42 -0700 (PDT) Message-Id: <20120731.072142.385816835.mbj@tail-f.com> To: jernej.tuljak@mg-soft.si From: Martin Bjorklund In-Reply-To: <50165FAA.4040700@mg-soft.com> References: <50165FAA.4040700@mg-soft.com> X-Mailer: Mew version 6.3.51 on Emacs 23.3 / 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] XPath errors in ietf-snmp.yang 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, 31 Jul 2012 14:23:15 -0000 Hi, Jernej Tuljak wrote: > Dne 29.7.2012 1:34, pi=A8e Andy Bierman: > > Hi, > > > > I am getting lots of XPath errors reported from yangdump: > > > > > > > > *** Generated by yangdump 5.0.da08cd7 > > *** Copyright (c) 2008-2012, Andy Bierman, All Rights Reserved. > > > > Warning: no child nodes found in XPath expr '../type =3D read or ..= /type =3D write' > > ietf-snmp-proxy.yang:114.24: warning(432): no child node available > > > > Warning: no child nodes found in XPath expr '../type =3D read or ..= /type =3D write' > > ietf-snmp-proxy.yang:114.42: warning(432): no child node available > > > > Warning: no child nodes found in XPath expr '../type =3D trap or ..= /type =3D inform' > > ietf-snmp-proxy.yang:123.24: warning(432): no child node available > > > > Warning: no child nodes found in XPath expr '../type =3D trap or ..= /type =3D inform' > > ietf-snmp-proxy.yang:123.42: warning(432): no child node available > > > > These errors in ietf-snmp-proxy.yang are because the strings need t= o > > be quoted. When unquoted, they are XPath node names, not strings. > > > > e.g.: > > > > ../type =3D 'trap' or ../type =3D 'inform' > = > I agree. These should be quoted. Fixed. > > Warning: no child nodes found in XPath expr 'snmp:params/snmp:v1 or= > > snmp:params/snmp:v2c' > > ietf-snmp-community.yang:196.12: warning(432): no child node availa= ble > > > > Warning: no child nodes found in XPath expr 'snmp:params/snmp:v1 or= > > snmp:params/snmp:v2c' > > ietf-snmp-community.yang:196.35: warning(432): no child node availa= ble > > > > > > There is a missing '/' so XPath this is supposed to be a child node= > > > > e.g. > > /snmp:params/snmp:v1 > = > No. There is no toplevel params node in this module. These should pro= bably be > "../snmp:v1 or ../snmp:v2c". They appear to be refering to nodes of > > the params choice inside /snmp:snmp/snmp:target. Yes. I fixed this by moving the when stmt up one level: augment /snmp:snmp/snmp:target { when "snmp:params/snmp:v1 or snmp:params/snmp:v2c"; leaf mms { ... > > Warning: no child nodes found in XPath expr > > '/snmp/usm/remote[engine-id=3Dcurrent()]/user[name=3Dcurrent()/../u= sm/user-name]' > > ietf-snmp-usm.yang:194.13: warning(432): no child node available > > > > Warning: no child nodes found in XPath expr > > '/snmp/usm/remote[engine-id=3Dcurrent()]/user[name=3Dcurrent()/../u= sm/user-name]' > > ietf-snmp-usm.yang:194.29: warning(432): no child node available > > > > Warning: no child nodes found in XPath expr > > '/snmp/usm/remote[engine-id=3Dcurrent()]/user[name=3Dcurrent()/../u= sm/user-name]' > > ietf-snmp-usm.yang:194.55: warning(432): no child node available > > > > > > Not sure if the 3 errors above are yangdump problems or due to > > restrictions on what can be > > referenced within an augment-stmt. The XPath and combination of us= es > > and augments > > is complicated to follow, so not sure if it is correct yet. > = > I don't think these are errors. Neither do I. > > Warning: no child nodes found in XPath expr '../map-type =3D snmp:s= pecified' > > ietf-snmp-tls.yang:174.30: warning(432): no child node available > > > > Not sure what snmp:specified is -- XPath thinks it is a node name b= ecause this > > is an unquoted string. There is no child 'specified' under this le= af. > = > snmp:specified appears to be an identity in ietf-snmp-tls (base > > cert-to-tm-security-name). This should also be quoted, it's a > > QName value. Fixed. /martin From yiya@cisco.com Tue Jul 31 07:29:13 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 583C021F86B3 for ; Tue, 31 Jul 2012 07:29:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.074 X-Spam-Level: X-Spam-Status: No, score=-10.074 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599, J_CHICKENPOX_74=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KbNxxvY27ztD for ; Tue, 31 Jul 2012 07:29:12 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id BD8E721F86A4 for ; Tue, 31 Jul 2012 07:29:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=yiya@cisco.com; l=2366; q=dns/txt; s=iport; t=1343744952; x=1344954552; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=4U4n+6wh+mfwb7b5Y9ALpqSUsAPanAsgRmkDeOfK7ZE=; b=Hfo6NGOu6s20XyFWwq7s3hm18FRUy3qvxYfnKvO9Gv+BZ/C2M6L/vWsQ 3KKFyUNm2+QFL/zWUPmsx70x1kxVQoxxW2imirQZjN43uJAQJ3zSLzaWA R5XLEigzeLMiDW3krULn6FRC/+jhr6Cmw87ZHFcITSuEiUcAlR8rSWwK6 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAFnqF1CtJXHA/2dsb2JhbABFuXWBB4IhAQEEEgFYDhACAQhGMiUCBA4nh2sLm2WgdZFyYAOVR44ngWaCXw X-IronPort-AV: E=Sophos;i="4.77,686,1336348800"; d="scan'208";a="107002860" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-2.cisco.com with ESMTP; 31 Jul 2012 14:29:12 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id q6VETCfC017377 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 31 Jul 2012 14:29:12 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.33]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0298.004; Tue, 31 Jul 2012 09:29:11 -0500 From: "Yi Yang (yiya)" To: Ladislav Lhotka Thread-Topic: comments on draft-ietf-netmod-routing-cfg-04 Thread-Index: AQHNbCicgjImo6D/hUmbbdTBxQ8JeZdAgg4AgADnagCAANDigIAAUjsAgAAfeYCAAEcVAIAABKQAgADVmIA= Date: Tue, 31 Jul 2012 14:29:10 +0000 Message-ID: References: <45BE39D9-2E92-4139-B579-B125649CD287@cisco.com> <1157C259-DE00-4DD9-870D-2E58CD188ED8@cisco.com> <5E5D58D7-824A-433A-87F1-53E08B80F991@cisco.com> <8D98A55A-A05D-41B5-9C82-616F9CB0EE51@cisco.com> <63AD2EEF-E8EC-42F4-82E9-19D248DA9904@nic.cz> In-Reply-To: <63AD2EEF-E8EC-42F4-82E9-19D248DA9904@nic.cz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.75.7] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19074.005 x-tm-as-result: No--33.603000-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="Windows-1252" Content-ID: <488D1FECE88F06419744FFBDD0CE89FE@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "netmod@ietf.org" Subject: Re: [netmod] comments on draft-ietf-netmod-routing-cfg-04 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, 31 Jul 2012 14:29:13 -0000 Hi Ladislav, >>>> I am not an expert on Junos, but here is the output of "show route for= warding-table", from http://www.juniper.net/techpubs/en_US/junos12.1/topics= /reference/command-summary/show-route-forwarding-table-mpls-ex-series.html >>>>=20 >>>> user@switch> show route forwarding-table >>>> Routing table: default.inet >>>> Internet: >>>> Destination Type RtRef Next hop Type Index NhRef Neti= f >>>> default user 2 0:12:f2:21:cf:0 ucst 333 5 me0.= 0 >>>> default perm 0 rjct 36 2 >>>> 0.0.0.0/32 perm 0 dscd 34 1 >>>> 2.2.2.0/24 intf 0 rslv 1309 1 ae0.= 0 >>>> ....... >>>>=20 >>>> Compared to the output of "show route", from >>>> http://www.juniper.net/techpubs/en_US/junos12.1/topics/reference/comma= nd-summary/show-route.html >>>>=20 >>>> user@host> show route >>>> inet.0: 10 destinations, 10 routes (9 active, 0 holddown, 1 hidden) >>>> + =3D Active Route, - =3D Last Active, * =3D Both >>>> 0.0.0.0/0 *[Static/5] 1w5d 20:30:29 >>>> Discard >>>> 10.255.245.51/32 *[Direct/0] 2w4d 13:11:14 >>>>> via lo0.0 >>>> 172.16.0.0/12 *[Static/5] 2w4d 13:11:14 >>>>> to 192.168.167.254 via fxp0.0 >>>> 192.168.0.0/18 *[Static/5] 1w5d 20:30:29 >>>>> to 192.168.167.254 via fxp0.0 >>>>=20 >>>> As mentioned earlier, source/age are not shown in the forwarding table= , unless they are hidden intentionally? Maybe someone familiar with Junos c= an comment on this? >>>=20 >>> Would it help if "age" and "source-protocol" were not mandatory? >>=20 >> I am inclined to separate forwarding table from routing table. The forwa= rding table is so special that it has a different data structure, doesn't i= nteract with routing protocol directly, and doesn't support export filters= =85 >=20 > This is certainly an option - somebody can write such an extension as a s= eparate module. But, as I said, some implementations do not use a forwardin= g table. Or, forwarding table as an optional?=20 IMO, no matter if forwarding table is specified in a separate module, or sp= ecified as an optional node, the reference of forwarding table and FIB in t= he draft should be clarified as they are not routing tables. Yi From mbj@tail-f.com Tue Jul 31 08:56:47 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A62A21F8510 for ; Tue, 31 Jul 2012 08:56:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.746 X-Spam-Level: X-Spam-Status: No, score=-1.746 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HsloucEQ9xjz for ; Tue, 31 Jul 2012 08:56:46 -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 16AE921F8505 for ; Tue, 31 Jul 2012 08:56:45 -0700 (PDT) Received: from localhost (dhcp-4088.meeting.ietf.org [130.129.64.136]) by mail.tail-f.com (Postfix) with ESMTPSA id 78E6112008E8; Tue, 31 Jul 2012 17:56:43 +0200 (CEST) Date: Tue, 31 Jul 2012 08:56:41 -0700 (PDT) Message-Id: <20120731.085641.221361732.mbj@tail-f.com> To: chelliot@pobox.com From: Martin Bjorklund In-Reply-To: References: <20120730.144458.521399411.mbj@tail-f.com> X-Mailer: Mew version 6.3.51 on Emacs 23.3 / 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] comment on ietf-interfaces module 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, 31 Jul 2012 15:56:47 -0000 Hi, Chris Elliott wrote: > It seems to me that, if we want to represent stacking that's compatible > with the draft YANG interfaces module, then we should not use the ifIndex, > whatever it's called, to represent stacking, if it's to be useful. Ok. It should be noted that the stacking information *is* available with the current model; but not generically. A generic stack table has the advantage that a client can see the interface stack hierarchy without understanding type-specific data models. This *might* not be as important with YANG as it was in SMIv2, since the augemented data is provided "inline" - if you the /interfaces list you will get the generic stuff and the augmented type-specific stuff, which includes the layering information. > It seems > to me that the only things needed are to add is one new leaf, "slave-if", > to use the name from Appendix B of this YANG module. That seems much easier > to use than how it's done in SMI. Then, Appendix B could be modified to > show how "slave-if" could be constrained for Ethernet LAG interfaces > (ieee8023adLag), > for example. > > I also think that these objects must be configurable. Absolutely. This is one of the requirements listed in section 2. But note that a single leaf is not enough, since we need to support 1-over-N interfaces. So it would have to be a leaf-list. But in some cases you might need more than just a set of interfaces; you might need to specify additional information per interface. As a simple example you might need to assign a priority or a tag to each underlying interface. In order for the generic model to be prepared for this, we cannot use a simple leaf-list; we'd have to use a list (that can be augmented by type-specific modules). And note that if we do this generically, this list will be available for *all* interface types, including interfaces that cannot be layered on top of some other interfaces. Of course, if you try to configure such an invalid layering, you will get an error back. But this constraint is not captured in the data model. So this is why I prefer to have type-specific layering configuration. It makes the data model more "direct" and less confusing, and it allows you to tailor the layering config for each type. /martin From pgili@cisco.com Tue Jul 31 09:02:48 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2661421F8566 for ; Tue, 31 Jul 2012 09:02:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 xa1teH8qUSyd for ; Tue, 31 Jul 2012 09:02:47 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 0F64F21F8564 for ; Tue, 31 Jul 2012 09:02:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pgili@cisco.com; l=3256; q=dns/txt; s=iport; t=1343750567; x=1344960167; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=HHH5+FXICc/F5km0udqWvy+oZERd6DDe7bN84RpCkLs=; b=gTeSMobRdRy0ue+UWAMQPPX599Wq36co+nMjTyv/D6P6csfJaA9usvLS EWoHlOd1da8uQp422N/U19lhkELbU1uhdI1WE1u6hQI3F6srCOyTGrhnL nmL7lOlRp4nH+mVano9tExWaqsDra1sv0DIn6+rJe90E53H+xynXUPxjk Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAK0AGFCtJV2b/2dsb2JhbABFuXWBB4IgAQEBAwEBAQEPASc0CwUHBAIBCA4DBAEBCxQJBycLFAkIAgQBDQUIGodlBgubfKBtBItJhilgA6NugWaCXw X-IronPort-AV: E=Sophos;i="4.77,686,1336348800"; d="scan'208";a="107059979" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-6.cisco.com with ESMTP; 31 Jul 2012 16:02:46 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q6VG2kp1011155 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 31 Jul 2012 16:02:46 GMT Received: from xmb-aln-x14.cisco.com ([169.254.8.145]) by xhc-rcd-x04.cisco.com ([173.37.183.78]) with mapi id 14.02.0298.004; Tue, 31 Jul 2012 11:02:46 -0500 From: "Patrick Gili (pgili)" To: Martin Bjorklund , "chelliot@pobox.com" Thread-Topic: [netmod] comment on ietf-interfaces module Thread-Index: AQHNbzUTpLzaXn+U8UWilvWloQKDDJdDjC2A Date: Tue, 31 Jul 2012 16:02:45 +0000 Message-ID: <50E64ADF99EAEE4CACEC18958F0FC0AB029236@xmb-aln-x14.cisco.com> References: <20120730.144458.521399411.mbj@tail-f.com> <20120731.085641.221361732.mbj@tail-f.com> In-Reply-To: <20120731.085641.221361732.mbj@tail-f.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.254.154] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19074.005 x-tm-as-result: No--29.771000-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "netmod@ietf.org" Subject: Re: [netmod] comment on ietf-interfaces module 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, 31 Jul 2012 16:02:48 -0000 Martin, I don't agree with your statement below. It isn't always possible to determ= ine the interface layering strictly from the type of an interface. For exam= ple, a PPP interface can sit atop any variety of interfaces, including DSL,= cable, IP, L2TP, POS, DS3, etc, etc, etc. Interface stacking data is not o= nly important for configuring bonded/aggregated interfaces, but also diagno= sing any variety of problems. Patrick Gili -----Original Message----- From: netmod-bounces@ietf.org [mailto:netmod-bounces@ietf.org] On Behalf Of= Martin Bjorklund Sent: Tuesday, July 31, 2012 11:57 AM To: chelliot@pobox.com Cc: netmod@ietf.org Subject: Re: [netmod] comment on ietf-interfaces module Hi, Chris Elliott wrote: > It seems to me that, if we want to represent stacking that's=20 > compatible with the draft YANG interfaces module, then we should not=20 > use the ifIndex, whatever it's called, to represent stacking, if it's to = be useful. Ok. It should be noted that the stacking information *is* available with the cu= rrent model; but not generically. A generic stack table has the advantage = that a client can see the interface stack hierarchy without understanding t= ype-specific data models. This *might* not be as important with YANG as it= was in SMIv2, since the augemented data is provided "inline" - if you the /interfaces list you will get the generic stuff and the augmented typ= e-specific stuff, which includes the layering information. > It seems > to me that the only things needed are to add is one new leaf,=20 > "slave-if", to use the name from Appendix B of this YANG module. That=20 > seems much easier to use than how it's done in SMI. Then, Appendix B=20 > could be modified to show how "slave-if" could be constrained for=20 > Ethernet LAG interfaces (ieee8023adLag), for example. >=20 > I also think that these objects must be configurable. Absolutely. This is one of the requirements listed in section 2. But note that a single leaf is not enough, since we need to support 1-over-= N interfaces. So it would have to be a leaf-list. But in some cases you m= ight need more than just a set of interfaces; you might need to specify add= itional information per interface. As a simple example you might need to a= ssign a priority or a tag to each underlying interface. In order for the g= eneric model to be prepared for this, we cannot use a simple leaf-list; we'= d have to use a list (that can be augmented by type-specific modules). And= note that if we do this generically, this list will be available for *all*= interface types, including interfaces that cannot be layered on top of som= e other interfaces. Of course, if you try to configure such an invalid lay= ering, you will get an error back. But this constraint is not captured in = the data model. So this is why I prefer to have type-specific layering configuration. It makes the data model more "direct" and less confusing, and it allows you= to tailor the layering config for each type. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From mbj@tail-f.com Tue Jul 31 09:03:35 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02CE421F869A for ; Tue, 31 Jul 2012 09:03:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.779 X-Spam-Level: X-Spam-Status: No, score=-1.779 tagged_above=-999 required=5 tests=[AWL=0.267, 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 s13-YKfumP15 for ; Tue, 31 Jul 2012 09:03:34 -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 0343121F863F for ; Tue, 31 Jul 2012 09:03:34 -0700 (PDT) Received: from localhost (dhcp-4088.meeting.ietf.org [130.129.64.136]) by mail.tail-f.com (Postfix) with ESMTPSA id 5414512008E8; Tue, 31 Jul 2012 18:03:32 +0200 (CEST) Date: Tue, 31 Jul 2012 09:02:57 -0700 (PDT) Message-Id: <20120731.090257.513496394.mbj@tail-f.com> To: pgili@cisco.com From: Martin Bjorklund In-Reply-To: <50E64ADF99EAEE4CACEC18958F0FC0AB028FEB@xmb-aln-x14.cisco.com> References: <50E64ADF99EAEE4CACEC18958F0FC0AB028FEB@xmb-aln-x14.cisco.com> X-Mailer: Mew version 6.3.51 on Emacs 23.3 / 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] comment on ietf-interfaces module 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, 31 Jul 2012 16:03:35 -0000 Hi, "Patrick Gili (pgili)" wrote: > Also, it is convenient to traverse interface stacks bottom-up, rather than > top-down. This is the reason why RFC 2864 came about. Does this mean that you suggest we add something like: list interface { ... leaf-list superior-if { type interface-ref; config false; } } or would you like to see both: leaf-list subordinate-if { ... } leaf-list superior-if { ... } /martin From pgili@cisco.com Tue Jul 31 09:08:16 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 340A421F8670 for ; Tue, 31 Jul 2012 09:08:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.449 X-Spam-Level: X-Spam-Status: No, score=-10.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 UDgOYePISYc7 for ; Tue, 31 Jul 2012 09:08:15 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 7926121F866B for ; Tue, 31 Jul 2012 09:08:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pgili@cisco.com; l=1493; q=dns/txt; s=iport; t=1343750895; x=1344960495; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=kB5JUPAz4RD7Ys/kJ/86e5vkZx0y6Dvmh7NJCC9TzmQ=; b=VL0Y+KTyQfKuW3BWNhZDGRkdZhm9R2z1npPVpG3DOoOXX4Kr/j+YX7QY ybbjPSsWYunHFyoUtFM5dV/m08U9OlJ9JCo4Uap17tlFuT86l3Mho40t4 74/vLlE403I+LH3qsqQq1rsXcwD7OX/o/yyliYIZ0724h6zYRETsePHj3 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EANcBGFCtJV2a/2dsb2JhbAA7Crl1gQeCIAEBAQQSASc/DAQCAQgOAwQBAQEKFAkHMhQJCAIEDgUIGodrnAegcYtJEBSGBWADo26BZoJf X-IronPort-AV: E=Sophos;i="4.77,686,1336348800"; d="scan'208";a="107062347" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-6.cisco.com with ESMTP; 31 Jul 2012 16:08:15 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q6VG8E7O002813 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 31 Jul 2012 16:08:15 GMT Received: from xmb-aln-x14.cisco.com ([169.254.8.145]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.02.0298.004; Tue, 31 Jul 2012 11:08:14 -0500 From: "Patrick Gili (pgili)" To: Martin Bjorklund Thread-Topic: [netmod] comment on ietf-interfaces module Thread-Index: AQHNbpZApLzaXn+U8UWilvWloQKDDJdCpy8AgAACpICAAAXyAIAAAmSAgAAhk4CAAF1OIIAAsYGA//+snKA= Date: Tue, 31 Jul 2012 16:08:14 +0000 Message-ID: <50E64ADF99EAEE4CACEC18958F0FC0AB029266@xmb-aln-x14.cisco.com> References: <50E64ADF99EAEE4CACEC18958F0FC0AB028FEB@xmb-aln-x14.cisco.com> <20120731.090257.513496394.mbj@tail-f.com> In-Reply-To: <20120731.090257.513496394.mbj@tail-f.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.254.154] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19074.005 x-tm-as-result: No--32.609800-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "netmod@ietf.org" Subject: Re: [netmod] comment on ietf-interfaces module 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, 31 Jul 2012 16:08:16 -0000 Hi Martin, The later would be prove very useful. The reason why both are useful is also for diagnosing faults or performing = impact analysis. For example, if I have a broadband customer contact custom= er service with a problem, the technician dealing with the trouble ticket c= an identify the interface over which the customer's traffic is flowing and = drill down through the interface stack, looking at status and statistics to= determine whether there is a possible fault. Another example, if I know I'= m going to take a particular physical interface offline, then I can perform= a depth-first traversal of all interfaces dependent on the physical interf= ace and send out the proper notifications. Cheers, Patrick -----Original Message----- From: Martin Bjorklund [mailto:mbj@tail-f.com]=20 Sent: Tuesday, July 31, 2012 12:03 PM To: Patrick Gili (pgili) Cc: chelliot@pobox.com; netmod@ietf.org Subject: Re: [netmod] comment on ietf-interfaces module Hi, "Patrick Gili (pgili)" wrote: > Also, it is convenient to traverse interface stacks bottom-up, rather=20 > than top-down. This is the reason why RFC 2864 came about. Does this mean that you suggest we add something like: list interface { ... leaf-list superior-if { type interface-ref; config false; } } =20 or would you like to see both: leaf-list subordinate-if { ... } leaf-list superior-if { ... } /martin From mbj@tail-f.com Tue Jul 31 09:10:48 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A564821F867F for ; Tue, 31 Jul 2012 09:10:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.806 X-Spam-Level: X-Spam-Status: No, score=-1.806 tagged_above=-999 required=5 tests=[AWL=0.240, 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 w8K+KpSAyEqv for ; Tue, 31 Jul 2012 09:10: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 1FB1F21F853E for ; Tue, 31 Jul 2012 09:10:48 -0700 (PDT) Received: from localhost (dhcp-4088.meeting.ietf.org [130.129.64.136]) by mail.tail-f.com (Postfix) with ESMTPSA id 7D80912008E8; Tue, 31 Jul 2012 18:10:46 +0200 (CEST) Date: Tue, 31 Jul 2012 09:09:26 -0700 (PDT) Message-Id: <20120731.090926.487270644.mbj@tail-f.com> To: pgili@cisco.com From: Martin Bjorklund In-Reply-To: <50E64ADF99EAEE4CACEC18958F0FC0AB029236@xmb-aln-x14.cisco.com> References: <20120731.085641.221361732.mbj@tail-f.com> <50E64ADF99EAEE4CACEC18958F0FC0AB029236@xmb-aln-x14.cisco.com> X-Mailer: Mew version 6.3.51 on Emacs 23.3 / 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] comment on ietf-interfaces module 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, 31 Jul 2012 16:10:48 -0000 "Patrick Gili (pgili)" wrote: > Martin, > > I don't agree with your statement below. It isn't always possible to determine > the interface layering strictly from the type of an interface. For example, a > PPP interface can sit atop any variety of interfaces, including DSL, cable, > IP, L2TP, POS, DS3, etc, etc, etc. I must have expresses myself badly. I did not mean this. I meant that for a specific interface type, you can add objects (through augmentation) that specifies how this particular interface type can be layered on top of other interfaces. Sometimes you can only layer an interface of type A over type B, and sometimes you do not have such restrictions. Regardless of which, by expressing this specifically in the data model for the interafce type, we can capture these constraints in the data model. This is not possible with a generic config model for layering. /martin From pgili@cisco.com Tue Jul 31 09:17:07 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E93521F86B0 for ; Tue, 31 Jul 2012 09:17:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 9GFG8Sp2nPai for ; Tue, 31 Jul 2012 09:17:06 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 89F3821F8629 for ; Tue, 31 Jul 2012 09:17:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pgili@cisco.com; l=1827; q=dns/txt; s=iport; t=1343751426; x=1344961026; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=026k49x+l/Mtk3LcWxbgAYu/5uujUgJfiG9pUsIngVA=; b=BUdbaDCgnvO0FtOnpFyjONdhF6ZXJgB1QAaCkwnCCcqK6Nc17BG6i0Ba WAPZ0gRHkyoCWchkNah6eMq6CqF1SFmf17Yj24knEgf6EUp2M2dyqob0E YbJpPIFXYXpDmPVhPW6dz44mcHTcIU/0EwXCI/4BOd+b2mrPvgAAPizt0 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAHcDGFCtJXHB/2dsb2JhbABFuXWBB4IgAQEBBBIBJz8MBAIBCA4DBAEBAQoUCQcyFAkIAgQOBQgah2ucDaBxi0mGKWADo26BZoJf X-IronPort-AV: E=Sophos;i="4.77,686,1336348800"; d="scan'208";a="107097499" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-4.cisco.com with ESMTP; 31 Jul 2012 16:17:06 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id q6VGH6j7023345 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 31 Jul 2012 16:17:06 GMT Received: from xmb-aln-x14.cisco.com ([169.254.8.145]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.02.0298.004; Tue, 31 Jul 2012 11:17:05 -0500 From: "Patrick Gili (pgili)" To: Martin Bjorklund Thread-Topic: [netmod] comment on ietf-interfaces module Thread-Index: AQHNbzUTpLzaXn+U8UWilvWloQKDDJdDjC2AgABW8AD//6zNMA== Date: Tue, 31 Jul 2012 16:17:05 +0000 Message-ID: <50E64ADF99EAEE4CACEC18958F0FC0AB02929A@xmb-aln-x14.cisco.com> References: <20120731.085641.221361732.mbj@tail-f.com> <50E64ADF99EAEE4CACEC18958F0FC0AB029236@xmb-aln-x14.cisco.com> <20120731.090926.487270644.mbj@tail-f.com> In-Reply-To: <20120731.090926.487270644.mbj@tail-f.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.254.154] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19074.005 x-tm-as-result: No--27.478900-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "netmod@ietf.org" Subject: Re: [netmod] comment on ietf-interfaces module 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, 31 Jul 2012 16:17:07 -0000 Hi Martin, The point you make below is true. SMIv2 was too generic in this regard and = we should guard against simple translations of what was done for SNMP. On the other hand, should we depend on developers defining YANG modules for= each specific technology to do the right thing by augmenting the interface= model to support this capability? If so, then I'm alright with this, as lo= ng as the RFC defining the ietf-interfaces model calls out best practices r= egarding interface layering. I still think a generic, read-only capability is useful for diagnostics and= impact analysis though. Patrick -----Original Message----- From: Martin Bjorklund [mailto:mbj@tail-f.com]=20 Sent: Tuesday, July 31, 2012 12:09 PM To: Patrick Gili (pgili) Cc: chelliot@pobox.com; netmod@ietf.org Subject: Re: [netmod] comment on ietf-interfaces module "Patrick Gili (pgili)" wrote: > Martin, >=20 > I don't agree with your statement below. It isn't always possible to=20 > determine the interface layering strictly from the type of an=20 > interface. For example, a PPP interface can sit atop any variety of=20 > interfaces, including DSL, cable, IP, L2TP, POS, DS3, etc, etc, etc. I must have expresses myself badly. I did not mean this. I meant that for= a specific interface type, you can add objects (through augmentation) that specifies how this particular interface type can be laye= red on top of other interfaces. Sometimes you can only layer an interface = of type A over type B, and sometimes you do not have such restrictions. Re= gardless of which, by expressing this specifically in the data model for th= e interafce type, we can capture these constraints in the data model. This= is not possible with a generic config model for layering. /martin From mbj@tail-f.com Tue Jul 31 09:24:00 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2851821F86FA for ; Tue, 31 Jul 2012 09:24:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.828 X-Spam-Level: X-Spam-Status: No, score=-1.828 tagged_above=-999 required=5 tests=[AWL=0.218, 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 5XLKYkgm8MUd for ; Tue, 31 Jul 2012 09:23:59 -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 939DB21F86EB for ; Tue, 31 Jul 2012 09:23:59 -0700 (PDT) Received: from localhost (dhcp-4088.meeting.ietf.org [130.129.64.136]) by mail.tail-f.com (Postfix) with ESMTPSA id F2ED71200048; Tue, 31 Jul 2012 18:23:57 +0200 (CEST) Date: Tue, 31 Jul 2012 09:23:33 -0700 (PDT) Message-Id: <20120731.092333.137778500.mbj@tail-f.com> To: pgili@cisco.com From: Martin Bjorklund In-Reply-To: <50E64ADF99EAEE4CACEC18958F0FC0AB02929A@xmb-aln-x14.cisco.com> References: <50E64ADF99EAEE4CACEC18958F0FC0AB029236@xmb-aln-x14.cisco.com> <20120731.090926.487270644.mbj@tail-f.com> <50E64ADF99EAEE4CACEC18958F0FC0AB02929A@xmb-aln-x14.cisco.com> X-Mailer: Mew version 6.3.51 on Emacs 23.3 / 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] comment on ietf-interfaces module 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, 31 Jul 2012 16:24:00 -0000 "Patrick Gili (pgili)" wrote: > Hi Martin, > > The point you make below is true. SMIv2 was too generic in this regard and we > should guard against simple translations of what was done for SNMP. > > On the other hand, should we depend on developers defining YANG modules for > each specific technology to do the right thing by augmenting the interface > model to support this capability? If so, then I'm alright with this Yes, this is a potential drawback. But the question is, if we add this layering thing as a generic config object, will that remove the need for type-specific augmentations? Not in general of course, but for some (large enough) percentage of all interface types? > , as long > as the RFC defining the ietf-interfaces model calls out best practices > regarding interface layering. What do you have in mind for this? > I still think a generic, read-only capability is useful for diagnostics and > impact analysis though. Ok. At this point it would be good to hear what others think about this idea. I think at least 4 persons agree with you, and so far noone has objected. /martin From andy@yumaworks.com Tue Jul 31 09:46:13 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 728E921F86B6 for ; Tue, 31 Jul 2012 09:46:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 Oz6pT4qkWbH0 for ; Tue, 31 Jul 2012 09:46:13 -0700 (PDT) Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id EA6E021F867E for ; Tue, 31 Jul 2012 09:46:12 -0700 (PDT) Received: by qadz3 with SMTP id z3so1869575qad.10 for ; Tue, 31 Jul 2012 09:46:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=UTf8jIbLPVHk/42SQ2WM+SNl/RLc/QO9grwAQoHoysQ=; b=eXn9IhFNJqeYW199YdqcrxGHdQiv36L+pAOpFXkIYnydikGaeRaYme6Gq3sSpZDriS DzvMrIl/Rziktrh9OAbHN6kQbr4f8nQdMJYAqMmWPqdm2Hed8yZhg2ced5YSAMpbEYgO P0bFvIWbW52FwhLdAwaznnbo53d9wECseSzzSo7/8juFDNCrWTAhxsefnSwuSaiqATRy cCgsITbOB8Fjt02cA1AvwHQLJBU5dqN2oK3Nb8aQParPXY1cfjfoisIv4SUIZHEme7Ai wsexR+/98neqS7ftla5E/O1sIIeKQecEKrywZV7cVQ3cBG6aIz1fEwGbU4lJ4sWDxJ6u 99sA== MIME-Version: 1.0 Received: by 10.224.42.76 with SMTP id r12mr19626190qae.96.1343753172440; Tue, 31 Jul 2012 09:46:12 -0700 (PDT) Received: by 10.49.26.168 with HTTP; Tue, 31 Jul 2012 09:46:12 -0700 (PDT) X-Originating-IP: [2001:df8:0:48:f1ec:fdf0:a427:dd2c] In-Reply-To: <20120731.090257.513496394.mbj@tail-f.com> References: <50E64ADF99EAEE4CACEC18958F0FC0AB028FEB@xmb-aln-x14.cisco.com> <20120731.090257.513496394.mbj@tail-f.com> Date: Tue, 31 Jul 2012 09:46:12 -0700 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQmAiuR5u9fxtZABySFnGPZAmOmZ86+mX8yBZTEgG5uObT2kNb7uF83QAYuJ+voHpg7uwEJL Cc: netmod@ietf.org Subject: Re: [netmod] comment on ietf-interfaces module 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, 31 Jul 2012 16:46:13 -0000 On Tue, Jul 31, 2012 at 9:02 AM, Martin Bjorklund wrote: > Hi, > > "Patrick Gili (pgili)" wrote: >> Also, it is convenient to traverse interface stacks bottom-up, rather than >> top-down. This is the reason why RFC 2864 came about. > > Does this mean that you suggest we add something like: > > list interface { > ... > leaf-list superior-if { > type interface-ref; > config false; > } > } > > or would you like to see both: > > leaf-list subordinate-if { ... } > leaf-list superior-if { ... } > Yes -- I think both leaf-lists should be added to the module. > > /martin Andy