From ietfc@btconnect.com Tue Oct 2 02:41: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 E3E1021F8B03 for ; Tue, 2 Oct 2012 02:41:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.495 X-Spam-Level: X-Spam-Status: No, score=-3.495 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G+mcysKyiTL1 for ; Tue, 2 Oct 2012 02:41:47 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe002.messaging.microsoft.com [216.32.181.182]) by ietfa.amsl.com (Postfix) with ESMTP id 3169721F8A92 for ; Tue, 2 Oct 2012 02:41:46 -0700 (PDT) Received: from mail95-ch1-R.bigfish.com (10.43.68.249) by CH1EHSOBE020.bigfish.com (10.43.70.77) with Microsoft SMTP Server id 14.1.225.23; Tue, 2 Oct 2012 09:41:45 +0000 Received: from mail95-ch1 (localhost [127.0.0.1]) by mail95-ch1-R.bigfish.com (Postfix) with ESMTP id C26674800D6; Tue, 2 Oct 2012 09:41:45 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.253.85; KIP:(null); UIP:(null); IPV:NLI; H:DB3PRD0710HT004.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -23 X-BigFish: PS-23(zz9371I542M1432Izz1202h1d1ah1d2ahzz8275ch1033IL17326ah8275bh8275dh84d07hz2dh2a8h5a9h668h839hd24hf0ah107ah1177h1179h1288h12a5h12a9h12bdh137ah139eh13b6h304l1155h) Received: from mail95-ch1 (localhost.localdomain [127.0.0.1]) by mail95-ch1 (MessageSwitch) id 1349170903354945_13803; Tue, 2 Oct 2012 09:41:43 +0000 (UTC) Received: from CH1EHSMHS013.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.254]) by mail95-ch1.bigfish.com (Postfix) with ESMTP id 5466B4E009A; Tue, 2 Oct 2012 09:41:43 +0000 (UTC) Received: from DB3PRD0710HT004.eurprd07.prod.outlook.com (157.56.253.85) by CH1EHSMHS013.bigfish.com (10.43.70.13) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 2 Oct 2012 09:41:42 +0000 Received: from BY2PRD0510HT005.namprd05.prod.outlook.com (157.56.236.101) by pod51017.outlook.com (10.255.75.39) with Microsoft SMTP Server (TLS) id 14.16.190.9; Tue, 2 Oct 2012 09:41:36 +0000 Message-ID: <025601cda082$23047620$4001a8c0@gateway.2wire.net> From: t.petch To: Benoit Claise , Ladislav Lhotka , Jernej Tuljak , Ladislav Lhotka , , , References: <20120921154850.6A92C72E038@rfc-editor.org><20120924083532.GB7097@elstar.local><0B670666-932D-4549-B444-93B8021F7F1F@lhotka.name><506022CA.9030200@cisco.com> <5062B8E4.6090303@mg-soft.com><86E04D86-9E91-4EC5-9106-8D37C3B41D4E@nic.cz><20120926093725.GA58512@elstar.local> <50642856.6030703@cisco.com> Date: Tue, 2 Oct 2012 10:02:36 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.236.101] X-FOPE-CRA-Verdict: 157.56.253.85$juniper.net%12218%4%btconnect.com%False%True%0$ X-OriginatorOrg: btconnect.com Subject: Re: [netmod] [Technical Errata Reported] RFC6110 (3362) X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 02 Oct 2012 09:41:48 -0000 ----- Original Message ----- From: "Benoit Claise" To: "Ladislav Lhotka" ; "Jernej Tuljak" ; "Ladislav Lhotka" ; ; ; Sent: Thursday, September 27, 2012 11:20 AM > Dear all, > >> I don't have any experience with the errata procedure but I think the first decision should be whether this qualifies as an erratum, because indeed it changes the DSDL mapping "protocol", as Martin pointed out. > >> > >> Who is entitled to make this decision? > >> > > I have moved this question over to Benoit since I think we need advice > > from the ADs here. > > Reviewing http://www.ietf.org/iesg/statement/errata-processing.html as > background information... > - As far as I can tell, we agree that this is a bug in the > specification. So an errata should be filed. > - As far as I can tell, we fall into: "Only errors that could cause > implementation or deployment problems or significant confusion should be > Approved." > - As far as I can tell, we don't fall into: "Changes that modify the > working of a protocol to something that might be different from the > intended consensus when the document was approved should be either Hold > for Document Update or Rejected" > > I'm in favor to keep the process simple, and to verify the errata, > instead of producing a new RFC. It is a substantive change to the protocol and would seem to me to be a change to the consensus when the document was approved, albeit a necessary change in the light of further understanding; but if an AD says not, I won't argue. My greater concern is that I do not believe that consumers of RFC know to look for Errata and so would miss it, producing something incompatible. I know that I have been caught out, in other contexts, by failing to look for Errata even though I have been around long enough to know the procedure well; ie, I would go for a revised RFC, greater cost to us, but more reliable for everyone else. Tom Petch > However, before doing so, we want to be a safe side, basically making > sure that there are no other implementations for which this bug fix > (read non-backward compatibility change) would cause a problem. > > So let me propose the following: > - We keep the errata 3362 open for now > - Since errata 3362 needs to updated (and since we can't update this > errata without approving/rejecting AFAIK), we create a new errata with > all the changes, as agreed on the mailing list. Do we have an agreement > on what Lada proposed? > - I send a kind of LC email to the mailing list, with this new errata > - If no issue during this LC, I reject errata 3362 (pointing to the new > errata), and I verify the new one. > > Regards, Benoit. > > /js > > From ladislav@lhotka.name Tue Oct 2 04:21: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 0F9D721F8B11 for ; Tue, 2 Oct 2012 04:21:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.205 X-Spam-Level: X-Spam-Status: No, score=-2.205 tagged_above=-999 required=5 tests=[AWL=-0.206, BAYES_00=-2.599, J_CHICKENPOX_15=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MCabtoWUWm5C for ; Tue, 2 Oct 2012 04:21:03 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 26CBD21F8A05 for ; Tue, 2 Oct 2012 04:21:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id A678A5406FE; Tue, 2 Oct 2012 13:20:48 +0200 (CEST) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9IxeY6xuAjNw; Tue, 2 Oct 2012 13:20:42 +0200 (CEST) Received: from [172.29.2.201] (unknown [10.107.191.189]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 158C0540239; Tue, 2 Oct 2012 13:20:42 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) Content-Type: text/plain; charset=iso-8859-1 From: Ladislav Lhotka X-Priority: 3 In-Reply-To: <025601cda082$23047620$4001a8c0@gateway.2wire.net> Date: Tue, 2 Oct 2012 13:20:21 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120921154850.6A92C72E038@rfc-editor.org><20120924083532.GB7097@elstar.local><0B670666-932D-4549-B444-93B8021F7F1F@lhotka.name><506022CA.9030200@cisco.com> <5062B8E4.6090303@mg-soft.com><86E04D86-9E91-4EC5-9106-8D37C3B41D4E@nic.cz><20120926093725.GA58512@elstar.local> <50642856.6030703@cisco.com> <025601cda082$23047620$4001a8c0@gateway.2wire.net> To: t.petch X-Mailer: Apple Mail (2.1498) Cc: netmod@ietf.org, rbonica@juniper.net, lhotka@cesnet.cz Subject: Re: [netmod] [Technical Errata Reported] RFC6110 (3362) X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 02 Oct 2012 11:21:04 -0000 On Oct 2, 2012, at 11:02 AM, t.petch wrote: > ----- Original Message ----- > From: "Benoit Claise" > To: "Ladislav Lhotka" ; "Jernej Tuljak" > ; "Ladislav Lhotka" ; > ; ; > Sent: Thursday, September 27, 2012 11:20 AM >> Dear all, >>>> I don't have any experience with the errata procedure but I think > the first decision should be whether this qualifies as an erratum, > because indeed it changes the DSDL mapping "protocol", as Martin = pointed > out. >>>>=20 >>>> Who is entitled to make this decision? >>>>=20 >>> I have moved this question over to Benoit since I think we need > advice >>> from the ADs here. >>=20 >> Reviewing http://www.ietf.org/iesg/statement/errata-processing.html = as >> background information... >> - As far as I can tell, we agree that this is a bug in the >> specification. So an errata should be filed. >> - As far as I can tell, we fall into: "Only errors that could cause >> implementation or deployment problems or significant confusion should > be >> Approved." >> - As far as I can tell, we don't fall into: "Changes that modify the >> working of a protocol to something that might be different from the >> intended consensus when the document was approved should be either > Hold >> for Document Update or Rejected" >>=20 >> I'm in favor to keep the process simple, and to verify the errata, >> instead of producing a new RFC. >=20 > It is a substantive change to the protocol and would seem to me to be = a > change to the consensus when the document was approved, albeit a > necessary change in the light of further understanding; but if an AD > says not, I won't argue. >=20 > My greater concern is that I do not believe that consumers of RFC = know > to look for Errata and so would miss it, producing something > incompatible. I know that I have been caught out, in other contexts, = by > failing to look for Errata even though I have been around long enough = to > know the procedure well; ie, I would go for a revised RFC, greater = cost > to us, but more reliable for everyone else. Yes, that's a relevant concern. It would actually be helpful in general = if the parts of RFCs that are affected by errata were clearly marked in = the RFC text, at least in the HTML rendering. Lada >=20 > Tom Petch >=20 >> However, before doing so, we want to be a safe side, basically making >> sure that there are no other implementations for which this bug fix >> (read non-backward compatibility change) would cause a problem. >>=20 >> So let me propose the following: >> - We keep the errata 3362 open for now >> - Since errata 3362 needs to updated (and since we can't update this >> errata without approving/rejecting AFAIK), we create a new errata = with >> all the changes, as agreed on the mailing list. Do we have an > agreement >> on what Lada proposed? >> - I send a kind of LC email to the mailing list, with this new errata >> - If no issue during this LC, I reject errata 3362 (pointing to the > new >> errata), and I verify the new one. >>=20 >> Regards, Benoit. >>> /js >>>=20 >=20 >=20 -- Ladislav Lhotka PGP Key ID: E74E8C0C From ietfc@btconnect.com Tue Oct 2 06:51: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 B50A621F866E for ; Tue, 2 Oct 2012 06:51:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.785 X-Spam-Level: X-Spam-Status: No, score=-4.785 tagged_above=-999 required=5 tests=[AWL=1.214, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pKeDur62fvXz for ; Tue, 2 Oct 2012 06:51:43 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe004.messaging.microsoft.com [65.55.88.14]) by ietfa.amsl.com (Postfix) with ESMTP id 8601921F8568 for ; Tue, 2 Oct 2012 06:51:42 -0700 (PDT) Received: from mail64-tx2-R.bigfish.com (10.9.14.237) by TX2EHSOBE012.bigfish.com (10.9.40.32) with Microsoft SMTP Server id 14.1.225.23; Tue, 2 Oct 2012 13:51:41 +0000 Received: from mail64-tx2 (localhost [127.0.0.1]) by mail64-tx2-R.bigfish.com (Postfix) with ESMTP id 605B280113; Tue, 2 Oct 2012 13:51:41 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.253.197; KIP:(null); UIP:(null); IPV:NLI; H:DBXPRD0710HT005.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -24 X-BigFish: PS-24(zz98dI9371I542M1432Izz1202h1d1ah1d2ahzz8275ch1033IL17326ah8275bh8275dh84d07hz2dh2a8h5a9h668h839hd24hf0ah107ah1177h1179h1288h12a5h12a9h12bdh137ah139eh13b6h304l1155h) Received: from mail64-tx2 (localhost.localdomain [127.0.0.1]) by mail64-tx2 (MessageSwitch) id 1349185899867214_30154; Tue, 2 Oct 2012 13:51:39 +0000 (UTC) Received: from TX2EHSMHS021.bigfish.com (unknown [10.9.14.253]) by mail64-tx2.bigfish.com (Postfix) with ESMTP id CAE70F00049; Tue, 2 Oct 2012 13:51:39 +0000 (UTC) Received: from DBXPRD0710HT005.eurprd07.prod.outlook.com (157.56.253.197) by TX2EHSMHS021.bigfish.com (10.9.99.121) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 2 Oct 2012 13:51:38 +0000 Received: from DB3PRD0410HT002.eurprd04.prod.outlook.com (157.56.252.21) by pod51017.outlook.com (10.255.79.168) with Microsoft SMTP Server (TLS) id 14.16.207.9; Tue, 2 Oct 2012 13:51:31 +0000 Message-ID: <006601cda0a5$0cba5b00$4001a8c0@gateway.2wire.net> From: t.petch To: Ladislav Lhotka References: <20120921154850.6A92C72E038@rfc-editor.org><20120924083532.GB7097@elstar.local><0B670666-932D-4549-B444-93B8021F7F1F@lhotka.name><506022CA.9030200@cisco.com> <5062B8E4.6090303@mg-soft.com><86E04D86-9E91-4EC5-9106-8D37C3B41D4E@nic.cz><20120926093725.GA58512@elstar.local> <50642856.6030703@cisco.com> <025601cda082$23047620$4001a8c0@gateway.2wire.net> Date: Tue, 2 Oct 2012 14:51:33 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.252.21] X-FOPE-CRA-Verdict: 157.56.253.197$juniper.net%12218%4%btconnect.com%False%True%0$ X-OriginatorOrg: btconnect.com Cc: rbonica@juniper.net, netmod@ietf.org Subject: Re: [netmod] [Technical Errata Reported] RFC6110 (3362) X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 02 Oct 2012 13:51:45 -0000 ----- Original Message ----- From: "Ladislav Lhotka" To: "t.petch" Cc: "Benoit Claise" ; "Ladislav Lhotka" ; "Jernej Tuljak" ; ; ; Sent: Tuesday, October 02, 2012 12:20 PM On Oct 2, 2012, at 11:02 AM, t.petch wrote: > ----- Original Message ----- > From: "Benoit Claise" > To: "Ladislav Lhotka" ; "Jernej Tuljak" > ; "Ladislav Lhotka" ; > ; ; > Sent: Thursday, September 27, 2012 11:20 AM >> Dear all, >>>> I don't have any experience with the errata procedure but I think > the first decision should be whether this qualifies as an erratum, > because indeed it changes the DSDL mapping "protocol", as Martin pointed > out. >>>> >>>> Who is entitled to make this decision? >>>> >>> I have moved this question over to Benoit since I think we need > advice >>> from the ADs here. >> >> Reviewing http://www.ietf.org/iesg/statement/errata-processing.html as >> background information... >> - As far as I can tell, we agree that this is a bug in the >> specification. So an errata should be filed. >> - As far as I can tell, we fall into: "Only errors that could cause >> implementation or deployment problems or significant confusion should > be >> Approved." >> - As far as I can tell, we don't fall into: "Changes that modify the >> working of a protocol to something that might be different from the >> intended consensus when the document was approved should be either > Hold >> for Document Update or Rejected" >> >> I'm in favor to keep the process simple, and to verify the errata, >> instead of producing a new RFC. > > It is a substantive change to the protocol and would seem to me to be a > change to the consensus when the document was approved, albeit a > necessary change in the light of further understanding; but if an AD > says not, I won't argue. > > My greater concern is that I do not believe that consumers of RFC know > to look for Errata and so would miss it, producing something > incompatible. I know that I have been caught out, in other contexts, by > failing to look for Errata even though I have been around long enough to > know the procedure well; ie, I would go for a revised RFC, greater cost > to us, but more reliable for everyone else. Yes, that's a relevant concern. It would actually be helpful in general if the parts of RFCs that are affected by errata were clearly marked in the RFC text, at least in the HTML rendering. Yes, I suggested that on the main IETF list two months ago, but did not get any traction. The HTML does say that they are errata but my doubt is how many people outside academia and IETF standards development know what the word means - I suggested using 'corrections' instead. Tom Petch Lada > > Tom Petch > >> However, before doing so, we want to be a safe side, basically making >> sure that there are no other implementations for which this bug fix >> (read non-backward compatibility change) would cause a problem. >> >> So let me propose the following: >> - We keep the errata 3362 open for now >> - Since errata 3362 needs to updated (and since we can't update this >> errata without approving/rejecting AFAIK), we create a new errata with >> all the changes, as agreed on the mailing list. Do we have an > agreement >> on what Lada proposed? >> - I send a kind of LC email to the mailing list, with this new errata >> - If no issue during this LC, I reject errata 3362 (pointing to the > new >> errata), and I verify the new one. >> >> Regards, Benoit. >>> /js >>> > > -- Ladislav Lhotka PGP Key ID: E74E8C0C From j.schoenwaelder@jacobs-university.de Tue Oct 2 07:31: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 C666A21F847D for ; Tue, 2 Oct 2012 07:31:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.923 X-Spam-Level: X-Spam-Status: No, score=-102.923 tagged_above=-999 required=5 tests=[AWL=-0.274, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VoxgnCur2aMA for ; Tue, 2 Oct 2012 07:31:29 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id A5EF021F84D8 for ; Tue, 2 Oct 2012 07:31:29 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9D63420C21; Tue, 2 Oct 2012 16:31:28 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id SX9otVzI5e9e; Tue, 2 Oct 2012 16:31:28 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id E032720BEE; Tue, 2 Oct 2012 16:31:26 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 85E342214550; Tue, 2 Oct 2012 16:31:21 +0200 (CEST) Date: Tue, 2 Oct 2012 16:31:18 +0200 From: Juergen Schoenwaelder To: "t.petch" Message-ID: <20121002143116.GA83875@elstar.local> Mail-Followup-To: "t.petch" , Ladislav Lhotka , rbonica@juniper.net, netmod@ietf.org References: <20120924083532.GB7097@elstar.local> <0B670666-932D-4549-B444-93B8021F7F1F@lhotka.name> <506022CA.9030200@cisco.com> <5062B8E4.6090303@mg-soft.com> <86E04D86-9E91-4EC5-9106-8D37C3B41D4E@nic.cz> <20120926093725.GA58512@elstar.local> <50642856.6030703@cisco.com> <025601cda082$23047620$4001a8c0@gateway.2wire.net> <006601cda0a5$0cba5b00$4001a8c0@gateway.2wire.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <006601cda0a5$0cba5b00$4001a8c0@gateway.2wire.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Ladislav Lhotka , rbonica@juniper.net, netmod@ietf.org Subject: Re: [netmod] [Technical Errata Reported] RFC6110 (3362) 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, 02 Oct 2012 14:31:30 -0000 On Tue, Oct 02, 2012 at 02:51:33PM +0100, t.petch wrote: > > My greater concern is that I do not believe that consumers of RFC > know > > to look for Errata and so would miss it, producing something > > incompatible. I know that I have been caught out, in other contexts, > by > > failing to look for Errata even though I have been around long enough > to > > know the procedure well; ie, I would go for a revised RFC, greater > cost > > to us, but more reliable for everyone else. > > Yes, that's a relevant concern. It would actually be helpful in general > if the parts of RFCs that are affected by errata were clearly marked in > the RFC text, at least in the HTML rendering. > > > Yes, I suggested that on the main IETF list two months ago, but did not > get any traction. The HTML does say that they are errata but my doubt > is how many people outside academia and IETF standards development know > what the word means - I suggested using 'corrections' instead. Well, this WG is not going to re-engineer how errata work in the IETF or how the IETF tools display them. We have to work with what we have. /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 Thu Oct 4 02:26:51 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 E1AE421F85F9; Thu, 4 Oct 2012 02:26:51 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kPa2Jbi37Vcs; Thu, 4 Oct 2012 02:26:51 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DC7921F8673; Thu, 4 Oct 2012 02:26:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121004092651.29129.34136.idtracker@ietfa.amsl.com> Date: Thu, 04 Oct 2012 02:26:51 -0700 Cc: netmod@ietf.org Subject: [netmod] I-D Action: draft-ietf-netmod-routing-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: Thu, 04 Oct 2012 09:26:52 -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-05.txt Pages : 64 Date : 2012-10-04 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-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netmod-routing-cfg-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From lhotka@nic.cz Thu Oct 4 02:37: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 5D23421F865E for ; Thu, 4 Oct 2012 02:37:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_23=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7i9IKuRK3KDf for ; Thu, 4 Oct 2012 02:37:44 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id BA95D21F867B for ; Thu, 4 Oct 2012 02:37:44 -0700 (PDT) Received: from [IPv6:2001:1488:ac14:1400:e50f:8df:3372:d448] (unknown [IPv6:2001:1488:ac14:1400:e50f:8df:3372:d448]) by mail.nic.cz (Postfix) with ESMTPSA id D1F2913F993 for ; Thu, 4 Oct 2012 11:37:43 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1349343463; bh=NyuOr1kvMFnQzZZmMY+ZjRHs2Pfv5UwDnQY+r8XOifU=; h=From:Content-Type:Content-Transfer-Encoding:Subject:Date: References:To:Message-Id:Mime-Version; b=J96ef/6yKdpWDexaUwO3tuzQWWciBpaN8V9v3takbnLSNKAZ1Kpro0nBLMHZaSgEY 7wvJgB3RuxTm+pOg9f/mb0aDEyyB9EZ9rnOFupQUzMtK+RI2/Npgv/ruqW1EnKMPON vt6OAYQgxZT7bd4OMngCVeqWa2RPghteA+yvzWaU= From: Ladislav Lhotka Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 4 Oct 2012 11:37:43 +0200 References: <20121004092651.29129.34136.idtracker@ietfa.amsl.com> To: netmod@ietf.org Message-Id: <2AA1A34C-0508-48E0-AB06-340248A02A92@nic.cz> Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) X-Mailer: Apple Mail (2.1498) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Subject: [netmod] Fwd: I-D Action: draft-ietf-netmod-routing-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: Thu, 04 Oct 2012 09:37:47 -0000 Hi, this is a new version of the routing-cfg draft. I incorporated most = fixes and changes proposed by the reviewers, with one notable exception: = I didn't include the forwarding table (sorry, Mr. Yang:-), and also = removed all occurences of RIB and FIB acronyms. These terms are = apparently not understood in the same way by RFC authors and different = vendors. I believe it is better to let vendors model the forwarding = table by way of their own extensions, rather than ignite new flame wars = around this draft. Lada =20 Begin forwarded message: > From: internet-drafts@ietf.org > Subject: [netmod] I-D Action: draft-ietf-netmod-routing-cfg-05.txt > Date: October 4, 2012 11:26:51 AM GMT+02:00 > To: i-d-announce@ietf.org > Cc: netmod@ietf.org >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the NETCONF Data Modeling Language = Working Group of the IETF. >=20 > Title : A YANG Data Model for Routing Configuration > Author(s) : Ladislav Lhotka > Filename : draft-ietf-netmod-routing-cfg-05.txt > Pages : 64 > Date : 2012-10-04 >=20 > Abstract: > This document contains a specification of three YANG modules. > Together they form the core routing data model which serves as a > framework for configuring 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. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-netmod-routing-cfg >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-netmod-routing-cfg-05 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netmod-routing-cfg-05 >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From david.kessens@nsn.com Thu Oct 4 13:41: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 4BEAF21F875C for ; Thu, 4 Oct 2012 13:41:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.446 X-Spam-Level: X-Spam-Status: No, score=-6.446 tagged_above=-999 required=5 tests=[AWL=0.153, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t2nV903jFNEB for ; Thu, 4 Oct 2012 13:41:33 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 8F24A21F8759 for ; Thu, 4 Oct 2012 13:41:33 -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 q94KfTLm002670 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 4 Oct 2012 22:41:29 +0200 Received: from localhost.localdomain ([10.138.52.20]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q94KfOp0001394 for ; Thu, 4 Oct 2012 22:41:28 +0200 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.14.5/8.14.5) with ESMTP id q94KfO3A005249 for ; Thu, 4 Oct 2012 13:41:24 -0700 Received: (from david@localhost) by localhost.localdomain (8.14.5/8.14.5/Submit) id q94KfNFE005248 for netmod@ietf.org; Thu, 4 Oct 2012 13:41:23 -0700 Date: Thu, 4 Oct 2012 13:41:23 -0700 From: David Kessens To: netmod@ietf.org Message-ID: <20121004204123.GB2136@nsn.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 170 X-purgate-ID: 151667::1349383289-00006DFC-C79B5F10/0-0/0-0 Subject: [netmod] FYI: Session has been scheduled for IETF 85 X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 04 Oct 2012 20:41:34 -0000 Our session for next IETF meeting in Atlanta is now scheduled for: netmod Session 1 (1:30:00) Tuesday, Afternoon Session III 1700-1830 Room Name: Salon B From mbj@tail-f.com Fri Oct 5 01:28: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 803A121F8480 for ; Fri, 5 Oct 2012 01:28:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.991 X-Spam-Level: X-Spam-Status: No, score=-1.991 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZZYsV4FAoOMu for ; Fri, 5 Oct 2012 01:28:09 -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 C3C4821F8466 for ; Fri, 5 Oct 2012 01:28:08 -0700 (PDT) Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id E1EB21200C61 for ; Fri, 5 Oct 2012 10:28:06 +0200 (CEST) Date: Fri, 05 Oct 2012 10:28:05 +0200 (CEST) Message-Id: <20121005.102805.519929541.mbj@tail-f.com> To: netmod@ietf.org From: Martin Bjorklund X-Mailer: Mew version 6.4 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Mixed; boundary="--Next_Part(Fri_Oct__5_10_28_05_2012_283)--" Content-Transfer-Encoding: 7bit Subject: [netmod] Fw: New Version Notification for draft-bjorklund-netmod-operational-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2012 08:28:09 -0000 ----Next_Part(Fri_Oct__5_10_28_05_2012_283)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, Lada and I have written a draft where we try to define the concept of operational state data. There are a couple of open issues in the draft that need to be discussed, so please comment! /martin & lada ----Next_Part(Fri_Oct__5_10_28_05_2012_283)-- Content-Type: Message/Rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on dragon X-Spam-Level: X-Spam-Status: No, score=0.1 required=5.0 tests=BAYES_00,RDNS_DYNAMIC,SPF_FAIL, TO_NO_BRKTS_DYNIP autolearn=no version=3.3.1 X-Original-To: mbj@tail-f.com Delivered-To: mbj@tail-f.com Received: from mx.tail-f.com (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTP id 968451200C61 for ; Fri, 5 Oct 2012 10:23:31 +0200 (CEST) Received: from mail.ietf.org (mail.ietf.org [64.170.98.30]) by mx.tail-f.com (Postfix) with ESMTP id 63BBC410DF0 for ; Fri, 5 Oct 2012 10:23:31 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF5DA21F845A; Fri, 5 Oct 2012 01:23:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HvAWEirKrKwm; Fri, 5 Oct 2012 01:23:30 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 487F821F8466; Fri, 5 Oct 2012 01:23:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: mbj@tail-f.com Cc: lhotka@nic.cz Subject: New Version Notification for draft-bjorklund-netmod-operational-00.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121005082330.24853.71135.idtracker@ietfa.amsl.com> Date: Fri, 05 Oct 2012 01:23:30 -0700 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.1 int cnt prob spamicity histogram 0.00 53 0.026232 0.024037 ################################################ 0.10 5 0.108327 0.033107 ##### 0.20 0 0.000000 0.033107 0.30 0 0.000000 0.033107 0.40 0 0.000000 0.033107 0.50 0 0.000000 0.033107 0.60 0 0.000000 0.033107 0.70 0 0.000000 0.033107 0.80 0 0.000000 0.033107 0.90 0 0.000000 0.033107 A new version of I-D, draft-bjorklund-netmod-operational-00.txt has been successfully submitted by Martin Bjorklund and posted to the IETF repository. Filename: draft-bjorklund-netmod-operational Revision: 00 Title: Operational Data in NETCONF and YANG Creation date: 2012-10-05 WG ID: Individual Submission Number of pages: 21 URL: http://www.ietf.org/internet-drafts/draft-bjorklund-netmod= -operational-00.txt Status: http://datatracker.ietf.org/doc/draft-bjorklund-netmod-ope= rational Htmlized: http://tools.ietf.org/html/draft-bjorklund-netmod-operatio= nal-00 Abstract: This document defines the concept of operational state data in the context of YANG and the Network Configuration Protocol (NETCONF). It updates RFC 6020 with rules for how to model the operational state, and defines NETCONF operations to retrieve and modify the operational state. = = The IETF Secretariat ----Next_Part(Fri_Oct__5_10_28_05_2012_283)---- From lhotka@nic.cz Fri Oct 5 05:35: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 82D1221F86D3 for ; Fri, 5 Oct 2012 05:35:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.907 X-Spam-Level: X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wcw4NSYskbk7 for ; Fri, 5 Oct 2012 05:35: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 BFF5821F86D8 for ; Fri, 5 Oct 2012 05:35:28 -0700 (PDT) Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id EBE2E13FE0B for ; Fri, 5 Oct 2012 14:35:27 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1349440528; bh=Os4flvo30Cf1D7FDCMXsF4I+IYp5KCTIxAxhLCLm860=; h=From:Content-Type:Content-Transfer-Encoding:Subject:Date: References:To:Message-Id:Mime-Version; b=p1i8rmz9KWR/c1Rm6cvt0p/TdGh4TGEWoOjNUU8gOwSHikJ02U6Wpeg1B6TOXnl3+ +ii+lSOUYj1j4K7d2pXa8KJnmVjOYkUZM/lCVDFWyD9AoUL0jXcIBMiADHKdbEEzm7 ojn7ZNz1FNdk3NGlQ34rHJKiftzG59xkymGySa3c= From: Ladislav Lhotka Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 5 Oct 2012 14:35:27 +0200 References: <20121005123149.2823.86710.idtracker@ietfa.amsl.com> To: netmod@ietf.org Message-Id: <87B6A7BC-5B11-4A65-9EE2-09FC6094FD6F@nic.cz> Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) X-Mailer: Apple Mail (2.1498) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Subject: [netmod] Fwd: New Version Notification for draft-lhotka-netmod-yang-json-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2012 12:35:29 -0000 Hi, this is a new revision of the JSON mapping draft with a few fixes and = clarifications. I also changed the I-D name so that it appears on the = NETMOD page within "Related Documents". Lada Begin forwarded message: > From: internet-drafts@ietf.org > Subject: New Version Notification for = draft-lhotka-netmod-yang-json-00.txt > Date: October 5, 2012 2:31:49 PM GMT+02:00 > To: lhotka@nic.cz >=20 >=20 > A new version of I-D, draft-lhotka-netmod-yang-json-00.txt > has been successfully submitted by Ladislav Lhotka and posted to the > IETF repository. >=20 > Filename: draft-lhotka-netmod-yang-json > Revision: 00 > Title: Modeling JSON Text with YANG > Creation date: 2012-10-05 > WG ID: Individual Submission > Number of pages: 13 > URL: = http://www.ietf.org/internet-drafts/draft-lhotka-netmod-yang-json-00.txt > Status: = http://datatracker.ietf.org/doc/draft-lhotka-netmod-yang-json > Htmlized: = http://tools.ietf.org/html/draft-lhotka-netmod-yang-json-00 >=20 >=20 > Abstract: > This document defines rules for mapping data models expressed in = YANG > to configuration and operational state data encoded as JSON text. = It > does so by specifying a procedure for translating the subset of = YANG- > compatible XML documents to JSON text, and vice versa. >=20 >=20 >=20 >=20 > The IETF Secretariat >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From bclaise@cisco.com Fri Oct 5 07:31: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 14DEC21F86A7 for ; Fri, 5 Oct 2012 07:31:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.427 X-Spam-Level: X-Spam-Status: No, score=-4.427 tagged_above=-999 required=5 tests=[AWL=-2.428, BAYES_00=-2.599, J_CHICKENPOX_15=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id REWf7bMQdZ08 for ; Fri, 5 Oct 2012 07:31:07 -0700 (PDT) Received: from av-tac-bru.cisco.com (spooky-brew.cisco.com [144.254.15.113]) by ietfa.amsl.com (Postfix) with ESMTP id EF96621F86AD for ; Fri, 5 Oct 2012 07:31:04 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q95EUtb2014671; Fri, 5 Oct 2012 16:30:55 +0200 (CEST) Received: from [10.60.67.86] (ams-bclaise-8915.cisco.com [10.60.67.86]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q95EUqPK009526; Fri, 5 Oct 2012 16:30:52 +0200 (CEST) Message-ID: <506EEF1C.3080306@cisco.com> Date: Fri, 05 Oct 2012 16:30:52 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: "t.petch" References: <20120921154850.6A92C72E038@rfc-editor.org><20120924083532.GB7097@elstar.local><0B670666-932D-4549-B444-93B8021F7F1F@lhotka.name><506022CA.9030200@cisco.com> <5062B8E4.6090303@mg-soft.com><86E04D86-9E91-4EC5-9106-8D37C3B41D4E@nic.cz><20120926093725.GA58512@elstar.local> <50642856.6030703@cisco.com> <025601cda082$23047620$4001a8c0@gateway.2wire.net> In-Reply-To: <025601cda082$23047620$4001a8c0@gateway.2wire.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org, Ladislav Lhotka , rbonica@juniper.net, lhotka@cesnet.cz Subject: Re: [netmod] [Technical Errata Reported] RFC6110 (3362) X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 05 Oct 2012 14:31:08 -0000 On 02/10/2012 11:02, t.petch wrote: > ----- Original Message ----- > From: "Benoit Claise" > To: "Ladislav Lhotka" ; "Jernej Tuljak" > ; "Ladislav Lhotka" ; > ; ; > Sent: Thursday, September 27, 2012 11:20 AM >> Dear all, >>>> I don't have any experience with the errata procedure but I think > the first decision should be whether this qualifies as an erratum, > because indeed it changes the DSDL mapping "protocol", as Martin pointed > out. >>>> Who is entitled to make this decision? >>>> >>> I have moved this question over to Benoit since I think we need > advice >>> from the ADs here. >> Reviewing http://www.ietf.org/iesg/statement/errata-processing.html as >> background information... >> - As far as I can tell, we agree that this is a bug in the >> specification. So an errata should be filed. >> - As far as I can tell, we fall into: "Only errors that could cause >> implementation or deployment problems or significant confusion should > be >> Approved." >> - As far as I can tell, we don't fall into: "Changes that modify the >> working of a protocol to something that might be different from the >> intended consensus when the document was approved should be either > Hold >> for Document Update or Rejected" >> >> I'm in favor to keep the process simple, and to verify the errata, >> instead of producing a new RFC. > It is a substantive change to the protocol and would seem to me to be a > change to the consensus when the document was approved, albeit a > necessary change in the light of further understanding; but if an AD > says not, I won't argue. > > My greater concern is that I do not believe that consumers of RFC know > to look for Errata and so would miss it, producing something > incompatible. I know that I have been caught out, in other contexts, by > failing to look for Errata even though I have been around long enough to > know the procedure well; ie, I would go for a revised RFC, greater cost > to us, but more reliable for everyone else. I understand your concern. So I discussed this issue with Ron, and the errata is also his preferred option. Regards, Benoit. > > Tom Petch > >> However, before doing so, we want to be a safe side, basically making >> sure that there are no other implementations for which this bug fix >> (read non-backward compatibility change) would cause a problem. >> >> So let me propose the following: >> - We keep the errata 3362 open for now >> - Since errata 3362 needs to updated (and since we can't update this >> errata without approving/rejecting AFAIK), we create a new errata with >> all the changes, as agreed on the mailing list. Do we have an > agreement >> on what Lada proposed? >> - I send a kind of LC email to the mailing list, with this new errata >> - If no issue during this LC, I reject errata 3362 (pointing to the > new >> errata), and I verify the new one. >> >> Regards, Benoit. >>> /js >>> > > From andy@yumaworks.com Fri Oct 5 08:13: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 730AF21F871E for ; Fri, 5 Oct 2012 08:13:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.482 X-Spam-Level: X-Spam-Status: No, score=-2.482 tagged_above=-999 required=5 tests=[AWL=-0.106, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zZ3pftORsnEc for ; Fri, 5 Oct 2012 08:13:00 -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 7815721F84D5 for ; Fri, 5 Oct 2012 08:13:00 -0700 (PDT) Received: by mail-qc0-f172.google.com with SMTP id c10so1365823qca.31 for ; Fri, 05 Oct 2012 08:13:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=Pg8DZaAv677DKU5+1/sGIzsPi6upczRU+MMI7FctZtE=; b=lFqL8/PB7nAtLo8Y02F9WGPozWRNBkUzsvgpQTg9TAAN1TtkoPpBn5oJl3qTTRwrKJ 7pD0gqVV5wEoeSddjVvVYLeu52TiKQ32ZP2u26jnD2tyx9ldU+W7rSI4EjhigXLu6LHi AuHOrxH0x7lk+K39KK+RBivfrVOGm/blRHoosXfUsK1sHbHflNkYlHY4/cgsy3XqKFJu zqAL/qdte739iHZxfjJyYdwI56VkDokoMda0UZYbXhFUU0ncgf9xJlL0FM+tY2vGMNEY HESJtAyXxnm19ZuHArkzoktuxRnrtavSBfakNp6864zdersCDj/AzuAqsrRaGKWi+PWg eEvA== MIME-Version: 1.0 Received: by 10.229.115.26 with SMTP id g26mr3652599qcq.106.1349449979789; Fri, 05 Oct 2012 08:12:59 -0700 (PDT) Received: by 10.49.127.52 with HTTP; Fri, 5 Oct 2012 08:12:59 -0700 (PDT) In-Reply-To: <20121005.102805.519929541.mbj@tail-f.com> References: <20121005.102805.519929541.mbj@tail-f.com> Date: Fri, 5 Oct 2012 08:12:59 -0700 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: multipart/alternative; boundary=0023544702acb004b004cb514e94 X-Gm-Message-State: ALoCoQnjvJbLstNRd2ddBMgxhhLAOmmrh/WrXfw8q31hQdLaqjmg0IvV//kEeEiBJ/pdAh3OJlQr Cc: netmod@ietf.org Subject: Re: [netmod] Fw: New Version Notification for draft-bjorklund-netmod-operational-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2012 15:13:01 -0000 --0023544702acb004b004cb514e94 Content-Type: text/plain; charset=UTF-8 On Fri, Oct 5, 2012 at 1:28 AM, Martin Bjorklund wrote: > Hi, > > Lada and I have written a draft where we try to define the concept of > operational state data. There are a couple of open issues in the > draft that need to be discussed, so please comment! > > I will just comment on the problem statements in section 3. 3.1) I don't agree that modeling config and operational data separately is is real problem, or that it is counter-intuitive to operators. The operational state (e.g., FIB) may come from multiple parts of the configuration, not just the simple example shown in sec. 3.1.1. I do not agree with that example, showing a separate interface-oper table. That is not needed. Just add a leaf to the interface entry to identify it as 'active'. This is a contrived example. 3.2) I do not agree that operational state needs to be edited directly by the client. I actually think the custom RPC approach in the example in 3.2.1 is better and more clear within the model. Editing config=false nodes is a fundamental change to the NETCONF/YANG architecture and it should not be done. Actions like and properly model the API between client and server, not . > /martin & lada > Andy > > > > > ---------- Forwarded message ---------- > From: internet-drafts@ietf.org > To: mbj@tail-f.com > Cc: lhotka@nic.cz > Date: Fri, 05 Oct 2012 01:23:30 -0700 > Subject: New Version Notification for > draft-bjorklund-netmod-operational-00.txt > > A new version of I-D, draft-bjorklund-netmod-operational-00.txt > has been successfully submitted by Martin Bjorklund and posted to the > IETF repository. > > Filename: draft-bjorklund-netmod-operational > Revision: 00 > Title: Operational Data in NETCONF and YANG > Creation date: 2012-10-05 > WG ID: Individual Submission > Number of pages: 21 > URL: > http://www.ietf.org/internet-drafts/draft-bjorklund-netmod-operational-00.txt > Status: > http://datatracker.ietf.org/doc/draft-bjorklund-netmod-operational > Htmlized: > http://tools.ietf.org/html/draft-bjorklund-netmod-operational-00 > > > Abstract: > This document defines the concept of operational state data in the > context of YANG and the Network Configuration Protocol (NETCONF). It > updates RFC 6020 with rules for how to model the operational state, > and defines NETCONF operations to retrieve and modify the operational > state. > > > > > The IETF Secretariat > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > --0023544702acb004b004cb514e94 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Fri, Oct 5, 2012 at 1:28 AM, Martin B= jorklund <mbj@tail-f.com> wrote:
Hi,

Lada and I have written a draft where we try to define the concept of
operational state data. =C2=A0There are a couple of open issues in the
draft that need to be discussed, so please comment!


I will just comment on the problem sta= tements in section 3.

3.1) I don't agree that = modeling config and operational data
separately is is real proble= m, or that it is counter-intuitive
to operators.=C2=A0

The operational state (e.= g., FIB) may come from multiple
parts of the configuration, not j= ust the simple example shown
in sec. 3.1.1. I do not agree with t= hat example, showing
a separate interface-oper table. =C2=A0That is not needed.
J= ust add a leaf to the interface entry to identify it as 'active'.
This is a contrived example.

3.2) =C2=A0I= do not agree that operational state needs to be edited directly
by the client. =C2=A0I actually think the custom RPC approach in the
example in 3.2.1 is better and more clear within the model.
<= div>Editing config=3Dfalse nodes is a fundamental change to the
N= ETCONF/YANG architecture and it should not be done.

Actions like <add-route> and <delete-route>= properly model
the API between client and server, not <edit-o= perational>.


/martin & lada


Andy<= /div>
=C2=A0




---------- Forwarded message ----------
From:=C2=A0internet-drafts@ietf.org
To:=C2=A0mbj@tail-f.com
Cc:=C2=A0lhotka@nic.cz
Date:=C2=A0Fri, 05 Oct 2012 01:23:30 -0700
Subject:=C2=A0New Version Not= ification for draft-bjorklund-netmod-operational-00.txt

A new version of I-D, draft-bjorklund-netmod-operational-00.txt
has been successfully submitted by Martin Bjorklund and posted to the
IETF repository.

Filename: =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-bjorklund-netmod-operational
Revision: =C2=A0 =C2=A0 =C2=A0 =C2=A000
Title: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Operational Data in NETCONF and Y= ANG
Creation date: =C2=A0 2012-10-05
WG ID: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Number of pages: 21
URL: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 http://www.ietf.org/internet-drafts/draft-bjorklund-netmod-operational= -00.txt
Status: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0http://data= tracker.ietf.org/doc/draft-bjorklund-netmod-operational
Htmlized: =C2=A0 =C2=A0 =C2=A0 =C2=A0http://tools.ietf.= org/html/draft-bjorklund-netmod-operational-00


Abstract:
=C2=A0 =C2=A0This document defines the concept of operational state data in= the
=C2=A0 =C2=A0context of YANG and the Network Configuration Protocol (NETCON= F). =C2=A0It
=C2=A0 =C2=A0updates RFC 6020 with rules for how to model the operational s= tate,
=C2=A0 =C2=A0and defines NETCONF operations to retrieve and modify the oper= ational
=C2=A0 =C2=A0state.




The IETF Secretariat


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


--0023544702acb004b004cb514e94-- From lhotka@nic.cz Fri Oct 5 08:50: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 DFD1221F86F5 for ; Fri, 5 Oct 2012 08:50:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.609 X-Spam-Level: X-Spam-Status: No, score=-1.609 tagged_above=-999 required=5 tests=[AWL=-0.210, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, J_CHICKENPOX_65=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HxvW1AyZ9uQJ for ; Fri, 5 Oct 2012 08:50:02 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id DFD6321F86B5 for ; Fri, 5 Oct 2012 08:50:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id A462C540558 for ; Fri, 5 Oct 2012 17:49:59 +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 NczIuF2o5oZo for ; Fri, 5 Oct 2012 17:49:53 +0200 (CEST) Received: from localhost (unknown [10.107.191.189]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id EC83B540239 for ; Fri, 5 Oct 2012 17:49:48 +0200 (CEST) From: Ladislav Lhotka To: netmod@ietf.org In-Reply-To: References: <20121005.102805.519929541.mbj@tail-f.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: Fri, 05 Oct 2012 17:49:28 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [netmod] Fw: New Version Notification for draft-bjorklund-netmod-operational-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2012 15:50:03 -0000 Andy Bierman writes: > On Fri, Oct 5, 2012 at 1:28 AM, Martin Bjorklund wrote: > >> Hi, >> >> Lada and I have written a draft where we try to define the concept of >> operational state data. There are a couple of open issues in the >> draft that need to be discussed, so please comment! >> >> > I will just comment on the problem statements in section 3. > > 3.1) I don't agree that modeling config and operational data > separately is is real problem, or that it is counter-intuitive > to operators. > > The operational state (e.g., FIB) may come from multiple > parts of the configuration, not just the simple example shown > in sec. 3.1.1. I do not agree with that example, showing > a separate interface-oper table. That is not needed. > Just add a leaf to the interface entry to identify it as 'active'. Who is supposed to add such a leaf - the server? And how can the client learn about the existence of inactive interfaces? > This is a contrived example. > > 3.2) I do not agree that operational state needs to be edited directly > by the client. I actually think the custom RPC approach in the > example in 3.2.1 is better and more clear within the model. > Editing config=false nodes is a fundamental change to the > NETCONF/YANG architecture and it should not be done. But this is exactly what the IRS and SCIM (and maybe other) folks are about to do. > > Actions like and properly model > the API between client and server, not . The means for modelling RPCs are very limited - the semantics has to be told in prose. This is exactly why REST is superior to all kinds of RPC-based APIs. Lada > > >> /martin & lada >> > > > Andy > > >> >> >> >> >> ---------- Forwarded message ---------- >> From: internet-drafts@ietf.org >> To: mbj@tail-f.com >> Cc: lhotka@nic.cz >> Date: Fri, 05 Oct 2012 01:23:30 -0700 >> Subject: New Version Notification for >> draft-bjorklund-netmod-operational-00.txt >> >> A new version of I-D, draft-bjorklund-netmod-operational-00.txt >> has been successfully submitted by Martin Bjorklund and posted to the >> IETF repository. >> >> Filename: draft-bjorklund-netmod-operational >> Revision: 00 >> Title: Operational Data in NETCONF and YANG >> Creation date: 2012-10-05 >> WG ID: Individual Submission >> Number of pages: 21 >> URL: >> http://www.ietf.org/internet-drafts/draft-bjorklund-netmod-operational-00.txt >> Status: >> http://datatracker.ietf.org/doc/draft-bjorklund-netmod-operational >> Htmlized: >> http://tools.ietf.org/html/draft-bjorklund-netmod-operational-00 >> >> >> Abstract: >> This document defines the concept of operational state data in the >> context of YANG and the Network Configuration Protocol (NETCONF). It >> updates RFC 6020 with rules for how to model the operational state, >> and defines NETCONF operations to retrieve and modify the operational >> state. >> >> >> >> >> The IETF Secretariat >> >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >> >> > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From andy@yumaworks.com Fri Oct 5 09:24: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 26FE221F87A8 for ; Fri, 5 Oct 2012 09:24:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[AWL=-0.703, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GtPWvMiwcs0T for ; Fri, 5 Oct 2012 09:24:16 -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 CB8E221F8686 for ; Fri, 5 Oct 2012 09:24:15 -0700 (PDT) Received: by mail-qc0-f172.google.com with SMTP id c10so1435410qca.31 for ; Fri, 05 Oct 2012 09:24:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=dKwbGC0xaymG67kXpCJCvYSuo+TnjKay6VI30GeMKMM=; b=ZUh602N6t7qc6zFAWOjAr3ydkyam+SQyBwhWG0RMYDYgdh6/X8CxMPxKWDPCPX/mrm K9TGcU7Pp/ZAsRl5pdwo0bEi2JKUd49U1lXGLZlDL52O94U7KwwteqpPN4EG93kLHD5b u2tA6cyCJvALwwXwkYVlkd0pe2UAZynRrKjb17IG86sGzAB7SKqBs8LBX0/xs9/9D2vO Q2xmIobm7iKpNVPVJlgn0uTgG6s8gX9au3nXF98WAePdGzgkHbPGRc7xpC9eiYXiFMLY yfE5DoZhMdRdv2It6z8Ea4DnZJ7GmJ0mrdxhwKEi3HdDX4Yhi5XK1gVLzDr+1jUTSo9i v/VA== MIME-Version: 1.0 Received: by 10.224.9.193 with SMTP id m1mr17714074qam.53.1349454250928; Fri, 05 Oct 2012 09:24:10 -0700 (PDT) Received: by 10.49.127.52 with HTTP; Fri, 5 Oct 2012 09:24:10 -0700 (PDT) In-Reply-To: References: <20121005.102805.519929541.mbj@tail-f.com> Date: Fri, 5 Oct 2012 09:24:10 -0700 Message-ID: From: Andy Bierman To: netmod@ietf.org Content-Type: multipart/alternative; boundary=bcaec51a82a0446a3004cb524d3e X-Gm-Message-State: ALoCoQkfjq+ytjEXihl+oqukEKpr5FjSvsRRJQ/r9rd3ra+GlYPTV9XjjAN7Bpg++jwAtM4hbox4 Subject: Re: [netmod] Fw: New Version Notification for draft-bjorklund-netmod-operational-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2012 16:24:17 -0000 --bcaec51a82a0446a3004cb524d3e Content-Type: text/plain; charset=UTF-8 On Fri, Oct 5, 2012 at 8:49 AM, Ladislav Lhotka wrote: > Andy Bierman writes: > > > On Fri, Oct 5, 2012 at 1:28 AM, Martin Bjorklund wrote: > > > >> Hi, > >> > >> Lada and I have written a draft where we try to define the concept of > >> operational state data. There are a couple of open issues in the > >> draft that need to be discussed, so please comment! > >> > >> > > I will just comment on the problem statements in section 3. > > > > 3.1) I don't agree that modeling config and operational data > > separately is is real problem, or that it is counter-intuitive > > to operators. > > > > The operational state (e.g., FIB) may come from multiple > > parts of the configuration, not just the simple example shown > > in sec. 3.1.1. I do not agree with that example, showing > > a separate interface-oper table. That is not needed. > > Just add a leaf to the interface entry to identify it as 'active'. > > Who is supposed to add such a leaf - the server? And how can the client > learn about the existence of inactive interfaces? > The data modeler writing the YANG module should add the leaf. > > This is a contrived example. > > > > 3.2) I do not agree that operational state needs to be edited directly > > by the client. I actually think the custom RPC approach in the > > example in 3.2.1 is better and more clear within the model. > > Editing config=false nodes is a fundamental change to the > > NETCONF/YANG architecture and it should not be done. > > But this is exactly what the IRS and SCIM (and maybe other) folks are > about to do. > They haven't decided what to do yet AFAIK. IRS hasn't even had a BOF yet, let alone a WG. I suspect they will create an API, not a data model that is edited like configuration. We don't need to change N/Y based on speculation about what IRS WG will choose for a solution. > > > > > Actions like and properly model > > the API between client and server, not . > > The means for modelling RPCs are very limited - the semantics has to be > told in prose. > This is exactly why REST is superior to all kinds of RPC-based APIs. > IMO operational state is a representation of internal device state. It may be very implementation-specific how the operational state can be edited. The use-cases where operational state is injected or altered are very limited. We already have a solution that works for these corner cases (custom RPCs). Your draft returns config=true nodes in , like duplex=auto vs. duplex=full. IMO these corner cases do not show up that often, and the old solution of separate admin-status and oper-status is good enough. Returning config=true nodes in requires a new YANG extension and server customization to support it. The validation/constraints/transaction model in NETCONF should be limited to config=true nodes. Operational nodes change too fast and are too distributed to justify adding editing capabilities for config=false nodes. > Lada > > Andy > > > > > >> /martin & lada > >> > > > > > > Andy > > > > > >> > >> > >> > >> > >> ---------- Forwarded message ---------- > >> From: internet-drafts@ietf.org > >> To: mbj@tail-f.com > >> Cc: lhotka@nic.cz > >> Date: Fri, 05 Oct 2012 01:23:30 -0700 > >> Subject: New Version Notification for > >> draft-bjorklund-netmod-operational-00.txt > >> > >> A new version of I-D, draft-bjorklund-netmod-operational-00.txt > >> has been successfully submitted by Martin Bjorklund and posted to the > >> IETF repository. > >> > >> Filename: draft-bjorklund-netmod-operational > >> Revision: 00 > >> Title: Operational Data in NETCONF and YANG > >> Creation date: 2012-10-05 > >> WG ID: Individual Submission > >> Number of pages: 21 > >> URL: > >> > http://www.ietf.org/internet-drafts/draft-bjorklund-netmod-operational-00.txt > >> Status: > >> http://datatracker.ietf.org/doc/draft-bjorklund-netmod-operational > >> Htmlized: > >> http://tools.ietf.org/html/draft-bjorklund-netmod-operational-00 > >> > >> > >> Abstract: > >> This document defines the concept of operational state data in the > >> context of YANG and the Network Configuration Protocol (NETCONF). It > >> updates RFC 6020 with rules for how to model the operational state, > >> and defines NETCONF operations to retrieve and modify the operational > >> state. > >> > >> > >> > >> > >> The IETF Secretariat > >> > >> > >> _______________________________________________ > >> netmod mailing list > >> netmod@ietf.org > >> https://www.ietf.org/mailman/listinfo/netmod > >> > >> > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --bcaec51a82a0446a3004cb524d3e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Fri, Oct 5, 2012 at 8:49 AM, Ladislav= Lhotka <lhotka@nic.cz> wrote:
Andy Bierman <andy@yumaworks.com> writes:

> On Fri, Oct 5, 2012 at 1:28 AM, Martin Bjorklund <mbj@tail-f.com> wrote:
>
>> Hi,
>>
>> Lada and I have written a draft where we try to define the concept= of
>> operational state data. =C2=A0There are a couple of open issues in= the
>> draft that need to be discussed, so please comment!
>>
>>
> I will just comment on the problem statements in section 3.
>
> 3.1) I don't agree that modeling config and operational data
> separately is is real problem, or that it is counter-intuitive
> to operators.
>
> The operational state (e.g., FIB) may come from multiple
> parts of the configuration, not just the simple example shown
> in sec. 3.1.1. I do not agree with that example, showing
> a separate interface-oper table. =C2=A0That is not needed.
> Just add a leaf to the interface entry to identify it as 'active&#= 39;.

Who is supposed to add such a leaf - the server? And how can the client lea= rn about the existence of inactive interfaces?


The data modeler writing the YANG module should add = the leaf.
=C2=A0
=C2=A0
> This is a contrived example.
>
> 3.2) =C2=A0I do not agree that operational state needs to be edited di= rectly
> by the client. =C2=A0I actually think the custom RPC approach in the > example in 3.2.1 is better and more clear within the model.
> Editing config=3Dfalse nodes is a fundamental change to the
> NETCONF/YANG architecture and it should not be done.

But this is exactly what the IRS and SCIM (and maybe other) folks are about= to do.


They haven't= decided what to do yet AFAIK.
IRS hasn't even had a BOF yet,= let alone a WG.
I suspect they will create an API, not a data model
that is = edited like configuration. =C2=A0We don't need
to change N/Y = based on speculation about what IRS WG
will choose for a solution= .


=C2=A0

>
> Actions like <add-route> and <delete-route> properly model=
> the API between client and server, not <edit-operational>.

The means for modelling RPCs are very limited - the semantics has to be tol= d in prose.
This is exactly why REST is superior to all kinds of RPC-based APIs.

IMO operational state is a representation of = internal device state.
It may be very implementation-specific how= the operational state
can be edited.

The use-cases where operationa= l state is injected or altered
are very limited. =C2=A0We already= have a solution that works for
these corner cases (custom RPCs).=

Your draft returns config=3Dtrue nodes in <get-opera= tional>,
like duplex=3Dauto vs. duplex=3Dfull. =C2=A0IMO these= corner cases
do not show up that often, and the old solution of<= /div>
separate admin-status and oper-status is good enough.
Returning c= onfig=3Dtrue nodes in <get-operational>
requires a new YANG= extension and server customization
to support it.

The validation/constraints/transaction model in NETCONF
should be limited to config=3Dtrue nodes. =C2=A0Operational nodes
change too fast and are too distributed to justify adding
edit= ing capabilities=C2=A0for config=3Dfalse nodes.



Lada



Andy
=C2=A0
>
>
>> /martin & lada
>>
>
>
> Andy
>
>
>>
>>
>>
>>
>> ---------- Forwarded message ----------
>> From: internet-drafts@= ietf.org
>> To: mbj@tail-f.com
>> Cc: lhotka@nic.cz
>> Date: Fri, 05 Oct 2012 01:23:30 -0700
>> Subject: New Version Notification for
>> draft-bjorklund-netmod-operational-00.txt
>>
>> A new version of I-D, draft-bjorklund-netmod-operational-00.txt >> has been successfully submitted by Martin Bjorklund and posted to = the
>> IETF repository.
>>
>> Filename: =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-bjorklund-netmod-operat= ional
>> Revision: =C2=A0 =C2=A0 =C2=A0 =C2=A000
>> Title: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Operational Data in NETC= ONF and YANG
>> Creation date: =C2=A0 2012-10-05
>> WG ID: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission >> Number of pages: 21
>> URL:
>> http://www.ietf.org/internet-draf= ts/draft-bjorklund-netmod-operational-00.txt
>> Status:
>> http://datatracker.ietf.org/doc/draft-bjorkl= und-netmod-operational
>> Htmlized:
>> http://tools.ietf.org/html/draft-bjorklund-net= mod-operational-00
>>
>>
>> Abstract:
>> =C2=A0 =C2=A0This document defines the concept of operational stat= e data in the
>> =C2=A0 =C2=A0context of YANG and the Network Configuration Protoco= l (NETCONF). =C2=A0It
>> =C2=A0 =C2=A0updates RFC 6020 with rules for how to model the oper= ational state,
>> =C2=A0 =C2=A0and defines NETCONF operations to retrieve and modify= the operational
>> =C2=A0 =C2=A0state.
>>
>>
>>
>>
>> The IETF Secretariat
>>
>>
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>>
>>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

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

--bcaec51a82a0446a3004cb524d3e-- From lhotka@nic.cz Sat Oct 6 02:17: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 4BECC21F865D for ; Sat, 6 Oct 2012 02:17:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.304 X-Spam-Level: X-Spam-Status: No, score=-1.304 tagged_above=-999 required=5 tests=[AWL=-0.505, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mOSvqyFEwMTg for ; Sat, 6 Oct 2012 02:17:57 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 2F09D21F8596 for ; Sat, 6 Oct 2012 02:17:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 045A2540379 for ; Sat, 6 Oct 2012 11:17:48 +0200 (CEST) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CYVe03E3U7Pn for ; Sat, 6 Oct 2012 11:17:43 +0200 (CEST) Received: from localhost (unknown [10.107.191.189]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id BA9F8540239 for ; Sat, 6 Oct 2012 11:17:39 +0200 (CEST) From: Ladislav Lhotka To: netmod@ietf.org In-Reply-To: References: <20121005.102805.519929541.mbj@tail-f.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: Sat, 06 Oct 2012 11:17:18 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [netmod] Fw: New Version Notification for draft-bjorklund-netmod-operational-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: Sat, 06 Oct 2012 09:17:58 -0000 Andy Bierman writes: > On Fri, Oct 5, 2012 at 8:49 AM, Ladislav Lhotka wrote: > >> Andy Bierman writes: >> >> > On Fri, Oct 5, 2012 at 1:28 AM, Martin Bjorklund wrote: >> > >> >> Hi, >> >> >> >> Lada and I have written a draft where we try to define the concept of >> >> operational state data. There are a couple of open issues in the >> >> draft that need to be discussed, so please comment! >> >> >> >> >> > I will just comment on the problem statements in section 3. >> > >> > 3.1) I don't agree that modeling config and operational data >> > separately is is real problem, or that it is counter-intuitive >> > to operators. >> > >> > The operational state (e.g., FIB) may come from multiple >> > parts of the configuration, not just the simple example shown >> > in sec. 3.1.1. I do not agree with that example, showing >> > a separate interface-oper table. That is not needed. >> > Just add a leaf to the interface entry to identify it as 'active'. >> >> Who is supposed to add such a leaf - the server? And how can the client >> learn about the existence of inactive interfaces? >> > > > The data modeler writing the YANG module should add the leaf. I mean: who is supposed to set the value of the "active" leaf - the server or client? But my second question is more important: how does the client learn about an existing interface that's not in the configuration? > > >> > >> This is a contrived example. >> > >> > 3.2) I do not agree that operational state needs to be edited directly >> > by the client. I actually think the custom RPC approach in the >> > example in 3.2.1 is better and more clear within the model. >> > Editing config=false nodes is a fundamental change to the >> > NETCONF/YANG architecture and it should not be done. >> >> But this is exactly what the IRS and SCIM (and maybe other) folks are >> about to do. >> > > > They haven't decided what to do yet AFAIK. > IRS hasn't even had a BOF yet, let alone a WG. > I suspect they will create an API, not a data model > that is edited like configuration. We don't need > to change N/Y based on speculation about what IRS WG > will choose for a solution. > This was just examples. The thing is, some applications and devices don't need the comfort (and overhead) of NETCONF. If I want to temporarily switch off forwarding on a Linux box, I simply set /proc/sys/net/ipv4/ip_forward to zero. While you may argue that creators of new configuration APIs are doomed to reinvent the NETCONF wheels, I don't think it always has to be the case. Our draft is also intended to enable coexistence of NETCONF with other management interfaces, and the operational state datastore (rather than NETCONF configuration datastores) is supposed to be the common playground. > > > >> >> > >> > Actions like and properly model >> > the API between client and server, not . >> >> The means for modelling RPCs are very limited - the semantics has to be >> told in prose. >> This is exactly why REST is superior to all kinds of RPC-based APIs. >> > > IMO operational state is a representation of internal device state. > It may be very implementation-specific how the operational state > can be edited. > > The use-cases where operational state is injected or altered > are very limited. We already have a solution that works for > these corner cases (custom RPCs). > > Your draft returns config=true nodes in , > like duplex=auto vs. duplex=full. IMO these corner cases > do not show up that often, and the old solution of > separate admin-status and oper-status is good enough. > Returning config=true nodes in > requires a new YANG extension and server customization > to support it. > > The validation/constraints/transaction model in NETCONF > should be limited to config=true nodes. Operational nodes > change too fast and are too distributed to justify adding > editing capabilities for config=false nodes. Even then operational nodes have to satisfy some constraints that must be common to all management interfaces and/or protocols that work with the data, and often constraints on config data also involve operational data. Lada > > > >> Lada >> >> > > Andy > > >> > >> > >> >> /martin & lada >> >> >> > >> > >> > Andy >> > >> > >> >> >> >> >> >> >> >> >> >> ---------- Forwarded message ---------- >> >> From: internet-drafts@ietf.org >> >> To: mbj@tail-f.com >> >> Cc: lhotka@nic.cz >> >> Date: Fri, 05 Oct 2012 01:23:30 -0700 >> >> Subject: New Version Notification for >> >> draft-bjorklund-netmod-operational-00.txt >> >> >> >> A new version of I-D, draft-bjorklund-netmod-operational-00.txt >> >> has been successfully submitted by Martin Bjorklund and posted to the >> >> IETF repository. >> >> >> >> Filename: draft-bjorklund-netmod-operational >> >> Revision: 00 >> >> Title: Operational Data in NETCONF and YANG >> >> Creation date: 2012-10-05 >> >> WG ID: Individual Submission >> >> Number of pages: 21 >> >> URL: >> >> >> http://www.ietf.org/internet-drafts/draft-bjorklund-netmod-operational-00.txt >> >> Status: >> >> http://datatracker.ietf.org/doc/draft-bjorklund-netmod-operational >> >> Htmlized: >> >> http://tools.ietf.org/html/draft-bjorklund-netmod-operational-00 >> >> >> >> >> >> Abstract: >> >> This document defines the concept of operational state data in the >> >> context of YANG and the Network Configuration Protocol (NETCONF). It >> >> updates RFC 6020 with rules for how to model the operational state, >> >> and defines NETCONF operations to retrieve and modify the operational >> >> state. >> >> >> >> >> >> >> >> >> >> The IETF Secretariat >> >> >> >> >> >> _______________________________________________ >> >> netmod mailing list >> >> netmod@ietf.org >> >> https://www.ietf.org/mailman/listinfo/netmod >> >> >> >> >> > _______________________________________________ >> > netmod mailing list >> > netmod@ietf.org >> > https://www.ietf.org/mailman/listinfo/netmod >> >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >> > _______________________________________________ > 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 Sun Oct 7 06:09: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 A49B021F8643 for ; Sun, 7 Oct 2012 06:09:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.86 X-Spam-Level: X-Spam-Status: No, score=-1.86 tagged_above=-999 required=5 tests=[AWL=-0.684, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8y3HOhFM+IMx for ; Sun, 7 Oct 2012 06:09:27 -0700 (PDT) Received: from mail-qc0-f182.google.com (mail-qc0-f182.google.com [209.85.216.182]) by ietfa.amsl.com (Postfix) with ESMTP id 50FD321F8609 for ; Sun, 7 Oct 2012 06:09:27 -0700 (PDT) Received: by mail-qc0-f182.google.com with SMTP id l39so3144452qcs.27 for ; Sun, 07 Oct 2012 06:09:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=YINGxgN4vncbLnQAjPRvmfFeigy6Vc3eE/NQaRDnK98=; b=ZcuAevXvf3HwisLJlsR5tvHV71Fk2+yQ1DKa4pehUt9gFwTSIF8A5R3LdMC21ZFyAs O9Evzg7tOOwLydY5Rs48Xs3nnL/xx5CR++H0Cf4dELYl/3S7PAwtVfuPUvpFW85zede0 KZSWv6DYSV1OviMWHp7BJYjJKp4P9uIPNkZiMuQval8eO5lMuKAROPm6yxqoTbUwkpvj w5e2bfPDCjNCM2g1/AqJN+NXBJ+Zzz/SLQf5xGPpUNBQ83QyN8ZN98pMO6XSy6yZ7799 Ml7poNP7WFfKNlvY8lFxkVzu83h5LpLAMrRXFDdLEhPjP1Tej+Rd5P5Cf8y8QfWXGqm1 JB5A== MIME-Version: 1.0 Received: by 10.224.100.200 with SMTP id z8mr25453895qan.75.1349615366555; Sun, 07 Oct 2012 06:09:26 -0700 (PDT) Received: by 10.49.127.52 with HTTP; Sun, 7 Oct 2012 06:09:26 -0700 (PDT) In-Reply-To: References: <20121005.102805.519929541.mbj@tail-f.com> Date: Sun, 7 Oct 2012 06:09:26 -0700 Message-ID: From: Andy Bierman To: netmod@ietf.org Content-Type: multipart/alternative; boundary=20cf3074afe681c73f04cb77d026 X-Gm-Message-State: ALoCoQkAG4J7IZ/NLpgtExYpI/V+fMgvPwnsMGyDRERS9es9buHW0YGaL3Hj1tAWjroHfNGPvjg9 Subject: Re: [netmod] Fw: New Version Notification for draft-bjorklund-netmod-operational-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: Sun, 07 Oct 2012 13:09:29 -0000 --20cf3074afe681c73f04cb77d026 Content-Type: text/plain; charset=UTF-8 On Sat, Oct 6, 2012 at 2:17 AM, Ladislav Lhotka wrote: > Andy Bierman writes: > > > On Fri, Oct 5, 2012 at 8:49 AM, Ladislav Lhotka wrote: > > > >> Andy Bierman writes: > >> > >> > On Fri, Oct 5, 2012 at 1:28 AM, Martin Bjorklund > wrote: > >> > > >> >> Hi, > >> >> > >> >> Lada and I have written a draft where we try to define the concept of > >> >> operational state data. There are a couple of open issues in the > >> >> draft that need to be discussed, so please comment! > >> >> > >> >> > >> > I will just comment on the problem statements in section 3. > >> > > >> > 3.1) I don't agree that modeling config and operational data > >> > separately is is real problem, or that it is counter-intuitive > >> > to operators. > >> > > >> > The operational state (e.g., FIB) may come from multiple > >> > parts of the configuration, not just the simple example shown > >> > in sec. 3.1.1. I do not agree with that example, showing > >> > a separate interface-oper table. That is not needed. > >> > Just add a leaf to the interface entry to identify it as 'active'. > >> > >> Who is supposed to add such a leaf - the server? And how can the client > >> learn about the existence of inactive interfaces? > >> > > > > > > The data modeler writing the YANG module should add the leaf. > > I mean: who is supposed to set the value of the "active" leaf - the server > or client? But my second question is more important: how does the client > learn about an existing interface that's not in the configuration? > > I meant the server sets it. Your problem statement does not mention client pre-provisioning of config data or disabling config data. These are still unsolved problems in NETCONF. > > > > > >> > > > >> This is a contrived example. > >> > > >> > 3.2) I do not agree that operational state needs to be edited > directly > >> > by the client. I actually think the custom RPC approach in the > >> > example in 3.2.1 is better and more clear within the model. > >> > Editing config=false nodes is a fundamental change to the > >> > NETCONF/YANG architecture and it should not be done. > >> > >> But this is exactly what the IRS and SCIM (and maybe other) folks are > >> about to do. > >> > > > > > > They haven't decided what to do yet AFAIK. > > IRS hasn't even had a BOF yet, let alone a WG. > > I suspect they will create an API, not a data model > > that is edited like configuration. We don't need > > to change N/Y based on speculation about what IRS WG > > will choose for a solution. > > > > This was just examples. The thing is, some applications and devices don't > need the comfort (and overhead) of NETCONF. If I want to temporarily switch > off forwarding on a Linux box, I simply set /proc/sys/net/ipv4/ip_forward > to zero. > I don't agree that NETCONF should have editable state. You can mess up a Linux system hacking on /proc. I do not want to add a hack or a full-blown validation system for editing config=false nodes. In your duplex example, let's say it is set to 'auto' and negotiates to 'half'. Then I the value to be 'full'. Now config says 'auto' and state says 'full'. How does every other operator know that I did that? To them it looks like the auto-negotiated value is 'full' but it is not. > While you may argue that creators of new configuration APIs are doomed to > reinvent the NETCONF wheels, I don't think it always has to be the case. > > Our draft is also intended to enable coexistence of NETCONF with other > management interfaces, and the operational state datastore (rather than > NETCONF configuration datastores) is supposed to be the common playground. > > > > > > > > >> > >> > > >> > Actions like and properly model > >> > the API between client and server, not . > >> > >> The means for modelling RPCs are very limited - the semantics has to be > >> told in prose. > >> This is exactly why REST is superior to all kinds of RPC-based APIs. > >> > > > > IMO operational state is a representation of internal device state. > > It may be very implementation-specific how the operational state > > can be edited. > > > > The use-cases where operational state is injected or altered > > are very limited. We already have a solution that works for > > these corner cases (custom RPCs). > > > > Your draft returns config=true nodes in , > > like duplex=auto vs. duplex=full. IMO these corner cases > > do not show up that often, and the old solution of > > separate admin-status and oper-status is good enough. > > Returning config=true nodes in > > requires a new YANG extension and server customization > > to support it. > > > > The validation/constraints/transaction model in NETCONF > > should be limited to config=true nodes. Operational nodes > > change too fast and are too distributed to justify adding > > editing capabilities for config=false nodes. > > Even then operational nodes have to satisfy some constraints that must be > common to all management interfaces and/or protocols that work with the > data, and often constraints on config data also involve operational data. > > Lada > > > > > > Andy > > > >> Lada > >> > >> > > > > Andy > > > > > >> > > >> > > >> >> /martin & lada > >> >> > >> > > >> > > >> > Andy > >> > > >> > > >> >> > >> >> > >> >> > >> >> > >> >> ---------- Forwarded message ---------- > >> >> From: internet-drafts@ietf.org > >> >> To: mbj@tail-f.com > >> >> Cc: lhotka@nic.cz > >> >> Date: Fri, 05 Oct 2012 01:23:30 -0700 > >> >> Subject: New Version Notification for > >> >> draft-bjorklund-netmod-operational-00.txt > >> >> > >> >> A new version of I-D, draft-bjorklund-netmod-operational-00.txt > >> >> has been successfully submitted by Martin Bjorklund and posted to the > >> >> IETF repository. > >> >> > >> >> Filename: draft-bjorklund-netmod-operational > >> >> Revision: 00 > >> >> Title: Operational Data in NETCONF and YANG > >> >> Creation date: 2012-10-05 > >> >> WG ID: Individual Submission > >> >> Number of pages: 21 > >> >> URL: > >> >> > >> > http://www.ietf.org/internet-drafts/draft-bjorklund-netmod-operational-00.txt > >> >> Status: > >> >> http://datatracker.ietf.org/doc/draft-bjorklund-netmod-operational > >> >> Htmlized: > >> >> http://tools.ietf.org/html/draft-bjorklund-netmod-operational-00 > >> >> > >> >> > >> >> Abstract: > >> >> This document defines the concept of operational state data in the > >> >> context of YANG and the Network Configuration Protocol (NETCONF). > It > >> >> updates RFC 6020 with rules for how to model the operational > state, > >> >> and defines NETCONF operations to retrieve and modify the > operational > >> >> state. > >> >> > >> >> > >> >> > >> >> > >> >> The IETF Secretariat > >> >> > >> >> > >> >> _______________________________________________ > >> >> netmod mailing list > >> >> netmod@ietf.org > >> >> https://www.ietf.org/mailman/listinfo/netmod > >> >> > >> >> > >> > _______________________________________________ > >> > netmod mailing list > >> > netmod@ietf.org > >> > https://www.ietf.org/mailman/listinfo/netmod > >> > >> -- > >> Ladislav Lhotka, CZ.NIC Labs > >> PGP Key ID: E74E8C0C > >> _______________________________________________ > >> netmod mailing list > >> netmod@ietf.org > >> https://www.ietf.org/mailman/listinfo/netmod > >> > > _______________________________________________ > > 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 > --20cf3074afe681c73f04cb77d026 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Sat, Oct 6, 2012 at 2:17 AM, Ladislav= Lhotka <lhotka@nic.cz> wrote:
Andy Bierman <andy@yumaworks.com> writes:

> On Fri, Oct 5, 2012 at 8:49 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
>
>> Andy Bierman <andy@yumawo= rks.com> writes:
>>
>> > On Fri, Oct 5, 2012 at 1:28 AM, Martin Bjorklund <mbj@tail-f.com> wrote:
>> >
>> >> Hi,
>> >>
>> >> Lada and I have written a draft where we try to define th= e concept of
>> >> operational state data. =C2=A0There are a couple of open = issues in the
>> >> draft that need to be discussed, so please comment!
>> >>
>> >>
>> > I will just comment on the problem statements in section 3. >> >
>> > 3.1) I don't agree that modeling config and operational d= ata
>> > separately is is real problem, or that it is counter-intuitiv= e
>> > to operators.
>> >
>> > The operational state (e.g., FIB) may come from multiple
>> > parts of the configuration, not just the simple example shown=
>> > in sec. 3.1.1. I do not agree with that example, showing
>> > a separate interface-oper table. =C2=A0That is not needed. >> > Just add a leaf to the interface entry to identify it as '= ;active'.
>>
>> Who is supposed to add such a leaf - the server? And how can the c= lient
>> learn about the existence of inactive interfaces?
>>
>
>
> The data modeler writing the YANG module should add the leaf.

I mean: who is supposed to set the value of the "active" leaf - t= he server or client? But my second question is more important: how does the= client learn about an existing interface that's not in the configurati= on?



I meant the server sets it.
Your problem statement does not men= tion client pre-provisioning of
config data or disabling config d= ata. =C2=A0These are still unsolved problems
in NETCONF.
=C2=A0
=C2=A0
>
>
>>
>
>> This is a contrived example.
>> >
>> > 3.2) =C2=A0I do not agree that operational state needs to be = edited directly
>> > by the client. =C2=A0I actually think the custom RPC approach= in the
>> > example in 3.2.1 is better and more clear within the model. >> > Editing config=3Dfalse nodes is a fundamental change to the >> > NETCONF/YANG architecture and it should not be done.
>>
>> But this is exactly what the IRS and SCIM (and maybe other) folks = are
>> about to do.
>>
>
>
> They haven't decided what to do yet AFAIK.
> IRS hasn't even had a BOF yet, let alone a WG.
> I suspect they will create an API, not a data model
> that is edited like configuration. =C2=A0We don't need
> to change N/Y based on speculation about what IRS WG
> will choose for a solution.
>

This was just examples. The thing is, some applications and devices don'= ;t need the comfort (and overhead) of NETCONF. If I want to temporarily swi= tch off forwarding on a Linux box, I simply set /proc/sys/net/ipv4/ip_forwa= rd to zero.

I don't agree that NETCONF should have= editable state.
You can mess up a Linux system hacking on /proc.=
I do not want to add a hack or a full-blown validation system
for editing config=3Dfalse nodes.


<= div>In your duplex example, let's say it is set to 'auto'
=
and negotiates to 'half'. =C2=A0Then I <edit-operational>= ; the
value to be 'full'.

Now config says &= #39;auto' and state says 'full'.
How does every other= operator know that I did that?
To them it looks like the auto-ne= gotiated value is 'full' but it is not.



While you may argue that creators of new configuration APIs are doomed to r= einvent the NETCONF wheels, I don't think it always has to be the case.=
=C2=A0
Our draft is also intended to enable coexistence of NETCONF with other mana= gement interfaces, and the operational state datastore (rather than NETCONF= configuration datastores) is supposed to be the common playground.

>
>
>
>>
>> >
>> > Actions like <add-route> and <delete-route> prope= rly model
>> > the API between client and server, not <edit-operational&g= t;.
>>
>> The means for modelling RPCs are very limited - the semantics has = to be
>> told in prose.
>> This is exactly why REST is superior to all kinds of RPC-based API= s.
>>
>
> IMO operational state is a representation of internal device state. > It may be very implementation-specific how the operational state
> can be edited.
>
> The use-cases where operational state is injected or altered
> are very limited. =C2=A0We already have a solution that works for
> these corner cases (custom RPCs).
>
> Your draft returns config=3Dtrue nodes in <get-operational>,
> like duplex=3Dauto vs. duplex=3Dfull. =C2=A0IMO these corner cases
> do not show up that often, and the old solution of
> separate admin-status and oper-status is good enough.
> Returning config=3Dtrue nodes in <get-operational>
> requires a new YANG extension and server customization
> to support it.
>
> The validation/constraints/transaction model in NETCONF
> should be limited to config=3Dtrue nodes. =C2=A0Operational nodes
> change too fast and are too distributed to justify adding
> editing capabilities for config=3Dfalse nodes.

Even then operational nodes have to satisfy some constraints that must be c= ommon to all management interfaces and/or protocols that work with the data= , and often constraints on config data also involve operational data.

Lada

>
>

Andy

=C2= =A0
>
>> Lada
>>
>>
>
> Andy
>
>
>> >
>> >
>> >> /martin & lada
>> >>
>> >
>> >
>> > Andy
>> >
>> >
>> >>
>> >>
>> >>
>> >>
>> >> ---------- Forwarded message ----------
>> >> From: interne= t-drafts@ietf.org
>> >> To: mbj@tail-f.com<= br> >> >> Cc: lhotka@nic.cz >> >> Date: Fri, 05 Oct 2012 01:23:30 -0700
>> >> Subject: New Version Notification for
>> >> draft-bjorklund-netmod-operational-00.txt
>> >>
>> >> A new version of I-D, draft-bjorklund-netmod-operational-= 00.txt
>> >> has been successfully submitted by Martin Bjorklund and p= osted to the
>> >> IETF repository.
>> >>
>> >> Filename: =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-bjorklund-netm= od-operational
>> >> Revision: =C2=A0 =C2=A0 =C2=A0 =C2=A000
>> >> Title: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Operational Dat= a in NETCONF and YANG
>> >> Creation date: =C2=A0 2012-10-05
>> >> WG ID: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Subm= ission
>> >> Number of pages: 21
>> >> URL:
>> >>
>> http://www.ietf.org/internet-draf= ts/draft-bjorklund-netmod-operational-00.txt
>> >> Status:
>> >> http://datatracker.ietf.org/doc/dra= ft-bjorklund-netmod-operational
>> >> Htmlized:
>> >> http://tools.ietf.org/html/draft-bjor= klund-netmod-operational-00
>> >>
>> >>
>> >> Abstract:
>> >> =C2=A0 =C2=A0This document defines the concept of operati= onal state data in the
>> >> =C2=A0 =C2=A0context of YANG and the Network Configuratio= n Protocol (NETCONF). =C2=A0It
>> >> =C2=A0 =C2=A0updates RFC 6020 with rules for how to model= the operational state,
>> >> =C2=A0 =C2=A0and defines NETCONF operations to retrieve a= nd modify the operational
>> >> =C2=A0 =C2=A0state.
>> >>
>> >>
>> >>
>> >>
>> >> The IETF Secretariat
>> >>
>> >>
>> >> _______________________________________________
>> >> netmod mailing list
>> >> netmod@ietf.org >> >> https://www.ietf.org/mailman/listinfo/netmod
>> >>
>> >>
>> > _______________________________________________
>> > netmod mailing list
>> > netmod@ietf.org
>> > https://www.ietf.org/mailman/listinfo/netmod
>>
>> --
>> Ladislav Lhotka, CZ.NIC Labs
>> PGP Key ID: E74E8C0C
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>>
> _______________________________________________
> 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

--20cf3074afe681c73f04cb77d026-- From mbj@tail-f.com Sun Oct 7 12:45: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 195AB21F870A for ; Sun, 7 Oct 2012 12:45:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.994 X-Spam-Level: X-Spam-Status: No, score=-1.994 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ksYZ8K7BTE6d for ; Sun, 7 Oct 2012 12:45:20 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 759A821F8705 for ; Sun, 7 Oct 2012 12:45:20 -0700 (PDT) Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 54A331200D2E; Sun, 7 Oct 2012 21:45:18 +0200 (CEST) Date: Sun, 07 Oct 2012 21:45:18 +0200 (CEST) Message-Id: <20121007.214518.455276563.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: <20121005.102805.519929541.mbj@tail-f.com> X-Mailer: Mew version 6.4 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] Fw: New Version Notification for draft-bjorklund-netmod-operational-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: Sun, 07 Oct 2012 19:45:21 -0000 Hi Andy, Andy Bierman wrote: > I will just comment on the problem statements in section 3. > > 3.1) I don't agree that modeling config and operational data > separately is is real problem We have this problem for interfaces, ip, and routing. If this is not a problem, maybe you can suggest a solution for these drafts? For example, in interface, there is no way to report status for interfaces that are not configured by the operator, since these config false nodes are defined in a config true list. It seems you are saying that data model duplication is not a problem, so I assume your proposal is to have two separate top-level containers, the current "interfaces" and a new one "interfaces-state" or something? And then two separate "interface" lists, one in each container? Is this correct? > or that it is counter-intuitive > to operators. It is counter-intuitive to data model designers. For example, the ipfix module mixes config false under config true nodes. /martin From andy@yumaworks.com Sun Oct 7 13:28: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 E63F621F860B for ; Sun, 7 Oct 2012 13:28:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.441 X-Spam-Level: X-Spam-Status: No, score=-2.441 tagged_above=-999 required=5 tests=[AWL=-0.065, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wyv2eTFQ5n9y for ; Sun, 7 Oct 2012 13:28:25 -0700 (PDT) Received: from mail-qc0-f182.google.com (mail-qc0-f182.google.com [209.85.216.182]) by ietfa.amsl.com (Postfix) with ESMTP id 1366721F8594 for ; Sun, 7 Oct 2012 13:28:24 -0700 (PDT) Received: by mail-qc0-f182.google.com with SMTP id l39so3386076qcs.27 for ; Sun, 07 Oct 2012 13:28:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=EhF+r6cWIRbu728TSF741djg146A2bT+098THcLUXMg=; b=cVkBjGhuyQ54erFjjNu8Of1jmUMu3gKKAQjgq+ErGtYuJNHwcynPtNudX9EPtm4R6o hPgksKqvK+T8xrQWwj0e7dsXA67SzMONcOMJ/8B3F5hN2iqdZAlbap/TgIx2tk81QQ4v wqSf4Ba4CrscsHbUIfhCnVkFiWNUBlAP+7cHdYiIArFp6maZH/w/iSIfJB7QWWMJRNgq gzmiddhhGXXsIt0i0SNuObyDPibm2sIRbaR5SXovoiirgSTaBexA+gwj2Aiv6h/7+KJ9 JeynamDUyOXF5P5eYcbkz/TSRi8gjK6SG55kXz/9iHLKJt6MOkM0jSESDjbRDcZhPP/R ZIYw== MIME-Version: 1.0 Received: by 10.224.199.2 with SMTP id eq2mr26787414qab.55.1349641704318; Sun, 07 Oct 2012 13:28:24 -0700 (PDT) Received: by 10.49.127.52 with HTTP; Sun, 7 Oct 2012 13:28:24 -0700 (PDT) In-Reply-To: <20121007.214518.455276563.mbj@tail-f.com> References: <20121005.102805.519929541.mbj@tail-f.com> <20121007.214518.455276563.mbj@tail-f.com> Date: Sun, 7 Oct 2012 13:28:24 -0700 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: multipart/alternative; boundary=20cf300fb1555c281304cb7df225 X-Gm-Message-State: ALoCoQkLsIQ1yZEmKQkU27Kev4DazBHBbHoHJWhtE7SMGq3oWtUYTVSswDy22qZrrFxHH+T98xm1 Cc: netmod@ietf.org Subject: Re: [netmod] Fw: New Version Notification for draft-bjorklund-netmod-operational-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: Sun, 07 Oct 2012 20:28:26 -0000 --20cf300fb1555c281304cb7df225 Content-Type: text/plain; charset=UTF-8 On Sun, Oct 7, 2012 at 12:45 PM, Martin Bjorklund wrote: > Hi Andy, > > Andy Bierman wrote: > > I will just comment on the problem statements in section 3. > > > > 3.1) I don't agree that modeling config and operational data > > separately is is real problem > > We have this problem for interfaces, ip, and routing. If this is not > a problem, maybe you can suggest a solution for these drafts? > > I think the server knows if a config entry is pre-provisioned, disabled, or active, etc.. This is built into the implementation. I like the idea of a meta-data tag (XML attribute) to identify the config-state, to be used as a sub-filter on config=true, and returned by the operation, like with-timestamps. e.g.: // get only the disabled config in running db disabled // get all the config-state tags in running db For example, in interface, there is no way to report status for > interfaces that are not configured by the operator, since these config > false nodes are defined in a config true list. It seems you are > saying that data model duplication is not a problem, so I assume your > proposal is to have two separate top-level containers, the current > "interfaces" and a new one "interfaces-state" or something? And then > two separate "interface" lists, one in each container? Is this > correct? > > > or that it is counter-intuitive > > to operators. > > It is counter-intuitive to data model designers. For example, the > ipfix module mixes config false under config true nodes. > > So? This is fine if the counters only exist under a list subtree when that list instance exists. I don't agree that some config for an interface that is not present is somehow operational state. It is config is the 'pre-provision' or 'disabled' state. > > /martin > Andy --20cf300fb1555c281304cb7df225 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Sun, Oct 7, 2012 at 12:45 PM, Martin = Bjorklund <mbj@tail-f.com> wrote:
Hi Andy,

Andy Bierman <andy@yumaworks.com> wrote:
> I will just comment on the problem statements in section 3.
>
> 3.1) I don't agree that modeling config and operational data
> separately is is real problem

We have this problem for interfaces, ip, and routing. =C2=A0If this is not<= br> a problem, maybe you can suggest a solution for these drafts?



the config-state, to be used as a sub-filter on config=3Dtrue,
and returned by the <get2> operation, like with-timestamps.
<= div>e.g.:

=C2=A0 <get2>
=C2=A0 =C2=A0 =C2=A0<config-state>= disabled</config-state>
=C2=A0 </get2>

=
=C2=A0 // get all the config-state tags in running db
=
=C2=A0 <get2>
=C2=A0 =C2=A0 =C2=A0<with-config-state />
=C2=A0 </get2&= gt;


For example, in interface, there is no way to report status for
interfaces that are not configured by the operator, since these config
false nodes are defined in a config true list. =C2=A0It seems you are
saying that data model duplication is not a problem, so I assume your
proposal is to have two separate top-level containers, the current
"interfaces" and a new one "interfaces-state" or someth= ing? =C2=A0And then
two separate "interface" lists, one in each container? =C2=A0Is t= his
correct?

> or that it is counter-intuitive
> to operators.

It is counter-intuitive to data model designers. =C2=A0For example, the
ipfix module mixes config false under config true nodes.


So? =C2=A0This is fine if the counters only exist un= der a list subtree
when that list instance exists. =C2=A0I don= 9;t agree that some config
for an interface that is not present is somehow operational state.
It is config is the 'pre-provision' or 'disabled' st= ate.

=C2=A0

/martin


Andy
--20cf300fb1555c281304cb7df225-- From mbj@tail-f.com Mon Oct 8 01:33: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 83CAD21F8694 for ; Mon, 8 Oct 2012 01:33:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.027 X-Spam-Level: X-Spam-Status: No, score=-2.027 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GCBZ5RSr8+OJ for ; Mon, 8 Oct 2012 01:33:43 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 7716321F8551 for ; Mon, 8 Oct 2012 01:33:43 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 960961200D92; Mon, 8 Oct 2012 10:33:41 +0200 (CEST) Date: Mon, 08 Oct 2012 10:33:41 +0200 (CEST) Message-Id: <20121008.103341.137047970843535797.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: <20121007.214518.455276563.mbj@tail-f.com> X-Mailer: Mew version 6.4 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] Fw: New Version Notification for draft-bjorklund-netmod-operational-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, 08 Oct 2012 08:33:44 -0000 Andy Bierman wrote: > On Sun, Oct 7, 2012 at 12:45 PM, Martin Bjorklund wrote: > > > Hi Andy, > > > > Andy Bierman wrote: > > > I will just comment on the problem statements in section 3. > > > > > > 3.1) I don't agree that modeling config and operational data > > > separately is is real problem > > > > We have this problem for interfaces, ip, and routing. If this is not > > a problem, maybe you can suggest a solution for these drafts? > > > > > I think the server knows if a config entry is pre-provisioned, > disabled, or active, etc.. This is built into the implementation. The problem is not the server, but the client. pre-provisioning can be dealt with if the data model designer thought about it. For example, the data model designer can add a "operational-status" leaf for objects that he believes can be pre-provisioned. This way, the client can learn which things are configured, but not in operational use. But this only works if the data model designer was clever enough to realize this need in advance. However, this approach does not work if there are objects that appears operationally but are not (yet) configured. It seems you are suggesting that you have a solution to this, so could you please answer my question below: > > For example, in interface, there is no way to report status for > > interfaces that are not configured by the operator, since these config > > false nodes are defined in a config true list. It seems you are > > saying that data model duplication is not a problem, so I assume your > > proposal is to have two separate top-level containers, the current > > "interfaces" and a new one "interfaces-state" or something? And then > > two separate "interface" lists, one in each container? Is this > > correct? /martin From lhotka@nic.cz Mon Oct 8 02:11:26 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 A5C0C21F8773 for ; Mon, 8 Oct 2012 02:11:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.293 X-Spam-Level: X-Spam-Status: No, score=-1.293 tagged_above=-999 required=5 tests=[AWL=-0.494, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nCLnP4rnO4M3 for ; Mon, 8 Oct 2012 02:11:25 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 7D6B721F8705 for ; Mon, 8 Oct 2012 02:11:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 20E45540457 for ; Mon, 8 Oct 2012 11:11: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 vuO4wzw0Xc0g for ; Mon, 8 Oct 2012 11:11:10 +0200 (CEST) Received: from localhost (unknown [10.107.191.189]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id C6EEB54012C for ; Mon, 8 Oct 2012 11:11:06 +0200 (CEST) From: Ladislav Lhotka To: netmod@ietf.org In-Reply-To: References: <20121005.102805.519929541.mbj@tail-f.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, 08 Oct 2012 11:10:45 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [netmod] Fw: New Version Notification for draft-bjorklund-netmod-operational-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, 08 Oct 2012 09:11:26 -0000 Andy Bierman writes: > On Sat, Oct 6, 2012 at 2:17 AM, Ladislav Lhotka wrote: > >> Andy Bierman writes: >> >> > On Fri, Oct 5, 2012 at 8:49 AM, Ladislav Lhotka wrote: >> > >> >> Andy Bierman writes: >> >> >> >> > On Fri, Oct 5, 2012 at 1:28 AM, Martin Bjorklund >> wrote: >> >> > >> >> >> Hi, >> >> >> >> >> >> Lada and I have written a draft where we try to define the concept of >> >> >> operational state data. There are a couple of open issues in the >> >> >> draft that need to be discussed, so please comment! >> >> >> >> >> >> >> >> > I will just comment on the problem statements in section 3. >> >> > >> >> > 3.1) I don't agree that modeling config and operational data >> >> > separately is is real problem, or that it is counter-intuitive >> >> > to operators. >> >> > >> >> > The operational state (e.g., FIB) may come from multiple >> >> > parts of the configuration, not just the simple example shown >> >> > in sec. 3.1.1. I do not agree with that example, showing >> >> > a separate interface-oper table. That is not needed. >> >> > Just add a leaf to the interface entry to identify it as 'active'. >> >> >> >> Who is supposed to add such a leaf - the server? And how can the client >> >> learn about the existence of inactive interfaces? >> >> >> > >> > >> > The data modeler writing the YANG module should add the leaf. >> >> I mean: who is supposed to set the value of the "active" leaf - the server >> or client? But my second question is more important: how does the client >> learn about an existing interface that's not in the configuration? >> >> > > I meant the server sets it. The concept of the server writing something to the configuration is not supported by the existing specs and IMO it is a non-starter. So you should write a draft defining the rules for this. In our draft, configuration contains only stuff explicitly written by client(s). The server writes the data about pre-provisioned object to the operational state datastore. Lada > Your problem statement does not mention client pre-provisioning of > config data or disabling config data. These are still unsolved problems > in NETCONF. > > > >> > >> > >> >> >> > >> >> This is a contrived example. >> >> > >> >> > 3.2) I do not agree that operational state needs to be edited >> directly >> >> > by the client. I actually think the custom RPC approach in the >> >> > example in 3.2.1 is better and more clear within the model. >> >> > Editing config=false nodes is a fundamental change to the >> >> > NETCONF/YANG architecture and it should not be done. >> >> >> >> But this is exactly what the IRS and SCIM (and maybe other) folks are >> >> about to do. >> >> >> > >> > >> > They haven't decided what to do yet AFAIK. >> > IRS hasn't even had a BOF yet, let alone a WG. >> > I suspect they will create an API, not a data model >> > that is edited like configuration. We don't need >> > to change N/Y based on speculation about what IRS WG >> > will choose for a solution. >> > >> >> This was just examples. The thing is, some applications and devices don't >> need the comfort (and overhead) of NETCONF. If I want to temporarily switch >> off forwarding on a Linux box, I simply set /proc/sys/net/ipv4/ip_forward >> to zero. >> > > I don't agree that NETCONF should have editable state. > You can mess up a Linux system hacking on /proc. > I do not want to add a hack or a full-blown validation system > for editing config=false nodes. > > > In your duplex example, let's say it is set to 'auto' > and negotiates to 'half'. Then I the > value to be 'full'. > > Now config says 'auto' and state says 'full'. > How does every other operator know that I did that? > To them it looks like the auto-negotiated value is 'full' but it is not. > > > >> While you may argue that creators of new configuration APIs are doomed to >> reinvent the NETCONF wheels, I don't think it always has to be the case. >> >> Our draft is also intended to enable coexistence of NETCONF with other >> management interfaces, and the operational state datastore (rather than >> NETCONF configuration datastores) is supposed to be the common playground. >> >> > >> > >> > >> >> >> >> > >> >> > Actions like and properly model >> >> > the API between client and server, not . >> >> >> >> The means for modelling RPCs are very limited - the semantics has to be >> >> told in prose. >> >> This is exactly why REST is superior to all kinds of RPC-based APIs. >> >> >> > >> > IMO operational state is a representation of internal device state. >> > It may be very implementation-specific how the operational state >> > can be edited. >> > >> > The use-cases where operational state is injected or altered >> > are very limited. We already have a solution that works for >> > these corner cases (custom RPCs). >> > >> > Your draft returns config=true nodes in , >> > like duplex=auto vs. duplex=full. IMO these corner cases >> > do not show up that often, and the old solution of >> > separate admin-status and oper-status is good enough. >> > Returning config=true nodes in >> > requires a new YANG extension and server customization >> > to support it. >> > >> > The validation/constraints/transaction model in NETCONF >> > should be limited to config=true nodes. Operational nodes >> > change too fast and are too distributed to justify adding >> > editing capabilities for config=false nodes. >> >> Even then operational nodes have to satisfy some constraints that must be >> common to all management interfaces and/or protocols that work with the >> data, and often constraints on config data also involve operational data. >> >> Lada >> >> > >> > >> > > Andy > > > >> > >> >> Lada >> >> >> >> >> > >> > Andy >> > >> > >> >> > >> >> > >> >> >> /martin & lada >> >> >> >> >> > >> >> > >> >> > Andy >> >> > >> >> > >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> ---------- Forwarded message ---------- >> >> >> From: internet-drafts@ietf.org >> >> >> To: mbj@tail-f.com >> >> >> Cc: lhotka@nic.cz >> >> >> Date: Fri, 05 Oct 2012 01:23:30 -0700 >> >> >> Subject: New Version Notification for >> >> >> draft-bjorklund-netmod-operational-00.txt >> >> >> >> >> >> A new version of I-D, draft-bjorklund-netmod-operational-00.txt >> >> >> has been successfully submitted by Martin Bjorklund and posted to the >> >> >> IETF repository. >> >> >> >> >> >> Filename: draft-bjorklund-netmod-operational >> >> >> Revision: 00 >> >> >> Title: Operational Data in NETCONF and YANG >> >> >> Creation date: 2012-10-05 >> >> >> WG ID: Individual Submission >> >> >> Number of pages: 21 >> >> >> URL: >> >> >> >> >> >> http://www.ietf.org/internet-drafts/draft-bjorklund-netmod-operational-00.txt >> >> >> Status: >> >> >> http://datatracker.ietf.org/doc/draft-bjorklund-netmod-operational >> >> >> Htmlized: >> >> >> http://tools.ietf.org/html/draft-bjorklund-netmod-operational-00 >> >> >> >> >> >> >> >> >> Abstract: >> >> >> This document defines the concept of operational state data in the >> >> >> context of YANG and the Network Configuration Protocol (NETCONF). >> It >> >> >> updates RFC 6020 with rules for how to model the operational >> state, >> >> >> and defines NETCONF operations to retrieve and modify the >> operational >> >> >> state. >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> The IETF Secretariat >> >> >> >> >> >> >> >> >> _______________________________________________ >> >> >> netmod mailing list >> >> >> netmod@ietf.org >> >> >> https://www.ietf.org/mailman/listinfo/netmod >> >> >> >> >> >> >> >> > _______________________________________________ >> >> > netmod mailing list >> >> > netmod@ietf.org >> >> > https://www.ietf.org/mailman/listinfo/netmod >> >> >> >> -- >> >> Ladislav Lhotka, CZ.NIC Labs >> >> PGP Key ID: E74E8C0C >> >> _______________________________________________ >> >> netmod mailing list >> >> netmod@ietf.org >> >> https://www.ietf.org/mailman/listinfo/netmod >> >> >> > _______________________________________________ >> > 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 >> > _______________________________________________ > 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 Mon Oct 8 02:53: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 5BD8121F8551 for ; Mon, 8 Oct 2012 02:53:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.84 X-Spam-Level: X-Spam-Status: No, score=-1.84 tagged_above=-999 required=5 tests=[AWL=-0.664, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OEg6qJ11rID6 for ; Mon, 8 Oct 2012 02:53:23 -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 9209021F8701 for ; Mon, 8 Oct 2012 02:53:23 -0700 (PDT) Received: by mail-qc0-f172.google.com with SMTP id c10so3170061qca.31 for ; Mon, 08 Oct 2012 02:53:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=mxbitfpkZZfB3mdb41V80vqWnkakDnFBdAX8IBHqcSo=; b=Z12c0PCpDmdOOzbwerJNwbeKVMgVpH0LaUjX+H+l3By+rjotLDPywPTA2N7UbwB8x5 h6qt9JCdWRAytNp641lKc6X0ggNk2ceDLsa2BYxZ6xlepwg/C6lXEnmNbLco2V6VS3HW 7suq0x08AuhADJP6WxlDtVRisyrFqcNS+cypk9e+gLkeO6rwZp47Ms/cn6Zx4g/UlITq U+904A9t2yKK+Fmf+KToTl8Xz+u3FBIz1UyV3PlkoczK3ziQtTEyB+DfEM8w94DZwgxn 0MXL7v8LkEbDKZBnxzKFw1p64CgTCuv/V6fLBsyr3LIvYfq/v1CU8qpHS/r1gvQG7WBG R8lg== MIME-Version: 1.0 Received: by 10.224.100.200 with SMTP id z8mr28868581qan.75.1349690002846; Mon, 08 Oct 2012 02:53:22 -0700 (PDT) Received: by 10.49.127.52 with HTTP; Mon, 8 Oct 2012 02:53:22 -0700 (PDT) In-Reply-To: References: <20121005.102805.519929541.mbj@tail-f.com> Date: Mon, 8 Oct 2012 02:53:22 -0700 Message-ID: From: Andy Bierman To: netmod@ietf.org Content-Type: multipart/alternative; boundary=20cf3074afe62d338b04cb89318e X-Gm-Message-State: ALoCoQlraFTMr+G+JfsPOtb7qXDa7vehFMDDTpZ7OYTvjZ5hfQ6HqGj8RB4S8IYs2qrNPrFBWsI4 Subject: Re: [netmod] Fw: New Version Notification for draft-bjorklund-netmod-operational-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, 08 Oct 2012 09:53:25 -0000 --20cf3074afe62d338b04cb89318e Content-Type: text/plain; charset=UTF-8 On Mon, Oct 8, 2012 at 2:10 AM, Ladislav Lhotka wrote: > Andy Bierman writes: > > > On Sat, Oct 6, 2012 at 2:17 AM, Ladislav Lhotka wrote: > > > >> Andy Bierman writes: > >> > >> > On Fri, Oct 5, 2012 at 8:49 AM, Ladislav Lhotka > wrote: > >> > > >> >> Andy Bierman writes: > >> >> > >> >> > On Fri, Oct 5, 2012 at 1:28 AM, Martin Bjorklund > >> wrote: > >> >> > > >> >> >> Hi, > >> >> >> > >> >> >> Lada and I have written a draft where we try to define the > concept of > >> >> >> operational state data. There are a couple of open issues in the > >> >> >> draft that need to be discussed, so please comment! > >> >> >> > >> >> >> > >> >> > I will just comment on the problem statements in section 3. > >> >> > > >> >> > 3.1) I don't agree that modeling config and operational data > >> >> > separately is is real problem, or that it is counter-intuitive > >> >> > to operators. > >> >> > > >> >> > The operational state (e.g., FIB) may come from multiple > >> >> > parts of the configuration, not just the simple example shown > >> >> > in sec. 3.1.1. I do not agree with that example, showing > >> >> > a separate interface-oper table. That is not needed. > >> >> > Just add a leaf to the interface entry to identify it as 'active'. > >> >> > >> >> Who is supposed to add such a leaf - the server? And how can the > client > >> >> learn about the existence of inactive interfaces? > >> >> > >> > > >> > > >> > The data modeler writing the YANG module should add the leaf. > >> > >> I mean: who is supposed to set the value of the "active" leaf - the > server > >> or client? But my second question is more important: how does the client > >> learn about an existing interface that's not in the configuration? > >> > >> > > > > I meant the server sets it. > > The concept of the server writing something to the configuration is not > supported by the existing specs and IMO it is a non-starter. So you should > write a draft defining the rules for this. > The concept of returning config=true nodes as operational data and the concept of editing config=false nodes does not exist in NETCONF/YANG and it should stay that way. I don't agree with any of your problem statements so of course I don't think we need your solution either. If the WG wants to support pre-provisioned config or disabled config, then a new charter item for that should be proposed. I am not interested in this problem enough to write a draft about it. Client provided config that is not currently in use is not operational state. The client cannot set server operational state. It can perform actions which have side effects that change server operational state. > In our draft, configuration contains only stuff explicitly written by > client(s). The server writes the data about pre-provisioned object to the > operational state datastore. > This is not the way real servers work. There are PHY interfaces and other top level containers that the server will create in the factory default config. > > Lada > > Andy > > Your problem statement does not mention client pre-provisioning of > > config data or disabling config data. These are still unsolved problems > > in NETCONF. > > > > > > > >> > > >> > > >> >> > >> > > >> >> This is a contrived example. > >> >> > > >> >> > 3.2) I do not agree that operational state needs to be edited > >> directly > >> >> > by the client. I actually think the custom RPC approach in the > >> >> > example in 3.2.1 is better and more clear within the model. > >> >> > Editing config=false nodes is a fundamental change to the > >> >> > NETCONF/YANG architecture and it should not be done. > >> >> > >> >> But this is exactly what the IRS and SCIM (and maybe other) folks are > >> >> about to do. > >> >> > >> > > >> > > >> > They haven't decided what to do yet AFAIK. > >> > IRS hasn't even had a BOF yet, let alone a WG. > >> > I suspect they will create an API, not a data model > >> > that is edited like configuration. We don't need > >> > to change N/Y based on speculation about what IRS WG > >> > will choose for a solution. > >> > > >> > >> This was just examples. The thing is, some applications and devices > don't > >> need the comfort (and overhead) of NETCONF. If I want to temporarily > switch > >> off forwarding on a Linux box, I simply set > /proc/sys/net/ipv4/ip_forward > >> to zero. > >> > > > > I don't agree that NETCONF should have editable state. > > You can mess up a Linux system hacking on /proc. > > I do not want to add a hack or a full-blown validation system > > for editing config=false nodes. > > > > > > In your duplex example, let's say it is set to 'auto' > > and negotiates to 'half'. Then I the > > value to be 'full'. > > > > Now config says 'auto' and state says 'full'. > > How does every other operator know that I did that? > > To them it looks like the auto-negotiated value is 'full' but it is not. > > > > > > > >> While you may argue that creators of new configuration APIs are doomed > to > >> reinvent the NETCONF wheels, I don't think it always has to be the case. > >> > >> Our draft is also intended to enable coexistence of NETCONF with other > >> management interfaces, and the operational state datastore (rather than > >> NETCONF configuration datastores) is supposed to be the common > playground. > >> > >> > > >> > > >> > > >> >> > >> >> > > >> >> > Actions like and properly model > >> >> > the API between client and server, not . > >> >> > >> >> The means for modelling RPCs are very limited - the semantics has to > be > >> >> told in prose. > >> >> This is exactly why REST is superior to all kinds of RPC-based APIs. > >> >> > >> > > >> > IMO operational state is a representation of internal device state. > >> > It may be very implementation-specific how the operational state > >> > can be edited. > >> > > >> > The use-cases where operational state is injected or altered > >> > are very limited. We already have a solution that works for > >> > these corner cases (custom RPCs). > >> > > >> > Your draft returns config=true nodes in , > >> > like duplex=auto vs. duplex=full. IMO these corner cases > >> > do not show up that often, and the old solution of > >> > separate admin-status and oper-status is good enough. > >> > Returning config=true nodes in > >> > requires a new YANG extension and server customization > >> > to support it. > >> > > >> > The validation/constraints/transaction model in NETCONF > >> > should be limited to config=true nodes. Operational nodes > >> > change too fast and are too distributed to justify adding > >> > editing capabilities for config=false nodes. > >> > >> Even then operational nodes have to satisfy some constraints that must > be > >> common to all management interfaces and/or protocols that work with the > >> data, and often constraints on config data also involve operational > data. > >> > >> Lada > >> > >> > > >> > > >> > > > > Andy > > > > > > > >> > > >> >> Lada > >> >> > >> >> > >> > > >> > Andy > >> > > >> > > >> >> > > >> >> > > >> >> >> /martin & lada > >> >> >> > >> >> > > >> >> > > >> >> > Andy > >> >> > > >> >> > > >> >> >> > >> >> >> > >> >> >> > >> >> >> > >> >> >> ---------- Forwarded message ---------- > >> >> >> From: internet-drafts@ietf.org > >> >> >> To: mbj@tail-f.com > >> >> >> Cc: lhotka@nic.cz > >> >> >> Date: Fri, 05 Oct 2012 01:23:30 -0700 > >> >> >> Subject: New Version Notification for > >> >> >> draft-bjorklund-netmod-operational-00.txt > >> >> >> > >> >> >> A new version of I-D, draft-bjorklund-netmod-operational-00.txt > >> >> >> has been successfully submitted by Martin Bjorklund and posted to > the > >> >> >> IETF repository. > >> >> >> > >> >> >> Filename: draft-bjorklund-netmod-operational > >> >> >> Revision: 00 > >> >> >> Title: Operational Data in NETCONF and YANG > >> >> >> Creation date: 2012-10-05 > >> >> >> WG ID: Individual Submission > >> >> >> Number of pages: 21 > >> >> >> URL: > >> >> >> > >> >> > >> > http://www.ietf.org/internet-drafts/draft-bjorklund-netmod-operational-00.txt > >> >> >> Status: > >> >> >> > http://datatracker.ietf.org/doc/draft-bjorklund-netmod-operational > >> >> >> Htmlized: > >> >> >> http://tools.ietf.org/html/draft-bjorklund-netmod-operational-00 > >> >> >> > >> >> >> > >> >> >> Abstract: > >> >> >> This document defines the concept of operational state data in > the > >> >> >> context of YANG and the Network Configuration Protocol > (NETCONF). > >> It > >> >> >> updates RFC 6020 with rules for how to model the operational > >> state, > >> >> >> and defines NETCONF operations to retrieve and modify the > >> operational > >> >> >> state. > >> >> >> > >> >> >> > >> >> >> > >> >> >> > >> >> >> The IETF Secretariat > >> >> >> > >> >> >> > >> >> >> _______________________________________________ > >> >> >> netmod mailing list > >> >> >> netmod@ietf.org > >> >> >> https://www.ietf.org/mailman/listinfo/netmod > >> >> >> > >> >> >> > >> >> > _______________________________________________ > >> >> > netmod mailing list > >> >> > netmod@ietf.org > >> >> > https://www.ietf.org/mailman/listinfo/netmod > >> >> > >> >> -- > >> >> Ladislav Lhotka, CZ.NIC Labs > >> >> PGP Key ID: E74E8C0C > >> >> _______________________________________________ > >> >> netmod mailing list > >> >> netmod@ietf.org > >> >> https://www.ietf.org/mailman/listinfo/netmod > >> >> > >> > _______________________________________________ > >> > 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 > >> > > _______________________________________________ > > 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 > --20cf3074afe62d338b04cb89318e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Mon, Oct 8, 2012 at 2:10 AM, Ladislav= Lhotka <lhotka@nic.cz> wrote:
Andy Bierman <andy@yumaworks.com> writes:

> On Sat, Oct 6, 2012 at 2:17 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
>
>> Andy Bierman <andy@yumawo= rks.com> writes:
>>
>> > On Fri, Oct 5, 2012 at 8:49 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
>> >
>> >> Andy Bierman <an= dy@yumaworks.com> writes:
>> >>
>> >> > On Fri, Oct 5, 2012 at 1:28 AM, Martin Bjorklund <= ;mbj@tail-f.com>
>> wrote:
>> >> >
>> >> >> Hi,
>> >> >>
>> >> >> Lada and I have written a draft where we try to = define the concept of
>> >> >> operational state data. =C2=A0There are a couple= of open issues in the
>> >> >> draft that need to be discussed, so please comme= nt!
>> >> >>
>> >> >>
>> >> > I will just comment on the problem statements in sec= tion 3.
>> >> >
>> >> > 3.1) I don't agree that modeling config and oper= ational data
>> >> > separately is is real problem, or that it is counter= -intuitive
>> >> > to operators.
>> >> >
>> >> > The operational state (e.g., FIB) may come from mult= iple
>> >> > parts of the configuration, not just the simple exam= ple shown
>> >> > in sec. 3.1.1. I do not agree with that example, sho= wing
>> >> > a separate interface-oper table. =C2=A0That is not n= eeded.
>> >> > Just add a leaf to the interface entry to identify i= t as 'active'.
>> >>
>> >> Who is supposed to add such a leaf - the server? And how = can the client
>> >> learn about the existence of inactive interfaces?
>> >>
>> >
>> >
>> > The data modeler writing the YANG module should add the leaf.=
>>
>> I mean: who is supposed to set the value of the "active"= leaf - the server
>> or client? But my second question is more important: how does the = client
>> learn about an existing interface that's not in the configurat= ion?
>>
>>
>
> I meant the server sets it.

The concept of the server writing something to the configuration is not sup= ported by the existing specs and IMO it is a non-starter. So you should wri= te a draft defining the rules for this.

The concept of returning config=3Dtrue nodes as operational data and t= he concept of
editing config=3Dfalse nodes does not exist in NETC= ONF/YANG and it should stay that way.
I don't agree with any = of your problem statements so of course I don't think
we need your solution either.

If the WG wants= to support pre-provisioned config or disabled config,
then a new= charter item for that should be proposed. =C2=A0I am not interested
<= div> in this problem enough to write a draft about it.

= Client provided config that is not currently in use is not operational stat= e.

The client cannot set server operational state.= =C2=A0It can perform actions
which have side effects that change server operational state.



In our draft, configuration contains only stuff explicitly written by clien= t(s). The server writes the data about pre-provisioned object to the operat= ional state datastore.

This is not the = way real servers work.
There are PHY interfaces and other top level containers that
the server will create in the factory default config.

=
=C2=A0

Lada



Andy



=C2=A0
> Your problem statement does not mention client pre-provisioning of
> config data or disabling config data. =C2=A0These are still unsolved p= roblems
> in NETCONF.
>
>
>
>> >
>> >
>> >>
>> >
>> >> This is a contrived example.
>> >> >
>> >> > 3.2) =C2=A0I do not agree that operational state nee= ds to be edited
>> directly
>> >> > by the client. =C2=A0I actually think the custom RPC= approach in the
>> >> > example in 3.2.1 is better and more clear within the= model.
>> >> > Editing config=3Dfalse nodes is a fundamental change= to the
>> >> > NETCONF/YANG architecture and it should not be done.=
>> >>
>> >> But this is exactly what the IRS and SCIM (and maybe othe= r) folks are
>> >> about to do.
>> >>
>> >
>> >
>> > They haven't decided what to do yet AFAIK.
>> > IRS hasn't even had a BOF yet, let alone a WG.
>> > I suspect they will create an API, not a data model
>> > that is edited like configuration. =C2=A0We don't need >> > to change N/Y based on speculation about what IRS WG
>> > will choose for a solution.
>> >
>>
>> This was just examples. The thing is, some applications and device= s don't
>> need the comfort (and overhead) of NETCONF. If I want to temporari= ly switch
>> off forwarding on a Linux box, I simply set /proc/sys/net/ipv4/ip_= forward
>> to zero.
>>
>
> I don't agree that NETCONF should have editable state.
> You can mess up a Linux system hacking on /proc.
> I do not want to add a hack or a full-blown validation system
> for editing config=3Dfalse nodes.
>
>
> In your duplex example, let's say it is set to 'auto'
> and negotiates to 'half'. =C2=A0Then I <edit-operational>= ; the
> value to be 'full'.
>
> Now config says 'auto' and state says 'full'.
> How does every other operator know that I did that?
> To them it looks like the auto-negotiated value is 'full' but = it is not.
>
>
>
>> While you may argue that creators of new configuration APIs are do= omed to
>> reinvent the NETCONF wheels, I don't think it always has to be= the case.
>>
>> Our draft is also intended to enable coexistence of NETCONF with o= ther
>> management interfaces, and the operational state datastore (rather= than
>> NETCONF configuration datastores) is supposed to be the common pla= yground.
>>
>> >
>> >
>> >
>> >>
>> >> >
>> >> > Actions like <add-route> and <delete-route&= gt; properly model
>> >> > the API between client and server, not <edit-oper= ational>.
>> >>
>> >> The means for modelling RPCs are very limited - the seman= tics has to be
>> >> told in prose.
>> >> This is exactly why REST is superior to all kinds of RPC-= based APIs.
>> >>
>> >
>> > IMO operational state is a representation of internal device = state.
>> > It may be very implementation-specific how the operational st= ate
>> > can be edited.
>> >
>> > The use-cases where operational state is injected or altered<= br> >> > are very limited. =C2=A0We already have a solution that works= for
>> > these corner cases (custom RPCs).
>> >
>> > Your draft returns config=3Dtrue nodes in <get-operational= >,
>> > like duplex=3Dauto vs. duplex=3Dfull. =C2=A0IMO these corner = cases
>> > do not show up that often, and the old solution of
>> > separate admin-status and oper-status is good enough.
>> > Returning config=3Dtrue nodes in <get-operational>
>> > requires a new YANG extension and server customization
>> > to support it.
>> >
>> > The validation/constraints/transaction model in NETCONF
>> > should be limited to config=3Dtrue nodes. =C2=A0Operational n= odes
>> > change too fast and are too distributed to justify adding
>> > editing capabilities for config=3Dfalse nodes.
>>
>> Even then operational nodes have to satisfy some constraints that = must be
>> common to all management interfaces and/or protocols that work wit= h the
>> data, and often constraints on config data also involve operationa= l data.
>>
>> Lada
>>
>> >
>> >
>>
>
> Andy
>
>
>
>> >
>> >> Lada
>> >>
>> >>
>> >
>> > Andy
>> >
>> >
>> >> >
>> >> >
>> >> >> /martin & lada
>> >> >>
>> >> >
>> >> >
>> >> > Andy
>> >> >
>> >> >
>> >> >>
>> >> >>
>> >> >>
>> >> >>
>> >> >> ---------- Forwarded message ----------
>> >> >> From: internet-drafts@ietf.org
>> >> >> To: mbj@tail-f= .com
>> >> >> Cc: lhotka@nic.= cz
>> >> >> Date: Fri, 05 Oct 2012 01:23:30 -0700
>> >> >> Subject: New Version Notification for
>> >> >> draft-bjorklund-netmod-operational-00.txt
>> >> >>
>> >> >> A new version of I-D, draft-bjorklund-netmod-ope= rational-00.txt
>> >> >> has been successfully submitted by Martin Bjorkl= und and posted to the
>> >> >> IETF repository.
>> >> >>
>> >> >> Filename: =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-bjork= lund-netmod-operational
>> >> >> Revision: =C2=A0 =C2=A0 =C2=A0 =C2=A000
>> >> >> Title: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Operat= ional Data in NETCONF and YANG
>> >> >> Creation date: =C2=A0 2012-10-05
>> >> >> WG ID: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Indivi= dual Submission
>> >> >> Number of pages: 21
>> >> >> URL:
>> >> >>
>> >>
>> http://www.ietf.org/internet-draf= ts/draft-bjorklund-netmod-operational-00.txt
>> >> >> Status:
>> >> >> http://datatracker.ietf.or= g/doc/draft-bjorklund-netmod-operational
>> >> >> Htmlized:
>> >> >> http://tools.ietf.org/html/d= raft-bjorklund-netmod-operational-00
>> >> >>
>> >> >>
>> >> >> Abstract:
>> >> >> =C2=A0 =C2=A0This document defines the concept o= f operational state data in the
>> >> >> =C2=A0 =C2=A0context of YANG and the Network Con= figuration Protocol (NETCONF).
>> =C2=A0It
>> >> >> =C2=A0 =C2=A0updates RFC 6020 with rules for how= to model the operational
>> state,
>> >> >> =C2=A0 =C2=A0and defines NETCONF operations to r= etrieve and modify the
>> operational
>> >> >> =C2=A0 =C2=A0state.
>> >> >>
>> >> >>
>> >> >>
>> >> >>
>> >> >> The IETF Secretariat
>> >> >>
>> >> >>
>> >> >> _______________________________________________<= br> >> >> >> netmod mailing list
>> >> >> netmod@ietf.o= rg
>> >> >> 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
>> >>
>> > _______________________________________________
>> > 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
>>
> _______________________________________________
> 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

--20cf3074afe62d338b04cb89318e-- From lhotka@nic.cz Mon Oct 8 04:21: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 AC16721F863C for ; Mon, 8 Oct 2012 04:21:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.281 X-Spam-Level: X-Spam-Status: No, score=-1.281 tagged_above=-999 required=5 tests=[AWL=-0.482, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T3AvnWB09i87 for ; Mon, 8 Oct 2012 04:21: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 ECB8521F855A for ; Mon, 8 Oct 2012 04:21:15 -0700 (PDT) Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id AC5B0141052; Mon, 8 Oct 2012 13:21:14 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1349695274; bh=81jhrn+ZUS8OPN09uMl1vQV67Kr66qJF18uPUlNSIHE=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=D5v2uLthnJyNOJ3GhTG7t0/b6emKaoMHCGM0lYMBqDSgnl9y6DT436ulhr5WW2+FS EBnFzkqRtFddKxjLgmARn+k3XQw5PnF2/sS2vt/QM2d2iH9tJBKOz3JEJwFb0NNdy4 hI1JvPanj3xPya44KCm5gLdXMKl1kSxrU2Uw7pho= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) From: Ladislav Lhotka In-Reply-To: Date: Mon, 8 Oct 2012 13:21:14 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <6D5DA3E7-FC58-4288-BF59-613F904540E9@nic.cz> References: <20121005.102805.519929541.mbj@tail-f.com> To: Andy Bierman X-Mailer: Apple Mail (2.1498) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] Fw: New Version Notification for draft-bjorklund-netmod-operational-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, 08 Oct 2012 11:21:17 -0000 On Oct 8, 2012, at 11:53 AM, Andy Bierman wrote: >=20 >=20 > On Mon, Oct 8, 2012 at 2:10 AM, Ladislav Lhotka wrote: > Andy Bierman writes: >=20 > > On Sat, Oct 6, 2012 at 2:17 AM, Ladislav Lhotka = wrote: > > > >> Andy Bierman writes: > >> > >> > On Fri, Oct 5, 2012 at 8:49 AM, Ladislav Lhotka = wrote: > >> > > >> >> Andy Bierman writes: > >> >> > >> >> > On Fri, Oct 5, 2012 at 1:28 AM, Martin Bjorklund = > >> wrote: > >> >> > > >> >> >> Hi, > >> >> >> > >> >> >> Lada and I have written a draft where we try to define the = concept of > >> >> >> operational state data. There are a couple of open issues in = the > >> >> >> draft that need to be discussed, so please comment! > >> >> >> > >> >> >> > >> >> > I will just comment on the problem statements in section 3. > >> >> > > >> >> > 3.1) I don't agree that modeling config and operational data > >> >> > separately is is real problem, or that it is counter-intuitive > >> >> > to operators. > >> >> > > >> >> > The operational state (e.g., FIB) may come from multiple > >> >> > parts of the configuration, not just the simple example shown > >> >> > in sec. 3.1.1. I do not agree with that example, showing > >> >> > a separate interface-oper table. That is not needed. > >> >> > Just add a leaf to the interface entry to identify it as = 'active'. > >> >> > >> >> Who is supposed to add such a leaf - the server? And how can the = client > >> >> learn about the existence of inactive interfaces? > >> >> > >> > > >> > > >> > The data modeler writing the YANG module should add the leaf. > >> > >> I mean: who is supposed to set the value of the "active" leaf - the = server > >> or client? But my second question is more important: how does the = client > >> learn about an existing interface that's not in the configuration? > >> > >> > > > > I meant the server sets it. >=20 > The concept of the server writing something to the configuration is = not supported by the existing specs and IMO it is a non-starter. So you = should write a draft defining the rules for this. >=20 > The concept of returning config=3Dtrue nodes as operational data and = the concept of > editing config=3Dfalse nodes does not exist in NETCONF/YANG and it = should stay that way. > I don't agree with any of your problem statements so of course I don't = think > we need your solution either. config=3Dtrue nodes (e.g., an IP address) become operational state data = as soon as the server decides to use them for its operation. We wanted = to avoid the duplication of nodes, so that's why the pair of the related = config and OS values is modelled as a single node. >=20 > If the WG wants to support pre-provisioned config or disabled config, > then a new charter item for that should be proposed. I am not = interested > in this problem enough to write a draft about it. The WG has already agreed that the issues of operational state versus = configuration would be investigated. I believe the issues are real and = not contrived. >=20 > Client provided config that is not currently in use is not operational = state. For sure it isn't, and we didn't say it was. Such a config is present in = the configuration datastore but it is ignored by the server. >=20 > The client cannot set server operational state. It can perform = actions > which have side effects that change server operational state. And vice versa: the server cannot write operational state data to = client's configuration. It all depends on how we define the terms. The long-term problem of = NETCONF is that terms like configuration or operational state data can = be (and are) understood in different ways by different people and = vendors. Maybe it was originally considered a feature but I think it's a = bug. >=20 >=20 >=20 > In our draft, configuration contains only stuff explicitly written by = client(s). The server writes the data about pre-provisioned object to = the operational state datastore. >=20 > This is not the way real servers work. > There are PHY interfaces and other top level containers that > the server will create in the factory default config. I suppose such items then cannot be deleted by the client, contrary to = the rules for the configuration datastore. Lada >=20 > =20 >=20 > Lada >=20 >=20 >=20 > Andy >=20 >=20 >=20 > =20 > > Your problem statement does not mention client pre-provisioning of > > config data or disabling config data. These are still unsolved = problems > > in NETCONF. > > > > > > > >> > > >> > > >> >> > >> > > >> >> This is a contrived example. > >> >> > > >> >> > 3.2) I do not agree that operational state needs to be edited > >> directly > >> >> > by the client. I actually think the custom RPC approach in = the > >> >> > example in 3.2.1 is better and more clear within the model. > >> >> > Editing config=3Dfalse nodes is a fundamental change to the > >> >> > NETCONF/YANG architecture and it should not be done. > >> >> > >> >> But this is exactly what the IRS and SCIM (and maybe other) = folks are > >> >> about to do. > >> >> > >> > > >> > > >> > They haven't decided what to do yet AFAIK. > >> > IRS hasn't even had a BOF yet, let alone a WG. > >> > I suspect they will create an API, not a data model > >> > that is edited like configuration. We don't need > >> > to change N/Y based on speculation about what IRS WG > >> > will choose for a solution. > >> > > >> > >> This was just examples. The thing is, some applications and devices = don't > >> need the comfort (and overhead) of NETCONF. If I want to = temporarily switch > >> off forwarding on a Linux box, I simply set = /proc/sys/net/ipv4/ip_forward > >> to zero. > >> > > > > I don't agree that NETCONF should have editable state. > > You can mess up a Linux system hacking on /proc. > > I do not want to add a hack or a full-blown validation system > > for editing config=3Dfalse nodes. > > > > > > In your duplex example, let's say it is set to 'auto' > > and negotiates to 'half'. Then I the > > value to be 'full'. > > > > Now config says 'auto' and state says 'full'. > > How does every other operator know that I did that? > > To them it looks like the auto-negotiated value is 'full' but it is = not. > > > > > > > >> While you may argue that creators of new configuration APIs are = doomed to > >> reinvent the NETCONF wheels, I don't think it always has to be the = case. > >> > >> Our draft is also intended to enable coexistence of NETCONF with = other > >> management interfaces, and the operational state datastore (rather = than > >> NETCONF configuration datastores) is supposed to be the common = playground. > >> > >> > > >> > > >> > > >> >> > >> >> > > >> >> > Actions like and properly model > >> >> > the API between client and server, not . > >> >> > >> >> The means for modelling RPCs are very limited - the semantics = has to be > >> >> told in prose. > >> >> This is exactly why REST is superior to all kinds of RPC-based = APIs. > >> >> > >> > > >> > IMO operational state is a representation of internal device = state. > >> > It may be very implementation-specific how the operational state > >> > can be edited. > >> > > >> > The use-cases where operational state is injected or altered > >> > are very limited. We already have a solution that works for > >> > these corner cases (custom RPCs). > >> > > >> > Your draft returns config=3Dtrue nodes in , > >> > like duplex=3Dauto vs. duplex=3Dfull. IMO these corner cases > >> > do not show up that often, and the old solution of > >> > separate admin-status and oper-status is good enough. > >> > Returning config=3Dtrue nodes in > >> > requires a new YANG extension and server customization > >> > to support it. > >> > > >> > The validation/constraints/transaction model in NETCONF > >> > should be limited to config=3Dtrue nodes. Operational nodes > >> > change too fast and are too distributed to justify adding > >> > editing capabilities for config=3Dfalse nodes. > >> > >> Even then operational nodes have to satisfy some constraints that = must be > >> common to all management interfaces and/or protocols that work with = the > >> data, and often constraints on config data also involve operational = data. > >> > >> Lada > >> > >> > > >> > > >> > > > > Andy > > > > > > > >> > > >> >> Lada > >> >> > >> >> > >> > > >> > Andy > >> > > >> > > >> >> > > >> >> > > >> >> >> /martin & lada > >> >> >> > >> >> > > >> >> > > >> >> > Andy > >> >> > > >> >> > > >> >> >> > >> >> >> > >> >> >> > >> >> >> > >> >> >> ---------- Forwarded message ---------- > >> >> >> From: internet-drafts@ietf.org > >> >> >> To: mbj@tail-f.com > >> >> >> Cc: lhotka@nic.cz > >> >> >> Date: Fri, 05 Oct 2012 01:23:30 -0700 > >> >> >> Subject: New Version Notification for > >> >> >> draft-bjorklund-netmod-operational-00.txt > >> >> >> > >> >> >> A new version of I-D, = draft-bjorklund-netmod-operational-00.txt > >> >> >> has been successfully submitted by Martin Bjorklund and = posted to the > >> >> >> IETF repository. > >> >> >> > >> >> >> Filename: draft-bjorklund-netmod-operational > >> >> >> Revision: 00 > >> >> >> Title: Operational Data in NETCONF and YANG > >> >> >> Creation date: 2012-10-05 > >> >> >> WG ID: Individual Submission > >> >> >> Number of pages: 21 > >> >> >> URL: > >> >> >> > >> >> > >> = http://www.ietf.org/internet-drafts/draft-bjorklund-netmod-operational-00.= txt > >> >> >> Status: > >> >> >> = http://datatracker.ietf.org/doc/draft-bjorklund-netmod-operational > >> >> >> Htmlized: > >> >> >> = http://tools.ietf.org/html/draft-bjorklund-netmod-operational-00 > >> >> >> > >> >> >> > >> >> >> Abstract: > >> >> >> This document defines the concept of operational state = data in the > >> >> >> context of YANG and the Network Configuration Protocol = (NETCONF). > >> It > >> >> >> updates RFC 6020 with rules for how to model the = operational > >> state, > >> >> >> and defines NETCONF operations to retrieve and modify the > >> operational > >> >> >> state. > >> >> >> > >> >> >> > >> >> >> > >> >> >> > >> >> >> The IETF Secretariat > >> >> >> > >> >> >> > >> >> >> _______________________________________________ > >> >> >> netmod mailing list > >> >> >> netmod@ietf.org > >> >> >> https://www.ietf.org/mailman/listinfo/netmod > >> >> >> > >> >> >> > >> >> > _______________________________________________ > >> >> > netmod mailing list > >> >> > netmod@ietf.org > >> >> > https://www.ietf.org/mailman/listinfo/netmod > >> >> > >> >> -- > >> >> Ladislav Lhotka, CZ.NIC Labs > >> >> PGP Key ID: E74E8C0C > >> >> _______________________________________________ > >> >> netmod mailing list > >> >> netmod@ietf.org > >> >> https://www.ietf.org/mailman/listinfo/netmod > >> >> > >> > _______________________________________________ > >> > 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 > >> > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod >=20 > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From andy@yumaworks.com Mon Oct 8 08: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 C50F121F87E8 for ; Mon, 8 Oct 2012 08:33:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.823 X-Spam-Level: X-Spam-Status: No, score=-1.823 tagged_above=-999 required=5 tests=[AWL=-0.647, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dge1zarXYXGg for ; Mon, 8 Oct 2012 08:33:17 -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 6905521F87BC for ; Mon, 8 Oct 2012 08:33:12 -0700 (PDT) Received: by mail-qc0-f172.google.com with SMTP id c10so3477162qca.31 for ; Mon, 08 Oct 2012 08:33:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=XJUOMjPOnjsYGc70zLVk7qol6dOOzJNkOBGF5vT0CbM=; b=AI0BWRIDjgYfkGEwvf4zK8ce8c3gs5zidmuytuRD7kNL1rNTSw4XwXUx5PzcTAceW/ E2YXmOdycBrnzzpxhOhM4IJV+dp029npVxDmMbfpieMX4krJXqvs0v/Tx+zVclkrn7Q/ tImqz8mzJ/qZ7Hz+5NILbwNzhSEadExpl5XfCk/VArOcK6sEUmVrF8sEo+ruYZJBLL3+ vxigDsyWHey31gx3HBuLkUume6d8Hh0VFWMxF11rgo89IcZSq9dka/rqwe1rkUWBEMha ASMP4c1lBP8o2kbcpD0cmlt7G/bct2V4jbdudLiVEWiEvTTLyPWeY5hQfoPxiJ7nJ6d2 YsBQ== MIME-Version: 1.0 Received: by 10.224.217.136 with SMTP id hm8mr13479166qab.81.1349710391742; Mon, 08 Oct 2012 08:33:11 -0700 (PDT) Received: by 10.49.127.52 with HTTP; Mon, 8 Oct 2012 08:33:11 -0700 (PDT) In-Reply-To: <6D5DA3E7-FC58-4288-BF59-613F904540E9@nic.cz> References: <20121005.102805.519929541.mbj@tail-f.com> <6D5DA3E7-FC58-4288-BF59-613F904540E9@nic.cz> Date: Mon, 8 Oct 2012 08:33:11 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=20cf300fb1dd730f8b04cb8df0dc X-Gm-Message-State: ALoCoQkweNeNI5XAgH/pKX9EhFx644LHeKP5X13NAMoyIssFcClZh2Chxk4DmiGEXXT1bhlihtPO Cc: netmod@ietf.org Subject: Re: [netmod] Fw: New Version Notification for draft-bjorklund-netmod-operational-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, 08 Oct 2012 15:33:18 -0000 --20cf300fb1dd730f8b04cb8df0dc Content-Type: text/plain; charset=UTF-8 On Mon, Oct 8, 2012 at 4:21 AM, Ladislav Lhotka wrote: > > On Oct 8, 2012, at 11:53 AM, Andy Bierman wrote: > > > > > > > On Mon, Oct 8, 2012 at 2:10 AM, Ladislav Lhotka wrote: > > Andy Bierman writes: > > > > > On Sat, Oct 6, 2012 at 2:17 AM, Ladislav Lhotka wrote: > > > > > >> Andy Bierman writes: > > >> > > >> > On Fri, Oct 5, 2012 at 8:49 AM, Ladislav Lhotka > wrote: > > >> > > > >> >> Andy Bierman writes: > > >> >> > > >> >> > On Fri, Oct 5, 2012 at 1:28 AM, Martin Bjorklund > > > >> wrote: > > >> >> > > > >> >> >> Hi, > > >> >> >> > > >> >> >> Lada and I have written a draft where we try to define the > concept of > > >> >> >> operational state data. There are a couple of open issues in > the > > >> >> >> draft that need to be discussed, so please comment! > > >> >> >> > > >> >> >> > > >> >> > I will just comment on the problem statements in section 3. > > >> >> > > > >> >> > 3.1) I don't agree that modeling config and operational data > > >> >> > separately is is real problem, or that it is counter-intuitive > > >> >> > to operators. > > >> >> > > > >> >> > The operational state (e.g., FIB) may come from multiple > > >> >> > parts of the configuration, not just the simple example shown > > >> >> > in sec. 3.1.1. I do not agree with that example, showing > > >> >> > a separate interface-oper table. That is not needed. > > >> >> > Just add a leaf to the interface entry to identify it as > 'active'. > > >> >> > > >> >> Who is supposed to add such a leaf - the server? And how can the > client > > >> >> learn about the existence of inactive interfaces? > > >> >> > > >> > > > >> > > > >> > The data modeler writing the YANG module should add the leaf. > > >> > > >> I mean: who is supposed to set the value of the "active" leaf - the > server > > >> or client? But my second question is more important: how does the > client > > >> learn about an existing interface that's not in the configuration? > > >> > > >> > > > > > > I meant the server sets it. > > > > The concept of the server writing something to the configuration is not > supported by the existing specs and IMO it is a non-starter. So you should > write a draft defining the rules for this. > > > > The concept of returning config=true nodes as operational data and the > concept of > > editing config=false nodes does not exist in NETCONF/YANG and it should > stay that way. > > I don't agree with any of your problem statements so of course I don't > think > > we need your solution either. > > config=true nodes (e.g., an IP address) become operational state data as > soon as the server decides to use them for its operation. We wanted to > avoid the duplication of nodes, so that's why the pair of the related > config and OS values is modelled as a single node. > > No, config=true nodes don't become operational data. There may be some operational data that is changed as a result of a config change or some action operation. The problem of dual-mode objects is a very tiny corner-case, which has been solved in the real world using an 'admin' leaf and an operational leaf. A nice-to-have feature would be complete management of config state to support pre-provisioning and disabled config, but that is not the problem you are trying to solve. Maybe somebody else has read the draft and has a different opinion. Andy > > > If the WG wants to support pre-provisioned config or disabled config, > > then a new charter item for that should be proposed. I am not interested > > in this problem enough to write a draft about it. > > The WG has already agreed that the issues of operational state versus > configuration would be investigated. I believe the issues are real and not > contrived. > > > > > Client provided config that is not currently in use is not operational > state. > > For sure it isn't, and we didn't say it was. Such a config is present in > the configuration datastore but it is ignored by the server. > > > > > The client cannot set server operational state. It can perform actions > > which have side effects that change server operational state. > > And vice versa: the server cannot write operational state data to client's > configuration. > It all depends on how we define the terms. The long-term problem of > NETCONF is that terms like configuration or operational state data can be > (and are) understood in different ways by different people and vendors. > Maybe it was originally considered a feature but I think it's a bug. > > > > > > > > > In our draft, configuration contains only stuff explicitly written by > client(s). The server writes the data about pre-provisioned object to the > operational state datastore. > > > > This is not the way real servers work. > > There are PHY interfaces and other top level containers that > > the server will create in the factory default config. > > I suppose such items then cannot be deleted by the client, contrary to the > rules for the configuration datastore. > > Lada > > > > > > > > > Lada > > > > > > > > Andy > > > > > > > > > > > Your problem statement does not mention client pre-provisioning of > > > config data or disabling config data. These are still unsolved > problems > > > in NETCONF. > > > > > > > > > > > >> > > > >> > > > >> >> > > >> > > > >> >> This is a contrived example. > > >> >> > > > >> >> > 3.2) I do not agree that operational state needs to be edited > > >> directly > > >> >> > by the client. I actually think the custom RPC approach in the > > >> >> > example in 3.2.1 is better and more clear within the model. > > >> >> > Editing config=false nodes is a fundamental change to the > > >> >> > NETCONF/YANG architecture and it should not be done. > > >> >> > > >> >> But this is exactly what the IRS and SCIM (and maybe other) folks > are > > >> >> about to do. > > >> >> > > >> > > > >> > > > >> > They haven't decided what to do yet AFAIK. > > >> > IRS hasn't even had a BOF yet, let alone a WG. > > >> > I suspect they will create an API, not a data model > > >> > that is edited like configuration. We don't need > > >> > to change N/Y based on speculation about what IRS WG > > >> > will choose for a solution. > > >> > > > >> > > >> This was just examples. The thing is, some applications and devices > don't > > >> need the comfort (and overhead) of NETCONF. If I want to temporarily > switch > > >> off forwarding on a Linux box, I simply set > /proc/sys/net/ipv4/ip_forward > > >> to zero. > > >> > > > > > > I don't agree that NETCONF should have editable state. > > > You can mess up a Linux system hacking on /proc. > > > I do not want to add a hack or a full-blown validation system > > > for editing config=false nodes. > > > > > > > > > In your duplex example, let's say it is set to 'auto' > > > and negotiates to 'half'. Then I the > > > value to be 'full'. > > > > > > Now config says 'auto' and state says 'full'. > > > How does every other operator know that I did that? > > > To them it looks like the auto-negotiated value is 'full' but it is > not. > > > > > > > > > > > >> While you may argue that creators of new configuration APIs are > doomed to > > >> reinvent the NETCONF wheels, I don't think it always has to be the > case. > > >> > > >> Our draft is also intended to enable coexistence of NETCONF with other > > >> management interfaces, and the operational state datastore (rather > than > > >> NETCONF configuration datastores) is supposed to be the common > playground. > > >> > > >> > > > >> > > > >> > > > >> >> > > >> >> > > > >> >> > Actions like and properly model > > >> >> > the API between client and server, not . > > >> >> > > >> >> The means for modelling RPCs are very limited - the semantics has > to be > > >> >> told in prose. > > >> >> This is exactly why REST is superior to all kinds of RPC-based > APIs. > > >> >> > > >> > > > >> > IMO operational state is a representation of internal device state. > > >> > It may be very implementation-specific how the operational state > > >> > can be edited. > > >> > > > >> > The use-cases where operational state is injected or altered > > >> > are very limited. We already have a solution that works for > > >> > these corner cases (custom RPCs). > > >> > > > >> > Your draft returns config=true nodes in , > > >> > like duplex=auto vs. duplex=full. IMO these corner cases > > >> > do not show up that often, and the old solution of > > >> > separate admin-status and oper-status is good enough. > > >> > Returning config=true nodes in > > >> > requires a new YANG extension and server customization > > >> > to support it. > > >> > > > >> > The validation/constraints/transaction model in NETCONF > > >> > should be limited to config=true nodes. Operational nodes > > >> > change too fast and are too distributed to justify adding > > >> > editing capabilities for config=false nodes. > > >> > > >> Even then operational nodes have to satisfy some constraints that > must be > > >> common to all management interfaces and/or protocols that work with > the > > >> data, and often constraints on config data also involve operational > data. > > >> > > >> Lada > > >> > > >> > > > >> > > > >> > > > > > > Andy > > > > > > > > > > > >> > > > >> >> Lada > > >> >> > > >> >> > > >> > > > >> > Andy > > >> > > > >> > > > >> >> > > > >> >> > > > >> >> >> /martin & lada > > >> >> >> > > >> >> > > > >> >> > > > >> >> > Andy > > >> >> > > > >> >> > > > >> >> >> > > >> >> >> > > >> >> >> > > >> >> >> > > >> >> >> ---------- Forwarded message ---------- > > >> >> >> From: internet-drafts@ietf.org > > >> >> >> To: mbj@tail-f.com > > >> >> >> Cc: lhotka@nic.cz > > >> >> >> Date: Fri, 05 Oct 2012 01:23:30 -0700 > > >> >> >> Subject: New Version Notification for > > >> >> >> draft-bjorklund-netmod-operational-00.txt > > >> >> >> > > >> >> >> A new version of I-D, draft-bjorklund-netmod-operational-00.txt > > >> >> >> has been successfully submitted by Martin Bjorklund and posted > to the > > >> >> >> IETF repository. > > >> >> >> > > >> >> >> Filename: draft-bjorklund-netmod-operational > > >> >> >> Revision: 00 > > >> >> >> Title: Operational Data in NETCONF and YANG > > >> >> >> Creation date: 2012-10-05 > > >> >> >> WG ID: Individual Submission > > >> >> >> Number of pages: 21 > > >> >> >> URL: > > >> >> >> > > >> >> > > >> > http://www.ietf.org/internet-drafts/draft-bjorklund-netmod-operational-00.txt > > >> >> >> Status: > > >> >> >> > http://datatracker.ietf.org/doc/draft-bjorklund-netmod-operational > > >> >> >> Htmlized: > > >> >> >> > http://tools.ietf.org/html/draft-bjorklund-netmod-operational-00 > > >> >> >> > > >> >> >> > > >> >> >> Abstract: > > >> >> >> This document defines the concept of operational state data > in the > > >> >> >> context of YANG and the Network Configuration Protocol > (NETCONF). > > >> It > > >> >> >> updates RFC 6020 with rules for how to model the operational > > >> state, > > >> >> >> and defines NETCONF operations to retrieve and modify the > > >> operational > > >> >> >> state. > > >> >> >> > > >> >> >> > > >> >> >> > > >> >> >> > > >> >> >> The IETF Secretariat > > >> >> >> > > >> >> >> > > >> >> >> _______________________________________________ > > >> >> >> netmod mailing list > > >> >> >> netmod@ietf.org > > >> >> >> https://www.ietf.org/mailman/listinfo/netmod > > >> >> >> > > >> >> >> > > >> >> > _______________________________________________ > > >> >> > netmod mailing list > > >> >> > netmod@ietf.org > > >> >> > https://www.ietf.org/mailman/listinfo/netmod > > >> >> > > >> >> -- > > >> >> Ladislav Lhotka, CZ.NIC Labs > > >> >> PGP Key ID: E74E8C0C > > >> >> _______________________________________________ > > >> >> netmod mailing list > > >> >> netmod@ietf.org > > >> >> https://www.ietf.org/mailman/listinfo/netmod > > >> >> > > >> > _______________________________________________ > > >> > 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 > > >> > > > _______________________________________________ > > > 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 > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > --20cf300fb1dd730f8b04cb8df0dc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Mon, Oct 8, 2012 at 4:21 AM, Ladislav= Lhotka <lhotka@nic.cz> wrote:

On Oct 8, 2012, at 11:53 AM, Andy Bierman <andy@yumaworks.com> wrote:

>
>
> On Mon, Oct 8, 2012 at 2:10 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
> Andy Bierman <andy@yumaworks.= com> writes:
>
> > On Sat, Oct 6, 2012 at 2:17 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
> >
> >> Andy Bierman <andy@y= umaworks.com> writes:
> >>
> >> > On Fri, Oct 5, 2012 at 8:49 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
> >> >
> >> >> Andy Bierman <andy@yumaworks.com> writes:
> >> >>
> >> >> > On Fri, Oct 5, 2012 at 1:28 AM, Martin Bjorklun= d <mbj@tail-f.com>
> >> wrote:
> >> >> >
> >> >> >> Hi,
> >> >> >>
> >> >> >> Lada and I have written a draft where we tr= y to define the concept of
> >> >> >> operational state data. =C2=A0There are a c= ouple of open issues in the
> >> >> >> draft that need to be discussed, so please = comment!
> >> >> >>
> >> >> >>
> >> >> > I will just comment on the problem statements i= n section 3.
> >> >> >
> >> >> > 3.1) I don't agree that modeling config and= operational data
> >> >> > separately is is real problem, or that it is co= unter-intuitive
> >> >> > to operators.
> >> >> >
> >> >> > The operational state (e.g., FIB) may come from= multiple
> >> >> > parts of the configuration, not just the simple= example shown
> >> >> > in sec. 3.1.1. I do not agree with that example= , showing
> >> >> > a separate interface-oper table. =C2=A0That is = not needed.
> >> >> > Just add a leaf to the interface entry to ident= ify it as 'active'.
> >> >>
> >> >> Who is supposed to add such a leaf - the server? And= how can the client
> >> >> learn about the existence of inactive interfaces? > >> >>
> >> >
> >> >
> >> > The data modeler writing the YANG module should add the = leaf.
> >>
> >> I mean: who is supposed to set the value of the "active&= quot; leaf - the server
> >> or client? But my second question is more important: how does= the client
> >> learn about an existing interface that's not in the confi= guration?
> >>
> >>
> >
> > I meant the server sets it.
>
> The concept of the server writing something to the configuration is no= t supported by the existing specs and IMO it is a non-starter. So you shoul= d write a draft defining the rules for this.
>
> The concept of returning config=3Dtrue nodes as operational data and t= he concept of
> editing config=3Dfalse nodes does not exist in NETCONF/YANG and it sho= uld stay that way.
> I don't agree with any of your problem statements so of course I d= on't think
> we need your solution either.

config=3Dtrue nodes (e.g., an IP address) become operational state data as = soon as the server decides to use them for its operation. We wanted to avoi= d the duplication of nodes, so that's why the pair of the related confi= g and OS values is modelled as a single node.


No, config=3Dtrue nodes don't beco= me operational data.
There may be some operational data that is c= hanged as a result
of a config change or some action operation.

The problem of dual-mode objects is a very tiny corner-= case,
which has been solved in the real world using an 'admin= ' leaf and an
operational leaf.

A nice-to-have feature would be complete management of
config sta= te to support pre-provisioning and disabled config,
but that is n= ot the problem you are trying to solve.

Maybe some= body else has read the draft and has a different opinion.


Andy


=

>
> If the WG wants to support pre-provisioned config or disabled config,<= br> > then a new charter item for that should be proposed. =C2=A0I am not in= terested
> in this problem enough to write a draft about it.

The WG has already agreed that the issues of operational state versus confi= guration would be investigated. I believe the issues are real and not contr= ived.

>
> Client provided config that is not currently in use is not operational= state.

For sure it isn't, and we didn't say it was. Such a config is prese= nt in the configuration datastore but it is ignored by the server.

>
> The client cannot set server operational state. =C2=A0It can perform a= ctions
> which have side effects that change server operational state.

And vice versa: the server cannot write operational state data to client= 9;s configuration.
It all depends on how we define the terms. The long-term problem of NETCONF= is that terms like configuration or operational state data can be (and are= ) understood in different ways by different people and vendors. Maybe it wa= s originally considered a feature but I think it's a bug.

>
>
>
> In our draft, configuration contains only stuff explicitly written by = client(s). The server writes the data about pre-provisioned object to the o= perational state datastore.
>
> This is not the way real servers work.
> There are PHY interfaces and other top level containers that
> the server will create in the factory default config.

I suppose such items then cannot be deleted by the client, contrary to the = rules for the configuration datastore.

Lada

>
>
>
> Lada
>
>
>
> Andy
>
>
>
>
> > Your problem statement does not mention client pre-provisioning o= f
> > config data or disabling config data. =C2=A0These are still unsol= ved problems
> > in NETCONF.
> >
> >
> >
> >> >
> >> >
> >> >>
> >> >
> >> >> This is a contrived example.
> >> >> >
> >> >> > 3.2) =C2=A0I do not agree that operational stat= e needs to be edited
> >> directly
> >> >> > by the client. =C2=A0I actually think the custo= m RPC approach in the
> >> >> > example in 3.2.1 is better and more clear withi= n the model.
> >> >> > Editing config=3Dfalse nodes is a fundamental c= hange to the
> >> >> > NETCONF/YANG architecture and it should not be = done.
> >> >>
> >> >> But this is exactly what the IRS and SCIM (and maybe= other) folks are
> >> >> about to do.
> >> >>
> >> >
> >> >
> >> > They haven't decided what to do yet AFAIK.
> >> > IRS hasn't even had a BOF yet, let alone a WG.
> >> > I suspect they will create an API, not a data model
> >> > that is edited like configuration. =C2=A0We don't ne= ed
> >> > to change N/Y based on speculation about what IRS WG
> >> > will choose for a solution.
> >> >
> >>
> >> This was just examples. The thing is, some applications and d= evices don't
> >> need the comfort (and overhead) of NETCONF. If I want to temp= orarily switch
> >> off forwarding on a Linux box, I simply set /proc/sys/net/ipv= 4/ip_forward
> >> to zero.
> >>
> >
> > I don't agree that NETCONF should have editable state.
> > You can mess up a Linux system hacking on /proc.
> > I do not want to add a hack or a full-blown validation system
> > for editing config=3Dfalse nodes.
> >
> >
> > In your duplex example, let's say it is set to 'auto'=
> > and negotiates to 'half'. =C2=A0Then I <edit-operation= al> the
> > value to be 'full'.
> >
> > Now config says 'auto' and state says 'full'.
> > How does every other operator know that I did that?
> > To them it looks like the auto-negotiated value is 'full'= but it is not.
> >
> >
> >
> >> While you may argue that creators of new configuration APIs a= re doomed to
> >> reinvent the NETCONF wheels, I don't think it always has = to be the case.
> >>
> >> Our draft is also intended to enable coexistence of NETCONF w= ith other
> >> management interfaces, and the operational state datastore (r= ather than
> >> NETCONF configuration datastores) is supposed to be the commo= n playground.
> >>
> >> >
> >> >
> >> >
> >> >>
> >> >> >
> >> >> > Actions like <add-route> and <delete-r= oute> properly model
> >> >> > the API between client and server, not <edit= -operational>.
> >> >>
> >> >> The means for modelling RPCs are very limited - the = semantics has to be
> >> >> told in prose.
> >> >> This is exactly why REST is superior to all kinds of= RPC-based APIs.
> >> >>
> >> >
> >> > IMO operational state is a representation of internal de= vice state.
> >> > It may be very implementation-specific how the operation= al state
> >> > can be edited.
> >> >
> >> > The use-cases where operational state is injected or alt= ered
> >> > are very limited. =C2=A0We already have a solution that = works for
> >> > these corner cases (custom RPCs).
> >> >
> >> > Your draft returns config=3Dtrue nodes in <get-operat= ional>,
> >> > like duplex=3Dauto vs. duplex=3Dfull. =C2=A0IMO these co= rner cases
> >> > do not show up that often, and the old solution of
> >> > separate admin-status and oper-status is good enough. > >> > Returning config=3Dtrue nodes in <get-operational>=
> >> > requires a new YANG extension and server customization > >> > to support it.
> >> >
> >> > The validation/constraints/transaction model in NETCONF<= br> > >> > should be limited to config=3Dtrue nodes. =C2=A0Operatio= nal nodes
> >> > change too fast and are too distributed to justify addin= g
> >> > editing capabilities for config=3Dfalse nodes.
> >>
> >> Even then operational nodes have to satisfy some constraints = that must be
> >> common to all management interfaces and/or protocols that wor= k with the
> >> data, and often constraints on config data also involve opera= tional data.
> >>
> >> Lada
> >>
> >> >
> >> >
> >>
> >
> > Andy
> >
> >
> >
> >> >
> >> >> Lada
> >> >>
> >> >>
> >> >
> >> > Andy
> >> >
> >> >
> >> >> >
> >> >> >
> >> >> >> /martin & lada
> >> >> >>
> >> >> >
> >> >> >
> >> >> > Andy
> >> >> >
> >> >> >
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >> ---------- Forwarded message ----------
> >> >> >> From: internet-drafts@ietf.org
> >> >> >> To: mbj@t= ail-f.com
> >> >> >> Cc: lhotka= @nic.cz
> >> >> >> Date: Fri, 05 Oct 2012 01:23:30 -0700
> >> >> >> Subject: New Version Notification for
> >> >> >> draft-bjorklund-netmod-operational-00.txt > >> >> >>
> >> >> >> A new version of I-D, draft-bjorklund-netmo= d-operational-00.txt
> >> >> >> has been successfully submitted by Martin B= jorklund and posted to the
> >> >> >> IETF repository.
> >> >> >>
> >> >> >> Filename: =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-= bjorklund-netmod-operational
> >> >> >> Revision: =C2=A0 =C2=A0 =C2=A0 =C2=A000
> >> >> >> Title: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 O= perational Data in NETCONF and YANG
> >> >> >> Creation date: =C2=A0 2012-10-05
> >> >> >> WG ID: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 I= ndividual Submission
> >> >> >> Number of pages: 21
> >> >> >> URL:
> >> >> >>
> >> >>
> >> http://www.ietf.org/internet= -drafts/draft-bjorklund-netmod-operational-00.txt
> >> >> >> Status:
> >> >> >> http://datatracker.ie= tf.org/doc/draft-bjorklund-netmod-operational
> >> >> >> Htmlized:
> >> >> >> http://tools.ietf.org/h= tml/draft-bjorklund-netmod-operational-00
> >> >> >>
> >> >> >>
> >> >> >> Abstract:
> >> >> >> =C2=A0 =C2=A0This document defines the conc= ept of operational state data in the
> >> >> >> =C2=A0 =C2=A0context of YANG and the Networ= k Configuration Protocol (NETCONF).
> >> =C2=A0It
> >> >> >> =C2=A0 =C2=A0updates RFC 6020 with rules fo= r how to model the operational
> >> state,
> >> >> >> =C2=A0 =C2=A0and defines NETCONF operations= to retrieve and modify the
> >> operational
> >> >> >> =C2=A0 =C2=A0state.
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >> The IETF Secretariat
> >> >> >>
> >> >> >>
> >> >> >> ___________________________________________= ____
> >> >> >> netmod mailing list
> >> >> >> netmod@i= etf.org
> >> >> >> https://www.ietf.org/mailman/listinfo/netmo= d
> >> >> >>
> >> >> >>
> >> >> > _______________________________________________=
> >> >> > 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
> >> >>
> >> > _______________________________________________
> >> > 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
> >>
> > _______________________________________________
> > 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
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

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





--20cf300fb1dd730f8b04cb8df0dc-- From bclaise@cisco.com Tue Oct 9 07:38: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 88C2F21F87CA for ; Tue, 9 Oct 2012 07:38:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.784 X-Spam-Level: X-Spam-Status: No, score=-8.784 tagged_above=-999 required=5 tests=[AWL=1.815, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jo9RE06LYB6l for ; Tue, 9 Oct 2012 07:38:37 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 3C7D221F87C8 for ; Tue, 9 Oct 2012 07:38:37 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q99EcXMh014960; Tue, 9 Oct 2012 16:38:33 +0200 (CEST) Received: from [10.60.67.86] (ams-bclaise-8915.cisco.com [10.60.67.86]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q99EcVn2020511; Tue, 9 Oct 2012 16:38:31 +0200 (CEST) Message-ID: <507436E7.8000807@cisco.com> Date: Tue, 09 Oct 2012 16:38:31 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Ladislav Lhotka , Jernej Tuljak , Ladislav Lhotka , lhotka@cesnet.cz, netmod@ietf.org, rbonica@juniper.net References: <20120921154850.6A92C72E038@rfc-editor.org> <20120924083532.GB7097@elstar.local> <0B670666-932D-4549-B444-93B8021F7F1F@lhotka.name> <506022CA.9030200@cisco.com> <5062B8E4.6090303@mg-soft.com> <86E04D86-9E91-4EC5-9106-8D37C3B41D4E@nic.cz> <20120926093725.GA58512@elstar.local> <50642856.6030703@cisco.com> In-Reply-To: <50642856.6030703@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [netmod] Last Call on the updated errata 3362 (was: [Technical Errata Reported] RFC6110 (3362)) X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 09 Oct 2012 14:38:44 -0000 Dear all, One simplification in the process of this errata. See in line. > Dear all, >>> I don't have any experience with the errata procedure but I think >>> the first decision should be whether this qualifies as an erratum, >>> because indeed it changes the DSDL mapping "protocol", as Martin >>> pointed out. >>> >>> Who is entitled to make this decision? >>> >> I have moved this question over to Benoit since I think we need advice >> from the ADs here. > > Reviewing http://www.ietf.org/iesg/statement/errata-processing.html as > background information... > - As far as I can tell, we agree that this is a bug in the > specification. So an errata should be filed. > - As far as I can tell, we fall into: "Only errors that could cause > implementation or deployment problems or significant confusion should > be Approved." > - As far as I can tell, we don't fall into: "Changes that modify the > working of a protocol to something that might be different from the > intended consensus when the document was approved should be either > Hold for Document Update or Rejected" > > I'm in favor to keep the process simple, and to verify the errata, > instead of producing a new RFC. > > However, before doing so, we want to be a safe side, basically making > sure that there are no other implementations for which this bug fix > (read non-backward compatibility change) would cause a problem. > > So let me propose the following: > - We keep the errata 3362 open for now > - Since errata 3362 needs to updated (and since we can't update this > errata without approving/rejecting AFAIK), we create a new errata with > all the changes, as agreed on the mailing list. Do we have an > agreement on what Lada proposed? After speaking to the RFC-editor, I was able to update the errata 3362 (thanks Lada for helping here). > - I send a kind of LC email to the mailing list, with this new errata > - If no issue during this LC, I reject errata 3362 (pointing to the > new errata), and I verify the new one. Please review the updated errata 3362 at http://www.rfc-editor.org/errata_search.php?eid=3362, and provide feedback by October 19th. At that date, the errata will be "verified" Regards, Benoit. > > Regards, Benoit. >> /js >> > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > From jernej.tuljak@mg-soft.si Tue Oct 9 23:36: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 24E5C21F8704 for ; Tue, 9 Oct 2012 23:36:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0a-XviZREH1r for ; Tue, 9 Oct 2012 23:36:28 -0700 (PDT) Received: from gate.mg-soft.si (gate.mg-soft.si [212.30.73.66]) by ietfa.amsl.com (Postfix) with ESMTP id 3588D21F86FF for ; Tue, 9 Oct 2012 23:36:27 -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 q9A6aK3U016095; Wed, 10 Oct 2012 08:36:20 +0200 Message-ID: <50751760.3050106@mg-soft.com> Date: Wed, 10 Oct 2012 08:36:16 +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: Benoit Claise References: <20120921154850.6A92C72E038@rfc-editor.org> <20120924083532.GB7097@elstar.local> <0B670666-932D-4549-B444-93B8021F7F1F@lhotka.name> <506022CA.9030200@cisco.com> <5062B8E4.6090303@mg-soft.com> <86E04D86-9E91-4EC5-9106-8D37C3B41D4E@nic.cz> <20120926093725.GA58512@elstar.local> <50642856.6030703@cisco.com> <507436E7.8000807@cisco.com> In-Reply-To: <507436E7.8000807@cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org, Ladislav Lhotka , rbonica@juniper.net, lhotka@cesnet.cz Subject: Re: [netmod] Last Call on the updated errata 3362 X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 10 Oct 2012 06:36:29 -0000 Dne 9.10.2012 16:38, piše Benoit Claise: > Dear all, > > One simplification in the process of this errata. > See in line. >> Dear all, >>>> I don't have any experience with the errata procedure but I think >>>> the first decision should be whether this qualifies as an erratum, >>>> because indeed it changes the DSDL mapping "protocol", as Martin >>>> pointed out. >>>> >>>> Who is entitled to make this decision? >>>> >>> I have moved this question over to Benoit since I think we need advice >>> from the ADs here. >> >> Reviewing http://www.ietf.org/iesg/statement/errata-processing.html >> as background information... >> - As far as I can tell, we agree that this is a bug in the >> specification. So an errata should be filed. >> - As far as I can tell, we fall into: "Only errors that could cause >> implementation or deployment problems or significant confusion should >> be Approved." >> - As far as I can tell, we don't fall into: "Changes that modify the >> working of a protocol to something that might be different from the >> intended consensus when the document was approved should be either >> Hold for Document Update or Rejected" >> >> I'm in favor to keep the process simple, and to verify the errata, >> instead of producing a new RFC. >> >> However, before doing so, we want to be a safe side, basically making >> sure that there are no other implementations for which this bug fix >> (read non-backward compatibility change) would cause a problem. >> >> So let me propose the following: >> - We keep the errata 3362 open for now >> - Since errata 3362 needs to updated (and since we can't update this >> errata without approving/rejecting AFAIK), we create a new errata >> with all the changes, as agreed on the mailing list. Do we have an >> agreement on what Lada proposed? > After speaking to the RFC-editor, I was able to update the errata 3362 > (thanks Lada for helping here). >> - I send a kind of LC email to the mailing list, with this new errata >> - If no issue during this LC, I reject errata 3362 (pointing to the >> new errata), and I verify the new one. > Please review the updated errata 3362 at > http://www.rfc-editor.org/errata_search.php?eid=3362, and provide > feedback by October 19th. > At that date, the errata will be "verified" > There's a typo in the corrected entry of Table of Contents. 12.16. The ..............................74 Should be 12.16. The Annotation ..............................74 ("greater than" moved) Jernej > Regards, Benoit. >> >> Regards, Benoit. >>> /js >>> >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >> >> From bclaise@cisco.com Wed Oct 10 00:36: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 A63AD21F8768 for ; Wed, 10 Oct 2012 00:36:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.796 X-Spam-Level: X-Spam-Status: No, score=-4.796 tagged_above=-999 required=5 tests=[AWL=-2.197, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lUbgKndbpVC1 for ; Wed, 10 Oct 2012 00:36:11 -0700 (PDT) Received: from av-tac-bru.cisco.com (spooky-brew.cisco.com [144.254.15.113]) by ietfa.amsl.com (Postfix) with ESMTP id D305C21F876A for ; Wed, 10 Oct 2012 00:36:10 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q9A7a6mN024790; Wed, 10 Oct 2012 09:36:06 +0200 (CEST) Received: from [10.60.67.86] (ams-bclaise-8915.cisco.com [10.60.67.86]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q9A7a5X5011139; Wed, 10 Oct 2012 09:36:06 +0200 (CEST) Message-ID: <50752565.7010501@cisco.com> Date: Wed, 10 Oct 2012 09:36:05 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Jernej Tuljak References: <20120921154850.6A92C72E038@rfc-editor.org> <20120924083532.GB7097@elstar.local> <0B670666-932D-4549-B444-93B8021F7F1F@lhotka.name> <506022CA.9030200@cisco.com> <5062B8E4.6090303@mg-soft.com> <86E04D86-9E91-4EC5-9106-8D37C3B41D4E@nic.cz> <20120926093725.GA58512@elstar.local> <50642856.6030703@cisco.com> <507436E7.8000807@cisco.com> <50751760.3050106@mg-soft.com> In-Reply-To: <50751760.3050106@mg-soft.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: Ladislav Lhotka , rbonica@juniper.net, lhotka@cesnet.cz, netmod@ietf.org Subject: Re: [netmod] Last Call on the updated errata 3362 X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 10 Oct 2012 07:36:11 -0000 Jernej, Well spot. Corrected Regards, Benoit. > Dne 9.10.2012 16:38, piše Benoit Claise: >> Dear all, >> >> One simplification in the process of this errata. >> See in line. >>> Dear all, >>>>> I don't have any experience with the errata procedure but I think >>>>> the first decision should be whether this qualifies as an erratum, >>>>> because indeed it changes the DSDL mapping "protocol", as Martin >>>>> pointed out. >>>>> >>>>> Who is entitled to make this decision? >>>>> >>>> I have moved this question over to Benoit since I think we need advice >>>> from the ADs here. >>> >>> Reviewing http://www.ietf.org/iesg/statement/errata-processing.html >>> as background information... >>> - As far as I can tell, we agree that this is a bug in the >>> specification. So an errata should be filed. >>> - As far as I can tell, we fall into: "Only errors that could cause >>> implementation or deployment problems or significant confusion >>> should be Approved." >>> - As far as I can tell, we don't fall into: "Changes that modify the >>> working of a protocol to something that might be different from the >>> intended consensus when the document was approved should be either >>> Hold for Document Update or Rejected" >>> >>> I'm in favor to keep the process simple, and to verify the errata, >>> instead of producing a new RFC. >>> >>> However, before doing so, we want to be a safe side, basically >>> making sure that there are no other implementations for which this >>> bug fix (read non-backward compatibility change) would cause a problem. >>> >>> So let me propose the following: >>> - We keep the errata 3362 open for now >>> - Since errata 3362 needs to updated (and since we can't update this >>> errata without approving/rejecting AFAIK), we create a new errata >>> with all the changes, as agreed on the mailing list. Do we have an >>> agreement on what Lada proposed? >> After speaking to the RFC-editor, I was able to update the errata >> 3362 (thanks Lada for helping here). >>> - I send a kind of LC email to the mailing list, with this new errata >>> - If no issue during this LC, I reject errata 3362 (pointing to the >>> new errata), and I verify the new one. >> Please review the updated errata 3362 at >> http://www.rfc-editor.org/errata_search.php?eid=3362, and provide >> feedback by October 19th. >> At that date, the errata will be "verified" >> > > There's a typo in the corrected entry of Table of Contents. > > 12.16. The ..............................74 > > Should be > > 12.16. The Annotation ..............................74 > > ("greater than" moved) > > Jernej > >> Regards, Benoit. >>> >>> Regards, Benoit. >>>> /js >>>> >>> >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >>> >>> > > From lhotka@nic.cz Wed Oct 10 01:34: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 5AB3E21F8546 for ; Wed, 10 Oct 2012 01:34:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kI2VeN-mUKj8 for ; Wed, 10 Oct 2012 01:34:41 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id BF05621F853C for ; Wed, 10 Oct 2012 01:34:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 2A68A5405D2; Wed, 10 Oct 2012 10:34: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 5Qs8W3ChCJST; Wed, 10 Oct 2012 10:34:31 +0200 (CEST) Received: from localhost (unknown [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 844BD5400CF; Wed, 10 Oct 2012 10:34:27 +0200 (CEST) From: Ladislav Lhotka To: Benoit Claise , Jernej Tuljak In-Reply-To: <50752565.7010501@cisco.com> References: <20120921154850.6A92C72E038@rfc-editor.org> <20120924083532.GB7097@elstar.local> <0B670666-932D-4549-B444-93B8021F7F1F@lhotka.name> <506022CA.9030200@cisco.com> <5062B8E4.6090303@mg-soft.com> <86E04D86-9E91-4EC5-9106-8D37C3B41D4E@nic.cz> <20120926093725.GA58512@elstar.local> <50642856.6030703@cisco.com> <507436E7.8000807@cisco.com> <50751760.3050106@mg-soft.com> <50752565.7010501@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: Benoit Claise , Jernej Tuljak , lhotka@cesnet.cz, netmod@ietf.org, rbonica@juniper.net Date: Wed, 10 Oct 2012 10:34:26 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: rbonica@juniper.net, lhotka@cesnet.cz, netmod@ietf.org Subject: Re: [netmod] Last Call on the updated errata 3362 X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 10 Oct 2012 08:34:41 -0000 Benoit Claise writes: > Jernej, > > Well spot. Corrected Oops, sorry, mea culpa. Unfortunately, there is now a new typo that wasn't in my text: There should be a space between "The" and the left chevron. That is, the correct ToC entry is: 12.16. The Annotation ..............................74 Thanks, Lada > >> >> There's a typo in the corrected entry of Table of Contents. >> >> 12.16. The ..............................74 >> >> Should be >> >> 12.16. The Annotation ..............................74 >> >> ("greater than" moved) >> >> Jernej >> >>> Regards, Benoit. >>>> >>>> Regards, Benoit. >>>>> /js >>>>> >>>> >>>> _______________________________________________ >>>> netmod mailing list >>>> netmod@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netmod >>>> >>>> >> >> > -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From bclaise@cisco.com Wed Oct 10 01:49: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 3370E21F86EA for ; Wed, 10 Oct 2012 01:49:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.778 X-Spam-Level: X-Spam-Status: No, score=-8.778 tagged_above=-999 required=5 tests=[AWL=1.821, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qef6bkIDlkeG for ; Wed, 10 Oct 2012 01:49:12 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 5AC5221F86EC for ; Wed, 10 Oct 2012 01:49:12 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q9A8n7W9003392; Wed, 10 Oct 2012 10:49:07 +0200 (CEST) Received: from [10.60.67.86] (ams-bclaise-8915.cisco.com [10.60.67.86]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q9A8n6FW025002; Wed, 10 Oct 2012 10:49:07 +0200 (CEST) Message-ID: <50753682.4080803@cisco.com> Date: Wed, 10 Oct 2012 10:49:06 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Jernej Tuljak , lhotka@cesnet.cz, netmod@ietf.org, rbonica@juniper.net References: <20120921154850.6A92C72E038@rfc-editor.org> <20120924083532.GB7097@elstar.local> <0B670666-932D-4549-B444-93B8021F7F1F@lhotka.name> <506022CA.9030200@cisco.com> <5062B8E4.6090303@mg-soft.com> <86E04D86-9E91-4EC5-9106-8D37C3B41D4E@nic.cz> <20120926093725.GA58512@elstar.local> <50642856.6030703@cisco.com> <507436E7.8000807@cisco.com> <50751760.3050106@mg-soft.com> <50752565.7010501@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [netmod] Last Call on the updated errata 3362 X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 10 Oct 2012 08:49:13 -0000 Done. Regards, Benoit. > Benoit Claise writes: > >> Jernej, >> >> Well spot. Corrected > Oops, sorry, mea culpa. Unfortunately, there is now a new typo that wasn't in my text: There should be a space between "The" and the left chevron. That is, the correct ToC entry is: > > 12.16. The Annotation ..............................74 > > Thanks, Lada > >>> There's a typo in the corrected entry of Table of Contents. >>> >>> 12.16. The ..............................74 >>> >>> Should be >>> >>> 12.16. The Annotation ..............................74 >>> >>> ("greater than" moved) >>> >>> Jernej >>> >>>> Regards, Benoit. >>>>> Regards, Benoit. >>>>>> /js >>>>>> >>>>> _______________________________________________ >>>>> netmod mailing list >>>>> netmod@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/netmod >>>>> >>>>> >>> From alex@cisco.com Mon Oct 15 11:11: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 4B16621F88C3 for ; Mon, 15 Oct 2012 11:11:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.148 X-Spam-Level: X-Spam-Status: No, score=-10.148 tagged_above=-999 required=5 tests=[AWL=0.450, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1RaKjDO3bXyC for ; Mon, 15 Oct 2012 11:10:58 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 4A4C921F88C8 for ; Mon, 15 Oct 2012 11:10:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12690; q=dns/txt; s=iport; t=1350324658; x=1351534258; h=from:to:cc:subject:date:message-id:mime-version; bh=e4xsx5nQ0LzXZtB+A365YfeYd/+coZSOno3wImDqLF4=; b=Qvg1o3/KdsQKm0HMfjZVRcChbpWzreqT1GiIceg4v6vLjXjvpmf3wsXF FpOAi9lzURGuaJKhWjQ+vuyw2DcgTinlHfr/GD5wmLZ/Fp6fLZ3sDyj+9 ZsOoqT8LHJ+lepuQ2rF3sn6/CmTFRXaIi7226NilF7m0tTCBG48Dp6dLQ U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlQGAGxQfFCtJV2Z/2dsb2JhbABFgkurXYh0AYhmgQiCIgEEEgEaTBIBCCJWJgEEDg0BGYdiC51coBCLboVIYAOXAY0wgWuCbYFbPA X-IronPort-AV: E=Sophos;i="4.80,588,1344211200"; d="scan'208,217";a="131786534" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-7.cisco.com with ESMTP; 15 Oct 2012 18:10:51 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q9FIApwL022054 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 15 Oct 2012 18:10:51 GMT Received: from xmb-rcd-x05.cisco.com ([169.254.15.188]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.02.0318.001; Mon, 15 Oct 2012 13:10:51 -0500 From: "Alexander Clemm (alex)" To: "netmod@ietf.org" Thread-Topic: New revision of Internet Draft for ACL YANG module Thread-Index: Ac2q+f8lcs9sSVmERQSSGGHmCdA4nAAAFShw Date: Mon, 15 Oct 2012 18:10:50 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.154.200.131] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19274.004 x-tm-as-result: No--35.840400-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_DBC595ED2346914F9F81D17DD5C32B570F4F9952xmbrcdx05ciscoc_" MIME-Version: 1.0 Subject: Re: [netmod] New revision of Internet Draft for ACL YANG 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, 15 Oct 2012 18:11:00 -0000 --_000_DBC595ED2346914F9F81D17DD5C32B570F4F9952xmbrcdx05ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello all, We just wanted to let you know that Lisa, Andy, and I have posted revision= 01 of the Internet Draft for the ACL YANG module. We are hoping to discus= s this revision at the IETF meeting in Atlanta. URL: http://www.ietf.org/internet-drafts/draft-huang-netmod-acl= -01.txt Status: http://datatracker.ietf.org/doc/draft-huang-netmod-acl Htmlized: http://tools.ietf.org/html/draft-huang-netmod-acl-01 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-huang-netmod-acl-= 01 Abstract: This document defines a YANG data model for the configuration of Access Control Lists (ACLs) on a device. Here is a summary of the main changes versus revision 00 - "Streamlined" and simplified the design to become more modular. = Specifically, defined common groupings for ACEs (ACE-COMMON) and ACE filte= rs (FILTER-COMMON), that span across different types of ACEs/ACLs and that = are now used by the different containers. - Removed the action to reset counters - Removed the discriminators to distinguish between different ACL = types - Changed capitalizations of node definitions to lower-case to be = more conformant with industry best practices - Added an ACL config example - Added a list of open issues - Some general cleanup We left the remark-or-filter as is - essentially the remark is not just a c= omment for an ACE, which would limit its scope to that ACE, but it is an en= tity in its own right, e.g. used to delineate sections of ACEs in an ACL. = While this may appear a bit odd, this reflects how actual systems behave to= day; retaining this behavior in our opinion will facilitate migration from = CLI. Thank you and kind regards --- Alex --_000_DBC595ED2346914F9F81D17DD5C32B570F4F9952xmbrcdx05ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello all,

 =

We just wanted to let yo= u know that Lisa, Andy, and I have posted  revision 01 of the Internet= Draft for the ACL YANG module.  We are hoping to discuss this revisio= n at the IETF meeting in Atlanta. 

 

URL:       &nb= sp;     http://www.ietf.org/internet-drafts/draft-huang-netmod-acl-01.txt<= /o:p>

Status:       =    http://datatracker.ietf.org/doc/draft-huang-netmod-acl

Htmlized:      &nbs= p; http://tools.ietf.org/html/draft-huang-netmod-acl-01

Diff:       &n= bsp;    http://www.ietf.org/rfcdiff?url2=3Ddraft-huang-netmod-acl-01=

 

Abstract:

   This document defines a YANG data mo= del for the configuration of

   Access Control Lists (ACLs) on a dev= ice.

 

Here is a summary of the= main changes  versus revision 00

- = ;         “Streamlin= ed” and simplified the design to become more modular.  Specifica= lly, defined common groupings for ACEs (ACE-COMMON) and ACE filters (FILTER= -COMMON), that span across different types of ACEs/ACLs and that are now used by the different containers.

- = ;         Removed the acti= on to reset counters

- = ;         Removed the disc= riminators to distinguish between different ACL types

- = ;         Changed capitali= zations of node definitions to lower-case to be more conformant with indust= ry best practices

- = ;         Added an ACL con= fig example

- = ;         Added a list of = open issues

- = ;         Some general cle= anup

 =

We left the remark-or-fi= lter as is – essentially the remark is not just a comment for an ACE,= which would limit its scope to that ACE, but it is an entity in its own ri= ght, e.g. used to delineate sections of ACEs in an ACL.  While this may appear a bit odd, this reflects how actual= systems behave today; retaining this behavior in our opinion will facilita= te migration from CLI. 

 

Thank you and kind regards

--- Alex

--_000_DBC595ED2346914F9F81D17DD5C32B570F4F9952xmbrcdx05ciscoc_-- From reid@snmp.com Wed Oct 17 11:40: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 54CD421F861A for ; Wed, 17 Oct 2012 11:40:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.044 X-Spam-Level: X-Spam-Status: No, score=-2.044 tagged_above=-999 required=5 tests=[AWL=0.555, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oalx0YjX7EHA for ; Wed, 17 Oct 2012 11:40:06 -0700 (PDT) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by ietfa.amsl.com (Postfix) with ESMTP id C936921F856C for ; Wed, 17 Oct 2012 11:40:05 -0700 (PDT) Received: from adminfs.snmp.com (adminfs.snmp.com [192.147.142.39]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id OAA03398 for ; Wed, 17 Oct 2012 14:40:03 -0400 (EDT) Received: from snmp.com (LOCALHOST.snmp.com [127.0.0.1]) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) with ESMTP id OAA06316 for ; Wed, 17 Oct 2012 14:40:00 -0400 (EDT) Message-Id: <201210171840.OAA06316@adminfs.snmp.com> To: netmod@ietf.org Date: Wed, 17 Oct 2012 14:40:00 -0400 From: David Reid Subject: [netmod] capability string for imports X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 17 Oct 2012 18:40:07 -0000 I have a question about the capability string advertised in the message in the case where a YANG module is only needed for importing a typedef. I know this has been discussed before, but I'm not sure if there was a resolution Here is an example: I want to implement TCP-ESTATS-MIB (RFC 4898) in my netconf server. TCP-ESTATS-MIB imports ZeroBasedCounter64 from HCNUM-TC TCP-ESTATS-MIB imports ZeroBasedCounter32 from RMON2-MIB RMON2-MIB imports OwnerString from RMON-MIB (there's more, but that's enough for the example) I convert all of the above MIB modules to yang (following RFC 6643) and build the netconf server with support for TCP-ESTATS-MIB.yang. In the message, clearly I have to advertise TCP-ESTATS-MIB.yang. What about the others? It seems wrong to advertise RMON2-MIB.yang, yet the netconf server really needs information from that module. -David Reid From mbj@tail-f.com Wed Oct 17 11:50: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 A2EA821F8670 for ; Wed, 17 Oct 2012 11:50:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fjyi2rrqjNDY for ; Wed, 17 Oct 2012 11:50:52 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 01A9421F8634 for ; Wed, 17 Oct 2012 11:50:51 -0700 (PDT) Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 1663A1200D5F; Wed, 17 Oct 2012 20:50:50 +0200 (CEST) Date: Wed, 17 Oct 2012 20:50:49 +0200 (CEST) Message-Id: <20121017.205049.467304399.mbj@tail-f.com> To: reid@snmp.com From: Martin Bjorklund In-Reply-To: <201210171840.OAA06316@adminfs.snmp.com> References: <201210171840.OAA06316@adminfs.snmp.com> X-Mailer: Mew version 6.4 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] capability string for imports X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 17 Oct 2012 18:50:53 -0000 David Reid wrote: > I have a question about the capability string advertised in the > message in the case where a YANG module is only needed for importing > a typedef. I know this has been discussed before, but I'm not sure if > there was a resolution > > Here is an example: > > I want to implement TCP-ESTATS-MIB (RFC 4898) in my netconf server. > > TCP-ESTATS-MIB imports ZeroBasedCounter64 from HCNUM-TC > TCP-ESTATS-MIB imports ZeroBasedCounter32 from RMON2-MIB > RMON2-MIB imports OwnerString from RMON-MIB > (there's more, but that's enough for the example) > > I convert all of the above MIB modules to yang (following RFC 6643) and > build the netconf server with support for TCP-ESTATS-MIB.yang. > > In the message, clearly I have to advertise TCP-ESTATS-MIB.yang. > What about the others? It seems wrong to advertise RMON2-MIB.yang, yet > the netconf server really needs information from that module. IMO, you should not advertise e.g. RMON2-MIB. You advertise TCP-ESTATS-MIB, which means that you implement the data nodes (and rpcs, notifs) in that module. But if you implement this module, it is obvious that you also use OwnerString from RMON2-MIB, so there is no point in advertising RMON2-MIB in order to communicate this to the client. /martin From andy@yumaworks.com Wed Oct 17 12:16: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 6600E21F86AB for ; Wed, 17 Oct 2012 12:16:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.718 X-Spam-Level: X-Spam-Status: No, score=-2.718 tagged_above=-999 required=5 tests=[AWL=0.258, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lotn2j07foDB for ; Wed, 17 Oct 2012 12:16:16 -0700 (PDT) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 21E9F21F86A4 for ; Wed, 17 Oct 2012 12:16:15 -0700 (PDT) Received: by mail-la0-f44.google.com with SMTP id b11so5946371lam.31 for ; Wed, 17 Oct 2012 12:16:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=T63SK+VLrkPhkT+hGQf4U49Ez5+3IT4jBU3muISQxYw=; b=MMw3mAX8A9nSQvMRIS9wvrXTqBld1OBXtn4bcpxFR67hKsDwLUXXzcyFDw2aPruLCi BSLg1WISgGYKlKtp4ntiEDTi1H1sPLEWy4tAINCPawD087eKRLIrc689xo/Ue9cz8p1V RlSETIX+yTh7SEnfEh8spSXpvKNaF6waIVcaEo04V3wrA2KIGE1QSWQPKn9LuIwFCTKK FY30D90vnpJFKIHVfcOeGyNjO/8fbB3OndEI79xVlndS5RUH8eE/WSH0tpD9IA84OdNO IBKvGBG+9Z3ox241e3rOWGN1xoIU1QzWTCBsY3n3LkXZgZTmPy4nQCW0pgXAWo75lpon Ov2A== MIME-Version: 1.0 Received: by 10.152.106.162 with SMTP id gv2mr16263777lab.14.1350501374885; Wed, 17 Oct 2012 12:16:14 -0700 (PDT) Received: by 10.112.108.198 with HTTP; Wed, 17 Oct 2012 12:16:14 -0700 (PDT) In-Reply-To: <20121017.205049.467304399.mbj@tail-f.com> References: <201210171840.OAA06316@adminfs.snmp.com> <20121017.205049.467304399.mbj@tail-f.com> Date: Wed, 17 Oct 2012 12:16:14 -0700 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: multipart/alternative; boundary=f46d04083aa5b7feae04cc461ae3 X-Gm-Message-State: ALoCoQlE9Ga/4zyx4QUFVATCm5i8i11A1ZQxkrXgLyJ8yxgztMOEyB8/SRmllxrdBZKMfZvLXvzJ Cc: netmod@ietf.org Subject: Re: [netmod] capability string for imports X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 17 Oct 2012 19:16:17 -0000 --f46d04083aa5b7feae04cc461ae3 Content-Type: text/plain; charset=UTF-8 On Wed, Oct 17, 2012 at 11:50 AM, Martin Bjorklund wrote: > David Reid wrote: > > I have a question about the capability string advertised in the > > message in the case where a YANG module is only needed for importing > > a typedef. I know this has been discussed before, but I'm not sure if > > there was a resolution > > > > Here is an example: > > > > I want to implement TCP-ESTATS-MIB (RFC 4898) in my netconf server. > > > > TCP-ESTATS-MIB imports ZeroBasedCounter64 from HCNUM-TC > > TCP-ESTATS-MIB imports ZeroBasedCounter32 from RMON2-MIB > > RMON2-MIB imports OwnerString from RMON-MIB > > (there's more, but that's enough for the example) > > > > I convert all of the above MIB modules to yang (following RFC 6643) and > > build the netconf server with support for TCP-ESTATS-MIB.yang. > > > > In the message, clearly I have to advertise TCP-ESTATS-MIB.yang. > > What about the others? It seems wrong to advertise RMON2-MIB.yang, yet > > the netconf server really needs information from that module. > > IMO, you should not advertise e.g. RMON2-MIB. > > You advertise TCP-ESTATS-MIB, which means that you implement the data > nodes (and rpcs, notifs) in that module. But if you implement this > module, it is obvious that you also use OwnerString from RMON2-MIB, so > there is no point in advertising RMON2-MIB in order to communicate > this to the client. > > > I disagree that this solves the problem, especially if import-by-revision is not used everywhere. The client needs the revision and namespace. The client needs to match XML namespace URI in the module capability URI to the YANG module namepsace-stmt to be sure it is really dealing with the same module as specified in the import-stmt. The WG was split last time this was discussed between those who think imports should be advertised and those who don't. There are some corner cases, like what if A and B both import C and the version of C used by B is updated, but not the version used by A. Is this allowed? Unless import-by-revision is used, there is no way to tell which version of C is used by A and which by B, even if both C versions are advertised. We plan to augment the /netconf-state/schemas/schema list to solve this problem. Not as good as the but does not impact existing clients at all. > /martin > > > > Andy > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --f46d04083aa5b7feae04cc461ae3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Wed, Oct 17, 2012 at 11:50 AM, Martin= Bjorklund <mbj@tail-f.com> wrote:
David Reid <reid@snmp.com> wrote= :
> I have a question about the capability string advertised in the <he= llo>
> message in the case where a YANG module is only needed for importing > a typedef. I know this has been discussed before, but I'm not sure= if
> there was a resolution
>
> Here is an example:
>
> I want to implement TCP-ESTATS-MIB (RFC 4898) in my netconf server. >
> TCP-ESTATS-MIB imports ZeroBasedCounter64 from HCNUM-TC
> TCP-ESTATS-MIB imports ZeroBasedCounter32 from RMON2-MIB
> RMON2-MIB imports OwnerString from RMON-MIB
> (there's more, but that's enough for the example)
>
> I convert all of the above MIB modules to yang (following RFC 6643) an= d
> build the netconf server with support for TCP-ESTATS-MIB.yang.
>
> In the <hello> message, clearly I have to advertise TCP-ESTATS-M= IB.yang.
> What about the others? It seems wrong to advertise RMON2-MIB.yang, yet=
> the netconf server really needs information from that module.

IMO, you should not advertise e.g. RMON2-MIB.

You advertise TCP-ESTATS-MIB, which means that you implement the data
nodes (and rpcs, notifs) in that module. =C2=A0But if you implement this module, it is obvious that you also use OwnerString from RMON2-MIB, so
there is no point in advertising RMON2-MIB in order to communicate
this to the client.



I disagree that this solves the proble= m, especially if import-by-revision
is not used everywhere. =C2= =A0The client needs the revision and namespace.

Th= e client needs to match XML namespace URI in the module capability URI
to the YANG module namepsace-stmt to be sure it is really dealing
with the same module as specified in the import-stmt.

<= /div>
The WG was split last time this was discussed between those who t= hink
imports should be advertised and those who don't. =C2=A0There are = some
corner cases, like what if A and B both import C and the ver= sion of C used
by B is updated, but not the version used by A. = =C2=A0Is this allowed?
Unless import-by-revision is used, there is no way to tell which versi= on of C=C2=A0
is used by A and which by B, even if both C version= s are advertised.

We plan to augment the /netconf-= state/schemas/schema list to solve this
problem. =C2=A0Not as good as the <hello> but does not impact ex= isting clients
at all.


= =C2=A0
/martin





Andy
=C2=A0



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

--f46d04083aa5b7feae04cc461ae3-- From mbj@tail-f.com Sun Oct 21 06:59: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 C688F21F898A for ; Sun, 21 Oct 2012 06:59:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N5kUmKQZ7iWA for ; Sun, 21 Oct 2012 06:59:50 -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 156D421F898D for ; Sun, 21 Oct 2012 06:59:50 -0700 (PDT) Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id A64D212008B7 for ; Sun, 21 Oct 2012 15:59:47 +0200 (CEST) Date: Sun, 21 Oct 2012 15:59:46 +0200 (CEST) Message-Id: <20121021.155946.517072342.mbj@tail-f.com> To: netmod@ietf.org From: Martin Bjorklund X-Mailer: Mew version 6.4 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] interfaces open issue X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 21 Oct 2012 13:59:50 -0000 Hi, After the recent discussion about interface keying and what a location is, Juergen suggested that we should try to examplify some common implementation use cases, to see if people can agree that the model covers these cases. One concern was if the "location" leaf could be set to the kernel-assigned name (e.g., "eth0"). I think the current text allows this: "The device-specific location of the interface of a particular type. The format of the location string depends on the interface type and the device. but suggestions for improvements are welcome. Below are two implementation examples: * A well controlled router with interfaces named by a physical location. Suppose a router has support for 4 cards, each with 8 ports. The cards are physically numbered from 0 to 3, and the ports on each card from 0 to 7. Each card has fast- or gigabit-ethernet ports. The implementation restricts the names of the interfaces to one of "fastethernet-N/M" or "gigabitethernet-N/M". The "location" of an interface is a string on the form "N/M". The implementation auto-initializes the values for "type" and "location" based on the interface name. An operator can configure a new interface by sending an containing: fastethernet-1/0" 1500 When the server processes this request, it will set the leaf "type" to "ethernetCsmacd" and "location" to "1/0". Thus, if the client performs a right after the above, it will get: fastethernet-1/0" ethernetCsmacd 1/0 1500 If the client tries to change the location of this interface with an containing: fastethernet-1/0" 1/1 then the server will reply with an "invalid-value" error, since the new location does not match the name. * A generic Linux host with (pluggable) interfaces named by the kernel and without easily usable location information. In this case, the implementation allows arbitrary values for "name", and the "location" is the kernel-assigned name for the interface. Suppose the device has two ethernet interfaces, named "eth0" and "eth1" by the kernel. The configuration may look like this: foo ethernetCsmacd eth1 ... When the system boots, an implementation can for example early in the boot procedure issue the command "ip link set eth1 name foo" in order to set the name "foo" in the kernel. If the kernel-assigned name changes from "eth1" to "eth2", e.g., due to the installation of a third ethernet card, the operator can change the "location" leaf of interface "foo", and the rest of the configuration can be left intact, since all references to this interface in the configuration is "foo". /martin From phil@juniper.net Sun Oct 21 12:31: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 01E7521F89FE for ; Sun, 21 Oct 2012 12:31:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M-uGDequWFfK for ; Sun, 21 Oct 2012 12:31:40 -0700 (PDT) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by ietfa.amsl.com (Postfix) with ESMTP id D869121F89AB for ; Sun, 21 Oct 2012 12:31:38 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP ID DSNKUIRNmkhcZ2d3kQ4m5tDNEkIaVAxeoLq1@postini.com; Sun, 21 Oct 2012 12:31:40 PDT Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB03-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.3.213.0; Sun, 21 Oct 2012 12:29:43 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id q9LJTgh67511; Sun, 21 Oct 2012 12:29:43 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.4/8.14.3) with ESMTP id q9LJTf0X041689; Sun, 21 Oct 2012 15:29:41 -0400 (EDT) (envelope-from phil@idle.juniper.net) Message-ID: <201210211929.q9LJTf0X041689@idle.juniper.net> To: Martin Bjorklund In-Reply-To: <20121021.155946.517072342.mbj@tail-f.com> Date: Sun, 21 Oct 2012 15:29:41 -0400 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] interfaces open issue X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 21 Oct 2012 19:31:41 -0000 Martin Bjorklund writes: >If the kernel-assigned name changes from "eth1" to "eth2", e.g., due >to the installation of a third ethernet card, the operator can change >the "location" leaf of interface "foo", and the rest of the >configuration can be left intact, since all references to this >interface in the configuration is "foo". If your kernel is arbitrarily renaming your interfaces, you have a much bigger issue. I don't think this is a real world use case. Modern systems are required to keep consistent SNMP index values, so holding consistent interfaces names is relatively trivial. I'm concerned we've moved from a "this is the way things work" POV to one of "if we could rebuild the world from scratch, it should have looked like this". Operators are completely comfortable with using existing device-assigned interface names. I don't see a real problem being solved by this "location" feature. Thanks, Phil From j.schoenwaelder@jacobs-university.de Mon Oct 22 01:44: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 E593E21F8436 for ; Mon, 22 Oct 2012 01:44:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.225 X-Spam-Level: X-Spam-Status: No, score=-103.225 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IQIC7ival7bE for ; Mon, 22 Oct 2012 01:44: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 D785221F8430 for ; Mon, 22 Oct 2012 01:44:02 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id D44CC20BD5; Mon, 22 Oct 2012 10:44:01 +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 FO7tvugfHTRx; Mon, 22 Oct 2012 10:44: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 5D75220BC1; Mon, 22 Oct 2012 10:44:01 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id E207A225A455; Mon, 22 Oct 2012 10:43:59 +0200 (CEST) Date: Mon, 22 Oct 2012 10:43:59 +0200 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20121022084358.GC96940@elstar.local> Mail-Followup-To: Martin Bjorklund , netmod@ietf.org References: <20121021.155946.517072342.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20121021.155946.517072342.mbj@tail-f.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] interfaces open issue 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, 22 Oct 2012 08:44:04 -0000 Speaking as technical contributor inline... On Sun, Oct 21, 2012 at 03:59:46PM +0200, Martin Bjorklund wrote: > Hi, > > After the recent discussion about interface keying and what a location > is, Juergen suggested that we should try to examplify some common > implementation use cases, to see if people can agree that the model > covers these cases. > > One concern was if the "location" leaf could be set to the > kernel-assigned name (e.g., "eth0"). I think the current text > allows this: > > "The device-specific location of the interface of a > particular type. The format of the location string > depends on the interface type and the device. > > but suggestions for improvements are welcome. > > Below are two implementation examples: > > * A well controlled router with interfaces named by a physical > location. > > Suppose a router has support for 4 cards, each with 8 ports. The > cards are physically numbered from 0 to 3, and the ports on each card > from 0 to 7. Each card has fast- or gigabit-ethernet ports. > > The implementation restricts the names of the interfaces to one of > "fastethernet-N/M" or "gigabitethernet-N/M". The "location" of an > interface is a string on the form "N/M". The implementation > auto-initializes the values for "type" and "location" based on the > interface name. > > An operator can configure a new interface by sending an > containing: > > > fastethernet-1/0" > 1500 > > > When the server processes this request, it will set the leaf "type" to > "ethernetCsmacd" and "location" to "1/0". Thus, if the client > performs a right after the above, it will > get: > > > fastethernet-1/0" > ethernetCsmacd > 1/0 > 1500 > > > If the client tries to change the location of this interface with an > containing: > > > fastethernet-1/0" > 1/1 > > > then the server will reply with an "invalid-value" error, since the > new location does not match the name. How would a generic configuration management application know that an interface name like "fastethernet-1/0" should be used? (Note that there is a " in the name value and that the get-config likely won't return an nc:operation="create" attribute.) > * A generic Linux host with (pluggable) interfaces named by the kernel > and without easily usable location information. > > In this case, the implementation allows arbitrary values for "name", > and the "location" is the kernel-assigned name for the interface. > Suppose the device has two ethernet interfaces, named "eth0" and > "eth1" by the kernel. The configuration may look like this: > > > foo > ethernetCsmacd > eth1 > ... > > > When the system boots, an implementation can for example early in the > boot procedure issue the command "ip link set eth1 name foo" in order > to set the name "foo" in the kernel. > > If the kernel-assigned name changes from "eth1" to "eth2", e.g., due > to the installation of a third ethernet card, the operator can change > the "location" leaf of interface "foo", and the rest of the > configuration can be left intact, since all references to this > interface in the configuration is "foo". I am not sure about this. You are saying the config above forces the name foo by renaming the system's notion of an interface. Is that really what we want? Note that eth1 is gone from the system once you do "ip link set eth1 name foo". I personally think that messing around with system level interface names as side effects is ugly. For me, the key question is whether we want an identity relationship between the value of interface/name and the system's notion of an interface. This is what you seem to have in mind. To allow for interoperability, we should really answer this question in a very clear way. Of course, saying 'yes' ties everything configured related to an interface to the system's notion of an interface. A separate question for me is whether we support renaming of interfaces. If we do, I think a separate mechanism should be introduced or we should acknowledge this as a function to be potentially added later. The third question is how a generic configuration manager knows how to properly configure new interfaces, that is how to learn about interface names and how to generically extract the type and location value out of the name or from some other resources. This likely ties into the operational state discussion but I think we need to be somewhat explicit about this if the goal is really to support generic interoperable configuration management. /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 Oct 22 02:02: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 A075921F8954 for ; Mon, 22 Oct 2012 02:02:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.728 X-Spam-Level: X-Spam-Status: No, score=-1.728 tagged_above=-999 required=5 tests=[AWL=-0.282, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_45=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SPjXdkkLpg+d for ; Mon, 22 Oct 2012 02:02:00 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id F078F21F8870 for ; Mon, 22 Oct 2012 02:01:57 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id DE05E1200AEC; Mon, 22 Oct 2012 11:01:55 +0200 (CEST) Date: Mon, 22 Oct 2012 11:01:55 +0200 (CEST) Message-Id: <20121022.110155.390324588001714813.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20121022084358.GC96940@elstar.local> References: <20121021.155946.517072342.mbj@tail-f.com> <20121022084358.GC96940@elstar.local> X-Mailer: Mew version 6.4 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] interfaces open issue X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 22 Oct 2012 09:02:00 -0000 Juergen Schoenwaelder wrote: > Speaking as technical contributor inline... > > On Sun, Oct 21, 2012 at 03:59:46PM +0200, Martin Bjorklund wrote: > > Hi, > > > > After the recent discussion about interface keying and what a location > > is, Juergen suggested that we should try to examplify some common > > implementation use cases, to see if people can agree that the model > > covers these cases. > > > > One concern was if the "location" leaf could be set to the > > kernel-assigned name (e.g., "eth0"). I think the current text > > allows this: > > > > "The device-specific location of the interface of a > > particular type. The format of the location string > > depends on the interface type and the device. > > > > but suggestions for improvements are welcome. > > > > Below are two implementation examples: > > > > * A well controlled router with interfaces named by a physical > > location. > > > > Suppose a router has support for 4 cards, each with 8 ports. The > > cards are physically numbered from 0 to 3, and the ports on each card > > from 0 to 7. Each card has fast- or gigabit-ethernet ports. > > > > The implementation restricts the names of the interfaces to one of > > "fastethernet-N/M" or "gigabitethernet-N/M". The "location" of an > > interface is a string on the form "N/M". The implementation > > auto-initializes the values for "type" and "location" based on the > > interface name. > > > > An operator can configure a new interface by sending an > > containing: > > > > > > fastethernet-1/0" > > 1500 > > > > > > When the server processes this request, it will set the leaf "type" to > > "ethernetCsmacd" and "location" to "1/0". Thus, if the client > > performs a right after the above, it will > > get: > > > > > > fastethernet-1/0" > > ethernetCsmacd > > 1/0 > > 1500 > > > > > > If the client tries to change the location of this interface with an > > containing: > > > > > > fastethernet-1/0" > > 1/1 > > > > > > then the server will reply with an "invalid-value" error, since the > > new location does not match the name. > > How would a generic configuration management application know that an > interface name like "fastethernet-1/0" should be used? out of scope for this document, just like the location values. As long as we are talking about physical interfaces, a generic configuration management app really needs to get information about the physical name/location from the operator that inserted the cable/card, ... > (Note that > there is a " in the name value and that the get-config likely won't > return an nc:operation="create" attribute.) Yes, copy&paste errors. > > * A generic Linux host with (pluggable) interfaces named by the kernel > > and without easily usable location information. > > > > In this case, the implementation allows arbitrary values for "name", > > and the "location" is the kernel-assigned name for the interface. > > Suppose the device has two ethernet interfaces, named "eth0" and > > "eth1" by the kernel. The configuration may look like this: > > > > > > foo > > ethernetCsmacd > > eth1 > > ... > > > > > > When the system boots, an implementation can for example early in the > > boot procedure issue the command "ip link set eth1 name foo" in order > > to set the name "foo" in the kernel. > > > > If the kernel-assigned name changes from "eth1" to "eth2", e.g., due > > to the installation of a third ethernet card, the operator can change > > the "location" leaf of interface "foo", and the rest of the > > configuration can be left intact, since all references to this > > interface in the configuration is "foo". > > I am not sure about this. You are saying the config above forces the > name foo by renaming the system's notion of an interface. Is that > really what we want? Note that eth1 is gone from the system once you > do "ip link set eth1 name foo". I personally think that messing around > with system level interface names as side effects is ugly. This is just an example. This is one way of doing it. By setting the configured name in the kernel, this name shows up in logs and other interfaces. > For me, the key question is whether we want an identity relationship > between the value of interface/name and the system's notion of an > interface. This is what you seem to have in mind. Personally, I think this is an implementation detail and that we should stay out of it. The idea was to provide an *example* so that people would easier understand how it *could* be done. I guess the risk with examples is that people rather think it is the way it *should* be done... > To allow for > interoperability, we should really answer this question in a very > clear way. Of course, saying 'yes' ties everything configured related > to an interface to the system's notion of an interface. > > A separate question for me is whether we support renaming of > interfaces. If we do, I think a separate mechanism should be > introduced or we should acknowledge this as a function to be > potentially added later. One thing is renaming of interfaces in the configuration. There is no NETCONF support for this in general, and I don't think we should do special rpc operations for some data models. Another thing is renaming of interfaces on the system level. I that is out of scope. /martin From j.schoenwaelder@jacobs-university.de Mon Oct 22 03:14: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 E852121F842C for ; Mon, 22 Oct 2012 03:14:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.225 X-Spam-Level: X-Spam-Status: No, score=-103.225 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C7wg1dJxjaQq for ; Mon, 22 Oct 2012 03:14:04 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id BDA9B21F8427 for ; Mon, 22 Oct 2012 03:14:03 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2206720A13; Mon, 22 Oct 2012 12:14:03 +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 lp98sKpNaioQ; Mon, 22 Oct 2012 12:14:03 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A99D920A1F; Mon, 22 Oct 2012 12:14:02 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 3DD0E225A888; Mon, 22 Oct 2012 12:14:00 +0200 (CEST) Date: Mon, 22 Oct 2012 12:14:00 +0200 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20121022101400.GA97176@elstar.local> Mail-Followup-To: Martin Bjorklund , netmod@ietf.org References: <20121021.155946.517072342.mbj@tail-f.com> <20121022084358.GC96940@elstar.local> <20121022.110155.390324588001714813.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20121022.110155.390324588001714813.mbj@tail-f.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] interfaces open issue 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, 22 Oct 2012 10:14:05 -0000 On Mon, Oct 22, 2012 at 11:01:55AM +0200, Martin Bjorklund wrote: > > > In this case, the implementation allows arbitrary values for "name", > > > and the "location" is the kernel-assigned name for the interface. > > > Suppose the device has two ethernet interfaces, named "eth0" and > > > "eth1" by the kernel. The configuration may look like this: > > > > > > > > > foo > > > ethernetCsmacd > > > eth1 > > > ... > > > > > > > > > When the system boots, an implementation can for example early in the > > > boot procedure issue the command "ip link set eth1 name foo" in order > > > to set the name "foo" in the kernel. > > > > > > If the kernel-assigned name changes from "eth1" to "eth2", e.g., due > > > to the installation of a third ethernet card, the operator can change > > > the "location" leaf of interface "foo", and the rest of the > > > configuration can be left intact, since all references to this > > > interface in the configuration is "foo". > > > > I am not sure about this. You are saying the config above forces the > > name foo by renaming the system's notion of an interface. Is that > > really what we want? Note that eth1 is gone from the system once you > > do "ip link set eth1 name foo". I personally think that messing around > > with system level interface names as side effects is ugly. > > This is just an example. This is one way of doing it. By setting the > configured name in the kernel, this name shows up in logs and other > interfaces. > > > For me, the key question is whether we want an identity relationship > > between the value of interface/name and the system's notion of an > > interface. This is what you seem to have in mind. > > Personally, I think this is an implementation detail and that we > should stay out of it. > > The idea was to provide an *example* so that people would easier > understand how it *could* be done. I guess the risk with examples is > that people rather think it is the way it *should* be done... I believe we need to decide this one way or the other if we want interoperability. In your example, the interface/location value would become meaningless. In another implementation, where interface/name really just names the config not the interface, the interface/location value would be the value that likely shows up in other management interfaces. In the worst case, we will see something like eth2 ethernetCsmacd eth1 ... where it becomes totally unclear how I relate this config snippet to syslog messages etc. I believe we need to settle this if we want interoperability. /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 Oct 22 04:40:20 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 5E0A021F8BC0 for ; Mon, 22 Oct 2012 04:40:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.563 X-Spam-Level: X-Spam-Status: No, score=-1.563 tagged_above=-999 required=5 tests=[AWL=-0.164, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, J_CHICKENPOX_45=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5NpkmRlR-ChN for ; Mon, 22 Oct 2012 04:40:19 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 6029D21F8697 for ; Mon, 22 Oct 2012 04:40:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 712055406BE for ; Mon, 22 Oct 2012 13:40:15 +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 pFxOaPXi+7Sg for ; Mon, 22 Oct 2012 13:40:03 +0200 (CEST) Received: from localhost (unknown [10.107.191.189]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 1C01C5400C8 for ; Mon, 22 Oct 2012 13:39:58 +0200 (CEST) From: Ladislav Lhotka To: netmod@ietf.org In-Reply-To: <20121022.110155.390324588001714813.mbj@tail-f.com> References: <20121021.155946.517072342.mbj@tail-f.com> <20121022084358.GC96940@elstar.local> <20121022.110155.390324588001714813.mbj@tail-f.com> User-Agent: Notmuch/0.14+37~gf227d63 (http://notmuchmail.org) Emacs/23.3.50.1 (i386-apple-darwin9.8.0) Mail-Followup-To: netmod@ietf.org Date: Mon, 22 Oct 2012 13:39:38 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [netmod] interfaces open issue X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 22 Oct 2012 11:40:20 -0000 Martin Bjorklund writes: ... >> >> How would a generic configuration management application know that an >> interface name like "fastethernet-1/0" should be used? > > out of scope for this document, just like the location values. As > long as we are talking about physical interfaces, a generic > configuration management app really needs to get information about the > physical name/location from the operator that inserted the cable/card, > ... I think this information should be available to the client through the NETCONF session, either as state data or via "show"-like RPC methods. That is, the "ietf-interfaces" module should address it. > > >> (Note that >> there is a " in the name value and that the get-config likely won't >> return an nc:operation="create" attribute.) > > Yes, copy&paste errors. > >> > * A generic Linux host with (pluggable) interfaces named by the kernel >> > and without easily usable location information. >> > >> > In this case, the implementation allows arbitrary values for "name", >> > and the "location" is the kernel-assigned name for the interface. >> > Suppose the device has two ethernet interfaces, named "eth0" and >> > "eth1" by the kernel. The configuration may look like this: >> > >> > >> > foo >> > ethernetCsmacd >> > eth1 >> > ... >> > >> > >> > When the system boots, an implementation can for example early in the >> > boot procedure issue the command "ip link set eth1 name foo" in order >> > to set the name "foo" in the kernel. >> > >> > If the kernel-assigned name changes from "eth1" to "eth2", e.g., due >> > to the installation of a third ethernet card, the operator can change >> > the "location" leaf of interface "foo", and the rest of the >> > configuration can be left intact, since all references to this >> > interface in the configuration is "foo". >> >> I am not sure about this. You are saying the config above forces the >> name foo by renaming the system's notion of an interface. Is that >> really what we want? Note that eth1 is gone from the system once you >> do "ip link set eth1 name foo". I personally think that messing around >> with system level interface names as side effects is ugly. > > This is just an example. This is one way of doing it. By setting the > configured name in the kernel, this name shows up in logs and other > interfaces. > >> For me, the key question is whether we want an identity relationship >> between the value of interface/name and the system's notion of an >> interface. This is what you seem to have in mind. > > Personally, I think this is an implementation detail and that we > should stay out of it. I think it is a fundamental question: Do we allow an indirection between the "name" key of an interface entry in the configuration and the system-assigned name? There are three possible answers to this: 1. The "name" key always has to be the same as the system-assigned name. 2. The "name" key as it is used in a NETCONF configuration is independent of the system-assigned name and the relationship is established by other data. 3. #2 on some systems and #1 on others. I think we should decide between #1 or #2, and I personally prefer #2. The draft currently supports #3. Note that #2 is completely unrelated to whether the system-assigned name can be changed or not - the indirection is always resolved within the NETCONF server implementation. Lada > > The idea was to provide an *example* so that people would easier > understand how it *could* be done. I guess the risk with examples is > that people rather think it is the way it *should* be done... > > >> To allow for >> interoperability, we should really answer this question in a very >> clear way. Of course, saying 'yes' ties everything configured related >> to an interface to the system's notion of an interface. >> >> A separate question for me is whether we support renaming of >> interfaces. If we do, I think a separate mechanism should be >> introduced or we should acknowledge this as a function to be >> potentially added later. > > One thing is renaming of interfaces in the configuration. There is no > NETCONF support for this in general, and I don't think we should do > special rpc operations for some data models. > > Another thing is renaming of interfaces on the system level. I that > is out of scope. > > > > /martin > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From mbj@tail-f.com Mon Oct 22 05:09: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 A212121F8B7E for ; Mon, 22 Oct 2012 05:09:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.013 X-Spam-Level: X-Spam-Status: No, score=-2.013 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YKyaaKUWc9vR for ; Mon, 22 Oct 2012 05:09:07 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id C95D621F89B5 for ; Mon, 22 Oct 2012 05:09:06 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 44F681200CFA; Mon, 22 Oct 2012 14:09:05 +0200 (CEST) Date: Mon, 22 Oct 2012 14:09:05 +0200 (CEST) Message-Id: <20121022.140905.2137853138765417515.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20121022101400.GA97176@elstar.local> References: <20121022084358.GC96940@elstar.local> <20121022.110155.390324588001714813.mbj@tail-f.com> <20121022101400.GA97176@elstar.local> X-Mailer: Mew version 6.4 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] interfaces open issue X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 22 Oct 2012 12:09:07 -0000 Juergen Schoenwaelder wrote: > On Mon, Oct 22, 2012 at 11:01:55AM +0200, Martin Bjorklund wrote: > > > > > In this case, the implementation allows arbitrary values for "name", > > > > and the "location" is the kernel-assigned name for the interface. > > > > Suppose the device has two ethernet interfaces, named "eth0" and > > > > "eth1" by the kernel. The configuration may look like this: > > > > > > > > > > > > foo > > > > ethernetCsmacd > > > > eth1 > > > > ... > > > > > > > > > > > > When the system boots, an implementation can for example early in the > > > > boot procedure issue the command "ip link set eth1 name foo" in order > > > > to set the name "foo" in the kernel. > > > > > > > > If the kernel-assigned name changes from "eth1" to "eth2", e.g., due > > > > to the installation of a third ethernet card, the operator can change > > > > the "location" leaf of interface "foo", and the rest of the > > > > configuration can be left intact, since all references to this > > > > interface in the configuration is "foo". > > > > > > I am not sure about this. You are saying the config above forces the > > > name foo by renaming the system's notion of an interface. Is that > > > really what we want? Note that eth1 is gone from the system once you > > > do "ip link set eth1 name foo". I personally think that messing around > > > with system level interface names as side effects is ugly. > > > > This is just an example. This is one way of doing it. By setting the > > configured name in the kernel, this name shows up in logs and other > > interfaces. > > > > > For me, the key question is whether we want an identity relationship > > > between the value of interface/name and the system's notion of an > > > interface. This is what you seem to have in mind. > > > > Personally, I think this is an implementation detail and that we > > should stay out of it. > > > > The idea was to provide an *example* so that people would easier > > understand how it *could* be done. I guess the risk with examples is > > that people rather think it is the way it *should* be done... > > I believe we need to decide this one way or the other if we want > interoperability. Can you elaborate on this? How would the interoperability be hurt if different implementations use different names in the kernel? > In your example, the interface/location value would > become meaningless. In common routers, the name carries both type and location information, yes. > In another implementation, where interface/name > really just names the config not the interface, the interface/location > value would be the value that likely shows up in other management > interfaces. In the worst case, we will see something like > > > eth2 > ethernetCsmacd > eth1 > ... > > > where it becomes totally unclear how I relate this config snippet to > syslog messages etc. 00100101010100101010100101010100111 .... 00100101010100101110100101010100111 .... So we need a rule that says "operators MUST choose meaningful names", to complement your old rule "implementations MUST be bug-free" :) /martin From mbj@tail-f.com Mon Oct 22 05:12: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 E86D321F8B9D for ; Mon, 22 Oct 2012 05:12:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.014 X-Spam-Level: X-Spam-Status: No, score=-2.014 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BbEDJ2ZpFtw7 for ; Mon, 22 Oct 2012 05:12:44 -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 1080221F8A71 for ; Mon, 22 Oct 2012 05:12:44 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 5A0E41200CFA; Mon, 22 Oct 2012 14:12:43 +0200 (CEST) Date: Mon, 22 Oct 2012 14:12:43 +0200 (CEST) Message-Id: <20121022.141243.1687176932462946209.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: References: <20121022084358.GC96940@elstar.local> <20121022.110155.390324588001714813.mbj@tail-f.com> X-Mailer: Mew version 6.4 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] interfaces open issue X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 22 Oct 2012 12:12:45 -0000 Ladislav Lhotka wrote: > Martin Bjorklund writes: > > ... > > >> > >> How would a generic configuration management application know that an > >> interface name like "fastethernet-1/0" should be used? > > > > out of scope for this document, just like the location values. As > > long as we are talking about physical interfaces, a generic > > configuration management app really needs to get information about the > > physical name/location from the operator that inserted the cable/card, > > ... > > I think this information should be available to the client through the > NETCONF session, either as state data or via "show"-like RPC > methods. That is, the "ietf-interfaces" module should address it. I prefer to do this later and leave it out of scope for now. We need to limit our work. > >> For me, the key question is whether we want an identity relationship > >> between the value of interface/name and the system's notion of an > >> interface. This is what you seem to have in mind. > > > > Personally, I think this is an implementation detail and that we > > should stay out of it. > > I think it is a fundamental question: Do we allow an indirection > between the "name" key of an interface entry in the configuration and > the system-assigned name? There are three possible answers to this: > > 1. The "name" key always has to be the same as the system-assigned > name. > > 2. The "name" key as it is used in a NETCONF configuration is > independent of the system-assigned name and the relationship is > established by other data. > > 3. #2 on some systems and #1 on others. > > I think we should decide between #1 or #2, and I personally prefer > #2. But in #2, what prevents one implementation to use the NETCONF name also as the kernel-name? I think #2 and #3 are the same. /martin From lhotka@nic.cz Mon Oct 22 05:36: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 68BC621F88F5 for ; Mon, 22 Oct 2012 05:36:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.86 X-Spam-Level: X-Spam-Status: No, score=-1.86 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9WbqJRlmnTZu for ; Mon, 22 Oct 2012 05:36:18 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 4DC7521F88AF for ; Mon, 22 Oct 2012 05:36:18 -0700 (PDT) Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 0D64E13FDA1; Mon, 22 Oct 2012 14:36:17 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1350909377; bh=i6RFt6qE/+LAmiyb+wvxrJxfWo0UQ/PHz5rLrPo0qxQ=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=QP/cpfQPfHe6evImqUgB5/pHvHCtqv0fA5fZupUzTB9WfrrU+mO+goOfwhFsWQW40 NyQIMXfuqgQjARYE6K9la9YYgOloBhlkXnCoW/P4x07AX04zG3stqGfye2DE6MEO6G 6tPt7sDCipYCcGWEsSvKEqLqdTZfvFXcDUHw4v/Y= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ladislav Lhotka In-Reply-To: <20121022.141243.1687176932462946209.mbj@tail-f.com> Date: Mon, 22 Oct 2012 14:36:12 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8837FA22-BC07-4A52-9FBA-77B69CDDBB63@nic.cz> References: <20121022084358.GC96940@elstar.local> <20121022.110155.390324588001714813.mbj@tail-f.com> <20121022.141243.1687176932462946209.mbj@tail-f.com> To: Martin Bjorklund X-Mailer: Apple Mail (2.1499) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] interfaces open issue X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 22 Oct 2012 12:36:19 -0000 On Oct 22, 2012, at 2:12 PM, Martin Bjorklund wrote: > Ladislav Lhotka wrote: >> Martin Bjorklund writes: >>=20 >> ... >>=20 >>>>=20 >>>> How would a generic configuration management application know that = an >>>> interface name like "fastethernet-1/0" should be used? >>>=20 >>> out of scope for this document, just like the location values. As >>> long as we are talking about physical interfaces, a generic >>> configuration management app really needs to get information about = the >>> physical name/location from the operator that inserted the = cable/card, >>> ... >>=20 >> I think this information should be available to the client through = the >> NETCONF session, either as state data or via "show"-like RPC >> methods. That is, the "ietf-interfaces" module should address it. >=20 > I prefer to do this later and leave it out of scope for now. We need > to limit our work. OK - in fact, the solution may also depend on the outcome of the = forthcoming general discussion on operational state data. =20 >=20 >>>> For me, the key question is whether we want an identity = relationship >>>> between the value of interface/name and the system's notion of an >>>> interface. This is what you seem to have in mind. >>>=20 >>> Personally, I think this is an implementation detail and that we >>> should stay out of it. >>=20 >> I think it is a fundamental question: Do we allow an indirection >> between the "name" key of an interface entry in the configuration and >> the system-assigned name? There are three possible answers to this: >>=20 >> 1. The "name" key always has to be the same as the system-assigned >> name. >>=20 >> 2. The "name" key as it is used in a NETCONF configuration is >> independent of the system-assigned name and the relationship is >> established by other data. >>=20 >> 3. #2 on some systems and #1 on others. >>=20 >> I think we should decide between #1 or #2, and I personally prefer >> #2. >=20 > But in #2, what prevents one implementation to use the NETCONF name > also as the kernel-name? I think #2 and #3 are the same. It is the client who selects the name and #2 means the server has to = accept it. With #3, a server working in the #1 mode would reject any = "name" key that does not correspond to a system-assigned name of an = existing interface. Lada >=20 >=20 > /martin -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From j.schoenwaelder@jacobs-university.de Mon Oct 22 05:51: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 F0D2821F8B3D for ; Mon, 22 Oct 2012 05:51:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.225 X-Spam-Level: X-Spam-Status: No, score=-103.225 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QiIRRa+52bi0 for ; Mon, 22 Oct 2012 05:51:04 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id C167A21F8B32 for ; Mon, 22 Oct 2012 05:51:03 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 21EBA20BD4; Mon, 22 Oct 2012 14:51:03 +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 og5_8WlyQsoe; Mon, 22 Oct 2012 14:51:03 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 94DF320AFE; Mon, 22 Oct 2012 14:51:02 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 0757B225B443; Mon, 22 Oct 2012 14:51:01 +0200 (CEST) Date: Mon, 22 Oct 2012 14:51:01 +0200 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20121022125101.GA97628@elstar.local> Mail-Followup-To: Martin Bjorklund , netmod@ietf.org References: <20121022084358.GC96940@elstar.local> <20121022.110155.390324588001714813.mbj@tail-f.com> <20121022101400.GA97176@elstar.local> <20121022.140905.2137853138765417515.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20121022.140905.2137853138765417515.mbj@tail-f.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] interfaces open issue 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, 22 Oct 2012 12:51:05 -0000 On Mon, Oct 22, 2012 at 02:09:05PM +0200, Martin Bjorklund wrote: > Juergen Schoenwaelder wrote: > > > The idea was to provide an *example* so that people would easier > > > understand how it *could* be done. I guess the risk with examples is > > > that people rather think it is the way it *should* be done... > > > > I believe we need to decide this one way or the other if we want > > interoperability. > > Can you elaborate on this? How would the interoperability be hurt if > different implementations use different names in the kernel? I need to know whether interface/name is just a name for the configuration (choosen by the operator or management application) or whether it is the native system level name of the interface. These are fundamentally different things. If I want to know the system level interface name, I need to know where I get it from. Guessing one out of two values is hampering interoperability. > > In another implementation, where interface/name > > really just names the config not the interface, the interface/location > > value would be the value that likely shows up in other management > > interfaces. In the worst case, we will see something like > > > > > > eth2 > > ethernetCsmacd > > eth1 > > ... > > > > > > where it becomes totally unclear how I relate this config snippet to > > syslog messages etc. > > > 00100101010100101010100101010100111 > .... > > > 00100101010100101110100101010100111 > .... > > > So we need a rule that says "operators MUST choose meaningful names", > to complement your old rule "implementations MUST be bug-free" :) You apparently did not get the point. So let me try to explain: If we allow different semantics of interface/name and interface/location, I have a hard time to correlate say syslog messages to configuration snippets. Is the above interface what syslog reports as eth1 or eth2? I think we need to settle this, one way or the other. For me, option #3 is Lada's enumeration is a failure interoperability wise. It actually forces to use #1 in practice since #2 can't be expected to be supported generally. /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 Oct 22 05:54:51 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 1E00B21F8B8B for ; Mon, 22 Oct 2012 05:54:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.016 X-Spam-Level: X-Spam-Status: No, score=-2.016 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id re4MtsW41rsL for ; Mon, 22 Oct 2012 05:54:50 -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 42D8121F8B70 for ; Mon, 22 Oct 2012 05:54:50 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 83A091200AEC; Mon, 22 Oct 2012 14:54:49 +0200 (CEST) Date: Mon, 22 Oct 2012 14:54:49 +0200 (CEST) Message-Id: <20121022.145449.1170643528858508439.mbj@tail-f.com> To: phil@juniper.net From: Martin Bjorklund In-Reply-To: <201210211929.q9LJTf0X041689@idle.juniper.net> References: <20121021.155946.517072342.mbj@tail-f.com> <201210211929.q9LJTf0X041689@idle.juniper.net> X-Mailer: Mew version 6.4 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] interfaces open issue X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 22 Oct 2012 12:54:51 -0000 Phil Shafer wrote: > Martin Bjorklund writes: > >If the kernel-assigned name changes from "eth1" to "eth2", e.g., due > >to the installation of a third ethernet card, the operator can change > >the "location" leaf of interface "foo", and the rest of the > >configuration can be left intact, since all references to this > >interface in the configuration is "foo". > > If your kernel is arbitrarily renaming your interfaces, you have a > much bigger issue. I don't think this is a real world use case. > Modern systems are required to keep consistent SNMP index values, > so holding consistent interfaces names is relatively trivial. Agreed; but this is a real problem in linux. I also don't think we should worry about this; this is an implementation issue. > I'm concerned we've moved from a "this is the way things work" POV > to one of "if we could rebuild the world from scratch, it should > have looked like this". That's not the intention. There are other devices that use different names than what the kernel uses (see mail from Jeffrey Lange http://www.ietf.org/mail-archive/web/netmod/current/msg07322.html). The are also devices that support arbitrary named interafces (I believe Alcatel-Lucent routers do this for example). The idea with this data model is to be flexible enough to allow such implementations, while at the same time also allow implementations such as junos that uses device-assigned names. /martin From mbj@tail-f.com Mon Oct 22 06:03: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 48FE221F8BC6 for ; Mon, 22 Oct 2012 06:03:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.017 X-Spam-Level: X-Spam-Status: No, score=-2.017 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xw-JtZ5foET6 for ; Mon, 22 Oct 2012 06:03:33 -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 AD7B721F8BC5 for ; Mon, 22 Oct 2012 06:03:33 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 73F111200AEC; Mon, 22 Oct 2012 15:03:32 +0200 (CEST) Date: Mon, 22 Oct 2012 15:03:32 +0200 (CEST) Message-Id: <20121022.150332.1248954481404573987.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20121022125101.GA97628@elstar.local> References: <20121022101400.GA97176@elstar.local> <20121022.140905.2137853138765417515.mbj@tail-f.com> <20121022125101.GA97628@elstar.local> X-Mailer: Mew version 6.4 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] interfaces open issue X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 22 Oct 2012 13:03:34 -0000 Juergen Schoenwaelder wrote: > On Mon, Oct 22, 2012 at 02:09:05PM +0200, Martin Bjorklund wrote: > > Juergen Schoenwaelder wrote: > > > > The idea was to provide an *example* so that people would easier > > > > understand how it *could* be done. I guess the risk with examples is > > > > that people rather think it is the way it *should* be done... > > > > > > I believe we need to decide this one way or the other if we want > > > interoperability. > > > > Can you elaborate on this? How would the interoperability be hurt if > > different implementations use different names in the kernel? > > I need to know whether interface/name is just a name for the > configuration (choosen by the operator or management application) or > whether it is the native system level name of the interface. These are > fundamentally different things. If I want to know the system level > interface name, I need to know where I get it from. Guessing one out > of two values is hampering interoperability. It seems there are two solutions to this problem: 1) Require the name in the config to be the same as the kernel-assigned name. 2) Allow an arbitrary name in the config, but add an additional config false leaf 'local-name' or 'system-name' or something. /martin From j.schoenwaelder@jacobs-university.de Mon Oct 22 06:32:51 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 60D7721F8B7E for ; Mon, 22 Oct 2012 06:32:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.226 X-Spam-Level: X-Spam-Status: No, score=-103.226 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t998G014zt4e for ; Mon, 22 Oct 2012 06:32:50 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id A20D421F8BA8 for ; Mon, 22 Oct 2012 06:32:45 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id B07BF20BD4; Mon, 22 Oct 2012 15:32:44 +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 aKhGzeHprdem; Mon, 22 Oct 2012 15:32: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 1B38920A9B; Mon, 22 Oct 2012 15:32:44 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id C6B24225B79B; Mon, 22 Oct 2012 15:32:42 +0200 (CEST) Date: Mon, 22 Oct 2012 15:32:42 +0200 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20121022133240.GA97741@elstar.local> Mail-Followup-To: Martin Bjorklund , netmod@ietf.org References: <20121022101400.GA97176@elstar.local> <20121022.140905.2137853138765417515.mbj@tail-f.com> <20121022125101.GA97628@elstar.local> <20121022.150332.1248954481404573987.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20121022.150332.1248954481404573987.mbj@tail-f.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] interfaces open issue 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, 22 Oct 2012 13:32:51 -0000 On Mon, Oct 22, 2012 at 03:03:32PM +0200, Martin Bjorklund wrote: > Juergen Schoenwaelder wrote: > > On Mon, Oct 22, 2012 at 02:09:05PM +0200, Martin Bjorklund wrote: > > > Juergen Schoenwaelder wrote: > > > > > The idea was to provide an *example* so that people would easier > > > > > understand how it *could* be done. I guess the risk with examples is > > > > > that people rather think it is the way it *should* be done... > > > > > > > > I believe we need to decide this one way or the other if we want > > > > interoperability. > > > > > > Can you elaborate on this? How would the interoperability be hurt if > > > different implementations use different names in the kernel? > > > > I need to know whether interface/name is just a name for the > > configuration (choosen by the operator or management application) or > > whether it is the native system level name of the interface. These are > > fundamentally different things. If I want to know the system level > > interface name, I need to know where I get it from. Guessing one out > > of two values is hampering interoperability. > > It seems there are two solutions to this problem: > > 1) Require the name in the config to be the same as the > kernel-assigned name. I think this is potentially misleading. The kernel assigns a name, which might be modified during system bootup. Hence, I prefer to talk about system's name of the interface (once the system is out of the boot sequence and running). > 2) Allow an arbitrary name in the config, but add an additional config > false leaf 'local-name' or 'system-name' or something. Is it then required to support arbitrary names? Right now, the problem for me is that I can not predict what the implementation will support. If I use an arbitrary name, how do I link to the system's notion of the interface name if the leaf is config false? I write it as a location and read it back as local-name? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From phil@juniper.net Mon Oct 22 06:38: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 7135C21F8BE8 for ; Mon, 22 Oct 2012 06:38:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NL5Qs-KfwoyS for ; Mon, 22 Oct 2012 06:38:54 -0700 (PDT) Received: from exprod7og115.obsmtp.com (exprod7og115.obsmtp.com [64.18.2.217]) by ietfa.amsl.com (Postfix) with ESMTP id 5291721F8BEA for ; Mon, 22 Oct 2012 06:38:49 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob115.postini.com ([64.18.6.12]) with SMTP ID DSNKUIVMZ94F7zYdMGdmDSQeEmoU4XC0tHc+@postini.com; Mon, 22 Oct 2012 06:38:53 PDT Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB03-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 22 Oct 2012 06:37:22 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id q9MDbLh75208; Mon, 22 Oct 2012 06:37:21 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.4/8.14.3) with ESMTP id q9MDbJ7Q045539; Mon, 22 Oct 2012 09:37:20 -0400 (EDT) (envelope-from phil@idle.juniper.net) Message-ID: <201210221337.q9MDbJ7Q045539@idle.juniper.net> To: Martin Bjorklund In-Reply-To: <20121022.150332.1248954481404573987.mbj@tail-f.com> Date: Mon, 22 Oct 2012 09:37:19 -0400 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] interfaces open issue X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 22 Oct 2012 13:38:54 -0000 Martin Bjorklund writes: >It seems there are two solutions to this problem: > >1) Require the name in the config to be the same as the > kernel-assigned name. > >2) Allow an arbitrary name in the config, but add an additional config > false leaf 'local-name' or 'system-name' or something. Will systems be expected (required) to emit snmp/syslog/etc content with the arbitrary-name or the system-name? Thanks, Phil From mbj@tail-f.com Mon Oct 22 06:39: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 B4A2E21F872E for ; Mon, 22 Oct 2012 06:39:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.019 X-Spam-Level: X-Spam-Status: No, score=-2.019 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fRV3VsJLwvxT for ; Mon, 22 Oct 2012 06:39:08 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 27FEC21F85E2 for ; Mon, 22 Oct 2012 06:39:08 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 8101A1200CFA; Mon, 22 Oct 2012 15:39:06 +0200 (CEST) Date: Mon, 22 Oct 2012 15:39:06 +0200 (CEST) Message-Id: <20121022.153906.1970983210068604573.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20121022133240.GA97741@elstar.local> References: <20121022125101.GA97628@elstar.local> <20121022.150332.1248954481404573987.mbj@tail-f.com> <20121022133240.GA97741@elstar.local> X-Mailer: Mew version 6.4 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] interfaces open issue X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 22 Oct 2012 13:39:08 -0000 Juergen Schoenwaelder wrote: > On Mon, Oct 22, 2012 at 03:03:32PM +0200, Martin Bjorklund wrote: > > Juergen Schoenwaelder wrote: > > > On Mon, Oct 22, 2012 at 02:09:05PM +0200, Martin Bjorklund wrote: > > > > Juergen Schoenwaelder wrote: > > > > > > The idea was to provide an *example* so that people would easier > > > > > > understand how it *could* be done. I guess the risk with examples is > > > > > > that people rather think it is the way it *should* be done... > > > > > > > > > > I believe we need to decide this one way or the other if we want > > > > > interoperability. > > > > > > > > Can you elaborate on this? How would the interoperability be hurt if > > > > different implementations use different names in the kernel? > > > > > > I need to know whether interface/name is just a name for the > > > configuration (choosen by the operator or management application) or > > > whether it is the native system level name of the interface. These are > > > fundamentally different things. If I want to know the system level > > > interface name, I need to know where I get it from. Guessing one out > > > of two values is hampering interoperability. > > > > It seems there are two solutions to this problem: > > > > 1) Require the name in the config to be the same as the > > kernel-assigned name. > > I think this is potentially misleading. The kernel assigns a name, > which might be modified during system bootup. Hence, I prefer to talk > about system's name of the interface (once the system is out of the > boot sequence and running). Ok, rephrase this as: 1) Require the name in the config to be the same as the system's name of the interface. > > 2) Allow an arbitrary name in the config, but add an additional config > > false leaf 'local-name' or 'system-name' or something. > > Is it then required to support arbitrary names? Just like before. MAY restrict. > Right now, the problem > for me is that I can not predict what the implementation will support. > If I use an arbitrary name, how do I link to the system's notion of > the interface name if the leaf is config false? I write it as a > location and read it back as local-name? You might write: name: foo type: ethernetCsmacd location 1/1 and read back system-name: fe-1/1 or on a linux-based system maybe you get back system-name: eth32 /martin From mbj@tail-f.com Mon Oct 22 06:49: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 385BD21F85B8 for ; Mon, 22 Oct 2012 06:49:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.02 X-Spam-Level: X-Spam-Status: No, score=-2.02 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oe4xBGfaBOPe for ; Mon, 22 Oct 2012 06:48: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 8F08921F8B59 for ; Mon, 22 Oct 2012 06:48:59 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 9F3F21200CFA; Mon, 22 Oct 2012 15:48:58 +0200 (CEST) Date: Mon, 22 Oct 2012 15:48:58 +0200 (CEST) Message-Id: <20121022.154858.1376215852744067548.mbj@tail-f.com> To: phil@juniper.net From: Martin Bjorklund In-Reply-To: <201210221337.q9MDbJ7Q045539@idle.juniper.net> References: <20121022.150332.1248954481404573987.mbj@tail-f.com> <201210221337.q9MDbJ7Q045539@idle.juniper.net> X-Mailer: Mew version 6.4 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] interfaces open issue X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 22 Oct 2012 13:49:00 -0000 Phil Shafer wrote: > Martin Bjorklund writes: > >It seems there are two solutions to this problem: > > > >1) Require the name in the config to be the same as the > > kernel-assigned name. > > > >2) Allow an arbitrary name in the config, but add an additional config > > false leaf 'local-name' or 'system-name' or something. > > Will systems be expected (required) to emit snmp/syslog/etc content > with the arbitrary-name or the system-name? I think Juergen's idea was 'system-name'. Of course, if an implementation actually uses the arbitrary name as the system name there is no difference. My worry is that it will be difficult to wrte the definition of 'system-name', since it applies to something we don't standardize (syslog, log files, ...). We'll probably not do it correctly. /martin From phil@juniper.net Mon Oct 22 06:50: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 2B1E621F88F3 for ; Mon, 22 Oct 2012 06:50:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dsZwDQ9icb6x for ; Mon, 22 Oct 2012 06:50:13 -0700 (PDT) Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by ietfa.amsl.com (Postfix) with ESMTP id 019DD21F8894 for ; Mon, 22 Oct 2012 06:50:08 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP ID DSNKUIVPECb/MaR4LEio5K1Xo0ZXe0exPpRi@postini.com; Mon, 22 Oct 2012 06:50:12 PDT Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB03-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 22 Oct 2012 06:48:22 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id q9MDmLh93924; Mon, 22 Oct 2012 06:48:21 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.4/8.14.3) with ESMTP id q9MDmJir045716; Mon, 22 Oct 2012 09:48:20 -0400 (EDT) (envelope-from phil@idle.juniper.net) Message-ID: <201210221348.q9MDmJir045716@idle.juniper.net> To: Martin Bjorklund In-Reply-To: <20121022.153906.1970983210068604573.mbj@tail-f.com> Date: Mon, 22 Oct 2012 09:48:19 -0400 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] interfaces open issue X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 22 Oct 2012 13:50:14 -0000 Martin Bjorklund writes: >You might write: > > name: foo > type: ethernetCsmacd > location 1/1 > >and read back > > system-name: fe-1/1 > >or on a linux-based system maybe you get back > > system-name: eth32 It's not clear if you are talking about writing/reading config here. If so, this seems like a poor API. I shouldn't be making interface instances to find the name of the thing I'm trying to make. Instead, I should be invoking an RPC that returns names based on criteria. Like "what's the name of an unsed ethernet port at location 1/1?" or "if I put an ATM FRU into location "2/2", what would but the interface names?". rpc get-interface-names { input { leaf location { .... } leaf type { ... } leaf ephemeral { type boolean; } ... } output { list interface { key name; leaf name { ... } ... } } } Or something like that.... Thanks, Phil From mbj@tail-f.com Mon Oct 22 07:06: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 4E57821F8BA6 for ; Mon, 22 Oct 2012 07:06:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BrN4Y9sGD7Wy for ; Mon, 22 Oct 2012 07:06:04 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 853D021F8B70 for ; Mon, 22 Oct 2012 07:06:04 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 746421200CFA; Mon, 22 Oct 2012 16:06:03 +0200 (CEST) Date: Mon, 22 Oct 2012 16:06:03 +0200 (CEST) Message-Id: <20121022.160603.1788890117353363179.mbj@tail-f.com> To: phil@juniper.net From: Martin Bjorklund In-Reply-To: <201210221348.q9MDmJir045716@idle.juniper.net> References: <20121022.153906.1970983210068604573.mbj@tail-f.com> <201210221348.q9MDmJir045716@idle.juniper.net> X-Mailer: Mew version 6.4 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] interfaces open issue X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 22 Oct 2012 14:06:05 -0000 Phil Shafer wrote: > Martin Bjorklund writes: > >You might write: > > > > name: foo > > type: ethernetCsmacd > > location 1/1 > > > >and read back > > > > system-name: fe-1/1 > > > >or on a linux-based system maybe you get back > > > > system-name: eth32 > > It's not clear if you are talking about writing/reading config here. To be clear: list interface { config true; key name; leaf name { ...} leaf type { ... } leaf location { ... } leaf system-name { config false; ... } ... } So 'system-name' behaves like 'if-index' in the current draft - they both map the configured interface to some other interface identifier. > If so, this seems like a poor API. I shouldn't be making interface > instances to find the name of the thing I'm trying to make. You don't have to care about the system name until the interface has been created. > Instead, I should be invoking an RPC that returns names based on > criteria. Like "what's the name of an unsed ethernet port at > location 1/1?" or "if I put an ATM FRU into location "2/2", what > would but the interface names?". This solves the problem that I wanted to punt for now... /martin From lhotka@nic.cz Mon Oct 22 08:18: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 A3ECC21F8A10 for ; Mon, 22 Oct 2012 08:18:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.863 X-Spam-Level: X-Spam-Status: No, score=-1.863 tagged_above=-999 required=5 tests=[AWL=0.136, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d3tYBdj3PlSB for ; Mon, 22 Oct 2012 08:18:01 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 7FFB521F8BBC for ; Mon, 22 Oct 2012 08:18:00 -0700 (PDT) Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 5B283140356; Mon, 22 Oct 2012 17:17:59 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1350919079; bh=9jAJR38iDJKy0CINSdr8sEvtDruObu6AXi8S1m1jKrI=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=momdLdQRFbsR13KVPbmWjKDOYu1lio0hAQxwcrZpdgr4Rr/i6kg/Xl/OkCReNVzNn RJc5/nCkBhadAmgAVbNf1T8CwPfhaEtaMIVW4v2RM85lx4gZzRmnkfKR49z5y0656e z7qzwGpKsuvN/wCwCo64c0q3dmAv2L20Tq/iVjGM= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ladislav Lhotka In-Reply-To: <20121022.153906.1970983210068604573.mbj@tail-f.com> Date: Mon, 22 Oct 2012 17:17:54 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <7B828CB8-99F8-4EEB-875E-73A41257CFDF@nic.cz> References: <20121022125101.GA97628@elstar.local> <20121022.150332.1248954481404573987.mbj@tail-f.com> <20121022133240.GA97741@elstar.local> <20121022.153906.1970983210068604573.mbj@tail-f.com> To: Martin Bjorklund X-Mailer: Apple Mail (2.1499) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] interfaces open issue X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 22 Oct 2012 15:18:01 -0000 On Oct 22, 2012, at 3:39 PM, Martin Bjorklund wrote: > Juergen Schoenwaelder wrote: >> On Mon, Oct 22, 2012 at 03:03:32PM +0200, Martin Bjorklund wrote: >>> Juergen Schoenwaelder wrote: >>>> On Mon, Oct 22, 2012 at 02:09:05PM +0200, Martin Bjorklund wrote: >>>>> Juergen Schoenwaelder = wrote: >>>>>>> The idea was to provide an *example* so that people would easier >>>>>>> understand how it *could* be done. I guess the risk with = examples is >>>>>>> that people rather think it is the way it *should* be done... >>>>>>=20 >>>>>> I believe we need to decide this one way or the other if we want >>>>>> interoperability. >>>>>=20 >>>>> Can you elaborate on this? How would the interoperability be hurt = if >>>>> different implementations use different names in the kernel?=20 >>>>=20 >>>> I need to know whether interface/name is just a name for the >>>> configuration (choosen by the operator or management application) = or >>>> whether it is the native system level name of the interface. These = are >>>> fundamentally different things. If I want to know the system level >>>> interface name, I need to know where I get it from. Guessing one = out >>>> of two values is hampering interoperability. >>>=20 >>> It seems there are two solutions to this problem: >>>=20 >>> 1) Require the name in the config to be the same as the >>> kernel-assigned name. >>=20 >> I think this is potentially misleading. The kernel assigns a name, >> which might be modified during system bootup. Hence, I prefer to talk >> about system's name of the interface (once the system is out of the >> boot sequence and running). >=20 > Ok, rephrase this as: >=20 > 1) Require the name in the config to be the same as the > system's name of the interface. >=20 >>> 2) Allow an arbitrary name in the config, but add an additional = config >>> false leaf 'local-name' or 'system-name' or something. >>=20 >> Is it then required to support arbitrary names? >=20 > Just like before. MAY restrict. Well, then it becomes my option #3, right? The same "name" key for an = interface entry then would be accepted by some systems and rejected by = others. This should IMO be avoided. >=20 >> Right now, the problem >> for me is that I can not predict what the implementation will = support. >> If I use an arbitrary name, how do I link to the system's notion of >> the interface name if the leaf is config false? I write it as a >> location and read it back as local-name? >=20 > You might write: >=20 > name: foo > type: ethernetCsmacd > location 1/1 >=20 > and read back >=20 > system-name: fe-1/1 >=20 >=20 > or on a linux-based system maybe you get back >=20 > system-name: eth32 What's then the point of having the (mandatory) "location" leaf? The = client could use "system-name" right away: name: foo type: ethernetCsmacd system-name: fe-1/1 (or eth0) The advantage is that semantics of "system-name" is natural and clear on = all systems I know, while it is not always the case for "location". BTW, note that even the "type" leaf is in fact unnecessary because the = system knows very well what type its interface "fe-1/1" is. Lada >=20 >=20 >=20 >=20 >=20 >=20 > /martin > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From lhotka@nic.cz Mon Oct 22 08:27: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 DDC8021F8C4C for ; Mon, 22 Oct 2012 08:27:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.866 X-Spam-Level: X-Spam-Status: No, score=-1.866 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qoTjwRGPE9CB for ; Mon, 22 Oct 2012 08:27:02 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id D110121F8C3E for ; Mon, 22 Oct 2012 08:27:01 -0700 (PDT) Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 19A33140356; Mon, 22 Oct 2012 17:27:01 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1350919621; bh=+Wg+iAZpLQR1POZHcrDCIArHWon6zLC2oWNvXuhmzrQ=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=fPsa4pWxVII3odkM5oMLr3LOe1x/ihBJkAnrsyxW9dqpXH/wTb8fNwsVj/KZXQElj d0tORwV/beC38koorVd2+YaS535XTYgZjngU9kpRLtcJyAFyq67f/oCl9Eo6XJAHkD ScDUbuGM4Mf7bJbdipJQi54USYS2TNwu9RbDDlx8= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ladislav Lhotka In-Reply-To: <20121022.154858.1376215852744067548.mbj@tail-f.com> Date: Mon, 22 Oct 2012 17:27:00 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8A4BDBEC-8BBA-4B50-83D1-E4AA549D3647@nic.cz> References: <20121022.150332.1248954481404573987.mbj@tail-f.com> <201210221337.q9MDbJ7Q045539@idle.juniper.net> <20121022.154858.1376215852744067548.mbj@tail-f.com> To: Martin Bjorklund X-Mailer: Apple Mail (2.1499) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] interfaces open issue X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 22 Oct 2012 15:27:03 -0000 On Oct 22, 2012, at 3:48 PM, Martin Bjorklund wrote: > Phil Shafer wrote: >> Martin Bjorklund writes: >>> It seems there are two solutions to this problem: >>>=20 >>> 1) Require the name in the config to be the same as the >>> kernel-assigned name. >>>=20 >>> 2) Allow an arbitrary name in the config, but add an additional = config >>> false leaf 'local-name' or 'system-name' or something. >>=20 >> Will systems be expected (required) to emit snmp/syslog/etc content >> with the arbitrary-name or the system-name? >=20 > I think Juergen's idea was 'system-name'. Of course, if an Yes, it should be "system-name". The "name" key should be internal to = the NETCONF configuration, pretty much as the "xml:id" attribute in XML = documents. =20 > implementation actually uses the arbitrary name as the system name > there is no difference. My worry is that it will be difficult to wrte > the definition of 'system-name', since it applies to something we > don't standardize (syslog, log files, ...). We'll probably not do it > correctly. We could use the same definition as RFC 2863: Device's local name for the interface (e.g., the name used at the = device's local console). Lada >=20 >=20 > /martin > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From andy@yumaworks.com Mon Oct 22 08:40: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 1872E21F8A10 for ; Mon, 22 Oct 2012 08:40:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.124 X-Spam-Level: X-Spam-Status: No, score=-2.124 tagged_above=-999 required=5 tests=[AWL=-0.348, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V9hs5c1EAwsW for ; Mon, 22 Oct 2012 08:40:26 -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 2B9A921F8981 for ; Mon, 22 Oct 2012 08:40:01 -0700 (PDT) Received: by mail-lb0-f172.google.com with SMTP id k13so2037884lbo.31 for ; Mon, 22 Oct 2012 08:40:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=arw1EibQt1XaIlV3RRYlKSNylo8GW3qLNRHqOnrx0vY=; b=nyLniYzJVQ7q0upfcvNSIsSLanHNd6vBlpqG1ths/j0jBAUeU5MbsdPDZAhgJwHXuO 3EJB3m5TwcEUE+xD3x88M8hT/k0l4biZp92bKwScxuPwI4UglxwK5EC47arA14ZarcGv JMNz++fLvumVXOZASnnkLU0j4Riqyck6S94fd53d4VdwE+AKVyxFMrDtDLoohKGjH79E NdboBTYfFUz84c6TsGC+RZZc5hHuJscmxzM5ZGKxuJzgBVgwW96dM5eKdb763+p3Stmv mV2UuuAnBDXBn6CVwz64izf3o2WRZ+PJgYbyVJuIkYY+Vd+wKk6uVm4o15YzZVizB36F +dhA== MIME-Version: 1.0 Received: by 10.112.38.228 with SMTP id j4mr3822319lbk.87.1350920400717; Mon, 22 Oct 2012 08:40:00 -0700 (PDT) Received: by 10.112.1.40 with HTTP; Mon, 22 Oct 2012 08:40:00 -0700 (PDT) In-Reply-To: References: <20121021.155946.517072342.mbj@tail-f.com> <20121022084358.GC96940@elstar.local> <20121022.110155.390324588001714813.mbj@tail-f.com> Date: Mon, 22 Oct 2012 08:40:00 -0700 Message-ID: From: Andy Bierman To: netmod@ietf.org Content-Type: multipart/alternative; boundary=e0cb4efe2f129ac61e04cca7aac8 X-Gm-Message-State: ALoCoQkj9li4ZyroaVsbKQ5RqBJZC8rLccoQhYxrOJdBCQdrZjChrqWfmjRdeqB/VvVG+/R2RJ9h Subject: Re: [netmod] interfaces open issue X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 22 Oct 2012 15:40:28 -0000 --e0cb4efe2f129ac61e04cca7aac8 Content-Type: text/plain; charset=UTF-8 Hi, So we are back to the 3 options? 1. The "name" key always has to be the same as the system-assigned name. 2. The "name" key as it is used in a NETCONF configuration is independent of the system-assigned name and the relationship is established by other data. 3. #2 on some systems and #1 on others. We should not try to change the industry interface naming rules. That is not the charter of this WG. The WG was asked to produce an interfaces model that real-world networking devices could use. There have been several custom RPCs proposed that would allow a client to get the system name for an interface, based on its type and location. That is an easily solved problem that the WG seems to insist on ignoring. For now, the current -06 text is close enough. If the server does not like the name used in the create request, then it returns an error. So what's the problem? Andy On Mon, Oct 22, 2012 at 4:39 AM, Ladislav Lhotka wrote: > Martin Bjorklund writes: > > ... > > >> > >> How would a generic configuration management application know that an > >> interface name like "fastethernet-1/0" should be used? > > > > out of scope for this document, just like the location values. As > > long as we are talking about physical interfaces, a generic > > configuration management app really needs to get information about the > > physical name/location from the operator that inserted the cable/card, > > ... > > I think this information should be available to the client through the > NETCONF session, either as state data or via "show"-like RPC methods. That > is, the "ietf-interfaces" module should address it. > > > > > > >> (Note that > >> there is a " in the name value and that the get-config likely won't > >> return an nc:operation="create" attribute.) > > > > Yes, copy&paste errors. > > > >> > * A generic Linux host with (pluggable) interfaces named by the > kernel > >> > and without easily usable location information. > >> > > >> > In this case, the implementation allows arbitrary values for "name", > >> > and the "location" is the kernel-assigned name for the interface. > >> > Suppose the device has two ethernet interfaces, named "eth0" and > >> > "eth1" by the kernel. The configuration may look like this: > >> > > >> > > >> > foo > >> > ethernetCsmacd > >> > eth1 > >> > ... > >> > > >> > > >> > When the system boots, an implementation can for example early in the > >> > boot procedure issue the command "ip link set eth1 name foo" in order > >> > to set the name "foo" in the kernel. > >> > > >> > If the kernel-assigned name changes from "eth1" to "eth2", e.g., due > >> > to the installation of a third ethernet card, the operator can change > >> > the "location" leaf of interface "foo", and the rest of the > >> > configuration can be left intact, since all references to this > >> > interface in the configuration is "foo". > >> > >> I am not sure about this. You are saying the config above forces the > >> name foo by renaming the system's notion of an interface. Is that > >> really what we want? Note that eth1 is gone from the system once you > >> do "ip link set eth1 name foo". I personally think that messing around > >> with system level interface names as side effects is ugly. > > > > This is just an example. This is one way of doing it. By setting the > > configured name in the kernel, this name shows up in logs and other > > interfaces. > > > >> For me, the key question is whether we want an identity relationship > >> between the value of interface/name and the system's notion of an > >> interface. This is what you seem to have in mind. > > > > Personally, I think this is an implementation detail and that we > > should stay out of it. > > I think it is a fundamental question: Do we allow an indirection between > the "name" key of an interface entry in the configuration and the > system-assigned name? There are three possible answers to this: > > 1. The "name" key always has to be the same as the system-assigned name. > > 2. The "name" key as it is used in a NETCONF configuration is independent > of the system-assigned name and the relationship is established by other > data. > > 3. #2 on some systems and #1 on others. > > I think we should decide between #1 or #2, and I personally prefer #2. The > draft currently supports #3. > > Note that #2 is completely unrelated to whether the system-assigned name > can be changed or not - the indirection is always resolved within the > NETCONF server implementation. > > Lada > > > > > The idea was to provide an *example* so that people would easier > > understand how it *could* be done. I guess the risk with examples is > > that people rather think it is the way it *should* be done... > > > > > >> To allow for > >> interoperability, we should really answer this question in a very > >> clear way. Of course, saying 'yes' ties everything configured related > >> to an interface to the system's notion of an interface. > >> > >> A separate question for me is whether we support renaming of > >> interfaces. If we do, I think a separate mechanism should be > >> introduced or we should acknowledge this as a function to be > >> potentially added later. > > > > One thing is renaming of interfaces in the configuration. There is no > > NETCONF support for this in general, and I don't think we should do > > special rpc operations for some data models. > > > > Another thing is renaming of interfaces on the system level. I that > > is out of scope. > > > > > > > > /martin > > _______________________________________________ > > 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 > --e0cb4efe2f129ac61e04cca7aac8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi,

So we are back to the 3 options?

1. The "name" key always has to be the same as the sys= tem-assigned name.

2. The "name" key as it is used in a NETCONF configuratio= n is independent of the system-assigned name and the relationship is establ= ished by other data.

3. #2 on some systems and #1 on others.


We should not try to change the industry interface naming rules.
That is not the charter of this WG. =C2=A0The WG was asked to
=
produce an interfaces model that real-world networking devices could u= se.

There have been several custom RPCs proposed that would= allow
a client to get the system name for an interface, based on= its type
and location. =C2=A0That is an easily solved problem th= at the WG seems
to insist on ignoring.

For now, the current -= 06 text is close enough.
If the server does not like the name use= d in the create request,
then it returns an error. So what's = the problem?


Andy



On Mon, Oct 22, 2012 at 4:39 AM, Ladislav Lhot= ka <lhotka@nic.cz> wrote:
Martin Bjorklund <mbj@tail-f.com> writes:

...

>>
>> How would a generic configuration management application know that= an
>> interface name like "fastethernet-1/0" should be used? >
> out of scope for this document, just like the location values. =C2=A0A= s
> long as we are talking about physical interfaces, a generic
> configuration management app really needs to get information about the=
> physical name/location from the operator that inserted the cable/card,=
> ...

I think this information should be available to the client through the NETC= ONF session, either as state data or via "show"-like RPC methods.= That is, the "ietf-interfaces" module should address it.

>
>
>> =C2=A0(Note that
>> there is a " in the name value and that the get-config likely= won't
>> return an nc:operation=3D"create" attribute.)
>
> Yes, copy&paste errors.
>
>> > * =C2=A0A generic Linux host with (pluggable) interfaces name= d by the kernel
>> > =C2=A0 =C2=A0and without easily usable location information.<= br> >> >
>> > In this case, the implementation allows arbitrary values for = "name",
>> > and the "location" is the kernel-assigned name for = the interface.
>> > Suppose the device has two ethernet interfaces, named "e= th0" and
>> > "eth1" by the kernel. =C2=A0The configuration may l= ook like this:
>> >
>> > =C2=A0 <interface>
>> > =C2=A0 =C2=A0 <name>foo</name>
>> > =C2=A0 =C2=A0 <type>ethernetCsmacd</type>
>> > =C2=A0 =C2=A0 <location>eth1</location>
>> > =C2=A0 =C2=A0 ...
>> > =C2=A0 </interface>
>> >
>> > When the system boots, an implementation can for example earl= y in the
>> > boot procedure issue the command "ip link set eth1 name = foo" in order
>> > to set the name "foo" in the kernel.
>> >
>> > If the kernel-assigned name changes from "eth1" to = "eth2", e.g., due
>> > to the installation of a third ethernet card, the operator ca= n change
>> > the "location" leaf of interface "foo", a= nd the rest of the
>> > configuration can be left intact, since all references to thi= s
>> > interface in the configuration is "foo".
>>
>> I am not sure about this. You are saying the config above forces t= he
>> name foo by renaming the system's notion of an interface. =C2= =A0Is that
>> really what we want? Note that eth1 is gone from the system once y= ou
>> do "ip link set eth1 name foo". I personally think that = messing around
>> with system level interface names as side effects is ugly.
>
> This is just an example. =C2=A0This is one way of doing it. =C2=A0By s= etting the
> configured name in the kernel, this name shows up in logs and other > interfaces.
>
>> For me, the key question is whether we want an identity relationsh= ip
>> between the value of interface/name and the system's notion of= an
>> interface. This is what you seem to have in mind.
>
> Personally, I think this is an implementation detail and that we
> should stay out of it.

I think it is a fundamental question: Do we allow an indirection between th= e "name" key of an interface entry in the configuration and the s= ystem-assigned name? There are three possible answers to this:

1. The "name" key always has to be the same as the system-assigne= d name.

2. The "name" key as it is used in a NETCONF configuration is ind= ependent of the system-assigned name and the relationship is established by= other data.

3. #2 on some systems and #1 on others.

I think we should decide between #1 or #2, and I personally prefer #2. The = draft currently supports #3.

Note that #2 is completely unrelated to whether the system-assigned name ca= n be changed or not - the indirection is always resolved within the NETCONF= server implementation.

Lada

>
> The idea was to provide an *example* so that people would easier
> understand how it *could* be done. =C2=A0I guess the risk with example= s is
> that people rather think it is the way it *should* be done...
>
>
>> To allow for
>> interoperability, we should really answer this question in a very<= br> >> clear way. Of course, saying 'yes' ties everything configu= red related
>> to an interface to the system's notion of an interface.
>>
>> A separate question for me is whether we support renaming of
>> interfaces. If we do, I think a separate mechanism should be
>> introduced or we should acknowledge this as a function to be
>> potentially added later.
>
> One thing is renaming of interfaces in the configuration. =C2=A0There = is no
> NETCONF support for this in general, and I don't think we should d= o
> special rpc operations for some data models.
>
> Another thing is renaming of interfaces on the system level. =C2=A0I t= hat
> is out of scope.
>
>
>
> /martin
> _______________________________________________
> 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

--e0cb4efe2f129ac61e04cca7aac8-- From lhotka@nic.cz Mon Oct 22 08:47: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 F0F7421F8C40 for ; Mon, 22 Oct 2012 08:47:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.568 X-Spam-Level: X-Spam-Status: No, score=-1.568 tagged_above=-999 required=5 tests=[AWL=-0.169, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, J_CHICKENPOX_45=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fn6C3cx-b2mN for ; Mon, 22 Oct 2012 08:47:41 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id B9EB921F8B46 for ; Mon, 22 Oct 2012 08:47:40 -0700 (PDT) Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id BAFE6140356; Mon, 22 Oct 2012 17:47:39 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1350920859; bh=SfbPh2BteinlriBP9KGr+Mta+wIo0xzUYjKz0Drwkw4=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=x1eM1S9G8zG8uldpQ3PaTSp/xQnDsefC0RKeRFQnX53ZYNW85sSyySs7bPh+weg52 VL5DjBVrXdEmECwlCrQ6y4yqbJiXiaGhdgMgOIoUjBiuEvd67cIc1gndvZgsZ8x175 LDkiNyi2tQDsRpXbeStScChThXsSnQyC+3axDhMA= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ladislav Lhotka In-Reply-To: Date: Mon, 22 Oct 2012 17:47:39 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <3C4E018D-6B47-408F-A1C7-52D1139384D5@nic.cz> References: <20121021.155946.517072342.mbj@tail-f.com> <20121022084358.GC96940@elstar.local> <20121022.110155.390324588001714813.mbj@tail-f.com> To: Andy Bierman X-Mailer: Apple Mail (2.1499) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] interfaces open issue X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 22 Oct 2012 15:47:42 -0000 On Oct 22, 2012, at 5:40 PM, Andy Bierman wrote: > Hi, >=20 > So we are back to the 3 options? >=20 > 1. The "name" key always has to be the same as the system-assigned = name. >=20 > 2. The "name" key as it is used in a NETCONF configuration is = independent of the system-assigned name and the relationship is = established by other data. >=20 > 3. #2 on some systems and #1 on others. >=20 >=20 > We should not try to change the industry interface naming rules. > That is not the charter of this WG. The WG was asked to > produce an interfaces model that real-world networking devices could = use. Nobody wants to change the industry interface naming rules, such a name = would be present in "system-name". The question only is whether it makes sense to allow for an indirection = *internal to NETCONF*. This would enable re-assigning a configured stack = of logical interfaces from one physical interface to another. Lada >=20 > There have been several custom RPCs proposed that would allow > a client to get the system name for an interface, based on its type > and location. That is an easily solved problem that the WG seems > to insist on ignoring. >=20 > For now, the current -06 text is close enough. > If the server does not like the name used in the create request, > then it returns an error. So what's the problem? >=20 >=20 > Andy >=20 >=20 >=20 >=20 > On Mon, Oct 22, 2012 at 4:39 AM, Ladislav Lhotka = wrote: > Martin Bjorklund writes: >=20 > ... >=20 > >> > >> How would a generic configuration management application know that = an > >> interface name like "fastethernet-1/0" should be used? > > > > out of scope for this document, just like the location values. As > > long as we are talking about physical interfaces, a generic > > configuration management app really needs to get information about = the > > physical name/location from the operator that inserted the = cable/card, > > ... >=20 > I think this information should be available to the client through the = NETCONF session, either as state data or via "show"-like RPC methods. = That is, the "ietf-interfaces" module should address it. >=20 > > > > > >> (Note that > >> there is a " in the name value and that the get-config likely won't > >> return an nc:operation=3D"create" attribute.) > > > > Yes, copy&paste errors. > > > >> > * A generic Linux host with (pluggable) interfaces named by the = kernel > >> > and without easily usable location information. > >> > > >> > In this case, the implementation allows arbitrary values for = "name", > >> > and the "location" is the kernel-assigned name for the interface. > >> > Suppose the device has two ethernet interfaces, named "eth0" and > >> > "eth1" by the kernel. The configuration may look like this: > >> > > >> > > >> > foo > >> > ethernetCsmacd > >> > eth1 > >> > ... > >> > > >> > > >> > When the system boots, an implementation can for example early in = the > >> > boot procedure issue the command "ip link set eth1 name foo" in = order > >> > to set the name "foo" in the kernel. > >> > > >> > If the kernel-assigned name changes from "eth1" to "eth2", e.g., = due > >> > to the installation of a third ethernet card, the operator can = change > >> > the "location" leaf of interface "foo", and the rest of the > >> > configuration can be left intact, since all references to this > >> > interface in the configuration is "foo". > >> > >> I am not sure about this. You are saying the config above forces = the > >> name foo by renaming the system's notion of an interface. Is that > >> really what we want? Note that eth1 is gone from the system once = you > >> do "ip link set eth1 name foo". I personally think that messing = around > >> with system level interface names as side effects is ugly. > > > > This is just an example. This is one way of doing it. By setting = the > > configured name in the kernel, this name shows up in logs and other > > interfaces. > > > >> For me, the key question is whether we want an identity = relationship > >> between the value of interface/name and the system's notion of an > >> interface. This is what you seem to have in mind. > > > > Personally, I think this is an implementation detail and that we > > should stay out of it. >=20 > I think it is a fundamental question: Do we allow an indirection = between the "name" key of an interface entry in the configuration and = the system-assigned name? There are three possible answers to this: >=20 > 1. The "name" key always has to be the same as the system-assigned = name. >=20 > 2. The "name" key as it is used in a NETCONF configuration is = independent of the system-assigned name and the relationship is = established by other data. >=20 > 3. #2 on some systems and #1 on others. >=20 > I think we should decide between #1 or #2, and I personally prefer #2. = The draft currently supports #3. >=20 > Note that #2 is completely unrelated to whether the system-assigned = name can be changed or not - the indirection is always resolved within = the NETCONF server implementation. >=20 > Lada >=20 > > > > The idea was to provide an *example* so that people would easier > > understand how it *could* be done. I guess the risk with examples = is > > that people rather think it is the way it *should* be done... > > > > > >> To allow for > >> interoperability, we should really answer this question in a very > >> clear way. Of course, saying 'yes' ties everything configured = related > >> to an interface to the system's notion of an interface. > >> > >> A separate question for me is whether we support renaming of > >> interfaces. If we do, I think a separate mechanism should be > >> introduced or we should acknowledge this as a function to be > >> potentially added later. > > > > One thing is renaming of interfaces in the configuration. There is = no > > NETCONF support for this in general, and I don't think we should do > > special rpc operations for some data models. > > > > Another thing is renaming of interfaces on the system level. I that > > is out of scope. > > > > > > > > /martin > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod >=20 > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From andy@yumaworks.com Mon Oct 22 09:22: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 D0D9B21F8B50 for ; Mon, 22 Oct 2012 09:22:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.116 X-Spam-Level: X-Spam-Status: No, score=-2.116 tagged_above=-999 required=5 tests=[AWL=-0.340, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Losjwocobe8P for ; Mon, 22 Oct 2012 09:22:56 -0700 (PDT) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id DAC2021F8B9B for ; Mon, 22 Oct 2012 09:22:50 -0700 (PDT) Received: by mail-la0-f44.google.com with SMTP id b11so2016814lam.31 for ; Mon, 22 Oct 2012 09:22:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=MXYtWpCjBhsadU9KUZBwEM/MOjRmz9Up2krvdvJjLb4=; b=fdnOTpYnaIiJHrbNjkxC3WLqjBqp2rac9xtNtjDwsgsIbcBezGmG0wDY77Ry4uDdcw gkoYZMuFYOyHA5o1llCt5vf1PfBj0hxF66Rhd/b5fwAs+0FEoSdZJEXyr7C9TPWX9hIv K2pgU3+JXzDiP3WRmpiXD0tYACu21tx8azOjDw/RBNecIVA+R5bda+7b0G7mW/0uxzPC 4KnI7DHN1lZlKI7N4yL2Jz//Xx/sFDsCPGsd33LUG2gBIpLszoPkyyJz71MC0n3V+kDq XQsPUNHnAmXjt8Cq8EkOAVj65q+BuGzeVgo+577N8aCjgnT96m7pDjqd+ebnK8lmURjM fGTQ== MIME-Version: 1.0 Received: by 10.112.38.228 with SMTP id j4mr3871544lbk.87.1350922969471; Mon, 22 Oct 2012 09:22:49 -0700 (PDT) Received: by 10.112.1.40 with HTTP; Mon, 22 Oct 2012 09:22:49 -0700 (PDT) In-Reply-To: <3C4E018D-6B47-408F-A1C7-52D1139384D5@nic.cz> References: <20121021.155946.517072342.mbj@tail-f.com> <20121022084358.GC96940@elstar.local> <20121022.110155.390324588001714813.mbj@tail-f.com> <3C4E018D-6B47-408F-A1C7-52D1139384D5@nic.cz> Date: Mon, 22 Oct 2012 09:22:49 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=e0cb4efe2f12b6dab904cca843b9 X-Gm-Message-State: ALoCoQkyqSTPq7mMV6znYg0RYxYBpuZFPmBgZDSokHaHD85rXwBmAWCFp1ZGDzmMmNUx6bH4qHmz Cc: netmod@ietf.org Subject: Re: [netmod] interfaces open issue X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 22 Oct 2012 16:22:58 -0000 --e0cb4efe2f12b6dab904cca843b9 Content-Type: text/plain; charset=UTF-8 On Mon, Oct 22, 2012 at 8:47 AM, Ladislav Lhotka wrote: > > On Oct 22, 2012, at 5:40 PM, Andy Bierman wrote: > > > Hi, > > > > So we are back to the 3 options? > > > > 1. The "name" key always has to be the same as the system-assigned name. > > > > 2. The "name" key as it is used in a NETCONF configuration is > independent of the system-assigned name and the relationship is established > by other data. > > > > 3. #2 on some systems and #1 on others. > > > > > > We should not try to change the industry interface naming rules. > > That is not the charter of this WG. The WG was asked to > > produce an interfaces model that real-world networking devices could use. > > Nobody wants to change the industry interface naming rules, such a name > would be present in "system-name". > The question only is whether it makes sense to allow for an indirection > *internal to NETCONF*. This would enable re-assigning a configured stack of > logical interfaces from one physical interface to another. > > I don't think we should continue tinkering on the interfaces model to handle every possible corner-case. If the server accepts the name "fred" when creating an interface, then it is an implementation detail what that means "internal to NETCONF". If the syslog output says "eth0" then too bad. Not in scope. We should only deal with CRUD operations on interface entries in this revision. Lada > Andy > > > > > There have been several custom RPCs proposed that would allow > > a client to get the system name for an interface, based on its type > > and location. That is an easily solved problem that the WG seems > > to insist on ignoring. > > > > For now, the current -06 text is close enough. > > If the server does not like the name used in the create request, > > then it returns an error. So what's the problem? > > > > > > Andy > > > > > > > > > > On Mon, Oct 22, 2012 at 4:39 AM, Ladislav Lhotka wrote: > > Martin Bjorklund writes: > > > > ... > > > > >> > > >> How would a generic configuration management application know that an > > >> interface name like "fastethernet-1/0" should be used? > > > > > > out of scope for this document, just like the location values. As > > > long as we are talking about physical interfaces, a generic > > > configuration management app really needs to get information about the > > > physical name/location from the operator that inserted the cable/card, > > > ... > > > > I think this information should be available to the client through the > NETCONF session, either as state data or via "show"-like RPC methods. That > is, the "ietf-interfaces" module should address it. > > > > > > > > > > >> (Note that > > >> there is a " in the name value and that the get-config likely won't > > >> return an nc:operation="create" attribute.) > > > > > > Yes, copy&paste errors. > > > > > >> > * A generic Linux host with (pluggable) interfaces named by the > kernel > > >> > and without easily usable location information. > > >> > > > >> > In this case, the implementation allows arbitrary values for "name", > > >> > and the "location" is the kernel-assigned name for the interface. > > >> > Suppose the device has two ethernet interfaces, named "eth0" and > > >> > "eth1" by the kernel. The configuration may look like this: > > >> > > > >> > > > >> > foo > > >> > ethernetCsmacd > > >> > eth1 > > >> > ... > > >> > > > >> > > > >> > When the system boots, an implementation can for example early in > the > > >> > boot procedure issue the command "ip link set eth1 name foo" in > order > > >> > to set the name "foo" in the kernel. > > >> > > > >> > If the kernel-assigned name changes from "eth1" to "eth2", e.g., due > > >> > to the installation of a third ethernet card, the operator can > change > > >> > the "location" leaf of interface "foo", and the rest of the > > >> > configuration can be left intact, since all references to this > > >> > interface in the configuration is "foo". > > >> > > >> I am not sure about this. You are saying the config above forces the > > >> name foo by renaming the system's notion of an interface. Is that > > >> really what we want? Note that eth1 is gone from the system once you > > >> do "ip link set eth1 name foo". I personally think that messing around > > >> with system level interface names as side effects is ugly. > > > > > > This is just an example. This is one way of doing it. By setting the > > > configured name in the kernel, this name shows up in logs and other > > > interfaces. > > > > > >> For me, the key question is whether we want an identity relationship > > >> between the value of interface/name and the system's notion of an > > >> interface. This is what you seem to have in mind. > > > > > > Personally, I think this is an implementation detail and that we > > > should stay out of it. > > > > I think it is a fundamental question: Do we allow an indirection between > the "name" key of an interface entry in the configuration and the > system-assigned name? There are three possible answers to this: > > > > 1. The "name" key always has to be the same as the system-assigned name. > > > > 2. The "name" key as it is used in a NETCONF configuration is > independent of the system-assigned name and the relationship is established > by other data. > > > > 3. #2 on some systems and #1 on others. > > > > I think we should decide between #1 or #2, and I personally prefer #2. > The draft currently supports #3. > > > > Note that #2 is completely unrelated to whether the system-assigned name > can be changed or not - the indirection is always resolved within the > NETCONF server implementation. > > > > Lada > > > > > > > > The idea was to provide an *example* so that people would easier > > > understand how it *could* be done. I guess the risk with examples is > > > that people rather think it is the way it *should* be done... > > > > > > > > >> To allow for > > >> interoperability, we should really answer this question in a very > > >> clear way. Of course, saying 'yes' ties everything configured related > > >> to an interface to the system's notion of an interface. > > >> > > >> A separate question for me is whether we support renaming of > > >> interfaces. If we do, I think a separate mechanism should be > > >> introduced or we should acknowledge this as a function to be > > >> potentially added later. > > > > > > One thing is renaming of interfaces in the configuration. There is no > > > NETCONF support for this in general, and I don't think we should do > > > special rpc operations for some data models. > > > > > > Another thing is renaming of interfaces on the system level. I that > > > is out of scope. > > > > > > > > > > > > /martin > > > _______________________________________________ > > > 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 > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > --e0cb4efe2f12b6dab904cca843b9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Mon, Oct 22, 2012 at 8:47 AM, Ladisla= v Lhotka <lhotka@nic.cz> wrote:
andy@yumaworks.com> wrote:

> Hi,
>
> So we are back to the 3 options?
>
> 1. The "name" key always has to be the same as the system-as= signed name.
>
> 2. The "name" key as it is used in a NETCONF configuration i= s independent of the system-assigned name and the relationship is establish= ed by other data.
>
> 3. #2 on some systems and #1 on others.
>
>
> We should not try to change the industry interface naming rules.
> That is not the charter of this WG. =C2=A0The WG was asked to
> produce an interfaces model that real-world networking devices could u= se.

Nobody wants to change the industry interface naming rules, such a name wou= ld be present in "system-name".
The question only is whether it makes sense to allow for an indirection *in= ternal to NETCONF*. This would enable re-assigning a configured stack of lo= gical interfaces from one physical interface to another.


I don't think we should continue t= inkering on the interfaces model
to handle every possible corner-= case. =C2=A0If the server accepts
the name "fred" when = creating an interface, then it is an
implementation detail what that means "internal to NETCONF".=
If the syslog output says "eth0" then too bad. =C2=A0N= ot in scope.

We should only deal with CRUD operati= ons on interface entries
in this revision.



Lada

Andy

=C2= =A0

>
> There have been several custom RPCs proposed that would allow
> a client to get the system name for an interface, based on its type > and location. =C2=A0That is an easily solved problem that the WG seems=
> to insist on ignoring.
>
> For now, the current -06 text is close enough.
> If the server does not like the name used in the create request,
> then it returns an error. So what's the problem?
>
>
> Andy
>
>
>
>
> On Mon, Oct 22, 2012 at 4:39 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
> Martin Bjorklund <mbj@tail-f.com<= /a>> writes:
>
> ...
>
> >>
> >> How would a generic configuration management application know= that an
> >> interface name like "fastethernet-1/0" should be us= ed?
> >
> > out of scope for this document, just like the location values. = =C2=A0As
> > long as we are talking about physical interfaces, a generic
> > configuration management app really needs to get information abou= t the
> > physical name/location from the operator that inserted the cable/= card,
> > ...
>
> I think this information should be available to the client through the= NETCONF session, either as state data or via "show"-like RPC met= hods. That is, the "ietf-interfaces" module should address it. >
> >
> >
> >> =C2=A0(Note that
> >> there is a " in the name value and that the get-config l= ikely won't
> >> return an nc:operation=3D"create" attribute.)
> >
> > Yes, copy&paste errors.
> >
> >> > * =C2=A0A generic Linux host with (pluggable) interfaces= named by the kernel
> >> > =C2=A0 =C2=A0and without easily usable location informat= ion.
> >> >
> >> > In this case, the implementation allows arbitrary values= for "name",
> >> > and the "location" is the kernel-assigned name= for the interface.
> >> > Suppose the device has two ethernet interfaces, named &q= uot;eth0" and
> >> > "eth1" by the kernel. =C2=A0The configuration = may look like this:
> >> >
> >> > =C2=A0 <interface>
> >> > =C2=A0 =C2=A0 <name>foo</name>
> >> > =C2=A0 =C2=A0 <type>ethernetCsmacd</type> > >> > =C2=A0 =C2=A0 <location>eth1</location>
> >> > =C2=A0 =C2=A0 ...
> >> > =C2=A0 </interface>
> >> >
> >> > When the system boots, an implementation can for example= early in the
> >> > boot procedure issue the command "ip link set eth1 = name foo" in order
> >> > to set the name "foo" in the kernel.
> >> >
> >> > If the kernel-assigned name changes from "eth1"= ; to "eth2", e.g., due
> >> > to the installation of a third ethernet card, the operat= or can change
> >> > the "location" leaf of interface "foo&quo= t;, and the rest of the
> >> > configuration can be left intact, since all references t= o this
> >> > interface in the configuration is "foo".
> >>
> >> I am not sure about this. You are saying the config above for= ces the
> >> name foo by renaming the system's notion of an interface.= =C2=A0Is that
> >> really what we want? Note that eth1 is gone from the system o= nce you
> >> do "ip link set eth1 name foo". I personally think = that messing around
> >> with system level interface names as side effects is ugly. > >
> > This is just an example. =C2=A0This is one way of doing it. =C2= =A0By setting the
> > configured name in the kernel, this name shows up in logs and oth= er
> > interfaces.
> >
> >> For me, the key question is whether we want an identity relat= ionship
> >> between the value of interface/name and the system's noti= on of an
> >> interface. This is what you seem to have in mind.
> >
> > Personally, I think this is an implementation detail and that we<= br> > > should stay out of it.
>
> I think it is a fundamental question: Do we allow an indirection betwe= en the "name" key of an interface entry in the configuration and = the system-assigned name? There are three possible answers to this:
>
> 1. The "name" key always has to be the same as the system-as= signed name.
>
> 2. The "name" key as it is used in a NETCONF configuration i= s independent of the system-assigned name and the relationship is establish= ed by other data.
>
> 3. #2 on some systems and #1 on others.
>
> I think we should decide between #1 or #2, and I personally prefer #2.= The draft currently supports #3.
>
> Note that #2 is completely unrelated to whether the system-assigned na= me can be changed or not - the indirection is always resolved within the NE= TCONF server implementation.
>
> Lada
>
> >
> > The idea was to provide an *example* so that people would easier<= br> > > understand how it *could* be done. =C2=A0I guess the risk with ex= amples is
> > that people rather think it is the way it *should* be done...
> >
> >
> >> To allow for
> >> interoperability, we should really answer this question in a = very
> >> clear way. Of course, saying 'yes' ties everything co= nfigured related
> >> to an interface to the system's notion of an interface. > >>
> >> A separate question for me is whether we support renaming of<= br> > >> interfaces. If we do, I think a separate mechanism should be<= br> > >> introduced or we should acknowledge this as a function to be<= br> > >> potentially added later.
> >
> > One thing is renaming of interfaces in the configuration. =C2=A0T= here is no
> > NETCONF support for this in general, and I don't think we sho= uld do
> > special rpc operations for some data models.
> >
> > Another thing is renaming of interfaces on the system level. =C2= =A0I that
> > is out of scope.
> >
> >
> >
> > /martin
> > _______________________________________________
> > 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
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

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





--e0cb4efe2f12b6dab904cca843b9-- From lhotka@nic.cz Mon Oct 22 11:37: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 8D71221F8972 for ; Mon, 22 Oct 2012 11:37:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.565 X-Spam-Level: X-Spam-Status: No, score=-1.565 tagged_above=-999 required=5 tests=[AWL=-0.166, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, J_CHICKENPOX_45=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sQCvmRyx4jNu for ; Mon, 22 Oct 2012 11:37:38 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 70FF821F88F8 for ; Mon, 22 Oct 2012 11:37:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id BAD085406BE for ; Mon, 22 Oct 2012 20:37:36 +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 doMiuhkgZeln for ; Mon, 22 Oct 2012 20:37:32 +0200 (CEST) Received: from localhost (unknown [10.107.191.189]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 85730540239 for ; Mon, 22 Oct 2012 20:37:28 +0200 (CEST) From: Ladislav Lhotka To: netmod@ietf.org In-Reply-To: References: <20121021.155946.517072342.mbj@tail-f.com> <20121022084358.GC96940@elstar.local> <20121022.110155.390324588001714813.mbj@tail-f.com> <3C4E018D-6B47-408F-A1C7-52D1139384D5@nic.cz> User-Agent: Notmuch/0.14+37~gf227d63 (http://notmuchmail.org) Emacs/23.3.50.1 (i386-apple-darwin9.8.0) Mail-Followup-To: netmod@ietf.org Date: Mon, 22 Oct 2012 20:37:05 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [netmod] interfaces open issue X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 22 Oct 2012 18:37:39 -0000 Andy Bierman writes: > On Mon, Oct 22, 2012 at 8:47 AM, Ladislav Lhotka wrote: > >> >> On Oct 22, 2012, at 5:40 PM, Andy Bierman wrote: >> >> > Hi, >> > >> > So we are back to the 3 options? >> > >> > 1. The "name" key always has to be the same as the system-assigned name. >> > >> > 2. The "name" key as it is used in a NETCONF configuration is >> independent of the system-assigned name and the relationship is established >> by other data. >> > >> > 3. #2 on some systems and #1 on others. >> > >> > >> > We should not try to change the industry interface naming rules. >> > That is not the charter of this WG. The WG was asked to >> > produce an interfaces model that real-world networking devices could use. >> >> Nobody wants to change the industry interface naming rules, such a name >> would be present in "system-name". >> The question only is whether it makes sense to allow for an indirection >> *internal to NETCONF*. This would enable re-assigning a configured stack of >> logical interfaces from one physical interface to another. >> >> > I don't think we should continue tinkering on the interfaces model > to handle every possible corner-case. If the server accepts > the name "fred" when creating an interface, then it is an > implementation detail what that means "internal to NETCONF". > If the syslog output says "eth0" then too bad. Not in scope. So what do you suggest? Do nothing? On 10 September you wrote [1]: I strongly object to undocumented vendor-specific value sets, as identified in this text: A device MAY restrict the allowed values for this leaf, possibly depending on the type and location. This is exactly the type of NMS data-silo design we are trying to avoid in standards. This seems to contradict what you are saying now. Lada [1] http://www.ietf.org/mail-archive/web/netmod/current/msg07192.html > > We should only deal with CRUD operations on interface entries > in this revision. > > > > Lada >> > > Andy > > > >> >> > >> > There have been several custom RPCs proposed that would allow >> > a client to get the system name for an interface, based on its type >> > and location. That is an easily solved problem that the WG seems >> > to insist on ignoring. >> > >> > For now, the current -06 text is close enough. >> > If the server does not like the name used in the create request, >> > then it returns an error. So what's the problem? >> > >> > >> > Andy >> > >> > >> > >> > >> > On Mon, Oct 22, 2012 at 4:39 AM, Ladislav Lhotka wrote: >> > Martin Bjorklund writes: >> > >> > ... >> > >> > >> >> > >> How would a generic configuration management application know that an >> > >> interface name like "fastethernet-1/0" should be used? >> > > >> > > out of scope for this document, just like the location values. As >> > > long as we are talking about physical interfaces, a generic >> > > configuration management app really needs to get information about the >> > > physical name/location from the operator that inserted the cable/card, >> > > ... >> > >> > I think this information should be available to the client through the >> NETCONF session, either as state data or via "show"-like RPC methods. That >> is, the "ietf-interfaces" module should address it. >> > >> > > >> > > >> > >> (Note that >> > >> there is a " in the name value and that the get-config likely won't >> > >> return an nc:operation="create" attribute.) >> > > >> > > Yes, copy&paste errors. >> > > >> > >> > * A generic Linux host with (pluggable) interfaces named by the >> kernel >> > >> > and without easily usable location information. >> > >> > >> > >> > In this case, the implementation allows arbitrary values for "name", >> > >> > and the "location" is the kernel-assigned name for the interface. >> > >> > Suppose the device has two ethernet interfaces, named "eth0" and >> > >> > "eth1" by the kernel. The configuration may look like this: >> > >> > >> > >> > >> > >> > foo >> > >> > ethernetCsmacd >> > >> > eth1 >> > >> > ... >> > >> > >> > >> > >> > >> > When the system boots, an implementation can for example early in >> the >> > >> > boot procedure issue the command "ip link set eth1 name foo" in >> order >> > >> > to set the name "foo" in the kernel. >> > >> > >> > >> > If the kernel-assigned name changes from "eth1" to "eth2", e.g., due >> > >> > to the installation of a third ethernet card, the operator can >> change >> > >> > the "location" leaf of interface "foo", and the rest of the >> > >> > configuration can be left intact, since all references to this >> > >> > interface in the configuration is "foo". >> > >> >> > >> I am not sure about this. You are saying the config above forces the >> > >> name foo by renaming the system's notion of an interface. Is that >> > >> really what we want? Note that eth1 is gone from the system once you >> > >> do "ip link set eth1 name foo". I personally think that messing around >> > >> with system level interface names as side effects is ugly. >> > > >> > > This is just an example. This is one way of doing it. By setting the >> > > configured name in the kernel, this name shows up in logs and other >> > > interfaces. >> > > >> > >> For me, the key question is whether we want an identity relationship >> > >> between the value of interface/name and the system's notion of an >> > >> interface. This is what you seem to have in mind. >> > > >> > > Personally, I think this is an implementation detail and that we >> > > should stay out of it. >> > >> > I think it is a fundamental question: Do we allow an indirection between >> the "name" key of an interface entry in the configuration and the >> system-assigned name? There are three possible answers to this: >> > >> > 1. The "name" key always has to be the same as the system-assigned name. >> > >> > 2. The "name" key as it is used in a NETCONF configuration is >> independent of the system-assigned name and the relationship is established >> by other data. >> > >> > 3. #2 on some systems and #1 on others. >> > >> > I think we should decide between #1 or #2, and I personally prefer #2. >> The draft currently supports #3. >> > >> > Note that #2 is completely unrelated to whether the system-assigned name >> can be changed or not - the indirection is always resolved within the >> NETCONF server implementation. >> > >> > Lada >> > >> > > >> > > The idea was to provide an *example* so that people would easier >> > > understand how it *could* be done. I guess the risk with examples is >> > > that people rather think it is the way it *should* be done... >> > > >> > > >> > >> To allow for >> > >> interoperability, we should really answer this question in a very >> > >> clear way. Of course, saying 'yes' ties everything configured related >> > >> to an interface to the system's notion of an interface. >> > >> >> > >> A separate question for me is whether we support renaming of >> > >> interfaces. If we do, I think a separate mechanism should be >> > >> introduced or we should acknowledge this as a function to be >> > >> potentially added later. >> > > >> > > One thing is renaming of interfaces in the configuration. There is no >> > > NETCONF support for this in general, and I don't think we should do >> > > special rpc operations for some data models. >> > > >> > > Another thing is renaming of interfaces on the system level. I that >> > > is out of scope. >> > > >> > > >> > > >> > > /martin >> > > _______________________________________________ >> > > 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 >> > >> > _______________________________________________ >> > 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 andy@yumaworks.com Mon Oct 22 11:50: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 88A0D21F8525 for ; Mon, 22 Oct 2012 11:50:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.109 X-Spam-Level: X-Spam-Status: No, score=-2.109 tagged_above=-999 required=5 tests=[AWL=-0.333, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g-Gx2n6myo-Z for ; Mon, 22 Oct 2012 11:50:22 -0700 (PDT) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 667B821F84FE for ; Mon, 22 Oct 2012 11:50:21 -0700 (PDT) Received: by mail-la0-f44.google.com with SMTP id b11so2116304lam.31 for ; Mon, 22 Oct 2012 11:50:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=Ykrb/ndnyqXAXOpPZFYqbdHN84MORslwSDvIxhTp53U=; b=esg3uMzeJpKQxUMqplfhnSry3f20SczpUbUH6gVOqstcxe6fOhCUQIcWCVB0v9C3c0 IaQ6yBcqqeiDW1mjr90a98cCXuKfD9t/RhzfR3LIjUTnrIK2JCxPmWR+MkaozXEDopgx gRsUUeTxlE4Pt3IDely7eSo6f1o+d9L9JOILmZ7ttKBrIo1IVfPsi+R5w5zgapuePL0/ +BnP9uQy2shIwbmKNpP0ONkx1+o4Jsz+XXISXpzZQO+z2BO6XgOOY0ehqs/3QeoSWRwW dnmcZP5/nZSNzY5l7TO4T2sXdn0SL6rF3G8MGhtpDveSrWYK1gjmUwfJdl97Inxy+AoY XbGQ== MIME-Version: 1.0 Received: by 10.112.28.98 with SMTP id a2mr3961530lbh.110.1350931820199; Mon, 22 Oct 2012 11:50:20 -0700 (PDT) Received: by 10.112.1.40 with HTTP; Mon, 22 Oct 2012 11:50:20 -0700 (PDT) In-Reply-To: References: <20121021.155946.517072342.mbj@tail-f.com> <20121022084358.GC96940@elstar.local> <20121022.110155.390324588001714813.mbj@tail-f.com> <3C4E018D-6B47-408F-A1C7-52D1139384D5@nic.cz> Date: Mon, 22 Oct 2012 11:50:20 -0700 Message-ID: From: Andy Bierman To: netmod@ietf.org Content-Type: multipart/alternative; boundary=bcaec554de464240d804ccaa53c6 X-Gm-Message-State: ALoCoQlsif+1qpVYGm4sDCaSKpOVZ9snULxgk4HcVfvf0wnEZgsyF+BCk29Nv2jyV9HjfjLKGbw2 Subject: Re: [netmod] interfaces open issue X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 22 Oct 2012 18:50:23 -0000 --bcaec554de464240d804ccaa53c6 Content-Type: text/plain; charset=UTF-8 On Mon, Oct 22, 2012 at 11:37 AM, Ladislav Lhotka wrote: > Andy Bierman writes: > > > On Mon, Oct 22, 2012 at 8:47 AM, Ladislav Lhotka wrote: > > > >> > >> On Oct 22, 2012, at 5:40 PM, Andy Bierman wrote: > >> > >> > Hi, > >> > > >> > So we are back to the 3 options? > >> > > >> > 1. The "name" key always has to be the same as the system-assigned > name. > >> > > >> > 2. The "name" key as it is used in a NETCONF configuration is > >> independent of the system-assigned name and the relationship is > established > >> by other data. > >> > > >> > 3. #2 on some systems and #1 on others. > >> > > >> > > >> > We should not try to change the industry interface naming rules. > >> > That is not the charter of this WG. The WG was asked to > >> > produce an interfaces model that real-world networking devices could > use. > >> > >> Nobody wants to change the industry interface naming rules, such a name > >> would be present in "system-name". > >> The question only is whether it makes sense to allow for an indirection > >> *internal to NETCONF*. This would enable re-assigning a configured > stack of > >> logical interfaces from one physical interface to another. > >> > >> > > I don't think we should continue tinkering on the interfaces model > > to handle every possible corner-case. If the server accepts > > the name "fred" when creating an interface, then it is an > > implementation detail what that means "internal to NETCONF". > > If the syslog output says "eth0" then too bad. Not in scope. > > So what do you suggest? Do nothing? > > On 10 September you wrote [1]: > > I strongly object to undocumented vendor-specific value sets, > as identified in this text: > > A device MAY restrict the allowed values for this leaf, > possibly depending on the type and location. > > This is exactly the type of NMS data-silo design we are trying to > avoid in standards. > > This seems to contradict what you are saying now. > > Yes -- then I realized we could get around this restriction just by adding a custom RPC that gives the client a mapping between (type, location) and a name. No data-silo. Problem solved. Lada > Andy > [1] http://www.ietf.org/mail-archive/web/netmod/current/msg07192.html > > > > > We should only deal with CRUD operations on interface entries > > in this revision. > > > > > > > > Lada > >> > > > > Andy > > > > > > > >> > >> > > >> > There have been several custom RPCs proposed that would allow > >> > a client to get the system name for an interface, based on its type > >> > and location. That is an easily solved problem that the WG seems > >> > to insist on ignoring. > >> > > >> > For now, the current -06 text is close enough. > >> > If the server does not like the name used in the create request, > >> > then it returns an error. So what's the problem? > >> > > >> > > >> > Andy > >> > > >> > > >> > > >> > > >> > On Mon, Oct 22, 2012 at 4:39 AM, Ladislav Lhotka > wrote: > >> > Martin Bjorklund writes: > >> > > >> > ... > >> > > >> > >> > >> > >> How would a generic configuration management application know that > an > >> > >> interface name like "fastethernet-1/0" should be used? > >> > > > >> > > out of scope for this document, just like the location values. As > >> > > long as we are talking about physical interfaces, a generic > >> > > configuration management app really needs to get information about > the > >> > > physical name/location from the operator that inserted the > cable/card, > >> > > ... > >> > > >> > I think this information should be available to the client through the > >> NETCONF session, either as state data or via "show"-like RPC methods. > That > >> is, the "ietf-interfaces" module should address it. > >> > > >> > > > >> > > > >> > >> (Note that > >> > >> there is a " in the name value and that the get-config likely won't > >> > >> return an nc:operation="create" attribute.) > >> > > > >> > > Yes, copy&paste errors. > >> > > > >> > >> > * A generic Linux host with (pluggable) interfaces named by the > >> kernel > >> > >> > and without easily usable location information. > >> > >> > > >> > >> > In this case, the implementation allows arbitrary values for > "name", > >> > >> > and the "location" is the kernel-assigned name for the interface. > >> > >> > Suppose the device has two ethernet interfaces, named "eth0" and > >> > >> > "eth1" by the kernel. The configuration may look like this: > >> > >> > > >> > >> > > >> > >> > foo > >> > >> > ethernetCsmacd > >> > >> > eth1 > >> > >> > ... > >> > >> > > >> > >> > > >> > >> > When the system boots, an implementation can for example early in > >> the > >> > >> > boot procedure issue the command "ip link set eth1 name foo" in > >> order > >> > >> > to set the name "foo" in the kernel. > >> > >> > > >> > >> > If the kernel-assigned name changes from "eth1" to "eth2", e.g., > due > >> > >> > to the installation of a third ethernet card, the operator can > >> change > >> > >> > the "location" leaf of interface "foo", and the rest of the > >> > >> > configuration can be left intact, since all references to this > >> > >> > interface in the configuration is "foo". > >> > >> > >> > >> I am not sure about this. You are saying the config above forces > the > >> > >> name foo by renaming the system's notion of an interface. Is that > >> > >> really what we want? Note that eth1 is gone from the system once > you > >> > >> do "ip link set eth1 name foo". I personally think that messing > around > >> > >> with system level interface names as side effects is ugly. > >> > > > >> > > This is just an example. This is one way of doing it. By setting > the > >> > > configured name in the kernel, this name shows up in logs and other > >> > > interfaces. > >> > > > >> > >> For me, the key question is whether we want an identity > relationship > >> > >> between the value of interface/name and the system's notion of an > >> > >> interface. This is what you seem to have in mind. > >> > > > >> > > Personally, I think this is an implementation detail and that we > >> > > should stay out of it. > >> > > >> > I think it is a fundamental question: Do we allow an indirection > between > >> the "name" key of an interface entry in the configuration and the > >> system-assigned name? There are three possible answers to this: > >> > > >> > 1. The "name" key always has to be the same as the system-assigned > name. > >> > > >> > 2. The "name" key as it is used in a NETCONF configuration is > >> independent of the system-assigned name and the relationship is > established > >> by other data. > >> > > >> > 3. #2 on some systems and #1 on others. > >> > > >> > I think we should decide between #1 or #2, and I personally prefer #2. > >> The draft currently supports #3. > >> > > >> > Note that #2 is completely unrelated to whether the system-assigned > name > >> can be changed or not - the indirection is always resolved within the > >> NETCONF server implementation. > >> > > >> > Lada > >> > > >> > > > >> > > The idea was to provide an *example* so that people would easier > >> > > understand how it *could* be done. I guess the risk with examples > is > >> > > that people rather think it is the way it *should* be done... > >> > > > >> > > > >> > >> To allow for > >> > >> interoperability, we should really answer this question in a very > >> > >> clear way. Of course, saying 'yes' ties everything configured > related > >> > >> to an interface to the system's notion of an interface. > >> > >> > >> > >> A separate question for me is whether we support renaming of > >> > >> interfaces. If we do, I think a separate mechanism should be > >> > >> introduced or we should acknowledge this as a function to be > >> > >> potentially added later. > >> > > > >> > > One thing is renaming of interfaces in the configuration. There is > no > >> > > NETCONF support for this in general, and I don't think we should do > >> > > special rpc operations for some data models. > >> > > > >> > > Another thing is renaming of interfaces on the system level. I that > >> > > is out of scope. > >> > > > >> > > > >> > > > >> > > /martin > >> > > _______________________________________________ > >> > > 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 > >> > > >> > _______________________________________________ > >> > 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 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --bcaec554de464240d804ccaa53c6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Mon, Oct 22, 2012 at 11:37 AM, Ladisl= av Lhotka <lhotka@nic.cz> wrote:
Andy Bierman <andy@yumaworks.com> writes:

> On Mon, Oct 22, 2012 at 8:47 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
>
>>
>> On Oct 22, 2012, at 5:40 PM, Andy Bierman <andy@yumaworks.com> wrote:
>>
>> > Hi,
>> >
>> > So we are back to the 3 options?
>> >
>> > 1. The "name" key always has to be the same as the = system-assigned name.
>> >
>> > 2. The "name" key as it is used in a NETCONF config= uration is
>> independent of the system-assigned name and the relationship is es= tablished
>> by other data.
>> >
>> > 3. #2 on some systems and #1 on others.
>> >
>> >
>> > We should not try to change the industry interface naming rul= es.
>> > That is not the charter of this WG. =C2=A0The WG was asked to=
>> > produce an interfaces model that real-world networking device= s could use.
>>
>> Nobody wants to change the industry interface naming rules, such a= name
>> would be present in "system-name".
>> The question only is whether it makes sense to allow for an indire= ction
>> *internal to NETCONF*. This would enable re-assigning a configured= stack of
>> logical interfaces from one physical interface to another.
>>
>>
> I don't think we should continue tinkering on the interfaces model=
> to handle every possible corner-case. =C2=A0If the server accepts
> the name "fred" when creating an interface, then it is an > implementation detail what that means "internal to NETCONF".=
> If the syslog output says "eth0" then too bad. =C2=A0Not in = scope.

So what do you suggest? Do nothing?

On 10 September you wrote [1]:

=C2=A0 =C2=A0 =C2=A0 I strongly object to undocumented vendor-specific valu= e sets,
=C2=A0 =C2=A0 =C2=A0 as identified in this text:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 A device MAY restrict the allowed= values for this leaf,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 possibly depending on the type an= d location.

=C2=A0 =C2=A0 =C2=A0 This is exactly the type of NMS data-silo design we ar= e trying to
=C2=A0 =C2=A0 =C2=A0 avoid in standards.

This seems to contradict what you are saying now.


Yes -- then I realized we could get ar= ound this restriction just
by adding a custom RPC that gives the = client a mapping
between (type, location) and a name. =C2=A0No da= ta-silo. =C2=A0Problem solved.

Lada

Andy
=C2=A0

[1] http://www.ietf.org/mail-archive/web/netmod/curren= t/msg07192.html

>
> We should only deal with CRUD operations on interface entries
> in this revision.
>
>
>
> Lada
>>
>
> Andy
>
>
>
>>
>> >
>> > There have been several custom RPCs proposed that would allow=
>> > a client to get the system name for an interface, based on it= s type
>> > and location. =C2=A0That is an easily solved problem that the= WG seems
>> > to insist on ignoring.
>> >
>> > For now, the current -06 text is close enough.
>> > If the server does not like the name used in the create reque= st,
>> > then it returns an error. So what's the problem?
>> >
>> >
>> > Andy
>> >
>> >
>> >
>> >
>> > On Mon, Oct 22, 2012 at 4:39 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
>> > Martin Bjorklund <mbj@ta= il-f.com> writes:
>> >
>> > ...
>> >
>> > >>
>> > >> How would a generic configuration management applica= tion know that an
>> > >> interface name like "fastethernet-1/0" sho= uld be used?
>> > >
>> > > out of scope for this document, just like the location v= alues. =C2=A0As
>> > > long as we are talking about physical interfaces, a gene= ric
>> > > configuration management app really needs to get informa= tion about the
>> > > physical name/location from the operator that inserted t= he cable/card,
>> > > ...
>> >
>> > I think this information should be available to the client th= rough the
>> NETCONF session, either as state data or via "show"-like= RPC methods. That
>> is, the "ietf-interfaces" module should address it.
>> >
>> > >
>> > >
>> > >> =C2=A0(Note that
>> > >> there is a " in the name value and that the get= -config likely won't
>> > >> return an nc:operation=3D"create" attribut= e.)
>> > >
>> > > Yes, copy&paste errors.
>> > >
>> > >> > * =C2=A0A generic Linux host with (pluggable) i= nterfaces named by the
>> kernel
>> > >> > =C2=A0 =C2=A0and without easily usable location= information.
>> > >> >
>> > >> > In this case, the implementation allows arbitra= ry values for "name",
>> > >> > and the "location" is the kernel-assi= gned name for the interface.
>> > >> > Suppose the device has two ethernet interfaces,= named "eth0" and
>> > >> > "eth1" by the kernel. =C2=A0The confi= guration may look like this:
>> > >> >
>> > >> > =C2=A0 <interface>
>> > >> > =C2=A0 =C2=A0 <name>foo</name>
>> > >> > =C2=A0 =C2=A0 <type>ethernetCsmacd</ty= pe>
>> > >> > =C2=A0 =C2=A0 <location>eth1</location= >
>> > >> > =C2=A0 =C2=A0 ...
>> > >> > =C2=A0 </interface>
>> > >> >
>> > >> > When the system boots, an implementation can fo= r example early in
>> the
>> > >> > boot procedure issue the command "ip link = set eth1 name foo" in
>> order
>> > >> > to set the name "foo" in the kernel.<= br> >> > >> >
>> > >> > If the kernel-assigned name changes from "= eth1" to "eth2", e.g., due
>> > >> > to the installation of a third ethernet card, t= he operator can
>> change
>> > >> > the "location" leaf of interface &quo= t;foo", and the rest of the
>> > >> > configuration can be left intact, since all ref= erences to this
>> > >> > interface in the configuration is "foo&quo= t;.
>> > >>
>> > >> I am not sure about this. You are saying the config = above forces the
>> > >> name foo by renaming the system's notion of an i= nterface. =C2=A0Is that
>> > >> really what we want? Note that eth1 is gone from the= system once you
>> > >> do "ip link set eth1 name foo". I personal= ly think that messing around
>> > >> with system level interface names as side effects is= ugly.
>> > >
>> > > This is just an example. =C2=A0This is one way of doing = it. =C2=A0By setting the
>> > > configured name in the kernel, this name shows up in log= s and other
>> > > interfaces.
>> > >
>> > >> For me, the key question is whether we want an ident= ity relationship
>> > >> between the value of interface/name and the system&#= 39;s notion of an
>> > >> interface. This is what you seem to have in mind. >> > >
>> > > Personally, I think this is an implementation detail and= that we
>> > > should stay out of it.
>> >
>> > I think it is a fundamental question: Do we allow an indirect= ion between
>> the "name" key of an interface entry in the configuratio= n and the
>> system-assigned name? There are three possible answers to this: >> >
>> > 1. The "name" key always has to be the same as the = system-assigned name.
>> >
>> > 2. The "name" key as it is used in a NETCONF config= uration is
>> independent of the system-assigned name and the relationship is es= tablished
>> by other data.
>> >
>> > 3. #2 on some systems and #1 on others.
>> >
>> > I think we should decide between #1 or #2, and I personally p= refer #2.
>> The draft currently supports #3.
>> >
>> > Note that #2 is completely unrelated to whether the system-as= signed name
>> can be changed or not - the indirection is always resolved within = the
>> NETCONF server implementation.
>> >
>> > Lada
>> >
>> > >
>> > > The idea was to provide an *example* so that people woul= d easier
>> > > understand how it *could* be done. =C2=A0I guess the ris= k with examples is
>> > > that people rather think it is the way it *should* be do= ne...
>> > >
>> > >
>> > >> To allow for
>> > >> interoperability, we should really answer this quest= ion in a very
>> > >> clear way. Of course, saying 'yes' ties ever= ything configured related
>> > >> to an interface to the system's notion of an int= erface.
>> > >>
>> > >> A separate question for me is whether we support ren= aming of
>> > >> interfaces. If we do, I think a separate mechanism s= hould be
>> > >> introduced or we should acknowledge this as a functi= on to be
>> > >> potentially added later.
>> > >
>> > > One thing is renaming of interfaces in the configuration= . =C2=A0There is no
>> > > NETCONF support for this in general, and I don't thi= nk we should do
>> > > special rpc operations for some data models.
>> > >
>> > > Another thing is renaming of interfaces on the system le= vel. =C2=A0I that
>> > > is out of scope.
>> > >
>> > >
>> > >
>> > > /martin
>> > > _______________________________________________
>> > > 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
>> >
>> > _______________________________________________
>> > 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
_______________________________________________
netmod mailing list
netmod@ietf.org
= https://www.ietf.org/mailman/listinfo/netmod

--bcaec554de464240d804ccaa53c6-- From mbj@tail-f.com Mon Oct 22 12:14: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 8C07E21F856D for ; Mon, 22 Oct 2012 12:14:57 -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.046, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6wSTZFPUfafc for ; Mon, 22 Oct 2012 12:14:57 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id B292B21F855C for ; Mon, 22 Oct 2012 12:14:56 -0700 (PDT) Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 3D7111200AEC; Mon, 22 Oct 2012 21:14:55 +0200 (CEST) Date: Mon, 22 Oct 2012 21:14:54 +0200 (CEST) Message-Id: <20121022.211454.332159865.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: <7B828CB8-99F8-4EEB-875E-73A41257CFDF@nic.cz> References: <20121022133240.GA97741@elstar.local> <20121022.153906.1970983210068604573.mbj@tail-f.com> <7B828CB8-99F8-4EEB-875E-73A41257CFDF@nic.cz> X-Mailer: Mew version 6.4 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] interfaces open issue X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 22 Oct 2012 19:14:57 -0000 Ladislav Lhotka wrote: > > On Oct 22, 2012, at 3:39 PM, Martin Bjorklund wrote: > > > Juergen Schoenwaelder wrote: > >> On Mon, Oct 22, 2012 at 03:03:32PM +0200, Martin Bjorklund wrote: > >>> Juergen Schoenwaelder wrote: > >>>> On Mon, Oct 22, 2012 at 02:09:05PM +0200, Martin Bjorklund wrote: > >>>>> Juergen Schoenwaelder wrote: > >>>>>>> The idea was to provide an *example* so that people would easier > >>>>>>> understand how it *could* be done. I guess the risk with examples is > >>>>>>> that people rather think it is the way it *should* be done... > >>>>>> > >>>>>> I believe we need to decide this one way or the other if we want > >>>>>> interoperability. > >>>>> > >>>>> Can you elaborate on this? How would the interoperability be hurt if > >>>>> different implementations use different names in the kernel? > >>>> > >>>> I need to know whether interface/name is just a name for the > >>>> configuration (choosen by the operator or management application) or > >>>> whether it is the native system level name of the interface. These are > >>>> fundamentally different things. If I want to know the system level > >>>> interface name, I need to know where I get it from. Guessing one out > >>>> of two values is hampering interoperability. > >>> > >>> It seems there are two solutions to this problem: > >>> > >>> 1) Require the name in the config to be the same as the > >>> kernel-assigned name. > >> > >> I think this is potentially misleading. The kernel assigns a name, > >> which might be modified during system bootup. Hence, I prefer to talk > >> about system's name of the interface (once the system is out of the > >> boot sequence and running). > > > > Ok, rephrase this as: > > > > 1) Require the name in the config to be the same as the > > system's name of the interface. > > > >>> 2) Allow an arbitrary name in the config, but add an additional config > >>> false leaf 'local-name' or 'system-name' or something. > >> > >> Is it then required to support arbitrary names? > > > > Just like before. MAY restrict. > > Well, then it becomes my option #3, right? The same "name" key for an interface > entry then would be accepted by some systems and rejected by others. This > should IMO be avoided. > > > > >> Right now, the problem > >> for me is that I can not predict what the implementation will support. > >> If I use an arbitrary name, how do I link to the system's notion of > >> the interface name if the leaf is config false? I write it as a > >> location and read it back as local-name? > > > > You might write: > > > > name: foo > > type: ethernetCsmacd > > location 1/1 > > > > and read back > > > > system-name: fe-1/1 > > > > > > or on a linux-based system maybe you get back > > > > system-name: eth32 > > What's then the point of having the (mandatory) "location" leaf? The client > could use "system-name" right away: > > name: foo > type: ethernetCsmacd > system-name: fe-1/1 (or eth0) > > The advantage is that semantics of "system-name" is natural and clear on all > systems I know, while it is not always the case for "location". It is not trivial on linux, as we have seen earlier. A location of // is probably easier than eth32. "mgmt" and "lan" are probably easier that "eth1" and "eth0". > BTW, note that even the "type" leaf is in fact unnecessary because the system > knows very well what type its interface "fe-1/1" is. Right, but we need something stable to base augmentation on. /martin From internet-drafts@ietf.org Mon Oct 22 12:56: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 1402811E80D9; Mon, 22 Oct 2012 12:56:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.538 X-Spam-Level: X-Spam-Status: No, score=-102.538 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iCBQT88Vy35u; Mon, 22 Oct 2012 12:56:39 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 861961F042B; Mon, 22 Oct 2012 12:56:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121022195639.20926.10023.idtracker@ietfa.amsl.com> Date: Mon, 22 Oct 2012 12:56:39 -0700 Cc: netmod@ietf.org Subject: [netmod] I-D Action: draft-ietf-netmod-interfaces-cfg-07.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, 22 Oct 2012 19:56:40 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the NETCONF Data Modeling Language Working Gr= oup of the IETF. Title : A YANG Data Model for Interface Management Author(s) : Martin Bjorklund Filename : draft-ietf-netmod-interfaces-cfg-07.txt Pages : 34 Date : 2012-10-22 Abstract: This document defines a YANG data model for the management of network interfaces. It is expected that interface type specific data models augment the generic interfaces data model defined in this document. The 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-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netmod-interfaces-cfg-07 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From mbj@tail-f.com Mon Oct 22 12:59: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 1922221F8495 for ; Mon, 22 Oct 2012 12:59:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IqzKglpxak4B for ; Mon, 22 Oct 2012 12:59:09 -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 8C1E921F8446 for ; Mon, 22 Oct 2012 12:59:09 -0700 (PDT) Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 348C71200DA6 for ; Mon, 22 Oct 2012 21:59:08 +0200 (CEST) Date: Mon, 22 Oct 2012 21:59:07 +0200 (CEST) Message-Id: <20121022.215907.261873553.mbj@tail-f.com> To: netmod@ietf.org From: Martin Bjorklund In-Reply-To: <20121022195639.20926.10023.idtracker@ietfa.amsl.com> References: <20121022195639.20926.10023.idtracker@ietfa.amsl.com> X-Mailer: Mew version 6.4 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [netmod] I-D Action: draft-ietf-netmod-interfaces-cfg-07.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, 22 Oct 2012 19:59:10 -0000 Hi, I have submitted a new version of the interface document, with just one small bugfix; leaf speed is a config false node. This draft does not try to address the current discussion about naming. /martin internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the NETCONF Data Modeling Language Working Group > of the IETF. > > Title : A YANG Data Model for Interface Management > Author(s) : Martin Bjorklund > Filename : draft-ietf-netmod-interfaces-cfg-07.txt > Pages : 34 > Date : 2012-10-22 > > Abstract: > This document defines a YANG data model for the management of network > interfaces. It is expected that interface type specific data models > augment the generic interfaces data model defined in this document. > > > The 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-07 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-interfaces-cfg-07 > > > 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 bclaise@cisco.com Mon Oct 22 15:41: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 890C211E80F6 for ; Mon, 22 Oct 2012 15:41:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.616 X-Spam-Level: X-Spam-Status: No, score=-7.616 tagged_above=-999 required=5 tests=[AWL=2.983, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BzsP2qUay2Mz for ; Mon, 22 Oct 2012 15:41:58 -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 EBAEE1F0C49 for ; Mon, 22 Oct 2012 15:41:57 -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 q9MMfq5A004970; Mon, 22 Oct 2012 15:41:52 -0700 (PDT) Received: from [10.21.167.60] ([10.21.167.60]) by fire.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q9MMfmx5008575; Mon, 22 Oct 2012 15:41:48 -0700 (PDT) Message-ID: <5085CBAB.1040707@cisco.com> Date: Mon, 22 Oct 2012 18:41:47 -0400 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Ladislav Lhotka , Jernej Tuljak , Ladislav Lhotka , lhotka@cesnet.cz, netmod@ietf.org, rbonica@juniper.net References: <20120921154850.6A92C72E038@rfc-editor.org> <20120924083532.GB7097@elstar.local> <0B670666-932D-4549-B444-93B8021F7F1F@lhotka.name> <506022CA.9030200@cisco.com> <5062B8E4.6090303@mg-soft.com> <86E04D86-9E91-4EC5-9106-8D37C3B41D4E@nic.cz> <20120926093725.GA58512@elstar.local> <50642856.6030703@cisco.com> <507436E7.8000807@cisco.com> In-Reply-To: <507436E7.8000807@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [netmod] Last Call on the updated errata 3362 X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 22 Oct 2012 22:41:58 -0000 Dear all, It's now past October 19th, and this errata is now verified. Thanks to all. Regards, Benoit > Dear all, > > One simplification in the process of this errata. > See in line. >> Dear all, >>>> I don't have any experience with the errata procedure but I think >>>> the first decision should be whether this qualifies as an erratum, >>>> because indeed it changes the DSDL mapping "protocol", as Martin >>>> pointed out. >>>> >>>> Who is entitled to make this decision? >>>> >>> I have moved this question over to Benoit since I think we need advice >>> from the ADs here. >> >> Reviewing http://www.ietf.org/iesg/statement/errata-processing.html >> as background information... >> - As far as I can tell, we agree that this is a bug in the >> specification. So an errata should be filed. >> - As far as I can tell, we fall into: "Only errors that could cause >> implementation or deployment problems or significant confusion should >> be Approved." >> - As far as I can tell, we don't fall into: "Changes that modify the >> working of a protocol to something that might be different from the >> intended consensus when the document was approved should be either >> Hold for Document Update or Rejected" >> >> I'm in favor to keep the process simple, and to verify the errata, >> instead of producing a new RFC. >> >> However, before doing so, we want to be a safe side, basically making >> sure that there are no other implementations for which this bug fix >> (read non-backward compatibility change) would cause a problem. >> >> So let me propose the following: >> - We keep the errata 3362 open for now >> - Since errata 3362 needs to updated (and since we can't update this >> errata without approving/rejecting AFAIK), we create a new errata >> with all the changes, as agreed on the mailing list. Do we have an >> agreement on what Lada proposed? > After speaking to the RFC-editor, I was able to update the errata 3362 > (thanks Lada for helping here). >> - I send a kind of LC email to the mailing list, with this new errata >> - If no issue during this LC, I reject errata 3362 (pointing to the >> new errata), and I verify the new one. > Please review the updated errata 3362 at > http://www.rfc-editor.org/errata_search.php?eid=3362, and provide > feedback by October 19th. > At that date, the errata will be "verified" > > Regards, Benoit. >> >> Regards, Benoit. >>> /js >>> >> >> _______________________________________________ >> 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 muthu@cisco.com Tue Oct 23 12: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 A8B7711E80A4 for ; Tue, 23 Oct 2012 12:03:35 -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=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z5pbBk8cDt9R for ; Tue, 23 Oct 2012 12:03:34 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 7626011E80A3 for ; Tue, 23 Oct 2012 12:03:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5694; q=dns/txt; s=iport; t=1351019012; x=1352228612; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=uiTwQgXFCbMEHF4XjLQA15UsGAAitGzjRhOwxB6w0hA=; b=FxNOedVqmT4oaaSGIFQQpgfXlflNJeRIZAu0Ooc339XfZfGIVvyqoS+U t4MTZ4DqhjSOK++sjtqsFrAbpYboZyuBvXirpiJClJKi7LZHCJ/xT8rP4 mAJkhfjWCN/8MTYyIMY7dovF0ljpPmWj6EK/EgK6j5CyAswjTV4+yau8H o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EANzohlCtJV2Z/2dsb2JhbABEgkq/M4EIgiABBBIBZBQBCAQKFB05FBECBAESCBqHYpwLj1yQMpFeYAOkQIFrgm+CGA X-IronPort-AV: E=Sophos;i="4.80,637,1344211200"; d="scan'208,217";a="134587660" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-7.cisco.com with ESMTP; 23 Oct 2012 19:03:30 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q9NJ3Tee018934 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 23 Oct 2012 19:03:29 GMT Received: from xmb-rcd-x13.cisco.com ([169.254.3.63]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.02.0318.001; Tue, 23 Oct 2012 14:03:28 -0500 From: "Muthumayan Madhayyan (muthu)" To: Martin Bjorklund , "netmod@ietf.org" Thread-Topic: [netmod] Fw: New Version Notification for draft-bjorklund-netmod-operational-00.txt Thread-Index: AQHNotNdB3VWL6baMkOn2VwVC21D95fHOvkA Date: Tue, 23 Oct 2012 19:03:28 +0000 Message-ID: <5A949C32AF740C4798AEECF2568F0D84163A42@xmb-rcd-x13.cisco.com> In-Reply-To: <20121005.102805.519929541.mbj@tail-f.com> 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.21.68.224] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19298.000 x-tm-as-result: No--28.225200-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_5A949C32AF740C4798AEECF2568F0D84163A42xmbrcdx13ciscocom_" MIME-Version: 1.0 Subject: Re: [netmod] Fw: New Version Notification for draft-bjorklund-netmod-operational-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 19:03:35 -0000 --_000_5A949C32AF740C4798AEECF2568F0D84163A42xmbrcdx13ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Martin, Seems like a good start for modeling writeable operational data. A few comments on the I-D: * Terminology: The term 'operational state' has typically referred to r= ead-only type of information. Here the intent is to make this an 'editable = state data' . * Read-only data in YANG is denoted by 'config false' statement on t= hose nodes. * Operational data stores could contain both read-only and read-writ= e nodes. So, just using 'config false' may not suffice. Unfortunately, 'con= fig' can take only true or false argument. So, nodes in operational data st= ores have to use 'config false'. * Now to make those nodes 'writeable', adding another keyword like o= per: writeable makes sense. * However, I have a question here: There could be two different use= -cases: * A node to be writeable both in the configuration store and the = operational-datastore (obviously with different values). Ex: Configured va= lue of MTU overridden by operational MTU on an interface. * Different instances of the same node where one instance works o= ff the configuration store and the other from the ODS. Ex: Some interfaces = working off the configured MTU, while others work off either the default or= ODS. This is similar to the example of route table modification in 3.2.1. * Can the same node have both 'config true' and 'oper: writeable'= attributes ? I presume not. * 4.2: This seems to suggest that there is a standalone operational da= tastore whose contents may be derived from the configuration datastore. Why= is it a required to have the operational datastore tied to a configuration= datastore ? There may be cases that would require just an operational data= store that is independent of configuration datastore. - muthu On 10/5/12 1:28 AM, "Martin Bjorklund" > wrote: Hi, Lada and I have written a draft where we try to define the concept of operational state data. There are a couple of open issues in the draft that need to be discussed, so please comment! /martin & lada --_000_5A949C32AF740C4798AEECF2568F0D84163A42xmbrcdx13ciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <1DF43850EF20754E97043D4A7FC421CE@cisco.com> Content-Transfer-Encoding: quoted-printable
Hi Martin,

Seems like a good start for modeling writeable operational data.

A few comments on the I-D:

  • Terminology: The term 'operational state' has typically referred to rea= d-only type of information. Here the intent is to make this an 'editable st= ate data' . 
    • Read-only data in YANG is denoted by 'config false' statement on those = nodes. 
    • Operational data stores could contain both read-only a= nd read-write nodes. So, just using 'config false' may not suffice. Unfortu= nately, 'config' can take only true or false argument. So, nodes in operati= onal data stores have to use 'config false'.
    • Now to make those node= s 'writeable', adding another keyword like oper: writeable makes sense.
    • However, I have a question here:  There could be two different us= e-cases:
      • A node to be writeable both in the configuration store and the operatio= nal-datastore (obviously with different values).  Ex: Configured value= of MTU overridden by operational MTU on an interface.
      • Different in= stances of the same node where one instance works off the configuration sto= re and the other from the ODS. Ex: Some interfaces working off the configur= ed MTU, while others work off either the default or ODS. This is similar to= the example of route table modification in 3.2.1.
      • Can the same node have both 'co= nfig true' and 'oper: writeable' attributes ?  I presume not.  
  • 4.2:  This seems to suggest that there is a standalone operat= ional datastore whose contents may be derived from the configuration datast= ore. Why is it a required to have the operational datastore tied to a confi= guration datastore ? There may be cases that would require just an operational datastore that is independent of configu= ration datastore.


- muthu

On 10/5/12 1:28 AM, "Martin Bjorklund" <mbj@tail-f.com> wrote:

Hi,

Lada and I have written a draft where we try to define the concept of<= /div>
operational state data.  There are a couple of open issues i= n the
draft that need to be discussed, so please comment!


/martin & lada



--_000_5A949C32AF740C4798AEECF2568F0D84163A42xmbrcdx13ciscocom_-- From j.schoenwaelder@jacobs-university.de Tue Oct 23 14:20: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 CAB3721F85E2 for ; Tue, 23 Oct 2012 14:20:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.226 X-Spam-Level: X-Spam-Status: No, score=-103.226 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ad+r0l9COGBW for ; Tue, 23 Oct 2012 14:20: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 0D87821F85E8 for ; Tue, 23 Oct 2012 14:20:05 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id E80D2209DC; Tue, 23 Oct 2012 23:20:03 +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 M6Quz_Y4toXr; Tue, 23 Oct 2012 23:20:03 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 597AA20968; Tue, 23 Oct 2012 23:20:03 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 8DF482270449; Tue, 23 Oct 2012 23:20:02 +0200 (CEST) Date: Tue, 23 Oct 2012 23:20:02 +0200 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20121023212002.GA77129@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] atlanta meeting draft agenda 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, 23 Oct 2012 21:20:06 -0000 Hi, I have posted a draft agenda for the Atlanta meeting: https://datatracker.ietf.org/meeting/85/agenda/netmod/ Please let the chairs know about any change requests. If your I-D is scheduled and you think you need less time, please let us know as well. Note that we like to reserve some time to discuss operational state issues and we might continue the discussion during the NETCONF meeting since this topic touches both WGs. I have not put the SNMP configuration document on the agenda since it has not been updated nor were there discussions on the mailing 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 Tue Oct 23 17:19: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 2818E11E8124 for ; Tue, 23 Oct 2012 17:19:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.636 X-Spam-Level: X-Spam-Status: No, score=-2.636 tagged_above=-999 required=5 tests=[AWL=0.209, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_UNSUB18=0.131] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UUVYwzmIM+fb for ; Tue, 23 Oct 2012 17:19:36 -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 C65FE11E8122 for ; Tue, 23 Oct 2012 17:19:35 -0700 (PDT) Received: by mail-lb0-f172.google.com with SMTP id k13so812271lbo.31 for ; Tue, 23 Oct 2012 17:19:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=0SAbhMJRdzOWwwzeCUSEpWCIx2nLJbHrMhrd7ovXCmk=; b=jyJglxU54h6W6hIKhaJeAErVPVg1txBmRLh2WR+FkCgeUcxlmpWP3ebx0zSGWCwDtp b34OsiYBfaE/+DfRXZCkM3288fbsVhlWWdGCAZeCz6PokSZbL04n4F7LW179/tbQJRTM wVGmZQVogmmtXSVqTLFvy6BrpJFCfAVw9belr2Dul9neJBd33jDIpvweL1JlTRaM0JB+ fr2uzc+Jgu63RF365gYCcnoGqQOVBQv4F9+w4gaU1z7L1IJgedDJFmXXyjJ3eX7jfOT2 4WgFyEH/LpZc13yR3vtQv1/D3NsHuP2XBaDJp+IDbqBRqkFm3Ko8WUQpjMdToCe0lHuH sVLg== MIME-Version: 1.0 Received: by 10.112.39.161 with SMTP id q1mr5649244lbk.131.1351037974557; Tue, 23 Oct 2012 17:19:34 -0700 (PDT) Received: by 10.112.1.40 with HTTP; Tue, 23 Oct 2012 17:19:34 -0700 (PDT) In-Reply-To: <5A949C32AF740C4798AEECF2568F0D84163A42@xmb-rcd-x13.cisco.com> References: <20121005.102805.519929541.mbj@tail-f.com> <5A949C32AF740C4798AEECF2568F0D84163A42@xmb-rcd-x13.cisco.com> Date: Tue, 23 Oct 2012 17:19:34 -0700 Message-ID: From: Andy Bierman To: "Muthumayan Madhayyan (muthu)" Content-Type: multipart/alternative; boundary=e0cb4efe2bec8d365c04ccc30adc X-Gm-Message-State: ALoCoQmbW60Xrm9Cl3GSOip7ghm8JKx3toCvZpnoqjoXGKYz7WEmIzr2BalOJ39bL5E0LC3QJkKu Cc: "netmod@ietf.org" Subject: Re: [netmod] Fw: New Version Notification for draft-bjorklund-netmod-operational-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: Wed, 24 Oct 2012 00:19:37 -0000 --e0cb4efe2bec8d365c04ccc30adc Content-Type: text/plain; charset=UTF-8 Hi, IMO, there are many problems with editing operational state. There are security concerns wrt/ data injection attacks. Does the server have to validate an operational datastore with YANG constraints like must-stmt and min-elements? Do any servers in existence today actually validate operational state in any way? Without validation, there increased vulnerabilities introduced. Since there is no 'candidate' config for editing operational state, there are ordering issues (similar to writing directly to running config). The server may not allow arbitrary edits in arbitrary order for operational state. This seems very difficult to standardize. There is no all-or-nothing transaction capability that the candidate config provides, so partial errors can leave the system in an unstable state. IMO, the design is too unconstrained, and multi-vendor interopability would be much easier to achieve with custom operations like that require certain parameters to be presented together, and the expected changes to the system behavior clearly documented. Andy On Tue, Oct 23, 2012 at 12:03 PM, Muthumayan Madhayyan (muthu) < muthu@cisco.com> wrote: > Hi Martin, > > Seems like a good start for modeling writeable operational data. > > A few comments on the I-D: > > > - Terminology: The term 'operational state' has typically referred to > read-only type of information. Here the intent is to make this an 'editable > state data' . > - Read-only data in YANG is denoted by 'config false' statement on > those nodes. > - Operational data stores could contain both read-only and > read-write nodes. So, just using 'config false' may not suffice. > Unfortunately, 'config' can take only true or false argument. So, nodes in > operational data stores have to use 'config false'. > - Now to make those nodes 'writeable', adding another keyword like > oper: writeable makes sense. > - However, I have a question here: There could be two different > use-cases: > - A node to be writeable both in the configuration store and the > operational-datastore (obviously with different values). Ex: Configured > value of MTU overridden by operational MTU on an interface. > - Different instances of the same node where one instance works > off the configuration store and the other from the ODS. Ex: Some interfaces > working off the configured MTU, while others work off either the default or > ODS. This is similar to the example of route table modification in 3.2.1. > - Can the same node have both 'config true' and 'oper: > writeable' attributes ? I presume not. > - 4.2: This seems to suggest that there is a standalone > operational datastore whose contents may be derived from the configuration > datastore. Why is it a required to have the operational datastore tied to a > configuration datastore ? There may be cases that would require just an > operational datastore that is independent of configuration datastore. > > > > - muthu > > On 10/5/12 1:28 AM, "Martin Bjorklund" wrote: > > Hi, > > Lada and I have written a draft where we try to define the concept of > operational state data. There are a couple of open issues in the > draft that need to be discussed, so please comment! > > > /martin & lada > > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > --e0cb4efe2bec8d365c04ccc30adc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi,

IMO, there are many problems with editing operationa= l state.

There are security concerns wrt/ data inj= ection attacks.
Does the server have to validate an operational d= atastore
with YANG constraints like must-stmt and min-elements?
Do an= y servers in existence today actually validate operational state
= in any way? =C2=A0Without validation, there increased=C2=A0vulnerabilities = introduced.

Since there is no 'candidate' config for editin= g operational
state, there are ordering issues (similar to writin= g directly
to running config). =C2=A0The server may not allow arb= itrary edits
in arbitrary order for operational state. =C2=A0This seems very diffic= ult
to standardize. =C2=A0There is no all-or-nothing transaction = capability
that the candidate config provides, so partial errors = can leave
the system in an unstable state.

IMO, the <= ;edit-operational> design is too unconstrained,
and multi-vend= or interopability would be much easier
to achieve with custom ope= rations like <inject-route>
that require certain parameters to be presented together,
an= d the expected changes to the system behavior clearly documented.


Andy

On Tue, Oct 23, 2012 at 12:03 PM, Muthumayan Madhayyan (muthu) <muthu@cisco.= com> wrote:
Hi Martin,

Seems like a good start for modeling writeable operational data.

A few comments on the I-D:

  • Terminology: The term 'operational state' has typically referre= d to read-only type of information. Here the intent is to make this an '= ;editable state data' .=C2=A0
    • Read-only data in YANG is denoted by 'config false' statement o= n those nodes.=C2=A0
    • Operational data stores could contain both rea= d-only and read-write nodes. So, just using 'config false' may not = suffice. Unfortunately, 'config' can take only true or false argume= nt. So, nodes in operational data stores have to use 'config false'= .
    • Now to make those nodes 'writeable', adding another keyword lik= e oper: writeable makes sense.
    • However, I have a question here: =C2= =A0There could be two different use-cases:
      • A node to be writeable both in the configuration store and the operatio= nal-datastore (obviously with different values). =C2=A0Ex: Configured value= of MTU overridden by operational MTU on an interface.
      • Different in= stances of the same node where one instance works off the configuration sto= re and the other from the ODS. Ex: Some interfaces working off the configur= ed MTU, while others work off either the default or ODS. This is similar to= the example of route table modification in 3.2.1.
      • Can the same node have both = 9;config true' and 'oper: writeable' attributes ? =C2=A0I presu= me not. =C2=A0
  • 4.2: =C2=A0This seems to suggest that there is a standalone operat= ional datastore whose contents may be derived from the configuration datast= ore. Why is it a required to have the operational datastore tied to a confi= guration datastore ? There may be cases that would require just an operational datastore that is independent of configu= ration datastore.


- muthu

On 10/5/12 1:28 AM, "Martin Bjorklund" <mbj@tail-f.com> wrote:

Hi,

Lada and I have written a draft where we try to define the concept of<= /div>
operational state data.=C2=A0=C2=A0There are a couple of open issues i= n the
draft that need to be discussed, so please comment!


/martin & lada




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


--e0cb4efe2bec8d365c04ccc30adc-- From andy@yumaworks.com Tue Oct 23 19:52: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 63B261F0C73 for ; Tue, 23 Oct 2012 19:52:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.406 X-Spam-Level: X-Spam-Status: No, score=-2.406 tagged_above=-999 required=5 tests=[AWL=-0.030, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F-MtBpTmWGxm for ; Tue, 23 Oct 2012 19:52:18 -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 610FA1F0C6E for ; Tue, 23 Oct 2012 19:52:12 -0700 (PDT) Received: by mail-lb0-f172.google.com with SMTP id k13so867814lbo.31 for ; Tue, 23 Oct 2012 19:52:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=i89FHPFDn1RU+VLadUsXZIC03IMEGyaAJfBpJpGDjG4=; b=erya2kURK8EIujHU6tJwGYfKMPwQhzgQXwEoiGB5/Z2c/Wu/htiXfV1J3dfbO0GZK9 fibPR91elFcRzbI6ssa6k/PelsjMdytClO0mv/YvHyBnZJtG9pJa1VQiAXTbCG1n/4rw hHBQKw7FmzaxavE55SLlgGt6UB8/boEtKg9mQhkiBKxrJ/GhEPmIzDU0FDfa8OSYzf1/ hTq7RKjXinNkgS2cswpQjUQdrOEiXAM3/24TRPyeWvImgH55DNNtVdUVIeyjL2um3LVy 2sw7leSbd4vsNuoyu2y+bYm7ZFZBg95ukt521m1T3cU4HwKudsY15qXJFSZktienMna+ d16g== MIME-Version: 1.0 Received: by 10.152.105.173 with SMTP id gn13mr13059780lab.41.1351047131366; Tue, 23 Oct 2012 19:52:11 -0700 (PDT) Received: by 10.112.1.40 with HTTP; Tue, 23 Oct 2012 19:52:11 -0700 (PDT) In-Reply-To: <5A949C32AF740C4798AEECF2568F0D84163A42@xmb-rcd-x13.cisco.com> References: <20121005.102805.519929541.mbj@tail-f.com> <5A949C32AF740C4798AEECF2568F0D84163A42@xmb-rcd-x13.cisco.com> Date: Tue, 23 Oct 2012 19:52:11 -0700 Message-ID: From: Andy Bierman To: "Muthumayan Madhayyan (muthu)" Content-Type: multipart/alternative; boundary=f46d040714c557047104ccc52ca8 X-Gm-Message-State: ALoCoQmNtWetz27/2hU2shlKNRW05+JDKKVwPKzQ2xoGJw51IGK2Pp1AkREy2h9oSgKGP4LuIF8l Cc: "netmod@ietf.org" Subject: Re: [netmod] Fw: New Version Notification for draft-bjorklund-netmod-operational-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: Wed, 24 Oct 2012 02:52:19 -0000 --f46d040714c557047104ccc52ca8 Content-Type: text/plain; charset=UTF-8 IMO the most interesting aspect of this draft is the configuration pre-provisioning mentioned in the example in 3.1.1. I agree that NETCONF should support it somehow. I do agree that config provided by the client for HW not present is operational state instead of config is a "pre-provisioned" state. There is another important corner-case related to operational state not mentioned in the draft, which is config=true operational state nodes. These are containers or lists that only the server can create -- e.g., the PHY interface list from the kernel. There is no standard way in YANG to say that the client can only edit descendant nodes of this config=true node. These nodes have to be saved in the NV-config because they are the parent nodes for all the client config. Andy On Tue, Oct 23, 2012 at 12:03 PM, Muthumayan Madhayyan (muthu) < muthu@cisco.com> wrote: > Hi Martin, > > Seems like a good start for modeling writeable operational data. > > A few comments on the I-D: > > > - Terminology: The term 'operational state' has typically referred to > read-only type of information. Here the intent is to make this an 'editable > state data' . > - Read-only data in YANG is denoted by 'config false' statement on > those nodes. > - Operational data stores could contain both read-only and > read-write nodes. So, just using 'config false' may not suffice. > Unfortunately, 'config' can take only true or false argument. So, nodes in > operational data stores have to use 'config false'. > - Now to make those nodes 'writeable', adding another keyword like > oper: writeable makes sense. > - However, I have a question here: There could be two different > use-cases: > - A node to be writeable both in the configuration store and the > operational-datastore (obviously with different values). Ex: Configured > value of MTU overridden by operational MTU on an interface. > - Different instances of the same node where one instance works > off the configuration store and the other from the ODS. Ex: Some interfaces > working off the configured MTU, while others work off either the default or > ODS. This is similar to the example of route table modification in 3.2.1. > - Can the same node have both 'config true' and 'oper: > writeable' attributes ? I presume not. > - 4.2: This seems to suggest that there is a standalone > operational datastore whose contents may be derived from the configuration > datastore. Why is it a required to have the operational datastore tied to a > configuration datastore ? There may be cases that would require just an > operational datastore that is independent of configuration datastore. > > > > - muthu > > On 10/5/12 1:28 AM, "Martin Bjorklund" wrote: > > Hi, > > Lada and I have written a draft where we try to define the concept of > operational state data. There are a couple of open issues in the > draft that need to be discussed, so please comment! > > > /martin & lada > > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > --f46d040714c557047104ccc52ca8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable IMO the most interesting aspect of this draft is the configuration pre-prov= isioning mentioned
in the example in 3.1.1. =C2=A0I agree that NETCONF = should support it somehow.
I do agree that config provided by the= client for HW not present is operational state
instead of config is a "pre-provisioned" state.
There is another important corner-case related to operational = state not mentioned
in the draft, which is config=3Dtrue operatio= nal state nodes. =C2=A0These are containers
or lists that only the server can create -- e.g., the PHY interface li= st from the kernel.
There is no standard way in YANG to say that = the client can only edit descendant nodes
of this config=3Dtrue n= ode. =C2=A0These nodes have to be saved in the NV-config because
they are the parent nodes for all the client config.


Andy


On Tue, Oct 23, 2012 at 12:03 PM, Muthumayan Madhayyan (muthu) <mut= hu@cisco.com> wrote:
Hi Martin,

Seems like a good start for modeling writeable operational data.

A few comments on the I-D:

  • Terminology: The term 'operational state' has typically referre= d to read-only type of information. Here the intent is to make this an '= ;editable state data' .=C2=A0
    • Read-only data in YANG is denoted by 'config false' statement o= n those nodes.=C2=A0
    • Operational data stores could contain both rea= d-only and read-write nodes. So, just using 'config false' may not = suffice. Unfortunately, 'config' can take only true or false argume= nt. So, nodes in operational data stores have to use 'config false'= .
    • Now to make those nodes 'writeable', adding another keyword lik= e oper: writeable makes sense.
    • However, I have a question here: =C2= =A0There could be two different use-cases:
      • A node to be writeable both in the configuration store and the operatio= nal-datastore (obviously with different values). =C2=A0Ex: Configured value= of MTU overridden by operational MTU on an interface.
      • Different in= stances of the same node where one instance works off the configuration sto= re and the other from the ODS. Ex: Some interfaces working off the configur= ed MTU, while others work off either the default or ODS. This is similar to= the example of route table modification in 3.2.1.
      • Can the same node have both = 9;config true' and 'oper: writeable' attributes ? =C2=A0I presu= me not. =C2=A0
  • 4.2: =C2=A0This seems to suggest that there is a standalone operat= ional datastore whose contents may be derived from the configuration datast= ore. Why is it a required to have the operational datastore tied to a confi= guration datastore ? There may be cases that would require just an operational datastore that is independent of configu= ration datastore.


- muthu

On 10/5/12 1:28 AM, "Martin Bjorklund" <mbj@tail-f.com> wrote:

Hi,

Lada and I have written a draft where we try to define the concept of<= /div>
operational state data.=C2=A0=C2=A0There are a couple of open issues i= n the
draft that need to be discussed, so please comment!


/martin & lada




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


--f46d040714c557047104ccc52ca8-- From andy@yumaworks.com Tue Oct 23 19:59: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 B452E21F8A0F for ; Tue, 23 Oct 2012 19:59:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.406 X-Spam-Level: X-Spam-Status: No, score=-2.406 tagged_above=-999 required=5 tests=[AWL=-0.030, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cQ4Pg5QLXNTY for ; Tue, 23 Oct 2012 19:59:18 -0700 (PDT) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5F5C021F8A0C for ; Tue, 23 Oct 2012 19:59:18 -0700 (PDT) Received: by mail-la0-f44.google.com with SMTP id b11so32056lam.31 for ; Tue, 23 Oct 2012 19:59:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=tAWebtFusLV8oFHCDm1Fqz14ztxDhm1tykeRF6Ep3oQ=; b=fzUQs8ig+HNFDSSjcWs/YGdhjV2SaD0nHpYXWGd85yp7NBo5NQXb3/B61hl1BKNwm7 iUbP7oJ9BSqOFNAdWdZIvH2bcqixxP8bNXiBsWvy7xhJaYFFJcKEf7wurFaxK5YiO9ZT xW4Ns6hJeCDRTWlujbXPCoe+P0QYVBsg1i+DoDXcyaM4h9lzxeMr6j3RlKz1EYVycCsP KmD0tR0IjvZWcDzSFSM2PossYdwRoqtixumqMG8RPMtGQvDh3j2cG93YJaOFl6d854cn oRViXPHSc/2dPwHGZRxbLqjyleIzPtOJ+jck4jDWsJQWKv1jP5Q+4WBPcNskTauGbCI8 JYHw== MIME-Version: 1.0 Received: by 10.152.104.107 with SMTP id gd11mr12915392lab.25.1351047557292; Tue, 23 Oct 2012 19:59:17 -0700 (PDT) Received: by 10.112.1.40 with HTTP; Tue, 23 Oct 2012 19:59:17 -0700 (PDT) In-Reply-To: References: <20121005.102805.519929541.mbj@tail-f.com> <5A949C32AF740C4798AEECF2568F0D84163A42@xmb-rcd-x13.cisco.com> Date: Tue, 23 Oct 2012 19:59:17 -0700 Message-ID: From: Andy Bierman To: "Muthumayan Madhayyan (muthu)" Content-Type: multipart/alternative; boundary=f46d04088d11ba248c04ccc54500 X-Gm-Message-State: ALoCoQkDCCP4QspucKUd59EsmlgcOtZWQzZ6G7UeV6MI8zCoNiPJgCLvm4k23+awUTiLe49VB+nE Cc: "netmod@ietf.org" Subject: Re: [netmod] Fw: New Version Notification for draft-bjorklund-netmod-operational-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: Wed, 24 Oct 2012 02:59:19 -0000 --f46d04088d11ba248c04ccc54500 Content-Type: text/plain; charset=UTF-8 On Tue, Oct 23, 2012 at 7:52 PM, Andy Bierman wrote: > IMO the most interesting aspect of this draft is the configuration > pre-provisioning mentioned > in the example in 3.1.1. I agree that NETCONF should support it somehow. > I do agree that config provided by the client for HW not present is > operational state > ^ not instead of config is a "pre-provisioned" state. > > I would also throw in client-disabled configuration an an important use-case to support. I think of this as config in a different state than "active", not operational state. Andy > There is another important corner-case related to operational state not > mentioned > in the draft, which is config=true operational state nodes. These are > containers > or lists that only the server can create -- e.g., the PHY interface list > from the kernel. > There is no standard way in YANG to say that the client can only edit > descendant nodes > of this config=true node. These nodes have to be saved in the NV-config > because > they are the parent nodes for all the client config. > > > Andy > > > On Tue, Oct 23, 2012 at 12:03 PM, Muthumayan Madhayyan (muthu) < > muthu@cisco.com> wrote: > >> Hi Martin, >> >> Seems like a good start for modeling writeable operational data. >> >> A few comments on the I-D: >> >> >> - Terminology: The term 'operational state' has typically referred to >> read-only type of information. Here the intent is to make this an 'editable >> state data' . >> - Read-only data in YANG is denoted by 'config false' statement on >> those nodes. >> - Operational data stores could contain both read-only and >> read-write nodes. So, just using 'config false' may not suffice. >> Unfortunately, 'config' can take only true or false argument. So, nodes in >> operational data stores have to use 'config false'. >> - Now to make those nodes 'writeable', adding another keyword like >> oper: writeable makes sense. >> - However, I have a question here: There could be two different >> use-cases: >> - A node to be writeable both in the configuration store and >> the operational-datastore (obviously with different values). Ex: >> Configured value of MTU overridden by operational MTU on an interface. >> - Different instances of the same node where one instance works >> off the configuration store and the other from the ODS. Ex: Some interfaces >> working off the configured MTU, while others work off either the default or >> ODS. This is similar to the example of route table modification in 3.2.1. >> - Can the same node have both 'config true' and 'oper: >> writeable' attributes ? I presume not. >> - 4.2: This seems to suggest that there is a standalone >> operational datastore whose contents may be derived from the configuration >> datastore. Why is it a required to have the operational datastore tied to a >> configuration datastore ? There may be cases that would require just an >> operational datastore that is independent of configuration datastore. >> >> >> >> - muthu >> >> On 10/5/12 1:28 AM, "Martin Bjorklund" wrote: >> >> Hi, >> >> Lada and I have written a draft where we try to define the concept of >> operational state data. There are a couple of open issues in the >> draft that need to be discussed, so please comment! >> >> >> /martin & lada >> >> >> >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >> >> > --f46d04088d11ba248c04ccc54500 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Tue, Oct 23, 2012 at 7:52 PM, Andy Bi= erman <andy@yumaworks.com> wrote:
IMO the most interesting aspect of this draft is the configuration pre-prov= isioning mentioned
in the example in 3.1.1. =C2=A0I agree that NETCONF = should support it somehow.
I do agree that config provided by the= client for HW not present is operational state
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0^ not=C2=A0
<= br>
instead of config is a "pre-provisioned" state.

I would also throw in client-disab= led configuration an an important use-case to support.
I think of= this as config in a different state than "active", not operation= al state.

Andy

=C2=A0
There is another important corner-case re= lated to operational state not mentioned
in the draft, which is config=3Dtrue operational state nodes. =C2=A0Th= ese are containers
or lists that only the server can create -- e.g., the PHY interface li= st from the kernel.
There is no standard way in YANG to say that = the client can only edit descendant nodes
of this config=3Dtrue n= ode. =C2=A0These nodes have to be saved in the NV-config because
they are the parent nodes for all the client config.


Andy


On Tue, Oct 23, 2012 at 12:03 PM, Muthumayan Madhayyan (muthu) <mut= hu@cisco.com> wrote:
Hi Martin,

Seems like a good start for modeling writeable operational data.

A few comments on the I-D:

  • Terminology: The term 'operational state' has typically referre= d to read-only type of information. Here the intent is to make this an '= ;editable state data' .=C2=A0
    • Read-only data in YANG is denoted by 'config false' statement o= n those nodes.=C2=A0
    • Operational data stores could contain both rea= d-only and read-write nodes. So, just using 'config false' may not = suffice. Unfortunately, 'config' can take only true or false argume= nt. So, nodes in operational data stores have to use 'config false'= .
    • Now to make those nodes 'writeable', adding another keyword lik= e oper: writeable makes sense.
    • However, I have a question here: =C2= =A0There could be two different use-cases:
      • A node to be writeable both in the configuration store and the operatio= nal-datastore (obviously with different values). =C2=A0Ex: Configured value= of MTU overridden by operational MTU on an interface.
      • Different in= stances of the same node where one instance works off the configuration sto= re and the other from the ODS. Ex: Some interfaces working off the configur= ed MTU, while others work off either the default or ODS. This is similar to= the example of route table modification in 3.2.1.
      • Can the same node have both = 9;config true' and 'oper: writeable' attributes ? =C2=A0I presu= me not. =C2=A0
  • 4.2: =C2=A0This seems to suggest that there is a standalone operat= ional datastore whose contents may be derived from the configuration datast= ore. Why is it a required to have the operational datastore tied to a confi= guration datastore ? There may be cases that would require just an operational datastore that is independent of configu= ration datastore.


- muthu

On 10/5/12 1:28 AM, "Martin Bjorklund" <mbj@tail-f.com> wrote:

Hi,

Lada and I have written a draft where we try to define the concept of<= /div>
operational state data.=C2=A0=C2=A0There are a couple of open issues i= n the
draft that need to be discussed, so please comment!


/martin & lada




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



--f46d04088d11ba248c04ccc54500-- From mbj@tail-f.com Wed Oct 24 00: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 99C4021F88E0 for ; Wed, 24 Oct 2012 00:44:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.022 X-Spam-Level: X-Spam-Status: No, score=-2.022 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d6xAWwCilnSx for ; Wed, 24 Oct 2012 00:44:19 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id BDB5021F88F0 for ; Wed, 24 Oct 2012 00:44:18 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id BD5191200CFA; Wed, 24 Oct 2012 09:44:16 +0200 (CEST) Date: Wed, 24 Oct 2012 09:44:16 +0200 (CEST) Message-Id: <20121024.094416.963558679295739360.mbj@tail-f.com> To: muthu@cisco.com From: Martin Bjorklund In-Reply-To: <5A949C32AF740C4798AEECF2568F0D84163A42@xmb-rcd-x13.cisco.com> References: <20121005.102805.519929541.mbj@tail-f.com> <5A949C32AF740C4798AEECF2568F0D84163A42@xmb-rcd-x13.cisco.com> X-Mailer: Mew version 6.4 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] Fw: New Version Notification for draft-bjorklund-netmod-operational-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: Wed, 24 Oct 2012 07:44:19 -0000 Hi, "Muthumayan Madhayyan (muthu)" wrote: > Hi Martin, > > Seems like a good start for modeling writeable operational data. > > A few comments on the I-D: > > * Terminology: The term 'operational state' has typically referred to > read-only type of information. Here the intent is to make this an > 'editable state data' . When you say that the operational state is read-only, you probably mean read-only through the management interface? The operational state changes all the time, obviously. Even today the operational state is indirectly changed through the management protocol when the configuration is changed (depending on the type of change of course). It seems there are use cases for modififying the operational state directly, for example in IRS they want to modify the routing table. So the question is how can we change the operational state through the management protocol? >From a logical point of view, it doesn't really matter if the operational state is modified directly by a generic rpc like 'edit-operational' or by special rpc 'inject-route', 'edit-route', 'delete-route' etc. As noted in the draft, this idea of 'edit-operational' is > + Read-only data in YANG is denoted by 'config false' statement on those > nodes. > + Operational data stores could contain both read-only and read-write > nodes. So, just using 'config false' may not suffice. Unfortunately, > 'config' can take only true or false argument. So, nodes in > operational data stores have to use 'config false'. > + Now to make those nodes 'writeable', adding another keyword like oper: > writeable makes sense. > + However, I have a question here: There could be two different > use-cases: > o A node to be writeable both in the configuration store and the > operational-datastore (obviously with different values). Ex: > Configured value of MTU overridden by operational MTU on an > interface. > o Different instances of the same node where one instance works off > the configuration store and the other from the ODS. Ex: Some > interfaces working off the configured MTU, while others work off > either the default or ODS. This is similar to the example of route > table modification in 3.2.1. > o Can the same node have both 'config true' and 'oper: writeable' > attributes ? I presume not. Probably not. You can run into the same problem today if you define something like this: leaf foo-address { config true; ... } rpc set-foo-address { description "directly sets the foo-address in the operational state"; input { leaf address { ... } } } > * 4.2: This seems to suggest that there is a standalone operational > datastore Yes, conceptually. In real implementations this "datastore" probably is built on the fly as needed, by using callbacks into the application. > whose contents may be derived from the configuration datastore. > Why is it a required to have the operational datastore tied to a > configuration datastore ? There may be cases that would require just an > operational datastore that is independent of configuration datastore. Most configuration parameters affect the operational behaviour of the device. So when the running config is modified, the applications pick up the changes and changes its behaviours accordingly, thus changing the operational state. /martin From mbj@tail-f.com Wed Oct 24 00:56: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 B326021F8B81 for ; Wed, 24 Oct 2012 00:56:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.023 X-Spam-Level: X-Spam-Status: No, score=-2.023 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FlooyX7hP3uP for ; Wed, 24 Oct 2012 00:56:33 -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 2521521F8B7E for ; Wed, 24 Oct 2012 00:56:33 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 077F31200CFA; Wed, 24 Oct 2012 09:56:32 +0200 (CEST) Date: Wed, 24 Oct 2012 09:56:31 +0200 (CEST) Message-Id: <20121024.095631.29126907866494919.mbj@tail-f.com> To: muthu@cisco.com From: Martin Bjorklund In-Reply-To: <20121024.094416.963558679295739360.mbj@tail-f.com> References: <20121005.102805.519929541.mbj@tail-f.com> <5A949C32AF740C4798AEECF2568F0D84163A42@xmb-rcd-x13.cisco.com> <20121024.094416.963558679295739360.mbj@tail-f.com> X-Mailer: Mew version 6.4 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] Fw: New Version Notification for draft-bjorklund-netmod-operational-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: Wed, 24 Oct 2012 07:56:33 -0000 Martin Bjorklund wrote: > Hi, > > "Muthumayan Madhayyan (muthu)" wrote: > > Hi Martin, > > > > Seems like a good start for modeling writeable operational data. > > > > A few comments on the I-D: > > > > * Terminology: The term 'operational state' has typically referred to > > read-only type of information. Here the intent is to make this an > > 'editable state data' . > > When you say that the operational state is read-only, you probably > mean read-only through the management interface? The operational > state changes all the time, obviously. > > Even today the operational state is indirectly changed through the > management protocol when the configuration is changed (depending on > the type of change of course). > > It seems there are use cases for modififying the operational state > directly, for example in IRS they want to modify the routing table. > > So the question is how can we change the operational state through the > management protocol? > > From a logical point of view, it doesn't really matter if the > operational state is modified directly by a generic rpc like > 'edit-operational' or by special rpc 'inject-route', 'edit-route', > 'delete-route' etc. > > As noted in the draft, this idea of 'edit-operational' is I meant to write: As noted in the draft, this idea of 'edit-operational' is not finished. We need to have more discussions about this. /martin From mbj@tail-f.com Wed Oct 24 04:32: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 11FDA21F8B90 for ; Wed, 24 Oct 2012 04:32:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.024 X-Spam-Level: X-Spam-Status: No, score=-2.024 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Itagk-J7yZG for ; Wed, 24 Oct 2012 04:32: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 A9AD621F8B8A for ; Wed, 24 Oct 2012 04:32:15 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id E87FF1200CFA; Wed, 24 Oct 2012 13:32:13 +0200 (CEST) Date: Wed, 24 Oct 2012 13:32:13 +0200 (CEST) Message-Id: <20121024.133213.428639413434989674.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: <20121005.102805.519929541.mbj@tail-f.com> <5A949C32AF740C4798AEECF2568F0D84163A42@xmb-rcd-x13.cisco.com> X-Mailer: Mew version 6.4 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] Fw: New Version Notification for draft-bjorklund-netmod-operational-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: Wed, 24 Oct 2012 11:32:21 -0000 Andy Bierman wrote: > Hi, > > IMO, there are many problems with editing operational state. > > There are security concerns wrt/ data injection attacks. Actually, this is can be controlled on a more fine-grained level (with NACM) if the state is edited by a generic operation. If you have a specific operation like 'inject-route' you can only permit/deny the operation itself, you cannot check parameters to the rpc. > Does the server have to validate an operational datastore > with YANG constraints like must-stmt and min-elements? No, I don't think this makes sense. > Do any servers in existence today actually validate operational state > in any way? Without validation, there increased vulnerabilities introduced. This is true also for special rpcs. > Since there is no 'candidate' config for editing operational > state, there are ordering issues (similar to writing directly > to running config). I think ordering is a bigger problem for special rpcs. With a generic edit-operational, the client can send all data in one go. With special rpcs it has to split the data into a bunch of special rpcs and send them *in the correct order*. > The server may not allow arbitrary edits > in arbitrary order for operational state. This seems very difficult > to standardize. There is no all-or-nothing transaction capability > that the candidate config provides, so partial errors can leave > the system in an unstable state. This is not better than if you do a bunch of special rpcs, and the 4th fails. > IMO, the design is too unconstrained, Yes, I agree that this can be a drawback with this design. /martin From mbj@tail-f.com Wed Oct 24 04:37: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 CC73321F8850 for ; Wed, 24 Oct 2012 04:37:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.725 X-Spam-Level: X-Spam-Status: No, score=-1.725 tagged_above=-999 required=5 tests=[AWL=-0.279, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_64=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3OgJmVvhfS8i for ; Wed, 24 Oct 2012 04:37: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 3E7CB21F8829 for ; Wed, 24 Oct 2012 04:37:58 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 695831200CFA; Wed, 24 Oct 2012 13:37:57 +0200 (CEST) Date: Wed, 24 Oct 2012 13:37:57 +0200 (CEST) Message-Id: <20121024.133757.1265113932294838812.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: <20121005.102805.519929541.mbj@tail-f.com> <5A949C32AF740C4798AEECF2568F0D84163A42@xmb-rcd-x13.cisco.com> X-Mailer: Mew version 6.4 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] Fw: New Version Notification for draft-bjorklund-netmod-operational-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: Wed, 24 Oct 2012 11:37:58 -0000 Andy Bierman wrote: > I do agree that config provided by the client for HW not present is > operational state > instead of config is a "pre-provisioned" state. I think you meant "I do not agree...". Well, neither do I. I don't think anyone said that pre-provisioned config is operational state. > There is another important corner-case related to operational state not > mentioned > in the draft, which is config=true operational state nodes. These are > containers > or lists that only the server can create -- e.g., the PHY interface list > from the kernel. > There is no standard way in YANG to say that the client can only edit > descendant nodes > of this config=true node. These nodes have to be saved in the NV-config > because > they are the parent nodes for all the client config. This is a different topic, but super simple to solve: The server should not mess with the config at all. No magic handling of physical interfaces. (they can be present as initial "factory created" config though). /martin From andy@yumaworks.com Wed Oct 24 08:14: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 CEF7421F887E for ; Wed, 24 Oct 2012 08:14:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.405 X-Spam-Level: X-Spam-Status: No, score=-2.405 tagged_above=-999 required=5 tests=[AWL=-0.029, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id voCcr++JPBaY for ; Wed, 24 Oct 2012 08:14:19 -0700 (PDT) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8B68D21F8816 for ; Wed, 24 Oct 2012 08:14:18 -0700 (PDT) Received: by mail-la0-f44.google.com with SMTP id b11so442153lam.31 for ; Wed, 24 Oct 2012 08:14:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=4x44bJuL2KOkbw5UKx+M6ZdoLdx24gLPgKjnY6WRS8E=; b=YUzs9tVm5SK6mLMrxwNCsMIXy2js0b4ZVuXGcwRhpzxvVe4OZdQmcIL3RGMo7zxuWE RAMzrwbEfOGCFjKh6L5cmaS9CnDiN0AqXjKm+v7xooEKgYSqnMtTbDqK6CcitSI5aunM +KdQTWb6BaIRy7V8D5VpVdFEyaoz1Du1ZrBJ99ejxMy7XAdGFWwqnoCsZznGbhkj8qM3 2WNSPsGfcn5AF7wy5FUzgomBRb17fW+P9PcbOXWv/g390LriQkm5yyQtyoU1EE2ZyE3F rDAHz56iJpPTiWp+6XE4r6OtPIEGswCt492GXnIpNe+s9JwopucqhZqs+/CVE7S3dKO9 T2fw== MIME-Version: 1.0 Received: by 10.112.37.7 with SMTP id u7mr6524414lbj.30.1351091657423; Wed, 24 Oct 2012 08:14:17 -0700 (PDT) Received: by 10.112.1.40 with HTTP; Wed, 24 Oct 2012 08:14:17 -0700 (PDT) In-Reply-To: <20121024.133757.1265113932294838812.mbj@tail-f.com> References: <20121005.102805.519929541.mbj@tail-f.com> <5A949C32AF740C4798AEECF2568F0D84163A42@xmb-rcd-x13.cisco.com> <20121024.133757.1265113932294838812.mbj@tail-f.com> Date: Wed, 24 Oct 2012 08:14:17 -0700 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: multipart/alternative; boundary=e0cb4efa6e824cba9004cccf8af6 X-Gm-Message-State: ALoCoQna8PNkZNy+HK2l/+KTSpRIa/oqKdBtlR4sy6bcPsPQ/pdtcsNNnnfT1I38PIacCVT/ToHw Cc: netmod@ietf.org Subject: Re: [netmod] Fw: New Version Notification for draft-bjorklund-netmod-operational-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: Wed, 24 Oct 2012 15:14:19 -0000 --e0cb4efa6e824cba9004cccf8af6 Content-Type: text/plain; charset=UTF-8 On Wed, Oct 24, 2012 at 4:37 AM, Martin Bjorklund wrote: > Andy Bierman wrote: > > I do agree that config provided by the client for HW not present is > > operational state > > instead of config is a "pre-provisioned" state. > > I think you meant "I do not agree...". > > Well, neither do I. I don't think anyone said that pre-provisioned > config is operational state. > > > > There is another important corner-case related to operational state not > > mentioned > > in the draft, which is config=true operational state nodes. These are > > containers > > or lists that only the server can create -- e.g., the PHY interface list > > from the kernel. > > There is no standard way in YANG to say that the client can only edit > > descendant nodes > > of this config=true node. These nodes have to be saved in the NV-config > > because > > they are the parent nodes for all the client config. > > This is a different topic, but super simple to solve: The server > should not mess with the config at all. No magic handling of physical > interfaces. (they can be present as initial "factory created" config > though). > > A factory-created config node that the client cannot change in anyway, that gets saved in NV-storage as part of the config, is a special type of node. Even if the client could delete it, the server would add it right back, so what's the point? > /martin > Andy --e0cb4efa6e824cba9004cccf8af6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Wed, Oct 24, 2012 at 4:37 AM, Martin = Bjorklund <mbj@tail-f.com> wrote:
Andy Bierman <andy@yumaworks.com> wrote:
> I do agree that config provided by the client for HW not present is > operational state
> instead of config is a "pre-provisioned" state.

I think you meant "I do not agree...".

Well, neither do I. =C2=A0I don't think anyone said that pre-provisione= d
config is operational state.


> There is another important corner-case related to operational state no= t
> mentioned
> in the draft, which is config=3Dtrue operational state nodes. =C2=A0Th= ese are
> containers
> or lists that only the server can create -- e.g., the PHY interface li= st
> from the kernel.
> There is no standard way in YANG to say that the client can only edit<= br> > descendant nodes
> of this config=3Dtrue node. =C2=A0These nodes have to be saved in the = NV-config
> because
> they are the parent nodes for all the client config.

This is a different topic, but super simple to solve: =C2=A0The server
should not mess with the config at all. =C2=A0No magic handling of physical=
interfaces. =C2=A0(they can be present as initial "factory created&quo= t; config
though).



A factory-created config node that th= e client cannot change in anyway,
that gets saved in NV-storage a= s part of the config, is a special type
of node. =C2=A0Even if the client could delete it, the server would ad= d it right back,
so what's the point?




/martin


Andy
--e0cb4efa6e824cba9004cccf8af6-- From andy@yumaworks.com Wed Oct 24 08:20: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 64EEE21F8BAE for ; Wed, 24 Oct 2012 08:20:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.639 X-Spam-Level: X-Spam-Status: No, score=-2.639 tagged_above=-999 required=5 tests=[AWL=0.206, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_UNSUB18=0.131] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yumg7vFKSs5L for ; Wed, 24 Oct 2012 08:20:58 -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 5165D21F8B71 for ; Wed, 24 Oct 2012 08:20:58 -0700 (PDT) Received: by mail-lb0-f172.google.com with SMTP id k13so1285714lbo.31 for ; Wed, 24 Oct 2012 08:20:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=l+tACJmOy2NJ+Rb+ep7GigkTuBUxrBMjFPnojrrKgCQ=; b=m/m4qw4UhvrWWEF5kAHM39fYPVcrz2B/Ygaefw85WfHMkZ2TELt5fMVQw6RWG2+wKs 4xmaGHmKBVoYSmMnfosy5ONtDScgA9BjwjyGIZRJXfYE3xFkZAKrK0TunNLM1PpN0Ck4 Q4tIDpFSBwtW8W5reJ49N47vSMqkbNvxYlnrTjgytvKm9i6GjPfITAOXWtJ7rRr7Z9Sm C6jVJ0KLSHvDFf0yx6TyMU/yy6Rj2FNHcfLWcQrbZX6DuTZIz9N7WNU56Wj5ohuQnpNC TvjOKBB2VwVi46ywb1c9R2CFmFsyt/tLYtof/35AG4Zh/E3P8Qaf9KcxVTZioP+a9K3M XQUw== MIME-Version: 1.0 Received: by 10.112.13.173 with SMTP id i13mr6584961lbc.108.1351092057913; Wed, 24 Oct 2012 08:20:57 -0700 (PDT) Received: by 10.112.1.40 with HTTP; Wed, 24 Oct 2012 08:20:57 -0700 (PDT) In-Reply-To: <20121024.133213.428639413434989674.mbj@tail-f.com> References: <20121005.102805.519929541.mbj@tail-f.com> <5A949C32AF740C4798AEECF2568F0D84163A42@xmb-rcd-x13.cisco.com> <20121024.133213.428639413434989674.mbj@tail-f.com> Date: Wed, 24 Oct 2012 08:20:57 -0700 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: multipart/alternative; boundary=f46d0401f77f2bbb5204cccfa281 X-Gm-Message-State: ALoCoQnSilTeEepNsM4RmvNqgLl08qu2sBTDMEwX+IdeoHoVl1jj0J447ALADKnRF/k/A7RP1mbz Cc: netmod@ietf.org Subject: Re: [netmod] Fw: New Version Notification for draft-bjorklund-netmod-operational-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: Wed, 24 Oct 2012 15:20:59 -0000 --f46d0401f77f2bbb5204cccfa281 Content-Type: text/plain; charset=UTF-8 On Wed, Oct 24, 2012 at 4:32 AM, Martin Bjorklund wrote: > Andy Bierman wrote: > > Hi, > > > > IMO, there are many problems with editing operational state. > > > > There are security concerns wrt/ data injection attacks. > > Actually, this is can be controlled on a more fine-grained level (with > NACM) if the state is edited by a generic operation. If you have a > specific operation like 'inject-route' you can only permit/deny the > operation itself, you cannot check parameters to the rpc. > > IMO this is simpler. You don't really need to allow/deny based on individual parameters, just the acrtion. > > Does the server have to validate an operational datastore > > with YANG constraints like must-stmt and min-elements? > > No, I don't think this makes sense. > > Without it there are even more security concerns. Yet operational data can change a million times a second, way faster than config chances. Doing validation would be so expensive nobody could implement it. > > Do any servers in existence today actually validate operational state > > in any way? Without validation, there increased vulnerabilities > introduced. > > This is true also for special rpcs. > > No it is not -- all the CLI commands I have seen to alter system behavior have been specialized commands. There is no generic 'configure' command for arbitrary operational nodes. > > Since there is no 'candidate' config for editing operational > > state, there are ordering issues (similar to writing directly > > to running config). > > I think ordering is a bigger problem for special rpcs. With a generic > edit-operational, the client can send all data in one go. With > special rpcs it has to split the data into a bunch of special rpcs and > send them *in the correct order*. > > No -- poking data into the running state is way worse than forcing all related parameters for a particular task to be present at once. > > The server may not allow arbitrary edits > > in arbitrary order for operational state. This seems very difficult > > to standardize. There is no all-or-nothing transaction capability > > that the candidate config provides, so partial errors can leave > > the system in an unstable state. > > This is not better than if you do a bunch of special rpcs, and the 4th > fails. > > Not if the special RPCs are designed correctly so they are independent. If you need 4 RPCs to make 1 change, then we are back to the writable-running vs. candidate problem, and custom RPCs are the same as in this case. > > IMO, the design is too unconstrained, > > Yes, I agree that this can be a drawback with this design. > > > /martin > Andy --f46d0401f77f2bbb5204cccfa281 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Wed, Oct 24, 2012 at 4:32 AM, Martin = Bjorklund <mbj@tail-f.com> wrote:
Andy Bierman <andy@yumaworks.com> wrote:
> Hi,
>
> IMO, there are many problems with editing operational state.
>
> There are security concerns wrt/ data injection attacks.

Actually, this is can be controlled on a more fine-grained level (with
NACM) if the state is edited by a generic operation. =C2=A0If you have a specific operation like 'inject-route' you can only permit/deny the=
operation itself, you cannot check parameters to the rpc.


> Does the server have to validate an operational datastore
> with YANG constraints like must-stmt and min-elements?

No, I don't think this makes sense.


be so expensive nobody could implement it.

= =C2=A0
> Do any servers in existence today actually validate operational state<= br> > in any way? =C2=A0Without validation, there increased vulnerabilities = introduced.

This is true also for special rpcs.


No it is not -- all the CLI commands I= have seen to alter system behavior
have been specialized command= s. =C2=A0There is no generic 'configure' command
for arbi= trary operational nodes.

=C2=A0
> Since there is no 'candidate' config for editing operational > state, there are ordering issues (similar to writing directly
> to running config).

I think ordering is a bigger problem for special rpcs. =C2=A0With a generic=
edit-operational, the client can send all data in one go. =C2=A0With
special rpcs it has to split the data into a bunch of special rpcs and
send them *in the correct order*.


No -- poking data into the running sta= te is way worse than
forcing all related parameters for a particu= lar task to be present at once.
=C2=A0
> The server may not allow arbitrary edits
> in arbitrary order for operational state. =C2=A0This seems very diffic= ult
> to standardize. =C2=A0There is no all-or-nothing transaction capabilit= y
> that the candidate config provides, so partial errors can leave
> the system in an unstable state.

This is not better than if you do a bunch of special rpcs, and the 4th
fails.


Not if the special RPCs are designed c= orrectly so they are independent.
If you need 4 RPCs to make 1 ch= ange, then we are back to the
writable-running vs. candidate prob= lem, and custom RPCs are the
same as <edit-operational> in this case.


> IMO, the <edit-operational> design is too unconstrained,

Yes, I agree that this can be a drawback with this design.


/martin


Andy
--f46d0401f77f2bbb5204cccfa281-- From lhotka@nic.cz Thu Oct 25 06:30: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 886A321F8963 for ; Thu, 25 Oct 2012 06:30:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_23=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8qlDdBdVYRZi for ; Thu, 25 Oct 2012 06:30:42 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id E596F21F8960 for ; Thu, 25 Oct 2012 06:30:41 -0700 (PDT) Received: from [IPv6:2001:1488:ac14:1400:14b9:8c07:1336:653a] (unknown [IPv6:2001:1488:ac14:1400:14b9:8c07:1336:653a]) by mail.nic.cz (Postfix) with ESMTPSA id DE77513FD97 for ; Thu, 25 Oct 2012 15:30:40 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1351171840; bh=sbuFToWk+0HeCWvmGlaAHJ7LYcLOxygwt5/HCZRMQ2I=; h=From:Content-Type:Content-Transfer-Encoding:Subject:Message-Id: Date:To:Mime-Version; b=loAbAozOLPvWaKtUtppADbLDv7w7mZ+PyhjzE4SCKB25c805oMtWlB5+xoW4sgNBB 8dZTziEv8jqTRVcq8KKNoUtQaFueK91CKbie3WGSllanxHJ6HczkbJc4H4dta5NpMn MEl6oXb6wUOM7+dIe26mKAdACxAJ80zXHS4fOWKU= From: Ladislav Lhotka Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <56F7C195-CC90-427A-8681-EE292D9315E7@nic.cz> Date: Thu, 25 Oct 2012 15:30:40 +0200 To: netmod@ietf.org Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Subject: [netmod] ABNF - instance-identifier X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 25 Oct 2012 13:30:42 -0000 Hi, in RFC 6020 there seems to be a mismatch between the text in sec. 9.13.3 = (lexical representation of instance identifier) and the = "instance-identifier" production in the ABNF. The text requires each = component name to have an explicit namespace prefix but the production = uses "node-identifier" where the prefix is optional. Lada =20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From xiangli@seguesoft.com Thu Oct 25 17:17: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 81ABC21F8830 for ; Thu, 25 Oct 2012 17:17:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mxUiS1Sf7uu1 for ; Thu, 25 Oct 2012 17:17:26 -0700 (PDT) Received: from smtpauth23.prod.mesa1.secureserver.net (smtpauth23.prod.mesa1.secureserver.net [64.202.165.47]) by ietfa.amsl.com (Postfix) with SMTP id 4743421F881E for ; Thu, 25 Oct 2012 17:17:26 -0700 (PDT) Received: (qmail 29106 invoked from network); 26 Oct 2012 00:17:25 -0000 Received: from unknown (98.212.151.151) by smtpauth23.prod.mesa1.secureserver.net (64.202.165.47) with ESMTP; 26 Oct 2012 00:17:24 -0000 Message-ID: <5089D695.10000@seguesoft.com> Date: Thu, 25 Oct 2012 19:17:25 -0500 From: Xiang Li User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: netmod@ietf.org References: <20121005.102805.519929541.mbj@tail-f.com> In-Reply-To: <20121005.102805.519929541.mbj@tail-f.com> Content-Type: multipart/alternative; boundary="------------090906020508030905030807" Subject: Re: [netmod] Fw: New Version Notification for draft-bjorklund-netmod-operational-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Oct 2012 00:17:28 -0000 This is a multi-part message in MIME format. --------------090906020508030905030807 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi I have read this draft. I think it's a good draft since it helped me a lot understand the various issues with this "Operational state data". Just a few quick comments for now. 1. Terminology: The draft's title uses "Operational Data", but then later it defines "operational state data". I assume they are same thing and they probably should be made consistent. Similarly, both "operational data store" and "operational state datastore" are used in the draft. The objectives of the draft mention "to develop a general model applicable not only to NETCONF but also to other approaches (RESTful, editable state data etc.)". What's the difference between "editable state data" and "operational state data"? Or they are same thing? 2. Section 1.1.1 Terms: operational state data: The data in the operational state datastore. I think this definition is too vague. I think you might want to add something like the definition available from RFC6244: -Operational state data is a set of data that has been obtained by the system at runtime and influences the system's behavior similar to configuration data. In contrast to configuration data, operational state is transient and modified by interactions with internal components or other systems via specialized protocols. In general, the problem statement in this draft can be made clearer by including some background information,. For example, "Configuration data", "Operational state data", and "Statistical data"., and NETCONF's "config data" and 'state data" etc. in RFC6244. I think the terminology is rather important here since they are not something a lot of us already familiar. 3. In section 3.1.1 Interface list example, there is a sentence reads "The counter is operational state data." . I think it would help to explain a bit why is that? Most people would probably feel confused here since we all know "counter" is statistical data. 4 In appendix C. Example Admin vs Oper state. I thought this draft is going to solve the schema duplication even for this scenario. Looks like that's not the case. It would help if the draft explains a bit why the "schema duplication" in this case is not a concern? --Xiang On 10/5/2012 3:28 AM, Martin Bjorklund wrote: > Hi, > > Lada and I have written a draft where we try to define the concept of > operational state data. There are a couple of open issues in the > draft that need to be discussed, so please comment! > > > /martin & lada > > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- -- Xiang Li Web: www.seguesoft.com Voice: 1 (872) 216-2610 --------------090906020508030905030807 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi
I have read this draft. I think it's a good draft since it helped me a lot understand the various issues with this "Operational state data". Just a few quick comments for now.

1. Terminology:

The draft's title uses “Operational Data", but then later it defines "operational state data". I assume they are same thing and they probably should be made consistent.

Similarly, both "operational data store" and "operational state datastore" are used in the draft.

The objectives of the draft mention "to develop a general model applicable not only to NETCONF but also to   other approaches (RESTful, editable state data etc.)". What's the difference between “editable state data” and “operational state data”? Or they are same thing?

2. Section 1.1.1 Terms: operational state data: The data in the operational state  datastore.

I think this definition is too vague. I think you might want to add something like the definition  available from RFC6244:

-Operational state data is a set of data that has been obtained by  the system at runtime and influences the system's behavior similar to configuration data. In contrast to configuration data,  operational state is transient and modified by interactions with  internal components or other systems via specialized protocols.

In general, the problem statement in this draft can be made clearer by including some background information,. For example, “Configuration data”, “Operational state data”, and “Statistical data”., and NETCONF's “config data” and 'state data” etc.  in RFC6244.

I think the terminology is rather important here since they are not something a lot of us already familiar.

3. In section 3.1.1 Interface list  example,  there is a sentence reads “The counter is operational state data.” . I think it would help to explain a bit why is that? Most people would probably feel confused here since we all know “counter” is statistical data.

4 In appendix C. Example Admin vs Oper state. I thought this draft is going to solve the schema duplication even for this scenario. Looks like that's not the case.

It would help if the draft explains a bit why the “schema duplication” in this case is not a concern?

--Xiang
On 10/5/2012 3:28 AM, Martin Bjorklund wrote:
Hi,

Lada and I have written a draft where we try to define the concept of
operational state data.  There are a couple of open issues in the
draft that need to be discussed, so please comment!


/martin & lada





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


-- 
--
Xiang Li
Web: www.seguesoft.com
Voice: 1 (872) 216-2610
--------------090906020508030905030807-- From bclaise@cisco.com Tue Oct 30 09:04: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 0BFE621F8629; Tue, 30 Oct 2012 09:04:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.795 X-Spam-Level: X-Spam-Status: No, score=-8.795 tagged_above=-999 required=5 tests=[AWL=-1.743, BAYES_00=-2.599, HTML_IMAGE_ONLY_16=1.526, HTML_MESSAGE=0.001, J_CHICKENPOX_46=0.6, RCVD_IN_DNSWL_HI=-8, SARE_GIF_ATTACH=1.42] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l5e3TdDyWnvb; Tue, 30 Oct 2012 09:04:51 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 9BF8121F8624; Tue, 30 Oct 2012 09:04:50 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q9UG1JqV026360; Tue, 30 Oct 2012 17:01:20 +0100 (CET) Received: from [10.60.67.92] (ams-bclaise-89111.cisco.com [10.60.67.92]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q9UG1Jji018135; Tue, 30 Oct 2012 17:01:19 +0100 (CET) Message-ID: <508FF9CF.2050902@cisco.com> Date: Tue, 30 Oct 2012 17:01:19 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: NETMOD Working Group , NETCONF Content-Type: multipart/alternative; boundary="------------040703080709090709040808" Cc: Adrian Farrel Subject: [netmod] Please attend the IRS BoF X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2012 16:04:52 -0000 This is a multi-part message in MIME format. --------------040703080709090709040808 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear all, I encourage you all to attend the IRS BoF, 1740-1940 Afternoon Session III Salon D RTG irs Interface to the Routing System BOF This BoF will!should be speaking about YANG for data modeling. Unfortunately, no agenda yet at https://datatracker.ietf.org/meeting/85/agenda.html The mailer is https://www.ietf.org/mailman/listinfo/irs-discuss Regards, Benoit. --------------040703080709090709040808 Content-Type: multipart/related; boundary="------------080106010402030208030902" --------------080106010402030208030902 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear all,

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

Salon D RTG irs Interface to the Routing System BOF

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

Regards, Benoit.



--------------080106010402030208030902 Content-Type: image/gif; name="color-palette-4x4.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="color-palette-4x4.gif" R0lGODlhEAAQAMIDAAAA//8AAP//AP///6CgoP///////////yH5BAEKAAcALAAAAAAQABAA AAMreLrc/jA6Qmm4d1aCc9tcp1VdMFpiA6yr4LoO275CLNO1etM2i0vAoLCRAAA7 --------------080106010402030208030902-- --------------040703080709090709040808-- From lhotka@nic.cz Tue Oct 30 10:34: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 E6F1421F8741; Tue, 30 Oct 2012 10:34:14 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T2pvCgXFxYP5; Tue, 30 Oct 2012 10:34:12 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 18C1921F8671; Tue, 30 Oct 2012 10:34:12 -0700 (PDT) Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 7E8D31410CD; Tue, 30 Oct 2012 18:34:10 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1351618450; bh=qXySzrMr0NjPNTCHXerJqOq1R8FJwvAaoctKvqnzFHo=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=AoUZLQyGNC+nfJZI8NV0ZDgavC8LW7DjbiPwEjoL4nEPz5YTxUuQqrAPgXB8pbFxN 7tfRazcOGqUhWZ/q6/NvGo0//bNgSK2uZTPYrlbeQ/bi7X4CTH3zlwPTJVXK30KX6s z721qZ5CkhvSoUA0DLQY5mRAJuI4SOQNhAei4rZs= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ladislav Lhotka In-Reply-To: <20121029162930.GA94042@elstar.local> Date: Tue, 30 Oct 2012 18:34:10 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20121029162930.GA94042@elstar.local> To: brijsman@juniper.net X-Mailer: Apple Mail (2.1499) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: netmod@ietf.org, irs-discuss@ietf.org Subject: Re: [netmod] A few comments on the draft-ietf-netmod-routing-cfg-04 draft. X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2012 17:34:17 -0000 Hi Bruno, first of all, I have to apologise that I didn't answer your comments in = a timely manner, the message somehow fell through the cracks. :-( I hope = it's still not too late though the draft is now at revision -05. So, thanks for your comments, please see my responses inline. =20 >=20 > -------- Original Message -------- > Subject: [irs-discuss] A few comments on the = draft-ietf-netmod-routing-cfg-04 draft. > Date: Mon, 3 Sep 2012 07:15:08 -0400 > From: Bruno Rijsman > To: netmod@ietf.org > CC: irs-discuss@ietf.org >=20 > I have a few comments on the draft-ietf-netmod-routing-cfg-04 draft. >=20 > 1) Generalize the concept of a next-hop >=20 > It appears that in the current model, routes can point to an outgoing = interface and a next-hop address. The concept of next-hops needs to be = generalized. Next-hops can have multiple tuples of outgoing interfaces = and next-hop addresses. The most common reasons is Equal Cost Multi Path = (ECMP) where a single route has multiple next-hops. This is not the same = as multi-pathing in the sense of multiple active routes to the same = prefix each contributing one next-hop. A variation of this is NECMP = where the next-hops are different weights. Another reason for multiple = next-hops is fast re-route where the next-hops represent alternatives = (the first one whose interface is up is used). Another needed = generalization of next-hops is the ability to push and pop MPLS labels, = VLAN tags, etc. Another is the ability to add a level of indirection = (e.g. BGP indirect next-hop for fast BGP reconvergence). The OpenFlow = 1.x documents are a good source to look for generalized next-hop = examples. I assume that multiple next-hops to the same destination will appear as = two separate routes. And indeed, the two routes may have different = weights. MPLS is outside the scope for the core routing data model, although the = framework should be ready to incorporate MPLS etc. via augments from = other modules. >=20 >=20 > 2) Generalize the concept of a prefix >=20 > Section 4.2 says that the core routing data model only defines the = following minimal set of route attributes: destination-prefix, next-hop, = outgoing-interface. However, in section 4 there are no = destination-prefix or next-hop. There are only v4ur:dest-prefix, = v4ur:next-hop, v6ur:dest-prefix, v6ur:next-hop. It appears that the Why is it a problem? These parameters are address family specific, so = they are defined in the ietf-ipv[46]-unicast-routing modules. Each = routing table only contains routes of a single address family, so the = ipv4:* and ipv6:* nodes can never appear as sibling elements in a = configuration or state data. > destination-prefix and next-hop were removed from the base object and = moved to the derived object. In my opinion, it would make sense to move = the destination-prefix (as a simple bit-string and length) and the = next-hop back to the base object. The derived object could have a string = object to contain the destination-prefix as a human-readable string = (e.g. "10.0.0.0/8" for an IPv4 prefix). Furthermore, section 4.2 assumes = that the routes are always IP routes (it uses repeatedly uses terms like = "IP prefix"). The routes can be non-IP routes. For example, MPLS routes = which are /20 exact matches on a label, or CLNS routes, or other = protocols > . Some VPLS implemen > tations even use the "routing table" abstraction to represent Ethernet = routes (as exact /48 routes on MAC addresses). Sure, modules for other address families can define their own parameters = of routes. They are supposed to be filled in via YANG augments. The core = routing data model only deals with IP. >=20 > 3) Static (and direct) routes for multiple routing tables. >=20 > Figure 2 appears to imply that static and direct routes can only be = inserted in the main routing table. Is it possible to install static = routes in multiple additional routing tables? This is now better explained in revision -05. Direct routes are always = installed in the main routing table but the static pseudo-protocol can = be connected to any table. Routes from any table can be installed in = other routing tables by means of the mechanism of recipient routing = tables and filters (sec. 4.3). Figure 2 is just an example. >=20 >=20 > 4) More attributes for static routes. >=20 > Configured static routes (routes in the pseudo routing-protocol = "static") need more attributes (e.g. metric). This can be done, although the use case for metrics of static routes is = not very clear to me, unless there is a way for redistributing such = routes to other routing protocols. Such parameters can be added via = augments from other (generic or vendor-specific) modules, if necessary. = In the core routing model, we tried to limit the number of parameters to = a reasonable minimum, or otherwise we will never finish this work. >=20 > 5) Add support for routing-instances. >=20 > Allow the creation of multiple routing-instances (also known as VRFs) = per logical-router. Allow interfaces to be assigned to = routing-instances. Allow multiple instances of routing protocols, scoped = by routing-instance. In rev. -05, each router instance has the "type" parameter so that the = same flat list of router instances may contain VRFs as well as = self-contained logical/virtual routers that differ in the type = parameter. New modules defining a particular router type then have to = specify the rules. e.g., whether/how routing tables can be shared among = router instances. >=20 > 6) Ability for a client to subscribe to RIB changes >=20 > It would be very useful for a client to be able to subscribe to route = table changes. (I am not a YANG expert and I don't know if such a thing = is even possible in YANG.) In the subscription, the client could specify = one or more routing tables in which it is interested and filter(s) to = specify which subset of routes it is interested in. This can be done using a NETCONF notification, but again - I am afraid = of feature creep, so I would leave this extension to a separate module. >=20 > 7) More sophisticated filters >=20 > Section 4.5 explicitly says that the core routing data model only = defines a skeleton for filtering. It would be "good" for the working = group to continue this work and define more sophisticated filtering = mechanisms. When we were discussing the current NETMOD charter, I proposed to work = on route filters but I didn't get support for this idea. Anyway, this = should probably be addressed by routing experts - I will be happy to = help. There is now a draft/module on ACLs = (http://tools.ietf.org/html/draft-huang-netmod-acl-01) that goes in this = direction. Thanks, Lada >=20 > -- Bruno >=20 > PS: Cross-post to the Interface to the Routing System (IRS) mailing = list because they are discussing very similar functionality. > _______________________________________________ > irs-discuss mailing list >=20 > irs-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/irs-discuss >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From phil@juniper.net Tue Oct 30 11:23: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 CE18821F860B; Tue, 30 Oct 2012 11:23:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EQ-myOLCdekR; Tue, 30 Oct 2012 11:23:29 -0700 (PDT) Received: from exprod7og121.obsmtp.com (exprod7og121.obsmtp.com [64.18.2.20]) by ietfa.amsl.com (Postfix) with ESMTP id A007521F8607; Tue, 30 Oct 2012 11:23:26 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob121.postini.com ([64.18.6.12]) with SMTP ID DSNKUJAbHikLJuK7NX1aHkIohcuokQKTjyFB@postini.com; Tue, 30 Oct 2012 11:23:28 PDT Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB01-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 30 Oct 2012 11:19:38 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id q9UIJah85600; Tue, 30 Oct 2012 11:19:36 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.4/8.14.3) with ESMTP id q9UIJYHD037109; Tue, 30 Oct 2012 14:19:35 -0400 (EDT) (envelope-from phil@idle.juniper.net) Message-ID: <201210301819.q9UIJYHD037109@idle.juniper.net> To: Benoit Claise In-Reply-To: <508FF9CF.2050902@cisco.com> Date: Tue, 30 Oct 2012 14:19:34 -0400 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain Cc: Adrian Farrel , NETCONF , NETMOD Working Group Subject: Re: [netmod] Please attend the IRS BoF X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2012 18:23:29 -0000 Benoit Claise writes: >I encourage you all to attend the IRS BoF, 1740-1940 Afternoon Session III FYI: It's Monday (11/5). Thanks, Phil From adrian@olddog.co.uk Tue Oct 30 19:42:17 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78F2421F85FF; Tue, 30 Oct 2012 19:42:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.589 X-Spam-Level: X-Spam-Status: No, score=-3.589 tagged_above=-999 required=5 tests=[AWL=-3.010, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_46=0.6, SARE_GIF_ATTACH=1.42] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2NlrfGKRtqt1; Tue, 30 Oct 2012 19:42:16 -0700 (PDT) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) by ietfa.amsl.com (Postfix) with ESMTP id BD15B21F85ED; Tue, 30 Oct 2012 19:42:15 -0700 (PDT) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id q9V2gBgK031954; Wed, 31 Oct 2012 02:42:11 GMT Received: from 950129200 (ip-64-134-100-50.public.wayport.net [64.134.100.50]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id q9V2fp1X031870 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 31 Oct 2012 02:41:55 GMT From: "Adrian Farrel" To: "'Benoit Claise'" , "'NETMOD Working Group'" , "'NETCONF'" References: <508FF9CF.2050902@cisco.com> In-Reply-To: <508FF9CF.2050902@cisco.com> Date: Wed, 31 Oct 2012 01:41:51 -0000 Message-ID: <000001cdb708$ef460fe0$cdd22fa0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_0001_01CDB708.EF56B1B0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQEDoCyoHvXiJdLSEk9D0EOlbqcWLZlmX20w Content-Language: en-gb Subject: Re: [netmod] Please attend the IRS BoF X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 02:42:17 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0001_01CDB708.EF56B1B0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0002_01CDB708.EF56B1B0" ------=_NextPart_001_0002_01CDB708.EF56B1B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I shall be disappointed if this BoF talks about YANG for data modelling. The first draft of the charter posted on the IRS mailing list says: > The IRS working group works to develop a framework and > architecture that will enable specific use cases, and lead to > an understanding of the informational models and > requirements for encodings and protocols. ...and > The working group is chartered to work on the following items: > > 1. Architecture and framework for IRS including considerations of > policy and security > > 2. Tightly scoped key use cases for operational use of IRS. These > use cases will include at least: > - Interactions with the RIB > - Association of routing policies with routing state > - The ability to extract information about topology from the network. > Injection and creation of topology will not be considered as an initial > work item. > Other use cases may be adopted by the working group only after > milestones have been added to the charter page. > > 3. Abstract information models consistent with the use cases > > 4. Requirements for IRS protocols and encoding languages > > 5. An analysis of existing IETF and other protocols and encoding languages against the requirements. ...and > The working group is not currently chartered to develop protocols, > encoding languages, or data models. What is more, the BoF description posted on the wiki and forming part of the grant of the BoF says: > This BoF is to determine focus and support for work within the IETF > to specify abstract data information models, specific data models, > and protocols to operate the IRS. The BoF does not assume that new > data modeling languages or protocols will be required - that decision > is expected to form part of the analysis carried out by a working > group if one is formed. My disappointment if YANG is mentioned during the BoF will be because it will demonstrate that people have not understood the need to develop use cases and requirements *before* discussing whether existing protocols and encoding languages are suitable for the task at hand. It would be frankly as absurd to rule out Netconf as one of the protocols used in IRS as it would be to demand that it is used because we have currently no idea what function we are trying to provide. Similarly, it would be wrong to rule YANG in or out at this stage. So, I hope the BoF will talk about use cases and WG charter, and not about solution protocols and encoding languages. Nevertheless, I hope that we get lots of Ops clue in this meeting and encourage you to come along. Thanks, Adrian From: Benoit Claise [mailto:bclaise@cisco.com] Sent: 30 October 2012 16:01 To: NETMOD Working Group; NETCONF Cc: Adrian Farrel Subject: Please attend the IRS BoF Dear all, I encourage you all to attend the IRS BoF, 1740-1940 Afternoon Session III Salon D RTG irs Description: cid:part2.02000006.09090603@cisco.comInterface to the Routing System BOF This BoF will!should be speaking about YANG for data modeling. Unfortunately, no agenda yet at https://datatracker.ietf.org/meeting/85/agenda.html The mailer is https://www.ietf.org/mailman/listinfo/irs-discuss Regards, Benoit. ------=_NextPart_001_0002_01CDB708.EF56B1B0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

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

 

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

 

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

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

> an understanding of the = informational models and

> requirements for = encodings and protocols.

 

...and

 

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

> 

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

>    policy and = security

> 

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

>  use cases will include at = least:

> - Interactions with the = RIB

> - Association of routing = policies with routing state

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

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

>    work = item.

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

> milestones have been = added to the charter page.

> 

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

> 

> 4. Requirements for IRS = protocols and encoding languages

>

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

 

...and

 

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

> encoding languages, or = data models.

 

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

 

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

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

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

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

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

>   group if one is = formed.

 

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

 

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

 

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

 

Thanks,

Adrian

 

 

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

 

Dear all,

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

Salon = D

RTG

irs

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


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

Regards, Benoit.


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