From nobody Sun Jun 1 08:20:07 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9F1A1A0237 for ; Sun, 1 Jun 2014 08:19:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VZiuEwpb21hF for ; Sun, 1 Jun 2014 08:19:58 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C93191A0234 for ; Sun, 1 Jun 2014 08:19:57 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 92DF3D2D for ; Sun, 1 Jun 2014 17:19:49 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id g4aOLlnSXu-i for ; Sun, 1 Jun 2014 17:19:28 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Sun, 1 Jun 2014 17:19:48 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4DBDB20013 for ; Sun, 1 Jun 2014 17:19:50 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id thiopRHv1ewM; Sun, 1 Jun 2014 17:19:49 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8049420017; Sun, 1 Jun 2014 17:19:48 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 924C32D144C5; Sun, 1 Jun 2014 17:19:47 +0200 (CEST) Date: Sun, 1 Jun 2014 17:19:47 +0200 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20140601151947.GA90395@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.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/8z2MR4Z0FRiBfcTH95BC0opkmtQ Subject: [netmod] strawman REJECT Y08 make leaf-list of type empty illegal X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jun 2014 15:20:00 -0000 This seems to be one out of many possible pathological cases and it does not seem sensible to come up with rules to fobid all pathological cases. Tool writers can of course generate proper warnings if tools detect pathological cases (like many C compiler do and some of the SMIv2 parsers do as well). Speak up by June 10th if you disagree with this strawman proposal. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Sun Jun 1 08:20:09 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B0E41A0234 for ; Sun, 1 Jun 2014 08:20:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SPjZtJF-TiRe for ; Sun, 1 Jun 2014 08:19:59 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FA9D1A0236 for ; Sun, 1 Jun 2014 08:19:59 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id A4173FC4 for ; Sun, 1 Jun 2014 17:19:51 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id jNSaQ-pqyZYj for ; Sun, 1 Jun 2014 17:19:31 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Sun, 1 Jun 2014 17:19:51 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id CD5FC20017 for ; Sun, 1 Jun 2014 17:19:52 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id rsPkiyZR28U5; Sun, 1 Jun 2014 17:19:52 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5558F20013; Sun, 1 Jun 2014 17:19:51 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 529B42D144D9; Sun, 1 Jun 2014 17:19:51 +0200 (CEST) Date: Sun, 1 Jun 2014 17:19:51 +0200 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20140601151951.GB90395@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.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/BsIAx_St-mAt7wVG_Fo2Diks6bQ Subject: [netmod] strawman REJECT Y15 identity advertisement problem X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jun 2014 15:20:00 -0000 This issue seems to be subsumed by Y45. Speak up by June 10th if you disagree with this strawman proposal. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Sun Jun 1 08:20:22 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EB9E1A0245 for ; Sun, 1 Jun 2014 08:20:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d30eMvDJm5bF for ; Sun, 1 Jun 2014 08:20:02 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 505FD1A0234 for ; Sun, 1 Jun 2014 08:20:02 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id DCF41D2D for ; Sun, 1 Jun 2014 17:19:54 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id qHDJGXAURzDg for ; Sun, 1 Jun 2014 17:19:34 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Sun, 1 Jun 2014 17:19:54 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0FE3B2002C for ; Sun, 1 Jun 2014 17:19:56 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 81kXDuqWoQwm; Sun, 1 Jun 2014 17:19:55 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B234420013; Sun, 1 Jun 2014 17:19:54 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id AFC442D144EB; Sun, 1 Jun 2014 17:19:54 +0200 (CEST) Date: Sun, 1 Jun 2014 17:19:54 +0200 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20140601151954.GC90395@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.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/QQWXXn82W98faLpVNRUqghMgGHY Subject: [netmod] strawman REJECT Y17 support "augment" of unique X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jun 2014 15:20:07 -0000 It seems existing workarounds using must expressions are sufficient. Speak up by June 10th if you disagree with this strawman proposal. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Sun Jun 1 08:20:24 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FFB41A024B for ; Sun, 1 Jun 2014 08:20:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pTacDvIk1cj6 for ; Sun, 1 Jun 2014 08:20:05 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B07E1A0239 for ; Sun, 1 Jun 2014 08:20:05 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id D26FFD2D for ; Sun, 1 Jun 2014 17:19:57 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id Fx7SE6JgPFvQ for ; Sun, 1 Jun 2014 17:19:37 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Sun, 1 Jun 2014 17:19:57 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 06D8620017 for ; Sun, 1 Jun 2014 17:19:59 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id FZ_4e7Ly20x9; Sun, 1 Jun 2014 17:19:58 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C90D320013; Sun, 1 Jun 2014 17:19:57 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id C6C4F2D144FD; Sun, 1 Jun 2014 17:19:57 +0200 (CEST) Date: Sun, 1 Jun 2014 17:19:57 +0200 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20140601151957.GD90395@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.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/g-p-WhJFphecLhhNaArcn0fqvd4 Subject: [netmod] strawman REJECT Y24 YIN -> YANG translation breaks text formatting X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jun 2014 15:20:08 -0000 This seems to add quite some complexity and it is unclear how widely YIN is used to write YANG (most people seem to write YANG directly). Speak up by June 10th if you disagree with this strawman proposal. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Sun Jun 1 08:21:20 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBFC91A0245 for ; Sun, 1 Jun 2014 08:21:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V8uuGnWS0P7V for ; Sun, 1 Jun 2014 08:21:13 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C591C1A0240 for ; Sun, 1 Jun 2014 08:21:12 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id A077911F9 for ; Sun, 1 Jun 2014 17:20:30 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id t54C5E4hR9iA for ; Sun, 1 Jun 2014 17:20:10 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Sun, 1 Jun 2014 17:20:30 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id BF86E20017 for ; Sun, 1 Jun 2014 17:20:31 +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 8CyPpV2pZZqA; Sun, 1 Jun 2014 17:20:31 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9B08420013; Sun, 1 Jun 2014 17:20:30 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 984B82D145BD; Sun, 1 Jun 2014 17:20:30 +0200 (CEST) Date: Sun, 1 Jun 2014 17:20:30 +0200 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20140601152030.GM90395@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.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/MOgVHr54mI9JUSFQwoRuvLfp7pw Subject: [netmod] strawman REJECT Y52 add a shorthand statement for 'mandatory' X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jun 2014 15:21:15 -0000 The benefit of this remains unclear. There is a trade-off between explicit text and inherited properties, which may not be obvious for a reader. Speak up by June 10th if you disagree with this strawman proposal. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Sun Jun 1 08:21:22 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98F691A0240 for ; Sun, 1 Jun 2014 08:21:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ynPhIJ1T2wB for ; Sun, 1 Jun 2014 08:21:13 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0AAA1A0236 for ; Sun, 1 Jun 2014 08:21:12 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id A1A5F11EB for ; Sun, 1 Jun 2014 17:20:26 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 3sMi2hibSwkJ for ; Sun, 1 Jun 2014 17:20:06 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Sun, 1 Jun 2014 17:20:26 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id C83A220013 for ; Sun, 1 Jun 2014 17:20:27 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id GHe__lxpKi_7; Sun, 1 Jun 2014 17:20:27 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2B2A420017; Sun, 1 Jun 2014 17:20:27 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 27CAF2D14598; Sun, 1 Jun 2014 17:20:26 +0200 (CEST) Date: Sun, 1 Jun 2014 17:20:26 +0200 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20140601152026.GL90395@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.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/Q-yLoLD2pzpv125DUQFLy9x3o9E Subject: [netmod] strawman REJECT Y51 support for long running commands X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jun 2014 15:21:15 -0000 A proper (that is less complex) solution requires specific protocol support and thus this falls out of scope for YANG 1.1. Speak up by June 10th if you disagree with this strawman proposal. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Sun Jun 1 08:21:23 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 465B41A0236 for ; Sun, 1 Jun 2014 08:21:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 55BhtW-0KHWO for ; Sun, 1 Jun 2014 08:21:15 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1FFB1A023A for ; Sun, 1 Jun 2014 08:21:12 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id AA96B11FE for ; Sun, 1 Jun 2014 17:20:34 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id VGWl9W5hEaH9 for ; Sun, 1 Jun 2014 17:20:14 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Sun, 1 Jun 2014 17:20:34 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6824120013 for ; Sun, 1 Jun 2014 17:20:35 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id PG0Y4_3LjuRf; Sun, 1 Jun 2014 17:20:35 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4A55520017; Sun, 1 Jun 2014 17:20:34 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 46EEF2D145F9; Sun, 1 Jun 2014 17:20:34 +0200 (CEST) Date: Sun, 1 Jun 2014 17:20:34 +0200 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20140601152034.GN90395@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.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/tzYcJDSI5iHcT07AY8af3k50PDs Subject: [netmod] strawman REJECT Y53 allow deep keys X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jun 2014 15:21:17 -0000 Nested keys add a lot of complexity. Other solutions may be possible, see also relationship to Y09. Speak up by June 10th if you disagree with this strawman proposal. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Sun Jun 1 08:21:31 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41A6A1A0259 for ; Sun, 1 Jun 2014 08:21:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d6S9GeDwatVZ for ; Sun, 1 Jun 2014 08:21:22 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71B931A0253 for ; Sun, 1 Jun 2014 08:21:22 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id DE36FD2D for ; Sun, 1 Jun 2014 17:20:01 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id XNUeNjEMFscl for ; Sun, 1 Jun 2014 17:19:41 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Sun, 1 Jun 2014 17:20:01 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1791220017 for ; Sun, 1 Jun 2014 17: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 (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 8_rxOisSQ7uh; Sun, 1 Jun 2014 17:20:02 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B0C8D20013; Sun, 1 Jun 2014 17:20:01 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id AE38E2D1450F; Sun, 1 Jun 2014 17:20:01 +0200 (CEST) Date: Sun, 1 Jun 2014 17:20:01 +0200 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20140601152001.GE90395@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.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/SAtz0iK4bpcXYq2tER3sTW0-zkg Subject: [netmod] strawman REJECT Y31 allow require-instance in leafref X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jun 2014 15:21:24 -0000 This can already be done in other ways. Speak up by June 10th if you disagree with this strawman proposal. -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Sun Jun 1 08:22:55 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 445D71A0245 for ; Sun, 1 Jun 2014 08:22:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H2Of8zzGzGOS for ; Sun, 1 Jun 2014 08:22:52 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A958A1A0240 for ; Sun, 1 Jun 2014 08:22:52 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 0E54A11B9 for ; Sun, 1 Jun 2014 17:20:13 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id Eao3ZC2ZUDQO for ; Sun, 1 Jun 2014 17:19:52 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Sun, 1 Jun 2014 17:20:12 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 10FDE20017 for ; Sun, 1 Jun 2014 17:20:14 +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 JVHM7xCStT8H; Sun, 1 Jun 2014 17:20:12 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4178E20013; Sun, 1 Jun 2014 17:20:12 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 3F03B2D14545; Sun, 1 Jun 2014 17:20:12 +0200 (CEST) Date: Sun, 1 Jun 2014 17:20:12 +0200 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20140601152012.GH90395@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.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/WVFX_tZXh4gIylG7T-Qc8094TTY Subject: [netmod] strawman REJECT Y40 add floating point base types X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jun 2014 15:22:54 -0000 YANG supports the decimal64 type and decimal64 is believed to be good enough for most situations and it does not suffer from floating point related issues. Speak up by June 10th if you disagree with this strawman proposal. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Sun Jun 1 08:22:56 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 989091A0240 for ; Sun, 1 Jun 2014 08:22:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E5gyu6Gk26Ni for ; Sun, 1 Jun 2014 08:22:52 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A89281A0237 for ; Sun, 1 Jun 2014 08:22:52 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id E1CFB119C for ; Sun, 1 Jun 2014 17:20:07 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 3KDhY_mladyO for ; Sun, 1 Jun 2014 17:19:47 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Sun, 1 Jun 2014 17:20:07 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0F5A820017 for ; Sun, 1 Jun 2014 17:20:09 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id Ytq2CTkEQWlF; Sun, 1 Jun 2014 17:20:08 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id E88C320013; Sun, 1 Jun 2014 17:20:07 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id E67862D14533; Sun, 1 Jun 2014 17:20:07 +0200 (CEST) Date: Sun, 1 Jun 2014 17:20:07 +0200 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20140601152007.GG90395@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.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/gaKdnHddfbUGDthJZWjj45CIGwY Subject: [netmod] strawman REJECT Y38 add 'mandatory' to NP-container X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jun 2014 15:22:54 -0000 This can already be done with YANG 1.0 using must statements. Speak up by June 10th if you disagree with this strawman proposal. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Sun Jun 1 08:23:11 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C36B1A025C for ; Sun, 1 Jun 2014 08:23:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bSW30jof_RDw for ; Sun, 1 Jun 2014 08:23:03 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 568161A024F for ; Sun, 1 Jun 2014 08:23:03 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id E9DF011CD for ; Sun, 1 Jun 2014 17:20:16 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id sKiZoYZv_WlS for ; Sun, 1 Jun 2014 17:19:56 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Sun, 1 Jun 2014 17:20:16 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 239C32002C for ; Sun, 1 Jun 2014 17:20:18 +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 LI2ILPybMNjC; Sun, 1 Jun 2014 17:20:17 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7339320017; Sun, 1 Jun 2014 17:20:17 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 0C0632D14557; Sun, 1 Jun 2014 17:20:17 +0200 (CEST) Date: Sun, 1 Jun 2014 17:20:17 +0200 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20140601152017.GI90395@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.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/o_OHCvv41S8oovIUrz-aW2WbdO4 Subject: [netmod] strawman REJECT Y43 add exception statement X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jun 2014 15:23:07 -0000 It is unclear how valuable reusable but somewhat exceptions in real data models are. Speak up by June 10th if you disagree with this strawman proposal. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Sun Jun 1 08:23:12 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76FD61A0237 for ; Sun, 1 Jun 2014 08:23:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0btmF85Lublb for ; Sun, 1 Jun 2014 08:23:07 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DA171A025A for ; Sun, 1 Jun 2014 08:23:03 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 73ED211E7 for ; Sun, 1 Jun 2014 17:20:23 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id OrZyii6qayAr for ; Sun, 1 Jun 2014 17:20:02 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Sun, 1 Jun 2014 17:20:23 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9708F2002C for ; Sun, 1 Jun 2014 17:20:24 +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 nIwwTDMhpCzb; Sun, 1 Jun 2014 17:20:24 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D492720017; Sun, 1 Jun 2014 17:20:23 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id D1CCB2D1457B; Sun, 1 Jun 2014 17:20:23 +0200 (CEST) Date: Sun, 1 Jun 2014 17:20:23 +0200 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20140601152023.GK90395@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.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/1bWql4C-LXqahcgpBl1w5sjmrpA Subject: [netmod] strawman REJECT Y48 enabled leaf design pattern X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jun 2014 15:23:09 -0000 The 'enabled' leafs do not have special semantics regarding validation rules. A mechanism to 'comment out' configuration requires likely a solution for Y33 and likely an update of the protocol. Speak up by June 10th if you disagree with this strawman proposal. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Sun Jun 1 08:25:47 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E98321A0240 for ; Sun, 1 Jun 2014 08:25:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WBiEan4eVwMl for ; Sun, 1 Jun 2014 08:25:42 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A471C1A0236 for ; Sun, 1 Jun 2014 08:25:42 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 6DD0211E3 for ; Sun, 1 Jun 2014 17:20:20 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 86FY5WDBBz7A for ; Sun, 1 Jun 2014 17:19:59 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Sun, 1 Jun 2014 17:20:20 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9AED72002C for ; Sun, 1 Jun 2014 17:20:21 +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 7HHS6XSIVjBA; Sun, 1 Jun 2014 17:20:21 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D492020017; Sun, 1 Jun 2014 17:20:20 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id CF3492D14569; Sun, 1 Jun 2014 17:20:20 +0200 (CEST) Date: Sun, 1 Jun 2014 17:20:20 +0200 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20140601152020.GJ90395@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.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/VIJqqtnKCZnwAEwnRnDulnyFna4 Subject: [netmod] strawman REJECT Y46 data-specific meta-data X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jun 2014 15:25:44 -0000 It seems Y33 subsumes this issue. Speak up by June 10th if you disagree with this strawman proposal. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Sun Jun 1 08:26:15 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 311F71A0236 for ; Sun, 1 Jun 2014 08:26:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FbiWFqhrPFK7 for ; Sun, 1 Jun 2014 08:26:14 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BD441A0253 for ; Sun, 1 Jun 2014 08:26:12 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 256E81172 for ; Sun, 1 Jun 2014 17:20:05 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id h0nwOoTR6v1f for ; Sun, 1 Jun 2014 17:19:44 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Sun, 1 Jun 2014 17:20:04 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 47E9A20017 for ; Sun, 1 Jun 2014 17:20:06 +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 K2HTna-2L44R; Sun, 1 Jun 2014 17:20:05 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2D19B20013; Sun, 1 Jun 2014 17:20:05 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 2AD362D14521; Sun, 1 Jun 2014 17:20:05 +0200 (CEST) Date: Sun, 1 Jun 2014 17:20:05 +0200 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20140601152005.GF90395@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.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/8MhK7w2NhQ1bvU0wXitBmpfPpx0 Subject: [netmod] strawman REJECT Y32 allow boolean combinations of pattern X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jun 2014 15:26:15 -0000 It seems this can already be done with YANG 1.0. Speak up by June 10th if you disagree with this strawman proposal. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Sun Jun 1 11:27:55 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4810C1A0270 for ; Sun, 1 Jun 2014 11:27:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T8Pl0mlSKBev for ; Sun, 1 Jun 2014 11:27:52 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id 272531A006E for ; Sun, 1 Jun 2014 11:27:51 -0700 (PDT) Received: from localhost (s193-12-74-81.cust.tele2.se [193.12.74.81]) by mail.tail-f.com (Postfix) with ESMTPSA id CD2B912807E1; Sun, 1 Jun 2014 20:27:02 +0200 (CEST) Date: Sun, 01 Jun 2014 20:27:44 +0200 (CEST) Message-Id: <20140601.202744.130295322.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20140601152001.GE90395@elstar.local> References: <20140601152001.GE90395@elstar.local> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/Y_BfNFS8XpfIqFhAVGcLCFhJGS8 Cc: netmod@ietf.org Subject: Re: [netmod] strawman REJECT Y31 allow require-instance in leafref X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jun 2014 18:27:54 -0000 Juergen Schoenwaelder wrote: > This can already be done in other ways. How? We have a vendor-specific extension to deal with this. The current situation means leafrefs and instance-identifiers have different behavior, for no apparent reason. > Speak up by June 10th if you disagree with this strawman proposal. I do not agree with this. Our experience is that this is pretty useful. /martin From nobody Sun Jun 1 12:06:10 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA2471A0294 for ; Sun, 1 Jun 2014 12:06:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ErTE9YIiRfwO for ; Sun, 1 Jun 2014 12:06:07 -0700 (PDT) Received: from mail-qa0-f45.google.com (mail-qa0-f45.google.com [209.85.216.45]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 649E51A02A8 for ; Sun, 1 Jun 2014 12:06:07 -0700 (PDT) Received: by mail-qa0-f45.google.com with SMTP id hw13so1517513qab.4 for ; Sun, 01 Jun 2014 12:06:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=7t8ysD/vPcJIzB9scT3tbbglQTXzKIi2yyLNWceMK1Q=; b=aZ/oWMI0a0Yi1iRrIIjlqu8tkrOmZLGBdq3fD9usvjm/8Lc9bCO26WKLlW3qBEv0le /HXzm9ReW2ccq4FmoQ8VwEmGdRp39ofJtRZFMeTsdLVw9QX7i45eAor9oMkZ6YrYL093 i8iDAD1bnuGTe95Qz8vjqYBx3FXybeUQVYr0CKMdDhsrublrcddmjVYdXM3gEMt4pxbr j31hRzatoDh2PLtn8NpdmjYNU+Z4Eh0rw3bvebVtlDmL5zOovEJTpEWfNLND02dfHl9m Id1S2H7IDeMU8YwDfUDTtJp+j0vDuE0PdhoadwT/2+twARJ3GSYFJSf/g9m1jFQIawfz E58g== X-Gm-Message-State: ALoCoQk+4waU8cEEqFxQcwwaUlwlI7qOwpykykE5GLlvMV023zKRhAZ2IEgSShdZUkV5FCNlJE+u MIME-Version: 1.0 X-Received: by 10.140.27.23 with SMTP id 23mr39721568qgw.94.1401649561797; Sun, 01 Jun 2014 12:06:01 -0700 (PDT) Received: by 10.140.104.49 with HTTP; Sun, 1 Jun 2014 12:06:01 -0700 (PDT) In-Reply-To: <20140601.202744.130295322.mbj@tail-f.com> References: <20140601152001.GE90395@elstar.local> <20140601.202744.130295322.mbj@tail-f.com> Date: Sun, 1 Jun 2014 12:06:01 -0700 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: multipart/alternative; boundary=001a11c14a7c3b328e04facaf8df Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/_yZgXIOEMY7ZkOb-6Sht7fF_rWQ Cc: "netmod@ietf.org" Subject: Re: [netmod] strawman REJECT Y31 allow require-instance in leafref X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jun 2014 19:06:09 -0000 --001a11c14a7c3b328e04facaf8df Content-Type: text/plain; charset=ISO-8859-1 On Sun, Jun 1, 2014 at 11:27 AM, Martin Bjorklund wrote: > Juergen Schoenwaelder wrote: > > This can already be done in other ways. > > How? > > We have a vendor-specific extension to deal with this. > > The current situation means leafrefs and instance-identifiers have > different behavior, for no apparent reason. > > > Speak up by June 10th if you disagree with this strawman proposal. > > I do not agree with this. Our experience is that this is pretty > useful. > > The require-instance sub-stmt was removed from leafref at some point type because the leaf type could just be copied instead. In hindsight, it is better not to cut-and-paste the type reference. If the original leaf has an inline type-stmt then there is no typedef-stmt to share, and cut-and-paste will get out of sync if the original leaf is updated. The require-instance false; statement would allow more loosely coupled dependencies, even if the referenced leaf does not use an exported typedef that can be shared. I agree this should be an open issue. > > /martin > Andy --001a11c14a7c3b328e04facaf8df Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Sun, Jun 1, 2014 at 11:27 AM, Martin Bjorklund <mbj@tail-f.com= > wrote:
Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:=
> This can already be done in other ways.

How?

We have a vendor-specific extension to deal with this.

The current situation means leafrefs and instance-identifiers have
different behavior, for no apparent reason.

> Speak up by June 10th if you disagree with this strawman proposal.

I do not agree with this. =A0Our experience is that this is pretty
useful.


The require-instance sub-stmt was removed from leafref at s= ome
point t= ype because the leaf type could just be copied instead.

In hindsight, it is be= tter not to cut-and-paste the type reference.
If the original leaf has an inline type-stmt then there is no typedef-stmt = to share,
and cut-and-paste will get out of sync if the original leaf is updated.<= /div>

The require-instance f= alse; statement would allow more loosely
coupled dependencies, even if the referenced leaf does not
use an exported typed= ef that can be shared.

I agree this should be an open issue.
=A0

/martin

Andy
=A0
<= /div>
--001a11c14a7c3b328e04facaf8df-- From nobody Mon Jun 2 01:14:47 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE9EF1A02C5 for ; Mon, 2 Jun 2014 01:14:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rtBU79gNiGSj for ; Mon, 2 Jun 2014 01:14:43 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17FBB1A02BA for ; Mon, 2 Jun 2014 01:14:43 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id EB3B6738 for ; Mon, 2 Jun 2014 10:14:36 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 3SCzdA-nt85x for ; Mon, 2 Jun 2014 10:14:35 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Mon, 2 Jun 2014 10:14:36 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8637720013 for ; Mon, 2 Jun 2014 10:14:36 +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 JparacDHfO29; Mon, 2 Jun 2014 10:14:36 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id DDB0820017; Mon, 2 Jun 2014 10:14:35 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 76D3B2D14EC0; Mon, 2 Jun 2014 10:14:34 +0200 (CEST) Date: Mon, 2 Jun 2014 10:14:33 +0200 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20140602081433.GA92342@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.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/hQfP9FBEygarpMTE4M9i5qqPjr0 Subject: [netmod] undecided Y09 introduce optional keys X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2014 08:14:45 -0000 We need to decide whether this is in scope of YANG 1.1 or not. The implications of this seem to be somewhat unclear. Does this only work if there are defaults or the leaf is initialized by system? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Mon Jun 2 01:15:58 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F2221A00FC for ; Mon, 2 Jun 2014 01:15:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fQw75IeORdya for ; Mon, 2 Jun 2014 01:15:55 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 140251A02BA for ; Mon, 2 Jun 2014 01:15:55 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id E690D738 for ; Mon, 2 Jun 2014 10:15:48 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id AqDWpkgpX1ob for ; Mon, 2 Jun 2014 10:15:47 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Mon, 2 Jun 2014 10:15:48 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6D64B2002F for ; Mon, 2 Jun 2014 10:15:48 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 7eP-par7OoRK; Mon, 2 Jun 2014 10:15:48 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id AD94020017; Mon, 2 Jun 2014 10:15:47 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id A4DA52D14EF2; Mon, 2 Jun 2014 10:15:47 +0200 (CEST) Date: Mon, 2 Jun 2014 10:15:47 +0200 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20140602081547.GB92342@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.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/BfKRP1jRunJ45pdmrjPKYnIfddE Subject: [netmod] undecided Y19 we need a better unique X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2014 08:15:56 -0000 We need to decide whether this is in scope of YANG 1.1 or not. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Mon Jun 2 01:17:26 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E18B51A02BA for ; Mon, 2 Jun 2014 01:17:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I5AksPrv0jHr for ; Mon, 2 Jun 2014 01:17:22 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A91281A01AE for ; Mon, 2 Jun 2014 01:17:22 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 88EBF738 for ; Mon, 2 Jun 2014 10:17:16 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id rVTU_ChbTb2s for ; Mon, 2 Jun 2014 10:17:14 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Mon, 2 Jun 2014 10:17:16 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2163F20031 for ; Mon, 2 Jun 2014 10:17:16 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id U83L5jkKMl4Z; Mon, 2 Jun 2014 10:17:15 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D466520013; Mon, 2 Jun 2014 10:17:14 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id CA74F2D14F1B; Mon, 2 Jun 2014 10:17:14 +0200 (CEST) Date: Mon, 2 Jun 2014 10:17:14 +0200 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20140602081714.GC92342@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.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/SGQyf56ZLD5xkNb4I86nMzTNvdQ Subject: [netmod] undecided Y21 statement to define new XPath functions in a module X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2014 08:17:24 -0000 We need to decide whether this is in scope of YANG 1.1 or not. Is there a risk that this may get abused, leading to non-interoperable vendor specific sets of functions in XPATH expressions? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Mon Jun 2 01:19:25 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95FD51A02C7 for ; Mon, 2 Jun 2014 01:19:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RKxPYlOkdQUM for ; Mon, 2 Jun 2014 01:19:23 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 625F31A02D3 for ; Mon, 2 Jun 2014 01:19:23 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 43BDAA92 for ; Mon, 2 Jun 2014 10:19:17 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id JYthgxgQD-5S for ; Mon, 2 Jun 2014 10:19:15 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Mon, 2 Jun 2014 10:19:16 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id D027720013 for ; Mon, 2 Jun 2014 10:19:16 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id o4ZDsjQATzW6; Mon, 2 Jun 2014 10:19:16 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1234020017; Mon, 2 Jun 2014 10:19:16 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 05E302D14F48; Mon, 2 Jun 2014 10:19:15 +0200 (CEST) Date: Mon, 2 Jun 2014 10:19:15 +0200 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20140602081915.GD92342@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.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/EP6t6-EIPeuqvJwIa-GVAAAZVos Subject: [netmod] undecided Y22 support constraints on unions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2014 08:19:24 -0000 We need to decide whether this is in scope of YANG 1.1 or not. It remains somewhat unclear what exactly the problem is that this is supposed to solve. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Mon Jun 2 01:21:06 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 086601A01AE for ; Mon, 2 Jun 2014 01:21:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3-hkIXwNVwdP for ; Mon, 2 Jun 2014 01:21:01 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A44E41A00FC for ; Mon, 2 Jun 2014 01:21:01 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 853487DE for ; Mon, 2 Jun 2014 10:20:55 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id qb9pjXhBbIiA for ; Mon, 2 Jun 2014 10:20:53 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Mon, 2 Jun 2014 10:20:55 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1D1A220017 for ; Mon, 2 Jun 2014 10:20:55 +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 iw-Ge3sEE6uB; Mon, 2 Jun 2014 10:20:54 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 740E720013; Mon, 2 Jun 2014 10:20:54 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 6B2F52D14F70; Mon, 2 Jun 2014 10:20:54 +0200 (CEST) Date: Mon, 2 Jun 2014 10:20:54 +0200 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20140602082054.GE92342@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.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/0n77XH_ejNY4B_eH5n_xgB5RZXY Subject: [netmod] undecided Y26 allow mandatory nodes in augment X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2014 08:21:03 -0000 We need to decide whether this is in scope of YANG 1.1 or not. What are the implications of allowing mandatory in augments? Can this be misused and do we need to constraint this? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Mon Jun 2 01:22:42 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 583651A00FC for ; Mon, 2 Jun 2014 01:22:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q6PDE4ur9W_s for ; Mon, 2 Jun 2014 01:22:39 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7952F1A02CA for ; Mon, 2 Jun 2014 01:22:38 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 5CF5BAC2 for ; Mon, 2 Jun 2014 10:22:32 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id KWV4QddqNRXr for ; Mon, 2 Jun 2014 10:22:30 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Mon, 2 Jun 2014 10:22:31 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id CF5E72002F for ; Mon, 2 Jun 2014 10:22:31 +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 mwyQfLrwWwbg; Mon, 2 Jun 2014 10:22:31 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2990E20013; Mon, 2 Jun 2014 10:22:31 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 202EC2D14F9A; Mon, 2 Jun 2014 10:22:31 +0200 (CEST) Date: Mon, 2 Jun 2014 10:22:31 +0200 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20140602082231.GF92342@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.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/gmHACa4cAsieDX1mYczPYc2wXBE Subject: [netmod] undecided Y27 allow mandatory nodes in an updated module X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2014 08:22:40 -0000 We need to decide whether this is in scope of YANG 1.1 or not. What are the implications of allowing the addition of mandatory nodes? Does this need to be restricted to cases where it is not harmful (e.g. if the nodes are part of a new feature)? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Mon Jun 2 01:24:33 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B04731A02D7 for ; Mon, 2 Jun 2014 01:24:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ya6a230jofgW for ; Mon, 2 Jun 2014 01:24:30 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4047E1A00FC for ; Mon, 2 Jun 2014 01:24:29 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id C5B306D5 for ; Mon, 2 Jun 2014 10:24:22 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id TfXAZ8hrSz1h for ; Mon, 2 Jun 2014 10:24:21 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Mon, 2 Jun 2014 10:24:22 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 66F3820017 for ; Mon, 2 Jun 2014 10:24:22 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id BrVKAXL-sbSO; Mon, 2 Jun 2014 10:24:22 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7882A20013; Mon, 2 Jun 2014 10:24:21 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 6ECF22D14FC4; Mon, 2 Jun 2014 10:24:21 +0200 (CEST) Date: Mon, 2 Jun 2014 10:24:21 +0200 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20140602082421.GG92342@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.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/9y4d8P3C6Ep9zDCJZ4RaaH3x3zk Subject: [netmod] undecided Y33 add 'attribute' statement X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2014 08:24:31 -0000 We need to decide whether this is in scope of YANG 1.1 or not. Is there a risk of attributes getting abused? How do we define metadata? We do not seem to want people to use attributes to model data. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Mon Jun 2 01:26:44 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 876591A02D3 for ; Mon, 2 Jun 2014 01:26:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PvFggPewiApu for ; Mon, 2 Jun 2014 01:26:42 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E23B1A02CA for ; Mon, 2 Jun 2014 01:26:42 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 3F2596D9 for ; Mon, 2 Jun 2014 10:26:36 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id e_f9haAJySt2 for ; Mon, 2 Jun 2014 10:26:34 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Mon, 2 Jun 2014 10:26:35 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id AA4662002C for ; Mon, 2 Jun 2014 10:26:35 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 0LjOhiUFddRd; Mon, 2 Jun 2014 10:26:35 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id E754B20013; Mon, 2 Jun 2014 10:26:34 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id DE0272D14FF4; Mon, 2 Jun 2014 10:26:34 +0200 (CEST) Date: Mon, 2 Jun 2014 10:26:34 +0200 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20140602082634.GH92342@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.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/Ojorw9OKeKCYBh-qMpHzpysASYU Subject: [netmod] undecided Y36 associate a notification with a data node X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2014 08:26:43 -0000 We need to decide whether this is in scope of YANG 1.1 or not. There are several questions associated with this and perhaps this requires some solution think through in order to understand the implications in more details. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Mon Jun 2 01:27:49 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AAFC1A02D9 for ; Mon, 2 Jun 2014 01:27:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r480-5E12gGR for ; Mon, 2 Jun 2014 01:27:46 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 867291A02D3 for ; Mon, 2 Jun 2014 01:27:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 9F1A15406C1; Mon, 2 Jun 2014 10:27:39 +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 MAbnqycSxVWI; Mon, 2 Jun 2014 10:27:34 +0200 (CEST) Received: from localhost (unknown [172.29.2.201]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 90CCF54027E; Mon, 2 Jun 2014 10:27:34 +0200 (CEST) From: Ladislav Lhotka To: Juergen Schoenwaelder , netmod@ietf.org In-Reply-To: <20140601151957.GD90395@elstar.local> References: <20140601151957.GD90395@elstar.local> User-Agent: Notmuch/0.17 (http://notmuchmail.org) Emacs/24.3.50.2 (x86_64-apple-darwin13.0.0) Date: Mon, 02 Jun 2014 10:27:33 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/fHfkstZs-U8VkxXTN8L1y3R63m4 Subject: Re: [netmod] strawman REJECT Y24 YIN -> YANG translation breaks text formatting X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2014 08:27:48 -0000 Juergen Schoenwaelder writes: > This seems to add quite some complexity and it is unclear how widely > YIN is used to write YANG (most people seem to write YANG directly). I agree. If I am really the only person in the known universe that uses YIN, it might even make sense what Andy proposed - namely to move YIN out of the YANG spec. On the other hand, it seems descriptions are quite often subject to machine processing, so it would be useful to have a recommended markup format for the YANG syntax, e.g. reStructuredText or markdown. Lada > > Speak up by June 10th if you disagree with this strawman proposal. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Mon Jun 2 01:28:42 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED26D1A02D3 for ; Mon, 2 Jun 2014 01:28:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mtYavwxqhP1X for ; Mon, 2 Jun 2014 01:28:38 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99BAB1A02CA for ; Mon, 2 Jun 2014 01:28:38 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 79F18F5A for ; Mon, 2 Jun 2014 10:28:32 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id ebsTGQCZWhbZ for ; Mon, 2 Jun 2014 10:28:30 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Mon, 2 Jun 2014 10:28:32 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 147502002C for ; Mon, 2 Jun 2014 10:28:32 +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 uIILkxMndw0D; Mon, 2 Jun 2014 10:28:31 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0707920013; Mon, 2 Jun 2014 10:28:31 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id ED1292D1501F; Mon, 2 Jun 2014 10:28:30 +0200 (CEST) Date: Mon, 2 Jun 2014 10:28:30 +0200 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20140602082830.GI92342@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.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/T0HN-em3Ydf8ga07Nytsk245u8o Subject: [netmod] undecided Y37 allow notifications to be derived from other notifications X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2014 08:28:40 -0000 We need to decide whether this is in scope of YANG 1.1 or not. It remains unclear whether this feature is needed for real-world data models or whether existing groupings get us there alreadly to a large extend. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Mon Jun 2 01:30:08 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1240A1A02E0 for ; Mon, 2 Jun 2014 01:30:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wjCbIDoDwFkk for ; Mon, 2 Jun 2014 01:30:03 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B01FB1A02DD for ; Mon, 2 Jun 2014 01:30:03 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 8F422F5E for ; Mon, 2 Jun 2014 10:29:57 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 4dMw0gdrU1nb for ; Mon, 2 Jun 2014 10:29:55 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Mon, 2 Jun 2014 10:29:57 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2EC3320017 for ; Mon, 2 Jun 2014 10:29:57 +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 0ji_flbUKQkj; Mon, 2 Jun 2014 10:29:56 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2929C20013; Mon, 2 Jun 2014 10:29:56 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 1E6112D1504A; Mon, 2 Jun 2014 10:29:56 +0200 (CEST) Date: Mon, 2 Jun 2014 10:29:56 +0200 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20140602082956.GJ92342@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.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/waXCpqoMnBanY9LGeyB7D6E8DlU Subject: [netmod] undecided Y39 define the terms system/user-controlled instances X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2014 08:30:05 -0000 We need to decide whether this is in scope of YANG 1.1 or not. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Mon Jun 2 01:31:48 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A21B01A0105 for ; Mon, 2 Jun 2014 01:31:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C5y5mN5JJ-iF for ; Mon, 2 Jun 2014 01:31:44 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B56461A00F7 for ; Mon, 2 Jun 2014 01:31:44 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 94EBEE9C for ; Mon, 2 Jun 2014 10:31:38 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id Y-rnmZvhyru7 for ; Mon, 2 Jun 2014 10:31:36 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Mon, 2 Jun 2014 10:31:38 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3796820017 for ; Mon, 2 Jun 2014 10:31:38 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id hPCFloa_XukQ; Mon, 2 Jun 2014 10:31:37 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2A24920013; Mon, 2 Jun 2014 10:31:37 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 20A8D2D15073; Mon, 2 Jun 2014 10:31:37 +0200 (CEST) Date: Mon, 2 Jun 2014 10:31:37 +0200 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20140602083137.GK92342@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.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/sdWN2xuRItqQh7NO5RrHAxsO4Hw Subject: [netmod] undecided Y50 additional extension grammar validation X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2014 08:31:46 -0000 We need to decide whether this is in scope of YANG 1.1 or not. Is the added value worth the complexity this introduces? A YANG parser would have to evaluate the grammar of extension statements at runtime. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Mon Jun 2 01:33:41 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D94381A0105 for ; Mon, 2 Jun 2014 01:33:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G1ieBdkHLBjq for ; Mon, 2 Jun 2014 01:33:37 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8ED4A1A00F7 for ; Mon, 2 Jun 2014 01:33:37 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 6F08A6D9 for ; Mon, 2 Jun 2014 10:33:31 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id bnoQsh4PCcsI for ; Mon, 2 Jun 2014 10:33:29 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Mon, 2 Jun 2014 10:33:31 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 20E8320017 for ; Mon, 2 Jun 2014 10:33:31 +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 nNm95mKhKMtF; Mon, 2 Jun 2014 10:33:30 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2C89020013; Mon, 2 Jun 2014 10:33:30 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 228C72D1509D; Mon, 2 Jun 2014 10:33:30 +0200 (CEST) Date: Mon, 2 Jun 2014 10:33:30 +0200 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20140602083330.GL92342@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.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/0F-oWR-JrVEn0jzVKFhXSS9WLrM Subject: [netmod] undecided Y54 remove the advertisement of conformance information in NETCONF hello message X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2014 08:33:39 -0000 We need to decide whether this is in scope of YANG 1.1 or not. This may be subsumed by Y45 (OPEN) and Y16 (OPEN). /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Mon Jun 2 01:35:02 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 016521A0105 for ; Mon, 2 Jun 2014 01:34:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CnjAF41nmpOm for ; Mon, 2 Jun 2014 01:34:54 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A35E1A00F7 for ; Mon, 2 Jun 2014 01:34:54 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 598FF71E; Mon, 2 Jun 2014 10:34:48 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 9NaCEJnTbV4e; Mon, 2 Jun 2014 10:34:46 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 2 Jun 2014 10:34:47 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id B64252002C; Mon, 2 Jun 2014 10:34:47 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id junMGr9A_qmV; Mon, 2 Jun 2014 10:34:47 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id E5E7520013; Mon, 2 Jun 2014 10:34:46 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id D7E012D150D1; Mon, 2 Jun 2014 10:34:46 +0200 (CEST) Date: Mon, 2 Jun 2014 10:34:46 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20140602083446.GM92342@elstar.local> Mail-Followup-To: Ladislav Lhotka , netmod@ietf.org References: <20140601151957.GD90395@elstar.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/qBpiK_Ca-5HbP8Jsr2t-sMXLU0E Cc: netmod@ietf.org Subject: Re: [netmod] strawman REJECT Y24 YIN -> YANG translation breaks text formatting X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2014 08:34:56 -0000 On Mon, Jun 02, 2014 at 10:27:33AM +0200, Ladislav Lhotka wrote: > Juergen Schoenwaelder writes: > > > This seems to add quite some complexity and it is unclear how widely > > YIN is used to write YANG (most people seem to write YANG directly). > > I agree. If I am really the only person in the known universe that uses YIN, it might even make sense what Andy proposed - namely to move YIN out of the YANG spec. > > On the other hand, it seems descriptions are quite often subject to machine processing, so it would be useful to have a recommended markup format for the YANG syntax, e.g. reStructuredText or markdown. > The deadline for new feature submissions has passed. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Mon Jun 2 01:45:39 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30AF11A0192 for ; Mon, 2 Jun 2014 01:45:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.002 X-Spam-Level: X-Spam-Status: No, score=-1.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.651] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fVnordi0z9Sl for ; Mon, 2 Jun 2014 01:45:38 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9E031A0105 for ; Mon, 2 Jun 2014 01:45:37 -0700 (PDT) Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 0F1BF13F66A; Mon, 2 Jun 2014 10:45:29 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1401698730; bh=vasUOo1JuNgQfz/iTSUClFvXZO38HFHzbWIoaDGisko=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=kp4bpLWm61S8Yocz7GpofDOlUwFyeQai3Qxb/jNDVmBGCCXNDoe+09rNyMpala3+1 1n3hMY9RfiPyTJbMTWrWF+haZjiz8yFnO/UF3C1iYEJdOmmLkmMjUg/g41Q2nU964k sYZ3STwE/Fh2JeEsavFrJdDpcGgwTus8ZuA54DZo= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Ladislav Lhotka In-Reply-To: <20140602083446.GM92342@elstar.local> Date: Mon, 2 Jun 2014 10:45:29 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140601151957.GD90395@elstar.local> <20140602083446.GM92342@elstar.local> To: =?iso-8859-1?Q?J=FCrgen_Sch=F6nw=E4lder?= X-Mailer: Apple Mail (2.1878.2) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/85ovXjNiU5SKNjOgW191ZI22gCs Cc: netmod@ietf.org Subject: Re: [netmod] strawman REJECT Y24 YIN -> YANG translation breaks text formatting X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2014 08:45:39 -0000 On 02 Jun 2014, at 10:34, Juergen Schoenwaelder = wrote: > On Mon, Jun 02, 2014 at 10:27:33AM +0200, Ladislav Lhotka wrote: >> Juergen Schoenwaelder writes: >>=20 >>> This seems to add quite some complexity and it is unclear how widely >>> YIN is used to write YANG (most people seem to write YANG directly). >>=20 >> I agree. If I am really the only person in the known universe that = uses YIN, it might even make sense what Andy proposed - namely to move = YIN out of the YANG spec. >>=20 >> On the other hand, it seems descriptions are quite often subject to = machine processing, so it would be useful to have a recommended markup = format for the YANG syntax, e.g. reStructuredText or markdown. >>=20 >=20 > The deadline for new feature submissions has passed. I know that. The first item only means restructuring that would make the main YANG = spec cleaner and shorter. For instance, RELAX NG took the same approach: = its compact syntax is defined in a separate document. The second item is no new feature at all. Module writers can of course = use some markup already now. However, having a RECOMMENDED markup format = (with an informative reference) would mean more consistence and that = would IMO be quite useful. Lada >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Mon Jun 2 08:17:29 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86BAE1A030F for ; Mon, 2 Jun 2014 08:17:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J8vQ0XFKiwWk for ; Mon, 2 Jun 2014 08:17:26 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2444D1A0344 for ; Mon, 2 Jun 2014 08:17:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: netmod@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.4.2.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140602151726.29751.22326.idtracker@ietfa.amsl.com> Date: Mon, 02 Jun 2014 08:17:26 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/ajY-0Ge8A06nim7fVZBQoQepG6g Subject: [netmod] Milestones changed for netmod WG X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2014 15:17:27 -0000 Changed milestone "Submit first working group draft of a mapping to JSON", resolved as "Done", added draft-ietf-netmod-yang-json to milestone. Changed milestone "Compiled issue list to be considered for YANG 1.1", resolved as "Done". URL: http://datatracker.ietf.org/wg/netmod/charter/ From nobody Mon Jun 2 08:31:59 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75CE11A0247 for ; Mon, 2 Jun 2014 08:31:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7O_Hszk-49Zz for ; Mon, 2 Jun 2014 08:31:53 -0700 (PDT) Received: from mail-qg0-f48.google.com (mail-qg0-f48.google.com [209.85.192.48]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93AB81A022A for ; Mon, 2 Jun 2014 08:31:53 -0700 (PDT) Received: by mail-qg0-f48.google.com with SMTP id i50so10840080qgf.21 for ; Mon, 02 Jun 2014 08:31:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=PGConQ5P3B1F8JUj95R1HJ5Ee8xIno9bn5wtWCnkGa4=; b=bL/mkbfvPmPPknRsoAtQRR6RxP8/SwqmPc3YZaqgQTu1BdFdnvP/u4NhtM2yiqzJ9F QXUMXGB/mSlcUrZ6022SBaDgQkyX4moF1dN5l+Bg3E9jwplb7LZL+kSFYcPQv2d8o+do pshfCFKwNAy00Hsd2sEBu2yDFB2Fhs9rA/2rhx9tnK/wopYHziMhMGBziCqaYbytWF5H ejxbF4tVqSfCbPflAmdOVOPCktODLm4/M6edH/dvKQkJHrbL566Q92H01CqoA3qsQD2G xj7E3Nf9l74VafZN/3S6ZAKJu9CSLXUuDppIkC7eLZMojDwDjqUQ3lmWUzSY+nhhd//z aphA== X-Gm-Message-State: ALoCoQlvEArpeHfJOva4n0I4S4ierPTjhxpeUIcQrTUBp2vLkkietHlDYJ2FxQsgNbd65a8h08dt MIME-Version: 1.0 X-Received: by 10.224.64.132 with SMTP id e4mr50464000qai.16.1401723107742; Mon, 02 Jun 2014 08:31:47 -0700 (PDT) Received: by 10.140.104.49 with HTTP; Mon, 2 Jun 2014 08:31:47 -0700 (PDT) In-Reply-To: <20140602081433.GA92342@elstar.local> References: <20140602081433.GA92342@elstar.local> Date: Mon, 2 Jun 2014 08:31:47 -0700 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , "netmod@ietf.org" Content-Type: multipart/alternative; boundary=001a11c20e7ae9619704fadc17bf Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/V1u7ETwo8sqJGfMfeqpTzFr919k Subject: Re: [netmod] undecided Y09 introduce optional keys X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2014 15:31:57 -0000 --001a11c20e7ae9619704fadc17bf Content-Type: text/plain; charset=ISO-8859-1 On Mon, Jun 2, 2014 at 1:14 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > We need to decide whether this is in scope of YANG 1.1 or not. > > The implications of this seem to be somewhat unclear. Does this only > work if there are defaults or the leaf is initialized by system? > > This issue states that the problem to be solved is removal of a redundant leaf in a list entry. If the key leaf has a YANG default then it can be used instead (just like a non-key leaf). The creation of 1 list entry (per optional key) is optimized by solving this problem. IMO that is not enough benefit to make this change. This change would also break YANG 1.0 because a YANG 1.0 client sending an with a missing key expects to get an error, not . Issue Y09 should be rejected. /js > Andy > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --001a11c20e7ae9619704fadc17bf Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Mon, Jun 2, 2014 at 1:14 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
We need to decide whether this is in scope o= f YANG 1.1 or not.

The implications of this seem to be somewhat unclear. Does this only
work if there are defaults or the leaf is initialized by system?



This issue states that the problem to= be solved is removal of a
redundant leaf in a list entry. =A0If = the key leaf has a YANG default
then it can be used instead (just like a non-key leaf).

=
The creation of 1 list entry (per optional key) is optimized by = solving
this problem. =A0IMO that is not enough benefit to make t= his change.
This change would also break YANG 1.0 because a YANG 1.0 client
<= div>sending an <edit-config> with a missing key expects to get an err= or, not <ok>.

Issue Y09 should be rejected.<= /div>


/js

Andy
=A0

--
Juergen Schoenwaelder =A0 =A0 =A0 =A0 =A0 Jacobs University Bremen gGmbH Phone: +49 421 200 3587 =A0 =A0 =A0 =A0 Campus Ring 1, 28759 Bremen, German= y
Fax: =A0 +49 421 200 3103 =A0 =A0 =A0 =A0 <http://www.jacobs-university.de/><= br>
_______________________________________________
netmod mailing list
netmod@ietf.org
= https://www.ietf.org/mailman/listinfo/netmod

--001a11c20e7ae9619704fadc17bf-- From nobody Mon Jun 2 08:38:23 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 178491A0366 for ; Mon, 2 Jun 2014 08:38:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YMZgNxaGOy9S for ; Mon, 2 Jun 2014 08:38:20 -0700 (PDT) Received: from mail-qa0-f43.google.com (mail-qa0-f43.google.com [209.85.216.43]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 289341A035E for ; Mon, 2 Jun 2014 08:38:20 -0700 (PDT) Received: by mail-qa0-f43.google.com with SMTP id m5so2973104qaj.2 for ; Mon, 02 Jun 2014 08:38:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=4ywyAnf+EClpK7v7HrGn5J2nEe9l6Yyq0eMDQg/mRFQ=; b=OmRhdp/CAyuprGxs4Bhf4+uz9PN68qCycFmbmLyBiIstnCVsxgBsi3COoXRjoi2v+4 HiUnD/ZmYk2We0Yvna8tMv2TFFi07+wl7itWr4qluX2Gc60SmN1H8hKquv+B2lZ1Pdgp IQ8oiPlgnoOdO4ZntHNo+HB4QVDrCb/1PdW1i9Oj3gLHUqmDi6H62SfIi2KXeiczHXg4 AkiGf3rv5vf8r/PClfvjDIJ4lttjUE7fUSZdxsiDurvncYyUdg1AtHfgCf9/3AKaPHhe 7GFh3y7OaUYSYJ2KDRIhaNweNa5Qkadh2YzLa7G6wXpiakrIRt9DxUFpJNf0c4ZkHu6C RcGA== X-Gm-Message-State: ALoCoQnKKgTGAvi7asVlIkTPZ5dWMcIorAi7DFl6Pq8yYU2Un6ieX/z1KN1n9v7ws9dbhA3t5fIO MIME-Version: 1.0 X-Received: by 10.140.36.105 with SMTP id o96mr47049549qgo.25.1401723494256; Mon, 02 Jun 2014 08:38:14 -0700 (PDT) Received: by 10.140.104.49 with HTTP; Mon, 2 Jun 2014 08:38:14 -0700 (PDT) In-Reply-To: <20140602081547.GB92342@elstar.local> References: <20140602081547.GB92342@elstar.local> Date: Mon, 2 Jun 2014 08:38:14 -0700 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , "netmod@ietf.org" Content-Type: multipart/alternative; boundary=001a11c17334f3053d04fadc2e63 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/VdN6ScoJd23lSzUHZrtLw_NyBws Subject: Re: [netmod] undecided Y19 we need a better unique X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2014 15:38:22 -0000 --001a11c17334f3053d04fadc2e63 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Jun 2, 2014 at 1:15 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > We need to decide whether this is in scope of YANG 1.1 or not. > > IMO this new feature should be rejected because there is already a work-around with must-stmt (as shown in the solution). In order to maintain YANG 1.0 compatibility, there would be 2 forms of the unique-stmt to support in YANG. > /js > Andy > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --001a11c17334f3053d04fadc2e63 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Mon, Jun 2, 2014 at 1:15 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
We need to decide whether this is in scope o= f YANG 1.1 or not.


IMO this new feature should be rejected because ther= e is already
a work-around with must-stmt (as shown in the soluti= on).
In order to maintain YANG 1.0 compatibility, there would be
= 2 forms of the unique-stmt to support in YANG.
=A0
/js

Andy
=A0

--
Juergen Schoenwaelder =A0 =A0 =A0 =A0 =A0 Jacobs University Bremen gGmbH Phone: +49 421 200 3587 =A0 =A0 =A0 =A0 Campus Ring 1, 28759 Bremen, German= y
Fax: =A0 +49 421 200 3103 =A0 =A0 =A0 =A0 <http://www.jacobs-university.de/><= br>
_______________________________________________
netmod mailing list
netmod@ietf.org
= https://www.ietf.org/mailman/listinfo/netmod

--001a11c17334f3053d04fadc2e63-- From nobody Mon Jun 2 08:46:29 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2FC81A0241 for ; Mon, 2 Jun 2014 08:46:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q4x63pHXRwIj for ; Mon, 2 Jun 2014 08:46:22 -0700 (PDT) Received: from mail-qa0-f48.google.com (mail-qa0-f48.google.com [209.85.216.48]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68AC61A0340 for ; Mon, 2 Jun 2014 08:46:16 -0700 (PDT) Received: by mail-qa0-f48.google.com with SMTP id i13so3007956qae.35 for ; Mon, 02 Jun 2014 08:46:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=jRI6bZQfyv57ZKQBTLzEAezFhJrjm1OAlsPjPg1aWIg=; b=KVxwnggpzRnkNLJWGmoN7T1SbFcMHv30feOXeO/u6NB5m76z4t+Nl0etVUj3YRWKLI EibkoluzcCunhp1V7W0kZu1cDvusIbrz2jN17gFgUa+Uepkkhih5isE1Atgr5rkZqeUR eNmEMp3Sygoa+KQOofwoV3eDCljJNii1M/P2os8eeeuzpl4XTB+r6PNJTobNG+iDPerw vTkEnnKM/HCNdaF9M5QX7FL4p0sbjc9p1EHMgbkQpV5WzFkgQe51OL+OT5jYNBvUInVO XQzcfGsNeYYTJ6AyHwLj9ZbNPHA52TucDztLYu4FHbSPYT6fohb/GS8lrKMc5Wz5GjV8 iBHg== X-Gm-Message-State: ALoCoQnOP0c+CSphfrnWIVNtGnqhqlNnr2BdVEAtUQo1j21pWbH2XLmNgGsbb0Z8FCIwYkEZnkBz MIME-Version: 1.0 X-Received: by 10.140.104.204 with SMTP id a70mr45977886qgf.91.1401723970458; Mon, 02 Jun 2014 08:46:10 -0700 (PDT) Received: by 10.140.104.49 with HTTP; Mon, 2 Jun 2014 08:46:10 -0700 (PDT) In-Reply-To: <20140602081714.GC92342@elstar.local> References: <20140602081714.GC92342@elstar.local> Date: Mon, 2 Jun 2014 08:46:10 -0700 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , "netmod@ietf.org" Content-Type: multipart/alternative; boundary=001a1134f42a55469204fadc4b9b Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/YliTAfBUx_WjD_VFVwE5jiL8E54 Subject: Re: [netmod] undecided Y21 statement to define new XPath functions in a module X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2014 15:46:26 -0000 --001a1134f42a55469204fadc4b9b Content-Type: text/plain; charset=ISO-8859-1 On Mon, Jun 2, 2014 at 1:17 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > We need to decide whether this is in scope of YANG 1.1 or not. > > Is there a risk that this may get abused, leading to non-interoperable > vendor specific sets of functions in XPATH expressions? > > Although I like this technical solution, I think it permits too much variability in the standard, so it should be rejected. The YANG 1.1 XPath library should be hard-wired (just like 1.0). > /js > Andy > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --001a1134f42a55469204fadc4b9b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Mon, Jun 2, 2014 at 1:17 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
We need to decide whether this is in scope o= f YANG 1.1 or not.

Is there a risk that this may get abused, leading to non-interoperable
vendor specific sets of functions in XPATH expressions?



Although I like this technical soluti= on, I think it permits too much
variability in the standard, so i= t should be rejected.
The YANG 1.1 XPath library should be hard-wired (just like 1.0).
=
=A0
/js

Andy
=A0

--
Juergen Schoenwaelder =A0 =A0 =A0 =A0 =A0 Jacobs University Bremen gGmbH Phone: +49 421 200 3587 =A0 =A0 =A0 =A0 Campus Ring 1, 28759 Bremen, German= y
Fax: =A0 +49 421 200 3103 =A0 =A0 =A0 =A0 <http://www.jacobs-university.de/><= br>
_______________________________________________
netmod mailing list
netmod@ietf.org
= https://www.ietf.org/mailman/listinfo/netmod

--001a1134f42a55469204fadc4b9b-- From nobody Mon Jun 2 09:01:28 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EFFB1A0256 for ; Mon, 2 Jun 2014 09:01:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zuLXhHbc-vIX for ; Mon, 2 Jun 2014 09:01:24 -0700 (PDT) Received: from mail-qa0-f48.google.com (mail-qa0-f48.google.com [209.85.216.48]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4BF61A0350 for ; Mon, 2 Jun 2014 09:01:24 -0700 (PDT) Received: by mail-qa0-f48.google.com with SMTP id i13so3040337qae.35 for ; Mon, 02 Jun 2014 09:01:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=ruE5mKA4uON0cqn9Z9+9IwbzJrwfzG2D64nMkPryTiE=; b=Sy6mHBZs7ZhfxlB1Y2mKUTv3VwJ/K9HEbbhSW/Fjv4NzWdRgWllCBTajKHLqSC3lZA UiYv8Fe+RKHzdy9UHkyNjpdAa6JjQe57nz+7ysdfHN0e1bFvgVW9glp0Mu/P7ofG8w7Z CRbxgT+E6A6844ye6FVVdKx4F+RDp2DVgT40dAxgptIiXTrHQ0IOESZ25r0HYGbzWGj9 TdwPWx4y/LFVbsb36ft6xhBlYw7nbNbibbZKgj6YP8d6RBNd5XxjqdmwhDml0wIlNGzH w2IO8lIXi/4MmMRPtR7MokreELUGXY1Jr/3K0VMOnfmaoPOzxDgjOsGwrNycMr55SQDt bk2Q== X-Gm-Message-State: ALoCoQl/qjKhfkKodwLKJXgWlCVgytPbmmFp35V73gTAT6K8losnhRL9NmbmvvebMTJu25e0LQRe MIME-Version: 1.0 X-Received: by 10.140.41.75 with SMTP id y69mr46812609qgy.34.1401724878741; Mon, 02 Jun 2014 09:01:18 -0700 (PDT) Received: by 10.140.104.49 with HTTP; Mon, 2 Jun 2014 09:01:18 -0700 (PDT) In-Reply-To: <20140602081915.GD92342@elstar.local> References: <20140602081915.GD92342@elstar.local> Date: Mon, 2 Jun 2014 09:01:18 -0700 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , "netmod@ietf.org" Content-Type: multipart/alternative; boundary=001a11c126ba78ba1e04fadc8133 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/3OjzE9iGfOL9OwBjPBElGpM7lY4 Subject: Re: [netmod] undecided Y22 support constraints on unions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2014 16:01:26 -0000 --001a11c126ba78ba1e04fadc8133 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Jun 2, 2014 at 1:19 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > We need to decide whether this is in scope of YANG 1.1 or not. > > It remains somewhat unclear what exactly the problem is that this > is supposed to solve. > > It seems to suggest that individual type-stmts within a union type-stmt should be conditional, based on an XPath expression. It may be useful to support constraints for union type. For example, a server can be defined as union of domain-name/ip-addresss. However, domain-name should only be allowed when a dns-server exists. #+BEGIN_EXAMPLE leaf foo { type union { type uint32; type union { type enumeration { enum bar; } type string; } } } #+END_EXAMPLE If foo has value "hi mom", base-type(foo) returns "string". Unfortunately, this won't work for the example use case, since both domain-name and ip-address are strings. The example is about 'foo' so I don't understand the reference to the other leafs. I understand that the tool implementation needs to know the type-stmt that actually matched in a union, but that is just an internal implementation detail. Not sure what "base-type(foo) returns string" means or why this would need to be exposed in the language. The type-stmts within a union need to be static, not changing based on some boolean expression. This issue should be rejected. /js > > Andy > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --001a11c126ba78ba1e04fadc8133 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Mon, Jun 2, 2014 at 1:19 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
We need to decide whether this is in scope of YANG 1.1 or = not.

It remains somewhat unclear what exactly the problem is that this
is supposed to solve.


It seems to suggest that individual type-stmts within a un= ion type-stmt
should be conditional, based on an XPath expression= .

  It may be useful to support constraints for union type=
.  For
  example, a server can be defined as union of
  domain-name/ip-addresss.  However, domain-name should only be
  allowed when a dns-server exists.
   #+BEGIN_EXAMPLE
    leaf foo {
      type union {
        type uint32;
        type union {
          type enumeration {
            enum bar;
          }
          type string;
        }
      }
    }
    #+END_EXAMPLE

   If foo has value "hi mom", base-type(foo) returns "string=
".

   Unfortunately, this won't work for the example use case, since both
   domain-name and ip-address are strings.
The example is about 'f= oo' so I don't understand the reference to the other leafs.
I un= derstand that the tool implementation needs to know the type-stmt that
actually matched in a union, but that is just an internal
im= plementation detail. =A0Not sure what "base-type(foo) returns string&q= uot; means
or why this would need to be exposed in the language.<= /div>

The type-stmts within a union need to be static, not changing base= d
on some boolean expression. This issue should be rejected.


/js


Andy
=A0
=
--
Juergen Schoenwaelder =A0 =A0 =A0 =A0 =A0 Jacobs University Bremen gGmbH Phone: +49 421 200 3587 =A0 =A0 =A0 =A0 Campus Ring 1, 28759 Bremen, German= y
Fax: =A0 +49 421 200 3103 =A0 =A0 =A0 =A0 <http://www.jacobs-university.de/><= br>
_______________________________________________
netmod mailing list
netmod@ietf.org
= https://www.ietf.org/mailman/listinfo/netmod

--001a11c126ba78ba1e04fadc8133-- From nobody Mon Jun 2 09:09:10 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6677D1A0254 for ; Mon, 2 Jun 2014 09:09:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j-nAMA8Z2s53 for ; Mon, 2 Jun 2014 09:09:07 -0700 (PDT) Received: from mail-qg0-f44.google.com (mail-qg0-f44.google.com [209.85.192.44]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 395241A024F for ; Mon, 2 Jun 2014 09:09:07 -0700 (PDT) Received: by mail-qg0-f44.google.com with SMTP id i50so11069502qgf.3 for ; Mon, 02 Jun 2014 09:09:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=avPnY3a1A+lGKXvcTyGDqACdvZcoc5xqoVss1RVd+vM=; b=Rm3g2neJMEYSPJsjbke9202eLXdPoEo4UjDc/+6lb24Q6+hhUfnrj6lXUZ+bLoFDHN TrRsaQxfErX6R2j9jLsFJTMmIemQe0GZmT4hUusW500geoyUBREn2U2WQg32pA+ML/O4 8XbB6fhRNtcf3W3IJ4qTnA03CoOI81tErVl3ijZQe3DJZqkwhmPUQTvVUybStNo6ghs3 AONXxjRnAbMyJyidTy+TIMkZXUpJAD2B1Rxzzn7NIAwgmdJSGA2nZch4XiGbeCPm7VUl oeV21m9A+HeQbwfUTJxCwZnHF1mpCNDWhtMNAGBMEUCSiZjBx5qvy9V5Z+y66fMLmdms BDLw== X-Gm-Message-State: ALoCoQmIsOxFoPZDVTT/tIwcISkwDyh4QTUEoq4py49nl4EkbWJvL2eJhNVmYrLxHdmfp9xHUZYm MIME-Version: 1.0 X-Received: by 10.140.104.204 with SMTP id a70mr46176303qgf.91.1401725341289; Mon, 02 Jun 2014 09:09:01 -0700 (PDT) Received: by 10.140.104.49 with HTTP; Mon, 2 Jun 2014 09:09:01 -0700 (PDT) In-Reply-To: <20140602082054.GE92342@elstar.local> References: <20140602082054.GE92342@elstar.local> Date: Mon, 2 Jun 2014 09:09:01 -0700 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , "netmod@ietf.org" Content-Type: multipart/alternative; boundary=001a1134f42a0a761904fadc9dfd Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/LNgOgWPbF3zhi4UY9g5Yab0eGi0 Subject: Re: [netmod] undecided Y26 allow mandatory nodes in augment X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2014 16:09:08 -0000 --001a1134f42a0a761904fadc9dfd Content-Type: text/plain; charset=ISO-8859-1 On Mon, Jun 2, 2014 at 1:20 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > We need to decide whether this is in scope of YANG 1.1 or not. > > What are the implications of allowing mandatory in augments? Can this > be misused and do we need to constraint this? > > I think this is part of a larger issue -- how to design YANG modules for reuse. This should be an open issue. There are design patterns that do not break old clients, but constraining the language to only these patterns is still a big TBD. > /js > > Andy > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --001a1134f42a0a761904fadc9dfd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Mon, Jun 2, 2014 at 1:20 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
We need to decide whether this is in scope o= f YANG 1.1 or not.

What are the implications of allowing mandatory in augments? Can this
be misused and do we need to constraint this?


I =A0think this is part of a larger issue -- how to = design YANG modules for reuse.
This should be an open issue. =A0T= here are design patterns that do not break
old clients, but constraining the language to only these patterns is s= till a big TBD.


=A0
/js


Andy
=A0
=
--
Juergen Schoenwaelder =A0 =A0 =A0 =A0 =A0 Jacobs University Bremen gGmbH Phone: +49 421 200 3587 =A0 =A0 =A0 =A0 Campus Ring 1, 28759 Bremen, German= y
Fax: =A0 +49 421 200 3103 =A0 =A0 =A0 =A0 <http://www.jacobs-university.de/><= br>
_______________________________________________
netmod mailing list
netmod@ietf.org
= https://www.ietf.org/mailman/listinfo/netmod

--001a1134f42a0a761904fadc9dfd-- From nobody Mon Jun 2 13:40:23 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 304391A045D; Mon, 2 Jun 2014 13:40:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iK0642V-beru; Mon, 2 Jun 2014 13:40:20 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 01F281A0464; Mon, 2 Jun 2014 13:40:18 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.4.2.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140602204018.1196.8963.idtracker@ietfa.amsl.com> Date: Mon, 02 Jun 2014 13:40:18 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/_yODTxGSnCToTy5cEctqN-f-yGI Cc: netmod chair , netmod mailing list , RFC Editor Subject: [netmod] Protocol Action: 'A YANG Data Model for System Management' to Proposed Standard (draft-ietf-netmod-system-mgmt-16.txt) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2014 20:40:21 -0000 The IESG has approved the following document: - 'A YANG Data Model for System Management' (draft-ietf-netmod-system-mgmt-16.txt) as Proposed Standard This document is the product of the NETCONF Data Modeling Language Working Group. The IESG contact persons are Benoit Claise and Joel Jaeggli. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-netmod-system-mgmt/ Technical Summary This document defines a YANG data model for the configuration and identification of some common system properties within a device containing a NETCONF server. This includes data node definitions for system identification, time-of-day management, user management, DNS resolver configuration, and some protocol operations for system management. Working Group Summary The normal WG process was followed and the documents reflect WG consensus with nothing special worth mentioning. Document Quality This document received extensive review within the working group and ample time was spent to review and reconsider all design choices. Some working group members have indicated that they plan to implement this data model once approved by the IESG. Personnel Juergen Schoenwaelder is the Document Shepherd. Benoit Claise is the responsible Area Director. From nobody Mon Jun 2 23:25:17 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 722B11A00EA for ; Mon, 2 Jun 2014 23:25:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DcinG49i6X75 for ; Mon, 2 Jun 2014 23:25:11 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id 4C2A51A00F8 for ; Mon, 2 Jun 2014 23:25:11 -0700 (PDT) Received: from localhost (x15.tail-f.com [192.168.1.60]) by mail.tail-f.com (Postfix) with ESMTPSA id B5D7712807E1; Tue, 3 Jun 2014 08:24:15 +0200 (CEST) Date: Tue, 03 Jun 2014 08:25:04 +0200 (CEST) Message-Id: <20140603.082504.1930881743030974892.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: <20140602081433.GA92342@elstar.local> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/RbLoAi8Iygqf7b4cvFhLzeBuPhc Cc: netmod@ietf.org Subject: Re: [netmod] undecided Y09 introduce optional keys X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 06:25:15 -0000 Andy Bierman wrote: > On Mon, Jun 2, 2014 at 1:14 AM, Juergen Schoenwaelder < > j.schoenwaelder@jacobs-university.de> wrote: > > > We need to decide whether this is in scope of YANG 1.1 or not. > > > > The implications of this seem to be somewhat unclear. Does this only > > work if there are defaults No, it would work also if the key leaf does not have a default. > or the leaf is initialized by system? I think that if we do Y12, initialized-by system would apply to non-key leafs only. Otherwise the client can't tell which value the server used w/o reading the entire list. (hmm, maybe not...) > This issue states that the problem to be solved is removal of a > redundant leaf in a list entry. If the key leaf has a YANG default > then it can be used instead (just like a non-key leaf). You mean the client needs to provide the default value? This is less user-friendly, and more error prone, since the operator (e.g., CLI user) must remember the correct default and type it in. > The creation of 1 list entry (per optional key) is optimized by solving > this problem. IMO that is not enough benefit to make this change. This assumes that there is a value to use for the optional key. It's not very elegant to have to put in some otherwise illegal value just to work around this apparent limitation. For example: list server { key "ip port"; leaf ip { type inet:ip-address; } leaf port { type union { type int8 { range "-1"; } type inet:port-number; } description "Use -1 to indicate that the port really is not set."; } ... } > This change would also break YANG 1.0 because a YANG 1.0 client > sending an with a missing key expects to get an error, not > . I disagree with this interpretation of backwards incompatibility. If all old clients must work with *new* modules, we can't do almost any changes at all. > Issue Y09 should be rejected. I think this issue needs more discussion. /martin From nobody Mon Jun 2 23:32:00 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A07AD1A0100 for ; Mon, 2 Jun 2014 23:31:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FO-99tU03TLD for ; Mon, 2 Jun 2014 23:31:56 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id BCE8A1A0108 for ; Mon, 2 Jun 2014 23:31:56 -0700 (PDT) Received: from localhost (x15.tail-f.com [192.168.1.60]) by mail.tail-f.com (Postfix) with ESMTPSA id 1C7111280F16; Tue, 3 Jun 2014 08:31:02 +0200 (CEST) Date: Tue, 03 Jun 2014 08:31:50 +0200 (CEST) Message-Id: <20140603.083150.482048035687747574.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: <20140602081547.GB92342@elstar.local> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/4vrZspaW-qfv7xpcyD35NIyimCI Cc: netmod@ietf.org Subject: Re: [netmod] undecided Y19 we need a better unique X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 06:31:58 -0000 Andy Bierman wrote: > On Mon, Jun 2, 2014 at 1:15 AM, Juergen Schoenwaelder < > j.schoenwaelder@jacobs-university.de> wrote: > > > We need to decide whether this is in scope of YANG 1.1 or not. > > > > > IMO this new feature should be rejected because there is already > a work-around with must-stmt (as shown in the solution). Two observations: 1) The work-around is incomprehensible, even to someone who understands XPath. 2) The work-around is O(N^2) whereas the proposed solution runs in O(N). > In order to maintain YANG 1.0 compatibility, there would be > 2 forms of the unique-stmt to support in YANG. Yes, I agree this is unfortunate. /martin From nobody Mon Jun 2 23:50:26 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5A811A0119 for ; Mon, 2 Jun 2014 23:50:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u0gjXoeBXSeu for ; Mon, 2 Jun 2014 23:50:20 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C8E91A010C for ; Mon, 2 Jun 2014 23:50:20 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 4AB7DE70; Tue, 3 Jun 2014 08:50:13 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id AQNcDQ7ROIQG; Tue, 3 Jun 2014 08:50:07 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 3 Jun 2014 08:50:12 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id E6DCE20017; Tue, 3 Jun 2014 08:50:12 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id TYPXUVpP-MAA; Tue, 3 Jun 2014 08:50:11 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7F9DF20013; Tue, 3 Jun 2014 08:50:10 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 727712D506C7; Tue, 3 Jun 2014 08:50:10 +0200 (CEST) Date: Tue, 3 Jun 2014 08:50:10 +0200 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20140603065010.GA4568@elstar.local> Mail-Followup-To: Martin Bjorklund , andy@yumaworks.com, netmod@ietf.org References: <20140602081433.GA92342@elstar.local> <20140603.082504.1930881743030974892.mbj@tail-f.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140603.082504.1930881743030974892.mbj@tail-f.com> User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/kvMxOWGG0SOypZN2C-qbWvpsnPk Cc: netmod@ietf.org Subject: Re: [netmod] undecided Y09 introduce optional keys X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 06:50:22 -0000 On Tue, Jun 03, 2014 at 08:25:04AM +0200, Martin Bjorklund wrote: > Andy Bierman wrote: > > On Mon, Jun 2, 2014 at 1:14 AM, Juergen Schoenwaelder < > > j.schoenwaelder@jacobs-university.de> wrote: > > > > > We need to decide whether this is in scope of YANG 1.1 or not. > > > > > > The implications of this seem to be somewhat unclear. Does this only > > > work if there are defaults > > No, it would work also if the key leaf does not have a default. But which value is then used? You seem to assume there is no value at all. What would be a good example for this? A configured service with an arbitrary port number seems somewhat strange to me - hence I am looking for a better example. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Tue Jun 3 00:02:18 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 888691A010C for ; Tue, 3 Jun 2014 00:02:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q8DnhpeEgRlx for ; Tue, 3 Jun 2014 00:02:13 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id 130A01A010B for ; Tue, 3 Jun 2014 00:02:12 -0700 (PDT) Received: from localhost (x15.tail-f.com [192.168.1.60]) by mail.tail-f.com (Postfix) with ESMTPSA id D4C5A12807E1; Tue, 3 Jun 2014 09:01:13 +0200 (CEST) Date: Tue, 03 Jun 2014 09:02:02 +0200 (CEST) Message-Id: <20140603.090202.1933519174538157296.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20140603065010.GA4568@elstar.local> References: <20140603.082504.1930881743030974892.mbj@tail-f.com> <20140603065010.GA4568@elstar.local> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/HnBw1zRJ6gB-3mxCu-JhobVHy2g Cc: netmod@ietf.org Subject: Re: [netmod] undecided Y09 introduce optional keys X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 07:02:14 -0000 Juergen Schoenwaelder wrote: > On Tue, Jun 03, 2014 at 08:25:04AM +0200, Martin Bjorklund wrote: > > Andy Bierman wrote: > > > On Mon, Jun 2, 2014 at 1:14 AM, Juergen Schoenwaelder < > > > j.schoenwaelder@jacobs-university.de> wrote: > > > > > > > We need to decide whether this is in scope of YANG 1.1 or not. > > > > > > > > The implications of this seem to be somewhat unclear. Does this only > > > > work if there are defaults > > > > No, it would work also if the key leaf does not have a default. > > But which value is then used? You seem to assume there is no value at > all. What would be a good example for this? A configured service with > an arbitrary port number seems somewhat strange to me - hence I am > looking for a better example. Recently there was the discussion about vrfs. Something like this: key "ip port vrf"; where vrf would be an optional key. Another use case is for extending models. Maybe you start with: key "ip port"; and later you add the vrf concept. Adding an optional key would be a nice way to extend this model. Currently we have to use an arbitrary key to handle this extensibilty problem. /martin From nobody Tue Jun 3 02:15:26 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E31B11A017F for ; Tue, 3 Jun 2014 02:15:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5QXAFWHcx51V for ; Tue, 3 Jun 2014 02:15:23 -0700 (PDT) Received: from mail-qa0-f50.google.com (mail-qa0-f50.google.com [209.85.216.50]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07DE21A00FC for ; Tue, 3 Jun 2014 02:15:22 -0700 (PDT) Received: by mail-qa0-f50.google.com with SMTP id j15so4434549qaq.37 for ; Tue, 03 Jun 2014 02:15:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=jpMe3VHTQ7rNhGi9F0yDzF2urzrZ1pEVlQ0y43d41gM=; b=IpHl32GsTRyTbgEN7BHJXF34qB7QsszwD/WWNo4tT70RWYUZjRclm/iEpkt2U3Jj9n ZBAO+0fXDKI6mtePtlaUQAngU++sBOj2qZ0Gl2+vqwU0mcF03ixp3DwuImmj/dCNhSD1 cRHuw1/6xIRG8so6up1pAuhJkhmUQKmMSbj33AREg0+/I0Te3eVEHEG5R3NWhADCQIUK A4nRuF52YzQo6sGOzzij3OyElbMr/Q09oePgaUWgU6haCxuq8xEgXo0n6AmRZZcTd342 txn5h8X9o9Hq84IgeYJkVCVercTdLxyqLJ1bxJpuNB5nK9zNaXjWRDPII/5JWI0Gmz5g 3DFg== X-Gm-Message-State: ALoCoQm+6ulPi+fU5LuXkChbjUkwzkw7ctoPb+umS1cP4RiYHJ7to821It7oXTBYiooJw4hcDqHZ MIME-Version: 1.0 X-Received: by 10.224.165.70 with SMTP id h6mr58968406qay.78.1401786916938; Tue, 03 Jun 2014 02:15:16 -0700 (PDT) Received: by 10.140.104.49 with HTTP; Tue, 3 Jun 2014 02:15:16 -0700 (PDT) In-Reply-To: <20140603.090202.1933519174538157296.mbj@tail-f.com> References: <20140603.082504.1930881743030974892.mbj@tail-f.com> <20140603065010.GA4568@elstar.local> <20140603.090202.1933519174538157296.mbj@tail-f.com> Date: Tue, 3 Jun 2014 02:15:16 -0700 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: multipart/alternative; boundary=089e0149c3a43c3e5404faeaf35c Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/ft3_jacOdyZzfXicKZ8chvDGLW8 Cc: "netmod@ietf.org" Subject: Re: [netmod] undecided Y09 introduce optional keys X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 09:15:25 -0000 --089e0149c3a43c3e5404faeaf35c Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jun 3, 2014 at 12:02 AM, Martin Bjorklund wrote: > Juergen Schoenwaelder wrote: > > On Tue, Jun 03, 2014 at 08:25:04AM +0200, Martin Bjorklund wrote: > > > Andy Bierman wrote: > > > > On Mon, Jun 2, 2014 at 1:14 AM, Juergen Schoenwaelder < > > > > j.schoenwaelder@jacobs-university.de> wrote: > > > > > > > > > We need to decide whether this is in scope of YANG 1.1 or not. > > > > > > > > > > The implications of this seem to be somewhat unclear. Does this > only > > > > > work if there are defaults > > > > > > No, it would work also if the key leaf does not have a default. > > > > But which value is then used? You seem to assume there is no value at > > all. What would be a good example for this? A configured service with > > an arbitrary port number seems somewhat strange to me - hence I am > > looking for a better example. > > Recently there was the discussion about vrfs. Something like this: > > key "ip port vrf"; > > where vrf would be an optional key. > > > So the list would have either 2 keys or 3 keys, depending on what the client decides to provide. It isn't that the server picks the default value or even some ad-hoc value unknown to the client. IMO variable number of keys is too complicated. It is better to keep YANG list naming stable. > Another use case is for extending models. Maybe you start with: > > key "ip port"; > > and later you add the vrf concept. Adding an optional key would be a > nice way to extend this model. Currently we have to use an arbitrary > key to handle this extensibilty problem. > Add a new list if the number of keys changes over time. Use leafref for the keys being duplicated. > > > /martin > > Andy --089e0149c3a43c3e5404faeaf35c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Tue, Jun 3, 2014 at 12:02 AM, Martin Bjorklund <mbj@tail-f.com= > wrote:
Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de<= /a>> wrote:
> On Tue, Jun 03, 2014 at 08:25:04AM +0200, Martin Bjorklund wrote:
> > Andy Bierman <andy@yumaw= orks.com> wrote:
> > > On Mon, Jun 2, 2014 at 1:14 AM, Juergen Schoenwaelder < > > > j.sc= hoenwaelder@jacobs-university.de> wrote:
> > >
> > > > We need to decide whether this is in scope of YANG 1.1 = or not.
> > > >
> > > > The implications of this seem to be somewhat unclear. D= oes this only
> > > > work if there are defaults
> >
> > No, it would work also if the key leaf does not have a default. >
> But which value is then used? You seem to assume there is no value at<= br> > all. What would be a good example for this? A configured service with<= br> > an arbitrary port number seems somewhat strange to me - hence I am
> looking for a better example.

Recently there was the discussion about vrfs. =A0Something like this:

=A0 key "ip port vrf";

where vrf would be an optional key.




So the list would have = either 2 keys or 3 keys, depending on what the
client decides to = provide. =A0It isn't that the server picks the default value
or even some ad-hoc value unknown to the client.

I= MO variable number of keys is too complicated.
It is better to ke= ep YANG list naming stable.

=A0
Another use case is for extending models. =A0Maybe you start with:

=A0 key "ip port";

and later you add the vrf concept. =A0Adding an optional key would be a
nice way to extend this model. =A0Currently we have to use an arbitrary
key to handle this extensibilty problem.

Add a new list if the number of keys changes over time.
Use lea= fref for the keys being duplicated.


=A0


/martin


Andy<= /div>

--089e0149c3a43c3e5404faeaf35c-- From nobody Tue Jun 3 02:55:06 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2299C1A00C0 for ; Tue, 3 Jun 2014 02:55:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QQTSwNWoiF50 for ; Tue, 3 Jun 2014 02:55:03 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id B237F1A00A3 for ; Tue, 3 Jun 2014 02:55:03 -0700 (PDT) Received: from localhost (x15.tail-f.com [192.168.1.60]) by mail.tail-f.com (Postfix) with ESMTPSA id 1341D12807E1; Tue, 3 Jun 2014 11:54:08 +0200 (CEST) Date: Tue, 03 Jun 2014 11:54:57 +0200 (CEST) Message-Id: <20140603.115457.1932459625756121828.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: <20140603065010.GA4568@elstar.local> <20140603.090202.1933519174538157296.mbj@tail-f.com> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/ee-FD2C3I6mYnzkC-xSqzvIfJFU Cc: netmod@ietf.org Subject: Re: [netmod] undecided Y09 introduce optional keys X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 09:55:05 -0000 Andy Bierman wrote: > On Tue, Jun 3, 2014 at 12:02 AM, Martin Bjorklund wrote: > > > Juergen Schoenwaelder wrote: > > > On Tue, Jun 03, 2014 at 08:25:04AM +0200, Martin Bjorklund wrote: > > > > Andy Bierman wrote: > > > > > On Mon, Jun 2, 2014 at 1:14 AM, Juergen Schoenwaelder < > > > > > j.schoenwaelder@jacobs-university.de> wrote: > > > > > > > > > > > We need to decide whether this is in scope of YANG 1.1 or not. > > > > > > > > > > > > The implications of this seem to be somewhat unclear. Does this > > only > > > > > > work if there are defaults > > > > > > > > No, it would work also if the key leaf does not have a default. > > > > > > But which value is then used? You seem to assume there is no value at > > > all. What would be a good example for this? A configured service with > > > an arbitrary port number seems somewhat strange to me - hence I am > > > looking for a better example. > > > > Recently there was the discussion about vrfs. Something like this: > > > > key "ip port vrf"; > > > > where vrf would be an optional key. > > > > > > > > So the list would have either 2 keys or 3 keys, depending on what the > client decides to provide. It isn't that the server picks the default value > or even some ad-hoc value unknown to the client. > > IMO variable number of keys is too complicated. In what way is this complicated? /martin From nobody Tue Jun 3 04:50:19 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDCAE1A01D8 for ; Tue, 3 Jun 2014 04:50:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bFbUyL3niLGF for ; Tue, 3 Jun 2014 04:50:16 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77D171A01D5 for ; Tue, 3 Jun 2014 04:50:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 1651954083A; Tue, 3 Jun 2014 13:50:09 +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 8KFWuXuTc0FN; Tue, 3 Jun 2014 13:50:04 +0200 (CEST) Received: from localhost (unknown [172.29.2.201]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id ED74B540447; Tue, 3 Jun 2014 13:50:03 +0200 (CEST) From: Ladislav Lhotka To: Martin Bjorklund , andy@yumaworks.com In-Reply-To: <20140603.082504.1930881743030974892.mbj@tail-f.com> References: <20140602081433.GA92342@elstar.local> <20140603.082504.1930881743030974892.mbj@tail-f.com> User-Agent: Notmuch/0.17 (http://notmuchmail.org) Emacs/24.3.50.2 (x86_64-apple-darwin13.0.0) Date: Tue, 03 Jun 2014 13:50:02 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/xTXtQSr8_c1d1pVczBUCGonVEAo Cc: netmod@ietf.org Subject: Re: [netmod] undecided Y09 introduce optional keys X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 11:50:19 -0000 Martin Bjorklund writes: > Andy Bierman wrote: >> On Mon, Jun 2, 2014 at 1:14 AM, Juergen Schoenwaelder < >> j.schoenwaelder@jacobs-university.de> wrote: >> >> > We need to decide whether this is in scope of YANG 1.1 or not. >> > >> > The implications of this seem to be somewhat unclear. Does this only >> > work if there are defaults > > No, it would work also if the key leaf does not have a default. > >> or the leaf is initialized by system? > > I think that if we do Y12, initialized-by system would apply to > non-key leafs only. Otherwise the client can't tell which value the > server used w/o reading the entire list. (hmm, maybe not...) Well, in the case of user database, the key is often the (system generated) uid. > >> This issue states that the problem to be solved is removal of a >> redundant leaf in a list entry. If the key leaf has a YANG default >> then it can be used instead (just like a non-key leaf). > > You mean the client needs to provide the default value? > > This is less user-friendly, and more error prone, since the operator > (e.g., CLI user) must remember the correct default and type it in. > >> The creation of 1 list entry (per optional key) is optimized by solving >> this problem. IMO that is not enough benefit to make this change. > > This assumes that there is a value to use for the optional key. It's > not very elegant to have to put in some otherwise illegal value just > to work around this apparent limitation. For example: > > list server { > key "ip port"; > leaf ip { > type inet:ip-address; > } > leaf port { > type union { > type int8 { > range "-1"; > } > type inet:port-number; > } > description > "Use -1 to indicate that the port really is not set."; > } > ... > } > >> This change would also break YANG 1.0 because a YANG 1.0 client >> sending an with a missing key expects to get an error, not >> . > > I disagree with this interpretation of backwards incompatibility. If > all old clients must work with *new* modules, we can't do almost any > changes at all. +1. The backward compatibility requirement for 1.1 states that old modules must not become invalid, and this is satisfied here. > >> Issue Y09 should be rejected. > > I think this issue needs more discussion. Yes, and I think it should therefore be OPENed. Lada > > > /martin > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Tue Jun 3 05:02:38 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49C2E1A01D5 for ; Tue, 3 Jun 2014 05:02:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qgc6ouquo0XM for ; Tue, 3 Jun 2014 05:02:36 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BD131A01D9 for ; Tue, 3 Jun 2014 05:02:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 45F8B54083A; Tue, 3 Jun 2014 14:02:29 +0200 (CEST) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GZdAeCfVBmg9; Tue, 3 Jun 2014 14:02:22 +0200 (CEST) Received: from localhost (unknown [172.29.2.201]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 7BD34540447; Tue, 3 Jun 2014 14:02:22 +0200 (CEST) From: Ladislav Lhotka To: Juergen Schoenwaelder , netmod@ietf.org In-Reply-To: <20140602081547.GB92342@elstar.local> References: <20140602081547.GB92342@elstar.local> User-Agent: Notmuch/0.17 (http://notmuchmail.org) Emacs/24.3.50.2 (x86_64-apple-darwin13.0.0) Date: Tue, 03 Jun 2014 14:02:21 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/xy3b0CiSPZOiROxCj106XlvCBI0 Subject: Re: [netmod] undecided Y19 we need a better unique X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 12:02:37 -0000 Juergen Schoenwaelder writes: > We need to decide whether this is in scope of YANG 1.1 or not. I think this should be rejected because the problem doesn't exist. RFC 6110 (sec. 12.16 together with 12.8) presents IMO a reasonable XPath interpretation that works with sublists, too: http://tools.ietf.org/html/rfc6110#section-12.16 Lada > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Tue Jun 3 05:24:17 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9374D1A0240 for ; Tue, 3 Jun 2014 05:24:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9TtsDGpQmsMX for ; Tue, 3 Jun 2014 05:24:07 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A68201A022D for ; Tue, 3 Jun 2014 05:24:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 8CC5A54083A; Tue, 3 Jun 2014 14:23: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 9t5bPjRFNvWa; Tue, 3 Jun 2014 14:23:54 +0200 (CEST) Received: from localhost (unknown [172.29.2.201]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 0C8A5540447; Tue, 3 Jun 2014 14:23:53 +0200 (CEST) From: Ladislav Lhotka To: Andy Bierman , Juergen Schoenwaelder , "netmod\@ietf.org" In-Reply-To: References: <20140602081714.GC92342@elstar.local> User-Agent: Notmuch/0.17 (http://notmuchmail.org) Emacs/24.3.50.2 (x86_64-apple-darwin13.0.0) Date: Tue, 03 Jun 2014 14:23:53 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/4mYED7mG32MP-vSOhOy4UmRExEA Subject: Re: [netmod] undecided Y21 statement to define new XPath functions in a module X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 12:24:10 -0000 Andy Bierman writes: > On Mon, Jun 2, 2014 at 1:17 AM, Juergen Schoenwaelder < > j.schoenwaelder@jacobs-university.de> wrote: > >> We need to decide whether this is in scope of YANG 1.1 or not. >> >> Is there a risk that this may get abused, leading to non-interoperable >> vendor specific sets of functions in XPATH expressions? >> >> > > Although I like this technical solution, I think it permits too much > variability in the standard, so it should be rejected. > The YANG 1.1 XPath library should be hard-wired (just like 1.0). +1. I think such a feature would be misused by vendors for locking customers in their silos, as it was the case e.g. with Internet Explorer extensions. All extensions must remain strictly optional. Lada > > >> /js >> > > Andy > > >> >> -- >> Juergen Schoenwaelder Jacobs University Bremen gGmbH >> Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany >> Fax: +49 421 200 3103 >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >> > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Tue Jun 3 05:47:45 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3797D1A01F3 for ; Tue, 3 Jun 2014 05:47:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FL7KpsJWy4ro for ; Tue, 3 Jun 2014 05:47:42 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CBF41A01D9 for ; Tue, 3 Jun 2014 05:47:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id BEDCD54083A; Tue, 3 Jun 2014 14:47:35 +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 5d09ISrwsFzc; Tue, 3 Jun 2014 14:47:32 +0200 (CEST) Received: from localhost (unknown [172.29.2.201]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 2454F540447; Tue, 3 Jun 2014 14:47:32 +0200 (CEST) From: Ladislav Lhotka To: Andy Bierman , Juergen Schoenwaelder , "netmod\@ietf.org" In-Reply-To: References: <20140602081915.GD92342@elstar.local> User-Agent: Notmuch/0.17 (http://notmuchmail.org) Emacs/24.3.50.2 (x86_64-apple-darwin13.0.0) Date: Tue, 03 Jun 2014 14:47:31 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/m1qCLr5vjDATmSNJn3Lv4Cx1Vp4 Subject: Re: [netmod] undecided Y22 support constraints on unions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 12:47:44 -0000 Andy Bierman writes: > On Mon, Jun 2, 2014 at 1:19 AM, Juergen Schoenwaelder < > j.schoenwaelder@jacobs-university.de> wrote: > >> We need to decide whether this is in scope of YANG 1.1 or not. >> >> It remains somewhat unclear what exactly the problem is that this >> is supposed to solve. >> >> > It seems to suggest that individual type-stmts within a union type-stmt > should be conditional, based on an XPath expression. > > It may be useful to support constraints for union type. For > example, a server can be defined as union of > domain-name/ip-addresss. However, domain-name should only be > allowed when a dns-server exists. > > #+BEGIN_EXAMPLE > leaf foo { > type union { > type uint32; > type union { > type enumeration { > enum bar; > } > type string; > } > } > } > #+END_EXAMPLE > > If foo has value "hi mom", base-type(foo) returns "string". > > Unfortunately, this won't work for the example use case, since both > domain-name and ip-address are strings. > > The example is about 'foo' so I don't understand the reference to the other > leafs. > I understand that the tool implementation needs to know the type-stmt that > actually matched in a union, but that is just an internal > implementation detail. Not sure what "base-type(foo) returns string" means > or why this would need to be exposed in the language. > > The type-stmts within a union need to be static, not changing based > on some boolean expression. This issue should be rejected. I agree. Maybe it would be useful to define an attribute allowing the sender to specify which of the union alternatives is actually used, i.e. 1.2.3.4 Lada > > > /js >> >> > Andy > > >> -- >> Juergen Schoenwaelder Jacobs University Bremen gGmbH >> Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany >> Fax: +49 421 200 3103 >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >> > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Tue Jun 3 05:55:47 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 683391A01F6 for ; Tue, 3 Jun 2014 05:55:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hGF0slN7LYie for ; Tue, 3 Jun 2014 05:55:43 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 207E21A01F3 for ; Tue, 3 Jun 2014 05:55:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 2600C54083A; Tue, 3 Jun 2014 14:55: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 I6gvQtXvfHb2; Tue, 3 Jun 2014 14:55:30 +0200 (CEST) Received: from localhost (unknown [172.29.2.201]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 79167540377; Tue, 3 Jun 2014 14:55:30 +0200 (CEST) From: Ladislav Lhotka To: Andy Bierman , Juergen Schoenwaelder , "netmod\@ietf.org" In-Reply-To: References: <20140602082054.GE92342@elstar.local> User-Agent: Notmuch/0.17 (http://notmuchmail.org) Emacs/24.3.50.2 (x86_64-apple-darwin13.0.0) Date: Tue, 03 Jun 2014 14:55:29 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/h0hyVYPS3ztA2od_EiGMCoB2tRc Subject: Re: [netmod] undecided Y26 allow mandatory nodes in augment X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 12:55:45 -0000 Andy Bierman writes: > On Mon, Jun 2, 2014 at 1:20 AM, Juergen Schoenwaelder < > j.schoenwaelder@jacobs-university.de> wrote: > >> We need to decide whether this is in scope of YANG 1.1 or not. >> >> What are the implications of allowing mandatory in augments? Can this >> be misused and do we need to constraint this? >> >> > I think this is part of a larger issue -- how to design YANG modules for > reuse. > This should be an open issue. There are design patterns that do not break > old clients, but constraining the language to only these patterns is still > a big TBD. Yes, and it also has to do with conformance specification. For instance, ietf-routing module needs at least one address family specific module to be useful. So a conformace statement should say this, and then there is no reason why the address family modules augmenting ietf-routing couldn't define mandatory nodes. Lada > > > > >> /js >> >> > Andy > > >> -- >> Juergen Schoenwaelder Jacobs University Bremen gGmbH >> Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany >> Fax: +49 421 200 3103 >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >> > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Tue Jun 3 06:10:30 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEFB11A026A for ; Tue, 3 Jun 2014 06:10:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lbRXNZGYGx0O for ; Tue, 3 Jun 2014 06:10:28 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA0B01A0278 for ; Tue, 3 Jun 2014 06:10:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id E67A454083A; Tue, 3 Jun 2014 15:10:08 +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 L2qDeE0tEkmL; Tue, 3 Jun 2014 15:10:04 +0200 (CEST) Received: from localhost (unknown [172.29.2.201]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 93A7C540377; Tue, 3 Jun 2014 15:10:04 +0200 (CEST) From: Ladislav Lhotka To: Juergen Schoenwaelder , netmod@ietf.org In-Reply-To: <20140602082421.GG92342@elstar.local> References: <20140602082421.GG92342@elstar.local> User-Agent: Notmuch/0.17 (http://notmuchmail.org) Emacs/24.3.50.2 (x86_64-apple-darwin13.0.0) Date: Tue, 03 Jun 2014 15:10:03 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/VnybX7aHBhjf6wHi3pas4qd38HQ Subject: Re: [netmod] undecided Y33 add 'attribute' statement X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 13:10:30 -0000 Juergen Schoenwaelder writes: > We need to decide whether this is in scope of YANG 1.1 or not. > > Is there a risk of attributes getting abused? How do we define > metadata? We do not seem to want people to use attributes to model > data. Yes, this has to be discussed. The secondary point of this issue is that IF any standard (global) attributes are to be defined, YANG modules are a good place to do it, rather than, say, using new NETCONF capabilities. Lada > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Tue Jun 3 06:29:01 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 531A81A026A for ; Tue, 3 Jun 2014 06:29:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ed06nDnJmzj1 for ; Tue, 3 Jun 2014 06:28:58 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 590E51A026C for ; Tue, 3 Jun 2014 06:28:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 5FC3854083A; Tue, 3 Jun 2014 15:28:51 +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 nINnmoNw8bjv; Tue, 3 Jun 2014 15:28:47 +0200 (CEST) Received: from localhost (unknown [172.29.2.201]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 03475540377; Tue, 3 Jun 2014 15:28:46 +0200 (CEST) From: Ladislav Lhotka To: Juergen Schoenwaelder , netmod@ietf.org In-Reply-To: <20140602082634.GH92342@elstar.local> References: <20140602082634.GH92342@elstar.local> User-Agent: Notmuch/0.17 (http://notmuchmail.org) Emacs/24.3.50.2 (x86_64-apple-darwin13.0.0) Date: Tue, 03 Jun 2014 15:28:45 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/3YUOVDmCdivWtea34gi_CLBxwaw Subject: Re: [netmod] undecided Y36 associate a notification with a data node X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 13:29:00 -0000 Juergen Schoenwaelder writes: > We need to decide whether this is in scope of YANG 1.1 or not. > > There are several questions associated with this and perhaps this > requires some solution think through in order to understand the > implications in more details. A general solution would IMO add a lot of complexity because the conditions triggering the notification may differ. For example: - For a boolean leaf, should the notification be sent whenever the leaf is enabled, disabled or both? - What are the triggering conditions for non-boolean leafs? There are two good solutions for handling such needs: - write appropriate description, - define an extension. So my preference is to reject this issue. Lada > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Tue Jun 3 06:40:07 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FE541A026A for ; Tue, 3 Jun 2014 06:40:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 62rOIK09xdFC for ; Tue, 3 Jun 2014 06:40:00 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2370C1A0290 for ; Tue, 3 Jun 2014 06:40:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 552A354083A; Tue, 3 Jun 2014 15:39:53 +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 wWBmCrYAPJmw; Tue, 3 Jun 2014 15:39:48 +0200 (CEST) Received: from localhost (unknown [172.29.2.201]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id BD1E4540377; Tue, 3 Jun 2014 15:39:48 +0200 (CEST) From: Ladislav Lhotka To: Juergen Schoenwaelder , netmod@ietf.org In-Reply-To: <20140602082830.GI92342@elstar.local> References: <20140602082830.GI92342@elstar.local> User-Agent: Notmuch/0.17 (http://notmuchmail.org) Emacs/24.3.50.2 (x86_64-apple-darwin13.0.0) Date: Tue, 03 Jun 2014 15:39:47 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/7LKN49XHHdFpe2_SDWhZerUW7sw Subject: Re: [netmod] undecided Y37 allow notifications to be derived from other notifications X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 13:40:02 -0000 Juergen Schoenwaelder writes: > We need to decide whether this is in scope of YANG 1.1 or not. > > It remains unclear whether this feature is needed for real-world data > models or whether existing groupings get us there alreadly to a large > extend. I think this can be handled quite nicely by adding a "type" leaf of the identity type. Lada > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Tue Jun 3 06:49:34 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6889B1A0290 for ; Tue, 3 Jun 2014 06:49:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eeyFhRZrmQk7 for ; Tue, 3 Jun 2014 06:49:32 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3877A1A0283 for ; Tue, 3 Jun 2014 06:49:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 69D4854083A; Tue, 3 Jun 2014 15:49:25 +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 fiGXwuRRy1jl; Tue, 3 Jun 2014 15:49:22 +0200 (CEST) Received: from localhost (unknown [172.29.2.201]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 4916A540377; Tue, 3 Jun 2014 15:49:22 +0200 (CEST) From: Ladislav Lhotka To: Juergen Schoenwaelder , netmod@ietf.org In-Reply-To: <20140602083330.GL92342@elstar.local> References: <20140602083330.GL92342@elstar.local> User-Agent: Notmuch/0.17 (http://notmuchmail.org) Emacs/24.3.50.2 (x86_64-apple-darwin13.0.0) Date: Tue, 03 Jun 2014 15:49:21 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/Ms9Vg85-vHXdoZmYcrrjFSvCtVk Subject: Re: [netmod] undecided Y54 remove the advertisement of conformance information in NETCONF hello message X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 13:49:33 -0000 Juergen Schoenwaelder writes: > We need to decide whether this is in scope of YANG 1.1 or not. I think this should be OPENed as it is one of the parts that are really NETCONF-specific. Lada > > This may be subsumed by Y45 (OPEN) and Y16 (OPEN). > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Tue Jun 3 07:13:58 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D0451A0170 for ; Tue, 3 Jun 2014 07:13:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NeNRK9B7H2I6 for ; Tue, 3 Jun 2014 07:13:52 -0700 (PDT) Received: from mail-qg0-f44.google.com (mail-qg0-f44.google.com [209.85.192.44]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAB5A1A0171 for ; Tue, 3 Jun 2014 07:13:52 -0700 (PDT) Received: by mail-qg0-f44.google.com with SMTP id i50so13254402qgf.31 for ; Tue, 03 Jun 2014 07:13:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=zS6hoxIuVXmCnEalpuQnTLljYPaz06O8zvnk3x33dBU=; b=aUBH2ZRIuB39aNtqCDrjCeHSwkZlXDVpmbU+qCsl0Rlp4NtyiMVGeVeOYllkcI7vRH EZCguuT1KOPMnc26DkT3c0h2uVQ9xyXDMKhSv5OQyn2yMKxpkj1CjaIWWFhUjp4s70DG qMlvk5DkWkp/Ptki9Rnu0By9RYOlSPSovSjXbB8El2XT8aw+4LFOOXeauLpPnUT/YHVw IgB+NBursObiLj+FUWz++4tmlYvnhDNNDN9OFq6yQtSzv8hCSXueESKpMiYOmwsSfp61 RwHFTCrp5i5Qt++lTWY6S+TlhKhnZP4CCJIX8aFOsZEdkuqju4SnArAGrNRPaqz+Z+ZN D/gw== X-Gm-Message-State: ALoCoQlx6V8HP2rKoXL5rmYSoA8Sr/ssNkrI08WSqScJJ7QSMRRsi+MRMu3DVTXYw+tf/JCA79zF MIME-Version: 1.0 X-Received: by 10.140.27.245 with SMTP id 108mr56184379qgx.18.1401804826445; Tue, 03 Jun 2014 07:13:46 -0700 (PDT) Received: by 10.140.104.49 with HTTP; Tue, 3 Jun 2014 07:13:46 -0700 (PDT) In-Reply-To: <20140603.115457.1932459625756121828.mbj@tail-f.com> References: <20140603065010.GA4568@elstar.local> <20140603.090202.1933519174538157296.mbj@tail-f.com> <20140603.115457.1932459625756121828.mbj@tail-f.com> Date: Tue, 3 Jun 2014 07:13:46 -0700 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: multipart/alternative; boundary=001a11c15260baa08f04faef1ef1 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/xvz9lWUyckeIukQdj7az-AtksMg Cc: "netmod@ietf.org" Subject: Re: [netmod] undecided Y09 introduce optional keys X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 14:13:54 -0000 --001a11c15260baa08f04faef1ef1 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jun 3, 2014 at 2:54 AM, Martin Bjorklund wrote: > Andy Bierman wrote: > > On Tue, Jun 3, 2014 at 12:02 AM, Martin Bjorklund > wrote: > > > > > Juergen Schoenwaelder wrote: > > > > On Tue, Jun 03, 2014 at 08:25:04AM +0200, Martin Bjorklund wrote: > > > > > Andy Bierman wrote: > > > > > > On Mon, Jun 2, 2014 at 1:14 AM, Juergen Schoenwaelder < > > > > > > j.schoenwaelder@jacobs-university.de> wrote: > > > > > > > > > > > > > We need to decide whether this is in scope of YANG 1.1 or not. > > > > > > > > > > > > > > The implications of this seem to be somewhat unclear. Does this > > > only > > > > > > > work if there are defaults > > > > > > > > > > No, it would work also if the key leaf does not have a default. > > > > > > > > But which value is then used? You seem to assume there is no value at > > > > all. What would be a good example for this? A configured service with > > > > an arbitrary port number seems somewhat strange to me - hence I am > > > > looking for a better example. > > > > > > Recently there was the discussion about vrfs. Something like this: > > > > > > key "ip port vrf"; > > > > > > where vrf would be an optional key. > > > > > > > > > > > > > So the list would have either 2 keys or 3 keys, depending on what the > > client decides to provide. It isn't that the server picks the default > value > > or even some ad-hoc value unknown to the client. > > > > IMO variable number of keys is too complicated. > > In what way is this complicated? > > This creates multiple ways for a list entry to be named. I think it is much simpler if all list entries of the same object have the same number of key components. Can I rename an entry by adding or deleting keys after it is created? This adds complexity. IMO it is better to only have lists that use the same naming. This corner case should be rare enough that simply picking a special value for the keys that can mean "applies to all entries". SQL seems to allow NULL foreign keys but not inline keys, so this change would not be compatible with an implementation that converts YANG to SQL. > /martin > Andy --001a11c15260baa08f04faef1ef1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Tue, Jun 3, 2014 at 2:54 AM, Martin Bjorklund = <mbj@tail-f.com&= gt; wrote:
Andy Bierman <andy@yumaworks.com> wrote:
> On Tue, Jun 3, 2014 at 12:02 AM, Martin Bjorklund <mbj@tail-f.com> wrote:
>
> > Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
> > > On Tue, Jun 03, 2014 at 08:25:04AM +0200, Martin Bjorklund w= rote:
> > > > Andy Bierman <= andy@yumaworks.com> wrote:
> > > > > On Mon, Jun 2, 2014 at 1:14 AM, Juergen Schoenwael= der <
> > > > > j.schoenwaelder@jacobs-university.de> wrote:
> > > > >
> > > > > > We need to decide whether this is in scope of= YANG 1.1 or not.
> > > > > >
> > > > > > The implications of this seem to be somewhat = unclear. Does this
> > only
> > > > > > work if there are defaults
> > > >
> > > > No, it would work also if the key leaf does not have a = default.
> > >
> > > But which value is then used? You seem to assume there is no= value at
> > > all. What would be a good example for this? A configured ser= vice with
> > > an arbitrary port number seems somewhat strange to me - henc= e I am
> > > looking for a better example.
> >
> > Recently there was the discussion about vrfs. =A0Something like t= his:
> >
> > =A0 key "ip port vrf";
> >
> > where vrf would be an optional key.
> >
> >
> >
>
> So the list would have either 2 keys or 3 keys, depending on what the<= br> > client decides to provide. =A0It isn't that the server picks the d= efault value
> or even some ad-hoc value unknown to the client.
>
> IMO variable number of keys is too complicated.

In what way is this complicated?


This creates multiple ways for a list entry to be na= med.
I think it is much simpler if all list entries of the same o= bject
have the same number of key components.

Can I= rename an entry by adding or deleting keys after it is created?
= This adds complexity.

IMO it is better to only hav= e lists that use the same naming.
This corner case should be rare enough that simply picking a special v= alue
for the keys that can mean "applies to all entries"= ;.

SQL seems to allow NULL foreign keys but not in= line keys, so
this change would not be compatible with an implementation that
<= div>converts YANG to SQL.



/martin


<= /div>
Andy

--001a11c15260baa08f04faef1ef1-- From nobody Tue Jun 3 07:37:18 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B84D1A02DA for ; Tue, 3 Jun 2014 07:37:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VAUIfBS_pVMO for ; Tue, 3 Jun 2014 07:37:16 -0700 (PDT) Received: from mail-qg0-f46.google.com (mail-qg0-f46.google.com [209.85.192.46]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 581DF1A02CF for ; Tue, 3 Jun 2014 07:37:16 -0700 (PDT) Received: by mail-qg0-f46.google.com with SMTP id q108so12833838qgd.5 for ; Tue, 03 Jun 2014 07:37:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=PoZunKt0U7I0d+uPhefUtj468JsOKWBQLM2LeJ8L9mk=; b=aiVGdSm7hxcA71CpkBSeWoXKlg15Z5zHDOSXDPVh/Ta8F0IPlLJarJaiSdvoYMGJnu ONOY+WB+p5IHIk3bO1nwUTH0ZZx0/LpEF3bjXMUDQ08oZ3FG6aaFHhkYyJOd0n7z73t+ stcYtdR/2UXZ0qmx4IqRyNQ2AM3LWosf6NmNPhsiaT3U98sZpOaToOVbl7HXA7GKkZE3 aGaEjFbZczvtd3xExy/LmF5TibztKNwX9k6Y7KISV8SFRZFYr5NRCsxDbRCqt4eObMia p4nxGO402R/Ux2GvoFCqEViK31bPJcyEQQk7QLj48ZoyxAurVFqSPLQRIQIIx85T5neW utWA== X-Gm-Message-State: ALoCoQnkzteajqh13K9gcMc+d3hFxSMkhQpHZhFiHb/NP6ON9W5qx4yKH+TI/rJOSPWyZu68DbfD MIME-Version: 1.0 X-Received: by 10.224.79.198 with SMTP id q6mr60582973qak.99.1401806230016; Tue, 03 Jun 2014 07:37:10 -0700 (PDT) Received: by 10.140.104.49 with HTTP; Tue, 3 Jun 2014 07:37:09 -0700 (PDT) In-Reply-To: References: <20140602083330.GL92342@elstar.local> Date: Tue, 3 Jun 2014 07:37:09 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=047d7bdca5da6323c804faef7291 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/vBm2kkOCwrBL33neQgyEKS68Fng Cc: "netmod@ietf.org" Subject: Re: [netmod] undecided Y54 remove the advertisement of conformance information in NETCONF hello message X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 14:37:17 -0000 --047d7bdca5da6323c804faef7291 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jun 3, 2014 at 6:49 AM, Ladislav Lhotka wrote: > Juergen Schoenwaelder writes: > > > We need to decide whether this is in scope of YANG 1.1 or not. > > I think this should be OPENed as it is one of the parts that are really > NETCONF-specific. > > Agree to open, but solution very TBD It is not really NETCONF-specific because the same URI could be conveyed from the server to the client in different protocols. This text should just identify the contents of the URI without saying how it is used in a protocol. Better yet would be to just advertise service-level YANG conformance and drop module URIs from the advertisement. Lada > > Andy > > > > This may be subsumed by Y45 (OPEN) and Y16 (OPEN). > > > > /js > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > > Fax: +49 421 200 3103 > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --047d7bdca5da6323c804faef7291 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Tue, Jun 3, 2014 at 6:49 AM, Ladislav Lhotka &= lt;lhotka@nic.cz>= wrote:
Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de<= /a>> writes:

> We need to decide whether this is in scope of YANG 1.1 or not.

I think this should be OPENed as it is one of the parts that are really NET= CONF-specific.


Agree to open, but solution very TBD

It is not really NETCONF-specific because the same = URI could be conveyed
from the server to the client in different = protocols. This text should just identify
the contents of the URI without saying how it is used in a protocol.
Better yet would be to just advertise service-level YANG conforman= ce
and drop module URIs from the advertisement.


Lada


Andy
=A0
>
> This may be subsumed by Y45 (OPEN) and Y16 (OPEN).
>
> /js
>
> --
> Juergen Schoenwaelder =A0 =A0 =A0 =A0 =A0 Jacobs University Bremen gGm= bH
> Phone: +49 421 200 3587 =A0 =A0 =A0 =A0 Campus Ring 1, 28759 Bremen, G= ermany
> Fax: =A0 +49 421 200 3103 =A0 =A0 =A0 =A0 <http://www.jacobs-university.de/= >
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

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

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

--047d7bdca5da6323c804faef7291-- From nobody Tue Jun 3 08:26:21 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1BFC1A02EE for ; Tue, 3 Jun 2014 08:26:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.678 X-Spam-Level: X-Spam-Status: No, score=-0.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_84=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yL9HkoOWwEox for ; Tue, 3 Jun 2014 08:26:18 -0700 (PDT) Received: from mail-qg0-f53.google.com (mail-qg0-f53.google.com [209.85.192.53]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5436E1A02E2 for ; Tue, 3 Jun 2014 08:26:18 -0700 (PDT) Received: by mail-qg0-f53.google.com with SMTP id f51so13222533qge.26 for ; Tue, 03 Jun 2014 08:26:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=VNq+rmZUajdD0ocVD01sijzHyC6urQEeNTOCKahMaHU=; b=Tr2Ykd8us9DxjXvnOc42ltWIFQBzR75upmeGZmCNnczKD9SztFJlo5UVsVdGCVwEjr uJgfFuWKkp9jDur80uOWFEMYOmxM/MdlxAnOK8GeKZV+fecitI4EH4d1TurB0+fi5Uet OaCkx74gN5hqX/5WgCQPG/uAbvfX37DIu63tvzkgRyHLyFTPKIkuodU8/Ap/sqBKjvFo PygLwi1uMP9VwxHpyvEN6tJVlbVVYyucGe11wgHHBflpj+S5o3DZmOmFfcgY4X0POpFt G9v5Ubr8GQpa32vnw06KJFsumdJZYAitXWPuhEB4mjbgRDrrGB10smWBRl8m59q6FlPJ 1bvw== X-Gm-Message-State: ALoCoQmFxdwsg8Tr0IlqOO7dS/4UeCaQbEm2Ae5m21PuLxINIuF0eI90JO2IhIPSQkS+iQRCTtt3 MIME-Version: 1.0 X-Received: by 10.224.64.132 with SMTP id e4mr61634155qai.16.1401809171956; Tue, 03 Jun 2014 08:26:11 -0700 (PDT) Received: by 10.140.104.49 with HTTP; Tue, 3 Jun 2014 08:26:11 -0700 (PDT) In-Reply-To: References: <20140602082421.GG92342@elstar.local> Date: Tue, 3 Jun 2014 08:26:11 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=001a11c20e7abceb7e04faf0216c Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/EasudFDRO14OXDU_rbm4PsbOVMw Cc: "netmod@ietf.org" Subject: Re: [netmod] undecided Y33 add 'attribute' statement X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 15:26:20 -0000 --001a11c20e7abceb7e04faf0216c Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jun 3, 2014 at 6:10 AM, Ladislav Lhotka wrote: > Juergen Schoenwaelder writes: > > > We need to decide whether this is in scope of YANG 1.1 or not. > > > > Is there a risk of attributes getting abused? How do we define > > metadata? We do not seem to want people to use attributes to model > > data. > > Yes, this has to be discussed. The secondary point of this issue is that > IF any standard (global) attributes are to be defined, YANG modules are a > good place to do it, rather than, say, using new NETCONF capabilities. > > OK to discuss, the problem to solve is poorly specified. IMO there can be no attributes in the data model. None. Zero. But a peer implementing the NETCONF or RESTCONF protocol MAY inject attributes into messages to the other peer. For RESTCONF+json a YANG module name is needed to identify the extended name part of a qualified attribute. For NC/RC+xml, an XML namespace is needed instead. If a designer is intent on using attributes in the data model, then they will abuse the attribute-stmt. IMO this is a problem for the YANG Guidelines RFC, not YANG 1.1. Such attributes could be quite useful to convert a legacy/proprietary DML to YANG. If the existing code expects a certain XML blob to perform its function, then modeling that blob correctly in YANG could be the only migration path (e.g. funding/time to rewrite all the legacy instrumentation at once may not be feasible). Lada > > Andy > > > > /js > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > > Fax: +49 421 200 3103 > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --001a11c20e7abceb7e04faf0216c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Tue, Jun 3, 2014 at 6:10 AM, Ladislav Lhotka &= lt;lhotka@nic.cz>= wrote:
Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de<= /a>> writes:

> We need to decide whether this is in scope of YANG 1.1 or not.
>
> Is there a risk of attributes getting abused? How do we define
> metadata? We do not seem to want people to use attributes to model
> data.

Yes, this has to be discussed. The secondary point of this issue is that IF= any standard (global) attributes are to be defined, YANG modules are a goo= d place to do it, rather than, say, using new NETCONF capabilities.


the other peer.

For RESTCONF+json a YANG modu= le name is needed to identify the extended
name part of a qualifi= ed attribute. For NC/RC+xml, an XML namespace is needed instead.

If a designer is intent on using attributes in the data mode= l, then they will abuse
the attribute-stmt. =A0IMO this is a prob= lem for the YANG Guidelines RFC, not YANG 1.1.
Such attributes co= uld be quite useful to convert a legacy/proprietary DML to YANG.
If the existing code expects a certain XML blob to perform its functio= n, then modeling
that blob correctly in YANG could be the only mi= gration path (e.g. funding/time to rewrite
all the legacy instrum= entation at once may not be feasible).



Lada


Andy
=A0
>
> /js
>
> --
> Juergen Schoenwaelder =A0 =A0 =A0 =A0 =A0 Jacobs University Bremen gGm= bH
> Phone: +49 421 200 3587 =A0 =A0 =A0 =A0 Campus Ring 1, 28759 Bremen, G= ermany
> Fax: =A0 +49 421 200 3103 =A0 =A0 =A0 =A0 <http://www.jacobs-university.de/= >
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

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

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

--001a11c20e7abceb7e04faf0216c-- From nobody Tue Jun 3 09:15:26 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F16F21A02CE for ; Tue, 3 Jun 2014 09:15:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.551 X-Spam-Level: X-Spam-Status: No, score=-9.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pnt7JFiufzp8 for ; Tue, 3 Jun 2014 09:15:19 -0700 (PDT) Received: from bgl-iport-4.cisco.com (bgl-iport-4.cisco.com [72.163.197.28]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A128A1A02D6 for ; Tue, 3 Jun 2014 09:15:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12615; q=dns/txt; s=iport; t=1401812113; x=1403021713; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=zwINbzSXw1FeSm1fBVWSO66KJZZN0ljAGtcYw6O0Ubo=; b=dwQtg1qLrJMvemphXBj89F+JwqU/T8TqprE/1XMO3XprvMA8UWeQ+Rq/ iX+1nWJxby26Q/VRu+Uf/GZK03PmYF39tR432fG6LdkqH5csUb2Nf8pwK Uikw+Y5lrbrDMgHcqXMR9BL3uQhFVt3WTUdo6xmvVX+EmsxfT7aIIl/4q 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqwEAFvzjVNIo8UY/2dsb2JhbABZg1lViEq6GQGBInSCJgEBBHgRLBYPCQMCAQIBRQYBDAgBARCILg3SJReJM4UmhEABA5YChAiBPoUvjEaDOjsv X-IronPort-AV: E=Sophos; i="4.98,966,1392163200"; d="scan'208,217"; a="10975498" Received: from vla196-nat.cisco.com (HELO bgl-core-3.cisco.com) ([72.163.197.24]) by bgl-iport-4.cisco.com with ESMTP; 03 Jun 2014 16:15:10 +0000 Received: from [10.60.67.91] (ams-bclaise-89110.cisco.com [10.60.67.91]) by bgl-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s53GF7et025226; Tue, 3 Jun 2014 16:15:08 GMT Message-ID: <538DF48C.6030605@cisco.com> Date: Tue, 03 Jun 2014 18:15:08 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: NETMOD Working Group , draft-ietf-netmod-snmp-cfg@tools.ietf.org References: <538D7EF7.4030202@cisco.com> In-Reply-To: <538D7EF7.4030202@cisco.com> X-Forwarded-Message-Id: <538D7EF7.4030202@cisco.com> Content-Type: multipart/alternative; boundary="------------070900050708070100080505" Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/LCPLvPOW4VJAuU45lXzKWC1uQg4 Subject: [netmod] AD review: draft-ietf-netmod-snmp-cfg-05 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 16:15:23 -0000 This is a multi-part message in MIME format. --------------070900050708070100080505 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear all, This is my AD review. Good work on a complete YANG model. It depends heavily on the knowledge of the different SNMP MIB modules: SNMP-TARGET-MIB, SNMP-NOTIFICATION-MIB, SNMP-PROXY-MIB, SNMP-COMMUNITY-MIB, etc. This is good as there is no specification redefinition. And I'm glad to find the examples in the appendix for the operators wanted "standard" SNMP configurations. My feedback: - The configuration data model in particular_targets_SNMP deployments where SNMP runs in read-only mode and NETCONF is used to configure the SNMP agent. Nevertheless, the data model has been_designed_to allow implementations that support write access both via SNMP and NETCONF in order to interwork with SNMP-managed management applications manipulating SNMP agent configuration using SNMP. The YANG data model focuses on configuration. I don't understand what you mean by "targets" or "designed to" So you made some tradeoffs in the design? Is this the way we should understand this? If which one? - At the beginning of VACM and SNMP, we faced one issue. Someone with a read-only community string could query the read-write community string. Router#sh run | i snmp snmp-server engineID local 000000090200009092827820 snmp-server group v1group v1 read includeeverything snmp-server view includeeverything internet included snmp-server community _claise _RW snmp-server user _public _v1group v1 ... "snmpwalk -v 1 _public _internet.6.3.16 | grep _claise_"... you would be surprised Basically, the trick is that we need a default view on VACM. I see http://tools.ietf.org/html/rfc3415#section-7.4 Do we need something specific in this draft to stress that issue? Editorial: - One small alignment issue below: see the port line +--rw snmp +--rw engine +--rw enabled? boolean +--rw listen* [name] | +--rw name snmp:identifier | +--rw (transport) | +--:(udp) | +--rw udp | +--rw ip inet:ip-address | +--rw port? inet:port-number +--rw version | +--rw v1? empty | +--rw v2c? empty | +--rw v3? empty +--rw engine-id? snmp:engine-id +--rw enable-authen-traps? boolean - The "/snmp/engine/version" container can be used to enable/disable the different message processing models. "message processing models": that's a specific SNMP term, well not well known to SNMP users. I would add a reference to RFC 3412 - Similarly to This submodule defines the feature "tsm". A server implements this feature if it supports the Transport Security Model (tsm) [RFC5591 ]. ... feature tsm { description "A server implements this feature if it supports the Transport Security Model for SNMP."; reference "RFC5591 : Transport Security Model for the Simple Network Management Protocol (SNMP)"; } It would be great to have references for: This submodule defines the feature "notification-filter". A server implements this feature if it supports SNMP notification filtering. ... feature notification-filter { description "A server implements this feature if it supports SNMP notification filtering."; } And for This submodule defines the feature "proxy". A server implements this feature if it can act as an SNMP Proxy. ... feature proxy { description "A server implements this feature if it can act as an SNMP Proxy"; } - augment /snmp:snmp/snmp:target { when "snmp:v1 or snmp:v2c"; leaf mms { type union { type enumeration { enum "unknown" { value 0; } } type int32 { range "484..max"; } } default "484"; reference "SNMP-COMMUNITY-MIB.snmpTargetAddrMMS"; } } mms: I thought it was a mistake: nms versus mms. I had to lookup snmpTargetAddrMMS to understand "maximum packet size" Proposal: either add a description or have a better name Regards, benoit --------------070900050708070100080505 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear all,

This is my AD review.
Good work on a complete YANG model. It depends heavily on the knowledge of the different SNMP MIB modules: SNMP-TARGET-MIB, SNMP-NOTIFICATION-MIB, SNMP-PROXY-MIB, SNMP-COMMUNITY-MIB, etc. This is good as there is no specification redefinition. And I'm glad to find the examples in the appendix for the operators wanted "standard" SNMP configurations.

My feedback:
-
   The configuration data model in particular targets SNMP deployments
   where SNMP runs in read-only mode and NETCONF is used to configure
   the SNMP agent.  Nevertheless, the data model has been designed to
   allow implementations that support write access both via SNMP and
   NETCONF in order to interwork with SNMP-managed management
   applications manipulating SNMP agent configuration using SNMP.

   The YANG data model focuses on configuration. 

I don't understand what you mean by "targets" or "designed to"
So you made some tradeoffs in the design? Is this the way we should understand this?
If which one?



- At the beginning of VACM and SNMP, we faced one issue. Someone with a read-only community string could query the read-write community string.

Router#sh run | i snmp

snmp-server engineID local 000000090200009092827820

snmp-server group v1group v1 read includeeverything

snmp-server view includeeverything internet included

snmp-server community claise RW

snmp-server user public v1group v1

...

“snmpwalk -v 1 <Router> public internet.6.3.16 | grep claise”... you would be surprised

Basically, the trick is that we need a default view on VACM. 
I see http://tools.ietf.org/html/rfc3415#section-7.4
Do we need something specific in this draft to stress that issue?


 
Editorial:
- 

One small alignment issue below: see the port line

    +--rw snmp
         +--rw engine
            +--rw enabled?               boolean
            +--rw listen* [name]
            |  +--rw name    snmp:identifier
            |  +--rw (transport)
            |     +--:(udp)
            |        +--rw udp
            |           +--rw ip      inet:ip-address
           |           +--rw port?   inet:port-number
            +--rw version
            |  +--rw v1?    empty
            |  +--rw v2c?   empty
            |  +--rw v3?    empty
            +--rw engine-id?             snmp:engine-id
            +--rw enable-authen-traps?   boolean



- 

   The "/snmp/engine/version" container can be used to enable/disable
   the different message processing models.

"message processing models": that's a specific SNMP term, well not well known to SNMP users. 
I would add a reference to RFC 3412

-
Similarly to
   This submodule defines the feature "tsm".  A server implements this
   feature if it supports the Transport Security Model (tsm) [RFC5591].

   ...

     feature tsm {
       description
         "A server implements this feature if it supports the
         Transport Security Model for SNMP.";
       reference
         "RFC5591: Transport Security Model for the
                   Simple Network Management Protocol (SNMP)";
     }

It would be great to have references for:

   This submodule defines the feature "notification-filter".  A server
   implements this feature if it supports SNMP notification filtering. 

   ...

     feature notification-filter {
       description
         "A server implements this feature if it supports SNMP
         notification filtering.";
     }

And for 

   This submodule defines the feature "proxy".  A server implements this
   feature if it can act as an SNMP Proxy.

   ...

     feature proxy {
       description
         "A server implements this feature if it can act as an
         SNMP Proxy";
     }


-

     augment /snmp:snmp/snmp:target {
       when "snmp:v1 or snmp:v2c";
       leaf mms {
         type union {
           type enumeration {
             enum "unknown" { value 0; }
           }
           type int32 {
             range "484..max";
           }
         }
         default "484";
         reference
           "SNMP-COMMUNITY-MIB.snmpTargetAddrMMS";
       }
     }


mms: I thought it was a mistake: nms versus mms.
I had to lookup snmpTargetAddrMMS to understand "maximum packet size"
Proposal: either add a description or have a better name


Regards, benoit

    

    

  


--------------070900050708070100080505--


From nobody Tue Jun  3 11:46:06 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07C371A025A for ; Tue,  3 Jun 2014 11:46:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.301
X-Spam-Level: 
X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_84=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9bocpd0TNWZm for ; Tue,  3 Jun 2014 11:46:01 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0142.outbound.protection.outlook.com [207.46.163.142]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F9AA1A01C3 for ; Tue,  3 Jun 2014 11:46:00 -0700 (PDT)
Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB460.namprd05.prod.outlook.com (10.141.72.152) with Microsoft SMTP Server (TLS) id 15.0.949.11; Tue, 3 Jun 2014 18:45:53 +0000
Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.75]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.75]) with mapi id 15.00.0949.001; Tue, 3 Jun 2014 18:45:52 +0000
From: Kent Watsen 
To: Andy Bierman , Ladislav Lhotka 
Thread-Topic: [netmod] undecided Y33 add 'attribute' statement
Thread-Index: AQHPfjxBuRebeveEPkCbNzhXgHo7cZtfXcqAgAAmCYD///S2gA==
Date: Tue, 3 Jun 2014 18:45:51 +0000
Message-ID: 
References: <20140602082421.GG92342@elstar.local>  
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.4.1.140326
x-originating-ip: [66.129.241.16]
x-microsoft-antispam: BL:0; ACTION:Default; RISK:Low; SCL:0; SPMLVL:NotSpam; PCL:0; RULEID:
x-forefront-prvs: 02318D10FB
x-forefront-antispam-report: SFV:NSPM; SFS:(428001)(51704005)(164054003)(24454002)(199002)(377454003)(189002)(92566001)(19580405001)(80022001)(76176999)(54356999)(85852003)(83322001)(81342001)(83072002)(81542001)(99396002)(19580395003)(87936001)(50986999)(99286001)(15202345003)(15975445006)(20776003)(31966008)(76482001)(74502001)(101416001)(46102001)(575784001)(64706001)(83506001)(2656002)(36756003)(66066001)(77982001)(79102001)(21056001)(92726001)(4396001)(74662001)(86362001); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR05MB460; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; 
received-spf: None (: juniper.net does not designate permitted sender hosts)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; 
Content-Type: multipart/alternative; boundary="_000_CFB38D4774786kwatsenjunipernet_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/AMnRQmt6MXZoxemEr8SdnCxJK-k
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] undecided Y33 add 'attribute' statement
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 03 Jun 2014 18:46:04 -0000

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


Can we enumerate everywhere attributes are desired?  I only know of two:
    - those defined to support "with-defaults"
    - those defined to support "conditional-enablement"

The first was added via an RFC6253 and the second being discussed as added =
via an RFC6241bis.  In neither case is having YANG support needed.  If we c=
an conclude the same for other uses, then I'd vote to close this issue.

Thanks,
Kent


From: Andy Bierman >
Date: Tuesday, June 3, 2014 at 11:26 AM
To: Ladislav Lhotka >
Cc: "netmod@ietf.org" >
Subject: Re: [netmod] undecided Y33 add 'attribute' statement




On Tue, Jun 3, 2014 at 6:10 AM, Ladislav Lhotka > wrote:
Juergen Schoenwaelder > writes:

> We need to decide whether this is in scope of YANG 1.1 or not.
>
> Is there a risk of attributes getting abused? How do we define
> metadata? We do not seem to want people to use attributes to model
> data.

Yes, this has to be discussed. The secondary point of this issue is that IF=
 any standard (global) attributes are to be defined, YANG modules are a goo=
d place to do it, rather than, say, using new NETCONF capabilities.


OK to discuss, the problem to solve is poorly specified.  IMO there can be =
no
attributes in the data model. None. Zero.  But a peer implementing
the NETCONF or RESTCONF protocol MAY inject attributes into messages to
the other peer.

For RESTCONF+json a YANG module name is needed to identify the extended
name part of a qualified attribute. For NC/RC+xml, an XML namespace is need=
ed instead.

If a designer is intent on using attributes in the data model, then they wi=
ll abuse
the attribute-stmt.  IMO this is a problem for the YANG Guidelines RFC, not=
 YANG 1.1.
Such attributes could be quite useful to convert a legacy/proprietary DML t=
o YANG.
If the existing code expects a certain XML blob to perform its function, th=
en modeling
that blob correctly in YANG could be the only migration path (e.g. funding/=
time to rewrite
all the legacy instrumentation at once may not be feasible).



Lada


Andy

>
> /js
>
> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
> Fax:   +49 421 200 3103         
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

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

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


--_000_CFB38D4774786kwatsenjunipernet_
Content-Type: text/html; charset="us-ascii"
Content-ID: <6E4BF60B80D610489484CE2B72AE88C9@namprd05.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable












Can we enumerate everywhere attributes are desired?  I only know =
of two:


    - those defined to support "with-defaults"

    - those defined to support "conditional-enablement&=
quot;







The first was added via an RFC6253 and the second being discussed as a=
dded via an RFC6241bis.  In neither case is having YANG support needed=
.  If we can conclude the same for other uses, then I'd vote to close =
this issue.







Thanks,


Kent














From: Andy Bierman <andy@yumaworks.com>

Date: Tuesday, June 3, 2014 at 11:2=
6 AM

To: Ladislav Lhotka <lhotka@nic.cz>

Cc: "netmod@ietf.org" <=
netmod@ietf.org>

Subject: Re: [netmod] undecided Y33=
 add 'attribute' statement





















On Tue, Jun 3, 2014 at 6:10 AM, Ladislav Lhotka =

<lhotka@nic.cz>=
; wrote:



Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> writes:



> We need to decide whether this is in scope of YANG 1.1 or not.

>

> Is there a risk of attributes getting abused? How do we define

> metadata? We do not seem to want people to use attributes to model

> data.



Yes, this has to be discussed. The secondary point of this issue is that IF=
 any standard (global) attributes are to be defined, YANG modules are a goo=
d place to do it, rather than, say, using new NETCONF capabilities.











OK to discuss, the problem to solve is poorly specified.  IMO the=
re can be no


attributes in the data model. None. Zero.  But a peer implementin=
g


the NETCONF or RESTCONF protocol MAY inject attributes into messages t=
o


the other peer.







For RESTCONF+json a YANG module name is needed to identify the ext=
ended


name part of a qualified attribute. For NC/RC+xml, an XML namespac=
e is needed instead.







If a designer is intent on using attributes in the data model, then th=
ey will abuse


the attribute-stmt.  IMO this is a problem for the YANG Guideline=
s RFC, not YANG 1.1.


Such attributes could be quite useful to convert a legacy/proprietary =
DML to YANG.


If the existing code expects a certain XML blob to perform its functio=
n, then modeling


that blob correctly in YANG could be the only migration path (e.g. fun=
ding/time to rewrite


all the legacy instrumentation at once may not be feasible).


















Lada











Andy


 



>

> /js

>

> --

> Juergen Schoenwaelder           Jacobs Univer=
sity Bremen gGmbH

> Phone: +49 421 200 3587         Campus Ring 1,=
 28759 Bremen, Germany

> Fax:   +49 421 200 3103         <http://www.jacobs=
-university.de/>

>

> _______________________________________________

> netmod mailing list

> netmod@ietf.org

> https://www.ietf.org/mailman/listinfo/netmod



--

Ladislav Lhotka, CZ.NIC Labs

PGP Key ID: E74E8C0C



_______________________________________________

netmod mailing list

netmod@ietf.org

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



















--_000_CFB38D4774786kwatsenjunipernet_--


From nobody Tue Jun  3 11:52:08 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D659C1A02B0 for ; Tue,  3 Jun 2014 11:52:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.702
X-Spam-Level: 
X-Spam-Status: No, score=-0.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, J_CHICKENPOX_84=0.6, RP_MATCHES_RCVD=-0.651] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SoaJ0MO2Z_uk for ; Tue,  3 Jun 2014 11:51:59 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D60211A01C3 for ; Tue,  3 Jun 2014 11:51:57 -0700 (PDT)
Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 094011412B1; Tue,  3 Jun 2014 20:51:48 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1401821509; bh=zusHzJi/lrJlhwfAriD8VZHclUeibACuCcgygogPuX0=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=hZauIRPc2BHAQyUaPcuNkHGPKqEO5/qa0I8MvCH54PTEJonQwBNlfTGIf2klRc3eC 8xOFuRF6vkEQlbxQRzvvqkXddaDpRvlZ7PDKVy39SZHV7Hal4C4ThT0ibHQ/ncLwqa lmaGQq+ywjYEb0Nz34AA+kIfeCvFW+yFQvizpeSA=
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
From: Ladislav Lhotka 
In-Reply-To: 
Date: Tue, 3 Jun 2014 20:51:41 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <82D0290D-58FF-4BA3-9BBE-17EDEAA242A4@nic.cz>
References: <20140602082421.GG92342@elstar.local>  
To: Andy Bierman 
X-Mailer: Apple Mail (2.1878.2)
X-Virus-Scanned: clamav-milter 0.97.8 at mail
X-Virus-Status: Clean
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/m38vKrQfxYBn6mZscclUCEzJqE0
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] undecided Y33 add 'attribute' statement
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 03 Jun 2014 18:52:01 -0000

On 03 Jun 2014, at 17:26, Andy Bierman  wrote:

>=20
>=20
>=20
> On Tue, Jun 3, 2014 at 6:10 AM, Ladislav Lhotka  wrote:
> Juergen Schoenwaelder  writes:
>=20
> > We need to decide whether this is in scope of YANG 1.1 or not.
> >
> > Is there a risk of attributes getting abused? How do we define
> > metadata? We do not seem to want people to use attributes to model
> > data.
>=20
> Yes, this has to be discussed. The secondary point of this issue is =
that IF any standard (global) attributes are to be defined, YANG modules =
are a good place to do it, rather than, say, using new NETCONF =
capabilities.
>=20
>=20
> OK to discuss, the problem to solve is poorly specified.  IMO there =
can be no
> attributes in the data model. None. Zero.  But a peer implementing
> the NETCONF or RESTCONF protocol MAY inject attributes into messages =
to
> the other peer.

Agreed, that=92s why the proposed solution permits the attribute =
statement only at the top level of a module, exactly as e.g. identities =
or extensions. I actually assume modules containing these attribute =
definitions would normally contain nothing else.

>=20
> For RESTCONF+json a YANG module name is needed to identify the =
extended
> name part of a qualified attribute. For NC/RC+xml, an XML namespace is =
needed instead.


Yes, that would be one of the benefits of having it in a module that =
both namespace identifiers would be automatically defined. Another =
option that=92s not mentioned in the issue text is that attribute =
definitions could contain datatypes.
=20
>=20
> If a designer is intent on using attributes in the data model, then =
they will abuse
> the attribute-stmt.  IMO this is a problem for the YANG Guidelines =
RFC, not YANG 1.1.

This issue is really about *global* attributes that can be used =
anywhere, which essentially implies they have to convey metadata and not =
plain config or state data.

Lada

> Such attributes could be quite useful to convert a legacy/proprietary =
DML to YANG.
> If the existing code expects a certain XML blob to perform its =
function, then modeling
> that blob correctly in YANG could be the only migration path (e.g. =
funding/time to rewrite
> all the legacy instrumentation at once may not be feasible).
>=20
>=20
>=20
> Lada
>=20
>=20
> Andy
> =20
> >
> > /js
> >
> > --
> > Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> > Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
> > Fax:   +49 421 200 3103         
> >
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
>=20
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>=20
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

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





From nobody Tue Jun  3 12:29:52 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D09E21A0323 for ; Tue,  3 Jun 2014 12:29:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.201
X-Spam-Level: 
X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fVGh3PqM5zbH for ; Tue,  3 Jun 2014 12:29:48 -0700 (PDT)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B4BF1A031A for ; Tue,  3 Jun 2014 12:29:48 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 72829FCB; Tue,  3 Jun 2014 21:29:40 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id l96zBM7Zrsm9; Tue,  3 Jun 2014 21:29:31 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue,  3 Jun 2014 21:29:39 +0200 (CEST)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1573720017; Tue,  3 Jun 2014 21:29:40 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id jyLoYFnKVHOK; Tue,  3 Jun 2014 21:29:39 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6A19420013; Tue,  3 Jun 2014 21:29:38 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 6FED92D50AE2; Tue,  3 Jun 2014 21:29:37 +0200 (CEST)
Date: Tue, 3 Jun 2014 21:29:36 +0200
From: Juergen Schoenwaelder 
To: Martin Bjorklund 
Message-ID: <20140603192936.GA5958@elstar.local>
Mail-Followup-To: Martin Bjorklund , andy@yumaworks.com, netmod@ietf.org
References:  <20140603.082504.1930881743030974892.mbj@tail-f.com> <20140603065010.GA4568@elstar.local> <20140603.090202.1933519174538157296.mbj@tail-f.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20140603.090202.1933519174538157296.mbj@tail-f.com>
User-Agent: Mutt/1.4.2.3i
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/ax5USvJO0GTJdfVrJ7BIAk0N6ok
Cc: netmod@ietf.org
Subject: Re: [netmod] undecided Y09 introduce optional keys
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 03 Jun 2014 19:29:51 -0000

On Tue, Jun 03, 2014 at 09:02:02AM +0200, Martin Bjorklund wrote:
> Juergen Schoenwaelder  wrote:
> > On Tue, Jun 03, 2014 at 08:25:04AM +0200, Martin Bjorklund wrote:
> > > Andy Bierman  wrote:
> > > > On Mon, Jun 2, 2014 at 1:14 AM, Juergen Schoenwaelder <
> > > > j.schoenwaelder@jacobs-university.de> wrote:
> > > > 
> > > > > We need to decide whether this is in scope of YANG 1.1 or not.
> > > > >
> > > > > The implications of this seem to be somewhat unclear. Does this only
> > > > > work if there are defaults
> > > 
> > > No, it would work also if the key leaf does not have a default.
> > 
> > But which value is then used? You seem to assume there is no value at
> > all. What would be a good example for this? A configured service with
> > an arbitrary port number seems somewhat strange to me - hence I am
> > looking for a better example.
> 
> Recently there was the discussion about vrfs.  Something like this:
> 
>   key "ip port vrf";
> 
> where vrf would be an optional key.
> 

But for this example, I would argue that there is again a default. If
you send something without a vrf leaf, the system will pick a default
vrf, no?

> 
> Another use case is for extending models.  Maybe you start with:
> 
>   key "ip port";
> 
> and later you add the vrf concept.  Adding an optional key would be a
> nice way to extend this model.  Currently we have to use an arbitrary
> key to handle this extensibilty problem.

Yes, we have to design for extensibility. While optional keys may help
in certain situations, we likely still need to design for extensibility.

You can find many discussions of the pros and cons of natural keys
vs. artificial keys on the Internet. (I personally probably lean a bit
towards the artificial keys camp since if used wisely, they can help
to decouple things and hence I find arbitrary keys probably not such a
bad idea.)

/js

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


From nobody Tue Jun  3 13:17:05 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A8491A0366 for ; Tue,  3 Jun 2014 13:16:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.201
X-Spam-Level: 
X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] autolearn=unavailable
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VBlTLfXtBInT for ; Tue,  3 Jun 2014 13:16:19 -0700 (PDT)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D91B21A035E for ; Tue,  3 Jun 2014 13:16:11 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 041D8AD6; Tue,  3 Jun 2014 22:16:05 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id zIJVyATjeUz0; Tue,  3 Jun 2014 22:15:56 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue,  3 Jun 2014 22:16:04 +0200 (CEST)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id C0B312002C; Tue,  3 Jun 2014 22:16:04 +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 kX2nhyhAuekb; Tue,  3 Jun 2014 22:16:04 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D554F20013; Tue,  3 Jun 2014 22:16:03 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 138AE2D50C49; Tue,  3 Jun 2014 22:16:02 +0200 (CEST)
Date: Tue, 3 Jun 2014 22:16:02 +0200
From: Juergen Schoenwaelder 
To: Ladislav Lhotka 
Message-ID: <20140603201602.GC6063@elstar.local>
Mail-Followup-To: Ladislav Lhotka , netmod@ietf.org
References: <20140602083330.GL92342@elstar.local> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.4.2.3i
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/cHunkVC4Pe-_o1yuSN41FiDVabw
Cc: netmod@ietf.org
Subject: Re: [netmod] undecided Y54 remove the advertisement of conformance information in NETCONF hello message
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 03 Jun 2014 20:16:39 -0000

On Tue, Jun 03, 2014 at 03:49:21PM +0200, Ladislav Lhotka wrote:
> Juergen Schoenwaelder  writes:
> 
> > We need to decide whether this is in scope of YANG 1.1 or not.
> 
> I think this should be OPENed as it is one of the parts that are really NETCONF-specific.
> 

Lets not confuse things. This issue is not about making YANG less
NETCONF specific. The question is whether this requires to the OPENed
or whether this is not already covered by Y45 (OPEN) and Y16 (OPEN).
If this is already covered, I prefer to not OPEN this another time.

/js

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


From nobody Wed Jun  4 03:33:35 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B2A21A02B2 for ; Wed,  4 Jun 2014 03:33:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.201
X-Spam-Level: 
X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J49tRT8fgu1L for ; Wed,  4 Jun 2014 03:33:31 -0700 (PDT)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A34B1A02AF for ; Wed,  4 Jun 2014 03:33:31 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 3E7BB9D6 for ; Wed,  4 Jun 2014 12:33:24 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id oAlv1RACwgtp for ; Wed,  4 Jun 2014 12:33:12 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Wed,  4 Jun 2014 12:33:23 +0200 (CEST)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2C51E20017 for ; Wed,  4 Jun 2014 12:33:24 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 1SuZxkvai_p4; Wed,  4 Jun 2014 12:33:23 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 743BA20013; Wed,  4 Jun 2014 12:33:23 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 64F312D512C5; Wed,  4 Jun 2014 12:33:23 +0200 (CEST)
Date: Wed, 4 Jun 2014 12:33:23 +0200
From: Juergen Schoenwaelder 
To: netmod@ietf.org
Message-ID: <20140604103323.GB8220@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.4.2.3i
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/y8a77rPwjpU-CM1E-7T3O8Ph69c
Subject: [netmod] virtual interim meeting reminder
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 04 Jun 2014 10:33:33 -0000

Hi,

this is a short reminder that we have a virtual interim meeting later
today (4pm-6pm central european time zone). You will find the webex
details here:

http://www.ietf.org/mail-archive/web/ietf-announce/current/msg12811.html

/js

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


From nobody Wed Jun  4 04:37:14 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3264F1A027A for ; Wed,  4 Jun 2014 04:37:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.002
X-Spam-Level: 
X-Spam-Status: No, score=-1.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.651] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id shbOXNqP_GMU for ; Wed,  4 Jun 2014 04:37:09 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 900001A01B3 for ; Wed,  4 Jun 2014 04:37:08 -0700 (PDT)
Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id D034A140587; Wed,  4 Jun 2014 13:37:00 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1401881821; bh=Pq0CjPadHV3H2nggQylgKcz4l8qauot9E9H8vCtN0yk=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=Gupm7oyvBECrdcvSnxmPx1c7EOeXo+lnneQ+J1oRbUApwrwgIKODa3lV65mOAoR8I vwmbAHtvAnGch//Hlk9puSSGmd1ByLJEaaMn4Fa41weGgUaMCPoUrK9fkLVAw95sea F4zsTlGaHnfJvs/tEv8+Lj8uEX/ippImP9xt2N7s=
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
From: Ladislav Lhotka 
In-Reply-To: <20140603201602.GC6063@elstar.local>
Date: Wed, 4 Jun 2014 13:37:01 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <249D470F-F45F-4AA0-8C80-C2F2711AD24D@nic.cz>
References: <20140602083330.GL92342@elstar.local>  <20140603201602.GC6063@elstar.local>
To: =?windows-1252?Q?J=FCrgen_Sch=F6nw=E4lder?= 
X-Mailer: Apple Mail (2.1878.2)
X-Virus-Scanned: clamav-milter 0.97.8 at mail
X-Virus-Status: Clean
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/MfCh6H1rg1nN7guFTV6IBU55UjE
Cc: netmod@ietf.org
Subject: Re: [netmod] undecided Y54 remove the advertisement of conformance information in NETCONF hello message
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 04 Jun 2014 11:37:11 -0000

On 03 Jun 2014, at 22:16, Juergen Schoenwaelder =
 wrote:

> On Tue, Jun 03, 2014 at 03:49:21PM +0200, Ladislav Lhotka wrote:
>> Juergen Schoenwaelder  writes:
>>=20
>>> We need to decide whether this is in scope of YANG 1.1 or not.
>>=20
>> I think this should be OPENed as it is one of the parts that are =
really NETCONF-specific.
>>=20
>=20
> Lets not confuse things. This issue is not about making YANG less
> NETCONF specific. The question is whether this requires to the OPENed
> or whether this is not already covered by Y45 (OPEN) and Y16 (OPEN).
> If this is already covered, I prefer to not OPEN this another time.

As I understand it, the point of Y54 is to move the specification of =
conformance declarations (whatever they are going to be) out of the YANG =
spec. IMO, this is worth considering and doesn=92t seem to be covered by =
either Y16 or Y45 yet.

Maybe a new issue subsuming all three could be created.

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

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





From nobody Wed Jun  4 23:26:02 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78E151A040C; Wed,  4 Jun 2014 23:26:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.1
X-Spam-Level: 
X-Spam-Status: No, score=-100.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, USER_IN_WHITELIST=-100] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zeMV_pf5uGof; Wed,  4 Jun 2014 23:25:59 -0700 (PDT)
Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 710291A040E; Wed,  4 Jun 2014 23:25:49 -0700 (PDT)
Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Websense Email Security Gateway with ESMTPS id 196EC12859F0; Thu,  5 Jun 2014 14:25:31 +0800 (CST)
Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id s556Mxhl044471; Thu, 5 Jun 2014 14:23:29 +0800 (GMT-8) (envelope-from feng.chong33@zte.com.cn)
In-Reply-To: <20140601152017.GI90395@elstar.local>
References: <20140601152017.GI90395@elstar.local>
To: Juergen Schoenwaelder 
MIME-Version: 1.0
X-KeepSent: 8E04E3C8:2363B269-48257CEE:00207D89; type=4; name=$KeepSent
X-Mailer: Lotus Notes Release 8.5.3 September 15, 2011
Message-ID: 
From: feng.chong33@zte.com.cn
Date: Thu, 5 Jun 2014 14:21:26 +0800
X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2014-06-05 14:23:30, Serialize complete at 2014-06-05 14:23:30
Content-Type: multipart/alternative; boundary="=_alternative 0022EBB148257CEE_="
X-MAIL: mse01.zte.com.cn s556Mxhl044471
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/V-sgqY2y5GpoNBaVhGSZ2kmr4Mg
Cc: netmod , netmod@ietf.org
Subject: Re: [netmod] strawman REJECT Y43 add exception statement
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 05 Jun 2014 06:26:01 -0000

This is a multipart message in MIME format.

--=_alternative 0022EBB148257CEE_=
Content-Type: text/plain; charset="GB2312"
Content-Transfer-Encoding: base64

SGksDQogIElmIG1hbnkgJ211c3QnIHN0YXRlbWVudHMgcmVwb3J0IHRoZSBzYW1lIGVycm9yLWFw
cC10YWcgYW5kIA0KZXJyb3ItbWVzc2FnZSwgDQp5b3UgY2FuIHVzZSAnZXhjZXB0aW9uJyBzdGF0
ZW1lbnQgdG8gZGVmaW5lIG9uZSBleGNlcHRpb24sIGFuZCB0aHJvdyB0aGlzIA0KZXhjZXB0aW9u
IGluICdtdXN0JyBzdGF0ZW1lbnRzLA0Kb3RoZXJ3aXNlLCB5b3UgbXVzdCBkZWZpbmUgdGhlIHNh
bWUgZXJyb3ItYXBwLXRhZyBhbmQgZXJyb3ItbWVzc2FnZSBtYW55IA0KdGltZXMgaW4gZXZlcnkg
J211c3QnIHN0YXRlbWVudC4NCg0KSW4gcmVhbCB3b3JsZCwgYSBzZXJ2ZXIgdXN1YWxseSBkZWZp
bmVkIG1hbnkgZ2VuZXJhbCBlcnJvciBjb2RlcywgYW5kIA0KYXBwKG1vZHVsZSkgd291bGQgdXNl
IHRoZXNlIGVycm9yIGNvZGVzIA0KdG8gcmVwb3J0IGVycm9yLiAnZXhjZXB0aW9uJyBzdGF0ZW1l
bnQgY2FuIGJlIHVzZWQgdG8gZGVmaW5lIHRoZSANCmluZm9ybWF0aW9uIG9mIHRoZXNlIGVycm9y
IGNvZGVzLg0KDQpJdCdzIGFsc28gdmVyeSB1c2VmdWwgdGhhdCBhIHJwYyBjYW4gZGVjbGFyZSBp
dHMgZXhjZXB0aW9uLiBORVRDT05GIGlzIGEgDQpwcm9ncmFtbWFibGUgaW50ZXJmYWNlLCAgaWYg
YSBycGMgZGVjbGFyZWQgaXRzIA0KZXhjZXB0aW9ucyAsIEFQUCB3aG8gdXNlIE5FVENPTkYgYXMg
cHJvZ3JhbW1hYmxlIGludGVyZmFjZSBjYW4gY2F0Y2ggdGhlc2UgDQpleGNlcHRpb24gYW5kIGRv
IHNvbWV0aGluZyBpdCB3YW50IHRvIGRvLA0Kc3VjaCBhcyBwcmludGluZyB0aGUgZXJyb3IgbWVz
c2FnZSwgY2hhbmdpbmcgdGhlIHJlcXVlc3QgYW5kIHJlc2VuZCB0byANCnNlcnZlciwgaW52b2tp
bmcgYSBub3RpZmljYXRpb24sZXRjLg0KDQoNCi9mcmFuaw0KDQoibmV0bW9kIiA8bmV0bW9kLWJv
dW5jZXNAaWV0Zi5vcmc+INC009ogMjAxNC0wNi0wMSAyMzoyMDoxNzoNCg0KPiBKdWVyZ2VuIFNj
aG9lbndhZWxkZXIgPGouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZT4gDQo+ILei
vP7IyzogICJuZXRtb2QiIDxuZXRtb2QtYm91bmNlc0BpZXRmLm9yZz4NCj4gDQo+IDIwMTQtMDYt
MDEgMjM6MjANCj4gDQo+IMfrtPC4tCC4+A0KPiBKdWVyZ2VuIFNjaG9lbndhZWxkZXIgPGouc2No
b2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZT4NCj4gDQo+IMrVvP7Iyw0KPiANCj4gbmV0
bW9kQGlldGYub3JnLCANCj4gDQo+ILOty80NCj4gDQo+INb3zOINCj4gDQo+IFtuZXRtb2RdIHN0
cmF3bWFuIFJFSkVDVCBZNDMgYWRkIGV4Y2VwdGlvbiBzdGF0ZW1lbnQNCj4gDQo+IEl0IGlzIHVu
Y2xlYXIgaG93IHZhbHVhYmxlIHJldXNhYmxlIGJ1dCBzb21ld2hhdCBleGNlcHRpb25zIGluIHJl
YWwNCj4gZGF0YSBtb2RlbHMgYXJlLg0KPiANCj4gU3BlYWsgdXAgYnkgSnVuZSAxMHRoIGlmIHlv
dSBkaXNhZ3JlZSB3aXRoIHRoaXMgc3RyYXdtYW4gcHJvcG9zYWwuDQo+IA0KPiAvanMNCj4gDQo+
IC0tIA0KPiBKdWVyZ2VuIFNjaG9lbndhZWxkZXIgICAgICAgICAgIEphY29icyBVbml2ZXJzaXR5
IEJyZW1lbiBnR21iSA0KPiBQaG9uZTogKzQ5IDQyMSAyMDAgMzU4NyAgICAgICAgIENhbXB1cyBS
aW5nIDEsIDI4NzU5IEJyZW1lbiwgR2VybWFueQ0KPiBGYXg6ICAgKzQ5IDQyMSAyMDAgMzEwMyAg
ICAgICAgIDxodHRwOi8vd3d3LmphY29icy11bml2ZXJzaXR5LmRlLz4NCj4gDQo+IF9fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IG5ldG1vZCBtYWlsaW5n
IGxpc3QNCj4gbmV0bW9kQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v
bGlzdGluZm8vbmV0bW9kDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUg
aW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgbWFpbCAoYW5kIGFueSBhdHRhY2htZW50IHRy
YW5zbWl0dGVkIGhlcmV3aXRoKSBpcyBwcml2aWxlZ2VkIGFuZCBjb25maWRlbnRpYWwgYW5kIGlz
IGludGVuZGVkIGZvciB0aGUgZXhjbHVzaXZlIHVzZSBvZiB0aGUgYWRkcmVzc2VlKHMpLiAgSWYg
eW91IGFyZSBub3QgYW4gaW50ZW5kZWQgcmVjaXBpZW50LCBhbnkgZGlzY2xvc3VyZSwgcmVwcm9k
dWN0aW9uLCBkaXN0cmlidXRpb24gb3Igb3RoZXIgZGlzc2VtaW5hdGlvbiBvciB1c2Ugb2YgdGhl
IGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiAgSWYgeW91IGhh
dmUgcmVjZWl2ZWQgdGhpcyBtYWlsIGluIGVycm9yLCBwbGVhc2UgZGVsZXRlIGl0IGFuZCBub3Rp
ZnkgdXMgaW1tZWRpYXRlbHkuDQo=

--=_alternative 0022EBB148257CEE_=
Content-Type: text/html; charset="GB2312"
Content-Transfer-Encoding: base64

PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpLDwvZm9udD4NCjxicj48Zm9udCBzaXpl
PTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7IElmIG1hbnkgJ211c3QnIHN0YXRlbWVudHMgcmVw
b3J0DQp0aGUgc2FtZSBlcnJvci1hcHAtdGFnIGFuZCBlcnJvci1tZXNzYWdlLCA8L2ZvbnQ+DQo8
YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPnlvdSBjYW4gdXNlICdleGNlcHRpb24n
IHN0YXRlbWVudCB0bw0KZGVmaW5lIG9uZSBleGNlcHRpb24sIGFuZCB0aHJvdyB0aGlzIGV4Y2Vw
dGlvbiBpbiAnbXVzdCcgc3RhdGVtZW50cyw8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9
InNhbnMtc2VyaWYiPm90aGVyd2lzZSwgeW91IG11c3QgZGVmaW5lIHRoZSBzYW1lDQplcnJvci1h
cHAtdGFnIGFuZCBlcnJvci1tZXNzYWdlIG1hbnkgdGltZXMgaW4gZXZlcnkgJ211c3QnIHN0YXRl
bWVudC48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPklu
IHJlYWwgd29ybGQsIGEgc2VydmVyIHVzdWFsbHkgZGVmaW5lZA0KbWFueSBnZW5lcmFsIGVycm9y
IGNvZGVzLCBhbmQgYXBwKG1vZHVsZSkgd291bGQgdXNlIHRoZXNlIGVycm9yIGNvZGVzIDwvZm9u
dD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+dG8gcmVwb3J0IGVycm9yLiAn
ZXhjZXB0aW9uJyBzdGF0ZW1lbnQNCmNhbiBiZSB1c2VkIHRvIGRlZmluZSB0aGUgaW5mb3JtYXRp
b24gb2YgdGhlc2UgZXJyb3IgY29kZXMuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBm
YWNlPSJzYW5zLXNlcmlmIj5JdCdzIGFsc28gdmVyeSB1c2VmdWwgdGhhdCBhIHJwYyBjYW4NCmRl
Y2xhcmUgaXRzIGV4Y2VwdGlvbi4gTkVUQ09ORiBpcyBhIHByb2dyYW1tYWJsZSBpbnRlcmZhY2Us
ICZuYnNwO2lmIGENCnJwYyBkZWNsYXJlZCBpdHMgPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBm
YWNlPSJzYW5zLXNlcmlmIj5leGNlcHRpb25zICwgQVBQIHdobyB1c2UgTkVUQ09ORiBhcw0KcHJv
Z3JhbW1hYmxlIGludGVyZmFjZSBjYW4gY2F0Y2ggdGhlc2UgZXhjZXB0aW9uIGFuZCBkbyBzb21l
dGhpbmcgaXQgd2FudA0KdG8gZG8sPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5z
LXNlcmlmIj5zdWNoIGFzIHByaW50aW5nIHRoZSBlcnJvciBtZXNzYWdlLA0KY2hhbmdpbmcgdGhl
IHJlcXVlc3QgYW5kIHJlc2VuZCB0byBzZXJ2ZXIsIGludm9raW5nIGEgbm90aWZpY2F0aW9uLGV0
Yy48L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYi
Pi9mcmFuazwvZm9udD4NCjxicj4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZxdW90O25ldG1vZCZx
dW90OyAmbHQ7bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7DQrQtNPaIDIwMTQtMDYtMDEgMjM6
MjA6MTc6PGJyPg0KPGJyPg0KJmd0OyBKdWVyZ2VuIFNjaG9lbndhZWxkZXIgJmx0O2ouc2Nob2Vu
d2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZSZndDsNCjwvZm9udD48L3R0Pg0KPGJyPjx0dD48
Zm9udCBzaXplPTI+Jmd0OyC3orz+yMs6ICZuYnNwOyZxdW90O25ldG1vZCZxdW90OyAmbHQ7bmV0
bW9kLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7PGJyPg0KJmd0OyA8L2ZvbnQ+PC90dD4NCjxicj48dHQ+
PGZvbnQgc2l6ZT0yPiZndDsgMjAxNC0wNi0wMSAyMzoyMDwvZm9udD48L3R0Pg0KPGJyPjx0dD48
Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7IMfrtPC4tCC4+Dxicj4NCiZndDsgSnVlcmdlbiBT
Y2hvZW53YWVsZGVyICZsdDtqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGUmZ3Q7
PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDxicj4NCiZndDsgytW8/sjL
PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDxicj4NCiZndDsgbmV0bW9k
QGlldGYub3JnLCA8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJyPg0K
Jmd0OyCzrcvNPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDxicj4NCiZn
dDsg1vfM4jwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7
IFtuZXRtb2RdIHN0cmF3bWFuIFJFSkVDVCBZNDMgYWRkIGV4Y2VwdGlvbiBzdGF0ZW1lbnQ8L2Zv
bnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0OyBJdCBpcyB1bmNs
ZWFyIGhvdyB2YWx1YWJsZSByZXVzYWJsZSBidXQgc29tZXdoYXQgZXhjZXB0aW9ucyBpbiByZWFs
PGJyPg0KJmd0OyBkYXRhIG1vZGVscyBhcmUuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFNwZWFrIHVw
IGJ5IEp1bmUgMTB0aCBpZiB5b3UgZGlzYWdyZWUgd2l0aCB0aGlzIHN0cmF3bWFuIHByb3Bvc2Fs
Ljxicj4NCiZndDsgPGJyPg0KJmd0OyAvanM8YnI+DQomZ3Q7IDxicj4NCiZndDsgLS0gPGJyPg0K
Jmd0OyBKdWVyZ2VuIFNjaG9lbndhZWxkZXIgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu
YnNwOyBKYWNvYnMgVW5pdmVyc2l0eQ0KQnJlbWVuIGdHbWJIPGJyPg0KJmd0OyBQaG9uZTogKzQ5
IDQyMSAyMDAgMzU4NyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgQ2FtcHVzIFJpbmcgMSwN
CjI4NzU5IEJyZW1lbiwgR2VybWFueTxicj4NCiZndDsgRmF4OiAmbmJzcDsgKzQ5IDQyMSAyMDAg
MzEwMyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJmx0OzwvZm9udD48L3R0PjxhIGhyZWY9
Imh0dHA6Ly93d3cuamFjb2JzLXVuaXZlcnNpdHkuZGUvIj48dHQ+PGZvbnQgc2l6ZT0yPmh0dHA6
Ly93d3cuamFjb2JzLXVuaXZlcnNpdHkuZGUvPC9mb250PjwvdHQ+PC9hPjx0dD48Zm9udCBzaXpl
PTI+Jmd0Ozxicj4NCiZndDsgPGJyPg0KJmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsgbmV0bW9kIG1haWxpbmcgbGlzdDxicj4NCiZn
dDsgbmV0bW9kQGlldGYub3JnPGJyPg0KJmd0OyA8L2ZvbnQ+PC90dD48YSBocmVmPWh0dHBzOi8v
d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kPjx0dD48Zm9udCBzaXplPTI+aHR0
cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2Q8L2ZvbnQ+PC90dD48L2E+
PHR0Pjxmb250IHNpemU9Mj48YnI+DQo8L2ZvbnQ+PC90dD4NCg0KPGJyPjxwcmU+PGZvbnQgY29s
b3I9ImJsdWUiPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0NClpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1h
dGlvbiBjb250YWluZWQgaW4gdGhpcyBtYWlsIChhbmQgYW55IGF0dGFjaG1lbnQgdHJhbnNtaXR0
ZWQgaGVyZXdpdGgpIGlzIHByaXZpbGVnZWQgYW5kIGNvbmZpZGVudGlhbCBhbmQgaXMgaW50ZW5k
ZWQgZm9yIHRoZSBleGNsdXNpdmUgdXNlIG9mIHRoZSBhZGRyZXNzZWUocykuICBJZiB5b3UgYXJl
IG5vdCBhbiBpbnRlbmRlZCByZWNpcGllbnQsIGFueSBkaXNjbG9zdXJlLCByZXByb2R1Y3Rpb24s
IGRpc3RyaWJ1dGlvbiBvciBvdGhlciBkaXNzZW1pbmF0aW9uIG9yIHVzZSBvZiB0aGUgaW5mb3Jt
YXRpb24gY29udGFpbmVkIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuICBJZiB5b3UgaGF2ZSByZWNl
aXZlZCB0aGlzIG1haWwgaW4gZXJyb3IsIHBsZWFzZSBkZWxldGUgaXQgYW5kIG5vdGlmeSB1cyBp
bW1lZGlhdGVseS4NCg0KPC9mb250PjwvcHJlPjxicj4NCg==

--=_alternative 0022EBB148257CEE_=--


From nobody Thu Jun  5 01:33:33 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B92B81A00F8 for ; Thu,  5 Jun 2014 01:33:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.201
X-Spam-Level: 
X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nMfKWyRuje3s for ; Thu,  5 Jun 2014 01:33:29 -0700 (PDT)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D25961A042E for ; Thu,  5 Jun 2014 01:33:25 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id B364E6F7; Thu,  5 Jun 2014 10:33:17 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id l-KsJttUlMh5; Thu,  5 Jun 2014 10:33:01 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu,  5 Jun 2014 10:33:17 +0200 (CEST)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6C3582002C; Thu,  5 Jun 2014 10:33:17 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id YP1IujlkDEeE; Thu,  5 Jun 2014 10:33:16 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 62B8920013; Thu,  5 Jun 2014 10:33:15 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 233262D51EC8; Thu,  5 Jun 2014 10:33:13 +0200 (CEST)
Date: Thu, 5 Jun 2014 10:33:13 +0200
From: Juergen Schoenwaelder 
To: feng.chong33@zte.com.cn
Message-ID: <20140605083313.GA10945@elstar.local>
Mail-Followup-To: feng.chong33@zte.com.cn, netmod@ietf.org
References: <20140601152017.GI90395@elstar.local> 
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 
User-Agent: Mutt/1.4.2.3i
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/Tz8M25wE6JatKysoM_BA0ov4_Yo
Cc: netmod@ietf.org
Subject: Re: [netmod] strawman REJECT Y43 add exception statement
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 05 Jun 2014 08:33:31 -0000

Hi,

I think the proposal is well described and understood.

The question is more whether this is a proposal that meets the YANG
1.1 goals or whether this is perhaps a proposal to consider for YANG
2.0. The WG charter clearly says that we are producing "a maintenance
release of the core YANG specification" and hence we should stay away
from adding new features unless we have strong evidence that there is
a real shortcoming that has surfaced in practice.

So it would be useful to hear from those who have experience with lots
of data models to what extend the lack of reusable exceptions has
caused them serious trouble.

The initial assessment that led to the strawman proposal was that this
is more a YANG 2.0 feature request anot not something required to
address in YANG 1.1.

/js

On Thu, Jun 05, 2014 at 02:21:26PM +0800, feng.chong33@zte.com.cn wrote:
> Hi,
>   If many 'must' statements report the same error-app-tag and 
> error-message, 
> you can use 'exception' statement to define one exception, and throw this 
> exception in 'must' statements,
> otherwise, you must define the same error-app-tag and error-message many 
> times in every 'must' statement.
> 
> In real world, a server usually defined many general error codes, and 
> app(module) would use these error codes 
> to report error. 'exception' statement can be used to define the 
> information of these error codes.
> 
> It's also very useful that a rpc can declare its exception. NETCONF is a 
> programmable interface,  if a rpc declared its 
> exceptions , APP who use NETCONF as programmable interface can catch these 
> exception and do something it want to do,
> such as printing the error message, changing the request and resend to 
> server, invoking a notification,etc.
> 
> 
> /frank
> 
> "netmod"  写于 2014-06-01 23:20:17:
> 
> > Juergen Schoenwaelder  
> > å‘件人:  "netmod" 
> > 
> > 2014-06-01 23:20
> > 
> > è¯·ç­”å¤ ç»™
> > Juergen Schoenwaelder 
> > 
> > 收件人
> > 
> > netmod@ietf.org, 
> > 
> > 抄é€
> > 
> > 主题
> > 
> > [netmod] strawman REJECT Y43 add exception statement
> > 
> > It is unclear how valuable reusable but somewhat exceptions in real
> > data models are.
> > 
> > Speak up by June 10th if you disagree with this strawman proposal.
> > 
> > /js
> > 
> > -- 
> > Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> > Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
> > Fax:   +49 421 200 3103         
> > 
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> 
> --------------------------------------------------------
> ZTE Information Security Notice: The information contained in this mail (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s).  If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited.  If you have received this mail in error, please delete it and notify us immediately.

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


From nobody Thu Jun  5 01:59:34 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4C7A1A0430; Thu,  5 Jun 2014 01:59:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id do2m76FDx63N; Thu,  5 Jun 2014 01:59:29 -0700 (PDT)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A0511A0407; Thu,  5 Jun 2014 01:59:29 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 1FC04540749; Thu,  5 Jun 2014 10:59:21 +0200 (CEST)
Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wDkJItHme6-7; Thu,  5 Jun 2014 10:59:16 +0200 (CEST)
Received: from localhost (unknown [172.29.2.201]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 717A55403EF; Thu,  5 Jun 2014 10:59:11 +0200 (CEST)
From: Ladislav Lhotka 
To: feng.chong33@zte.com.cn, Juergen Schoenwaelder 
In-Reply-To: 
References: <20140601152017.GI90395@elstar.local> 
User-Agent: Notmuch/0.18 (http://notmuchmail.org) Emacs/24.3.50.2 (x86_64-apple-darwin13.0.0)
Date: Thu, 05 Jun 2014 10:59:12 +0200
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/98A0b8eEFoBQLb7ImRVUfuz7hMU
Cc: netmod , netmod@ietf.org
Subject: Re: [netmod] strawman REJECT Y43 add exception statement
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 05 Jun 2014 08:59:32 -0000

feng.chong33@zte.com.cn writes:

> Hi,
>   If many 'must' statements report the same error-app-tag and=20
> error-message,

If a data model has a node that's used in many places with the same role an=
d semantics, it should define a grouping for it. If this node has a 'must' =
statement, it is defined only once.

Otherwise, each 'must' statement corresponds to a specific context in the d=
ata model, so I guess at least the error-message should be specific as well=
.=20=20
=20
> you can use 'exception' statement to define one exception, and throw this=
=20
> exception in 'must' statements,
> otherwise, you must define the same error-app-tag and error-message many=
=20
> times in every 'must' statement.
>
> In real world, a server usually defined many general error codes, and=20
> app(module) would use these error codes=20
> to report error. 'exception' statement can be used to define the=20
> information of these error codes.
>
> It's also very useful that a rpc can declare its exception. NETCONF is a
> programmable interface,  if a rpc declared its=20
> exceptions , APP who use NETCONF as programmable interface can catch thes=
e=20
> exception and do something it want to do,
> such as printing the error message, changing the request and resend to=20
> server, invoking a notification,etc.

This is quite different from the above case. IMO, exceptions as they are us=
ed in programming languages should be dealt with in implementations, not in=
 YANG. A client application receiving an error message from the server may =
raise an exception or handle the error by other means.

Lada

>
>
> /frank
>
> "netmod"  =E5=86=99=E4=BA=8E 2014-06-01 23:20:17:
>
>> Juergen Schoenwaelder =20
>> =E5=8F=91=E4=BB=B6=E4=BA=BA:  "netmod" 
>>=20
>> 2014-06-01 23:20
>>=20
>> =E8=AF=B7=E7=AD=94=E5=A4=8D =E7=BB=99
>> Juergen Schoenwaelder 
>>=20
>> =E6=94=B6=E4=BB=B6=E4=BA=BA
>>=20
>> netmod@ietf.org,=20
>>=20
>> =E6=8A=84=E9=80=81
>>=20
>> =E4=B8=BB=E9=A2=98
>>=20
>> [netmod] strawman REJECT Y43 add exception statement
>>=20
>> It is unclear how valuable reusable but somewhat exceptions in real
>> data models are.
>>=20
>> Speak up by June 10th if you disagree with this strawman proposal.
>>=20
>> /js
>>=20
>> --=20
>> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
>> Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
>> Fax:   +49 421 200 3103         
>>=20
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>
> --------------------------------------------------------
> ZTE Information Security Notice: The information contained in this mail (=
and any attachment transmitted herewith) is privileged and confidential and=
 is intended for the exclusive use of the addressee(s).  If you are not an =
intended recipient, any disclosure, reproduction, distribution or other dis=
semination or use of the information contained is strictly prohibited.  If =
you have received this mail in error, please delete it and notify us immedi=
ately.
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

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


From nobody Thu Jun  5 02:21:26 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C755A1A0420; Thu,  5 Jun 2014 02:21:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.1
X-Spam-Level: 
X-Spam-Status: No, score=-100.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, USER_IN_WHITELIST=-100] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dumXRuBiX8kP; Thu,  5 Jun 2014 02:21:21 -0700 (PDT)
Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 2EB951A03BE; Thu,  5 Jun 2014 02:21:21 -0700 (PDT)
Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Websense Email Security Gateway with ESMTPS id D7D671287ADF; Thu,  5 Jun 2014 17:21:00 +0800 (CST)
Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id s559L4el096410; Thu, 5 Jun 2014 17:21:04 +0800 (GMT-8) (envelope-from feng.chong33@zte.com.cn)
In-Reply-To: 
References: <20140601152017.GI90395@elstar.local>  
To: Ladislav Lhotka 
MIME-Version: 1.0
X-KeepSent: D01B72AD:DD92F5FC-48257CEE:00329DF9; type=4; name=$KeepSent
X-Mailer: Lotus Notes Release 8.5.3 September 15, 2011
Message-ID: 
From: feng.chong33@zte.com.cn
Date: Thu, 5 Jun 2014 17:21:04 +0800
X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2014-06-05 17:21:05, Serialize complete at 2014-06-05 17:21:05
Content-Type: multipart/alternative; boundary="=_alternative 00335DED48257CEE_="
X-MAIL: mse01.zte.com.cn s559L4el096410
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/OKWHMQMnf_BBkw8gpgA9Hr-B1Uc
Cc: netmod , netmod@ietf.org
Subject: Re: [netmod] strawman REJECT Y43 add exception statement
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 05 Jun 2014 09:21:23 -0000

This is a multipart message in MIME format.

--=_alternative 00335DED48257CEE_=
Content-Type: text/plain; charset="GB2312"
Content-Transfer-Encoding: base64

L2ZyYW5rDQoNCkxhZGlzbGF2IExob3RrYSA8bGhvdGthQG5pYy5jej4g0LTT2iAyMDE0LTA2LTA1
IDE2OjU5OjEyOg0KDQo+IExhZGlzbGF2IExob3RrYSA8bGhvdGthQG5pYy5jej4gDQo+IDIwMTQt
MDYtMDUgMTY6NTkNCj4gDQo+IMrVvP7Iyw0KPiANCj4gZmVuZy5jaG9uZzMzQHp0ZS5jb20uY24s
IEp1ZXJnZW4gU2Nob2Vud2FlbGRlciANCj4gPGouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVy
c2l0eS5kZT4sIA0KPiANCj4gs63LzQ0KPiANCj4gbmV0bW9kIDxuZXRtb2QtYm91bmNlc0BpZXRm
Lm9yZz4sIG5ldG1vZEBpZXRmLm9yZw0KPiANCj4g1vfM4g0KPiANCj4gUmU6IFtuZXRtb2RdIHN0
cmF3bWFuIFJFSkVDVCBZNDMgYWRkIGV4Y2VwdGlvbiBzdGF0ZW1lbnQNCj4gDQo+IGZlbmcuY2hv
bmczM0B6dGUuY29tLmNuIHdyaXRlczoNCj4gDQo+ID4gSGksDQo+ID4gICBJZiBtYW55ICdtdXN0
JyBzdGF0ZW1lbnRzIHJlcG9ydCB0aGUgc2FtZSBlcnJvci1hcHAtdGFnIGFuZCANCj4gPiBlcnJv
ci1tZXNzYWdlLA0KPiANCj4gSWYgYSBkYXRhIG1vZGVsIGhhcyBhIG5vZGUgdGhhdCdzIHVzZWQg
aW4gbWFueSBwbGFjZXMgd2l0aCB0aGUgc2FtZSANCj4gcm9sZSBhbmQgc2VtYW50aWNzLCBpdCBz
aG91bGQgZGVmaW5lIGEgZ3JvdXBpbmcgZm9yIGl0LiBJZiB0aGlzIG5vZGUNCj4gaGFzIGEgJ211
c3QnIHN0YXRlbWVudCwgaXQgaXMgZGVmaW5lZCBvbmx5IG9uY2UuDQo+IA0KPiBPdGhlcndpc2Us
IGVhY2ggJ211c3QnIHN0YXRlbWVudCBjb3JyZXNwb25kcyB0byBhIHNwZWNpZmljIGNvbnRleHQg
DQo+IGluIHRoZSBkYXRhIG1vZGVsLCBzbyBJIGd1ZXNzIGF0IGxlYXN0IHRoZSBlcnJvci1tZXNz
YWdlIHNob3VsZCBiZSANCj4gc3BlY2lmaWMgYXMgd2VsbC4gDQo+IA0KDQpJbiBteSBwcmFjdGlj
ZSwgb3VyIHN5c3RlbShtYW5hZ2VtZW50IGluZm9ybWF0aW9uIG1vZGVsKSBoYXZlIGRlZmluZWQg
bWFueSANCmdlbmVyYWwgDQplcnJvciBjb2Rlcywgd2hlbiB0aGUgY29uc3RyYWludCBpcyBpbnZh
bGlkLCBtYW55IG5vZGVzIHdvdWxkIHJlcG9ydCANCmdlbmVyYWwgZXJyb3IgY29kZSANCnVubGVz
cyBpdCdzIGhhcmQgdG8gZGVzY3JpYmUgdGhlIGVycm9yIHVzaW5nIGdlbmVyYWwgZXJyb3IgY29k
ZS4NCg0KPiA+IHlvdSBjYW4gdXNlICdleGNlcHRpb24nIHN0YXRlbWVudCB0byBkZWZpbmUgb25l
IGV4Y2VwdGlvbiwgYW5kIHRocm93IA0KdGhpcyANCj4gPiBleGNlcHRpb24gaW4gJ211c3QnIHN0
YXRlbWVudHMsDQo+ID4gb3RoZXJ3aXNlLCB5b3UgbXVzdCBkZWZpbmUgdGhlIHNhbWUgZXJyb3It
YXBwLXRhZyBhbmQgZXJyb3ItbWVzc2FnZSANCm1hbnkgDQo+ID4gdGltZXMgaW4gZXZlcnkgJ211
c3QnIHN0YXRlbWVudC4NCj4gPg0KPiA+IEluIHJlYWwgd29ybGQsIGEgc2VydmVyIHVzdWFsbHkg
ZGVmaW5lZCBtYW55IGdlbmVyYWwgZXJyb3IgY29kZXMsIGFuZCANCj4gPiBhcHAobW9kdWxlKSB3
b3VsZCB1c2UgdGhlc2UgZXJyb3IgY29kZXMgDQo+ID4gdG8gcmVwb3J0IGVycm9yLiAnZXhjZXB0
aW9uJyBzdGF0ZW1lbnQgY2FuIGJlIHVzZWQgdG8gZGVmaW5lIHRoZSANCj4gPiBpbmZvcm1hdGlv
biBvZiB0aGVzZSBlcnJvciBjb2Rlcy4NCj4gPg0KPiA+IEl0J3MgYWxzbyB2ZXJ5IHVzZWZ1bCB0
aGF0IGEgcnBjIGNhbiBkZWNsYXJlIGl0cyBleGNlcHRpb24uIE5FVENPTkYgaXMgDQphDQo+ID4g
cHJvZ3JhbW1hYmxlIGludGVyZmFjZSwgIGlmIGEgcnBjIGRlY2xhcmVkIGl0cyANCj4gPiBleGNl
cHRpb25zICwgQVBQIHdobyB1c2UgTkVUQ09ORiBhcyBwcm9ncmFtbWFibGUgaW50ZXJmYWNlIGNh
biBjYXRjaCANCnRoZXNlIA0KPiA+IGV4Y2VwdGlvbiBhbmQgZG8gc29tZXRoaW5nIGl0IHdhbnQg
dG8gZG8sDQo+ID4gc3VjaCBhcyBwcmludGluZyB0aGUgZXJyb3IgbWVzc2FnZSwgY2hhbmdpbmcg
dGhlIHJlcXVlc3QgYW5kIHJlc2VuZCB0byANCg0KPiA+IHNlcnZlciwgaW52b2tpbmcgYSBub3Rp
ZmljYXRpb24sZXRjLg0KPiANCj4gVGhpcyBpcyBxdWl0ZSBkaWZmZXJlbnQgZnJvbSB0aGUgYWJv
dmUgY2FzZS4gSU1PLCBleGNlcHRpb25zIGFzIHRoZXkNCj4gYXJlIHVzZWQgaW4gcHJvZ3JhbW1p
bmcgbGFuZ3VhZ2VzIHNob3VsZCBiZSBkZWFsdCB3aXRoIGluIA0KPiBpbXBsZW1lbnRhdGlvbnMs
IG5vdCBpbiBZQU5HLiBBIGNsaWVudCBhcHBsaWNhdGlvbiByZWNlaXZpbmcgYW4gDQo+IGVycm9y
IG1lc3NhZ2UgZnJvbSB0aGUgc2VydmVyIG1heSByYWlzZSBhbiBleGNlcHRpb24gb3IgaGFuZGxl
IHRoZSANCj4gZXJyb3IgYnkgb3RoZXIgbWVhbnMuDQo+IA0KPiBMYWRhDQo+IA0KDQpIYW5kbGlu
ZyBleGNlcHRpb25zIGlzIGltcGxlbWVudHRhdGlvbidzIGpvYiwgSSBvbmx5IHJlcXVpcmUgWUFO
RyB0byANCmRlY2xhcmUgZXhjZXB0aW9ucy4NCg0KPiA+DQo+ID4NCj4gPiAvZnJhbmsNCj4gPg0K
PiA+ICJuZXRtb2QiIDxuZXRtb2QtYm91bmNlc0BpZXRmLm9yZz4g0LTT2iAyMDE0LTA2LTAxIDIz
OjIwOjE3Og0KPiA+DQo+ID4+IEp1ZXJnZW4gU2Nob2Vud2FlbGRlciA8ai5zY2hvZW53YWVsZGVy
QGphY29icy11bml2ZXJzaXR5LmRlPiANCj4gPj4gt6K8/sjLOiAgIm5ldG1vZCIgPG5ldG1vZC1i
b3VuY2VzQGlldGYub3JnPg0KPiA+PiANCj4gPj4gMjAxNC0wNi0wMSAyMzoyMA0KPiA+PiANCj4g
Pj4gx+u08Li0ILj4DQo+ID4+IEp1ZXJnZW4gU2Nob2Vud2FlbGRlciA8ai5zY2hvZW53YWVsZGVy
QGphY29icy11bml2ZXJzaXR5LmRlPg0KPiA+PiANCj4gPj4gytW8/sjLDQo+ID4+IA0KPiA+PiBu
ZXRtb2RAaWV0Zi5vcmcsIA0KPiA+PiANCj4gPj4gs63LzQ0KPiA+PiANCj4gPj4g1vfM4g0KPiA+
PiANCj4gPj4gW25ldG1vZF0gc3RyYXdtYW4gUkVKRUNUIFk0MyBhZGQgZXhjZXB0aW9uIHN0YXRl
bWVudA0KPiA+PiANCj4gPj4gSXQgaXMgdW5jbGVhciBob3cgdmFsdWFibGUgcmV1c2FibGUgYnV0
IHNvbWV3aGF0IGV4Y2VwdGlvbnMgaW4gcmVhbA0KPiA+PiBkYXRhIG1vZGVscyBhcmUuDQo+ID4+
IA0KPiA+PiBTcGVhayB1cCBieSBKdW5lIDEwdGggaWYgeW91IGRpc2FncmVlIHdpdGggdGhpcyBz
dHJhd21hbiBwcm9wb3NhbC4NCj4gPj4gDQo+ID4+IC9qcw0KPiA+PiANCj4gPj4gLS0gDQo+ID4+
IEp1ZXJnZW4gU2Nob2Vud2FlbGRlciAgICAgICAgICAgSmFjb2JzIFVuaXZlcnNpdHkgQnJlbWVu
IGdHbWJIDQo+ID4+IFBob25lOiArNDkgNDIxIDIwMCAzNTg3ICAgICAgICAgQ2FtcHVzIFJpbmcg
MSwgMjg3NTkgQnJlbWVuLCBHZXJtYW55DQo+ID4+IEZheDogICArNDkgNDIxIDIwMCAzMTAzICAg
ICAgICAgPGh0dHA6Ly93d3cuamFjb2JzLXVuaXZlcnNpdHkuZGUvPg0KPiA+PiANCj4gPj4gX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPj4gbmV0bW9k
IG1haWxpbmcgbGlzdA0KPiA+PiBuZXRtb2RAaWV0Zi5vcmcNCj4gPj4gaHR0cHM6Ly93d3cuaWV0
Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCj4gPg0KPiA+IC0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4gWlRFIEluZm9ybWF0
aW9uIFNlY3VyaXR5IE5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzDQo+
IG1haWwgKGFuZCBhbnkgYXR0YWNobWVudCB0cmFuc21pdHRlZCBoZXJld2l0aCkgaXMgcHJpdmls
ZWdlZCBhbmQgDQo+IGNvbmZpZGVudGlhbCBhbmQgaXMgaW50ZW5kZWQgZm9yIHRoZSBleGNsdXNp
dmUgdXNlIG9mIHRoZSBhZGRyZXNzZWUNCj4gKHMpLiAgSWYgeW91IGFyZSBub3QgYW4gaW50ZW5k
ZWQgcmVjaXBpZW50LCBhbnkgZGlzY2xvc3VyZSwgDQo+IHJlcHJvZHVjdGlvbiwgZGlzdHJpYnV0
aW9uIG9yIG90aGVyIGRpc3NlbWluYXRpb24gb3IgdXNlIG9mIHRoZSANCj4gaW5mb3JtYXRpb24g
Y29udGFpbmVkIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuICBJZiB5b3UgaGF2ZSByZWNlaXZlZCAN
Cj4gdGhpcyBtYWlsIGluIGVycm9yLCBwbGVhc2UgZGVsZXRlIGl0IGFuZCBub3RpZnkgdXMgaW1t
ZWRpYXRlbHkuDQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX18NCj4gPiBuZXRtb2QgbWFpbGluZyBsaXN0DQo+ID4gbmV0bW9kQGlldGYub3JnDQo+ID4g
aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCj4gDQo+IC0tIA0K
PiBMYWRpc2xhdiBMaG90a2EsIENaLk5JQyBMYWJzDQo+IFBHUCBLZXkgSUQ6IEU3NEU4QzBDDQoN
Ci0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
DQpaVEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFp
bmVkIGluIHRoaXMgbWFpbCAoYW5kIGFueSBhdHRhY2htZW50IHRyYW5zbWl0dGVkIGhlcmV3aXRo
KSBpcyBwcml2aWxlZ2VkIGFuZCBjb25maWRlbnRpYWwgYW5kIGlzIGludGVuZGVkIGZvciB0aGUg
ZXhjbHVzaXZlIHVzZSBvZiB0aGUgYWRkcmVzc2VlKHMpLiAgSWYgeW91IGFyZSBub3QgYW4gaW50
ZW5kZWQgcmVjaXBpZW50LCBhbnkgZGlzY2xvc3VyZSwgcmVwcm9kdWN0aW9uLCBkaXN0cmlidXRp
b24gb3Igb3RoZXIgZGlzc2VtaW5hdGlvbiBvciB1c2Ugb2YgdGhlIGluZm9ybWF0aW9uIGNvbnRh
aW5lZCBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiAgSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBt
YWlsIGluIGVycm9yLCBwbGVhc2UgZGVsZXRlIGl0IGFuZCBub3RpZnkgdXMgaW1tZWRpYXRlbHku
DQo=

--=_alternative 00335DED48257CEE_=
Content-Type: text/html; charset="GB2312"
Content-Transfer-Encoding: base64

PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPi9mcmFuazwvZm9udD4NCjxicj4NCjxicj48
dHQ+PGZvbnQgc2l6ZT0yPkxhZGlzbGF2IExob3RrYSAmbHQ7bGhvdGthQG5pYy5jeiZndDsg0LTT
2iAyMDE0LTA2LTA1DQoxNjo1OToxMjo8YnI+DQo8YnI+DQomZ3Q7IExhZGlzbGF2IExob3RrYSAm
bHQ7bGhvdGthQG5pYy5jeiZndDsgPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4m
Z3Q7IDIwMTQtMDYtMDUgMTY6NTk8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZn
dDsgPGJyPg0KJmd0OyDK1bz+yMs8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZn
dDsgPGJyPg0KJmd0OyBmZW5nLmNob25nMzNAenRlLmNvbS5jbiwgSnVlcmdlbiBTY2hvZW53YWVs
ZGVyIDxicj4NCiZndDsgJmx0O2ouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZSZn
dDssIDwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7ILOt
y808L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0OyBuZXRt
b2QgJmx0O25ldG1vZC1ib3VuY2VzQGlldGYub3JnJmd0OywgbmV0bW9kQGlldGYub3JnPC9mb250
PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDxicj4NCiZndDsg1vfM4jwvZm9udD48
L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7IFJlOiBbbmV0bW9kXSBz
dHJhd21hbiBSRUpFQ1QgWTQzIGFkZCBleGNlcHRpb24gc3RhdGVtZW50PC9mb250PjwvdHQ+DQo8
YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDxicj4NCiZndDsgZmVuZy5jaG9uZzMzQHp0ZS5jb20u
Y24gd3JpdGVzOjxicj4NCiZndDsgPGJyPg0KJmd0OyAmZ3Q7IEhpLDxicj4NCiZndDsgJmd0OyAm
bmJzcDsgSWYgbWFueSAnbXVzdCcgc3RhdGVtZW50cyByZXBvcnQgdGhlIHNhbWUgZXJyb3ItYXBw
LXRhZw0KYW5kIDxicj4NCiZndDsgJmd0OyBlcnJvci1tZXNzYWdlLDxicj4NCiZndDsgPGJyPg0K
Jmd0OyBJZiBhIGRhdGEgbW9kZWwgaGFzIGEgbm9kZSB0aGF0J3MgdXNlZCBpbiBtYW55IHBsYWNl
cyB3aXRoIHRoZSBzYW1lDQo8YnI+DQomZ3Q7IHJvbGUgYW5kIHNlbWFudGljcywgaXQgc2hvdWxk
IGRlZmluZSBhIGdyb3VwaW5nIGZvciBpdC4gSWYgdGhpcyBub2RlPGJyPg0KJmd0OyBoYXMgYSAn
bXVzdCcgc3RhdGVtZW50LCBpdCBpcyBkZWZpbmVkIG9ubHkgb25jZS48YnI+DQomZ3Q7IDxicj4N
CiZndDsgT3RoZXJ3aXNlLCBlYWNoICdtdXN0JyBzdGF0ZW1lbnQgY29ycmVzcG9uZHMgdG8gYSBz
cGVjaWZpYyBjb250ZXh0DQo8YnI+DQomZ3Q7IGluIHRoZSBkYXRhIG1vZGVsLCBzbyBJIGd1ZXNz
IGF0IGxlYXN0IHRoZSBlcnJvci1tZXNzYWdlIHNob3VsZCBiZQ0KPGJyPg0KJmd0OyBzcGVjaWZp
YyBhcyB3ZWxsLiAmbmJzcDs8YnI+DQomZ3Q7ICZuYnNwOzwvZm9udD48L3R0Pg0KPGJyPg0KPGJy
Pjx0dD48Zm9udCBzaXplPTI+SW4gbXkgcHJhY3RpY2UsIG91ciBzeXN0ZW0obWFuYWdlbWVudCBp
bmZvcm1hdGlvbg0KbW9kZWwpIGhhdmUgZGVmaW5lZCBtYW55IGdlbmVyYWwgPC9mb250PjwvdHQ+
DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5lcnJvciBjb2Rlcywgd2hlbiB0aGUgY29uc3RyYWludCBp
cyBpbnZhbGlkLCBtYW55DQpub2RlcyB3b3VsZCByZXBvcnQgZ2VuZXJhbCBlcnJvciBjb2RlIDwv
Zm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+dW5sZXNzIGl0J3MgaGFyZCB0byBkZXNj
cmliZSB0aGUgZXJyb3IgdXNpbmcgZ2VuZXJhbA0KZXJyb3IgY29kZS48L2ZvbnQ+PC90dD4NCjxi
cj48dHQ+PGZvbnQgc2l6ZT0yPjxicj4NCiZndDsgJmd0OyB5b3UgY2FuIHVzZSAnZXhjZXB0aW9u
JyBzdGF0ZW1lbnQgdG8gZGVmaW5lIG9uZSBleGNlcHRpb24sIGFuZA0KdGhyb3cgdGhpcyA8YnI+
DQomZ3Q7ICZndDsgZXhjZXB0aW9uIGluICdtdXN0JyBzdGF0ZW1lbnRzLDxicj4NCiZndDsgJmd0
OyBvdGhlcndpc2UsIHlvdSBtdXN0IGRlZmluZSB0aGUgc2FtZSBlcnJvci1hcHAtdGFnIGFuZCBl
cnJvci1tZXNzYWdlDQptYW55IDxicj4NCiZndDsgJmd0OyB0aW1lcyBpbiBldmVyeSAnbXVzdCcg
c3RhdGVtZW50Ljxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBJbiByZWFsIHdvcmxkLCBh
IHNlcnZlciB1c3VhbGx5IGRlZmluZWQgbWFueSBnZW5lcmFsIGVycm9yIGNvZGVzLA0KYW5kIDxi
cj4NCiZndDsgJmd0OyBhcHAobW9kdWxlKSB3b3VsZCB1c2UgdGhlc2UgZXJyb3IgY29kZXMgPGJy
Pg0KJmd0OyAmZ3Q7IHRvIHJlcG9ydCBlcnJvci4gJ2V4Y2VwdGlvbicgc3RhdGVtZW50IGNhbiBi
ZSB1c2VkIHRvIGRlZmluZQ0KdGhlIDxicj4NCiZndDsgJmd0OyBpbmZvcm1hdGlvbiBvZiB0aGVz
ZSBlcnJvciBjb2Rlcy48YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgSXQncyBhbHNvIHZl
cnkgdXNlZnVsIHRoYXQgYSBycGMgY2FuIGRlY2xhcmUgaXRzIGV4Y2VwdGlvbi4gTkVUQ09ORg0K
aXMgYTxicj4NCiZndDsgJmd0OyBwcm9ncmFtbWFibGUgaW50ZXJmYWNlLCAmbmJzcDtpZiBhIHJw
YyBkZWNsYXJlZCBpdHMgPGJyPg0KJmd0OyAmZ3Q7IGV4Y2VwdGlvbnMgLCBBUFAgd2hvIHVzZSBO
RVRDT05GIGFzIHByb2dyYW1tYWJsZSBpbnRlcmZhY2UgY2FuDQpjYXRjaCB0aGVzZSA8YnI+DQom
Z3Q7ICZndDsgZXhjZXB0aW9uIGFuZCBkbyBzb21ldGhpbmcgaXQgd2FudCB0byBkbyw8YnI+DQom
Z3Q7ICZndDsgc3VjaCBhcyBwcmludGluZyB0aGUgZXJyb3IgbWVzc2FnZSwgY2hhbmdpbmcgdGhl
IHJlcXVlc3QgYW5kDQpyZXNlbmQgdG8gPGJyPg0KJmd0OyAmZ3Q7IHNlcnZlciwgaW52b2tpbmcg
YSBub3RpZmljYXRpb24sZXRjLjxicj4NCiZndDsgPGJyPg0KJmd0OyBUaGlzIGlzIHF1aXRlIGRp
ZmZlcmVudCBmcm9tIHRoZSBhYm92ZSBjYXNlLiBJTU8sIGV4Y2VwdGlvbnMgYXMgdGhleTxicj4N
CiZndDsgYXJlIHVzZWQgaW4gcHJvZ3JhbW1pbmcgbGFuZ3VhZ2VzIHNob3VsZCBiZSBkZWFsdCB3
aXRoIGluIDxicj4NCiZndDsgaW1wbGVtZW50YXRpb25zLCBub3QgaW4gWUFORy4gQSBjbGllbnQg
YXBwbGljYXRpb24gcmVjZWl2aW5nIGFuIDxicj4NCiZndDsgZXJyb3IgbWVzc2FnZSBmcm9tIHRo
ZSBzZXJ2ZXIgbWF5IHJhaXNlIGFuIGV4Y2VwdGlvbiBvciBoYW5kbGUgdGhlDQo8YnI+DQomZ3Q7
IGVycm9yIGJ5IG90aGVyIG1lYW5zLjxicj4NCiZndDsgPGJyPg0KJmd0OyBMYWRhPGJyPg0KJmd0
OyA8L2ZvbnQ+PC90dD4NCjxicj4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPkhhbmRsaW5nIGV4Y2Vw
dGlvbnMgaXMgaW1wbGVtZW50dGF0aW9uJ3Mgam9iLCBJIG9ubHkNCnJlcXVpcmUgWUFORyB0byBk
ZWNsYXJlIGV4Y2VwdGlvbnMuPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj48YnI+
DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgL2ZyYW5rPGJyPg0KJmd0
OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZxdW90O25ldG1vZCZxdW90OyAmbHQ7bmV0bW9kLWJvdW5j
ZXNAaWV0Zi5vcmcmZ3Q7INC009ogMjAxNC0wNi0wMQ0KMjM6MjA6MTc6PGJyPg0KJmd0OyAmZ3Q7
PGJyPg0KJmd0OyAmZ3Q7Jmd0OyBKdWVyZ2VuIFNjaG9lbndhZWxkZXIgJmx0O2ouc2Nob2Vud2Fl
bGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZSZndDsNCjxicj4NCiZndDsgJmd0OyZndDsgt6K8/sjL
OiAmbmJzcDsmcXVvdDtuZXRtb2QmcXVvdDsgJmx0O25ldG1vZC1ib3VuY2VzQGlldGYub3JnJmd0
Ozxicj4NCiZndDsgJmd0OyZndDsgPGJyPg0KJmd0OyAmZ3Q7Jmd0OyAyMDE0LTA2LTAxIDIzOjIw
PGJyPg0KJmd0OyAmZ3Q7Jmd0OyA8YnI+DQomZ3Q7ICZndDsmZ3Q7IMfrtPC4tCC4+Dxicj4NCiZn
dDsgJmd0OyZndDsgSnVlcmdlbiBTY2hvZW53YWVsZGVyICZsdDtqLnNjaG9lbndhZWxkZXJAamFj
b2JzLXVuaXZlcnNpdHkuZGUmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyA8YnI+DQomZ3Q7ICZndDsm
Z3Q7IMrVvP7Iyzxicj4NCiZndDsgJmd0OyZndDsgPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBuZXRtb2RA
aWV0Zi5vcmcsIDxicj4NCiZndDsgJmd0OyZndDsgPGJyPg0KJmd0OyAmZ3Q7Jmd0OyCzrcvNPGJy
Pg0KJmd0OyAmZ3Q7Jmd0OyA8YnI+DQomZ3Q7ICZndDsmZ3Q7INb3zOI8YnI+DQomZ3Q7ICZndDsm
Z3Q7IDxicj4NCiZndDsgJmd0OyZndDsgW25ldG1vZF0gc3RyYXdtYW4gUkVKRUNUIFk0MyBhZGQg
ZXhjZXB0aW9uIHN0YXRlbWVudDxicj4NCiZndDsgJmd0OyZndDsgPGJyPg0KJmd0OyAmZ3Q7Jmd0
OyBJdCBpcyB1bmNsZWFyIGhvdyB2YWx1YWJsZSByZXVzYWJsZSBidXQgc29tZXdoYXQgZXhjZXB0
aW9ucw0KaW4gcmVhbDxicj4NCiZndDsgJmd0OyZndDsgZGF0YSBtb2RlbHMgYXJlLjxicj4NCiZn
dDsgJmd0OyZndDsgPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBTcGVhayB1cCBieSBKdW5lIDEwdGggaWYg
eW91IGRpc2FncmVlIHdpdGggdGhpcyBzdHJhd21hbg0KcHJvcG9zYWwuPGJyPg0KJmd0OyAmZ3Q7
Jmd0OyA8YnI+DQomZ3Q7ICZndDsmZ3Q7IC9qczxicj4NCiZndDsgJmd0OyZndDsgPGJyPg0KJmd0
OyAmZ3Q7Jmd0OyAtLSA8YnI+DQomZ3Q7ICZndDsmZ3Q7IEp1ZXJnZW4gU2Nob2Vud2FlbGRlciAm
bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQpKYWNvYnMgVW5pdmVyc2l0eSBCcmVt
ZW4gZ0dtYkg8YnI+DQomZ3Q7ICZndDsmZ3Q7IFBob25lOiArNDkgNDIxIDIwMCAzNTg3ICZuYnNw
OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBDYW1wdXMNClJpbmcgMSwgMjg3NTkgQnJlbWVuLCBHZXJt
YW55PGJyPg0KJmd0OyAmZ3Q7Jmd0OyBGYXg6ICZuYnNwOyArNDkgNDIxIDIwMCAzMTAzICZuYnNw
OyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJmx0OzwvZm9udD48L3R0PjxhIGhyZWY9Imh0dHA6Ly93
d3cuamFjb2JzLXVuaXZlcnNpdHkuZGUvIj48dHQ+PGZvbnQgc2l6ZT0yPmh0dHA6Ly93d3cuamFj
b2JzLXVuaXZlcnNpdHkuZGUvPC9mb250PjwvdHQ+PC9hPjx0dD48Zm9udCBzaXplPTI+Jmd0Ozxi
cj4NCiZndDsgJmd0OyZndDsgPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBfX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsgJmd0OyZndDsgbmV0bW9kIG1h
aWxpbmcgbGlzdDxicj4NCiZndDsgJmd0OyZndDsgbmV0bW9kQGlldGYub3JnPGJyPg0KJmd0OyAm
Z3Q7Jmd0OyA8L2ZvbnQ+PC90dD48YSBocmVmPWh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v
bGlzdGluZm8vbmV0bW9kPjx0dD48Zm9udCBzaXplPTI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp
bG1hbi9saXN0aW5mby9uZXRtb2Q8L2ZvbnQ+PC90dD48L2E+PHR0Pjxmb250IHNpemU9Mj48YnI+
DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQomZ3Q7ICZndDsgWlRFIEluZm9ybWF0aW9u
IFNlY3VyaXR5IE5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbg0KdGhpczxicj4N
CiZndDsgbWFpbCAoYW5kIGFueSBhdHRhY2htZW50IHRyYW5zbWl0dGVkIGhlcmV3aXRoKSBpcyBw
cml2aWxlZ2VkIGFuZCA8YnI+DQomZ3Q7IGNvbmZpZGVudGlhbCBhbmQgaXMgaW50ZW5kZWQgZm9y
IHRoZSBleGNsdXNpdmUgdXNlIG9mIHRoZSBhZGRyZXNzZWU8YnI+DQomZ3Q7IChzKS4gJm5ic3A7
SWYgeW91IGFyZSBub3QgYW4gaW50ZW5kZWQgcmVjaXBpZW50LCBhbnkgZGlzY2xvc3VyZSwgPGJy
Pg0KJmd0OyByZXByb2R1Y3Rpb24sIGRpc3RyaWJ1dGlvbiBvciBvdGhlciBkaXNzZW1pbmF0aW9u
IG9yIHVzZSBvZiB0aGUgPGJyPg0KJmd0OyBpbmZvcm1hdGlvbiBjb250YWluZWQgaXMgc3RyaWN0
bHkgcHJvaGliaXRlZC4gJm5ic3A7SWYgeW91IGhhdmUgcmVjZWl2ZWQNCjxicj4NCiZndDsgdGhp
cyBtYWlsIGluIGVycm9yLCBwbGVhc2UgZGVsZXRlIGl0IGFuZCBub3RpZnkgdXMgaW1tZWRpYXRl
bHkuPGJyPg0KJmd0OyAmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fPGJyPg0KJmd0OyAmZ3Q7IG5ldG1vZCBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7ICZn
dDsgbmV0bW9kQGlldGYub3JnPGJyPg0KJmd0OyAmZ3Q7IDwvZm9udD48L3R0PjxhIGhyZWY9aHR0
cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2Q+PHR0Pjxmb250IHNpemU9
Mj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZDwvZm9udD48L3R0
PjwvYT48dHQ+PGZvbnQgc2l6ZT0yPjxicj4NCiZndDsgPGJyPg0KJmd0OyAtLSA8YnI+DQomZ3Q7
IExhZGlzbGF2IExob3RrYSwgQ1ouTklDIExhYnM8YnI+DQomZ3Q7IFBHUCBLZXkgSUQ6IEU3NEU4
QzBDPGJyPg0KPC9mb250PjwvdHQ+DQoNCjxicj48cHJlPjxmb250IGNvbG9yPSJibHVlIj4NCi0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpa
VEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVk
IGluIHRoaXMgbWFpbCAoYW5kIGFueSBhdHRhY2htZW50IHRyYW5zbWl0dGVkIGhlcmV3aXRoKSBp
cyBwcml2aWxlZ2VkIGFuZCBjb25maWRlbnRpYWwgYW5kIGlzIGludGVuZGVkIGZvciB0aGUgZXhj
bHVzaXZlIHVzZSBvZiB0aGUgYWRkcmVzc2VlKHMpLiAgSWYgeW91IGFyZSBub3QgYW4gaW50ZW5k
ZWQgcmVjaXBpZW50LCBhbnkgZGlzY2xvc3VyZSwgcmVwcm9kdWN0aW9uLCBkaXN0cmlidXRpb24g
b3Igb3RoZXIgZGlzc2VtaW5hdGlvbiBvciB1c2Ugb2YgdGhlIGluZm9ybWF0aW9uIGNvbnRhaW5l
ZCBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiAgSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBtYWls
IGluIGVycm9yLCBwbGVhc2UgZGVsZXRlIGl0IGFuZCBub3RpZnkgdXMgaW1tZWRpYXRlbHkuDQoN
CjwvZm9udD48L3ByZT48YnI+DQo=

--=_alternative 00335DED48257CEE_=--


From nobody Thu Jun  5 02:50:12 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D26311A0420 for ; Thu,  5 Jun 2014 02:50:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.148
X-Spam-Level: *
X-Spam-Status: No, score=1.148 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_CHARSET_FARAWAY=2.45, RP_MATCHES_RCVD=-0.651] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2uX0t0GwH2RX for ; Thu,  5 Jun 2014 02:50:08 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2318C1A0365 for ; Thu,  5 Jun 2014 02:50:08 -0700 (PDT)
Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id B0750140141; Thu,  5 Jun 2014 11:50:00 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1401961800; bh=LIFlQxYmJ5Mcc96YreKA3V7IJ7TBXIi2ZlOYVIN7BXs=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=vuhZVdLY1dnwPv1qbO5lh7Fj24dJBeeHAUJzOLKRE5shHA/GY4LxLCdp9G34xonG/ DqJ7roUou8oMJyf8L2dd5JNshnWvE7UDKn0hU+OiSqwlIMkxPoDWpzsQExYa3BTyYl QjRrLkp4f87gTjusr7jgyANOATqgMHHrabs3jHkk=
Content-Type: text/plain; charset=GB2312
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
From: Ladislav Lhotka 
In-Reply-To: 
Date: Thu, 5 Jun 2014 11:50:01 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <2D99121A-2F15-4B1C-B525-4D804AB72BDF@nic.cz>
References: <20140601152017.GI90395@elstar.local>   
To: feng.chong33@zte.com.cn
X-Mailer: Apple Mail (2.1878.2)
X-Virus-Scanned: clamav-milter 0.97.8 at mail
X-Virus-Status: Clean
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/kwgSoWPbAvuDXuGE6KKt496vikw
Cc: NETMOD Working Group 
Subject: Re: [netmod] strawman REJECT Y43 add exception statement
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 05 Jun 2014 09:50:10 -0000

On 05 Jun 2014, at 11:21, feng.chong33@zte.com.cn wrote:

> /frank=20
>=20
> Ladislav Lhotka  =D0=B4=D3=DA 2014-06-05 16:59:12:
>=20
> > Ladislav Lhotka =20
> > 2014-06-05 16:59=20
> >=20
> > =CA=D5=BC=FE=C8=CB=20
> >=20
> > feng.chong33@zte.com.cn, Juergen Schoenwaelder=20
> > ,=20
> >=20
> > =B3=AD=CB=CD=20
> >=20
> > netmod , netmod@ietf.org=20
> >=20
> > =D6=F7=CC=E2=20
> >=20
> > Re: [netmod] strawman REJECT Y43 add exception statement=20
> >=20
> > feng.chong33@zte.com.cn writes:
> >=20
> > > Hi,
> > >   If many 'must' statements report the same error-app-tag and=20
> > > error-message,
> >=20
> > If a data model has a node that's used in many places with the same=20=

> > role and semantics, it should define a grouping for it. If this node
> > has a 'must' statement, it is defined only once.
> >=20
> > Otherwise, each 'must' statement corresponds to a specific context=20=

> > in the data model, so I guess at least the error-message should be=20=

> > specific as well. =20
> >  =20
>=20
> In my practice, our system(management information model) have defined =
many general=20
> error codes, when the constraint is invalid, many nodes would report =
general error code=20
> unless it's hard to describe the error using general error code.

I understand that app-tags may be general (=A1=B0must constraint =
violated=A1=B1), but it is IMO a good data modelling practice to give =
specific information in an error message, e.g. what does it mean in =
human terms that the constraint was violated.

And then, if it is only the app-tag that=A1=AFs reused in many places, =
making a new statement for declaring it doesn=A1=AFt make much sense to =
me. The meaning of common app-tags can be explained in a module =
description.

> =20
>=20
> > > you can use 'exception' statement to define one exception, and =
throw this=20
> > > exception in 'must' statements,
> > > otherwise, you must define the same error-app-tag and =
error-message many=20
> > > times in every 'must' statement.
> > >
> > > In real world, a server usually defined many general error codes, =
and=20
> > > app(module) would use these error codes=20
> > > to report error. 'exception' statement can be used to define the=20=

> > > information of these error codes.
> > >
> > > It's also very useful that a rpc can declare its exception. =
NETCONF is a
> > > programmable interface,  if a rpc declared its=20
> > > exceptions , APP who use NETCONF as programmable interface can =
catch these=20
> > > exception and do something it want to do,
> > > such as printing the error message, changing the request and =
resend to=20
> > > server, invoking a notification,etc.
> >=20
> > This is quite different from the above case. IMO, exceptions as they
> > are used in programming languages should be dealt with in=20
> > implementations, not in YANG. A client application receiving an=20
> > error message from the server may raise an exception or handle the=20=

> > error by other means.
> >=20
> > Lada
> >=20
>=20
> Handling exceptions is implementtation's job, I only require YANG to =
declare exceptions.

YANG spec tells the implementer when an error message should be sent, =
and error-app-tag + error-message can be used to provide details. I =
don=A1=AFt understand what extra information you want to communicate in =
an exception declaration.

Lada

>=20
> > >
> > >
> > > /frank
> > >
> > > "netmod"  =D0=B4=D3=DA 2014-06-01 =
23:20:17:
> > >
> > >> Juergen Schoenwaelder =20
> > >> =B7=A2=BC=FE=C8=CB:  "netmod" 
> > >>=20
> > >> 2014-06-01 23:20
> > >>=20
> > >> =C7=EB=B4=F0=B8=B4 =B8=F8
> > >> Juergen Schoenwaelder 
> > >>=20
> > >> =CA=D5=BC=FE=C8=CB
> > >>=20
> > >> netmod@ietf.org,=20
> > >>=20
> > >> =B3=AD=CB=CD
> > >>=20
> > >> =D6=F7=CC=E2
> > >>=20
> > >> [netmod] strawman REJECT Y43 add exception statement
> > >>=20
> > >> It is unclear how valuable reusable but somewhat exceptions in =
real
> > >> data models are.
> > >>=20
> > >> Speak up by June 10th if you disagree with this strawman =
proposal.
> > >>=20
> > >> /js
> > >>=20
> > >> --=20
> > >> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> > >> Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, =
Germany
> > >> Fax:   +49 421 200 3103         =

> > >>=20
> > >> _______________________________________________
> > >> netmod mailing list
> > >> netmod@ietf.org
> > >> https://www.ietf.org/mailman/listinfo/netmod
> > >
> > > --------------------------------------------------------
> > > ZTE Information Security Notice: The information contained in this
> > mail (and any attachment transmitted herewith) is privileged and=20
> > confidential and is intended for the exclusive use of the addressee
> > (s).  If you are not an intended recipient, any disclosure,=20
> > reproduction, distribution or other dissemination or use of the=20
> > information contained is strictly prohibited.  If you have received=20=

> > this mail in error, please delete it and notify us immediately.
> > > _______________________________________________
> > > netmod mailing list
> > > netmod@ietf.org
> > > https://www.ietf.org/mailman/listinfo/netmod
> >=20
> > --=20
> > Ladislav Lhotka, CZ.NIC Labs
> > PGP Key ID: E74E8C0C
>=20
>=20
> --------------------------------------------------------
> ZTE Information Security Notice: The information contained in this =
mail (and any attachment transmitted herewith) is privileged and =
confidential and is intended for the exclusive use of the addressee(s).  =
If you are not an intended recipient, any disclosure, reproduction, =
distribution or other dissemination or use of the information contained =
is strictly prohibited.  If you have received this mail in error, please =
delete it and notify us immediately.
>=20
>=20
>=20

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





From nobody Thu Jun  5 03:53:57 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 666091A0272 for ; Thu,  5 Jun 2014 03:53:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.172
X-Spam-Level: *
X-Spam-Status: No, score=1.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id attktJoJKDSt for ; Thu,  5 Jun 2014 03:53:52 -0700 (PDT)
Received: from mail-qg0-f48.google.com (mail-qg0-f48.google.com [209.85.192.48]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F047C1A043C for ; Thu,  5 Jun 2014 03:53:50 -0700 (PDT)
Received: by mail-qg0-f48.google.com with SMTP id i50so1204343qgf.21 for ; Thu, 05 Jun 2014 03:53:44 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=3QESky3kKfitC92j1k2njhR38g6wyHS1xhMrjmKjTH0=; b=KES/AyysnSxi1YDfy7JUmeDxSwPemCVqBt4KPu97soj5lmpWZjFjo3b8G5NiwcB5Vm Ai0FUFLSaBem0UZuvvkjsrlcOWgvyO5JzM/zaaZrV0e8qYCJ//eXcHEQC2SZCcw9qUxR K/TCb8VWwXXVi0x+jzIffaEMy9t0PqJGrWgp8mFYDIulJBAr67gM/gKNCOLXFM01zl1K bLIt8LgzE7M9A4yLQDrcA5iHO5nvnTKl6QD/kZ4Md9UtSXZWEDuP4DyWdGgYOLOgdEjz 3TfB6jqHm8VtnzZX4gOgV+G3Yf+h33z6lgunxgpm8fNnb/4+LhqD1j9N7wcPrOLAJ88Q 0n8A==
X-Gm-Message-State: ALoCoQmwf25lmyNt/VIrK0dW9xNUpxBbLKklrapuQoe/YXv8zQIsiXBBx1jKmB4xg731dEdTKJQw
MIME-Version: 1.0
X-Received: by 10.224.55.6 with SMTP id s6mr81546000qag.7.1401965624046; Thu, 05 Jun 2014 03:53:44 -0700 (PDT)
Received: by 10.140.104.49 with HTTP; Thu, 5 Jun 2014 03:53:43 -0700 (PDT)
In-Reply-To: <2D99121A-2F15-4B1C-B525-4D804AB72BDF@nic.cz>
References: <20140601152017.GI90395@elstar.local>    <2D99121A-2F15-4B1C-B525-4D804AB72BDF@nic.cz>
Date: Thu, 5 Jun 2014 03:53:43 -0700
Message-ID: 
From: Andy Bierman 
To: Ladislav Lhotka 
Content-Type: multipart/alternative; boundary=089e0153705e02654104fb148fb5
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/YFUOF2K-uEl2QqxuNDGhvu_h3KE
Cc: NETMOD Working Group 
Subject: Re: [netmod] strawman REJECT Y43 add exception statement
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 05 Jun 2014 10:53:55 -0000

--089e0153705e02654104fb148fb5
Content-Type: text/plain; charset=GB2312
Content-Transfer-Encoding: quoted-printable

On Thu, Jun 5, 2014 at 2:50 AM, Ladislav Lhotka  wrote:

>
> On 05 Jun 2014, at 11:21, feng.chong33@zte.com.cn wrote:
>
> > /frank
> >
> > Ladislav Lhotka  =D0=B4=D3=DA 2014-06-05 16:59:12:
> >
> > > Ladislav Lhotka 
> > > 2014-06-05 16:59
> > >
> > > =CA=D5=BC=FE=C8=CB
> > >
> > > feng.chong33@zte.com.cn, Juergen Schoenwaelder
> > > ,
> > >
> > > =B3=AD=CB=CD
> > >
> > > netmod , netmod@ietf.org
> > >
> > > =D6=F7=CC=E2
> > >
> > > Re: [netmod] strawman REJECT Y43 add exception statement
> > >
> > > feng.chong33@zte.com.cn writes:
> > >
> > > > Hi,
> > > >   If many 'must' statements report the same error-app-tag and
> > > > error-message,
> > >
> > > If a data model has a node that's used in many places with the same
> > > role and semantics, it should define a grouping for it. If this node
> > > has a 'must' statement, it is defined only once.
> > >
> > > Otherwise, each 'must' statement corresponds to a specific context
> > > in the data model, so I guess at least the error-message should be
> > > specific as well.
> > >
> >
> > In my practice, our system(management information model) have defined
> many general
> > error codes, when the constraint is invalid, many nodes would report
> general error code
> > unless it's hard to describe the error using general error code.
>
> I understand that app-tags may be general (=A1=B0must constraint violated=
=A1=B1),
> but it is IMO a good data modelling practice to give specific information
> in an error message, e.g. what does it mean in human terms that the
> constraint was violated.
>
> And then, if it is only the app-tag that=A1=AFs reused in many places, ma=
king a
> new statement for declaring it doesn=A1=AFt make much sense to me. The me=
aning
> of common app-tags can be explained in a module description.
>
>
IMO there is no point in enhancing error-app-tag because it is handled
so badly in the NETCONF protocol. It is a flat string that has a mandatory
value for a handful of errors and utterly meaningless for everything else.

If the purpose of error-app-tag is to allow each vendor to create all the
classification systems they want, then it fails because of the handful
of mandatory error-app-tags that override the vendor.

If it is supposed to be a standard that adds reusable value then it fails
because it is 97% ad-hoc and mostly left to the vendors.

Since we have no charter to fix NETCONF there is no point in changing YANG.

Andy



>
> >
> > > > you can use 'exception' statement to define one exception, and thro=
w
> this
> > > > exception in 'must' statements,
> > > > otherwise, you must define the same error-app-tag and error-message
> many
> > > > times in every 'must' statement.
> > > >
> > > > In real world, a server usually defined many general error codes, a=
nd
> > > > app(module) would use these error codes
> > > > to report error. 'exception' statement can be used to define the
> > > > information of these error codes.
> > > >
> > > > It's also very useful that a rpc can declare its exception. NETCONF
> is a
> > > > programmable interface,  if a rpc declared its
> > > > exceptions , APP who use NETCONF as programmable interface can catc=
h
> these
> > > > exception and do something it want to do,
> > > > such as printing the error message, changing the request and resend
> to
> > > > server, invoking a notification,etc.
> > >
> > > This is quite different from the above case. IMO, exceptions as they
> > > are used in programming languages should be dealt with in
> > > implementations, not in YANG. A client application receiving an
> > > error message from the server may raise an exception or handle the
> > > error by other means.
> > >
> > > Lada
> > >
> >
> > Handling exceptions is implementtation's job, I only require YANG to
> declare exceptions.
>
> YANG spec tells the implementer when an error message should be sent, and
> error-app-tag + error-message can be used to provide details. I don=A1=AF=
t
> understand what extra information you want to communicate in an exception
> declaration.
>
> Lada
>
> >
> > > >
> > > >
> > > > /frank
> > > >
> > > > "netmod"  =D0=B4=D3=DA 2014-06-01 23:20:17=
:
> > > >
> > > >> Juergen Schoenwaelder 
> > > >> =B7=A2=BC=FE=C8=CB:  "netmod" 
> > > >>
> > > >> 2014-06-01 23:20
> > > >>
> > > >> =C7=EB=B4=F0=B8=B4 =B8=F8
> > > >> Juergen Schoenwaelder 
> > > >>
> > > >> =CA=D5=BC=FE=C8=CB
> > > >>
> > > >> netmod@ietf.org,
> > > >>
> > > >> =B3=AD=CB=CD
> > > >>
> > > >> =D6=F7=CC=E2
> > > >>
> > > >> [netmod] strawman REJECT Y43 add exception statement
> > > >>
> > > >> It is unclear how valuable reusable but somewhat exceptions in rea=
l
> > > >> data models are.
> > > >>
> > > >> Speak up by June 10th if you disagree with this strawman proposal.
> > > >>
> > > >> /js
> > > >>
> > > >> --
> > > >> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> > > >> Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germa=
ny
> > > >> Fax:   +49 421 200 3103         
> > > >>
> > > >> _______________________________________________
> > > >> netmod mailing list
> > > >> netmod@ietf.org
> > > >> https://www.ietf.org/mailman/listinfo/netmod
> > > >
> > > > --------------------------------------------------------
> > > > ZTE Information Security Notice: The information contained in this
> > > mail (and any attachment transmitted herewith) is privileged and
> > > confidential and is intended for the exclusive use of the addressee
> > > (s).  If you are not an intended recipient, any disclosure,
> > > reproduction, distribution or other dissemination or use of the
> > > information contained is strictly prohibited.  If you have received
> > > this mail in error, please delete it and notify us immediately.
> > > > _______________________________________________
> > > > netmod mailing list
> > > > netmod@ietf.org
> > > > https://www.ietf.org/mailman/listinfo/netmod
> > >
> > > --
> > > Ladislav Lhotka, CZ.NIC Labs
> > > PGP Key ID: E74E8C0C
> >
> >
> > --------------------------------------------------------
> > ZTE Information Security Notice: The information contained in this mail
> (and any attachment transmitted herewith) is privileged and confidential
> and is intended for the exclusive use of the addressee(s).  If you are no=
t
> an intended recipient, any disclosure, reproduction, distribution or othe=
r
> dissemination or use of the information contained is strictly prohibited.
>  If you have received this mail in error, please delete it and notify us
> immediately.
> >
> >
> >
>
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>
>
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>

--089e0153705e02654104fb148fb5
Content-Type: text/html; charset=GB2312
Content-Transfer-Encoding: quoted-printable





On Thu, Jun 5, 2014 at 2:50 AM, Ladislav Lhotka &=
lt;lhotka@nic.cz>=
 wrote:




On 05 Jun 2014, at 11:21, feng.c=
hong33@zte.com.cn wrote:



> /frank

>

> Ladislav Lhotka <lhotka@nic.cz=
> =D0=B4=D3=DA 2014-06-05 16:59:12:

>

> > Ladislav Lhotka <lhotka@nic.c=
z>

> > 2014-06-05 16:59

> >

> > =CA=D5=BC=FE=C8=CB

> >

> > feng.chong33@zte.com.c=
n, Juergen Schoenwaelder

> > <j.sch=
oenwaelder@jacobs-university.de>,

> >

> > =B3=AD=CB=CD

> >

> > netmod <netmod-boun=
ces@ietf.org>, netmod@ietf.org

> >

> > =D6=F7=CC=E2

> >

> > Re: [netmod] strawman REJECT Y43 add exception statement

> >

> > feng.chong33@zte.com.c=
n writes:

> >

> > > Hi,

> > >   If many 'must' statements report the same err=
or-app-tag and

> > > error-message,

> >

> > If a data model has a node that's used in many places with th=
e same

> > role and semantics, it should define a grouping for it. If this n=
ode

> > has a 'must' statement, it is defined only once.

> >

> > Otherwise, each 'must' statement corresponds to a specifi=
c context

> > in the data model, so I guess at least the error-message should b=
e

> > specific as well.

> >

>

> In my practice, our system(management information model) have defined =
many general

> error codes, when the constraint is invalid, many nodes would report g=
eneral error code

> unless it's hard to describe the error using general error code.


I understand that app-tags may be general (“must constraint violated&=
rdquo;), but it is IMO a good data modelling practice to give specific info=
rmation in an error message, e.g. what does it mean in human terms that the=
 constraint was violated.




And then, if it is only the app-tag that’s reused in many places, mak=
ing a new statement for declaring it doesn’t make much sense to me. T=
he meaning of common app-tags can be explained in a module description.



IMO there is no point in enhancing err=
or-app-tag because it is handled
so badly in the NETCONF protocol=
. It is a flat string that has a mandatory
value for a handful of=
 errors and utterly meaningless for everything else.



If the purpose of error-app-tag is to allow each vendor=
 to create all the
classification systems they want, then it fail=
s because of the handful
of mandatory error-app-tags that overrid=
e the vendor.



If it is supposed to be a standard that adds reusable v=
alue then it fails
because it is 97% ad-hoc and mostly left to th=
e vendors.

Since we have no charter to fix NETCONF=
 there is no point in changing YANG.



Andy



=


>

>

> > > you can use 'exception' statement to define one exce=
ption, and throw this

> > > exception in 'must' statements,

> > > otherwise, you must define the same error-app-tag and error-=
message many

> > > times in every 'must' statement.

> > >

> > > In real world, a server usually defined many general error c=
odes, and

> > > app(module) would use these error codes

> > > to report error. 'exception' statement can be used t=
o define the

> > > information of these error codes.

> > >

> > > It's also very useful that a rpc can declare its excepti=
on. NETCONF is a

> > > programmable interface,  if a rpc declared its

> > > exceptions , APP who use NETCONF as programmable interface c=
an catch these

> > > exception and do something it want to do,

> > > such as printing the error message, changing the request and=
 resend to

> > > server, invoking a notification,etc.

> >

> > This is quite different from the above case. IMO, exceptions as t=
hey

> > are used in programming languages should be dealt with in

> > implementations, not in YANG. A client application receiving an
> > error message from the server may raise an exception or handle th=
e

> > error by other means.

> >

> > Lada

> >

>

> Handling exceptions is implementtation's job, I only require YANG =
to declare exceptions.



YANG spec tells the implementer when an error message should be sent, and e=
rror-app-tag + error-message can be used to provide details. I don’t =
understand what extra information you want to communicate in an exception d=
eclaration.




Lada



>

> > >

> > >

> > > /frank

> > >

> > > "netmod" <netmod-bounces@ietf.org> =D0=B4=D3=DA 2014-06-01 23:20:17:

> > >

> > >> Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>

> > >> =B7=A2=BC=FE=C8=CB:  "netmod" <netmod-bounces@ietf.org>

> > >>

> > >> 2014-06-01 23:20

> > >>

> > >> =C7=EB=B4=F0=B8=B4 =B8=F8

> > >> Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>

> > >>

> > >> =CA=D5=BC=FE=C8=CB

> > >>

> > >> netmod@ietf.org,<=
br>
> > >>

> > >> =B3=AD=CB=CD

> > >>

> > >> =D6=F7=CC=E2

> > >>

> > >> [netmod] strawman REJECT Y43 add exception statement

> > >>

> > >> It is unclear how valuable reusable but somewhat excepti=
ons in real

> > >> data models are.

> > >>

> > >> Speak up by June 10th if you disagree with this strawman=
 proposal.

> > >>

> > >> /js

> > >>

> > >> --

> > >> Juergen Schoenwaelder          =
 Jacobs University Bremen gGmbH

> > >> Phone: +49 421 200 3587         Camp=
us Ring 1, 28759 Bremen, Germany

> > >> Fax:   +49 421 200 3103        =
 <http://=
www.jacobs-university.de/>

> > >>

> > >> _______________________________________________

> > >> netmod mailing list

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

> > >

> > > --------------------------------------------------------

> > > ZTE Information Security Notice: The information contained i=
n this

> > mail (and any attachment transmitted herewith) is privileged and<=
br>
> > confidential and is intended for the exclusive use of the address=
ee

> > (s).  If you are not an intended recipient, any disclosure,<=
br>
> > reproduction, distribution or other dissemination or use of the
> > information contained is strictly prohibited.  If you have r=
eceived

> > this mail in error, please delete it and notify us immediately.
> > > _______________________________________________

> > > netmod mailing list

> > > netmod@ietf.org

> > > https://www.ietf.org/mailman/listinfo/netmod

> >

> > --

> > Ladislav Lhotka, CZ.NIC Labs

> > PGP Key ID: E74E8C0C

>

>

> --------------------------------------------------------

> ZTE Information Security Notice: The information contained in this mai=
l (and any attachment transmitted herewith) is privileged and confidential =
and is intended for the exclusive use of the addressee(s).  If you are=
 not an intended recipient, any disclosure, reproduction, distribution or o=
ther dissemination or use of the information contained is strictly prohibit=
ed.  If you have received this mail in error, please delete it and not=
ify us immediately.


>

>

>



--

Ladislav Lhotka, CZ.NIC Labs

PGP Key ID: E74E8C0C









_______________________________________________

netmod mailing list

netmod@ietf.org

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





--089e0153705e02654104fb148fb5--


From nobody Sat Jun  7 00:02:31 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23C2F1A01F5 for ; Sat,  7 Jun 2014 00:02:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.001
X-Spam-Level: 
X-Spam-Status: No, score=-1.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, J_CHICKENPOX_15=0.6, J_CHICKENPOX_62=0.6, RP_MATCHES_RCVD=-0.651] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gheQPNztDfw1 for ; Sat,  7 Jun 2014 00:02:28 -0700 (PDT)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AACE11A01C1 for ; Sat,  7 Jun 2014 00:02:27 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 6AF17F69; Sat,  7 Jun 2014 09:02:18 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id UwptU-_OQKcv; Sat,  7 Jun 2014 09:01:52 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Sat,  7 Jun 2014 09:02:17 +0200 (CEST)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id B11B52002C; Sat,  7 Jun 2014 09:02:17 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id BnrF5SwgN4_w; Sat,  7 Jun 2014 09:02:16 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 934FF20017; Sat,  7 Jun 2014 09:02:15 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 8F15B2D5ED15; Sat,  7 Jun 2014 09:02:14 +0200 (CEST)
Date: Sat, 7 Jun 2014 09:02:14 +0200
From: Juergen Schoenwaelder 
To: Benoit Claise 
Message-ID: <20140607070213.GA21144@elstar.local>
Mail-Followup-To: Benoit Claise , NETMOD Working Group , draft-ietf-netmod-snmp-cfg@tools.ietf.org
References: <538D7EF7.4030202@cisco.com> <538DF48C.6030605@cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <538DF48C.6030605@cisco.com>
User-Agent: Mutt/1.4.2.3i
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/mviJaMVG7XD_7jj4cuVZmF5OssQ
Cc: draft-ietf-netmod-snmp-cfg@tools.ietf.org, NETMOD Working Group 
Subject: Re: [netmod] AD review: draft-ietf-netmod-snmp-cfg-05
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 07 Jun 2014 07:02:30 -0000

On Tue, Jun 03, 2014 at 06:15:08PM +0200, Benoit Claise wrote:
> Dear all,
> 
> This is my AD review.
> Good work on a complete YANG model. It depends heavily on the knowledge 
> of the different SNMP MIB modules: SNMP-TARGET-MIB, 
> SNMP-NOTIFICATION-MIB, SNMP-PROXY-MIB, SNMP-COMMUNITY-MIB, etc. This is 
> good as there is no specification redefinition. And I'm glad to find the 
> examples in the appendix for the operators wanted "standard" SNMP 
> configurations.
> 
> My feedback:
> -
> 
>    The configuration data model in particular_targets_SNMP deployments
>    where SNMP runs in read-only mode and NETCONF is used to configure
>    the SNMP agent.  Nevertheless, the data model has been_designed_to
>    allow implementations that support write access both via SNMP and
>    NETCONF in order to interwork with SNMP-managed management
>    applications manipulating SNMP agent configuration using SNMP.
> 
>    The YANG data model focuses on configuration.
> 
> I don't understand what you mean by "targets" or "designed to"
> So you made some tradeoffs in the design? Is this the way we should 
> understand this?
> If which one?

I think "in particular targets" should be read as in "will likely be
primarily used in". Or to say it in other words: If a deployment uses
SNMP to configure SNMP agents, then this data model may be of limited
value.

Concerning "designed to": The data model has been designed to cover
everything that the SNMP configuration models describe. It allows an
implementation that supports both configuration via NETCONF and
configuration via SNMP. The details are discussed in section 3.2.

> - At the beginning of VACM and SNMP, we faced one issue. Someone with a 
> read-only community string could query the read-write community string.
> 
> 
> Router#sh run | i snmp
> 
> snmp-server engineID local 000000090200009092827820
> 
> snmp-server group v1group v1 read includeeverything
> 
> snmp-server view includeeverything internet included
> 
> snmp-server community _claise _RW
> 
> snmp-server user _public _v1group v1
> 
> ...
> 
> "snmpwalk -v 1  _public _internet.6.3.16 | grep _claise_"... you 
> would be surprised
> 
> Basically, the trick is that we need a default view on VACM.
> I see http://tools.ietf.org/html/rfc3415#section-7.4
> Do we need something specific in this draft to stress that issue?

I do not think that this document is the place to discuss how default
VACM rules should look like. This should go into a separate document
because this is not specific to the YANG data model but rather
specific to VACM.

> Editorial:
> 
> -
> 
> One small alignment issue below: see the port line
> 
>     +--rw snmp
>          +--rw engine
>             +--rw enabled?               boolean
>             +--rw listen* [name]
>             |  +--rw name    snmp:identifier
>             |  +--rw (transport)
>             |     +--:(udp)
>             |        +--rw udp
>             |           +--rw ip      inet:ip-address
>            |           +--rw port?   inet:port-number
>             +--rw version
>             |  +--rw v1?    empty
>             |  +--rw v2c?   empty
>             |  +--rw v3?    empty
>             +--rw engine-id?             snmp:engine-id
>             +--rw enable-authen-traps?   boolean
 
fixed 
 
> -
> 
>    The "/snmp/engine/version" container can be used to enable/disable
>    the different message processing models.
> 
> "message processing models": that's a specific SNMP term, well not well 
> known to SNMP users.
> I would add a reference to RFC 3412
>
> -
> Similarly to
>    This submodule defines the feature "tsm".  A server implements this
>    feature if it supports the Transport Security Model (tsm) [RFC5591  
>    ].
> 

OK. Although I think this should be a reference to RFC 3411 since RFC
3411 defines the components (called models in SNMP speak) and RFC 3412
is just one specific instance.

>    ...
> 
>      feature tsm {
>        description
>          "A server implements this feature if it supports the
>          Transport Security Model for SNMP.";
>        reference
>          "RFC5591  : Transport Security 
>          Model for the
>                    Simple Network Management Protocol (SNMP)";
>      }
> 
> It would be great to have references for:
> 
>    This submodule defines the feature "notification-filter".  A server
>    implements this feature if it supports SNMP notification filtering.

Added reference to RFC 3413.
 
>    ...
> 
>      feature notification-filter {
>        description
>          "A server implements this feature if it supports SNMP
>          notification filtering.";
>      }

Added reference	to RFC 3413.

> And for
> 
>    This submodule defines the feature "proxy".  A server implements this
>    feature if it can act as an SNMP Proxy.

Added reference to RFC 3413.

>    ...
> 
>      feature proxy {
>        description
>          "A server implements this feature if it can act as an
>          SNMP Proxy";
>      }
> 

Added reference to RFC 3413.

> 
>      augment /snmp:snmp/snmp:target {
>        when "snmp:v1 or snmp:v2c";
>        leaf mms {
>          type union {
>            type enumeration {
>              enum "unknown" { value 0; }
>            }
>            type int32 {
>              range "484..max";
>            }
>          }
>          default "484";
>          reference
>            "SNMP-COMMUNITY-MIB.snmpTargetAddrMMS";
>        }
>      }
> 
> 
> mms: I thought it was a mistake: nms versus mms.
> I had to lookup snmpTargetAddrMMS to understand "maximum packet size"
> Proposal: either add a description or have a better name

I prefer to keep the name since the SNMPv3 specifications use
this name. I added a description clause (and I surprised that
a leaf without a description clause slipped through).

Do you want us to post a new revision?

/js

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


From nobody Mon Jun  9 11:41:41 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD1921A02B7 for ; Mon,  9 Jun 2014 11:41:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.6
X-Spam-Level: 
X-Spam-Status: No, score=-0.6 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nVktjNhsO3vT for ; Mon,  9 Jun 2014 11:41:36 -0700 (PDT)
Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by ietfa.amsl.com (Postfix) with ESMTP id 458E81A02A6 for ; Mon,  9 Jun 2014 11:41:35 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=BZGajCY4wYEhjrq+bhk//FGulasAI3gLj4i+fTg6ZHIr0hOnpfTaqUS4IC2/LKUP; h=Message-ID:Date:From:Reply-To:To:Subject:Cc:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP;
Received: from [209.86.224.29] (helo=mswamui-cedar.atl.sa.earthlink.net) by elasmtp-kukur.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Wu4VF-0001T4-Cy; Mon, 09 Jun 2014 14:41:05 -0400
Received: from 76.254.54.24 by webmail.earthlink.net with HTTP; Mon, 9 Jun 2014 14:41:05 -0400
Message-ID: <14507864.1402339265349.JavaMail.root@mswamui-cedar.atl.sa.earthlink.net>
Date: Mon, 9 Jun 2014 11:41:05 -0700 (GMT-07:00)
From: Randy Presuhn 
To: Juergen Schoenwaelder ,  Benoit Claise 
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Mailer: EarthLink Zoo Mail 1.0
X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88864c4c3a38ce6fd81e6b07bfe95586fab1decfc976a7c5cbe350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 209.86.224.29
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/jTHj6lRDtxZiUq1BoL7w4JO4Uv0
Cc: draft-ietf-netmod-snmp-cfg@tools.ietf.org, NETMOD Working Group 
Subject: Re: [netmod] AD review: draft-ietf-netmod-snmp-cfg-05
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Randy Presuhn 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 09 Jun 2014 18:41:38 -0000

Hi -

>From: Juergen Schoenwaelder 
>Sent: Jun 7, 2014 12:02 AM
>To: Benoit Claise 
>Cc: draft-ietf-netmod-snmp-cfg@tools.ietf.org, NETMOD Working Group 
>Subject: Re: [netmod] AD review: draft-ietf-netmod-snmp-cfg-05
...
>Concerning "designed to": The data model has been designed to cover
>everything that the SNMP configuration models describe. It allows an
>implementation that supports both configuration via NETCONF and
>configuration via SNMP. The details are discussed in section 3.2.

When SNMP is used to change the value of an
instance of vacmGroupName in the vacmSecurityToGroupTable,
some side-effects will need to happen in the netconf datastores,
due to the decision to model the information differently.
I know this has come up before, but it's unclear to me what
needs to happen on the netconf server side in a couple
of specific cases:

(1) If the vacmGroupName has a value that hasn't been seen before,
a "group" obviously needs to be created as a side-effect in
netconf land.  What's less obvious is what happens to the
old "group" in the case where no other entries in the
vacmSecurityToGroupTable still have that particular value
for vacmGroupName.  Is it to be automagically deleted
because the security-model's min-elements constrainted
would otherwise be violated?

(2) Likewise, when the value of the StorageType of an entry
in vacmSecurityToGroupTable is modified from nonVolatile
to volatile, does similar "garbage collection" have
to happen as a side-effect?

(3) When the entry in vacmSecurityToGroupTable is volatile,
and some (but not all) of the corresponding vacmAccessTable
entries are nonVolatile, what happens in the netconf datastores?

Randy


From nobody Mon Jun  9 18:37:47 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CABF1A0348 for ; Mon,  9 Jun 2014 18:37:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level: 
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5NRSebo545ie for ; Mon,  9 Jun 2014 18:37:38 -0700 (PDT)
Received: from mail-qg0-f48.google.com (mail-qg0-f48.google.com [209.85.192.48]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23C211A032E for ; Mon,  9 Jun 2014 18:37:38 -0700 (PDT)
Received: by mail-qg0-f48.google.com with SMTP id i50so9746873qgf.35 for ; Mon, 09 Jun 2014 18:37:36 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=REZjJLIhdQzIINK0uS5u7ZqbpoUqxnxRGrtRe2X4onA=; b=Xa3K+VlTxptcGudVYVr5CXhFInZs+Yx0o7dY1Uq1HQGluZEbts6QCjMG+JsHU3oWXz KxMIH6UTyidp5PMMEb+eEiSjgKhnESuE6CE2ELHfnBYS+Ol417s9HlNDs70yPnpXe4K7 fRysgECjksG5i9OjTOqpwqq+k/awkUfeMVxr7uzurb+J6F+4w8IoF5GT6AZD/I0NmaFA zIVfPuOrxKSQiOAESGfsrY7cnOccnO+cRM5ZDDthc+5Nnlk2LSUdmfmQ460gnAD+/4Q5 cfIOzXd3jaY/FGtJ0WygNyTC4zRrkvumoFdFO20VLFF+E5ccm3aDYmjDRj/gdAta4HmF 1hVg==
X-Gm-Message-State: ALoCoQmdEVIaJEi6ukkT7zFHwS3A3KkDQNrTgnN3sBsa/YCADwzbUwuDGuL5r6pumcgdXojpmVUG
MIME-Version: 1.0
X-Received: by 10.224.165.70 with SMTP id h6mr38020115qay.78.1402364256063; Mon, 09 Jun 2014 18:37:36 -0700 (PDT)
Received: by 10.140.104.49 with HTTP; Mon, 9 Jun 2014 18:37:35 -0700 (PDT)
Date: Mon, 9 Jun 2014 18:37:35 -0700
Message-ID: 
From: Andy Bierman 
To: "netmod@ietf.org" 
Content-Type: multipart/alternative; boundary=089e0149c3a4542b0d04fb715f71
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/grwlHeSqFybADrVJ4uyowaIomSo
Subject: [netmod] YANG 1.1 Clarification: must-stmt within an NP-container
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 10 Jun 2014 01:37:39 -0000

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

Hi,

Consider this YANG snippet:

   container np-con {
      must "/some-node-test";   // must1
      leaf def42 {
        must "/some-other-node-test";   // must2
        type int32;
        default 42;
     }
   }

  leaf X {
     must "/np-con";  // must3
     type string;
     default foo;
  }

  leaf Y {
     must "/np-con/def42";  // must4
     type string;
     default bar;
  }


Sec. 7.5.8 says that an empty NP-container MAY be removed by the server.

   If a container does not have a "presence" statement and the last
   child node is deleted, the NETCONF server MAY delete the container.


Additional text in 7.5.3. para 2:

   When a datastore is validated, all "must" constraints are
   conceptually evaluated once for each data node in the data tree, and
   for all leafs with default values in use (see Section 7.6.1).  If a
   data node does not exist in the data tree, and it does not have a
   default value, its "must" statements are not evaluated.


Problems:

  * This MAY statement in 7.5.8 means that a client does not know if the
server
    will evaluate "must1" if all child nodes are removed from /np-con.

 * The RFC is not clear about server-created NP containers. Are they
allowed?
    When is 'must1' evaluated on all servers?

 * The RFC does not account for the conceptual existence of default
    NP containers.  Clearly, 'must2' needs to be evaluated.  In order for
    the node /np-con/def42 to exist for XPath purposes, the parent node
    /np-con must also exist for XPath purposes

 * This node existence ambiguity can ripple to other nodes. The 'must'3'
    and 'must4' evaluations need to be done.  The rules are inconsistent.
    Evaluation of 'must4' is clearly defined but 'must3' is not.

Solution:
  * Define consistent behavior rules for NP-containers wrt/ default and
    related must/when expression evaluation


Andy

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


Hi,

Consider this YANG snippet:

=A0 =A0container np-con {
=A0 =A0 =A0 must &quo=
t;/some-node-test"; =A0 // must1
=A0 =A0 =A0 leaf def42 {
=A0 =A0 =A0 =A0 must "/some-other-node-test"; =A0 // must=
2


=A0 =A0 =A0 =A0 type int32;
=A0 =A0 =A0 =A0 default 42;
=A0 =A0 =A0}
=A0 =A0}

=A0 leaf X {=

=A0 =A0 =A0must "/np-con"; =A0// must3
=A0 =
=A0 =A0type string;
=A0 =A0 =A0default foo;


=A0 }

=A0 leaf Y {
=A0 =A0 =A0must =
"/np-con/def42"; =A0// must4
=A0 =A0 =A0type string;
=A0 =A0 =A0default bar;
=A0 }

Sec. 7.5.8 says that an empty NP-container MAY be removed by t=
he server.



   If a container does not have a "presence" s=
tatement and the last
   child node is deleted, the NETCONF server MAY delete the container.


Additional text in 7.5.3. para 2:
   When a datastor=
e is validated, all "must" constraints are
   conceptually evaluated once for each data node in the data tree, and
   for all leafs with default values in use (see Section 7.6.1).  If a
   data node does not exist in the data tree, and it does not have a
   default value, its "must" statements are not evaluated.


Problems:
=A0 * This MAY statemen=
t in 7.5.8 means that a client does not know if the server
=A0 =
=A0 will evaluate "must1" if all child nodes are removed from /np=
-con.



=A0* The RFC is not clear about server-created NP conta=
iners. Are they allowed?
=A0 =A0 When is 'must1' evaluate=
d on all servers?

=A0* The RFC does not account fo=
r the conceptual existence of default


=A0 =A0 NP containers. =A0Clearly, 'must2' needs to be evaluat=
ed. =A0In order for
=A0 =A0 the node /np-con/def42 to exist for X=
Path purposes, the parent node
=A0 =A0 /np-con must also exist fo=
r XPath purposes



=A0* This node existence ambiguity can ripple to other =
nodes. The 'must'3'
=A0 =A0 and 'must4' evalu=
ations need to be done. =A0The rules are inconsistent.
=A0 =A0 Ev=
aluation of 'must4' is clearly defined but 'must3' is not.<=
/div>


Solution:
=A0 * Define consistent behavior ru=
les for NP-containers wrt/ default and
=A0 =A0 related must/when =
expression evaluation


Andy




=A0 =A0 =A0


--089e0149c3a4542b0d04fb715f71--


From nobody Tue Jun 10 03:26:54 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57C331A0503; Tue, 10 Jun 2014 03:26:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.401
X-Spam-Level: 
X-Spam-Status: No, score=-2.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sj6bTkPykOxs; Tue, 10 Jun 2014 03:26:47 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87BF51A0035; Tue, 10 Jun 2014 03:26:46 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BFG50078; Tue, 10 Jun 2014 10:26:45 +0000 (GMT)
Received: from nkgeml409-hub.china.huawei.com (10.98.56.40) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 10 Jun 2014 11:26:28 +0100
Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.193]) by nkgeml409-hub.china.huawei.com ([10.98.56.40]) with mapi id 14.03.0158.001; Tue, 10 Jun 2014 18:26:24 +0800
From: Qin Wu 
To: "netmod@ietf.org" , "netconf@ietf.org" 
Thread-Topic: Introduction to TIME Mailing List
Thread-Index: Ac+Ed/EqiWfsJ33vSgy5XLhDzjJJGgAHeClg
Date: Tue, 10 Jun 2014 10:26:23 +0000
Message-ID: 
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.138.41.180]
Content-Type: multipart/mixed; boundary="_004_B8F9A780D330094D99AF023C5877DABA84549734nkgeml501mbschi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/uiYjM5au9fSeoaxrKxyutiF6xjA
Subject: Re: [netmod] Introduction to TIME Mailing List
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 10 Jun 2014 10:26:49 -0000

--_004_B8F9A780D330094D99AF023C5877DABA84549734nkgeml501mbschi_
Content-Type: multipart/alternative;
	boundary="_000_B8F9A780D330094D99AF023C5877DABA84549734nkgeml501mbschi_"

--_000_B8F9A780D330094D99AF023C5877DABA84549734nkgeml501mbschi_
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64

RllJLg0KDQq3orz+yMs6IFRpbWUgW21haWx0bzp0aW1lLWJvdW5jZXNAaWV0Zi5vcmddILT6se0g
UWluIFd1DQq3osvNyrG85DogMjAxNMTqNtTCMTDI1SAxNDo0OA0KytW8/sjLOiB0aW1lQGlldGYu
b3JnDQqzrcvNOiBSb21hc2NhbnUsIERhbiAoRGFuKTsgTWlzaGFlbCBXZXhsZXINCtb3zOI6IFtU
aW1lXSBJbnRyb2R1Y3Rpb24gdG8gVElNRSBNYWlsaW5nIExpc3QNCg0KRGVhciBhbGwsDQoNCg0K
VGhpcyBpcyB0byBpbnRyb2R1Y2UgdGhlIFRJTUUgbWFpbGluZyBsaXN0LiBUSU1FIHN0YW5kcyBm
b3IgobBUcmFuc3BvcnQgSW5kZXBlbmRlbnQgT0FNIGluIE11bHRpLUxheWVyIE5ldHdvcmsgRW50
aXR5obEgLg0KDQoNClRoaXMgbWFpbGluZyBsaXN0IGlzIG5ld2x5IGNyZWF0ZWQgYXMgYSByZXN1
bHQgb2YgYSBCT0YgcmVxdWVzdCBwcm9wb3NhbCB0byBPUFMgQXJlYSByZWNlbnRseS4gSGVyZSBp
cyBhbiBpbml0aWFsIGRlc2NyaXB0aW9uIG9mIHRoZSBwcm9ibGVtIGluDQoNCmh0dHBzOi8vZGF0
YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXd3LW9wc2F3Zy1tdWx0aS1sYXllci1vYW0tMDAN
CmFuZCB3ZSBhcmUgbG9va2luZyBmb3IgZGlzY3Vzc2lvbiBhbmQgZmVlZGJhY2sgb24gdGhpcyBs
aXN0LCBhcyB3ZWxsIGFzIGV4cGVjdGluZyB0byBoYW1tZXIgb3V0IGEgY29uY3JldGUgc2NvcGUg
YW5kIGdldCB0aGUgZmlyc3QgdmVyc2lvbiBvZiBkcmFmdA0KY2hhcnRlciBjb21pbmcgb3V0IHRo
cm91Z2ggdGhpcyBkaXNjdXNzaW9uIC4NCg0KQmFja2dyb3VuZDoNCg0KICBUaGUgYmFzaWMgY29u
Y2VwdHMgb2YgT3BlcmF0aW9ucywgQWRtaW5pc3RyYXRpb24sIGFuZCBNYWludGVuYW5jZSAoT0FN
KSBhbmQgdGhlDQogICBmdW5jdGlvbmFsIHJvbGVzIGluIG1vbml0b3JpbmcgYW5kIGRpYWdub3Np
bmcgdGhlIGJlaGF2aW9yIG9mIHRlbGVjb21tdW5pY2F0aW9ucyBuZXR3b3Jrcw0KICAgaGF2ZSBi
ZWVuIGxvbmcgdGVybSBzdHVkaWVkIGF0IHRoZSBMYXllciAxJjIgJiBMYXllciAzIGxldmVscy4g
IFRoZSBjdXJyZW50IHByYWN0aWNlIGlzIHRoYXQNCiAgIG1hbnkgdGVjaG5vbG9naWVzIGFuZCBs
YXllcnMgaGF2ZSB0aGVpciBvd24gT0FNIHByb3RvY29scy4gICBUaGVyZSBpcyBsaXR0bGUgb3Ig
bm8NCiAgIHJlLXVzZSBvZiBzb2Z0d2FyZSBhbmQgaGFyZHdhcmUgZm9yIGVhY2ggZXhpc3Rpbmcg
T0FNIHByb3RvY29sLiBWZW5kb3JzIGFuZCBvcGVyYXRvcnMgd2FzdGUNCmEgbG90IHRocm91Z2gg
dGhlIHdob2xlIE9BTSBsaWZlLWN5Y2xlIHdoZW4gYSBuZXcgdGVjaG5vbG9neSBpcyBpbnRyb2R1
Y2VkLiBJbnRlZ3JhdGlvbiBvZiBPQU0NCmFjcm9zcyBtdWx0aXBsZSB0ZWNobm9sb2dpZXMgaXMg
ZXh0cmVtZWx5IGRpZmZpY3VsdC4gV2hlbiBoYXZpbmcgbmV0d29ya3Mgd2l0aCBtb3JlIHRoYW4g
b25lIHRlY2hub2xvZ3ksDQptYWludGVuYW5jZSBhbmQgdHJvdWJsZXNob290aW5nIGFyZSBkb25l
IHBlciB0ZWNobm9sb2d5DQogICBhbmQgbGF5ZXIsIG9wZXJhdGlvbiBwcm9jZXNzIGNhbiBiZSB2
ZXJ5IGN1bWJlcnNvbWUuIEluIG1hbnkgY2FzZXMgaXQgaXMgZGVzaXJhYmxlIHRvIGhhdmUgYQ0K
ICAgZ2VuZXJpYyBPQU0gdG8gY292ZXIgaGV0ZXJvZ2VuZW91cyBuZXR3b3JraW5nIHRlY2hub2xv
Z2llcy4gR2VuZXJpYyBPQU0gdG9vbHMgc2hvdWxkIGJlDQogICBkZXBsb3llZCBvdmVyIHZhcmlv
dXMgZW5jYXBzdWxhdGluZyBwcm90b2NvbHMsIGFuZCBpbiB2YXJpb3VzIG1lZGl1bSB0eXBlcy4N
Cg0KICAgQW4gZXhhbXBsZSBvZiBhbiBlbnZpcm9ubWVudCBpbiB3aGljaCBhIGdlbmVyaWMgYW5k
IGludGVncmF0ZWQgT0FNIHByb3RvY29sIHdvdWxkIGJlDQogICB2YWx1YWJsZSBpcyBTZXJ2aWNl
IEZ1bmN0aW9uIENoYWluaW5nLiBBIFNlcnZpY2UgRnVuY3Rpb24gQ2hhaW5pbmcgaXMgY29tcG9z
ZWQgYnkgYSBzZXJpZXMgb2YNCiAgIHNlcnZpY2UgRnVuY3Rpb25zLCB0aGF0IGNhbiBhY3QgaW4g
ZGlmZmVyZW50IGxheWVycyBidXQgcHJvdmlkaW5nIGFuIGVuZC10by1lbmQgY2hhaW4gb3IgcGF0
aA0KICAgZnJvbSBhIHNvdXJjZSB0byBkZXN0aW5hdGlvbiBpbiBhIGdpdmVuIG9yZGVyLiAgSW4g
c2VydmljZSBmdW5jdGlvbiBjaGFpbmluZyBFbnZpcm9ubWVudCwgaXQgaXMNCiAgIG5lY2Vzc2Fy
eSB0byBwcm92aWRlIGVuZCB0byBlbmQgT0FNIGFjcm9zcyBjZXJ0YWluIG9yIGFsbCBlbnRpdGll
cyBhbmQgaW52b2x2aW5nIG1hbnkgbGF5ZXJzLg0KICAgT0FNIGluZm9ybWF0aW9uIHNob3VsZCBi
ZSBleGNoYW5nZWQgYmV0d2VlbiBzZXJ2aWNlIGZ1bmN0aW9ucyBpbiBkaWZmZXJlbnQgbGF5ZXJz
IHdoaWxlDQogICB1c2luZyB2YXJpb3VzIGVuY2Fwc3VsYXRpbmcgcHJvdG9jb2xzLiAgSW4gc29t
ZSBjYXNlcyBPQU0gc2hvdWxkIGNyb3NzIGRpZmZlcmVudA0KICAgYWRtaW5pc3RyYXRpb24gYW5k
L29yIG1haW50ZW5hbmNlIGRvbWFpbnMuDQoNClRoZSBwdXJwb3NlIG9mIHRoZSBsaXN0Og0KDQog
ICAxLnVuZGVyc3RhbmRpbmcgYW5kIGRpc2N1c3NpbmcgdGhlIHRpbWVzIHdoZW4gYW4gT0FNDQog
ICBwcm90b2NvbCBjYW4gYmUgdHVuZWQgYW5kIG9wdGltaXNlZCBmb3IgYSBzcGVjaWZpYyBkYXRh
IHBsYW5lIChmb3IgZXhhbXBsZSwgT0FNIGluIGEgcGFja2V0DQogICBuZXR3b3JrIGNhbiBiZSB2
ZXJ5IGRpZmZlcmVudCBmcm9tIE9BTSBpbiBhIGNpcmN1aXQgc3dpdGNoZWQgbmV0d29yayBiZWNh
dXNlIG9mIHRoZQ0KICAgZGlmZmVyZW50IGNoYXJhY3RlcmlzdGljcyBvZiB0aGUgbmV0d29yaykN
Cg0KMi5hbmQgc2Vla2luZyB0aGUgYmVzdCB3YXlzOg0KDQogICAgICAgIE8gRXhjaGFuZ2UgT0FN
IGluZm9ybWF0aW9uIGF0IHRoZSBzZXJ2aWNlIGxheWVyIGF0b3Agb2YgbGF5ZXIgMw0KDQpPIEFi
c3RyYWN0IE9BTSBpbmZvcm1hdGlvbiBjb21tb24gdG8gZGlmZmVyZW50IGxheWVyDQoNCk8gUHJv
dmlkZSB0aGVtIHZpYSB1bmlmaWVkIGludGVyZmFjZSB0byBtYW5hZ2VtZW50IGVudGl0aWVzLg0K
DQpPIFNldCB1cCBNYWludGVuYW5jZSBEb21haW5zIChNRCkgYW5kIE1haW50ZW5hbmNlIEludGVy
bWVkaWF0ZSBQb2ludHMgKE1JUCkNCg0KTyBFbmFibGUgT0FNIGZ1bmN0aW9uIGF0IGRpZmZlcmVu
dCBsYXllciBpbiB0aGUgbXVsdGktbGF5ZXIgbmV0d29yaw0KDQpPIEFjdGl2YXRlIE9BTSBmdW5j
dGlvbiBhIGRpZmZlcmVudCBsYXllciBhbmQgcHJvdmlkZSByZXN1bHRzIHRvIG1hbmFnZW1lbnQg
ZW50aXR5DQoNClRoaXMgbWFpbGluZyBsaXN0IGlzIGludGVuZGVkIHRvIGVuYWJsZSBkaXNjdXNz
aW9uIG9mIHRoZSBhcmNoaXRlY3R1cmUsIHVzZS1jYXNlcy9hcHBsaWNhYmlsaXR5LCBhbmQNCnJl
cXVpcmVtZW50cyB0aGF0IHByb3ZpZGUgZ2VuZXJpYyBhbmQgaW50ZWdyYXRlZCBPQU0gY292ZXJp
bmcgdmFyaW91cyBoZXRlcm9nZW5lb3VzIG5ldHdvcmsgdGVjaG5vbG9naWVzLg0KDQpPIEFuYWx5
c2UgYW5kIHVuZGVyc3RhbmQgdGhlIGRpZmZlcmVudCBtb3RpdmF0aW9ucyBhbmQgb3Bwb3J0dW5p
dGllcyBmb3Igb3B0aW1pc2F0aW9uIG9mIE9BTSBpbiBkaWZmZXJlbnQNCnRlY2hub2xvZ3kgbmV0
d29ya3MsIGFuZCB0aGUgdHJhZGUtb2ZmcyBiZXR3ZWVuIHRob3NlIG9wdGltaXNhdGlvbnMgYW5k
IHRoZQ0KIG92ZXJhbGwgYWR2YW50YWdlIG9mIGEgZ2VuZXJpYyBPQU0gbWVjaGFuaXNtLg0KDQpP
IFNldCBvdXQgdGhlIHByb2JsZW0gc3RhdGVtZW50IGFuZCBhcmNoaXRlY3R1cmUgZm9yIHRoZQ0K
ICAgICBUcmFuc3BvcnQgSW5kZXBlbmRlbnQgT0FNIGluIHRoZSBtdWx0aS1sYXllciBuZXR3b3Jr
IGFuZCBvdXRsaW5lcyB0aGUgcHJvYmxlbXMNCiAgICAgZW5jb3VudGVyZWQgd2l0aCBleGlzdGlu
ZyBPQU0gcHJvdG9jb2wgdmFyaWV0eSBhbmQgdGhlaXIgaW1wYWN0IG9uIGludHJvZHVjdGlvbiBv
ZiBuZXcgdGVjaG5vbG9naWVzLg0KDQpZb3UgY2FuIHN1YnNjcmliZSB0byB0aGUgbGlzdCBhdDog
aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90aW1lLg0KDQoNClRvIHBvc3Qg
YSBtZXNzYWdlIHRvIGFsbCB0aGUgbGlzdCBtZW1iZXJzLCBzZW5kIGVtYWlsIHRvIHRpbWUgYXQg
aWV0Zi5vcmcuDQoNCg0KQmVzdCBSZWdhcmRzLA0KDQpRaW4mRGFuDQo=

--_000_B8F9A780D330094D99AF023C5877DABA84549734nkgeml501mbschi_
Content-Type: text/html; charset="gb2312"
Content-Transfer-Encoding: quoted-printable











FYI.


&n=
bsp;






=B7=A2=BC=FE=C8=CB: Time [mailto:time-bounces@ietf.org]
=B4=FA=
=B1=ED Qin Wu

=B7=A2=
=CB=CD=CA=B1=BC=E4: 2014=C4=EA6=D4=C210=C8=D5
 14:48

=CA=D5=BC=FE=C8=CB: time@ietf.org

=B3=AD=CB=CD: Romascanu, Dan (Dan); Mishael Wexler

=D6=F7=CC=E2: [Time] Introduction to TIME Mailing List






 


Dear all,


 


 


This is to introduce the TIME m=
ailing list. TIME stands for =A1=B0Transport Independent OAM in Multi-Layer=
 Network Entity=A1=B1 .


 


This mailing list is newly c=
reated as a result of a BOF request proposal to OPS Area recently. Here is =
an initial description of the problem in



https://datatracker.iet=
f.org/doc/draft-ww-opsawg-multi-layer-oam-00


and we are looking for discussi=
on and feedback on this list, as well as expecting to hammer out a concrete=
 scope and get the first version of draft



charter coming out through this=
 discussion .


 


Background:

 


  The basic concepts of Op=
erations, Administration, and Maintenance (OAM) and the

   functional roles i=
n monitoring and diagnosing the behavior of telecommunications networks



   have been lon=
g term studied at the Layer 1&2 & Layer 3 levels.  The current=
 practice is that



   many technolo=
gies and layers have their own OAM protocols.   There is little o=
r no


   re-use of software=
 and hardware for each existing OAM protocol. Vendors and operators waste



a=
 lot through the whole OAM life-cycle when a new technology is introduced. =
Integration of OAM



a=
cross multiple technologies is extremely difficult. When having networks wi=
th more than one technology,



m=
aintenance and troubleshooting are done per technology

   and layer, operati=
on process can be very cumbersome. In many cases it is desirable to have a



   generic OAM t=
o cover heterogeneous networking technologies. Generic OAM tools should be<=
o:p>


   deployed over vari=
ous encapsulating protocols, and in various medium types.=



 


   An example of an e=
nvironment in which a generic and integrated OAM protocol would be



   valuable is S=
ervice Function Chaining. A Service Function Chaining is composed by a seri=
es of


   service Functions,=
 that can act in different layers but providing an end-to-end chain or path=



   from a source to d=
estination in a given order.  In service function chaining Environment=
, it is


   necessary to provi=
de end to end OAM across certain or all entities and involving many layers.=
 



   OAM informati=
on should be exchanged between service functions in different layers while



   using various=
 encapsulating protocols.  In some cases OAM should cross different



   administratio=
n and/or maintenance domains.


 


The purpose of the list:


 


   1.understanding an=
d discussing the times when an OAM



   protocol can =
be tuned and optimised for a specific data plane (for example, OAM in a pac=
ket



   network can b=
e very different from OAM in a circuit switched network because of the



   different cha=
racteristics of the network)



 


2=
.and seeking the best ways:


<=
o:p> 


      =
  O Exchange OAM information at the service layer atop of layer 3



 


O =
Abstract OAM information common to different layer



 


O =
Provide them via unified interface to management entities.



 


O =
Set up Maintenance Domains (MD) and Maintenance Intermediate Points (MIP)



 


O =
Enable OAM function at different layer in the multi-layer network



 


O =
Activate OAM function a different layer and provide results to management e=
ntity


 


This mailing list is intended t=
o enable discussion of the architecture, use-cases/applicability, and



requirements that provide gener=
ic and integrated OAM covering various heterogeneous network technologies.<=
o:p>


 


O =
Analyse and understand the different motivations and opportunities for opti=
misation of OAM in different



te=
chnology networks, and the trade-offs between those optimisations and the


&n=
bsp;overall advantage of a generic OAM mechanism.


 


O =
Set out the problem statement and architecture for the

     Transp=
ort Independent OAM in the multi-layer network and outlines the problems


     encoun=
tered with existing OAM protocol variety and their impact on introduction o=
f new technologies.



 


You can subscribe to the list a=
t: 
https://www.ietf.org/mailman/listinfo/time.


 


 


To post a message to all the li=
st members, send email to time at ietf.org.



 


 


Best Regards,=



 


Qin&Dan





--_000_B8F9A780D330094D99AF023C5877DABA84549734nkgeml501mbschi_--

--_004_B8F9A780D330094D99AF023C5877DABA84549734nkgeml501mbschi_
Content-Type: text/plain; name="ATT00001.txt"
Content-Description: ATT00001.txt
Content-Disposition: attachment; filename="ATT00001.txt"; size=127;
	creation-date="Tue, 10 Jun 2014 07:00:08 GMT";
	modification-date="Tue, 10 Jun 2014 07:00:08 GMT"
Content-ID: 
Content-Transfer-Encoding: base64

X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NClRpbWUgbWFp
bGluZyBsaXN0DQpUaW1lQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp
c3RpbmZvL3RpbWUNCg==

--_004_B8F9A780D330094D99AF023C5877DABA84549734nkgeml501mbschi_--


From nobody Tue Jun 10 05:03:49 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF0231A007F for ; Tue, 10 Jun 2014 05:03:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id knGIciZZpMX8 for ; Tue, 10 Jun 2014 05:03:45 -0700 (PDT)
Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1lp0011.outbound.protection.outlook.com [213.199.154.11]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 024971A0077 for ; Tue, 10 Jun 2014 05:03:44 -0700 (PDT)
Received: from AMXPRD0310HT002.eurprd03.prod.outlook.com (157.56.248.133) by AMSPR07MB052.eurprd07.prod.outlook.com (10.242.81.27) with Microsoft SMTP Server (TLS) id 15.0.959.24; Tue, 10 Jun 2014 12:03:42 +0000
Message-ID: <029801cf84a3$9964f5e0$4001a8c0@gateway.2wire.net>
From: t.petch 
To: Juergen Schoenwaelder , 
References: <20140602082956.GJ92342@elstar.local>
Date: Tue, 10 Jun 2014 13:00:34 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Originating-IP: [157.56.248.133]
X-ClientProxiedBy: AMSPR07CA007.eurprd07.prod.outlook.com (10.242.77.175) To AMSPR07MB052.eurprd07.prod.outlook.com (10.242.81.27)
X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:
X-Forefront-PRVS: 0238AEEDB0
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(6009001)(428001)(51704005)(13464003)(189002)(199002)(377454003)(87286001)(84392001)(77982001)(76176999)(50226001)(62236002)(81816999)(89996001)(87976001)(93916002)(20776003)(47776003)(46102001)(77156001)(74502001)(42186004)(74662001)(76482001)(88136002)(50986999)(83322001)(99396002)(81542001)(92726001)(19580405001)(15975445006)(62966002)(79102001)(44716002)(50466002)(4396001)(80022001)(83072002)(19580395003)(31966008)(66066001)(14496001)(85852003)(92566001)(81342001)(23756003)(44736004)(102836001)(81686999)(61296002)(33646001)(21056001)(64706001)(104166001)(86362001)(101416001)(74416001)(7726001); DIR:OUT; SFP:; SCL:1; SRVR:AMSPR07MB052; H:AMXPRD0310HT002.eurprd03.prod.outlook.com; FPR:; MLV:nov; PTR:InfoNoRecords;  MX:1; A:0; LANG:en; 
Received-SPF: None (: btconnect.com does not designate permitted sender hosts)
Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; 
X-OriginatorOrg: btconnect.com
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/TMko11lj5xOPpmUFUtW1vg8HTog
Subject: Re: [netmod] undecided Y39 define the terms system/user-controlledinstances
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 10 Jun 2014 12:03:47 -0000

I would like to see this included.  I would regard it as one of the more
important issues that will facilitate future data models (well,
re-reading that, it may depend on what the definitions are but even then
probably better defined than not).

Tom Petch


----- Original Message -----
From: "Juergen Schoenwaelder" 
To: 
Sent: Monday, June 02, 2014 9:29 AM

> We need to decide whether this is in scope of YANG 1.1 or not.
>
> /js
>
> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
> Fax:   +49 421 200 3103         
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


From nobody Tue Jun 10 07:19:22 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11C1D1B27B9 for ; Tue, 10 Jun 2014 07:19:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.152
X-Spam-Level: 
X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id usdo1Hd3qYRL for ; Tue, 10 Jun 2014 07:19:17 -0700 (PDT)
Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D2CA1A049F for ; Tue, 10 Jun 2014 07:19:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1007; q=dns/txt; s=iport; t=1402409955; x=1403619555; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=q0lmAS5zokz15JIh4A8j7NfqYWbbVxyKH+YJgh2lF34=; b=SFiHc/wOpwiWXHbJv5NHX+JBpdEEygP5ctkrs7c9xECEd0EslpE+3qUV CTq5cA0POFl9la/6PTlTQ6sVeWn6ocZorQfCvCu++tx8Xk3tUmUOn8JKz yTnSdNlPGpOYmMGcp5OMhpHLL7c9ePw2dPM3mNsFTD+1YOzXb+XQ5IyqR E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ag0FAGgTl1OtJA2B/2dsb2JhbABWA4MNUlm8RoZrUQGBCBZ1hAMBAQEEAQEBNzQEEwICAgEIDgIBBAEBCxQJBxsMCxQJCAIEARIIE4gnDctZFwSOFCEXBguDGoEWBK1pgzyCLw
X-IronPort-AV: E=Sophos;i="4.98,1009,1392163200"; d="scan'208";a="51861694"
Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-8.cisco.com with ESMTP; 10 Jun 2014 14:19:14 +0000
Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id s5AEJGeT018561 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 10 Jun 2014 14:19:16 GMT
Received: from xmb-aln-x08.cisco.com ([169.254.3.9]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.03.0123.003; Tue, 10 Jun 2014 09:19:16 -0500
From: "Peyman Owladi -X (powladi - Ensoft Ltd at Cisco)" 
To: Juergen Schoenwaelder , "netmod@ietf.org" 
Thread-Topic: [netmod] strawman REJECT Y53 allow deep keys
Thread-Index: AQItgP9QjJs4u3MLstI9sokoTaGJxZquasAg
Date: Tue, 10 Jun 2014 14:19:16 +0000
Message-ID: <013A9B371AC6DF4C8AD261897D8F243E10B00239@xmb-aln-x08.cisco.com>
References: <20140601152034.GN90395@elstar.local>
In-Reply-To: <20140601152034.GN90395@elstar.local>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.63.23.76]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/VbTGZEdJEb9FcJEHXbAq__SUJG0
Subject: Re: [netmod] strawman REJECT Y53 allow deep keys
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 10 Jun 2014 14:19:20 -0000

This is fine, but I would suggest the second example provided for Y53 shoul=
d be considered for Y09 and for the additional "clarification of unions" is=
sue (which will presumably be Y55).

Cheers,
Peyman

> -----Original Message-----
> From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Juergen
> Schoenwaelder
> Sent: 01 June 2014 16:21
> To: netmod@ietf.org
> Subject: [netmod] strawman REJECT Y53 allow deep keys
>=20
> Nested keys add a lot of complexity. Other solutions may be possible,
> see also relationship to Y09.
>=20
> Speak up by June 10th if you disagree with this strawman proposal.
>=20
> /js
>=20
> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
> Fax:   +49 421 200 3103         
>=20
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


From nobody Tue Jun 10 07:39:50 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A0F01A0182 for ; Tue, 10 Jun 2014 07:39:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.152
X-Spam-Level: 
X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qc4jwbZ4VKN7 for ; Tue, 10 Jun 2014 07:39:42 -0700 (PDT)
Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F9631A017F for ; Tue, 10 Jun 2014 07:39:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4096; q=dns/txt; s=iport; t=1402411182; x=1403620782; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=22QUJXx4AWW/sJCvlDxw6tzSvxAdvsbuuoC7KTY+WII=; b=SLquEFezcUxviz2JyvtD8LQDW3wvuBI20kihIhf8RN0cKMLuorlqIdY4 TFUhP2uECs2DuASD2/0x/qpsd7jA3SYUzp6i28Ej9VvtzWajb+ejtzilA QfPa65ndk79SALpgxfVNiKQ99A/2AbBHKgKnAP6A2qBDDyP2fzQ0mt354 A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgkFAFQYl1OtJA2G/2dsb2JhbABZgw2BK8QCAYEIFnWEAwEBAQSBBQQCAQgRBAEBCwsSBzIUCQgCBAESCBOIJ8tvF44YOAYEgyGBFgSJeYN5iCiLf4tQgzyBbyQc
X-IronPort-AV: E=Sophos;i="4.98,1009,1392163200"; d="scan'208";a="51853834"
Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-6.cisco.com with ESMTP; 10 Jun 2014 14:39:41 +0000
Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s5AEdfpE005926 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 10 Jun 2014 14:39:41 GMT
Received: from xmb-aln-x08.cisco.com ([169.254.3.9]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0123.003; Tue, 10 Jun 2014 09:39:41 -0500
From: "Peyman Owladi -X (powladi - Ensoft Ltd at Cisco)" 
To: Andy Bierman , "netmod@ietf.org" 
Thread-Topic: [netmod] YANG 1.1 Clarification: must-stmt within an NP-container
Thread-Index: AQFLopx0e40Sm3DQVyNToSoXtnfHYZxyKWXw
Date: Tue, 10 Jun 2014 14:39:40 +0000
Message-ID: <013A9B371AC6DF4C8AD261897D8F243E10B002E7@xmb-aln-x08.cisco.com>
References: 
In-Reply-To: 
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.63.23.76]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/jiNBaDpR1Iz_7cjmi3BqL_rn8WM
Subject: Re: [netmod] YANG 1.1 Clarification: must-stmt within an NP-container
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 10 Jun 2014 14:39:46 -0000

Yes, we need this clarification, and it looks like it addresses the core pr=
oblem described in Y38.

Some further thoughts on the solution:

It looks like banning the use of "must" in an NP container would fail the b=
ackwards-compatibility test. So the two alternative clarifications I can th=
ink of are:
  1. Only evaluate the "must" statement in an NP container if a node (not a=
n NP container) is instantiated in the data tree within the subtree encapsu=
lated by the NP container.
  2. Always evaluate the "must" statement in an NP container if its nearest=
 non-NP-container ancestor exists (similarly defined to the rules for evalu=
ating the "mandatory" statement in RFC6020 7.6.5 and "default" in 7.6.1).

It would be reasonable for existing implementations to be using either opti=
on 1 or option 2.=20

If the rules are being tightened one way or the other, option 2 would have =
the following advantages:
  * It is more consistent with the "leaf with default" example Andy has giv=
en below.
  * It has better implications for the conformance of existing implementati=
ons:
    - If the clarification specifies that option 1 is the right behavior, t=
hen an existing implementation based on option 2 would reject some operatio=
ns that are valid.
    - If the clarification specifies that option 2 is the right behavior, t=
hen an existing implementation based on option 1 would accept some operatio=
ns that are invalid (and this is presumably the lesser evil?).
  * It seems more in line with the description of NP containers in 7.5.1, t=
hat they "exist only for organizing the hierarchy of data nodes ... the con=
tainer has no meaning of its own, existing only to contain child nodes."

Cheers,
Peyman

-----Original Message-----
From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Andy Bierman
Sent: 10 June 2014 02:38
To: netmod@ietf.org
Subject: [netmod] YANG 1.1 Clarification: must-stmt within an NP-container

Hi,

Consider this YANG snippet:

=A0 =A0container np-con {
=A0 =A0 =A0 must "/some-node-test"; =A0 // must1
=A0 =A0 =A0 leaf def42 {
=A0 =A0 =A0 =A0 must "/some-other-node-test"; =A0 // must2
=A0 =A0 =A0 =A0 type int32;
=A0 =A0 =A0 =A0 default 42;
=A0 =A0 =A0}
=A0 =A0}

=A0 leaf X {
=A0 =A0 =A0must "/np-con"; =A0// must3
=A0 =A0 =A0type string;
=A0 =A0 =A0default foo;
=A0 }

=A0 leaf Y {
=A0 =A0 =A0must "/np-con/def42"; =A0// must4
=A0 =A0 =A0type string;
=A0 =A0 =A0default bar;
=A0 }


Sec. 7.5.8 says that an empty NP-container MAY be removed by the server.

   If a container does not have a "presence" statement and the last
   child node is deleted, the NETCONF server MAY delete the container.

Additional text in 7.5.3. para 2:

   When a datastore is validated, all "must" constraints are
   conceptually evaluated once for each data node in the data tree, and
   for all leafs with default values in use (see Section 7.6.1).  If a
   data node does not exist in the data tree, and it does not have a
   default value, its "must" statements are not evaluated.

Problems:
=A0 * This MAY statement in 7.5.8 means that a client does not know if the =
server
=A0 =A0 will evaluate "must1" if all child nodes are removed from /np-con.

=A0* The RFC is not clear about server-created NP containers. Are they allo=
wed?
=A0 =A0 When is 'must1' evaluated on all servers?

=A0* The RFC does not account for the conceptual existence of default
=A0 =A0 NP containers. =A0Clearly, 'must2' needs to be evaluated. =A0In ord=
er for
=A0 =A0 the node /np-con/def42 to exist for XPath purposes, the parent node
=A0 =A0 /np-con must also exist for XPath purposes

=A0* This node existence ambiguity can ripple to other nodes. The 'must'3'
=A0 =A0 and 'must4' evaluations need to be done. =A0The rules are inconsist=
ent.
=A0 =A0 Evaluation of 'must4' is clearly defined but 'must3' is not.

Solution:
=A0 * Define consistent behavior rules for NP-containers wrt/ default and
=A0 =A0 related must/when expression evaluation


Andy



=A0 =A0 =A0


From nobody Tue Jun 10 07:58:15 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5E831B27C6 for ; Tue, 10 Jun 2014 07:58:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.151
X-Spam-Level: 
X-Spam-Status: No, score=-15.151 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fwU8ypyVhpf8 for ; Tue, 10 Jun 2014 07:58:10 -0700 (PDT)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB0001B27CF for ; Tue, 10 Jun 2014 07:58:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=22905; q=dns/txt; s=iport; t=1402412287; x=1403621887; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=hk51dhTQqUUcQX413rLiODdo7jbclhCOJAnRXcbLR3g=; b=cYdLpCheYU2n2MHIRb2S0iVxMKKb6zBw2FKsOPsT1jrkmgLexioq45on g2XNIWtoC082mdG+OUV1GoWNeeSbZhe7xxREtPpyxW770+RigBz6GOjSz fcttk0exKhbJHVuzOi5Rfy4NCr8UwlryflcYi+bZTHqBYj6zV3tX8QPk+ I=;
X-Files: Untitled attachment 04626.txt : 133
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhAFAOAbl1OtJA2K/2dsb2JhbABWA4JGR1JZvEYBhmpRAYEIFnWEAwEBAQMBAQEBKkEQBwICAgEIDgIBBAEBCx0HAhkMCxQJCAIEARIIBg2IHwgNy3MXBIkehE8HAQEeFgsWAQYLgxqBFgSRboE7mkCDPIFtAgIFFwYc
X-IronPort-AV: E=Sophos;i="4.98,1009,1392163200";  d="txt'?scan'208,217";a="331984451"
Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-2.cisco.com with ESMTP; 10 Jun 2014 14:58:06 +0000
Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s5AEw5hm021301 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 10 Jun 2014 14:58:05 GMT
Received: from xmb-aln-x08.cisco.com ([169.254.3.9]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.03.0123.003; Tue, 10 Jun 2014 09:58:05 -0500
From: "Peyman Owladi -X (powladi - Ensoft Ltd at Cisco)" 
To: Juergen Schoenwaelder , "netmod@ietf.org" 
Thread-Topic: [netmod] strawman REJECT Y51 support for long running commands
Thread-Index: AQLQWMYJ+ah+zxyoKv8/eHvkU7I1x5loxvKw
Date: Tue, 10 Jun 2014 14:58:05 +0000
Message-ID: <013A9B371AC6DF4C8AD261897D8F243E10B00381@xmb-aln-x08.cisco.com>
References: <20140601152026.GL90395@elstar.local>
In-Reply-To: <20140601152026.GL90395@elstar.local>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.63.23.76]
Content-Type: multipart/mixed; boundary="_002_013A9B371AC6DF4C8AD261897D8F243E10B00381xmbalnx08ciscoc_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/umyr9Bd3UiC9wXM1dEXRaSYUByI
Subject: Re: [netmod] strawman REJECT Y51 support for long running commands
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 10 Jun 2014 14:58:13 -0000

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

Is it fair to say that with the current Yang (1.0) support, the design
pattern specified in the original mail (attached for reference) is the
best way to represent this construct?

And to clarify:

> A proper (that is less complex) solution requires specific protocol
> support and thus this falls out of scope for YANG 1.1.

Does this mean that the suggested formulaic expansion in the attached mail
(which was intended to avoid the need for specific protocol support) is
missing some functionality or is limited in some way, or just that
performing the formulaic expansion is too complex?

(We have events of this form that need modelling, so in any case I'm
looking to validate the design pattern for consistency/completeness. In
lieu of native support, our best answer so far is to use the design
pattern described with an extension for interested implementations to link
the related primary RPC, cancellation RPC and notification.)

Thanks,
Peyman

> -----Original Message-----
> From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Juergen
> Schoenwaelder
> Sent: 01 June 2014 16:20
> To: netmod@ietf.org
> Subject: [netmod] strawman REJECT Y51 support for long running commands
>=20
> A proper (that is less complex) solution requires specific protocol
> support and thus this falls out of scope for YANG 1.1.
>=20
> Speak up by June 10th if you disagree with this strawman proposal.
>=20
> /js
>=20
> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
> Fax:   +49 421 200 3103         
>=20
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


--_002_013A9B371AC6DF4C8AD261897D8F243E10B00381xmbalnx08ciscoc_
Content-Type: message/rfc822
Content-Disposition: attachment;
	creation-date="Tue, 10 Jun 2014 14:58:03 GMT";
	modification-date="Tue, 10 Jun 2014 14:58:03 GMT"

Received: from localhost.cisco.com ([127.0.0.1] helo=ensoft-linux3.cisco.com)
	by ensoft-linux3.cisco.com with esmtp (Exim 4.76)	(envelope-from
 )	id 1WhnOH-0008Fv-QN	for powladi@localhost; Tue, 06
 May 2014 22:59:10 +0100
Received: from mail-rcd.cisco.com	by ensoft-linux3.cisco.com with IMAP
 (fetchmail-6.3.21)	for  (single-drop); Tue, 06 May 2014
 22:59:09 +0100 (BST)
Received: from rcdn-iport-8.cisco.com (173.37.86.79) by mail.cisco.com
 (173.36.12.84) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 6 May
 2014 16:58:55 -0500
Received: from rcdn-core-6.cisco.com ([173.37.93.157])  by
 rcdn-iport-8.cisco.com with ESMTP; 06 May 2014 21:58:55 +0000
Received: from alln-inbound-a.cisco.com (alln-inbound-a.cisco.com
 [173.37.147.231])	by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id
 s46LwkA4016047;	Tue, 6 May 2014 21:58:54 GMT
Received: from mail.ietf.org ([IPv6:2001:1900:3001:11::2c])  by
 alln-inbound-a.cisco.com with ESMTP; 06 May 2014 21:58:51 +0000
Received: from ietfa.amsl.com (localhost [IPv6:::1])	by ietfa.amsl.com
 (Postfix) with ESMTP id AB1761A0476;	Tue,  6 May 2014 14:58:54 -0700 (PDT)
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com
 (Postfix) with ESMTP id DC2D11A0469 for ; Tue,  6 May
 2014 14:58:51 -0700 (PDT)
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com
 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gxmpVEdjoigf for
 ; Tue,  6 May 2014 14:58:49 -0700 (PDT)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75])
 by ietfa.amsl.com (Postfix) with ESMTP id 879C61A0357 for ;
 Tue,  6 May 2014 14:58:49 -0700 (PDT)
Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by
 rcdn-iport-4.cisco.com with ESMTP; 06 May 2014 21:58:45 +0000
Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by
 rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s46LwjtZ015008
 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for
 ; Tue, 6 May 2014 21:58:45 GMT
Received: from xmb-aln-x08.cisco.com ([169.254.3.148]) by
 xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.03.0123.003; Tue, 6
 May 2014 16:58:45 -0500
From: "Peyman Owladi -X (powladi - Ensoft Ltd at Cisco)" 
To: "netmod@ietf.org" 
Subject: [netmod] Yang 1.1 support for long-running commands
Thread-Topic: [netmod] Yang 1.1 support for long-running commands
Thread-Index: AQHkyB0zBPaCpEQseZE/fAPmJNo8gA==
Sender: netmod 
Date: Tue, 6 May 2014 21:58:45 +0000
Message-ID: <013A9B371AC6DF4C8AD261897D8F243E10AAD433@xmb-aln-x08.cisco.com>
List-Help: 
List-Subscribe: ,
 
List-Unsubscribe: ,
 
Content-Language: en-US
X-MS-Exchange-Organization-AuthMechanism: 10
X-MS-Exchange-Organization-AuthSource: xhc-aln-x10.cisco.com
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.63.23.138]
Content-Type: multipart/mixed;
	boundary="_004_013A9B371AC6DF4C8AD261897D8F243E10AAD433xmbalnx08ciscoc_"
MIME-Version: 1.0

--_004_013A9B371AC6DF4C8AD261897D8F243E10AAD433xmbalnx08ciscoc_
Content-Type: multipart/alternative;
	boundary="_000_013A9B371AC6DF4C8AD261897D8F243E10AAD433xmbalnx08ciscoc_"

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

Issue:



Currently, we cannot find a "clean" way to mode a long-running command (e.g=
. "ping", "traceroute") in Yang. This class of command requires the followi=
ng:

-    A request to be made to trigger the command starting (e.g. an RPC).

-    Notifications to be returned (for a period) as partial results become =
available.

-    A request to be made to cancel the operation if required.

-    An indication that the operation has completed and no further results =
are pending.



So in Yang 1.0 this could be modelled as follows:



rpc ping {

  input {

    leaf dest     { type yang:ip-address; mandatory true; }

    leaf timeout  { type uint32; units "ms"; default 1000; }

    leaf interval { type uint32; units "ms"; default 0; }

    leaf count    { type uint32; description "Default: infinite"; }

  }

  output {

    leaf operation-id {

      type uint64;

      description "Correlates the request to 'ping-cancel' and 'ping-result=
s'"

  }

}

rpc ping-cancel {

  input {

    leaf operation-id {

      type uint64;

      description "The ID for the operation to cancel, as returned by the p=
ing request";

    }

  }

}

notification ping-results {

  leaf operation-id {

    type uint64;

    mandatory true;

    description "The ID for the request for which results are being returne=
d";

  leaf result {

    type enumeration {

      enum success;

      enum timeout;

      enum unreachable;

    }

  }

  leaf operation-completed {

    type empty;

    description "Indicates that no further results are to be returned";

  }

}



However, it would be preferable to have an abbreviated form for this usage =
pattern, which would also allow for it to be implemented differently depend=
ing on the protocol.



Solution:



This could be done various ways, but one suggestion would be to define a "p=
artial-output" RPC result, such that whenever it is used, the type of opera=
tion is as above.



rpc ping {

  input {

    leaf dest     { type yang:ip-address; mandatory true; }

    leaf timeout  { type uint32; units "ms"; default 1000; }

    leaf interval { type uint32; units "ms"; default 0; }

    leaf count    { type uint32; description "Default: infinite"; }

  }

  partial-output {

    leaf result {

      mandatory true;

      type enumeration {

        enum success;

        enum failed;

        enum unreachable;

      }

    }

  }

}



Depending on the protocol, this could be implicitly expanded to the above Y=
ang 1.0 form (with the "cancel", operation-id and "operation-completed" bei=
ng implicit based on a standard pattern), so all the extraneous parts that =
are common to this pattern are abstracted from the user.



[Note: If an "output" is also specified, that would be expected to be retur=
ned immediately in response to the input, in line with the existing RPC sem=
antics.]



Alternative solution:



It would be possible to implement this as an extension, though that would r=
equire a fifth type of operation to be defined as part of the extension.




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











Issue:


 


Currently, we cannot find a "clean" way=
 to mode a long-running command (e.g. "ping", "traceroute&qu=
ot;) in Yang. This class of command requires the following:



-   
A request to be made to trigger the command startin=
g (e.g. an RPC).



-   
Notifications to be returned (for a period) as part=
ial results become available.



-   
A request to be made to cancel the operation if req=
uired.



-   
An indication that the operation has completed and =
no further results are pending.


 


So in Yang 1.0 this could be modelled as follows:=



 


rpc ping {


  input {


    leaf dest    &n=
bsp;{ type yang:ip-address; mandatory true; }


    leaf timeout  { type uint=
32; units "ms"; default 1000; }


    leaf interval { type uint32; u=
nits "ms"; default 0; }


    leaf count    {=
 type uint32; description "Default: infinite"; }


  }


  output {


    leaf operation-id {=



      type uint64;<=
/o:p>


      description "=
Correlates the request to 'ping-cancel' and 'ping-results'"=



  }


}


rpc ping-cancel {


  input {


    leaf operation-id {=



      type uint64;<=
/o:p>


      description "=
The ID for the operation to cancel, as returned by the ping request";<=
o:p>


    }


  }


}


notification ping-results {


  leaf operation-id {


    type uint64;


    mandatory true;


    description "The ID for t=
he request for which results are being returned";


  leaf result {


    type enumeration {<=
/p>

      enum success;=



      enum timeout;=



      enum unreachable;<=
o:p>


    }


  }


  leaf operation-completed {


    type empty;


    description "Indicates th=
at no further results are to be returned";


  }


}


 


However, it would be preferable to have an abbrev=
iated form for this usage pattern, which would also allow for it to be impl=
emented differently depending on the protocol.


 


Solution:


 


This could be done various ways, but one suggesti=
on would be to define a "partial-output" RPC result, such that wh=
enever it is used, the type of operation is as above.



 


rpc ping {


  input {


    leaf dest    &n=
bsp;{ type yang:ip-address; mandatory true; }


    leaf timeout  { type uint=
32; units "ms"; default 1000; }


    leaf interval { type uint32; u=
nits "ms"; default 0; }


    leaf count    {=
 type uint32; description "Default: infinite"; }


  }


  partial-output {


    leaf result {


      mandatory true;


      type enumeration {=



        enum s=
uccess;


        enum f=
ailed;


        enum u=
nreachable;


      }


    }


  }


}


 


Depending on the protocol, this could be implicit=
ly expanded to the above Yang 1.0 form (with the "cancel", operat=
ion-id and "operation-completed" being implicit based on a standa=
rd pattern), so all the extraneous parts that are common
 to this pattern are abstracted from the user.


 


[Note: If an "output" is also specified=
, that would be expected to be returned immediately in response to the inpu=
t, in line with the existing RPC semantics.]


 


Alternative solution:


 


It would be possible to implement this as an exte=
nsion, though that would require a fifth type of operation to be defined as=
 part of the extension.


 






--_000_013A9B371AC6DF4C8AD261897D8F243E10AAD433xmbalnx08ciscoc_--

--_004_013A9B371AC6DF4C8AD261897D8F243E10AAD433xmbalnx08ciscoc_
Content-Type: text/plain; name="Untitled attachment 04626.txt"
Content-Description: Untitled attachment 04626.txt
Content-Disposition: attachment; filename="Untitled attachment 04626.txt";
	size=133; creation-date="Tue, 10 Jun 2014 14:58:04 GMT";
	modification-date="Tue, 10 Jun 2014 14:58:04 GMT"
Content-Transfer-Encoding: base64

X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm5ldG1vZCBt
YWlsaW5nIGxpc3QNCm5ldG1vZEBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h
bi9saXN0aW5mby9uZXRtb2QNCg==

--_004_013A9B371AC6DF4C8AD261897D8F243E10AAD433xmbalnx08ciscoc_--

--_002_013A9B371AC6DF4C8AD261897D8F243E10B00381xmbalnx08ciscoc_--


From nobody Tue Jun 10 08:00:09 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B300C1B27CD for ; Tue, 10 Jun 2014 08:00:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level: 
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p5ZoUOLU9nE1 for ; Tue, 10 Jun 2014 08:00:05 -0700 (PDT)
Received: from mail-qa0-f53.google.com (mail-qa0-f53.google.com [209.85.216.53]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 990B21B27D4 for ; Tue, 10 Jun 2014 08:00:05 -0700 (PDT)
Received: by mail-qa0-f53.google.com with SMTP id j5so503396qaq.26 for ; Tue, 10 Jun 2014 08:00:04 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=xur/tKGmts0O6cm8H4EfDylPGMeM02ELynjXZOirTC4=; b=lfcI8Gb0JxYlGpSVJD6ZAXGmdfjFYnkNkk+N51qUKeVZ4zrTLJ4m5J1zX83llgm4Di lCe2vpmow1VTNnNzRwcBYz3I4VP8SWinxMZVp7NwPxeCkefp38m3qVkuij7YYi6pl6Dj nBcgu1fMJtzmked6BU1bfThMUYSEsvpYvYkzyNdP4ZQSXZnkA0J6CFeolJ+ZorZUu0nR cV7AQ6DVOorHVvGvv57ZROBe2p9Y7r4wMk2fTa1Rna7vPbiSoTy0bcSOG4GbOMeo2ES3 09Yz0O7EwUllSfinGj9RuVVOTUyi7nWTQ7hcZq3T2MM9ymEY37vKDPm0B7sT0jMmcdjT LQqQ==
X-Gm-Message-State: ALoCoQmD3CAEmYOE9Jwlu9DhLqelVRMovqDONDdI9CkKtsLllooaVlM+8ftZQsM/RadED8d7fzSV
MIME-Version: 1.0
X-Received: by 10.140.41.75 with SMTP id y69mr39988335qgy.34.1402412404667; Tue, 10 Jun 2014 08:00:04 -0700 (PDT)
Received: by 10.140.104.49 with HTTP; Tue, 10 Jun 2014 08:00:04 -0700 (PDT)
In-Reply-To: <013A9B371AC6DF4C8AD261897D8F243E10B002E7@xmb-aln-x08.cisco.com>
References:  <013A9B371AC6DF4C8AD261897D8F243E10B002E7@xmb-aln-x08.cisco.com>
Date: Tue, 10 Jun 2014 08:00:04 -0700
Message-ID: 
From: Andy Bierman 
To: "Peyman Owladi -X (powladi - Ensoft Ltd at Cisco)" 
Content-Type: multipart/alternative; boundary=001a11c126ba35b2ff04fb7c955e
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/n9NMdqaE3D4Ey584w61Z7STqhEw
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] YANG 1.1 Clarification: must-stmt within an NP-container
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 10 Jun 2014 15:00:07 -0000

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

On Tue, Jun 10, 2014 at 7:39 AM, Peyman Owladi -X (powladi - Ensoft Ltd at
Cisco)  wrote:

> Yes, we need this clarification, and it looks like it addresses the core
> problem described in Y38.
>
> Some further thoughts on the solution:
>
> It looks like banning the use of "must" in an NP container would fail the
> backwards-compatibility test. So the two alternative clarifications I can
> think of are:
>   1. Only evaluate the "must" statement in an NP container if a node (not
> an NP container) is instantiated in the data tree within the subtree
> encapsulated by the NP container.
>   2. Always evaluate the "must" statement in an NP container if its
> nearest non-NP-container ancestor exists (similarly defined to the rules
> for evaluating the "mandatory" statement in RFC6020 7.6.5 and "default" in
> 7.6.1).
>
> It would be reasonable for existing implementations to be using either
> option 1 or option 2.
>
> If the rules are being tightened one way or the other, option 2 would have
> the following advantages:
>   * It is more consistent with the "leaf with default" example Andy has
> given below.
>   * It has better implications for the conformance of existing
> implementations:
>     - If the clarification specifies that option 1 is the right behavior,
> then an existing implementation based on option 2 would reject some
> operations that are valid.
>     - If the clarification specifies that option 2 is the right behavior,
> then an existing implementation based on option 1 would accept some
> operations that are invalid (and this is presumably the lesser evil?).
>   * It seems more in line with the description of NP containers in 7.5.1,
> that they "exist only for organizing the hierarchy of data nodes ... the
> container has no meaning of its own, existing only to contain child nodes."
>
>
I could support option 2.
That would change the "MAY delete" NP-containers to "MUST NOT delete"
and "MUST create".

Is that a backward-compatible change?  It does not cause a YANG 1.0
module to be invalid but changes normative server behavior.



> Cheers,
> Peyman
>

Andy


>
> -----Original Message-----
> From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Andy Bierman
> Sent: 10 June 2014 02:38
> To: netmod@ietf.org
> Subject: [netmod] YANG 1.1 Clarification: must-stmt within an NP-container
>
> Hi,
>
> Consider this YANG snippet:
>
>    container np-con {
>       must "/some-node-test";   // must1
>       leaf def42 {
>         must "/some-other-node-test";   // must2
>         type int32;
>         default 42;
>      }
>    }
>
>   leaf X {
>      must "/np-con";  // must3
>      type string;
>      default foo;
>   }
>
>   leaf Y {
>      must "/np-con/def42";  // must4
>      type string;
>      default bar;
>   }
>
>
> Sec. 7.5.8 says that an empty NP-container MAY be removed by the server.
>
>    If a container does not have a "presence" statement and the last
>    child node is deleted, the NETCONF server MAY delete the container.
>
> Additional text in 7.5.3. para 2:
>
>    When a datastore is validated, all "must" constraints are
>    conceptually evaluated once for each data node in the data tree, and
>    for all leafs with default values in use (see Section 7.6.1).  If a
>    data node does not exist in the data tree, and it does not have a
>    default value, its "must" statements are not evaluated.
>
> Problems:
>   * This MAY statement in 7.5.8 means that a client does not know if the
> server
>     will evaluate "must1" if all child nodes are removed from /np-con.
>
>  * The RFC is not clear about server-created NP containers. Are they
> allowed?
>     When is 'must1' evaluated on all servers?
>
>  * The RFC does not account for the conceptual existence of default
>     NP containers.  Clearly, 'must2' needs to be evaluated.  In order for
>     the node /np-con/def42 to exist for XPath purposes, the parent node
>     /np-con must also exist for XPath purposes
>
>  * This node existence ambiguity can ripple to other nodes. The 'must'3'
>     and 'must4' evaluations need to be done.  The rules are inconsistent.
>     Evaluation of 'must4' is clearly defined but 'must3' is not.
>
> Solution:
>   * Define consistent behavior rules for NP-containers wrt/ default and
>     related must/when expression evaluation
>
>
> Andy
>
>
>
>
>

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





On Tue, Jun 10, 2014 at 7:39 AM, Peyman Owladi -X (powladi - Ensoft=
 Ltd at Cisco) <powladi@cisco.com> wrote:


Yes, we need this clarification, and it look=
s like it addresses the core problem described in Y38.



Some further thoughts on the solution:



It looks like banning the use of "must" in an NP container would =
fail the backwards-compatibility test. So the two alternative clarification=
s I can think of are:

=A0 1. Only evaluate the "must" statement in an NP container if a=
 node (not an NP container) is instantiated in the data tree within the sub=
tree encapsulated by the NP container.

=A0 2. Always evaluate the "must" statement in an NP container if=
 its nearest non-NP-container ancestor exists (similarly defined to the rul=
es for evaluating the "mandatory" statement in RFC6020 7.6.5 and =
"default" in 7.6.1).




It would be reasonable for existing implementations to be using either opti=
on 1 or option 2.



If the rules are being tightened one way or the other, option 2 would have =
the following advantages:

=A0 * It is more consistent with the "leaf with default" example =
Andy has given below.

=A0 * It has better implications for the conformance of existing implementa=
tions:

=A0 =A0 - If the clarification specifies that option 1 is the right behavio=
r, then an existing implementation based on option 2 would reject some oper=
ations that are valid.

=A0 =A0 - If the clarification specifies that option 2 is the right behavio=
r, then an existing implementation based on option 1 would accept some oper=
ations that are invalid (and this is presumably the lesser evil?).

=A0 * It seems more in line with the description of NP containers in 7.5.1,=
 that they "exist only for organizing the hierarchy of data nodes ... =
the container has no meaning of its own, existing only to contain child nod=
es."




I could support option 2.
Th=
at would change the "MAY delete" NP-containers to "MUST NOT =
delete"
and "MUST create".



Is that a backward-compatible change? =A0It does not cause a YANG 1.0<=
/div>
module to be invalid but changes normative server behavior.
=


=A0


Cheers,

Peyman

Andy
=A0



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

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

Sent: 10 June 2014 02:38

To: netmod@ietf.org

Subject: [netmod] YANG 1.1 Clarification: must-stmt within an NP-container<=
br>


Hi,



Consider this YANG snippet:



=A0 =A0container np-con {

=A0 =A0 =A0 must "/some-node-test"; =A0 // must1

=A0 =A0 =A0 leaf def42 {

=A0 =A0 =A0 =A0 must "/some-other-node-test"; =A0 // must2

=A0 =A0 =A0 =A0 type int32;

=A0 =A0 =A0 =A0 default 42;

=A0 =A0 =A0}

=A0 =A0}



=A0 leaf X {

=A0 =A0 =A0must "/np-con"; =A0// must3

=A0 =A0 =A0type string;

=A0 =A0 =A0default foo;

=A0 }



=A0 leaf Y {

=A0 =A0 =A0must "/np-con/def42"; =A0// must4

=A0 =A0 =A0type string;

=A0 =A0 =A0default bar;

=A0 }





Sec. 7.5.8 says that an empty NP-container MAY be removed by the server.


=A0 =A0If a container does not have a "presence" statement and th=
e last

=A0 =A0child node is deleted, the NETCONF server MAY delete the container.<=
br>


Additional text in 7.5.3. para 2:



=A0 =A0When a datastore is validated, all "must" constraints are<=
br>
=A0 =A0conceptually evaluated once for each data node in the data tree, and=


=A0 =A0for all leafs with default values in use (see Section 7.6.1). =A0If =
a

=A0 =A0data node does not exist in the data tree, and it does not have a
=A0 =A0default value, its "must" statements are not evaluated.


Problems:

=A0 * This MAY statement in 7.5.8 means that a client does not know if the =
server

=A0 =A0 will evaluate "must1" if all child nodes are removed from=
 /np-con.



=A0* The RFC is not clear about server-created NP containers. Are they allo=
wed?

=A0 =A0 When is 'must1' evaluated on all servers?



=A0* The RFC does not account for the conceptual existence of default

=A0 =A0 NP containers. =A0Clearly, 'must2' needs to be evaluated. =
=A0In order for

=A0 =A0 the node /np-con/def42 to exist for XPath purposes, the parent node=


=A0 =A0 /np-con must also exist for XPath purposes



=A0* This node existence ambiguity can ripple to other nodes. The 'must=
'3'

=A0 =A0 and 'must4' evaluations need to be done. =A0The rules are i=
nconsistent.

=A0 =A0 Evaluation of 'must4' is clearly defined but 'must3'=
; is not.



Solution:

=A0 * Define consistent behavior rules for NP-containers wrt/ default and
=A0 =A0 related must/when expression evaluation





Andy







=A0 =A0 =A0





--001a11c126ba35b2ff04fb7c955e--


From nobody Tue Jun 10 08:29:15 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A2771A01DF for ; Tue, 10 Jun 2014 08:29:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.702
X-Spam-Level: 
X-Spam-Status: No, score=-0.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, J_CHICKENPOX_15=0.6, RP_MATCHES_RCVD=-0.651] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3T5npWCuqUWX for ; Tue, 10 Jun 2014 08:29:12 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D85A1A01C4 for ; Tue, 10 Jun 2014 08:29:11 -0700 (PDT)
Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id D8EFD140259; Tue, 10 Jun 2014 17:29:08 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1402414149; bh=yd1ygz9qOZdzuj8S7nb+HIoCC00Nee4i7YjyiyH4djI=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=IONTloOKwbdFHWJBYPhAvCtHVZbpNXl6y5oV1Ef7ZQBdHnt1WNigKA7kmmEzAjoLN x0w1JT3Pv1TkNRoPGZc+HsmGTm7rZEzwQAir3BVU/bkbJu5161xfbphj+6RNLDNbk+ OXRk/01MgPsfiRD/3YldwDXVNecIydOIYVFNOZq0=
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
Content-Type: text/plain; charset=us-ascii
From: Ladislav Lhotka 
X-Priority: 3
In-Reply-To: <029801cf84a3$9964f5e0$4001a8c0@gateway.2wire.net>
Date: Tue, 10 Jun 2014 17:29:10 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <20140602082956.GJ92342@elstar.local> <029801cf84a3$9964f5e0$4001a8c0@gateway.2wire.net>
To: "t.petch" 
X-Mailer: Apple Mail (2.1878.2)
X-Virus-Scanned: clamav-milter 0.97.8 at mail
X-Virus-Status: Clean
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/NsMExitgP0R8s7RsjOTB7fnEhgU
Cc: netmod@ietf.org
Subject: Re: [netmod] undecided Y39 define the terms system/user-controlledinstances
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 10 Jun 2014 15:29:14 -0000

On 10 Jun 2014, at 14:00, t.petch  wrote:

> I would like to see this included.  I would regard it as one of the =
more
> important issues that will facilitate future data models (well,
> re-reading that, it may depend on what the definitions are but even =
then
> probably better defined than not).

We agreed during the first virtual interim that these terms should be =
defined in the architecture document, that is RFC 6244bis.

Lada

>=20
> Tom Petch
>=20
>=20
> ----- Original Message -----
> From: "Juergen Schoenwaelder" 
> To: 
> Sent: Monday, June 02, 2014 9:29 AM
>=20
>> We need to decide whether this is in scope of YANG 1.1 or not.
>>=20
>> /js
>>=20
>> --
>> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
>> Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
>> Fax:   +49 421 200 3103         
>>=20
>> _______________________________________________
>> 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 nobody Tue Jun 10 09:56:00 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65E991A021F for ; Tue, 10 Jun 2014 09:55:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.151
X-Spam-Level: 
X-Spam-Status: No, score=-15.151 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5gwJwrrt6cie for ; Tue, 10 Jun 2014 09:55:55 -0700 (PDT)
Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B07271A022F for ; Tue, 10 Jun 2014 09:55:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=23786; q=dns/txt; s=iport; t=1402419354; x=1403628954; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=JCuiHRpBx7djGcH7H/LQY8oyA8tYLZcBwM3wAZWkCGA=; b=lHIjHm78Qs4ho2IbKUffmSTBI7Q8A2lsa4syL3WPOgE0wfe30COSKfir TEaZHqGclrhprtzL8ZvsVZCMvi/nl/oSLPMZxrX+CzTTzKfe5Bk1Fff1l UMUxr0NACNCMzTayFi/zWTLECtyyh/LPpmvnLT7pqTmSZobP9UKtY6jqJ w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgwFAIQ3l1OtJA2H/2dsb2JhbABZgkZHUlnEAwGBCBZ1hAMBAQEELUwMBAIBCBEEAQELCwsHBzIUCQgCBA4FCBOIJ8xFF44YMQYBBgSDIYEWBIYIh2qIKIt/i1CDPIFvJBw
X-IronPort-AV: E=Sophos;i="4.98,1009,1392163200";  d="scan'208,217";a="51825902"
Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-1.cisco.com with ESMTP; 10 Jun 2014 16:55:53 +0000
Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s5AGtrru028051 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 10 Jun 2014 16:55:53 GMT
Received: from xmb-aln-x08.cisco.com ([169.254.3.9]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0123.003; Tue, 10 Jun 2014 11:55:53 -0500
From: "Peyman Owladi -X (powladi - Ensoft Ltd at Cisco)" 
To: Andy Bierman 
Thread-Topic: [netmod] YANG 1.1 Clarification: must-stmt within an NP-container
Thread-Index: AQFLopx0e40Sm3DQVyNToSoXtnfHYQFtuDltAtYopxmcUDQvgA==
Date: Tue, 10 Jun 2014 16:55:52 +0000
Message-ID: <013A9B371AC6DF4C8AD261897D8F243E10B005E8@xmb-aln-x08.cisco.com>
References:  <013A9B371AC6DF4C8AD261897D8F243E10B002E7@xmb-aln-x08.cisco.com> 
In-Reply-To: 
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.63.23.76]
Content-Type: multipart/alternative; boundary="_000_013A9B371AC6DF4C8AD261897D8F243E10B005E8xmbalnx08ciscoc_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/QDAnyWDOBnmnkmHn_rNI4Q1iHFA
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] YANG 1.1 Clarification: must-stmt within an NP-container
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 10 Jun 2014 16:55:58 -0000

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


From: Andy Bierman [mailto:andy@yumaworks.com]
Sent: 10 June 2014 16:00
To: Peyman Owladi -X (powladi - Ensoft Ltd at Cisco)
Cc: netmod@ietf.org
Subject: Re: [netmod] YANG 1.1 Clarification: must-stmt within an NP-contai=
ner



On Tue, Jun 10, 2014 at 7:39 AM, Peyman Owladi -X (powladi - Ensoft Ltd at =
Cisco) > wrote:
Yes, we need this clarification, and it looks like it addresses the core pr=
oblem described in Y38.

Some further thoughts on the solution:

It looks like banning the use of "must" in an NP container would fail the b=
ackwards-compatibility test. So the two alternative clarifications I can th=
ink of are:
  1. Only evaluate the "must" statement in an NP container if a node (not a=
n NP container) is instantiated in the data tree within the subtree encapsu=
lated by the NP container.
  2. Always evaluate the "must" statement in an NP container if its nearest=
 non-NP-container ancestor exists (similarly defined to the rules for evalu=
ating the "mandatory" statement in RFC6020 7.6.5 and "default" in 7.6.1).

It would be reasonable for existing implementations to be using either opti=
on 1 or option 2.

If the rules are being tightened one way or the other, option 2 would have =
the following advantages:
  * It is more consistent with the "leaf with default" example Andy has giv=
en below.
  * It has better implications for the conformance of existing implementati=
ons:
    - If the clarification specifies that option 1 is the right behavior, t=
hen an existing implementation based on option 2 would reject some operatio=
ns that are valid.
    - If the clarification specifies that option 2 is the right behavior, t=
hen an existing implementation based on option 1 would accept some operatio=
ns that are invalid (and this is presumably the lesser evil?).
  * It seems more in line with the description of NP containers in 7.5.1, t=
hat they "exist only for organizing the hierarchy of data nodes ... the con=
tainer has no meaning of its own, existing only to contain child nodes."

I could support option 2.
That would change the "MAY delete" NP-containers to "MUST NOT delete"
and "MUST create".

Is that a backward-compatible change?  It does not cause a YANG 1.0
module to be invalid but changes normative server behavior.


It seems to me that this can simply be a recommendation for server behavior=
 that helps to define the expected externally-observed behavior for evaluat=
ing "must" constraints. (Perhaps this should also apply to the behavior of =
"default" and "mandatory" leaves, to simplify the language in 7.6.1 and 7.6=
.5.)

A server implementation could choose not to actually instantiate the NP con=
tainers, but to evaluate the "must" constraints in the cases in the cases w=
here they are described as being logically instantiated. (In other words, I=
 think what's being described is just the "conceptual" existence  of NP-con=
tainers for these evaluations/behaviors.)

An alternative approach would be to avoid updating the statement about exis=
tence of NP-containers at all, and instead update the datastore validation =
statement in 7.5.3 to bring it in line with 7.6.1 and 7.6.5; e.g. replace t=
he second paragraph of 7.5.3 with:

When a datastore is validated, all "must" constraints are
conceptually evaluated once for each data node in the data tree,
and for all leafs with default values in use (see Section 7.6.1).
For "must" constraints in non-presence containers (see Section
7.5.1), the evaluation depends on each instance of its closest
ancestor node in the schema tree that is not a non-presence
container:

   o  If no such ancestor exists in the schema tree, the "must"
      constraint is evaluated.

   o  Otherwise, if this ancestor is a case node, the "must"
      constraint is evaluated if any node from the case exists
      in the data tree.

   o  Otherwise, the leaf "must" constraint is evaluated if the
      ancestor node in the data tree.

For any other data node, its "must" statements are not evaluated.

Cheers,
Peyman

Andy

Cheers,
Peyman



-----Original Message-----
From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Andy Bierman
Sent: 10 June 2014 02:38
To: netmod@ietf.org
Subject: [netmod] YANG 1.1 Clarification: must-stmt within an NP-container

Hi,

Consider this YANG snippet:

   container np-con {
      must "/some-node-test";   // must1
      leaf def42 {
        must "/some-other-node-test";   // must2
        type int32;
        default 42;
     }
   }

  leaf X {
     must "/np-con";  // must3
     type string;
     default foo;
  }

  leaf Y {
     must "/np-con/def42";  // must4
     type string;
     default bar;
  }


Sec. 7.5.8 says that an empty NP-container MAY be removed by the server.

   If a container does not have a "presence" statement and the last
   child node is deleted, the NETCONF server MAY delete the container.

Additional text in 7.5.3. para 2:

   When a datastore is validated, all "must" constraints are
   conceptually evaluated once for each data node in the data tree, and
   for all leafs with default values in use (see Section 7.6.1).  If a
   data node does not exist in the data tree, and it does not have a
   default value, its "must" statements are not evaluated.

Problems:
  * This MAY statement in 7.5.8 means that a client does not know if the se=
rver
    will evaluate "must1" if all child nodes are removed from /np-con.

 * The RFC is not clear about server-created NP containers. Are they allowe=
d?
    When is 'must1' evaluated on all servers?

 * The RFC does not account for the conceptual existence of default
    NP containers.  Clearly, 'must2' needs to be evaluated.  In order for
    the node /np-con/def42 to exist for XPath purposes, the parent node
    /np-con must also exist for XPath purposes

 * This node existence ambiguity can ripple to other nodes. The 'must'3'
    and 'must4' evaluations need to be done.  The rules are inconsistent.
    Evaluation of 'must4' is clearly defined but 'must3' is not.

Solution:
  * Define consistent behavior rules for NP-containers wrt/ default and
    related must/when expression evaluation


Andy






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











 








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


Sent: 10 June 2014 16:00

To: Peyman Owladi -X (powladi - Ensoft Ltd at Cisco)

Cc: netmod@ietf.org

Subject: Re: [netmod] YANG 1.1 Clarification: must-stmt within an NP=
-container






 




 




 




On Tue, Jun 10, 2014 at 7:39 AM, Peyman Owladi -X (p=
owladi - Ensoft Ltd at Cisco) <powladi@cisco.com> wrote:


Yes, we need this cla=
rification, and it looks like it addresses the core problem described in Y3=
8.



Some further thoughts on the solution:



It looks like banning the use of "must" in an NP container would =
fail the backwards-compatibility test. So the two alternative clarification=
s I can think of are:

  1. Only evaluate the "must" statement in an NP container i=
f a node (not an NP container) is instantiated in the data tree within the =
subtree encapsulated by the NP container.

  2. Always evaluate the "must" statement in an NP container=
 if its nearest non-NP-container ancestor exists (similarly defined to the =
rules for evaluating the "mandatory" statement in RFC6020 7.6.5 a=
nd "default" in 7.6.1).



It would be reasonable for existing implementations to be using either opti=
on 1 or option 2.



If the rules are being tightened one way or the other, option 2 would have =
the following advantages:

  * It is more consistent with the "leaf with default" examp=
le Andy has given below.

  * It has better implications for the conformance of existing impleme=
ntations:

    - If the clarification specifies that option 1 is the right b=
ehavior, then an existing implementation based on option 2 would reject som=
e operations that are valid.

    - If the clarification specifies that option 2 is the right b=
ehavior, then an existing implementation based on option 1 would accept som=
e operations that are invalid (and this is presumably the lesser evil?).
  * It seems more in line with the description of NP containers in 7.5=
.1, that they "exist only for organizing the hierarchy of data nodes .=
.. the container has no meaning of its own, existing only to contain child =
nodes."




 






I could support option 2.






That would change the "MAY delete" NP-cont=
ainers to "MUST NOT delete"






and "MUST create".






 






Is that a backward-compatible change?  It does =
not cause a YANG 1.0






module to be invalid but changes normative server be=
havior.






 


 <=
/p>

It seems to me that this =
can simply be a recommendation for server behavior that helps to define the=
 expected externally-observed behavior for evaluating "must"
 constraints. (Perhaps this should also apply to the behavior of "defa=
ult" and "mandatory" leaves, to simplify the language in 7.6=
.1 and 7.6.5.)


 <=
/p>

A server implementation c=
ould choose not to actually instantiate the NP containers, but to evaluate =
the "must" constraints in the cases in the cases where they
 are described as being logically instantiated. (In other words, I think wh=
at's being described is just the "conceptual" existence  of =
NP-containers for these evaluations/behaviors.)


 <=
/p>

An alternative approach w=
ould be to avoid updating the statement about existence of NP-containers at=
 all, and instead update the datastore validation statement
 in 7.5.3 to bring it in line with 7.6.1 and 7.6.5; e.g. replace the second=
 paragraph of 7.5.3 with:


 <=
/p>

When a data=
store is validated, all "must" constraints are<=
/p>

conceptuall=
y evaluated once for each data node in the data tree,


and for all=
 leafs with default values in use (see Section 7.6.1).

For "m=
ust" constraints in non-presence containers (see Section


7.5.1), the=
 evaluation depends on each instance of its closest


ancestor no=
de in the schema tree that is not a non-presence


container:<=
o:p>


 =



  =
; o  If no such ancestor exists in the schema tree, the "must&quo=
t;


  =
;    constraint is evaluated.


 =



  =
; o  Otherwise, if this ancestor is a case node, the "must"<=
o:p>


  =
;    constraint is evaluated if any node from the case exist=
s


  =
;    in the data tree.


 =



  =
; o  Otherwise, the leaf "must" constraint is evaluated if t=
he


  =
;    ancestor node in the data tree.


 =



For any oth=
er data node, its "must" statements are not evaluated.=







 






Cheers,

Peyman






 






Andy






 


Cheers,=



Peyman<=
/p>

 <=
/p>

 








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

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

Sent: 10 June 2014 02:38

To: netmod@ietf.org

Subject: [netmod] YANG 1.1 Clarification: must-stmt within an NP-container<=
br>


Hi,



Consider this YANG snippet:



   container np-con {

      must "/some-node-test";   // must1

      leaf def42 {

        must "/some-other-node-test";   =
// must2

        type int32;

        default 42;

     }

   }



  leaf X {

     must "/np-con";  // must3

     type string;

     default foo;

  }



  leaf Y {

     must "/np-con/def42";  // must4

     type string;

     default bar;

  }





Sec. 7.5.8 says that an empty NP-container MAY be removed by the server.


   If a container does not have a "presence" statement =
and the last

   child node is deleted, the NETCONF server MAY delete the conta=
iner.



Additional text in 7.5.3. para 2:



   When a datastore is validated, all "must" constraint=
s are

   conceptually evaluated once for each data node in the data tre=
e, and

   for all leafs with default values in use (see Section 7.6.1). =
 If a

   data node does not exist in the data tree, and it does not hav=
e a

   default value, its "must" statements are not evaluat=
ed.



Problems:

  * This MAY statement in 7.5.8 means that a client does not know if t=
he server

    will evaluate "must1" if all child nodes are remove=
d from /np-con.



 * The RFC is not clear about server-created NP containers. Are they a=
llowed?

    When is 'must1' evaluated on all servers?



 * The RFC does not account for the conceptual existence of default
    NP containers.  Clearly, 'must2' needs to be evaluated. =
 In order for

    the node /np-con/def42 to exist for XPath purposes, the paren=
t node

    /np-con must also exist for XPath purposes



 * This node existence ambiguity can ripple to other nodes. The 'must'=
3'

    and 'must4' evaluations need to be done.  The rules are =
inconsistent.

    Evaluation of 'must4' is clearly defined but 'must3' is not.<=
br>


Solution:

  * Define consistent behavior rules for NP-containers wrt/ default an=
d

    related must/when expression evaluation





Andy







     






 












--_000_013A9B371AC6DF4C8AD261897D8F243E10B005E8xmbalnx08ciscoc_--


From nobody Tue Jun 10 12:03:54 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 548AA1A026B; Tue, 10 Jun 2014 12:03:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.151
X-Spam-Level: 
X-Spam-Status: No, score=-15.151 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I1cuYv2yqKdr; Tue, 10 Jun 2014 12:03:30 -0700 (PDT)
Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D77E1A0265; Tue, 10 Jun 2014 12:03:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5934; q=dns/txt; s=iport; t=1402427010; x=1403636610; h=from:to:subject:date:message-id:mime-version; bh=Dc3hr127a1X+3mZdBPQzA/LAdjc5BmgXpMtO1fFmr4Q=; b=JFeAsyaCIQAkI7pcxI9f6r15+b4k9RG1LTo5E+mdf6vVQKM2YC5zkBXD YTc4E+yQZf5nU2fQVwyIFqMT4dzQA7lqinYZPYZXcCjeDyD3yDEixI04Z JRbUbVGxArc+mKv0k/2Z+aaQnc3Xrd3HN8lMSWuEeFN5tjNbAS6X4FHOg c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ArgPAPdVl1OtJV2c/2dsb2JhbABZgkZHUlmqaQEBBoMIjH2JDQGBChZ1hAUBBC1eASpWJgEEARqIOg3NEBeFVohCg2OBFgSbZpIDgzyCLw
X-IronPort-AV: E=Sophos;i="4.98,1010,1392163200";  d="scan'208,217";a="51931176"
Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-6.cisco.com with ESMTP; 10 Jun 2014 19:03:29 +0000
Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s5AJ3TO1011224 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 10 Jun 2014 19:03:29 GMT
Received: from xmb-rcd-x08.cisco.com ([169.254.8.200]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0123.003; Tue, 10 Jun 2014 14:03:29 -0500
From: "Tissa Senevirathne (tsenevir)" 
To: "netmod@ietf.org" , "nvo3@ietf.org" , "trill@ietf.org" , "l2vpn@ietf.org" , "opsawg@ietf.org" 
Thread-Topic: YANG models for OAM
Thread-Index: Ac+E3qlMyPi638vnRGmjYh75Wx+edA==
Date: Tue, 10 Jun 2014 19:03:28 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.155.1.132]
Content-Type: multipart/alternative; boundary="_000_FBEA3E19AA24F847BA3AE74E2FE193562EE91CDAxmbrcdx08ciscoc_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/vAb7OL9Ul7MA5OWs_tsdl7preFE
Subject: [netmod] YANG models for OAM
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 10 Jun 2014 19:03:32 -0000

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

All

We have published YANG model for OAM. #1 draft below place the generic fram=
ework for OAM, that can be augmented for different technologies. #2 and #3 =
are application of the concept to NVO3 and TRILL,


1.      http://datatracker.ietf.org/doc/draft-tissa-netmod-oam/

2.      http://datatracker.ietf.org/doc/draft-tissa-nvo3-yang-oam/

3.      http://datatracker.ietf.org/doc/draft-tissa-trill-yang-oam/

Please review and share your comments

Thanks
Tissa



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











All


 


We have published YANG model for OAM. #1 draft below=
 place the generic framework for OAM, that can be augmented for different t=
echnologies. #2 and #3 are application of the concept to NVO3 and TRILL,


 


1.     
http://datatracker.ietf.org/doc/draft-tissa-netmod-=
oam/


2.     
http://datatracker.ietf.org/doc/draft-tissa-nvo3-ya=
ng-oam/


3.     
http://datatracker.ietf.org/doc/draft-tissa-trill-yang=
-oam/


 


Please review and share your comments


 


Thanks


Tissa


 


 






--_000_FBEA3E19AA24F847BA3AE74E2FE193562EE91CDAxmbrcdx08ciscoc_--


From nobody Tue Jun 10 12:17:14 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D46641A0279 for ; Tue, 10 Jun 2014 12:16:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.801
X-Spam-Level: 
X-Spam-Status: No, score=-0.801 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hbzEon4gaEAM for ; Tue, 10 Jun 2014 12:16:57 -0700 (PDT)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC9191A0081 for ; Tue, 10 Jun 2014 12:16:57 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 7E71AF7F for ; Tue, 10 Jun 2014 21:16:54 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 6TcUq85zCm27 for ; Tue, 10 Jun 2014 21:16:47 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Tue, 10 Jun 2014 21:16:54 +0200 (CEST)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6027220017 for ; Tue, 10 Jun 2014 21:16:55 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id xYeMET3rJzR5; Tue, 10 Jun 2014 21:16:55 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B1BAD20013; Tue, 10 Jun 2014 21:16:54 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id AC60E2D6112A; Tue, 10 Jun 2014 21:16:52 +0200 (CEST)
Date: Tue, 10 Jun 2014 21:16:52 +0200
From: Juergen Schoenwaelder 
To: netmod@ietf.org
Message-ID: <20140610191652.GA28878@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.4.2.3i
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/jzmmliyNekXuwMODMNhqh1gaCCg
Subject: [netmod] draft minutes of the 2014-06-04 virtual interim meeting
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
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, 10 Jun 2014 19:17:00 -0000

Hi,

attached please find the minutes of the 2014-06-04 virtual interim
meeting. Note that a final version needs to be submitted within 10
days - so please send any corrections of the minutes by Friday June
13th.

/js

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


From nobody Tue Jun 10 12:19:00 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05FF01A0279 for ; Tue, 10 Jun 2014 12:18:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.201
X-Spam-Level: 
X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id quWLm3joODqa for ; Tue, 10 Jun 2014 12:18:45 -0700 (PDT)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D548B1A0081 for ; Tue, 10 Jun 2014 12:18:44 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 36674F7F for ; Tue, 10 Jun 2014 21:18:42 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id EUjOtRTfm5hD for ; Tue, 10 Jun 2014 21:18:34 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Tue, 10 Jun 2014 21:18:41 +0200 (CEST)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1550620017 for ; Tue, 10 Jun 2014 21:18:43 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id g5dwpXzPMyZo; Tue, 10 Jun 2014 21:18:42 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5525920013; Tue, 10 Jun 2014 21:18:42 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 3BB6F2D61159; Tue, 10 Jun 2014 21:18:42 +0200 (CEST)
Date: Tue, 10 Jun 2014 21:18:42 +0200
From: Juergen Schoenwaelder 
To: netmod@ietf.org
Message-ID: <20140610191842.GB28878@elstar.local>
Mail-Followup-To: netmod@ietf.org
References: <20140602081433.GA92342@elstar.local>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20140602081433.GA92342@elstar.local>
User-Agent: Mutt/1.4.2.3i
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/_OUrHbDCP4964q6Kc-_-7lt062I
Subject: Re: [netmod] undecided Y09 introduce optional keys
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
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, 10 Jun 2014 19:18:46 -0000

On Mon, Jun 02, 2014 at 10:14:33AM +0200, Juergen Schoenwaelder wrote:
> We need to decide whether this is in scope of YANG 1.1 or not.
> 
> The implications of this seem to be somewhat unclear. Does this only
> work if there are defaults or the leaf is initialized by system?
> 

Interim proposal:

  Proposal: Move this to open for now. Some concerns from KW and
  AB. We might revisit this issue later if the complexity/cost of a
  solution is too high. Action item for MB to provide a detailed
  solution proposal.

If you disagree, please speak up by June 18th.

/js

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


From nobody Tue Jun 10 12:19:34 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9B581A028B for ; Tue, 10 Jun 2014 12:19:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.201
X-Spam-Level: 
X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1OM4l_mKJVSq for ; Tue, 10 Jun 2014 12:19:17 -0700 (PDT)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8710B1A0081 for ; Tue, 10 Jun 2014 12:19:17 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id DAD2BF7F for ; Tue, 10 Jun 2014 21:19:14 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id h-89jGqQx7Km for ; Tue, 10 Jun 2014 21:19:07 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Tue, 10 Jun 2014 21:19:14 +0200 (CEST)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id B988A20017 for ; Tue, 10 Jun 2014 21:19:15 +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 copeBy50ayng; Tue, 10 Jun 2014 21:19:15 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id E920F20013; Tue, 10 Jun 2014 21:19:14 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id C57C52D6116A; Tue, 10 Jun 2014 21:19:14 +0200 (CEST)
Date: Tue, 10 Jun 2014 21:19:14 +0200
From: Juergen Schoenwaelder 
To: netmod@ietf.org
Message-ID: <20140610191914.GC28878@elstar.local>
Mail-Followup-To: netmod@ietf.org
References: <20140602081547.GB92342@elstar.local>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20140602081547.GB92342@elstar.local>
User-Agent: Mutt/1.4.2.3i
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/1UPZ3utgroVie7Ir9fmeJsjIrHY
Subject: Re: [netmod] undecided Y19 we need a better unique
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
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, 10 Jun 2014 19:19:19 -0000

On Mon, Jun 02, 2014 at 10:15:47AM +0200, Juergen Schoenwaelder wrote:
> We need to decide whether this is in scope of YANG 1.1 or not.
> 

Interim proposal:

  Proposal: Reject this request for a new feature but clarify the
  semantics of unique in RFC 6020bis (might require to open a separate
  clarification issue). A new and more powerful unique seems more like
  a YANG 2.0 work item than a YANG 1.1 work item. The consensus on
  this was rough (MB prefers to have this issue opened).

If you disagree, please speak up by June 18th.

/js

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


From nobody Tue Jun 10 12:20:30 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 455C91A0279 for ; Tue, 10 Jun 2014 12:20:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.201
X-Spam-Level: 
X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oGvGyB3zqR5I for ; Tue, 10 Jun 2014 12:20:07 -0700 (PDT)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBC0F1A0081 for ; Tue, 10 Jun 2014 12:20:06 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 2CE1571E for ; Tue, 10 Jun 2014 21:20:04 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id ES29WNa0GL9g for ; Tue, 10 Jun 2014 21:19:56 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Tue, 10 Jun 2014 21:20:03 +0200 (CEST)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0518A2002C for ; Tue, 10 Jun 2014 21:20:05 +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 CxmQkTvjBdFr; Tue, 10 Jun 2014 21:19:56 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 55E8920013; Tue, 10 Jun 2014 21:20:04 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 243EC2D61191; Tue, 10 Jun 2014 21:20:03 +0200 (CEST)
Date: Tue, 10 Jun 2014 21:20:03 +0200
From: Juergen Schoenwaelder 
To: netmod@ietf.org
Message-ID: <20140610192003.GD28878@elstar.local>
Mail-Followup-To: netmod@ietf.org
References: <20140602081714.GC92342@elstar.local>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20140602081714.GC92342@elstar.local>
User-Agent: Mutt/1.4.2.3i
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/Vg6Ek2RN1hSnhYRcAuIlO2tS5vs
Subject: Re: [netmod] undecided Y21 statement to define new XPath functions in a module
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
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, 10 Jun 2014 19:20:08 -0000

On Mon, Jun 02, 2014 at 10:17:14AM +0200, Juergen Schoenwaelder wrote:
> We need to decide whether this is in scope of YANG 1.1 or not.
> 
> Is there a risk that this may get abused, leading to non-interoperable
> vendor specific sets of functions in XPATH expressions?
> 

Interim proposal:

  Proposal: Reject this request for a YANG statement to declare new
  XPATH functions but add a new issue to define additional XPATH
  functions that we know are needed to make for examples identity
  derivations accessible.

If you disagree, please speak up by June 18th.

/js

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


From nobody Tue Jun 10 12:21:22 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9511F1A0279 for ; Tue, 10 Jun 2014 12:20:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.201
X-Spam-Level: 
X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qnET1mlNh2bG for ; Tue, 10 Jun 2014 12:20:39 -0700 (PDT)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9AEB1A0081 for ; Tue, 10 Jun 2014 12:20:38 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 2772071E for ; Tue, 10 Jun 2014 21:20:36 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id pV8WBe0Q3njz for ; Tue, 10 Jun 2014 21:20:28 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Tue, 10 Jun 2014 21:20:35 +0200 (CEST)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 01E4520017 for ; Tue, 10 Jun 2014 21:20:37 +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 6pQfKf0nT9Yt; Tue, 10 Jun 2014 21:20:36 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5D1B020013; Tue, 10 Jun 2014 21:20:36 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 49D0B2D611A2; Tue, 10 Jun 2014 21:20:36 +0200 (CEST)
Date: Tue, 10 Jun 2014 21:20:36 +0200
From: Juergen Schoenwaelder 
To: netmod@ietf.org
Message-ID: <20140610192036.GE28878@elstar.local>
Mail-Followup-To: netmod@ietf.org
References: <20140602081915.GD92342@elstar.local>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20140602081915.GD92342@elstar.local>
User-Agent: Mutt/1.4.2.3i
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/qU37f45JlVO48RKnvjVQxrE8pDU
Subject: Re: [netmod] undecided Y22 support constraints on unions
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
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, 10 Jun 2014 19:20:45 -0000

On Mon, Jun 02, 2014 at 10:19:15AM +0200, Juergen Schoenwaelder wrote:
> We need to decide whether this is in scope of YANG 1.1 or not.
> 
> It remains somewhat unclear what exactly the problem is that this
> is supposed to solve.
> 

Interim proposal:

  Proposal: Reject the issue and add a new issue that a clarification
  is needed about the nature of unions and that they primarily are
  needed for validation.

If you disagree, please speak up by June 18th.

/js

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


From nobody Tue Jun 10 12:21:31 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD7751A0282 for ; Tue, 10 Jun 2014 12:21:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.201
X-Spam-Level: 
X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CyYdp44ZpDQ0 for ; Tue, 10 Jun 2014 12:21:08 -0700 (PDT)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57A441A0081 for ; Tue, 10 Jun 2014 12:21:08 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id AD29471E for ; Tue, 10 Jun 2014 21:21:05 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id TyLLbk9xXGLz for ; Tue, 10 Jun 2014 21:20:58 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Tue, 10 Jun 2014 21:21:05 +0200 (CEST)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8E56220013 for ; Tue, 10 Jun 2014 21:21:06 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id ivrVnhCWnetN; Tue, 10 Jun 2014 21:21:06 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0508C20017; Tue, 10 Jun 2014 21:21:06 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id DF8DE2D611C8; Tue, 10 Jun 2014 21:21:05 +0200 (CEST)
Date: Tue, 10 Jun 2014 21:21:05 +0200
From: Juergen Schoenwaelder 
To: netmod@ietf.org
Message-ID: <20140610192105.GF28878@elstar.local>
Mail-Followup-To: netmod@ietf.org
References: <20140602082054.GE92342@elstar.local>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20140602082054.GE92342@elstar.local>
User-Agent: Mutt/1.4.2.3i
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/ZD-RseFlkTRPMX3EIbVkFmZB-Ak
Subject: Re: [netmod] undecided Y26 allow mandatory nodes in augment
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
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, 10 Jun 2014 19:21:13 -0000

On Mon, Jun 02, 2014 at 10:20:54AM +0200, Juergen Schoenwaelder wrote:
> We need to decide whether this is in scope of YANG 1.1 or not.
> 
> What are the implications of allowing mandatory in augments? Can this
> be misused and do we need to constraint this?
> 

Interim proposal:

  Proposal: Open this issue even though a possible solution remains
  rather unclear.

If you disagree, please speak up by June 18th.

/js

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


From nobody Tue Jun 10 12:22:04 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A55A1A0282 for ; Tue, 10 Jun 2014 12:21:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.201
X-Spam-Level: 
X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gG4xiJ8z52_7 for ; Tue, 10 Jun 2014 12:21:42 -0700 (PDT)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC72C1A0081 for ; Tue, 10 Jun 2014 12:21:42 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 10B3771E for ; Tue, 10 Jun 2014 21:21:40 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id agngR3WvujZ6 for ; Tue, 10 Jun 2014 21:21:32 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Tue, 10 Jun 2014 21:21:39 +0200 (CEST)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id E771C20017 for ; Tue, 10 Jun 2014 21:21:40 +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 7HEHp9Oh9Zvk; Tue, 10 Jun 2014 21:21:32 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4F02F20013; Tue, 10 Jun 2014 21:21:40 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 3BC372D611D9; Tue, 10 Jun 2014 21:21:40 +0200 (CEST)
Date: Tue, 10 Jun 2014 21:21:40 +0200
From: Juergen Schoenwaelder 
To: netmod@ietf.org
Message-ID: <20140610192140.GG28878@elstar.local>
Mail-Followup-To: netmod@ietf.org
References: <20140602082231.GF92342@elstar.local>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20140602082231.GF92342@elstar.local>
User-Agent: Mutt/1.4.2.3i
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/sLXzyvu7spvATV_U2z4W9be15IM
Subject: Re: [netmod] undecided Y27 allow mandatory nodes in an updated module
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
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, 10 Jun 2014 19:21:47 -0000

On Mon, Jun 02, 2014 at 10:22:31AM +0200, Juergen Schoenwaelder wrote:
> We need to decide whether this is in scope of YANG 1.1 or not.
> 
> What are the implications of allowing the addition of mandatory
> nodes? Does this need to be restricted to cases where it is not
> harmful (e.g. if the nodes are part of a new feature)?
> 

Interim proposal:

   Proposal: Open this issue.

If you disagree, please speak up by June 18th.

/js

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


From nobody Tue Jun 10 12:22:25 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 992261A0295 for ; Tue, 10 Jun 2014 12:22:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.201
X-Spam-Level: 
X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ZXBsQPDafP0 for ; Tue, 10 Jun 2014 12:22:08 -0700 (PDT)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1F071A0081 for ; Tue, 10 Jun 2014 12:22:08 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 08ABD71E for ; Tue, 10 Jun 2014 21:22:06 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id tdKoSsEUonHr for ; Tue, 10 Jun 2014 21:21:58 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Tue, 10 Jun 2014 21:22:05 +0200 (CEST)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id B296B20017 for ; Tue, 10 Jun 2014 21:22:06 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id R1VPnO1zYOFi; Tue, 10 Jun 2014 21:21:57 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1CA2C20013; Tue, 10 Jun 2014 21:22:06 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id F05372D611FF; Tue, 10 Jun 2014 21:22:05 +0200 (CEST)
Date: Tue, 10 Jun 2014 21:22:05 +0200
From: Juergen Schoenwaelder 
To: netmod@ietf.org
Message-ID: <20140610192205.GH28878@elstar.local>
Mail-Followup-To: netmod@ietf.org
References: <20140602082421.GG92342@elstar.local>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20140602082421.GG92342@elstar.local>
User-Agent: Mutt/1.4.2.3i
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/j_RvUkmgWXvsVHBPivMiGhIzLRQ
Subject: Re: [netmod] undecided Y33 add 'attribute' statement
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
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, 10 Jun 2014 19:22:11 -0000

On Mon, Jun 02, 2014 at 10:24:21AM +0200, Juergen Schoenwaelder wrote:
> We need to decide whether this is in scope of YANG 1.1 or not.
> 
> Is there a risk of attributes getting abused? How do we define
> metadata? We do not seem to want people to use attributes to model
> data.
> 

Interim proposal:

   Proposal: Reject this issue.

If you disagree, please speak up by June 18th.

/js

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


From nobody Tue Jun 10 12:22:59 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C92511A0292 for ; Tue, 10 Jun 2014 12:22:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.201
X-Spam-Level: 
X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kM5DK8_iYYVL for ; Tue, 10 Jun 2014 12:22:41 -0700 (PDT)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D0C01A0081 for ; Tue, 10 Jun 2014 12:22:41 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id DFCF8F85 for ; Tue, 10 Jun 2014 21:22:38 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id v57VK0nnX_07 for ; Tue, 10 Jun 2014 21:22:31 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Tue, 10 Jun 2014 21:22:38 +0200 (CEST)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id B514220017 for ; Tue, 10 Jun 2014 21:22:39 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id HGsQja27cDfG; Tue, 10 Jun 2014 21:22:38 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1E09820013; Tue, 10 Jun 2014 21:22:39 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 0B0D22D6120F; Tue, 10 Jun 2014 21:22:39 +0200 (CEST)
Date: Tue, 10 Jun 2014 21:22:39 +0200
From: Juergen Schoenwaelder 
To: netmod@ietf.org
Message-ID: <20140610192239.GI28878@elstar.local>
Mail-Followup-To: netmod@ietf.org
References: <20140602082634.GH92342@elstar.local>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20140602082634.GH92342@elstar.local>
User-Agent: Mutt/1.4.2.3i
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/sms7AIlKyDvowhXfyXljsVUX5GI
Subject: Re: [netmod] undecided Y36 associate a notification with a data node
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
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, 10 Jun 2014 19:22:42 -0000

On Mon, Jun 02, 2014 at 10:26:34AM +0200, Juergen Schoenwaelder wrote:
> We need to decide whether this is in scope of YANG 1.1 or not.
> 
> There are several questions associated with this and perhaps this
> requires some solution think through in order to understand the
> implications in more details.
> 

Interim proposal:

  Proposal: Reject this issue. May be considered for YANG 2.0.

If you disagree, please speak up by June 18th.

/js

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


From nobody Tue Jun 10 12:23:44 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A15341A02A8 for ; Tue, 10 Jun 2014 12:23:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.201
X-Spam-Level: 
X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3MbmU7lJiSfb for ; Tue, 10 Jun 2014 12:23:09 -0700 (PDT)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0AC71A0299 for ; Tue, 10 Jun 2014 12:23:08 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 3C43671E for ; Tue, 10 Jun 2014 21:23:06 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id DiEtSYjLdiUA for ; Tue, 10 Jun 2014 21:22:58 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Tue, 10 Jun 2014 21:23:05 +0200 (CEST)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 201BC20017 for ; Tue, 10 Jun 2014 21:23:07 +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 zkwCESXYWRQE; Tue, 10 Jun 2014 21:23:06 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7D8D320013; Tue, 10 Jun 2014 21:23:06 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 63D9A2D61235; Tue, 10 Jun 2014 21:23:06 +0200 (CEST)
Date: Tue, 10 Jun 2014 21:23:06 +0200
From: Juergen Schoenwaelder 
To: netmod@ietf.org
Message-ID: <20140610192306.GJ28878@elstar.local>
Mail-Followup-To: netmod@ietf.org
References: <20140602082830.GI92342@elstar.local>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20140602082830.GI92342@elstar.local>
User-Agent: Mutt/1.4.2.3i
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/GzRai_rRAMrI0PjPmbu2aTxyoug
Subject: Re: [netmod] undecided Y37 allow notifications to be derived from other notifications
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
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, 10 Jun 2014 19:23:10 -0000

On Mon, Jun 02, 2014 at 10:28:30AM +0200, Juergen Schoenwaelder wrote:
> We need to decide whether this is in scope of YANG 1.1 or not.
> 
> It remains unclear whether this feature is needed for real-world data
> models or whether existing groupings get us there alreadly to a large
> extend.
> 

Interim proposal:

  Proposal: Reject this issue. Reject supported by LL, AB, and MB.

If you disagree, please speak up by June 18th.

/js

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


From nobody Tue Jun 10 12:23:55 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F27311A028B for ; Tue, 10 Jun 2014 12:23:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.201
X-Spam-Level: 
X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZRBIsnq9yKAT for ; Tue, 10 Jun 2014 12:23:36 -0700 (PDT)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 526581A0081 for ; Tue, 10 Jun 2014 12:23:36 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id A3DB471E for ; Tue, 10 Jun 2014 21:23:33 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id N6RLn953IuWH for ; Tue, 10 Jun 2014 21:23:26 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Tue, 10 Jun 2014 21:23:33 +0200 (CEST)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 858C92002C for ; Tue, 10 Jun 2014 21:23:34 +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 djIOKaS1UiyO; Tue, 10 Jun 2014 21:23:34 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C4D6B20013; Tue, 10 Jun 2014 21:23:33 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id AC6CE2D61246; Tue, 10 Jun 2014 21:23:33 +0200 (CEST)
Date: Tue, 10 Jun 2014 21:23:33 +0200
From: Juergen Schoenwaelder 
To: netmod@ietf.org
Message-ID: <20140610192333.GK28878@elstar.local>
Mail-Followup-To: netmod@ietf.org
References: <20140602082956.GJ92342@elstar.local>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20140602082956.GJ92342@elstar.local>
User-Agent: Mutt/1.4.2.3i
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/qlT37DgpJ1SsXG6R_sr24n9vYjs
Subject: Re: [netmod] undecided Y39 define the terms system/user-controlled instances
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
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, 10 Jun 2014 19:23:41 -0000

On Mon, Jun 02, 2014 at 10:29:56AM +0200, Juergen Schoenwaelder wrote:
> We need to decide whether this is in scope of YANG 1.1 or not.
> 

Interim proposal:

   Proposal: Reject since this is an architectural distinction and
   should thus should be defined generically elsewhere. It does not
   seem to be a YANG 1.1 issue.

If you disagree, please speak up by June 18th.

/js

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


From nobody Tue Jun 10 12:24:17 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D5151A0292 for ; Tue, 10 Jun 2014 12:24:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.201
X-Spam-Level: 
X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g3j5ApkDkKUp for ; Tue, 10 Jun 2014 12:24:04 -0700 (PDT)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 891481A0081 for ; Tue, 10 Jun 2014 12:24:04 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id E2A7571E for ; Tue, 10 Jun 2014 21:24:01 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id Vp7qPjwVeamg for ; Tue, 10 Jun 2014 21:23:54 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Tue, 10 Jun 2014 21:24:01 +0200 (CEST)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id C16CC20017 for ; Tue, 10 Jun 2014 21:24:02 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id qRmM726Xh89X; Tue, 10 Jun 2014 21:24:02 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id F3DC420013; Tue, 10 Jun 2014 21:24:01 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id E0FCC2D61254; Tue, 10 Jun 2014 21:24:01 +0200 (CEST)
Date: Tue, 10 Jun 2014 21:24:01 +0200
From: Juergen Schoenwaelder 
To: netmod@ietf.org
Message-ID: <20140610192401.GL28878@elstar.local>
Mail-Followup-To: netmod@ietf.org
References: <20140602083137.GK92342@elstar.local>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20140602083137.GK92342@elstar.local>
User-Agent: Mutt/1.4.2.3i
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/nwL2i8nWXqNmlHK5ZaUvO5M2mOY
Subject: Re: [netmod] undecided Y50 additional extension grammar validation
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
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, 10 Jun 2014 19:24:06 -0000

On Mon, Jun 02, 2014 at 10:31:37AM +0200, Juergen Schoenwaelder wrote:
> We need to decide whether this is in scope of YANG 1.1 or not.
> 
> Is the added value worth the complexity this introduces? A YANG
> parser would have to evaluate the grammar of extension statements
> at runtime.
> 

Interim proposal:

  Proposal: Reject the issue since it can be done as an extension and
  does not need to be part of YANG 1.1.

If you disagree, please speak up by June 18th.

/js

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


From nobody Tue Jun 10 12:24:54 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A19B41A0282 for ; Tue, 10 Jun 2014 12:24:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.201
X-Spam-Level: 
X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IjTOTiWml_wQ for ; Tue, 10 Jun 2014 12:24:33 -0700 (PDT)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F62A1A0081 for ; Tue, 10 Jun 2014 12:24:33 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 6E00A71E for ; Tue, 10 Jun 2014 21:24:30 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id U9yKD6BMQ0Xj for ; Tue, 10 Jun 2014 21:24:23 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Tue, 10 Jun 2014 21:24:30 +0200 (CEST)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4C9D22002C for ; Tue, 10 Jun 2014 21:24:31 +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 OunLO4YcLP-y; Tue, 10 Jun 2014 21:24:22 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9B3AB20017; Tue, 10 Jun 2014 21:24:30 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 797CC2D6127A; Tue, 10 Jun 2014 21:24:30 +0200 (CEST)
Date: Tue, 10 Jun 2014 21:24:30 +0200
From: Juergen Schoenwaelder 
To: netmod@ietf.org
Message-ID: <20140610192430.GM28878@elstar.local>
Mail-Followup-To: netmod@ietf.org
References: <20140602083330.GL92342@elstar.local>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20140602083330.GL92342@elstar.local>
User-Agent: Mutt/1.4.2.3i
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/S_zbNw-ZnxDX3ani00ImiOd-GK8
Subject: Re: [netmod] undecided Y54 remove the advertisement of conformance information in NETCONF hello message
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
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, 10 Jun 2014 19:24:34 -0000

On Mon, Jun 02, 2014 at 10:33:30AM +0200, Juergen Schoenwaelder wrote:
> We need to decide whether this is in scope of YANG 1.1 or not.
> 
> This may be subsumed by Y45 (OPEN) and Y16 (OPEN).
> 

Interim proposal:

  Proposal: Open this issue as it is related to the other conformance
  related issues.

If you disagree, please speak up by June 18th.

/js

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


From nobody Tue Jun 10 12:25:31 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01AAA1A0081 for ; Tue, 10 Jun 2014 12:25:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.201
X-Spam-Level: 
X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TNl2UWAm0Ndh for ; Tue, 10 Jun 2014 12:25:03 -0700 (PDT)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7AB4F1A0295 for ; Tue, 10 Jun 2014 12:25:03 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id C7CC271E; Tue, 10 Jun 2014 21:25:00 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 9TFtQ6Hudafj; Tue, 10 Jun 2014 21:24:53 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 10 Jun 2014 21:25:00 +0200 (CEST)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7D7E620017; Tue, 10 Jun 2014 21:25: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 h-U6u_HpBApM; Tue, 10 Jun 2014 21:24:52 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 90C2120013; Tue, 10 Jun 2014 21:25:00 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 7D1312D612A8; Tue, 10 Jun 2014 21:25:00 +0200 (CEST)
Date: Tue, 10 Jun 2014 21:25:00 +0200
From: Juergen Schoenwaelder 
To: "Peyman Owladi -X (powladi - Ensoft Ltd at Cisco)" 
Message-ID: <20140610192500.GA29064@elstar.local>
Mail-Followup-To: "Peyman Owladi -X (powladi - Ensoft Ltd at Cisco)" , "netmod@ietf.org" 
References: <20140601152026.GL90395@elstar.local> <013A9B371AC6DF4C8AD261897D8F243E10B00381@xmb-aln-x08.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <013A9B371AC6DF4C8AD261897D8F243E10B00381@xmb-aln-x08.cisco.com>
User-Agent: Mutt/1.4.2.3i
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/6-l-ZxwnfylpM9QHdS1GrFVSras
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] strawman REJECT Y51 support for long running commands
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
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, 10 Jun 2014 19:25:08 -0000

On Tue, Jun 10, 2014 at 02:58:05PM +0000, Peyman Owladi -X (powladi - Ensoft Ltd at Cisco) wrote:
> Is it fair to say that with the current Yang (1.0) support, the design
> pattern specified in the original mail (attached for reference) is the
> best way to represent this construct?

I can't say whether this is the best or just some way to do it.
 
> And to clarify:
> 
> > A proper (that is less complex) solution requires specific protocol
> > support and thus this falls out of scope for YANG 1.1.
> 
> Does this mean that the suggested formulaic expansion in the attached mail
> (which was intended to avoid the need for specific protocol support) is
> missing some functionality or is limited in some way, or just that
> performing the formulaic expansion is too complex?

It is unclear whether notification channels are the proper way to
deliver partial results. CMIP back in last century had something
called linked responses, translated into NETCONF, you invoke an rpc
but you receive not just one rpc-reply but multiple linked rpc-reply
elements (which can also solve issues with very long rpc-replys).
 
> (We have events of this form that need modelling, so in any case I'm
> looking to validate the design pattern for consistency/completeness. In
> lieu of native support, our best answer so far is to use the design
> pattern described with an extension for interested implementations to link
> the related primary RPC, cancellation RPC and notification.)

One concern is usually access control. If you use notification
channels for partial results, you might get into odd access control
configuration issues (since allowing an RPC now also involves allowing
at least some notifications). Hence, a solution that can build on
protocol support may not use notifications this way.

/js

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


From nobody Tue Jun 10 12:28:07 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 709CD1A0081 for ; Tue, 10 Jun 2014 12:27:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.201
X-Spam-Level: 
X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K1cjinq-390m for ; Tue, 10 Jun 2014 12:27:48 -0700 (PDT)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDDB31A027F for ; Tue, 10 Jun 2014 12:27:47 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 1CB3E71E for ; Tue, 10 Jun 2014 21:27:45 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 1YhXBFShCamq for ; Tue, 10 Jun 2014 21:27:36 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Tue, 10 Jun 2014 21:27:43 +0200 (CEST)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id A8B1020017 for ; Tue, 10 Jun 2014 21:27:44 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id GfaiV0aRbd_X; Tue, 10 Jun 2014 21:27:42 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5EAC020013; Tue, 10 Jun 2014 21:27:38 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id D3CA82D61317; Tue, 10 Jun 2014 21:27:36 +0200 (CEST)
Date: Tue, 10 Jun 2014 21:27:36 +0200
From: Juergen Schoenwaelder 
To: netmod@ietf.org
Message-ID: <20140610192736.GB29064@elstar.local>
Mail-Followup-To: netmod@ietf.org
References: <20140610191652.GA28878@elstar.local>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="zhXaljGHf11kAtnf"
Content-Disposition: inline
In-Reply-To: <20140610191652.GA28878@elstar.local>
User-Agent: Mutt/1.4.2.3i
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/J8iK8zq3qY7cxvL92h4-a26aRUQ
Subject: Re: [netmod] draft minutes of the 2014-06-04 virtual interim meeting
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
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, 10 Jun 2014 19:27:50 -0000

--zhXaljGHf11kAtnf
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Tue, Jun 10, 2014 at 09:16:52PM +0200, Juergen Schoenwaelder wrote:
> Hi,
> 
> attached please find the minutes of the 2014-06-04 virtual interim
> meeting. Note that a final version needs to be submitted within 10
> days - so please send any corrections of the minutes by Friday June
> 13th.
> 

And now with the promised attachment...

/js

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

--zhXaljGHf11kAtnf
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="netmod-2014-06-04-minutes.txt"

=============================================================
NETCONF Data Modeling Language WG (netmod)
1st Virtual Interim
Wednesday, June 4th, 2014, 16:00-16:00 CEST
Minutes Benoit Claise, Juergen Schoenwaelder
=============================================================

* Participants

  - JS = Juergen Schoenwaelder
  - BC = Benoit Claise
  - AZ = Alex Zhankin
  - AB = Andy Bierman
  - BZ = Bernd Zeuner
  - DR = Dan Romascanu
  - JT = Jason Sterne
  - KW = Kent Watsen
  - LL = Lada Lotka
  - MB = Martin Bjorklund
  - PH = Peter van Horne
  - XL = Xufeng Liu
  - AN = anonymous

* Summary

  The goal of the 1st virtual interim meeting was to decide on the
  submitted issues marked NEW and without a strawman position (or a
  strawman position that let to discussions) whether they are in scope
  (OPEN) of the YANG 1.1 effort or out of scope (REJECT).

* Y31 allow require-instance in leafref

  Proposal: Keep Y31 open as already being discussed on the mailing
  list. LL, MB, AB, AZ in favor of moving this to open.

* Y09 introduce optional keys

  LL things a key not present simply does not contribute to the
  uniqueness requirement.

  AB against it since it breaks restconf. Why is this really needed?
  
  LL sees no problem with opening and to see whether a solution can be
  found.
  
  AB how does this map to things like SQL? What are the interactions
  with optional keys?

  AZ we should perhaps abstract from implementation details.

  MB volunteers to come up with a concrete proposal and then we can
  decide whether the complexity is under control.

  KW does not see a simple mapping to SQL. I tend to agree with AB
  that this is perhaps complex. Why would you not use artificial keys?

  MB says that in some cases the data model would be more natural.

  AB says if a leaf is optional, then it is really not part of the key
  and you might be picking the wrong thing as a key.

  AB asks what happens if there are multiple optional keys? Can they
  all be optional?

  BC asks whether AB is afraid for the combination of multiple
  optional keys?

  AB responds that the key is crucial for naming.

  Proposal: Move this to open for now. Some concerns from KW and
  AB. We might revisit this issue later if the complexity/cost of a
  solution is too high. Action item for MB to provide a detailed
  solution proposal.

* Y19 we need a better unique

  LL says that nested lists can already be now included in XPATH, at
  least the DSDL mapping handles this.

  MB says we need to make sure that the current unique works
  correctly with the DSDL and clarify RFC 6020.

  MB is fine with the interpretation of the DSDL draft. But MB also
  says that we need to check whether the DSDL mapping solution
  achieves the same as the issue writeup.

  AB is concerned that this adds complexity.

  LL got concerned that if semantics deviate from what the DSDL
  mapping currently does, then he is against accepting this.

  AB remarks that maybe it is easier to tell people how to use must
  statements to achieve similar results.

  AB is concerned that we end up with two unique statments and then we
  need to tell everybody what the difference is and when to use which;
  not convinced that this better unique is needed.

  PH this sounds more like an optimization.

  PO says it does not break backwards compatibility.

  Proposal: Reject this request for a new feature but clarify the
  semantics of unique in RFC 6020bis (might require to open a separate
  clarification issue). A new and more powerful unique seems more like
  a YANG 2.0 work item than a YANG 1.1 work item. The consensus on
  this was rough (MB prefers to have this issue opened).

* Y21 statement to define new XPath functions in a module

  MB we apparently need a few more XPATH functions. The question is
  whether these XPATH functions are hard wired in the language
  (requiring a language update for each addition).

  LL says that implementations simply can't ignore the XPATH functions
  and hence it does not satisfy the requirement of the extension
  statement.

  AB is concerned about interoperability problems.

  AZ thinks it is a bad idea to define XPATH function in YANG itself.
  
  MB says that in the IETF, we would need to bump the YANG version
  number when we add new XPATH functions.
  
  PO says the alternative today is to implement an extension to
  support the same function (which would be ignored by existing
  implementations).

  Proposal: Reject this request for a YANG statement to declare new
  XPATH functions but add a new issue to define additional XPATH
  functions that we know are needed to make for examples identity
  derivations accessible. 

* Y22 support constraints on unions

  AB says it is not clear which problem is being solved. Why does it
  need to get exposed which type statement of the union got selected?
  
  PO how is it well defined what the value set is?
  
  AB says that if a value matches any of the types in the union, the
  value is valid. The value set hence is really the union of the types
  involved.

  PO says in XML and JSON, you can have the type identified. What YANG
  does is sufficient for validation.

  LL agrees that this should be rejected.

  MB agrees to reject as well.

  PO suggests to clarify that this is primarily for validation and not
  necessarily for type identification.

  LL says there is text that types are tried sequentially.

  Proposal: Reject the issue and add a new issue that a clarification
  is needed about the nature of unions and that they primarily are
  needed for validation.

* Y26 allow mandatory nodes in augment
  
  MB believes the current rules are too strict but removing the rule
  would allow things to break easily.

  LL says the overarching principle is that published modules are not
  allowed to become invalid by augments.

  AB says that if an old client implements old module A and later a
  new module augmenting module A comes along but things stop working.
  This breaks an old manager.

  AB says there are ways how this can be done if a module has been
  designed for such mandatory augmentations.

  MB says that in certain cases such a mandatory augmentation is fine;
  the problem is defining and writing down the rules.

  PO asks whether it is possible to create rules like augmentations
  with mandatory is allowed if the augmentation is guarded by a when
  statement?

  MB says it is difficult to write up such rules. Suggests to open
  this and reject it later if we can't come up with good rules.

  AB says unless we have service level conformance, the mandatory
  property is a scoped to a module.

  PO asks whether we can just restrict it to what has come up in the
  interfaces data model?

  AB is concerned that it will not be a single case. It is important
  that we protect old clients. It will, however, be difficult for a
  YANG compiler to validate this.

  AZ supports this to be open since we have an actual use case.

  JS asks whether it is possible to relax the current rule with lots
  of explanatory text, assuming that implementations will generate
  warnings based on the current restrictive rule but humans may choose
  to ignore them if they checked that indeed old implementations do
  not break.

  Proposal: Open this issue even though a possible solution remains
  rather unclear.

* Y27 allow mandatory nodes in an updated module

  MB says the intention of the text was to protect old clients.
  However, different from Y26, the revision number changes here.
  MB suggests this to be opened.
  
  AB and LL agree to open this.
  
  Proposal: Open this issue.

* Y33 add 'attribute' statement

  LL says if there are only a really small set of attributes that we
  need, then he is fine with rejecting it.

  AB is OK with a reject since it is likely only a small number of
  attributes that we need.

  AB believes such an attribute statement will likely cause people to
  misuse it.

  Proposal: Reject this issue.

* Y36 associate a notification with a data node

  MB says that he did not have customers asking for this but Tail-f
  has something similar called actions (inlined rpcs). If we do this,
  it makes sense to add inline RPCs as well.

  AZ sees a use case.

  PO sees value in notification source properties attached to leafs.

  PO says that this is essentially about associating a notification
  with a resource object.

  MB says this is a nice to have feature because you can do
  without. Sounds more like a YANG 2.0 issue.

  AB agrees that this is an optimization, perhaps this can also be
  dealt with by certain design patterns.

  JS suggests that one could also think about guidelines how to
  structure notifications to make resource identification easier.

  Proposal: Reject this issue. May be considered for YANG 2.0.

* Y37 allow notifications to be derived from other notifications

  MB says this is an optimization, nice to have, but not critical.
   
  AB says this is convenient and simple to implement.
   
  JS says that for other things we expect designers to explicitly
  design reusable things, we do not allow uses on an arbitrary
  container.

  Proposal: Reject this issue. Reject supported by LL, AB, and MB.

* Y39 define the terms system/user-controlled instances

  PO asks how exactly is this envisioned to be used?

  MB is concerned that it does not belong into the YANG language
  definition since this seems to be more architectural.

  LL agrees that with MB, perhaps this can go into the architecture
  document? Or in a design pattern document.

  PO asks whether there are any consequences of not putting this into
  the YANG 1.1 specification?

  LL answers no, the question is more whether we define this in a
  single place instead of multiple places. Right now, this is defined
  in those data model documents that require this distinction.

  Proposal: Reject since this is an architectural distinction and
  should thus should be defined generically elsewhere. It does not
  seem to be a YANG 1.1 issue.

* Y50 additional extension grammar validation

  MB says this is a nice to heave feature for tool writers, users of
  tools likely do not care.

  PO says that this makes extensions more readable and well
  defined. But yes, this is a nice to have feature.

  MB says that Tail-f has an extension for this but it is a nice to
  have feature and not essential

  AB is concerned that this asks compilers to interpret ABNF at
  runtime.

  PO says that their implementation is not more constrained / precise
  than the existing YANG grammar.

  JS says if this can be done as an extension, why make it part of
  YANG 1.1? Simply write an extension YANG module.

  Proposal: Reject the issue since it can be done as an extension and
  does not need to be part of YANG 1.1.

* Y54 remove the advertisement of conformance information in NETCONF hello message

  MB says all conformance issues need to be discussed together and
  hence we should keep this open as well.

  LL suggests to write a new issue Y55 that consolidates all
  conformance related issues.
  
  AB says the way this is written it is not workable.
  
  JS suggests to move Y54 as a solution of Y16.

  JS does not like adding new issues, he prefers to cluster
  conformance related issues.

  Proposal: Open this issue as it is related to the other conformance
  related issues.

--zhXaljGHf11kAtnf--


From nobody Tue Jun 10 12:58:21 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21DC01A02BC for ; Tue, 10 Jun 2014 12:57:56 -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=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nXJAp4ur8ZCS for ; Tue, 10 Jun 2014 12:57:54 -0700 (PDT)
Received: from elasmtp-galgo.atl.sa.earthlink.net (elasmtp-galgo.atl.sa.earthlink.net [209.86.89.61]) by ietfa.amsl.com (Postfix) with ESMTP id A46D51A0284 for ; Tue, 10 Jun 2014 12:57:54 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=PSu6RkFZfjoLv9/n2NkhM1317YN6fsGX/C1SEylVCdO4QRF6KkslMc4SpzVIdNWV; h=Message-ID:Date:From:Reply-To:To:Subject:Cc:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP;
Received: from [209.86.224.43] (helo=elwamui-norfolk.atl.sa.earthlink.net) by elasmtp-galgo.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1WuSB5-0004oZ-Ra; Tue, 10 Jun 2014 15:57:51 -0400
Received: from 76.254.54.24 by webmail.earthlink.net with HTTP; Tue, 10 Jun 2014 15:57:51 -0400
Message-ID: <981035.1402430271758.JavaMail.root@elwamui-norfolk.atl.sa.earthlink.net>
Date: Tue, 10 Jun 2014 12:57:51 -0700 (GMT-07:00)
From: Randy Presuhn 
To: Juergen Schoenwaelder ,  "Peyman Owladi -X (powladi - Ensoft Ltd at Cisco)" 
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Mailer: EarthLink Zoo Mail 1.0
X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88864c4c3a38ce6fd812f7b4da976510523c2644f933b86c8cf350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 209.86.224.43
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/fS6QhZH0aK0Ug17onCz0EbKy32M
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] strawman REJECT Y51 support for long running commands
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Randy Presuhn 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 10 Jun 2014 19:57:56 -0000

Hi -

>From: Juergen Schoenwaelder 
>Sent: Jun 10, 2014 12:25 PM
>To: "Peyman Owladi -X (powladi - Ensoft Ltd at Cisco)" 
>Cc: "netmod@ietf.org" 
>Subject: Re: [netmod] strawman REJECT Y51 support for long running commands
>
>On Tue, Jun 10, 2014 at 02:58:05PM +0000, Peyman Owladi -X (powladi - Ensoft Ltd at Cisco) wrote:
>> Is it fair to say that with the current Yang (1.0) support, the design
>> pattern specified in the original mail (attached for reference) is the
>> best way to represent this construct?
>
>I can't say whether this is the best or just some way to do it.
> 
>> And to clarify:
>> 
>> > A proper (that is less complex) solution requires specific protocol
>> > support and thus this falls out of scope for YANG 1.1.
>> 
>> Does this mean that the suggested formulaic expansion in the attached mail
>> (which was intended to avoid the need for specific protocol support) is
>> missing some functionality or is limited in some way, or just that
>> performing the formulaic expansion is too complex?
>
>It is unclear whether notification channels are the proper way to
>deliver partial results. CMIP back in last century had something
>called linked responses, translated into NETCONF, you invoke an rpc
>but you receive not just one rpc-reply but multiple linked rpc-reply
>elements (which can also solve issues with very long rpc-replys).

A bit of additional background on linked replies -

In CMIP gets, sets, deletes, and actions may, through the use
of scoping and filtering, iterate over multiple object
instances.  Each linked reply conveys the result of
that operation when attempted on a particular object
instance as the managed system iterates through the
set of object instances selected by the scope/filter/etc
on the request.

Works well, but it's strongly tied to having a clear notion
of object instances in a containment hierarchy, and isn't
really applicable for long-running operations, and, FWIW,
did precipitate the addition of the cancel-get operation
to CMIP.

Randy


From nobody Tue Jun 10 21:22:16 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 090D31A0338; Tue, 10 Jun 2014 21:22:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.401
X-Spam-Level: 
X-Spam-Status: No, score=-2.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tZZwoV6dM038; Tue, 10 Jun 2014 21:22:07 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 529CE1A02F4; Tue, 10 Jun 2014 21:22:06 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BIH26045; Wed, 11 Jun 2014 04:22:04 +0000 (GMT)
Received: from nkgeml409-hub.china.huawei.com (10.98.56.40) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 11 Jun 2014 05:22:03 +0100
Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.193]) by nkgeml409-hub.china.huawei.com ([10.98.56.40]) with mapi id 14.03.0158.001; Wed, 11 Jun 2014 12:22:00 +0800
From: Qin Wu 
To: "Tissa Senevirathne (tsenevir)" , "time@ietf.org" 
Thread-Topic: YANG models for OAM
Thread-Index: Ac+E3qlMyPi638vnRGmjYh75Wx+edAATLCxA
Date: Wed, 11 Jun 2014 04:21:59 +0000
Message-ID: 
References: 
In-Reply-To: 
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.138.41.180]
Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABA84549D17nkgeml501mbschi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/xxXWQRxN57uK9J3Htj4mY7aFhj8
Cc: "l2vpn@ietf.org" , "opsawg@ietf.org" , "nvo3@ietf.org" , "netmod@ietf.org" , "trill@ietf.org" 
Subject: Re: [netmod] YANG models for OAM
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 11 Jun 2014 04:22:11 -0000

--_000_B8F9A780D330094D99AF023C5877DABA84549D17nkgeml501mbschi_
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64

SGksIFRpc3NhOg0KVGhhbmtzIGZvciBpbml0aWF0aW5nIGRpc2N1c3Npb24gb24gdGhpcyB0b3Bp
Yy4NClVuaWZpZWQgT0FNIGZvciBtdWx0aS1MYXllciBuZXR3b3JrIGlzIGEgZ29vZCBpZGVhIHRv
IG1lLg0KZHJhZnQtd3ctb3BzYXdnLW11bHRpLWxheWVyLW9hbS0wMCB3ZSBwcm9wb3NlZCBpbiBv
cHNhd2cgbGFpZCBvdXQgdGhlIGFuIGluaXRpYWwgZGVzY3JpcHRpb24gb2YgdGhlIHByb2JsZW0u
DQpUaGUgcXVlc3Rpb24gdG8gZHJhZnQtdGlzc2EtbmV0bW9kLW9hbSBpcw0KSSBhbSB3b25kZXJp
bmcgaG93IHRoaXMgZ2VuZXJpYyBZYW5nIE1vZGVsIGNhbiBiZSBhcHBsaWVkIHRvIFNGQyBlbnZp
cm9ubWVudD8NCkhvdyBkbyB5b3Ugc3VwcG9ydCB0aGUgY2FzZSB3aGVyZSB0d28gZW5kcG9pbnRz
IHN1cHBvcnQgZGlmZmVyZW50IGxheWVyIE9BTSBvciBkb2VzbqGvdCBzdXBwb3J0IGFueSBPQU0g
YXQgdGhhdCBsYXllci4NCg0KQlRXOiBJIGhhdmUgY2Ohr2VkIHRpbWUgbWFpbGluZyBsaXN0IHNp
bmNlIEkgYmVsaWV2ZSB0aGlzIG1haWxpbmcgbGlzdCBpcyBwdXJwb3NlZCB0byBsb29rIGZvciBn
ZW5lcmljIGFuZCBpbnRlZ3JhdGVkIE9BTSBjb3ZlcmluZyB2YXJpb3VzIGhldGVyb2dlbmVvdXMg
bmV0d29ya2luZyB0ZWNobm9sb2dpZXMuDQpSZWdhcmRzIQ0KLVFpbg0Kt6K8/sjLOiBuZXRtb2Qg
W21haWx0bzpuZXRtb2QtYm91bmNlc0BpZXRmLm9yZ10gtPqx7SBUaXNzYSBTZW5ldmlyYXRobmUg
KHRzZW5ldmlyKQ0Kt6LLzcqxvOQ6IDIwMTTE6jbUwjExyNUgMzowMw0KytW8/sjLOiBuZXRtb2RA
aWV0Zi5vcmc7IG52bzNAaWV0Zi5vcmc7IHRyaWxsQGlldGYub3JnOyBsMnZwbkBpZXRmLm9yZzsg
b3BzYXdnQGlldGYub3JnDQrW98ziOiBbbmV0bW9kXSBZQU5HIG1vZGVscyBmb3IgT0FNDQoNCkFs
bA0KDQpXZSBoYXZlIHB1Ymxpc2hlZCBZQU5HIG1vZGVsIGZvciBPQU0uICMxIGRyYWZ0IGJlbG93
IHBsYWNlIHRoZSBnZW5lcmljIGZyYW1ld29yayBmb3IgT0FNLCB0aGF0IGNhbiBiZSBhdWdtZW50
ZWQgZm9yIGRpZmZlcmVudCB0ZWNobm9sb2dpZXMuICMyIGFuZCAjMyBhcmUgYXBwbGljYXRpb24g
b2YgdGhlIGNvbmNlcHQgdG8gTlZPMyBhbmQgVFJJTEwsDQoNCg0KMS4gICAgICAgaHR0cDovL2Rh
dGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC10aXNzYS1uZXRtb2Qtb2FtLw0KDQoyLiAgICAg
ICBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXRpc3NhLW52bzMteWFuZy1v
YW0vDQoNCjMuICAgICAgIGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtdGlz
c2EtdHJpbGwteWFuZy1vYW0vDQoNClBsZWFzZSByZXZpZXcgYW5kIHNoYXJlIHlvdXIgY29tbWVu
dHMNCg0KVGhhbmtzDQpUaXNzYQ0KDQoNCg==

--_000_B8F9A780D330094D99AF023C5877DABA84549D17nkgeml501mbschi_
Content-Type: text/html; charset="gb2312"
Content-Transfer-Encoding: quoted-printable











Hi, Tissa:


Thanks for initiating discussion on this topic.=



Unified OAM for multi-Layer network is a good idea to me.


draft-ww-opsawg-multi-layer-oam-00 we proposed in opsawg laid out=
 the an initial description of the problem.


The question to
draft-=
tissa-netmod-oam is


I am wondering how this generic Yang Model can be applied to SFC =
environment?


How do you support the case where two endpoints support different=
 layer OAM or doesn=A1=AFt support any OAM at that layer.=



 


BTW: I have cc=A1=AFed time mailing list since I believe this mai=
ling list is purposed to look for generic and integrated OAM covering vario=
us heterogeneous networking technologies.


Regards!


-Qin






=B7=A2=BC=FE=C8=CB: netmod =
[mailto:netmod-bounces@ietf.org]
=B4=FA=
=B1=ED Tissa Senevirathne (tsenevir)

=B7=A2=
=CB=CD=CA=B1=BC=E4: 2014=C4=EA6=D4=C211=C8=D5
 3:03

=CA=D5=BC=FE=C8=CB: netmod@ietf.org; nvo3@ietf.org; trill@ietf.org; l2vpn@ietf.org; ops=
awg@ietf.org

=D6=F7=CC=E2: [netmod] YANG models for OAM






 


All


 


We have published YANG model fo=
r OAM. #1 draft below place the generic framework for OAM, that can be augm=
ented for different technologies. #2 and #3 are application of the concept =
to NVO3 and TRILL,


 


1. &nbs=
p;    
http://datatracker.ietf.org/do=
c/draft-tissa-netmod-oam/


2. &nbs=
p;    
http://datatracker.ietf.org=
/doc/draft-tissa-nvo3-yang-oam/


3. &nbs=
p;    
http://datatracker.ietf.or=
g/doc/draft-tissa-trill-yang-oam/


 


Please review and share your co=
mments


 


Thanks


Tissa


 


 






--_000_B8F9A780D330094D99AF023C5877DABA84549D17nkgeml501mbschi_--


From nobody Wed Jun 11 01:23:15 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96D8C1B282D for ; Wed, 11 Jun 2014 01:22:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r9UoeP-pO2gp for ; Wed, 11 Jun 2014 01:22:54 -0700 (PDT)
Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3lp0084.outbound.protection.outlook.com [213.199.154.84]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9C8C1B2795 for ; Wed, 11 Jun 2014 01:22:53 -0700 (PDT)
Received: from AMXPRD0310HT002.eurprd03.prod.outlook.com (157.56.248.133) by DB3PR07MB060.eurprd07.prod.outlook.com (10.242.137.151) with Microsoft SMTP Server (TLS) id 15.0.949.11; Wed, 11 Jun 2014 08:22:51 +0000
Message-ID: <00e101cf854d$e8b6bde0$4001a8c0@gateway.2wire.net>
From: t.petch 
To: Juergen Schoenwaelder , 
References: <20140602082956.GJ92342@elstar.local> <20140610192333.GK28878@elstar.local>
Date: Wed, 11 Jun 2014 09:19:40 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Originating-IP: [157.56.248.133]
X-ClientProxiedBy: AM3PR07CA001.eurprd07.prod.outlook.com (10.242.16.41) To DB3PR07MB060.eurprd07.prod.outlook.com (10.242.137.151)
X-Microsoft-Antispam: BL:0; ACTION:Default; RISK:Low; SCL:0; SPMLVL:NotSpam; PCL:0; RULEID:
X-Forefront-PRVS: 0239D46DB6
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(6009001)(428001)(24454002)(51704005)(377454003)(199002)(189002)(13464003)(104166001)(79102001)(64706001)(92726001)(4396001)(76482001)(83322001)(62236002)(20776003)(47776003)(88136002)(89996001)(87976001)(93916002)(44736004)(44716002)(81542001)(31966008)(77982001)(83072002)(86362001)(19580405001)(62966002)(19580395003)(85852003)(101416001)(66066001)(42186004)(80022001)(92566001)(84392001)(99396002)(74502001)(61296002)(561944003)(102836001)(74662001)(81342001)(23756003)(21056001)(33646001)(50226001)(81816999)(50466002)(77156001)(50986999)(15975445006)(14496001)(76176999)(46102001)(87286001)(81686999)(74416001)(7726001); DIR:OUT; SFP:; SCL:1; SRVR:DB3PR07MB060; H:AMXPRD0310HT002.eurprd03.prod.outlook.com; FPR:; MLV:nov; PTR:InfoNoRecords;  A:0; MX:1; LANG:en; 
Received-SPF: None (: btconnect.com does not designate permitted sender hosts)
Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; 
X-OriginatorOrg: btconnect.com
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/l6H0TZB1oB3u_Ece_puGll98S3c
Subject: Re: [netmod] undecided Y39 define the terms system/user-controlledinstances
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 11 Jun 2014 08:22:56 -0000

----- Original Message -----
From: "Juergen Schoenwaelder" 
To: 
Sent: Tuesday, June 10, 2014 8:23 PM
> On Mon, Jun 02, 2014 at 10:29:56AM +0200, Juergen Schoenwaelder wrote:
> > We need to decide whether this is in scope of YANG 1.1 or not.
> >
>
> Interim proposal:
>
>    Proposal: Reject since this is an architectural distinction and
>    should thus should be defined generically elsewhere. It does not
>    seem to be a YANG 1.1 issue.
>
> If you disagree, please speak up by June 18th.

Lada's response to me said further that you would put it in RFC6244bis.
That is currently Informational and so would be an unsuitable, not
impossible just eyebrow raising, as a reference for data models.

Can you really see the current definitions in e.g. netmod-routing-cfg as
being just informational, not normative?  Would the I-D make any sense
without them?

Tom Petch






>
> /js
>
> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
> Fax:   +49 421 200 3103         
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


From nobody Wed Jun 11 01:35:22 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 336771B2830 for ; Wed, 11 Jun 2014 01:35:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.201
X-Spam-Level: 
X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J-A3A88gTDj9 for ; Wed, 11 Jun 2014 01:35:04 -0700 (PDT)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 764A61A0010 for ; Wed, 11 Jun 2014 01:35:04 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id C9FF0E77; Wed, 11 Jun 2014 10:35:01 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id ColHqQcdlTvE; Wed, 11 Jun 2014 10:34:51 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 11 Jun 2014 10:35:01 +0200 (CEST)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 99A752002C; Wed, 11 Jun 2014 10:35:02 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id y20DHNDR0_tV; Wed, 11 Jun 2014 10:34:51 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5451520013; Wed, 11 Jun 2014 10:35:01 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 97E952D61E04; Wed, 11 Jun 2014 10:35:00 +0200 (CEST)
Date: Wed, 11 Jun 2014 10:34:59 +0200
From: Juergen Schoenwaelder 
To: "t. petch" 
Message-ID: <20140611083459.GA32709@elstar.local>
Mail-Followup-To: "t. petch" , netmod@ietf.org, Ladislav Lhotka 
References: <20140602082956.GJ92342@elstar.local> <20140610192333.GK28878@elstar.local> <00e101cf854d$e8b6bde0$4001a8c0@gateway.2wire.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <00e101cf854d$e8b6bde0$4001a8c0@gateway.2wire.net>
User-Agent: Mutt/1.4.2.3i
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/0PnoXDb__99KBFdBoQigAYUaX-g
Cc: netmod@ietf.org
Subject: Re: [netmod] undecided Y39 define the terms system/user-controlledinstances
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 11 Jun 2014 08:35:06 -0000

On Wed, Jun 11, 2014 at 09:19:40AM +0100, t. petch wrote:
> ----- Original Message -----
> From: "Juergen Schoenwaelder" 
> To: 
> Sent: Tuesday, June 10, 2014 8:23 PM
> > On Mon, Jun 02, 2014 at 10:29:56AM +0200, Juergen Schoenwaelder wrote:
> > > We need to decide whether this is in scope of YANG 1.1 or not.
> > >
> >
> > Interim proposal:
> >
> >    Proposal: Reject since this is an architectural distinction and
> >    should thus should be defined generically elsewhere. It does not
> >    seem to be a YANG 1.1 issue.
> >
> > If you disagree, please speak up by June 18th.
> 
> Lada's response to me said further that you would put it in RFC6244bis.
> That is currently Informational and so would be an unsuitable, not
> impossible just eyebrow raising, as a reference for data models.

I do not know whether there are any plans to revise RFC 6244. The
point raised during the virtual interim meeting is that this distinction
is not something that affects the YANG language itself.
 
> Can you really see the current definitions in e.g. netmod-routing-cfg as
> being just informational, not normative?  Would the I-D make any sense
> without them?

I think there are other places in the IETF where terminology and key
concepts are defined in informational architecture documents and then
used in normative protocol documents. But then again this can be
considered once a WG revises RFC 6244. It is also conceivable to have
a separate NETCONF/YANG Terminology document that defines normatively
basic concepts.

Again, the key observation during the virtual interim was that things
not affecting YANG directly should be kept out of the YANG specification.

/js

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


From nobody Wed Jun 11 04:06:47 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDCFD1B2852 for ; Wed, 11 Jun 2014 04:06:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.201
X-Spam-Level: 
X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9iY1Dz9Fbmx5 for ; Wed, 11 Jun 2014 04:06:07 -0700 (PDT)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A03C1B2854 for ; Wed, 11 Jun 2014 04:06:07 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 378E0742 for ; Wed, 11 Jun 2014 13:06:04 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id MAr873RSOW3Z for ; Wed, 11 Jun 2014 13:05:53 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Wed, 11 Jun 2014 13:06:03 +0200 (CEST)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3A67B20013 for ; Wed, 11 Jun 2014 13:06:05 +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 Z8TZ0-3m_UcL; Wed, 11 Jun 2014 13:06:04 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 875BF2002C; Wed, 11 Jun 2014 13:06:04 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id D2F4F2D6206A; Wed, 11 Jun 2014 13:06:03 +0200 (CEST)
Date: Wed, 11 Jun 2014 13:06:03 +0200
From: Juergen Schoenwaelder 
To: netmod@ietf.org
Message-ID: <20140611110603.GA33009@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.4.2.3i
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/asst3mGHAHOkasixeULGw0h0uHw
Subject: [netmod] virtual interim meeting reminder
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 11 Jun 2014 11:06:09 -0000

Hi,

this is a short reminder that we have a virtual interim meeting later
today (4pm-6pm central european time zone). You will find the webex
details here:

http://www.ietf.org/mail-archive/web/ietf-announce/current/msg12811.html

/js

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


From nobody Wed Jun 11 04:32:32 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA1151B2866 for ; Wed, 11 Jun 2014 04:31:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.002
X-Spam-Level: 
X-Spam-Status: No, score=-1.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.651] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LhKkoQFXp1DP for ; Wed, 11 Jun 2014 04:31:48 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABC7D1B2864 for ; Wed, 11 Jun 2014 04:31:48 -0700 (PDT)
Received: from [10.36.190.117] (cst-prg-62-250.cust.vodafone.cz [46.135.62.250]) by mail.nic.cz (Postfix) with ESMTPSA id B470C13FA29; Wed, 11 Jun 2014 13:31:46 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1402486307; bh=gy1ZQuv6b19SihStNGIgNoQ7fUdt6YtoccgUM7+H16g=; h=Date:Subject:Message-ID:From:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding; b=k8q8e0/70v/x3pzAfyoWtLeIaaI0A2bimFWwpECqjYp8nbcGjU1I6fs3YmRUsp8v8 +Bo/xOHcYrnHNq9tIH4iyL3LY5PzEatTGCeIvg04YBZS+pOlVU02u8da1rX5o1RCne /nsdaJoXA9t4d11Wk2SB2laIv7z7LkNtfcrA5tg8=
Date: Wed, 11 Jun 2014 13:31:38 +0200
Message-ID: 
From: Ladislav Lhotka 
To: =?ISO-8859-1?Q?J=FCrgen_Sch=F6nw=E4lder?= 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: base64
X-Virus-Scanned: clamav-milter 0.97.8 at mail
X-Virus-Status: Clean
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/pULzHVg6nOH-qfoM62XSpmg6M_c
Cc: NETMOD WG 
Subject: Re: [netmod] virtual interim meeting reminder
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 11 Jun 2014 11:31:50 -0000

SGksCgpJIGFtIG5vdyB0cmF2ZWxsaW5nLCBJJ2xsIGJlIGFibGUgdG8gam9pbiB0aGUgbWVldGlu
ZyBhdCBhYm91dCA0OjMwIHBtLgoKTGFkYQoKSnVlcmdlbiBTY2hvZW53YWVsZGVyIDxqLnNjaG9l
bndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGU+bmFwc2FsL2E6Cgo+SGksCj4KPnRoaXMgaXMg
YSBzaG9ydCByZW1pbmRlciB0aGF0IHdlIGhhdmUgYSB2aXJ0dWFsIGludGVyaW0gbWVldGluZyBs
YXRlcgo+dG9kYXkgKDRwbS02cG0gY2VudHJhbCBldXJvcGVhbiB0aW1lIHpvbmUpLiBZb3Ugd2ls
bCBmaW5kIHRoZSB3ZWJleAo+ZGV0YWlscyBoZXJlOgo+Cj5odHRwOi8vd3d3LmlldGYub3JnL21h
aWwtYXJjaGl2ZS93ZWIvaWV0Zi1hbm5vdW5jZS9jdXJyZW50L21zZzEyODExLmh0bWwKPgo+L2pz
Cj4KPi0tIAo+SnVlcmdlbiBTY2hvZW53YWVsZGVyICAgICAgICAgICBKYWNvYnMgVW5pdmVyc2l0
eSBCcmVtZW4gZ0dtYkgKPlBob25lOiArNDkgNDIxIDIwMCAzNTg3ICAgICAgICAgQ2FtcHVzIFJp
bmcgMSwgMjg3NTkgQnJlbWVuLCBHZXJtYW55Cj5GYXg6ICAgKzQ5IDQyMSAyMDAgMzEwMyAgICAg
ICAgIDxodHRwOi8vd3d3LmphY29icy11bml2ZXJzaXR5LmRlLz4KPgo+X19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPm5ldG1vZCBtYWlsaW5nIGxpc3QKPm5l
dG1vZEBpZXRmLm9yZwo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRt
b2QK


From nobody Wed Jun 11 05:46:18 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 715D71A045B for ; Wed, 11 Jun 2014 05:46:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.552
X-Spam-Level: 
X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V_zok0HdDilc for ; Wed, 11 Jun 2014 05:46:14 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id BCC981A0278 for ; Wed, 11 Jun 2014 05:46:13 -0700 (PDT)
Received: from localhost (x15.tail-f.com [192.168.1.60]) by mail.tail-f.com (Postfix) with ESMTPSA id A5E991280260; Wed, 11 Jun 2014 14:44:40 +0200 (CEST)
Date: Wed, 11 Jun 2014 14:46:06 +0200 (CEST)
Message-Id: <20140611.144606.1344507277614536718.mbj@tail-f.com>
To: powladi@cisco.com
From: Martin Bjorklund 
In-Reply-To: <013A9B371AC6DF4C8AD261897D8F243E10B005E8@xmb-aln-x08.cisco.com>
References: <013A9B371AC6DF4C8AD261897D8F243E10B002E7@xmb-aln-x08.cisco.com>  <013A9B371AC6DF4C8AD261897D8F243E10B005E8@xmb-aln-x08.cisco.com>
X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/PjKy04-hDScXL1tcjMOW_0ZBxAE
Cc: netmod@ietf.org
Subject: Re: [netmod] YANG 1.1 Clarification: must-stmt within an NP-container
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 11 Jun 2014 12:46:16 -0000

Hi,

First of all, I think is issue is covered by Y41.  I will update the
issues list with a reference to this ML thread.

(I don't know which mail client you are using, but the citation got
messed up...)


"Peyman Owladi -X (powladi - Ensoft Ltd at Cisco)"  wrote:
> 
> From: Andy Bierman [mailto:andy@yumaworks.com]
> Sent: 10 June 2014 16:00
> To: Peyman Owladi -X (powladi - Ensoft Ltd at Cisco)
> Cc: netmod@ietf.org
> Subject: Re: [netmod] YANG 1.1 Clarification: must-stmt within an
> NP-container
> 
> 
> 
> On Tue, Jun 10, 2014 at 7:39 AM, Peyman Owladi -X (powladi - Ensoft
> Ltd at Cisco) > wrote:
> Yes, we need this clarification, and it looks like it addresses the
> core problem described in Y38.
> 
> Some further thoughts on the solution:
> 
> It looks like banning the use of "must" in an NP container would fail
> the backwards-compatibility test. So the two alternative
> clarifications I can think of are:
>   1. Only evaluate the "must" statement in an NP container if a node
>   (not an NP container) is instantiated in the data tree within the
>   subtree encapsulated by the NP container.
>   2. Always evaluate the "must" statement in an NP container if its
>   nearest non-NP-container ancestor exists (similarly defined to the
>   rules for evaluating the "mandatory" statement in RFC6020 7.6.5 and
>   "default" in 7.6.1).
> 
> It would be reasonable for existing implementations to be using either
> option 1 or option 2.
> 
> If the rules are being tightened one way or the other, option 2 would
> have the following advantages:
>   * It is more consistent with the "leaf with default" example Andy has
>   * given below.
>   * It has better implications for the conformance of existing
>   * implementations:
>     - If the clarification specifies that option 1 is the right behavior,
>     - then an existing implementation based on option 2 would reject some
>     - operations that are valid.
>     - If the clarification specifies that option 2 is the right behavior,
>     - then an existing implementation based on option 1 would accept some
>     - operations that are invalid (and this is presumably the lesser evil?).
>   * It seems more in line with the description of NP containers in 7.5.1,
>   * that they "exist only for organizing the hierarchy of data nodes
>   * ... the container has no meaning of its own, existing only to contain
>   * child nodes."
> 
> I could support option 2.

+1

> That would change the "MAY delete" NP-containers to "MUST NOT delete"
> and "MUST create".
> 
> Is that a backward-compatible change?  It does not cause a YANG 1.0
> module to be invalid but changes normative server behavior.
> 
> 
> It seems to me that this can simply be a recommendation for server
> behavior that helps to define the expected externally-observed
> behavior for evaluating "must" constraints. (Perhaps this should also
> apply to the behavior of "default" and "mandatory" leaves, to simplify
> the language in 7.6.1 and 7.6.5.)
> 
> A server implementation could choose not to actually instantiate the
> NP containers, but to evaluate the "must" constraints in the cases in
> the cases where they are described as being logically
> instantiated. (In other words, I think what's being described is just
> the "conceptual" existence of NP-containers for these
> evaluations/behaviors.)
> 
> An alternative approach would be to avoid updating the statement about
> existence of NP-containers at all, and instead update the datastore
> validation statement in 7.5.3 to bring it in line with 7.6.1 and
> 7.6.5; e.g. replace the second paragraph of 7.5.3 with:
> 
> When a datastore is validated, all "must" constraints are
> conceptually evaluated once for each data node in the data tree,
> and for all leafs with default values in use (see Section 7.6.1).
> For "must" constraints in non-presence containers (see Section
> 7.5.1), the evaluation depends on each instance of its closest
> ancestor node in the schema tree that is not a non-presence
> container:
> 
>    o  If no such ancestor exists in the schema tree, the "must"
>       constraint is evaluated.
> 
>    o  Otherwise, if this ancestor is a case node, the "must"
>       constraint is evaluated if any node from the case exists
>       in the data tree.
> 
>    o  Otherwise, the leaf "must" constraint is evaluated if the
>       ancestor node in the data tree.
> 
> For any other data node, its "must" statements are not evaluated.

I like this approach.  It doesn't handle Andy's original "must3", but
I am not sure the behavior in that case needs to be well-defined.
These kinds of expressions should be avoided.


/martin

> 
> Cheers,
> Peyman
> 
> Andy
> 
> Cheers,
> Peyman
> 
> 
> 
> -----Original Message-----
> From: netmod
> [mailto:netmod-bounces@ietf.org] On
> Behalf Of Andy Bierman
> Sent: 10 June 2014 02:38
> To: netmod@ietf.org
> Subject: [netmod] YANG 1.1 Clarification: must-stmt within an
> NP-container
> 
> Hi,
> 
> Consider this YANG snippet:
> 
>    container np-con {
>       must "/some-node-test";   // must1
>       leaf def42 {
>         must "/some-other-node-test";   // must2
>         type int32;
>         default 42;
>      }
>    }
> 
>   leaf X {
>      must "/np-con";  // must3
>      type string;
>      default foo;
>   }
> 
>   leaf Y {
>      must "/np-con/def42";  // must4
>      type string;
>      default bar;
>   }
> 
> 
> Sec. 7.5.8 says that an empty NP-container MAY be removed by the
> server.
> 
>    If a container does not have a "presence" statement and the last
>    child node is deleted, the NETCONF server MAY delete the container.
> 
> Additional text in 7.5.3. para 2:
> 
>    When a datastore is validated, all "must" constraints are
>    conceptually evaluated once for each data node in the data tree, and
>    for all leafs with default values in use (see Section 7.6.1).  If a
>    data node does not exist in the data tree, and it does not have a
>    default value, its "must" statements are not evaluated.
> 
> Problems:
>   * This MAY statement in 7.5.8 means that a client does not know if the
>   * server
>     will evaluate "must1" if all child nodes are removed from /np-con.
> 
>  * The RFC is not clear about server-created NP containers. Are they
>  * allowed?
>     When is 'must1' evaluated on all servers?
> 
>  * The RFC does not account for the conceptual existence of default
>     NP containers.  Clearly, 'must2' needs to be evaluated.  In order for
>     the node /np-con/def42 to exist for XPath purposes, the parent node
>     /np-con must also exist for XPath purposes
> 
>  * This node existence ambiguity can ripple to other nodes. The 'must'3'
>     and 'must4' evaluations need to be done.  The rules are inconsistent.
>     Evaluation of 'must4' is clearly defined but 'must3' is not.
> 
> Solution:
>   * Define consistent behavior rules for NP-containers wrt/ default and
>     related must/when expression evaluation
> 
> 
> Andy
> 
> 
> 
> 
> 


From nobody Wed Jun 11 05:49:43 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C5431A0278 for ; Wed, 11 Jun 2014 05:49:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.552
X-Spam-Level: 
X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JbD81_uUzDaY for ; Wed, 11 Jun 2014 05:49:39 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id 649771A0263 for ; Wed, 11 Jun 2014 05:49:39 -0700 (PDT)
Received: from localhost (x15.tail-f.com [192.168.1.60]) by mail.tail-f.com (Postfix) with ESMTPSA id 8485F1280260; Wed, 11 Jun 2014 14:48:12 +0200 (CEST)
Date: Wed, 11 Jun 2014 14:49:38 +0200 (CEST)
Message-Id: <20140611.144938.333441271137904852.mbj@tail-f.com>
To: j.schoenwaelder@jacobs-university.de
From: Martin Bjorklund 
In-Reply-To: <20140611083459.GA32709@elstar.local>
References: <20140610192333.GK28878@elstar.local> <00e101cf854d$e8b6bde0$4001a8c0@gateway.2wire.net> <20140611083459.GA32709@elstar.local>
X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/5IZsZO2DExW8ao8399qBIkd0BnY
Cc: netmod@ietf.org
Subject: Re: [netmod] undecided Y39 define the terms system/user-controlledinstances
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 11 Jun 2014 12:49:41 -0000

Juergen Schoenwaelder  wrote:
> On Wed, Jun 11, 2014 at 09:19:40AM +0100, t. petch wrote:
> > ----- Original Message -----
> > From: "Juergen Schoenwaelder" 
> > To: 
> > Sent: Tuesday, June 10, 2014 8:23 PM
> > > On Mon, Jun 02, 2014 at 10:29:56AM +0200, Juergen Schoenwaelder wrote:
> > > > We need to decide whether this is in scope of YANG 1.1 or not.
> > > >
> > >
> > > Interim proposal:
> > >
> > >    Proposal: Reject since this is an architectural distinction and
> > >    should thus should be defined generically elsewhere. It does not
> > >    seem to be a YANG 1.1 issue.
> > >
> > > If you disagree, please speak up by June 18th.
> > 
> > Lada's response to me said further that you would put it in RFC6244bis.
> > That is currently Informational and so would be an unsuitable, not
> > impossible just eyebrow raising, as a reference for data models.
> 
> I do not know whether there are any plans to revise RFC 6244. The
> point raised during the virtual interim meeting is that this distinction
> is not something that affects the YANG language itself.

I think this definition could go into a new revision of RFC 6244, RFC
6087, or possibly a document on "YANG Design Patterns" (doesn't exist
yet, but we have talked about it).  All these would be Information
though.

> > Can you really see the current definitions in e.g. netmod-routing-cfg as
> > being just informational, not normative?  Would the I-D make any sense
> > without them?
> 
> I think there are other places in the IETF where terminology and key
> concepts are defined in informational architecture documents and then
> used in normative protocol documents. But then again this can be
> considered once a WG revises RFC 6244. It is also conceivable to have
> a separate NETCONF/YANG Terminology document that defines normatively
> basic concepts.
> 
> Again, the key observation during the virtual interim was that things
> not affecting YANG directly should be kept out of the YANG specification.


/martin


From nobody Wed Jun 11 05:56:02 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBA461A009C for ; Wed, 11 Jun 2014 05:55:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.002
X-Spam-Level: 
X-Spam-Status: No, score=-1.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.651] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WlSv7JFupPJD for ; Wed, 11 Jun 2014 05:55:57 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 982921A009A for ; Wed, 11 Jun 2014 05:55:57 -0700 (PDT)
Received: from [192.168.42.235] (cst-prg-107-6.cust.vodafone.cz [46.135.107.6]) by mail.nic.cz (Postfix) with ESMTPSA id C885813FD9F; Wed, 11 Jun 2014 14:55:53 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1402491356; bh=GE5EgPFIFq2TRpbX2yGfNd1KUPGtFk5jk120bPy+PE4=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=d7Df63K4SEhESS8MANZFhMu/77lEXW/7C9skbMLG6eTjZRWifBoYs5Y+w/akv7Vwh 5u8L5v218Qjr39E0xoRg+5TVrAi55Tv0V/2m7aHsK1EsSISrbOJa10xdfqVlGkbH6t gfQTcrO6AFY6GoVcZ7cf26rwN21b6Bw6VmdzB3A0=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
From: Ladislav Lhotka 
In-Reply-To: <20140611.144606.1344507277614536718.mbj@tail-f.com>
Date: Wed, 11 Jun 2014 14:55:49 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <1116B7A5-F0DE-4D66-92D8-758FB546246C@nic.cz>
References: <013A9B371AC6DF4C8AD261897D8F243E10B002E7@xmb-aln-x08.cisco.com>  <013A9B371AC6DF4C8AD261897D8F243E10B005E8@xmb-aln-x08.cisco.com> <20140611.144606.1344507277614536718.mbj@tail-f.com>
To: =?iso-8859-1?Q?Martin_Bj=F6rklund?= 
X-Mailer: Apple Mail (2.1878.2)
X-Virus-Scanned: clamav-milter 0.97.8 at mail
X-Virus-Status: Clean
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/D2o5oP-81JiBhCtg4zglaz7P2kg
Cc: netmod@ietf.org
Subject: Re: [netmod] YANG 1.1 Clarification: must-stmt within an NP-container
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 11 Jun 2014 12:56:00 -0000

On 11 Jun 2014, at 14:46, Martin Bjorklund  wrote:

> Hi,
>=20
> First of all, I think is issue is covered by Y41.  I will update the

Yes, and see also this thread:

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

Lada

> issues list with a reference to this ML thread.
>=20
> (I don't know which mail client you are using, but the citation got
> messed up...)
>=20
>=20
> "Peyman Owladi -X (powladi - Ensoft Ltd at Cisco)"  =
wrote:
>>=20
>> From: Andy Bierman [mailto:andy@yumaworks.com]
>> Sent: 10 June 2014 16:00
>> To: Peyman Owladi -X (powladi - Ensoft Ltd at Cisco)
>> Cc: netmod@ietf.org
>> Subject: Re: [netmod] YANG 1.1 Clarification: must-stmt within an
>> NP-container
>>=20
>>=20
>>=20
>> On Tue, Jun 10, 2014 at 7:39 AM, Peyman Owladi -X (powladi - Ensoft
>> Ltd at Cisco) > wrote:
>> Yes, we need this clarification, and it looks like it addresses the
>> core problem described in Y38.
>>=20
>> Some further thoughts on the solution:
>>=20
>> It looks like banning the use of "must" in an NP container would fail
>> the backwards-compatibility test. So the two alternative
>> clarifications I can think of are:
>>  1. Only evaluate the "must" statement in an NP container if a node
>>  (not an NP container) is instantiated in the data tree within the
>>  subtree encapsulated by the NP container.
>>  2. Always evaluate the "must" statement in an NP container if its
>>  nearest non-NP-container ancestor exists (similarly defined to the
>>  rules for evaluating the "mandatory" statement in RFC6020 7.6.5 and
>>  "default" in 7.6.1).
>>=20
>> It would be reasonable for existing implementations to be using =
either
>> option 1 or option 2.
>>=20
>> If the rules are being tightened one way or the other, option 2 would
>> have the following advantages:
>>  * It is more consistent with the "leaf with default" example Andy =
has
>>  * given below.
>>  * It has better implications for the conformance of existing
>>  * implementations:
>>    - If the clarification specifies that option 1 is the right =
behavior,
>>    - then an existing implementation based on option 2 would reject =
some
>>    - operations that are valid.
>>    - If the clarification specifies that option 2 is the right =
behavior,
>>    - then an existing implementation based on option 1 would accept =
some
>>    - operations that are invalid (and this is presumably the lesser =
evil?).
>>  * It seems more in line with the description of NP containers in =
7.5.1,
>>  * that they "exist only for organizing the hierarchy of data nodes
>>  * ... the container has no meaning of its own, existing only to =
contain
>>  * child nodes."
>>=20
>> I could support option 2.
>=20
> +1
>=20
>> That would change the "MAY delete" NP-containers to "MUST NOT delete"
>> and "MUST create".
>>=20
>> Is that a backward-compatible change?  It does not cause a YANG 1.0
>> module to be invalid but changes normative server behavior.
>>=20
>>=20
>> It seems to me that this can simply be a recommendation for server
>> behavior that helps to define the expected externally-observed
>> behavior for evaluating "must" constraints. (Perhaps this should also
>> apply to the behavior of "default" and "mandatory" leaves, to =
simplify
>> the language in 7.6.1 and 7.6.5.)
>>=20
>> A server implementation could choose not to actually instantiate the
>> NP containers, but to evaluate the "must" constraints in the cases in
>> the cases where they are described as being logically
>> instantiated. (In other words, I think what's being described is just
>> the "conceptual" existence of NP-containers for these
>> evaluations/behaviors.)
>>=20
>> An alternative approach would be to avoid updating the statement =
about
>> existence of NP-containers at all, and instead update the datastore
>> validation statement in 7.5.3 to bring it in line with 7.6.1 and
>> 7.6.5; e.g. replace the second paragraph of 7.5.3 with:
>>=20
>> When a datastore is validated, all "must" constraints are
>> conceptually evaluated once for each data node in the data tree,
>> and for all leafs with default values in use (see Section 7.6.1).
>> For "must" constraints in non-presence containers (see Section
>> 7.5.1), the evaluation depends on each instance of its closest
>> ancestor node in the schema tree that is not a non-presence
>> container:
>>=20
>>   o  If no such ancestor exists in the schema tree, the "must"
>>      constraint is evaluated.
>>=20
>>   o  Otherwise, if this ancestor is a case node, the "must"
>>      constraint is evaluated if any node from the case exists
>>      in the data tree.
>>=20
>>   o  Otherwise, the leaf "must" constraint is evaluated if the
>>      ancestor node in the data tree.
>>=20
>> For any other data node, its "must" statements are not evaluated.
>=20
> I like this approach.  It doesn't handle Andy's original "must3", but
> I am not sure the behavior in that case needs to be well-defined.
> These kinds of expressions should be avoided.
>=20
>=20
> /martin
>=20
>>=20
>> Cheers,
>> Peyman
>>=20
>> Andy
>>=20
>> Cheers,
>> Peyman
>>=20
>>=20
>>=20
>> -----Original Message-----
>> From: netmod
>> [mailto:netmod-bounces@ietf.org] On
>> Behalf Of Andy Bierman
>> Sent: 10 June 2014 02:38
>> To: netmod@ietf.org
>> Subject: [netmod] YANG 1.1 Clarification: must-stmt within an
>> NP-container
>>=20
>> Hi,
>>=20
>> Consider this YANG snippet:
>>=20
>>   container np-con {
>>      must "/some-node-test";   // must1
>>      leaf def42 {
>>        must "/some-other-node-test";   // must2
>>        type int32;
>>        default 42;
>>     }
>>   }
>>=20
>>  leaf X {
>>     must "/np-con";  // must3
>>     type string;
>>     default foo;
>>  }
>>=20
>>  leaf Y {
>>     must "/np-con/def42";  // must4
>>     type string;
>>     default bar;
>>  }
>>=20
>>=20
>> Sec. 7.5.8 says that an empty NP-container MAY be removed by the
>> server.
>>=20
>>   If a container does not have a "presence" statement and the last
>>   child node is deleted, the NETCONF server MAY delete the container.
>>=20
>> Additional text in 7.5.3. para 2:
>>=20
>>   When a datastore is validated, all "must" constraints are
>>   conceptually evaluated once for each data node in the data tree, =
and
>>   for all leafs with default values in use (see Section 7.6.1).  If a
>>   data node does not exist in the data tree, and it does not have a
>>   default value, its "must" statements are not evaluated.
>>=20
>> Problems:
>>  * This MAY statement in 7.5.8 means that a client does not know if =
the
>>  * server
>>    will evaluate "must1" if all child nodes are removed from /np-con.
>>=20
>> * The RFC is not clear about server-created NP containers. Are they
>> * allowed?
>>    When is 'must1' evaluated on all servers?
>>=20
>> * The RFC does not account for the conceptual existence of default
>>    NP containers.  Clearly, 'must2' needs to be evaluated.  In order =
for
>>    the node /np-con/def42 to exist for XPath purposes, the parent =
node
>>    /np-con must also exist for XPath purposes
>>=20
>> * This node existence ambiguity can ripple to other nodes. The =
'must'3'
>>    and 'must4' evaluations need to be done.  The rules are =
inconsistent.
>>    Evaluation of 'must4' is clearly defined but 'must3' is not.
>>=20
>> Solution:
>>  * Define consistent behavior rules for NP-containers wrt/ default =
and
>>    related must/when expression evaluation
>>=20
>>=20
>> Andy
>>=20
>>=20
>>=20
>>=20
>>=20
>=20
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

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





From nobody Wed Jun 11 06:23:08 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CEA01A0086 for ; Wed, 11 Jun 2014 06:23:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.002
X-Spam-Level: 
X-Spam-Status: No, score=-1.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.651] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0LVm93OMXyXc for ; Wed, 11 Jun 2014 06:23:04 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BA311A0084 for ; Wed, 11 Jun 2014 06:23:03 -0700 (PDT)
Received: from [192.168.42.235] (cst-prg-107-6.cust.vodafone.cz [46.135.107.6]) by mail.nic.cz (Postfix) with ESMTPSA id 1CA7713FDFE; Wed, 11 Jun 2014 15:22:27 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1402492982; bh=84i6k2CD7xfiCwXqqLYW3cneI73No1CHNl9fsxN5z9k=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=oC4rYbw/dDr1xHvo1mUroHejC/uY5Km+NhZi3DxodHFDrJL+unHFbIhYeCGYRmEtC snyIQQyKNOSZwYfR4NlDSdu6TVLztFLugPXpFAvc6MGr5FprQiQABkUZVNTX9KgAWM QqIDXFoYBgR6DcnFlEJAEslKv3clLS/EileG/gFs=
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
From: Ladislav Lhotka 
In-Reply-To: <20140611.144938.333441271137904852.mbj@tail-f.com>
Date: Wed, 11 Jun 2014 15:22:23 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <9125A040-1223-4504-B884-83D56937F34C@nic.cz>
References: <20140610192333.GK28878@elstar.local> <00e101cf854d$e8b6bde0$4001a8c0@gateway.2wire.net> <20140611083459.GA32709@elstar.local> <20140611.144938.333441271137904852.mbj@tail-f.com>
To: =?windows-1252?Q?Martin_Bj=F6rklund?= 
X-Mailer: Apple Mail (2.1878.2)
X-Virus-Scanned: clamav-milter 0.97.8 at mail
X-Virus-Status: Clean
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/mqfvvJNAoFkA_BuuNstevvAi4P4
Cc: netmod@ietf.org
Subject: Re: [netmod] undecided Y39 define the terms system/user-controlledinstances
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 11 Jun 2014 13:23:05 -0000

On 11 Jun 2014, at 14:49, Martin Bjorklund  wrote:

> Juergen Schoenwaelder  wrote:
>> On Wed, Jun 11, 2014 at 09:19:40AM +0100, t. petch wrote:
>>> ----- Original Message -----
>>> From: "Juergen Schoenwaelder" 
>>> To: 
>>> Sent: Tuesday, June 10, 2014 8:23 PM
>>>> On Mon, Jun 02, 2014 at 10:29:56AM +0200, Juergen Schoenwaelder =
wrote:
>>>>> We need to decide whether this is in scope of YANG 1.1 or not.
>>>>>=20
>>>>=20
>>>> Interim proposal:
>>>>=20
>>>>   Proposal: Reject since this is an architectural distinction and
>>>>   should thus should be defined generically elsewhere. It does not
>>>>   seem to be a YANG 1.1 issue.
>>>>=20
>>>> If you disagree, please speak up by June 18th.
>>>=20
>>> Lada's response to me said further that you would put it in =
RFC6244bis.
>>> That is currently Informational and so would be an unsuitable, not
>>> impossible just eyebrow raising, as a reference for data models.
>>=20
>> I do not know whether there are any plans to revise RFC 6244. The
>> point raised during the virtual interim meeting is that this =
distinction
>> is not something that affects the YANG language itself.
>=20
> I think this definition could go into a new revision of RFC 6244, RFC
> 6087, or possibly a document on "YANG Design Patterns" (doesn't exist
> yet, but we have talked about it).  All these would be Information
> though.

I think Tom is right that this is quite an important data modelling =
concept, and it is also related to issue Y42. We have these dual lists =
in config and state (e.g. =93interface=94 in RFC 7223), and so far their =
relationship is only explained in descriptions. Maybe we need a formal =
means for expressing this relationship in data models, and then the =
notion of user/system-controlled entries will be crucial.

So I agree with rejecting Y39 with the caveat that it might pop up as =
part of Y42 (and yes, we might have to ask Deep Thought what the =
question of the latter issue really is).

Lada

>=20
>>> Can you really see the current definitions in e.g. =
netmod-routing-cfg as
>>> being just informational, not normative?  Would the I-D make any =
sense
>>> without them?
>>=20
>> I think there are other places in the IETF where terminology and key
>> concepts are defined in informational architecture documents and then
>> used in normative protocol documents. But then again this can be
>> considered once a WG revises RFC 6244. It is also conceivable to have
>> a separate NETCONF/YANG Terminology document that defines normatively
>> basic concepts.
>>=20
>> Again, the key observation during the virtual interim was that things
>> not affecting YANG directly should be kept out of the YANG =
specification.
>=20
>=20
> /martin
>=20
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

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





From nobody Wed Jun 11 06:46:25 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76FDF1A00F0 for ; Wed, 11 Jun 2014 06:46:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level: 
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lWf_mmJazuSW for ; Wed, 11 Jun 2014 06:46:21 -0700 (PDT)
Received: from mail-qa0-f53.google.com (mail-qa0-f53.google.com [209.85.216.53]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DD6B1A00DA for ; Wed, 11 Jun 2014 06:46:21 -0700 (PDT)
Received: by mail-qa0-f53.google.com with SMTP id j15so508324qaq.26 for ; Wed, 11 Jun 2014 06:46:20 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=ol5HWYhlp6IE0QKPT6hWIdfNN4GW6rxcR5zKPY0mxjU=; b=j0j8AfEXbuf1xNH3+25jORFjYRLJK8Qk6vZv9gV0GoLY7NRKIqjnO75NOVZS2iFXbc VQn2yIsF7cIBFGR+85WC2ZGsF8FJXF8UddUTtfFqy8GP8DJDr5ParVvEjHFm2ymRHtYV XZs+HLLambSzzDTjeOo+mxkB0WGKLnbjUCTWRnM1TxakyWj63RXdElzWYsY9QeArXQVH kvvOFTt9wsyesVsQLpkl3Uzm91lWfq1nMYHnPzL/jRDbH/wW+d5Jl4CU662ItUnXNgLZ mdw3p/jyNDb6nrVf1Y5JbbsOWwVlhey3JpikIb/F3zIBmgnY1qDA17VVrxBWb9T5+Tbg QrDQ==
X-Gm-Message-State: ALoCoQl1kN2VV4D7nt0R05Ht7fROrlA+j6mOj5RLaCkqAaYq6k3yfOgj2f3P5D9OcL6uiUg1o1i4
MIME-Version: 1.0
X-Received: by 10.224.165.70 with SMTP id h6mr52231983qay.78.1402494380494; Wed, 11 Jun 2014 06:46:20 -0700 (PDT)
Received: by 10.140.104.49 with HTTP; Wed, 11 Jun 2014 06:46:20 -0700 (PDT)
In-Reply-To: <9125A040-1223-4504-B884-83D56937F34C@nic.cz>
References: <20140610192333.GK28878@elstar.local> <00e101cf854d$e8b6bde0$4001a8c0@gateway.2wire.net> <20140611083459.GA32709@elstar.local> <20140611.144938.333441271137904852.mbj@tail-f.com> <9125A040-1223-4504-B884-83D56937F34C@nic.cz>
Date: Wed, 11 Jun 2014 06:46:20 -0700
Message-ID: 
From: Andy Bierman 
To: Ladislav Lhotka 
Content-Type: multipart/alternative; boundary=089e0149c3a459af4304fb8fabd6
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/ZxtQgLL4mYtJ3UAwz6tNQ-diDDQ
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] undecided Y39 define the terms system/user-controlledinstances
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 11 Jun 2014 13:46:24 -0000

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

On Wed, Jun 11, 2014 at 6:22 AM, Ladislav Lhotka  wrote:

>
> On 11 Jun 2014, at 14:49, Martin Bjorklund  wrote:
>
> > Juergen Schoenwaelder  wrote:
> >> On Wed, Jun 11, 2014 at 09:19:40AM +0100, t. petch wrote:
> >>> ----- Original Message -----
> >>> From: "Juergen Schoenwaelder" 
> >>> To: 
> >>> Sent: Tuesday, June 10, 2014 8:23 PM
> >>>> On Mon, Jun 02, 2014 at 10:29:56AM +0200, Juergen Schoenwaelder wrote:
> >>>>> We need to decide whether this is in scope of YANG 1.1 or not.
> >>>>>
> >>>>
> >>>> Interim proposal:
> >>>>
> >>>>   Proposal: Reject since this is an architectural distinction and
> >>>>   should thus should be defined generically elsewhere. It does not
> >>>>   seem to be a YANG 1.1 issue.
> >>>>
> >>>> If you disagree, please speak up by June 18th.
> >>>
> >>> Lada's response to me said further that you would put it in RFC6244bis.
> >>> That is currently Informational and so would be an unsuitable, not
> >>> impossible just eyebrow raising, as a reference for data models.
> >>
> >> I do not know whether there are any plans to revise RFC 6244. The
> >> point raised during the virtual interim meeting is that this distinction
> >> is not something that affects the YANG language itself.
> >
> > I think this definition could go into a new revision of RFC 6244, RFC
> > 6087, or possibly a document on "YANG Design Patterns" (doesn't exist
> > yet, but we have talked about it).  All these would be Information
> > though.
>
> I think Tom is right that this is quite an important data modelling
> concept, and it is also related to issue Y42. We have these dual lists in
> config and state (e.g. "interface" in RFC 7223), and so far their
> relationship is only explained in descriptions. Maybe we need a formal
> means for expressing this relationship in data models, and then the notion
> of user/system-controlled entries will be crucial.
>
>

It would be nice if somebody could describe the problem that
needs to be solved in protocol terms. List all changes in protocol
behavior between user and system controlled instances.
This doesn't seem like simply a terminology issue to me.



So I agree with rejecting Y39 with the caveat that it might pop up as part
> of Y42 (and yes, we might have to ask Deep Thought what the question of the
> latter issue really is).
>
> Lada
>
>

Andy


> >
> >>> Can you really see the current definitions in e.g. netmod-routing-cfg
> as
> >>> being just informational, not normative?  Would the I-D make any sense
> >>> without them?
> >>
> >> I think there are other places in the IETF where terminology and key
> >> concepts are defined in informational architecture documents and then
> >> used in normative protocol documents. But then again this can be
> >> considered once a WG revises RFC 6244. It is also conceivable to have
> >> a separate NETCONF/YANG Terminology document that defines normatively
> >> basic concepts.
> >>
> >> Again, the key observation during the virtual interim was that things
> >> not affecting YANG directly should be kept out of the YANG
> specification.
> >
> >
> > /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
>

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





On Wed, Jun 11, 2014 at 6:22 AM, Ladislav Lhotka =
<lhotka@nic.cz>=
; wrote:




On 11 Jun 2014, at 14:49, Martin Bjorklund <mbj@tail-f.com> wrote:



> Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:

>> On Wed, Jun 11, 2014 at 09:19:40AM +0100, t. petch wrote:

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

>>> From: "Juergen Schoenwaelder" <j.schoenwaelder@jacobs-university.de<=
/a>>

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

>>> Sent: Tuesday, June 10, 2014 8:23 PM

>>>> On Mon, Jun 02, 2014 at 10:29:56AM +0200, Juergen Schoenwa=
elder wrote:

>>>>> We need to decide whether this is in scope of YANG 1.1=
 or not.

>>>>>

>>>>

>>>> Interim proposal:

>>>>

>>>>   Proposal: Reject since this is an architectural dis=
tinction and

>>>>   should thus should be defined generically elsewhere=
. It does not

>>>>   seem to be a YANG 1.1 issue.

>>>>

>>>> If you disagree, please speak up by June 18th.

>>>

>>> Lada's response to me said further that you would put it i=
n RFC6244bis.

>>> That is currently Informational and so would be an unsuitable,=
 not

>>> impossible just eyebrow raising, as a reference for data model=
s.

>>

>> I do not know whether there are any plans to revise RFC 6244. The<=
br>
>> point raised during the virtual interim meeting is that this disti=
nction

>> is not something that affects the YANG language itself.

>

> I think this definition could go into a new revision of RFC 6244, RFC<=
br>
> 6087, or possibly a document on "YANG Design Patterns" (does=
n't exist

> yet, but we have talked about it).  All these would be Informatio=
n

> though.



I think Tom is right that this is quite an important data modelling concept=
, and it is also related to issue Y42. We have these dual lists in config a=
nd state (e.g. “interface” in RFC 7223), and so far their relat=
ionship is only explained in descriptions. Maybe we need a formal means for=
 expressing this relationship in data models, and then the notion of user/s=
ystem-controlled entries will be crucial.





It would be nice if som=
ebody could describe the problem that
needs to be solved in proto=
col terms. List all changes in protocol
behavior between user and=
 system controlled instances.


This doesn't seem like simply a terminology issue to me.




So I agree with rejecting Y39 with the caveat that it might pop up as part =
of Y42 (and yes, we might have to ask Deep Thought what the question of the=
 latter issue really is).



Lada




Andy
 

>

>>> Can you really see the current definitions in e.g. netmod-rout=
ing-cfg as

>>> being just informational, not normative?  Would the I-D m=
ake any sense

>>> without them?

>>

>> I think there are other places in the IETF where terminology and k=
ey

>> concepts are defined in informational architecture documents and t=
hen

>> used in normative protocol documents. But then again this can be
>> considered once a WG revises RFC 6244. It is also conceivable to h=
ave

>> a separate NETCONF/YANG Terminology document that defines normativ=
ely

>> basic concepts.

>>

>> Again, the key observation during the virtual interim was that thi=
ngs

>> not affecting YANG directly should be kept out of the YANG specifi=
cation.

>

>

> /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





--089e0149c3a459af4304fb8fabd6--


From nobody Wed Jun 11 06:51:18 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 117E11A00E5; Wed, 11 Jun 2014 06:51:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.552
X-Spam-Level: 
X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sH8aCc80jtJa; Wed, 11 Jun 2014 06:51:12 -0700 (PDT)
Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 9BE6E1A00DA; Wed, 11 Jun 2014 06:51:12 -0700 (PDT)
Received: from [10.181.109.54] (mobile-166-137-176-061.mycingular.net [166.137.176.61]) by lucidvision.com (Postfix) with ESMTP id A4F2727DD383; Wed, 11 Jun 2014 09:51:11 -0400 (EDT)
Content-Type: multipart/alternative; boundary=Apple-Mail-04F7ECFE-B2CD-4026-AE82-EEE68295C12A
Mime-Version: 1.0 (1.0)
From: Thomas Nadeau 
X-Mailer: iPhone Mail (11D201)
In-Reply-To: 
Date: Wed, 11 Jun 2014 06:51:09 -0700
Content-Transfer-Encoding: 7bit
Message-Id: 
References: 
To: "Tissa Senevirathne (tsenevir)" 
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/R3qf2kKi8zE-34PZHdDOYzrfcNA
Cc: "l2vpn@ietf.org" , "opsawg@ietf.org" , "nvo3@ietf.org" , "netmod@ietf.org" , "trill@ietf.org" 
Subject: Re: [netmod] YANG models for OAM
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 11 Jun 2014 13:51:14 -0000

--Apple-Mail-04F7ECFE-B2CD-4026-AE82-EEE68295C12A
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable

Are these models based on any implementation/s or proof-of-concept code that=
 anyone can look at?

Tom=20


> On Jun 10, 2014, at 12:03 PM, "Tissa Senevirathne (tsenevir)"  wrote:
>=20
> All
> =20
> We have published YANG model for OAM. #1 draft below place the generic fra=
mework for OAM, that can be augmented for different technologies. #2 and #3 a=
re application of the concept to NVO3 and TRILL,
> =20
> 1.      http://datatracker.ietf.org/doc/draft-tissa-netmod-oam/
> 2.      http://datatracker.ietf.org/doc/draft-tissa-nvo3-yang-oam/
> 3.      http://datatracker.ietf.org/doc/draft-tissa-trill-yang-oam/
> =20
> Please review and share your comments
> =20
> Thanks
> Tissa
> =20
> =20
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

--Apple-Mail-04F7ECFE-B2CD-4026-AE82-EEE68295C12A
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: 7bit


Are these models based on any implementation/s or proof-of-concept code that anyone can look at?

Tom 


On Jun 10, 2014, at 12:03 PM, "Tissa Senevirathne (tsenevir)" <tsenevir@cisco.com> wrote:











All


 


We have published YANG model for OAM. #1 draft below place the generic framework for OAM, that can be augmented for different technologies. #2 and #3 are application of the concept to NVO3 and TRILL,


 


1.     
http://datatracker.ietf.org/doc/draft-tissa-netmod-oam/


2.     
http://datatracker.ietf.org/doc/draft-tissa-nvo3-yang-oam/


3.     
http://datatracker.ietf.org/doc/draft-tissa-trill-yang-oam/


 


Please review and share your comments


 


Thanks


Tissa


 


 






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

--Apple-Mail-04F7ECFE-B2CD-4026-AE82-EEE68295C12A--


From nobody Wed Jun 11 07:04:06 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08D4F1A00F1 for ; Wed, 11 Jun 2014 07:04:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.302
X-Spam-Level: 
X-Spam-Status: No, score=-1.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RP_MATCHES_RCVD=-0.651] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0SEuhO9v1yjA for ; Wed, 11 Jun 2014 07:04:02 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 288C91A00E5 for ; Wed, 11 Jun 2014 07:04:01 -0700 (PDT)
Received: from [192.168.42.235] (cst-prg-107-6.cust.vodafone.cz [46.135.107.6]) by mail.nic.cz (Postfix) with ESMTPSA id 70D0E14012E; Wed, 11 Jun 2014 16:03:33 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1402495439; bh=xEW5FSt1lhTEemMzTfmlmBL8sLdGGo19b1/JZcW7TDc=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=ip1l1H2ESlVvZXq3gE+QIcYAcuhrhWERqiVC7VjPU3Iq4RPPUVuEgMdu4mPO3nHE0 vwgvu5E/wr05v5Fqa8bcRfLrubnjVj9HobKeAx4Kt/u5U7BWkAa3X6/RDtcYD76/Xo DNPf3W1EvmT4nYHiELUnujHecuDEPedQLGZnMWVU=
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
From: Ladislav Lhotka 
In-Reply-To: 
Date: Wed, 11 Jun 2014 16:03:01 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <20140610192333.GK28878@elstar.local> <00e101cf854d$e8b6bde0$4001a8c0@gateway.2wire.net> <20140611083459.GA32709@elstar.local> <20140611.144938.333441271137904852.mbj@tail-f.com> <9125A040-1223-4504-B884-83D56937F34C@nic.cz> 
To: Andy Bierman 
X-Mailer: Apple Mail (2.1878.2)
X-Virus-Scanned: clamav-milter 0.97.8 at mail
X-Virus-Status: Clean
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/eLGqWTEvz-Xu15UiuHEND3WM7d4
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] undecided Y39 define the terms system/user-controlledinstances
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 11 Jun 2014 14:04:05 -0000

On 11 Jun 2014, at 15:46, Andy Bierman  wrote:

>=20
>=20
>=20
> On Wed, Jun 11, 2014 at 6:22 AM, Ladislav Lhotka  =
wrote:
>=20
> On 11 Jun 2014, at 14:49, Martin Bjorklund  wrote:
>=20
> > Juergen Schoenwaelder  wrote:
> >> On Wed, Jun 11, 2014 at 09:19:40AM +0100, t. petch wrote:
> >>> ----- Original Message -----
> >>> From: "Juergen Schoenwaelder" =

> >>> To: 
> >>> Sent: Tuesday, June 10, 2014 8:23 PM
> >>>> On Mon, Jun 02, 2014 at 10:29:56AM +0200, Juergen Schoenwaelder =
wrote:
> >>>>> We need to decide whether this is in scope of YANG 1.1 or not.
> >>>>>
> >>>>
> >>>> Interim proposal:
> >>>>
> >>>>   Proposal: Reject since this is an architectural distinction and
> >>>>   should thus should be defined generically elsewhere. It does =
not
> >>>>   seem to be a YANG 1.1 issue.
> >>>>
> >>>> If you disagree, please speak up by June 18th.
> >>>
> >>> Lada's response to me said further that you would put it in =
RFC6244bis.
> >>> That is currently Informational and so would be an unsuitable, not
> >>> impossible just eyebrow raising, as a reference for data models.
> >>
> >> I do not know whether there are any plans to revise RFC 6244. The
> >> point raised during the virtual interim meeting is that this =
distinction
> >> is not something that affects the YANG language itself.
> >
> > I think this definition could go into a new revision of RFC 6244, =
RFC
> > 6087, or possibly a document on "YANG Design Patterns" (doesn't =
exist
> > yet, but we have talked about it).  All these would be Information
> > though.
>=20
> I think Tom is right that this is quite an important data modelling =
concept, and it is also related to issue Y42. We have these dual lists =
in config and state (e.g. =93interface=94 in RFC 7223), and so far their =
relationship is only explained in descriptions. Maybe we need a formal =
means for expressing this relationship in data models, and then the =
notion of user/system-controlled entries will be crucial.
>=20
>=20
>=20
> It would be nice if somebody could describe the problem that
> needs to be solved in protocol terms. List all changes in protocol
> behavior between user and system controlled instances.
> This doesn't seem like simply a terminology issue to me.

I am not sure whether anything has to be solved in protocol terms but =
sec. 4.1 in the routing draft does have some implications for server =
behaviour - e.g. the side effects in operational state of =
adding/deleting a list entry in config.

Lada

>=20
>=20
>=20
> So I agree with rejecting Y39 with the caveat that it might pop up as =
part of Y42 (and yes, we might have to ask Deep Thought what the =
question of the latter issue really is).
>=20
> Lada
>=20
>=20
>=20
> Andy
> =20
> >
> >>> Can you really see the current definitions in e.g. =
netmod-routing-cfg as
> >>> being just informational, not normative?  Would the I-D make any =
sense
> >>> without them?
> >>
> >> I think there are other places in the IETF where terminology and =
key
> >> concepts are defined in informational architecture documents and =
then
> >> used in normative protocol documents. But then again this can be
> >> considered once a WG revises RFC 6244. It is also conceivable to =
have
> >> a separate NETCONF/YANG Terminology document that defines =
normatively
> >> basic concepts.
> >>
> >> Again, the key observation during the virtual interim was that =
things
> >> not affecting YANG directly should be kept out of the YANG =
specification.
> >
> >
> > /martin
> >
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
>=20
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>=20
>=20
>=20
>=20
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>=20

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





From nobody Wed Jun 11 09:06:00 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E8821B27B7; Wed, 11 Jun 2014 09:05:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.151
X-Spam-Level: 
X-Spam-Status: No, score=-15.151 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8K3NOpXgz7qW; Wed, 11 Jun 2014 09:05:55 -0700 (PDT)
Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC6801A063B; Wed, 11 Jun 2014 09:05:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12000; q=dns/txt; s=iport; t=1402502755; x=1403712355; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=FH4eyIvWt92FvLwHbHVoyxp5+N77vMFBZKMyjMQOr60=; b=FvcB9/v3lfiu8yQdigH2ck3Cvb8dlXdAt/hSpFHJt3s3JJMpTC5ERzoj pzY6/aLQsddmDwI6PFps1ECZ6q7BZs21ZVMtJo4oLIoSGO6upAMjNo8yk 9iNG1FU/v9EsqtYlP8ntENvbHTap8wJF9CakVFBp/9UQsXXX4gxZv8h71 E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AnYJAId9mFOtJA2I/2dsb2JhbABagkZHUlmCbKd1AQEBAQEBBQGDCI0FgVIBhmpRARltFnWEAwEBAQQBAQEgCkELEAIBCA4DBAEBCx0DAgICJQsUCQgBAQQOBQiIOg2wMJ88F4VciEwtBAYBgnU2gRYEm3CSCYM8gi8
X-IronPort-AV: E=Sophos; i="5.01,458,1400025600"; d="scan'208,217"; a="52212609"
Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-6.cisco.com with ESMTP; 11 Jun 2014 16:05:54 +0000
Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s5BG5sg7002159 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 11 Jun 2014 16:05:54 GMT
Received: from xmb-rcd-x08.cisco.com ([169.254.8.200]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.03.0123.003; Wed, 11 Jun 2014 11:05:54 -0500
From: "Tissa Senevirathne (tsenevir)" 
To: Thomas Nadeau 
Thread-Topic: [netmod] YANG models for OAM
Thread-Index: Ac+E3qlMyPi638vnRGmjYh75Wx+edAAx3I+AAAXWFYA=
Date: Wed, 11 Jun 2014 16:05:53 +0000
Message-ID: 
References:  
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.155.1.132]
Content-Type: multipart/alternative; boundary="_000_FBEA3E19AA24F847BA3AE74E2FE193562EE925ABxmbrcdx08ciscoc_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/-k6he6S1F_vMIVV958PktkrebxM
Cc: "l2vpn@ietf.org" , "opsawg@ietf.org" , "nvo3@ietf.org" , "netmod@ietf.org" , "trill@ietf.org" 
Subject: Re: [netmod] YANG models for OAM
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 11 Jun 2014 16:05:57 -0000

--_000_FBEA3E19AA24F847BA3AE74E2FE193562EE925ABxmbrcdx08ciscoc_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

QWxsIG9mIFRoZSBZQU5HIGNvZGUgaXMgaW5jbHVkZWQgaW4gZHJhZnRzLiBPciBhcmUgeW91IHJl
ZmVycmluZyB0byBiYWNrZW5kIGltcGxlbWVudGF0aW9ucyBvciBYTUwgZW5jb2RpbmcgPw0KDQpG
cm9tOiBUaG9tYXMgTmFkZWF1IFttYWlsdG86dG5hZGVhdUBsdWNpZHZpc2lvbi5jb21dDQpTZW50
OiBXZWRuZXNkYXksIEp1bmUgMTEsIDIwMTQgNjo1MSBBTQ0KVG86IFRpc3NhIFNlbmV2aXJhdGhu
ZSAodHNlbmV2aXIpDQpDYzogbmV0bW9kQGlldGYub3JnOyBudm8zQGlldGYub3JnOyB0cmlsbEBp
ZXRmLm9yZzsgbDJ2cG5AaWV0Zi5vcmc7IG9wc2F3Z0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtu
ZXRtb2RdIFlBTkcgbW9kZWxzIGZvciBPQU0NCg0KQXJlIHRoZXNlIG1vZGVscyBiYXNlZCBvbiBh
bnkgaW1wbGVtZW50YXRpb24vcyBvciBwcm9vZi1vZi1jb25jZXB0IGNvZGUgdGhhdCBhbnlvbmUg
Y2FuIGxvb2sgYXQ/DQoNClRvbQ0KDQoNCk9uIEp1biAxMCwgMjAxNCwgYXQgMTI6MDMgUE0sICJU
aXNzYSBTZW5ldmlyYXRobmUgKHRzZW5ldmlyKSIgPHRzZW5ldmlyQGNpc2NvLmNvbTxtYWlsdG86
dHNlbmV2aXJAY2lzY28uY29tPj4gd3JvdGU6DQpBbGwNCg0KV2UgaGF2ZSBwdWJsaXNoZWQgWUFO
RyBtb2RlbCBmb3IgT0FNLiAjMSBkcmFmdCBiZWxvdyBwbGFjZSB0aGUgZ2VuZXJpYyBmcmFtZXdv
cmsgZm9yIE9BTSwgdGhhdCBjYW4gYmUgYXVnbWVudGVkIGZvciBkaWZmZXJlbnQgdGVjaG5vbG9n
aWVzLiAjMiBhbmQgIzMgYXJlIGFwcGxpY2F0aW9uIG9mIHRoZSBjb25jZXB0IHRvIE5WTzMgYW5k
IFRSSUxMLA0KDQoNCjEuICAgICAgaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFm
dC10aXNzYS1uZXRtb2Qtb2FtLw0KDQoyLiAgICAgIGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9y
Zy9kb2MvZHJhZnQtdGlzc2EtbnZvMy15YW5nLW9hbS8NCg0KMy4gICAgICBodHRwOi8vZGF0YXRy
YWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXRpc3NhLXRyaWxsLXlhbmctb2FtLw0KDQpQbGVhc2Ug
cmV2aWV3IGFuZCBzaGFyZSB5b3VyIGNvbW1lbnRzDQoNClRoYW5rcw0KVGlzc2ENCg0KDQpfX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbmV0bW9kIG1haWxp
bmcgbGlzdA0KbmV0bW9kQGlldGYub3JnPG1haWx0bzpuZXRtb2RAaWV0Zi5vcmc+DQpodHRwczov
L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0K

--_000_FBEA3E19AA24F847BA3AE74E2FE193562EE925ABxmbrcdx08ciscoc_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ
e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov
KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z
b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp
emU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KYTpsaW5r
LCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1
ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBl
cmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0K
CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29M
aXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6
MzQ7DQoJbWFyZ2luLXRvcDowaW47DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltYXJnaW4tYm90dG9t
OjBpbjsNCgltYXJnaW4tbGVmdDouNWluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250
LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0Kc3Bh
bi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6
IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxT
dHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJD
YWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0K
CXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdl
IFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4g
MS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQov
KiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDo3MDA5MzMwMDM7
DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi04ODQ1MTMx
NCA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNSA2
NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNTt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVs
LXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt
aW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt
YXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51
bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZl
bDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRh
Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWlu
ZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC10YWItc3RvcDpub25l
Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47
fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2Vy
Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246
bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZl
bC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0K
CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30N
CkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt
bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxl
dmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwt
dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p
bmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h
dDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt
YmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpvbA0KCXttYXJnaW4t
Ym90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48L3N0eWxlPjwhLS1b
aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1h
eD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K
PG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9
IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9k
eSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJX
b3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMx
RjQ5N0QiPkFsbCBvZiBUaGUgWUFORyBjb2RlIGlzIGluY2x1ZGVkIGluIGRyYWZ0cy4gT3IgYXJl
IHlvdSByZWZlcnJpbmcgdG8gYmFja2VuZCBpbXBsZW1lbnRhdGlvbnMgb3IgWE1MIGVuY29kaW5n
ID88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxk
aXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRk
aW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVv
dDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm
cXVvdDsiPiBUaG9tYXMgTmFkZWF1IFttYWlsdG86dG5hZGVhdUBsdWNpZHZpc2lvbi5jb21dDQo8
YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBKdW5lIDExLCAyMDE0IDY6NTEgQU08YnI+DQo8
Yj5Ubzo8L2I+IFRpc3NhIFNlbmV2aXJhdGhuZSAodHNlbmV2aXIpPGJyPg0KPGI+Q2M6PC9iPiBu
ZXRtb2RAaWV0Zi5vcmc7IG52bzNAaWV0Zi5vcmc7IHRyaWxsQGlldGYub3JnOyBsMnZwbkBpZXRm
Lm9yZzsgb3BzYXdnQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbbmV0bW9kXSBZ
QU5HIG1vZGVscyBmb3IgT0FNPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPkFyZSB0aGVzZSBtb2RlbHMgYmFzZWQgb24gYW55IGltcGxlbWVudGF0
aW9uL3Mgb3IgcHJvb2Ytb2YtY29uY2VwdCBjb2RlIHRoYXQgYW55b25lIGNhbiBsb29rIGF0Pzxv
OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m
bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Ub20m
bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQpPbiBKdW4gMTAsIDIwMTQsIGF0
IDEyOjAzIFBNLCAmcXVvdDtUaXNzYSBTZW5ldmlyYXRobmUgKHRzZW5ldmlyKSZxdW90OyAmbHQ7
PGEgaHJlZj0ibWFpbHRvOnRzZW5ldmlyQGNpc2NvLmNvbSI+dHNlbmV2aXJAY2lzY28uY29tPC9h
PiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJt
YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPkFsbDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7
PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XZSBoYXZlIHB1Ymxpc2hlZCBZ
QU5HIG1vZGVsIGZvciBPQU0uICMxIGRyYWZ0IGJlbG93IHBsYWNlIHRoZSBnZW5lcmljIGZyYW1l
d29yayBmb3IgT0FNLCB0aGF0IGNhbiBiZSBhdWdtZW50ZWQgZm9yIGRpZmZlcmVudCB0ZWNobm9s
b2dpZXMuICMyIGFuZCAjMyBhcmUgYXBwbGljYXRpb24gb2YgdGhlIGNvbmNlcHQgdG8gTlZPMyBh
bmQgVFJJTEwsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpw
PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRl
bnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBsZm8yIj48IVtpZiAhc3VwcG9ydExpc3RzXT48
c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4xLjxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZx
dW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
DQo8L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48YSBocmVmPSJodHRwOi8vZGF0YXRyYWNrZXIuaWV0
Zi5vcmcvZG9jL2RyYWZ0LXRpc3NhLW5ldG1vZC1vYW0vIj5odHRwOi8vZGF0YXRyYWNrZXIuaWV0
Zi5vcmcvZG9jL2RyYWZ0LXRpc3NhLW5ldG1vZC1vYW0vPC9hPjxvOnA+PC9vOnA+PC9wPg0KPHAg
Y2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW47bXNvLWxp
c3Q6bDAgbGV2ZWwxIGxmbzIiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJtc28t
bGlzdDpJZ25vcmUiPjIuPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJv
bWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+
PCFbZW5kaWZdPjxhIGhyZWY9Imh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQt
dGlzc2EtbnZvMy15YW5nLW9hbS8iPmh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJh
ZnQtdGlzc2EtbnZvMy15YW5nLW9hbS88L2E+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv
TGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZl
bDEgbGZvMiI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9y
ZSI+My48c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsi
PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+
PGEgaHJlZj0iaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC10aXNzYS10cmls
bC15YW5nLW9hbS8iPmh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtdGlzc2Et
dHJpbGwteWFuZy1vYW0vPC9hPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5QbGVhc2UgcmV2aWV3
IGFuZCBzaGFyZSB5b3VyIGNvbW1lbnRzPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rczxv
OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGlzc2E8bzpwPjwvbzpwPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxi
bG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90
OyI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpu
ZXRtb2QgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOm5ldG1vZEBpZXRmLm9yZyI+
bmV0bW9kQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21h
aWxtYW4vbGlzdGluZm8vbmV0bW9kIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp
bmZvL25ldG1vZDwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90
ZT4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K

--_000_FBEA3E19AA24F847BA3AE74E2FE193562EE925ABxmbrcdx08ciscoc_--


From nobody Thu Jun 12 01:12:42 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E2141A0199 for ; Thu, 12 Jun 2014 01:12:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.3
X-Spam-Level: 
X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_25=0.6] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8raoOysr8Pmp for ; Thu, 12 Jun 2014 01:12:38 -0700 (PDT)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB6DB1A0034 for ; Thu, 12 Jun 2014 01:12:38 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id CC72D5408D4; Thu, 12 Jun 2014 10:12:35 +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 Am5n5osFAUJl; Thu, 12 Jun 2014 10:12:30 +0200 (CEST)
Received: from localhost (unknown [172.29.2.201]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id DEB84540447; Thu, 12 Jun 2014 10:12:29 +0200 (CEST)
From: Ladislav Lhotka 
To: Juergen Schoenwaelder , netmod@ietf.org
In-Reply-To: <20140610191914.GC28878@elstar.local>
References: <20140602081547.GB92342@elstar.local> <20140610191914.GC28878@elstar.local>
User-Agent: Notmuch/0.18 (http://notmuchmail.org) Emacs/24.3.50.2 (x86_64-apple-darwin13.0.0)
Date: Thu, 12 Jun 2014 10:12:28 +0200
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/wbU5UEb8So2FzbTH2oqfiKn0ua8
Subject: Re: [netmod] undecided Y19 we need a better unique
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 12 Jun 2014 08:12:40 -0000

Juergen Schoenwaelder  writes:

> On Mon, Jun 02, 2014 at 10:15:47AM +0200, Juergen Schoenwaelder wrote:
>> We need to decide whether this is in scope of YANG 1.1 or not.
>> 
>
> Interim proposal:
>
>   Proposal: Reject this request for a new feature but clarify the
>   semantics of unique in RFC 6020bis (might require to open a separate
>   clarification issue). A new and more powerful unique seems more like
>   a YANG 2.0 work item than a YANG 1.1 work item. The consensus on
>   this was rough (MB prefers to have this issue opened).

In fact, XSD unique is more restricted than the solution proposed in Y19. Essentially, the XPath expression in xs:field is limited to the subtree of the element where the uniqueness constraint appears. It is quite logical - speaking about uniqueness of list entries in terms of values outside the list seems a little weird.

It does make sense in the cited example from the ietf-routing module ("connected-rib" list) because of the leafref that "binds" the outside stuff to each list entry. However, such cases are IMO hard to define and not so common to warrant redesigning the "unique" statement - a "must" statement with an appropriate description should be fine.

Lada

>
> If you disagree, please speak up by June 18th.
>
> /js
>
> -- 
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
> Fax:   +49 421 200 3103         
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

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


From nobody Thu Jun 12 14:49:30 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E2A11A02A2 for ; Thu, 12 Jun 2014 14:49:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level: 
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DkyFl7vaForK for ; Thu, 12 Jun 2014 14:49:28 -0700 (PDT)
Received: from mail-qa0-f50.google.com (mail-qa0-f50.google.com [209.85.216.50]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E71391A0276 for ; Thu, 12 Jun 2014 14:49:27 -0700 (PDT)
Received: by mail-qa0-f50.google.com with SMTP id m5so2421270qaj.9 for ; Thu, 12 Jun 2014 14:49:27 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=BsCHiwbnRAyLyNXvb2r8mm6wKYaPn86xiEeuOyHLPOQ=; b=da8gJQ3ZMV2J0b0tkJ13ZmAFBKpoLx0X1r3mwDj24eIAlhadlv5haRpma62GW/arvP 32alRtIgo9vKyFVKnkSKJQ9BrysCe1Ib9YKRbMqeqQRPij+OCc9DmXNXEfjwCjgeGU6j zHzLS5Uy7oJzNJEyrzuBFxxoo2Ztkmfrbdlymbh8e7A8qe8gs+htLdFyq4NfCYMfmlY0 zekxBY67DGdwoHTxmcsoCPyM+BL7Zq0m8xURJbEjINNtBvlVfxfNxOgzSimKITif36gK 6NOKdYZybdZMUCPWkSQLvf5iM1Z4PSJC3G/7w9hsChiucpVX3uahGCb2sCRo3ACRRiPi zJAQ==
X-Gm-Message-State: ALoCoQmlobfGQtfPDwm8IlXn5UpWdyOE7J0eXC9CC341HHq2q+HrpKRipBA5fptpbrSr17jssVul
MIME-Version: 1.0
X-Received: by 10.140.36.37 with SMTP id o34mr8527662qgo.25.1402609767117; Thu, 12 Jun 2014 14:49:27 -0700 (PDT)
Received: by 10.140.104.49 with HTTP; Thu, 12 Jun 2014 14:49:27 -0700 (PDT)
Date: Thu, 12 Jun 2014 14:49:27 -0700
Message-ID: 
From: Andy Bierman 
To: "netmod@ietf.org" 
Content-Type: multipart/alternative; boundary=001a11c15a48eda62b04fbaa880d
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/KLT9YhAX2rl4SuWmyJXrbr9b0Cw
Subject: [netmod] comments on draft-ietf-netmod-snmp-cfg--05
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 12 Jun 2014 21:49:29 -0000

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

Hi,

It's probably past WG Last Call, but I still do not understand
the value of splitting the ietf-snmp configuration module into
12 files (1 main + 11 sub-modules) instead of just 1 file.

IMO it makes it harder to read, not easier, and wrt/ YANG library
management,
there are 12 files to update and keep in sync, instead of 1.

Is there some expectation that individual sub-modules for SNMP
configuration will be updated regularly in new RFCs?


Andy

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


Hi,

It's probably past WG Last Call=
, but I still do not understand
the value of splitting the ietf-s=
nmp configuration module into
12 files (1 main + 11 sub-modules) =
instead of just 1 file.



IMO it makes it harder to read, not easier, and wrt/ YA=
NG library management,
there are 12 files to update and keep in s=
ync, instead of 1.

Is there some expectation that =
individual sub-modules for SNMP


configuration will be updated regularly in new RFCs?


Andy









--001a11c15a48eda62b04fbaa880d--


From nobody Thu Jun 12 23:26:12 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3B1A1A0384 for ; Thu, 12 Jun 2014 23:26:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.201
X-Spam-Level: 
X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0WEmamYO97vM for ; Thu, 12 Jun 2014 23:26:09 -0700 (PDT)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71F6F1B28D7 for ; Thu, 12 Jun 2014 23:26:09 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 7910D1136; Fri, 13 Jun 2014 08:26:06 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 9meygoNIxEqm; Fri, 13 Jun 2014 08:25:47 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Fri, 13 Jun 2014 08:26:06 +0200 (CEST)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id ACE7220013; Fri, 13 Jun 2014 08:26:07 +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 iIt_hOldc8YC; Fri, 13 Jun 2014 08:25:51 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A316A20017; Fri, 13 Jun 2014 08:26:06 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id A8B7A2D64C49; Fri, 13 Jun 2014 08:26:05 +0200 (CEST)
Date: Fri, 13 Jun 2014 08:26:05 +0200
From: Juergen Schoenwaelder 
To: Andy Bierman 
Message-ID: <20140613062605.GA37482@elstar.local>
Mail-Followup-To: Andy Bierman , "netmod@ietf.org" 
References: 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.4.2.3i
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/ky5HMk9nsSBlzwqqm4V2jNlUtxQ
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] comments on draft-ietf-netmod-snmp-cfg--05
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 13 Jun 2014 06:26:11 -0000

On Thu, Jun 12, 2014 at 02:49:27PM -0700, Andy Bierman wrote:
> Hi,
> 
> It's probably past WG Last Call, but I still do not understand
> the value of splitting the ietf-snmp configuration module into
> 12 files (1 main + 11 sub-modules) instead of just 1 file.
> 
> IMO it makes it harder to read, not easier, and wrt/ YANG library
> management,
> there are 12 files to update and keep in sync, instead of 1.
> 
> Is there some expectation that individual sub-modules for SNMP
> configuration will be updated regularly in new RFCs?

The organization essentially reflects the modular structure of the
SNMPv3 MIB modules. The SNMPv3 MIB modules are roughly the same
number.

If updates will ever will be necessary, we might benefit from the
modular structure. If updates will never be needed, there is not much
work with synchronizing the sub-modules either. Whether modularity is
a good thing of not can likely be discussed endlessly. In this case,
we followed the modular structure of the SNMPv3 MIB modules.

/js

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


From nobody Fri Jun 13 04:18:07 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E7271A04C8 for ; Fri, 13 Jun 2014 04:18:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level: 
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2selz5om6Ond for ; Fri, 13 Jun 2014 04:18:03 -0700 (PDT)
Received: from mail-qc0-f171.google.com (mail-qc0-f171.google.com [209.85.216.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 827D91A0463 for ; Fri, 13 Jun 2014 04:18:03 -0700 (PDT)
Received: by mail-qc0-f171.google.com with SMTP id w7so3961835qcr.16 for ; Fri, 13 Jun 2014 04:18:02 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=dAJX+CW6c+PpBpg3CJ1/doDjORy87LdZ2VFYppTGZVA=; b=hElEuR3YJhUIsYWrcfyNheZvebDOKj+laAA1tSqLp3JW6622/KSLS2oZ1ZDRTGCAEb XMhkydXumulx++x2sKhrFsdlgzNf7whOeX98oI+c+bXgSTkGJnKSB7TVCB/PNaU0rqPc FjJAV76QTqpUdNoI/0TVJ5A6oCbLckh7+jvCKm2W+WROaBG8ODWMrmqB97MxBdkZPU6N xt7EIc1I45UU2bPVuSJ9hNxldtoHomZ3AnS+cVz80DfIHJnn8Jiyx4BWhBeN7qmVTIuG 7H/lh4WsX2WiE4Vxj2WfTfSHdmo8T6e1Krra5YSKZmaGdwstsLLGUs7Df+E4Axr4nOCh KP8w==
X-Gm-Message-State: ALoCoQnLJdyP0ILJNcOP5nyu0RQyBfu6oFV0Xcb5ALqTT0rNKTjNvKoFOX0BR2wkLm/e68v+/0W3
MIME-Version: 1.0
X-Received: by 10.229.93.133 with SMTP id v5mr2503416qcm.1.1402658282707; Fri, 13 Jun 2014 04:18:02 -0700 (PDT)
Received: by 10.140.104.49 with HTTP; Fri, 13 Jun 2014 04:18:02 -0700 (PDT)
In-Reply-To: <20140613062605.GA37482@elstar.local>
References:  <20140613062605.GA37482@elstar.local>
Date: Fri, 13 Jun 2014 04:18:02 -0700
Message-ID: 
From: Andy Bierman 
To: Juergen Schoenwaelder , Andy Bierman , "netmod@ietf.org" 
Content-Type: multipart/alternative; boundary=001a11330666aeb34604fbb5d40a
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/D4kGaWeDj8NmXxqR9P0D7eTccS0
Subject: Re: [netmod] comments on draft-ietf-netmod-snmp-cfg--05
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 13 Jun 2014 11:18:06 -0000

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

On Thu, Jun 12, 2014 at 11:26 PM, Juergen Schoenwaelder <
j.schoenwaelder@jacobs-university.de> wrote:

> On Thu, Jun 12, 2014 at 02:49:27PM -0700, Andy Bierman wrote:
> > Hi,
> >
> > It's probably past WG Last Call, but I still do not understand
> > the value of splitting the ietf-snmp configuration module into
> > 12 files (1 main + 11 sub-modules) instead of just 1 file.
> >
> > IMO it makes it harder to read, not easier, and wrt/ YANG library
> > management,
> > there are 12 files to update and keep in sync, instead of 1.
> >
> > Is there some expectation that individual sub-modules for SNMP
> > configuration will be updated regularly in new RFCs?
>
> The organization essentially reflects the modular structure of the
> SNMPv3 MIB modules. The SNMPv3 MIB modules are roughly the same
> number.
>
> If updates will ever will be necessary, we might benefit from the
> modular structure. If updates will never be needed, there is not much
> work with synchronizing the sub-modules either. Whether modularity is
> a good thing of not can likely be discussed endlessly. In this case,
> we followed the modular structure of the SNMPv3 MIB modules.
>
>
Seems like SNMP WG had a good reason to have 12 modules
(not all developed at once like the YANG modules). Half the
YANG text is boilerplate. (Copied 12 times to make sure it gets read!)

I am glad this module is an anomaly. Not one other YANG module
in the IETF uses submodules, let alone 11 of them.


/js
>

Andy


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

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





On Thu, Jun 12, 2014 at 11:26 PM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:


On Thu, Jun 12, 2014 at 02:49:27PM -0700, An=
dy Bierman wrote:

> Hi,

>

> It's probably past WG Last Call, but I still do not understand

> the value of splitting the ietf-snmp configuration module into

> 12 files (1 main + 11 sub-modules) instead of just 1 file.

>

> IMO it makes it harder to read, not easier, and wrt/ YANG library

> management,

> there are 12 files to update and keep in sync, instead of 1.

>

> Is there some expectation that individual sub-modules for SNMP

> configuration will be updated regularly in new RFCs?



The organization essentially reflects the modular structure of the

SNMPv3 MIB modules. The SNMPv3 MIB modules are roughly the same

number.



If updates will ever will be necessary, we might benefit from the

modular structure. If updates will never be needed, there is not much

work with synchronizing the sub-modules either. Whether modularity is

a good thing of not can likely be discussed endlessly. In this case,

we followed the modular structure of the SNMPv3 MIB modules.



Seems like SNMP WG had a good reason to have 12 modu=
les
(not all developed at once like the YANG modules). Half the

YANG text is boilerplate. (Copied 12 times to make sure it gets read!)=


I am glad this module is an anomaly. Not one othe=
r YANG module
in the IETF uses submodules, let alone 11 of them.<=
/div>




/js

Andy
=A0



--

Juergen Schoenwaelder =A0 =A0 =A0 =A0 =A0 Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 =A0 =A0 =A0 =A0 Campus Ring 1, 28759 Bremen, German=
y

Fax: =A0 +49 421 200 3103 =A0 =A0 =A0 =A0 <http://www.jacobs-university.de/><=
br>




--001a11330666aeb34604fbb5d40a--


From nobody Fri Jun 13 12:01:44 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 683E11B29E8 for ; Fri, 13 Jun 2014 12:01:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level: 
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KxJTmw3u9ebE for ; Fri, 13 Jun 2014 12:01:40 -0700 (PDT)
Received: from mail-qa0-f45.google.com (mail-qa0-f45.google.com [209.85.216.45]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E97361B29E1 for ; Fri, 13 Jun 2014 12:01:37 -0700 (PDT)
Received: by mail-qa0-f45.google.com with SMTP id v10so4179248qac.4 for ; Fri, 13 Jun 2014 12:01:37 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=iwbAP1HiY+lyBT7Qy6NJ7qe+YxAnU5XwzlMgn9h+Mow=; b=eTIZjJzmolMoSZIEA5QPcHrw1P2fGxS8Eh5b3YiXDwQjgR1C9fN4exT2ReQBWEzn7k aMT7j3ydzrGYwmzzdg6ZUHWtWYr22xmplRYDF1uQ5I6AAslUV+LbB55OJSz0lDTl1lJk 5W8hv6tn6mXJ7FeK8m4nFLCpjPcXvdQmmUr6cBQQXonMkQ7sj2MtmBR8zKWVeVi/p3KU yY9TG1v7t7XztquXi2HafDQN/5on0WfxFtbgiyQqsadml1pO5S5VuHBx3TZElV9NsE2h HMBU03vH08A0KyEurOmyUHzvUnVDQaEFxnpa1X2aNK5q2VAHWryEzgB6U7Z90MAJpd4S ck1Q==
X-Gm-Message-State: ALoCoQme7dQ9Gevs/6ONM2wE+NYJbF2uk4T+oHZ04bDjlucEJot1zfAuCg7b/PLcUPPfR45Fouc7
MIME-Version: 1.0
X-Received: by 10.224.20.10 with SMTP id d10mr6551993qab.16.1402686097129; Fri, 13 Jun 2014 12:01:37 -0700 (PDT)
Received: by 10.140.104.49 with HTTP; Fri, 13 Jun 2014 12:01:37 -0700 (PDT)
In-Reply-To: <20140613062605.GA37482@elstar.local>
References:  <20140613062605.GA37482@elstar.local>
Date: Fri, 13 Jun 2014 12:01:37 -0700
Message-ID: 
From: Andy Bierman 
To: Juergen Schoenwaelder , Andy Bierman , "netmod@ietf.org" 
Content-Type: multipart/alternative; boundary=001a11c1c2ae8d57de04fbbc4ef3
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/YpFhpOH7DeX7inHQxboEpq3QKcA
Subject: Re: [netmod] comments on draft-ietf-netmod-snmp-cfg--05
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 13 Jun 2014 19:01:42 -0000

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

On Thu, Jun 12, 2014 at 11:26 PM, Juergen Schoenwaelder <
j.schoenwaelder@jacobs-university.de> wrote:

> On Thu, Jun 12, 2014 at 02:49:27PM -0700, Andy Bierman wrote:
> > Hi,
> >
> > It's probably past WG Last Call, but I still do not understand
> > the value of splitting the ietf-snmp configuration module into
> > 12 files (1 main + 11 sub-modules) instead of just 1 file.
> >
> > IMO it makes it harder to read, not easier, and wrt/ YANG library
> > management,
> > there are 12 files to update and keep in sync, instead of 1.
> >
> > Is there some expectation that individual sub-modules for SNMP
> > configuration will be updated regularly in new RFCs?
>
> The organization essentially reflects the modular structure of the
> SNMPv3 MIB modules. The SNMPv3 MIB modules are roughly the same
> number.
>
> If updates will ever will be necessary, we might benefit from the
> modular structure. If updates will never be needed, there is not much
> work with synchronizing the sub-modules either. Whether modularity is
> a good thing of not can likely be discussed endlessly. In this case,
> we followed the modular structure of the SNMPv3 MIB modules.
>
>

Actually, you did not really follow the SMIv2 structure, or you would have
used
modules instead of submodules. The main module (ietf-snmp) is just a list
of include-by-revision statements.  All submodules have to be present
or the tool will exit with a fatal error.  I suppose the main module could
be altered by vendors (e.g., comment out the include-stmts they don't want
to support), but that would be non-compliant for standard modules.


/js
>

Andy


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

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





On Thu, Jun 12, 2014 at 11:26 PM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:


On Thu, Jun 12, 2014 at 02:49:27PM -0700, An=
dy Bierman wrote:

> Hi,

>

> It's probably past WG Last Call, but I still do not understand

> the value of splitting the ietf-snmp configuration module into

> 12 files (1 main + 11 sub-modules) instead of just 1 file.

>

> IMO it makes it harder to read, not easier, and wrt/ YANG library

> management,

> there are 12 files to update and keep in sync, instead of 1.

>

> Is there some expectation that individual sub-modules for SNMP

> configuration will be updated regularly in new RFCs?



The organization essentially reflects the modular structure of the

SNMPv3 MIB modules. The SNMPv3 MIB modules are roughly the same

number.



If updates will ever will be necessary, we might benefit from the

modular structure. If updates will never be needed, there is not much

work with synchronizing the sub-modules either. Whether modularity is

a good thing of not can likely be discussed endlessly. In this case,

we followed the modular structure of the SNMPv3 MIB modules.




Actually, you did not really follow t=
he SMIv2 structure, or you would have used
modules instead of sub=
modules. The main module (ietf-snmp) is just a list


of include-by-revision statements. =A0All submodules have to be presen=
t
or the tool will exit with a fatal error. =A0I suppose the main=
 module could
be altered by vendors (e.g., comment out the includ=
e-stmts they don't want


to support), but that would be non-compliant for standard modules.



/js

Andy
=A0



--

Juergen Schoenwaelder =A0 =A0 =A0 =A0 =A0 Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 =A0 =A0 =A0 =A0 Campus Ring 1, 28759 Bremen, German=
y

Fax: =A0 +49 421 200 3103 =A0 =A0 =A0 =A0 <http://www.jacobs-university.de/><=
br>




--001a11c1c2ae8d57de04fbbc4ef3--


From nobody Fri Jun 13 14:03:58 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 898971B2A4F for ; Fri, 13 Jun 2014 14:03:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.201
X-Spam-Level: 
X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oaidriqz6Wid for ; Fri, 13 Jun 2014 14:03:53 -0700 (PDT)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1B9B1B2A4C for ; Fri, 13 Jun 2014 14:03:51 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 61C13E88; Fri, 13 Jun 2014 23:03:48 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id ZZ-swClgbJTl; Fri, 13 Jun 2014 23:03:26 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Fri, 13 Jun 2014 23:03:47 +0200 (CEST)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 60CDE20017; Fri, 13 Jun 2014 23:03:49 +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 qpj9SRgp8Hmm; Fri, 13 Jun 2014 23:03:48 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id EBA6020013; Fri, 13 Jun 2014 23:03:47 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id D60252D651ED; Fri, 13 Jun 2014 23:03:47 +0200 (CEST)
Date: Fri, 13 Jun 2014 23:03:47 +0200
From: Juergen Schoenwaelder 
To: Andy Bierman 
Message-ID: <20140613210347.GA38910@elstar.local>
Mail-Followup-To: Andy Bierman , "netmod@ietf.org" 
References:  <20140613062605.GA37482@elstar.local> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.4.2.3i
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/5Z6BuHn1K8aKPf2MACRytZTz8LE
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] comments on draft-ietf-netmod-snmp-cfg--05
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 13 Jun 2014 21:03:55 -0000

On Fri, Jun 13, 2014 at 12:01:37PM -0700, Andy Bierman wrote:
> On Thu, Jun 12, 2014 at 11:26 PM, Juergen Schoenwaelder <
> j.schoenwaelder@jacobs-university.de> wrote:
> 
> > On Thu, Jun 12, 2014 at 02:49:27PM -0700, Andy Bierman wrote:
> > > Hi,
> > >
> > > It's probably past WG Last Call, but I still do not understand
> > > the value of splitting the ietf-snmp configuration module into
> > > 12 files (1 main + 11 sub-modules) instead of just 1 file.
> > >
> > > IMO it makes it harder to read, not easier, and wrt/ YANG library
> > > management,
> > > there are 12 files to update and keep in sync, instead of 1.
> > >
> > > Is there some expectation that individual sub-modules for SNMP
> > > configuration will be updated regularly in new RFCs?
> >
> > The organization essentially reflects the modular structure of the
> > SNMPv3 MIB modules. The SNMPv3 MIB modules are roughly the same
> > number.
> >
> > If updates will ever will be necessary, we might benefit from the
> > modular structure. If updates will never be needed, there is not much
> > work with synchronizing the sub-modules either. Whether modularity is
> > a good thing of not can likely be discussed endlessly. In this case,
> > we followed the modular structure of the SNMPv3 MIB modules.
> >
> >
> 
> Actually, you did not really follow the SMIv2 structure, or you
> would have used modules instead of submodules.

I wrote "reflects the modular structure of the SNMPv3 MIB modules". I
think my statement was precise.

> The main module (ietf-snmp) is just a list of include-by-revision
> statements.

Correct.

> All submodules have to be present or the tool will exit with a fatal
> error.

Correct.

> I suppose the main module could be altered by vendors (e.g., comment
> out the include-stmts they don't want to support), but that would be
> non-compliant for standard modules.

Yes, it is possible to implement a standard incorrectly.

It does not matter whether a vendor comments out an include statement
or comments out complete containers. The result is equally broken.

/js

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


From nobody Sat Jun 14 01:06:13 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EBB61B2BCD; Sat, 14 Jun 2014 01:06:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.201
X-Spam-Level: 
X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c0pn-nUAdyOO; Sat, 14 Jun 2014 01:06:02 -0700 (PDT)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0182D1B2BC9; Sat, 14 Jun 2014 01:06:02 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 821F6F6F; Sat, 14 Jun 2014 10:05:58 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id wiDp2AIaCwNS; Sat, 14 Jun 2014 10:05:33 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Sat, 14 Jun 2014 10:05:56 +0200 (CEST)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 46FEF20017; Sat, 14 Jun 2014 10:05:58 +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 OJOTs6QqFG3Y; Sat, 14 Jun 2014 10:05:37 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 33A9E20013; Sat, 14 Jun 2014 10:05:55 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 3400E2D7BB88; Sat, 14 Jun 2014 10:05:53 +0200 (CEST)
Date: Sat, 14 Jun 2014 10:05:53 +0200
From: Juergen Schoenwaelder 
To: proceedings@ietf.org
Message-ID: <20140614080553.GA69256@elstar.local>
Mail-Followup-To: proceedings@ietf.org, netmod@ietf.org
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="7JfCtLOvnd9MIVvH"
Content-Disposition: inline
User-Agent: Mutt/1.4.2.3i
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/TNShc-P3-udfMDfTQc8SoWTj2lg
Cc: netmod@ietf.org
Subject: [netmod] minutes of the NETMOD 2014-06-04 virtual interim meeting
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 14 Jun 2014 08:06:07 -0000

--7JfCtLOvnd9MIVvH
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

Hi,

attached please find the minutes of the NETMOD virtual interim
meeting that took place on 2014-06-04.

/js

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

--7JfCtLOvnd9MIVvH
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="netmod-2014-06-04-minutes.txt"

=============================================================
NETCONF Data Modeling Language WG (netmod)
1st YANG 1.1 Virtual Interim
Wednesday, June 4th, 2014, 16:00-16:00 CEST
Minutes Benoit Claise, Juergen Schoenwaelder
=============================================================

* Participants

  - JS = Juergen Schoenwaelder
  - BC = Benoit Claise
  - AZ = Alex Zhankin
  - AB = Andy Bierman
  - BZ = Bernd Zeuner
  - DR = Dan Romascanu
  - JT = Jason Sterne
  - KW = Kent Watsen
  - LL = Lada Lotka
  - MB = Martin Bjorklund
  - PH = Peter van Horne
  - XL = Xufeng Liu
  - AN = anonymous

* Summary

  The goal of the 1st virtual interim meeting was to decide on the
  submitted issues marked NEW and without a strawman position (or a
  strawman position that led to discussions) whether they are in scope
  (OPEN) of the YANG 1.1 effort or out of scope (REJECT).

* Y31 allow require-instance in leafref

  Proposal: Keep Y31 open as already being discussed on the mailing
  list. LL, MB, AB, AZ in favor of moving this to open.

* Y09 introduce optional keys

  LL thinks a key not present simply does not contribute to the
  uniqueness requirement.

  AB against it since it breaks restconf. Why is this really needed?
  
  LL has no problem with opening the issue and seeing whether a
  solution can be found.
  
  AB how does this map to things like SQL? What are the interactions
  with optional keys?

  AZ we should perhaps abstract from implementation details.

  MB volunteers to come up with a concrete proposal and then we can
  decide whether the complexity is under control.

  KW does not see a simple mapping to SQL. I tend to agree with AB
  that this is perhaps complex. Why would you not use artificial keys?

  MB says that in some cases the data model would be more natural.

  AB says if a leaf is optional, then it is really not part of the key
  and you might be picking the wrong thing as a key.

  AB asks what happens if there are multiple optional keys? Can they
  all be optional?

  BC asks whether AB is afraid of the combination of multiple optional
  keys?

  AB responds that the key is crucial for naming.

  Proposal: Move this to open for now. Some concerns from KW and
  AB. We might revisit this issue later if the complexity/cost of a
  solution is too high. Action item for MB to provide a detailed
  solution proposal.

* Y19 we need a better unique

  LL says that nested lists can already be included in XPATH, at least
  the DSDL mapping handles this.

  MB says we need to make sure that the current unique works
  correctly with the DSDL and clarify RFC 6020.

  MB is fine with the interpretation of the DSDL draft. But MB also
  says that we need to check whether the DSDL mapping solution
  achieves the same as the issue writeup.

  AB is concerned that this adds complexity.

  LL got concerned that if semantics deviate from what the DSDL
  mapping currently does, then he is against accepting this.

  AB remarks that maybe it is easier to tell people how to use must
  statements to achieve similar results.

  AB is concerned that we end up with two unique statments and then we
  need to tell everybody what the difference is and when to use which;
  not convinced that this better unique is needed.

  PH this sounds more like an optimization.

  PO says it does not break backwards compatibility.

  Proposal: Reject this request for a new feature but clarify the
  semantics of unique in RFC 6020bis (might require to open a separate
  clarification issue). A new and more powerful unique seems more like
  a YANG 2.0 work item than a YANG 1.1 work item. The consensus on
  this was rough (MB prefers to have this issue opened).

* Y21 statement to define new XPath functions in a module

  MB we apparently need a few more XPATH functions. The question is
  whether these XPATH functions are hard wired in the language
  (requiring a language update for each addition).

  LL says that implementations simply can't ignore the XPATH functions
  and hence it does not satisfy the requirement of the extension
  statement.

  AB is concerned about interoperability problems.

  AZ thinks it is a bad idea to define XPATH function in YANG itself.
  
  MB says that in the IETF, we would need to bump the YANG version
  number when we add new XPATH functions.
  
  PO says the alternative today is to implement an extension to
  support the same function (which would be ignored by existing
  implementations).

  Proposal: Reject this request for a YANG statement to declare new
  XPATH functions.

* Y22 support constraints on unions

  AB says it is not clear which problem is being solved. Why does it
  need to get exposed which type statement of the union got selected?
  
  PO how is it well defined what the value set is?
  
  AB says that if a value matches any of the types in the union, the
  value is valid. The value set hence is really the union of the types
  involved.

  PO says in XML and JSON, you can have the type identified. What YANG
  does is sufficient for validation.

  LL agrees that this should be rejected.

  MB agrees to reject as well.

  PO suggests to clarify that this is primarily for validation and not
  necessarily for type identification.

  LL says there is text that types are tried sequentially.

  Proposal: Reject the issue and add a new issue that a clarification
  is needed about the nature of unions and that they primarily are
  needed for validation.

* Y26 allow mandatory nodes in augment
  
  MB believes the current rules are too strict but removing the rule
  would allow things to break easily.

  LL says the overarching principle is that published modules are not
  allowed to become invalid by augments.

  AB sees a problem if an old client implements old module A and later
  a new module augmenting module A comes along causing things to stop
  working for the old client.

  AB says there are ways this can be done if a module has been
  designed for such mandatory augmentations.

  MB says that in certain cases such a mandatory augmentation is fine;
  the problem is defining and writing down the rules.

  PO asks whether it is possible to create rules like augmentations
  with mandatory is allowed if the augmentation is guarded by a when
  statement?

  MB says it is difficult to write up such rules. Suggests to open
  this and reject it later if we can't come up with good rules.

  AB says unless we have service level conformance, the mandatory
  property is scoped to a module.

  PO asks whether we can just restrict it to what has come up in the
  interfaces data model?

  AB is concerned that it will not be a single case. It is important
  that we protect old clients. It will, however, be difficult for a
  YANG compiler to validate this.

  AZ supports this to be open since we have an actual use case.

  JS asks whether it is possible to relax the current rule with lots
  of explanatory text, assuming that implementations will generate
  warnings based on the current restrictive rule but humans may choose
  to ignore them if they checked that indeed old implementations do
  not break.

  Proposal: Open this issue even though a possible solution remains
  rather unclear.

* Y27 allow mandatory nodes in an updated module

  MB says the intention of the text was to protect old clients.
  However, different from Y26, the revision number changes here.
  MB suggests this to be opened.
  
  AB and LL agree to open this.
  
  Proposal: Open this issue.

* Y33 add 'attribute' statement

  LL says if there are only a really small set of attributes that we
  need, then he is fine with rejecting it.

  AB is OK with a reject since it is likely only a small number of
  attributes that we need.

  AB believes such an attribute statement will likely cause people to
  misuse it.

  Proposal: Reject this issue.

* Y36 associate a notification with a data node

  MB says that he did not have customers asking for this but Tail-f
  has something similar called actions (inlined rpcs). If we do this,
  it makes sense to add inline RPCs as well.

  AZ sees a use case.

  PO sees value in notification source properties attached to leafs.

  PO says that this is essentially about associating a notification
  with a resource object.

  MB says this is a nice to have feature because you can do
  without. Sounds more like a YANG 2.0 issue.

  AB agrees that this is an optimization, perhaps this can also be
  dealt with by certain design patterns.

  JS suggests that one could also think about guidelines on how to
  structure notifications to make resource identification easier.

  Proposal: Reject this issue. May be considered for YANG 2.0.

* Y37 allow notifications to be derived from other notifications

  MB says this is an optimization, nice to have, but not critical.
   
  AB says this is convenient and simple to implement.
   
  JS says that for other things we expect designers to explicitly
  design reusable things, we do not allow uses on an arbitrary
  container.

  Proposal: Reject this issue. Reject supported by LL, AB, and MB.

* Y39 define the terms system/user-controlled instances

  PO asks how exactly is this envisioned to be used?

  MB is concerned that it does not belong in the YANG language
  definition since this seems to be more architectural.

  LL agrees with MB, perhaps this can go into the architecture
  document? Or in a design pattern document.

  PO asks whether there are any consequences of not putting this into
  the YANG 1.1 specification?

  LL answers no, the question is more whether we define this in a
  single place instead of multiple places. Right now, this is defined
  in those data model documents that require this distinction.

  Proposal: Reject since this is an architectural distinction and
  should thus should be defined generically elsewhere. It does not
  seem to be a YANG 1.1 issue.

* Y50 additional extension grammar validation

  MB says this is a nice to heave feature for tool writers, users of
  tools likely do not care.

  PO says that this makes extensions more readable and well
  defined. But yes, this is a nice to have feature.

  MB says that Tail-f has an extension for this but it is a nice to
  have feature and not essential

  AB is concerned that this asks compilers to interpret ABNF at
  runtime.

  PO says that their implementation is not more constrained / precise
  than the existing YANG grammar.

  JS says if this can be done as an extension, why make it part of
  YANG 1.1? Simply write an extension YANG module.

  Proposal: Reject the issue since it can be done as an extension and
  does not need to be part of YANG 1.1.

* Y54 remove the advertisement of conformance information in NETCONF hello message

  MB says all conformance issues need to be discussed together and
  hence we should keep this open as well.

  LL suggests to write a new issue that consolidates all conformance
  related issues.
  
  AB says the way this is written it is not workable.
  
  JS suggests to move Y54 as a solution of Y16.

  JS does not like adding new issues, he prefers to cluster
  conformance related issues.

  Proposal: Open this issue as it is related to the other conformance
  related issues.

--7JfCtLOvnd9MIVvH--


From nobody Sat Jun 14 05:40:31 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E39C1B2C25 for ; Sat, 14 Jun 2014 05:40:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.201
X-Spam-Level: 
X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oFiMutVfq7KI for ; Sat, 14 Jun 2014 05:40:26 -0700 (PDT)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC3F91A0340 for ; Sat, 14 Jun 2014 05:40:25 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 40B97FD3 for ; Sat, 14 Jun 2014 14:40:22 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id bLCWuVWaNN80 for ; Sat, 14 Jun 2014 14:39:56 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Sat, 14 Jun 2014 14:40:20 +0200 (CEST)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id B55B520017 for ; Sat, 14 Jun 2014 14:40:22 +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 lKBoJwLglqJW; Sat, 14 Jun 2014 14:40:20 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 753E220013; Sat, 14 Jun 2014 14:40:20 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 7E7812D7BCCF; Sat, 14 Jun 2014 14:40:18 +0200 (CEST)
Date: Sat, 14 Jun 2014 14:40:18 +0200
From: Juergen Schoenwaelder 
To: netmod@ietf.org
Message-ID: <20140614124018.GA69637@elstar.local>
Mail-Followup-To: netmod@ietf.org
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="qDbXVdCdHGoSgWSk"
Content-Disposition: inline
User-Agent: Mutt/1.4.2.3i
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/ZmBhTKoPkbZPfTDP5kcUMXeL_WI
Subject: [netmod] draft minutes of the 2014-06-11 virtual interim meeting
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 14 Jun 2014 12:40:29 -0000

--qDbXVdCdHGoSgWSk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

Hi,

attached please find the draft minutes of the 2014-06-11 virtual
interim meeting. Note that a final version needs to be submitted
within 10 days - so please send any corrections of the minutes by
Friday June 20th.

/js

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

--qDbXVdCdHGoSgWSk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="netmod-2014-06-11-minutes.txt"

=============================================================
NETCONF Data Modeling Language WG (netmod)
2nd YANG 1.1 Virtual Interim
Wednesday, June 11th, 2014, 16:00-16:00 CEST
Minutes Juergen Schoenwaelder
=============================================================

* Participants

  - JS = Juergen Schoenwaelder
  - AB = Andy Bierman
  - KW = Kent Watsen
  - MB = Martin Bjorklund
  - PO = Peyman Owladi
  - DR = David Reid
  - AZ = Alex Zhankin
  - LL = Lada Lotka
  - PH = Peter van Horne
  - GH = Giles Heron

* Summary

  After a short review of the outcome of the last virtual interim
  meeting, the group started going through the open issues in order to
  discussion solutions. Strawman proposals for solutions were
  identified for Y01-Y06. Since MB will be unavailable the next two
  weeks, it was decided to skip the next two virtual interim meetings
  and to continue on July 2nd.

  It was agreed that JS will track the state changes of the issues in
  the issues list.  MB will start work on a first I-D for YANG 1.1. It
  will contain a section with a high-level summary of the changes since
  RFC 6020 that will be part of the final RFC plus an additional
  section in the appendix cross referencing the issues list. This
  section is intended to make reviews of changes easier and will be
  removed from the final RFC.

* Y55 clarify type in union

  MB added this issue as discussed in the last virtual interim
  meeting.

  Proposal: Open this issue. JS to confirm this on the mailing list.

* additional clarification issue on the mailing list

  AB: Did recently send an additional clarification issues to the
      list. 
  MB: I believe this falls into an existing issue (Y41)
  AB: Why is the server making decisions whether or not to return nodes?
  MB: I am not sure I understand the question. It always depends on the
      semantics of the particular leaf.
  AB: A mandatory false node will not be returned if and only if it
      does not exist (ignoring filters and access control for a
      moment).
  MB: Depends on the semantics of the leaf.
  PO: Non-existence can have specific meaning.
  KW: Mandatory true would mean that a leaf always exist.
  MB: Is this something to be clarified?
  AB: I will take a look at the text to see whether something needs
      changing.

* Y01: allow boolean if-feature

  AB: I am fine with accepting Y01-01, the specification should get 
      the operator precedence right.
  AB: There might be an issue with a feature called 'and'.
  JS: This clash should only be an issue for
         if-feature and; 
      or
         if-feature or;
      and these can be handled as special cases.
  MB: Will add text to make sure that theoretical clashes with 
      features like 'and' and 'or' are well defined.

  Proposal: Adopt Y01-01, MB to work out the edits.

* Y02: allow must in input, output, and notification

  AB: Why do we need these top-level must expressions? When are
      they evaluated? I am fine with Y02-01, not sure about Y02-02.
  PO: I believe mandatory is essentially like a must in a top-level.
  AB: YANG does not allow top-level mandatories. The reason is that
      in practice not all servers may have mandatories all the time,
      e.g. when a module is loaded.
  MB: If you load a module, you need to provide a factory default 
      because otherwise the module would be invalid.
  PO: Here is an example: There must not be more than 100 VLANs on
      this port. This must applies for a top-level list. The logical
      place for the must statement is at the top-level.
  MB: We have the same issue with an empty container.
  AB: What is the context node for the must? The root?
  AB: Should we also consider rpcs? Or does this only apply to data
      nodes?
  MB: It seems Y02-02 does not work because of unclear context, so we
      better go with Y02-01.

  Proposal: Adopt Y02-01. AB and MB support this. MB to work out the
  edits.

* Y03 allow if-feature in refine

  LL: What does it mean? Assume feature in A, grouping in B. 
      C imports B.
  MB: The grouping does not use the feature.
  LL: Yes, I got confused.
  AB: Are there any problems if a refine rewrites an if-feature,
      e.g., adding or removing something from the expression?
  MB: But grouping expansion happens in the usual way, you could always
      cut and paste the grouping and add the if-feature as you like.
  LL: I think this is OK.
  KW: Can this break existing clients?
  LL: No, a server would have to advertise a new module.
  KW: I am not sure whether there could be an issue.

  Proposal: Go along with Y03-01. KW to double check that there is no
  issue with dependencies and versioning.

* Y04 accessible tree in xpath in notifs and rpc

  JS: Where has this become a problem?
  MB: Look at the example.
  LL: Is this similar to something in the SMI?
  AB: This does never happen in SMI.
  MB: The current situation is somewhat wired.
  PO: If you define a type in a top-level module, you can't use that
      type inside of a notification?
  MB: Yes, this is kind of true. It depends on the path and whether
      you have the same structure in a notification.
  PO: Are we sure this is a corner case? Reusing a type in a 
      notification may happen more frequently.
  MB: If we make this change (Y04-01), then existing notifications
      may be illegal.
  AB: We need to rule out solutions that make YANG 1.0 modules
      illegal.
  MB: This is really a bug in the YANG 1.0 specification and we better
      fix it.
  AB: I am in favor of Y04-04.
  MB: But how do we make the bref path legal in YANG 1.0?
  AB: When is this path expression actually evaluated? When the
      event occurs, when the notification is being prepared?
  PO: This seems to tighten the restrictions but conflicts with
      backward compatibility.
  AB: Why do we need to be able to reference things in the
      notification?
  AB: If the notification is returning copies of stuff in the data
      tree, everything should be fine. I am concerned about breaking
      things by changing the meaning of the path statement.
  AB: I believe this is a really corner case and any solution must
      keep existing notifications valid. It may require a new keyword
      to introduce different semantics.
  MB: What is the initial context node of a path statement in a
      notification?
  MB: LL, is the example in Y04 is valid?
  LL: It could be valid - current() means the bref in the
      notification.
  PO: Solution Y04-02 is _not_ problematic since top-level names can't
      clash according to RFC 6020 section 6.2.1.

  Proposal: Go along with Y04-02 now that we have realized that it
  actually works.

* Y05 unprefixed path in top-level typedef

  AB: I am fine with the first solution.
  PO: The binding should be done where the typedef is evaluated.
  JS: I agree with PO.
  MB: This would be solution Y05-03.

  Proposal: MB to write down solution Y05-03 and once done we get back
  to this issue.

* Y06 escaped characters in double quoted strings

  LL: A third solution is that \x means x.
  MB: Randy Presuhn likes Y06-02.
  LL: There may be backwards compatibility issue.
  PO: We pay attention to existing implementations or, if something is
      undefined, we are free to choose any interpretation.
  JS: What does "all known implementations" mean?
  MB: At least YumaPro and Tail-f.
  JS: This is a much more narrow statement.
  MB: Guidelines should say better use single quotes for pattern.
  PO: Could others have copied RFC 6536 style?
  MB: The only hard backwards compatible solution is to leave this
      undefined forever.
  LL: I am in favor for Y06-02.
  KW: I think this is the best option.
  MB: I am in favor of Y06-02.
  JS: I am in favor of Y06-02 as well.
  AB: I am fine with this, it seems a regression bug fix.

  Proposal: Move forward with Y06-02.

--qDbXVdCdHGoSgWSk--


From nobody Mon Jun 16 11:06:19 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A6FE1A0142; Mon, 16 Jun 2014 11:06:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WJcCUsGpSuLZ; Mon, 16 Jun 2014 11:06:13 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C44EC1A013B; Mon, 16 Jun 2014 11:06:13 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 5.5.0.p2
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20140616180613.31989.54213.idtracker@ietfa.amsl.com>
Date: Mon, 16 Jun 2014 11:06:13 -0700
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/39f2wKsCFt6D7rZkq-lWPqhiGXY
Cc: netmod@ietf.org
Subject: [netmod] I-D Action: draft-ietf-netmod-rfc6087bis-00.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 16 Jun 2014 18:06:16 -0000

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           : Guidelines for Authors and Reviewers of YANG Data Model Documents
        Author          : Andy Bierman
	Filename        : draft-ietf-netmod-rfc6087bis-00.txt
	Pages           : 32
	Date            : 2014-06-16

Abstract:
   This memo provides guidelines for authors and reviewers of Standards
   Track specifications containing YANG data model modules.  Applicable
   portions may be used as a basis for reviews of other YANG data model
   documents.  Recommendations and procedures are defined, which are
   intended to increase interoperability and usability of Network
   Configuration Protocol (NETCONF) implementations that utilize YANG
   data model modules.


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

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


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

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


From nobody Tue Jun 17 06:16:18 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 818541A037D for ; Tue, 17 Jun 2014 06:16:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.553
X-Spam-Level: 
X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QV0bN6GMw1IL for ; Tue, 17 Jun 2014 06:16:08 -0700 (PDT)
Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id B2A3A1A037A for ; Tue, 17 Jun 2014 06:16:08 -0700 (PDT)
Received: from [192.168.1.110] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id 2869427E7393 for ; Tue, 17 Jun 2014 09:16:08 -0400 (EDT)
From: "Thomas D. Nadeau" 
Content-Type: multipart/signed; boundary="Apple-Mail=_A62C12DF-5DDC-47F8-963A-1B9029EF55CE"; protocol="application/pgp-signature"; micalg=pgp-sha512
Message-Id: <27C93A81-123A-4244-9ADC-3496764A990D@lucidvision.com>
Date: Tue, 17 Jun 2014 09:16:07 -0400
To: netmod@ietf.org
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
X-Mailer: Apple Mail (2.1878.2)
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/LdgImHCDBQLa0J-SKa810Zj3Yr0
Subject: [netmod] Agenda Slot Requests for EMAN IETF 90 Toronto
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 17 Jun 2014 13:16:12 -0000

--Apple-Mail=_A62C12DF-5DDC-47F8-963A-1B9029EF55CE
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii


	EMAN WG,

	If you would like to request a time-slot for the WG session at =
IETF 90-Toronto, please reply to us by Friday 07/04/2014 along with the =
following information:

	1) Draft title
	2) Presenter name
	3) Requested duration

	Please, make sure that the subject of you reply is for ease of =
tracking: Re:[eman] Agenda 	Slot Requests for EMAN IETF 90 Toronto

	Requests for slots must have had the drafts discussed on the =
mailing list a priori.=20

	The cutoff date for all draft submissions is:

	2014-07-04 (Friday): Internet Draft submission cut-off (for all =
drafts, including -00) by UTC 23:5, upload using IETF ID Submission =
Tool.


	Thanks,

	Tom and Juergen=20


--Apple-Mail=_A62C12DF-5DDC-47F8-963A-1B9029EF55CE
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJToD+XAAoJEPcO+I7eiUJZvKsP/jzVg7P8vEm6k343Y5SSAFtO
E3SqeWb5SmfmD8DIlhBpulOhCQOf9GKhW2oCssY/yfF+smrkLJlOpp3tnUoGlQpq
WSd4YjZNHMw02BnBu3CHl0OvSYQHzThOLW5803ytglyCK2aHPJoLdUMrs8eb+j+e
apiGcjlVoelCivAJVra8t6dZs14j7DXe0jO+tpaS1g6GB0QtnAzcKnR6lEG0NHYH
Q9yyw/pw1T2UaYTjx9u6ZyJlzxVWMD8lSs0cazdBM1rPWK6BPY4fRkMxkw5iLCzl
86OutJM3tL7UqbjvFdXYjjubbAGBfjAvrScXev8HMy4rkuWHGNWTyyoKx4qMHXQG
fgaJxhdDoZ9QtLhFR881x4E6ZrK6X4mgCRw6nROrKR4wQVQE4D9Ghgc7es+MdHho
LYHKPGGpXtebWd4Od3NjeaBP6uujaPZIPvyizwSlyzGb38HUmX59pbgV/8npFTV+
Lj9lRRFQmHoeyfgMEbx/pj0WuQ2gsYMdXtocKbeEzaIJV5loUyqYUvQjFueZA8qg
L8Whj/Wi5UD0ATQE8PksqwXfFvQAMiyena4TRBETVLHRi/mSH9C3TASQv8ZtXGdB
sEhnHSQdk/1aFB7EyJzoNeNmORhTIcAdLZzXfvIJhBAGKWKiFReXeaa1gK5xxquM
QvkbsdkcSApYeJ8a7Wmk
=8eeV
-----END PGP SIGNATURE-----

--Apple-Mail=_A62C12DF-5DDC-47F8-963A-1B9029EF55CE--


From nobody Tue Jun 17 06:45:50 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70C551A0386 for ; Tue, 17 Jun 2014 06:45:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.952
X-Spam-Level: 
X-Spam-Status: No, score=-8.952 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_15=0.6, J_CHICKENPOX_62=0.6, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cc9psWuNxQZY for ; Tue, 17 Jun 2014 06:45:42 -0700 (PDT)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5B241A013B for ; Tue, 17 Jun 2014 06:45:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5563; q=dns/txt; s=iport; t=1403012741; x=1404222341; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=7KqHnINQXqlJ+lTlY7HfX9QlnlEpJImIhuwb+TXvbvo=; b=YXBzdMsR9bk9PmmSaQfYA33KKe1tVONSH23MxLRZt5JCZqRyl05biDic 5p4MrO+wCYSAr1K4j2GohkZo065xb0G8HeS0Ff7Ah6Pq30PS5xTBSIPh5 kzjuoVn2CbeHKkuJtFiHmw7BONkFme9MfH48gpiTSZh1hgIeThkQQV3fb Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AigGALdFoFOtJssW/2dsb2JhbABag1+qWQEBAQEBAQUBmSYBgSN1hAMBAQEEMgEFQBELGAkWDwkDAgECAUUGAQwIAQEQiC4NzA0XhWOIO1+EQwEDljSED4FDhTeMXoNCOy+BAg
X-IronPort-AV: E=Sophos;i="5.01,494,1400025600"; d="scan'208";a="89296605"
Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP; 17 Jun 2014 13:45:39 +0000
Received: from [10.149.0.180] (dhcp-10-149-0-180.cisco.com [10.149.0.180]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s5HDjdqj028615; Tue, 17 Jun 2014 13:45:39 GMT
Message-ID: <53A04683.3040308@cisco.com>
Date: Tue, 17 Jun 2014 15:45:39 +0200
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: NETMOD Working Group , draft-ietf-netmod-snmp-cfg@tools.ietf.org
References: <538D7EF7.4030202@cisco.com> <538DF48C.6030605@cisco.com> <20140607070213.GA21144@elstar.local>
In-Reply-To: <20140607070213.GA21144@elstar.local>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/K3BDkm675-Ob0xCshZtrjkk7wWo
Subject: Re: [netmod] AD review: draft-ietf-netmod-snmp-cfg-05
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 17 Jun 2014 13:45:46 -0000

Jüergen,

Sorry for the delay in getting back to you.
> On Tue, Jun 03, 2014 at 06:15:08PM +0200, Benoit Claise wrote:
>> Dear all,
>>
>> This is my AD review.
>> Good work on a complete YANG model. It depends heavily on the knowledge
>> of the different SNMP MIB modules: SNMP-TARGET-MIB,
>> SNMP-NOTIFICATION-MIB, SNMP-PROXY-MIB, SNMP-COMMUNITY-MIB, etc. This is
>> good as there is no specification redefinition. And I'm glad to find the
>> examples in the appendix for the operators wanted "standard" SNMP
>> configurations.
>>
>> My feedback:
>> -
>>
>>     The configuration data model in particular_targets_SNMP deployments
>>     where SNMP runs in read-only mode and NETCONF is used to configure
>>     the SNMP agent.  Nevertheless, the data model has been_designed_to
>>     allow implementations that support write access both via SNMP and
>>     NETCONF in order to interwork with SNMP-managed management
>>     applications manipulating SNMP agent configuration using SNMP.
>>
>>     The YANG data model focuses on configuration.
>>
>> I don't understand what you mean by "targets" or "designed to"
>> So you made some tradeoffs in the design? Is this the way we should
>> understand this?
>> If which one?
> I think "in particular targets" should be read as in "will likely be
> primarily used in". Or to say it in other words: If a deployment uses
> SNMP to configure SNMP agents, then this data model may be of limited
> value.
I didn't read this way the first time. Maybe it's only me...
>
> Concerning "designed to": The data model has been designed to cover
> everything that the SNMP configuration models describe. It allows an
> implementation that supports both configuration via NETCONF and
> configuration via SNMP. The details are discussed in section 3.2.
I didn't read this way the first time. Your new wording makes it clearer 
to me.
Again, maybe it's just me...
>
>> - At the beginning of VACM and SNMP, we faced one issue. Someone with a
>> read-only community string could query the read-write community string.
>>
>>
>> Router#sh run | i snmp
>>
>> snmp-server engineID local 000000090200009092827820
>>
>> snmp-server group v1group v1 read includeeverything
>>
>> snmp-server view includeeverything internet included
>>
>> snmp-server community _claise _RW
>>
>> snmp-server user _public _v1group v1
>>
>> ...
>>
>> "snmpwalk -v 1  _public _internet.6.3.16 | grep _claise_"... you
>> would be surprised
>>
>> Basically, the trick is that we need a default view on VACM.
>> I see http://tools.ietf.org/html/rfc3415#section-7.4
>> Do we need something specific in this draft to stress that issue?
> I do not think that this document is the place to discuss how default
> VACM rules should look like. This should go into a separate document
> because this is not specific to the YANG data model but rather
> specific to VACM.
Yes, this is specific to VACM, but having an extra document just for 
this might be an overkill.
Adding one sentence in the Security Considerations would be make IMO.
>
>> Editorial:
>>
>> -
>>
>> One small alignment issue below: see the port line
>>
>>      +--rw snmp
>>           +--rw engine
>>              +--rw enabled?               boolean
>>              +--rw listen* [name]
>>              |  +--rw name    snmp:identifier
>>              |  +--rw (transport)
>>              |     +--:(udp)
>>              |        +--rw udp
>>              |           +--rw ip      inet:ip-address
>>             |           +--rw port?   inet:port-number
>>              +--rw version
>>              |  +--rw v1?    empty
>>              |  +--rw v2c?   empty
>>              |  +--rw v3?    empty
>>              +--rw engine-id?             snmp:engine-id
>>              +--rw enable-authen-traps?   boolean
>   
> fixed
>   
>> -
>>
>>     The "/snmp/engine/version" container can be used to enable/disable
>>     the different message processing models.
>>
>> "message processing models": that's a specific SNMP term, well not well
>> known to SNMP users.
>> I would add a reference to RFC 3412
>>
>> -
>> Similarly to
>>     This submodule defines the feature "tsm".  A server implements this
>>     feature if it supports the Transport Security Model (tsm) [RFC5591
>>     ].
>>
> OK. Although I think this should be a reference to RFC 3411 since RFC
> 3411 defines the components (called models in SNMP speak) and RFC 3412
> is just one specific instance.
Sure.
>
>>       augment /snmp:snmp/snmp:target {
>>         when "snmp:v1 or snmp:v2c";
>>         leaf mms {
>>           type union {
>>             type enumeration {
>>               enum "unknown" { value 0; }
>>             }
>>             type int32 {
>>               range "484..max";
>>             }
>>           }
>>           default "484";
>>           reference
>>             "SNMP-COMMUNITY-MIB.snmpTargetAddrMMS";
>>         }
>>       }
>>
>>
>> mms: I thought it was a mistake: nms versus mms.
>> I had to lookup snmpTargetAddrMMS to understand "maximum packet size"
>> Proposal: either add a description or have a better name
> I prefer to keep the name since the SNMPv3 specifications use
> this name. I added a description clause (and I surprised that
> a leaf without a description clause slipped through).
A description makes sense.
>
> Do you want us to post a new revision?
Yes please.

Regards, Benoit
>
> /js
>


From nobody Tue Jun 17 06:50:10 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 170DF1A0390 for ; Tue, 17 Jun 2014 06:50:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.152
X-Spam-Level: 
X-Spam-Status: No, score=-10.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B1b1ttbSZET5 for ; Tue, 17 Jun 2014 06:50:04 -0700 (PDT)
Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7172F1A0387 for ; Tue, 17 Jun 2014 06:50:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1982; q=dns/txt; s=iport; t=1403013000; x=1404222600; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=XAHI4zSYLRCq7kiLFL3XHcA82RLx1JUBeG6qHWb5G70=; b=hlXc9NcKjadakRzmXxcL+P0qWV1FeGrrX0PgnHWFTAtNSwswampIhMuq Ms4tbqZI7b9etEY6kWXCZWjIv2luEUiktRAqlrAbBUA9ea8hi5lzc89ds bt9RoPAGmnR1Vspe+gIX7dHEGN4qas3gqImOG1ko7myiDFk7GEPejA9W0 M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AikGAN5GoFOtJssW/2dsb2JhbABahyWnEwEBAQEBAQUBmSYBgSN1hAMBAQEEIxVAARALEAEEAQEDAgUWCwICCQMCAQIBPQgGAQwBBQIBAYg+rWSeNReBKoQ5iRMHgneBTAEDmkOGeoxeg0I7
X-IronPort-AV: E=Sophos;i="5.01,494,1400025600"; d="scan'208";a="84565092"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP; 17 Jun 2014 13:49:58 +0000
Received: from [10.149.0.180] (dhcp-10-149-0-180.cisco.com [10.149.0.180]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s5HDnwlG021627; Tue, 17 Jun 2014 13:49:58 GMT
Message-ID: <53A04786.8060902@cisco.com>
Date: Tue, 17 Jun 2014 15:49:58 +0200
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Randy Presuhn , Juergen Schoenwaelder 
References: <14507864.1402339265349.JavaMail.root@mswamui-cedar.atl.sa.earthlink.net>
In-Reply-To: <14507864.1402339265349.JavaMail.root@mswamui-cedar.atl.sa.earthlink.net>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/k-p-BCErUjvaKXRFURiu4vqpPoo
Cc: draft-ietf-netmod-snmp-cfg@tools.ietf.org, NETMOD Working Group 
Subject: Re: [netmod] AD review: draft-ietf-netmod-snmp-cfg-05
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 17 Jun 2014 13:50:09 -0000

Dear authors, document shepherd,

Should Randy's point be discussed in this document?

Regards, Benoit
> Hi -
>
>> From: Juergen Schoenwaelder 
>> Sent: Jun 7, 2014 12:02 AM
>> To: Benoit Claise 
>> Cc: draft-ietf-netmod-snmp-cfg@tools.ietf.org, NETMOD Working Group 
>> Subject: Re: [netmod] AD review: draft-ietf-netmod-snmp-cfg-05
> ...
>> Concerning "designed to": The data model has been designed to cover
>> everything that the SNMP configuration models describe. It allows an
>> implementation that supports both configuration via NETCONF and
>> configuration via SNMP. The details are discussed in section 3.2.
> When SNMP is used to change the value of an
> instance of vacmGroupName in the vacmSecurityToGroupTable,
> some side-effects will need to happen in the netconf datastores,
> due to the decision to model the information differently.
> I know this has come up before, but it's unclear to me what
> needs to happen on the netconf server side in a couple
> of specific cases:
>
> (1) If the vacmGroupName has a value that hasn't been seen before,
> a "group" obviously needs to be created as a side-effect in
> netconf land.  What's less obvious is what happens to the
> old "group" in the case where no other entries in the
> vacmSecurityToGroupTable still have that particular value
> for vacmGroupName.  Is it to be automagically deleted
> because the security-model's min-elements constrainted
> would otherwise be violated?
>
> (2) Likewise, when the value of the StorageType of an entry
> in vacmSecurityToGroupTable is modified from nonVolatile
> to volatile, does similar "garbage collection" have
> to happen as a side-effect?
>
> (3) When the entry in vacmSecurityToGroupTable is volatile,
> and some (but not all) of the corresponding vacmAccessTable
> entries are nonVolatile, what happens in the netconf datastores?
>
> Randy
> .
>


From nobody Tue Jun 17 08:23:24 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 166241A0066 for ; Tue, 17 Jun 2014 08:23:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.553
X-Spam-Level: 
X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WKqcZ5f26_GV for ; Tue, 17 Jun 2014 08:23:18 -0700 (PDT)
Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 361751A0061 for ; Tue, 17 Jun 2014 08:23:17 -0700 (PDT)
Received: from [192.168.1.110] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id 662C727E77C1 for ; Tue, 17 Jun 2014 11:23:17 -0400 (EDT)
From: "Thomas D. Nadeau" 
Content-Type: multipart/signed; boundary="Apple-Mail=_22CD75B7-E4A1-4F79-A0D7-613F8841921F"; protocol="application/pgp-signature"; micalg=pgp-sha512
Message-Id: 
Date: Tue, 17 Jun 2014 11:23:16 -0400
To: netmod@ietf.org
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
X-Mailer: Apple Mail (2.1878.2)
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/bZSgITjps7zWOHXf5gJ6BAMHPGo
Subject: [netmod]  Agenda Slot Requests for NETMOD IETF 90 Toronto
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 17 Jun 2014 15:23:23 -0000

--Apple-Mail=_22CD75B7-E4A1-4F79-A0D7-613F8841921F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii


	This was directed to the NETMOD WG. Apologies. *)

	--Tom


	EMAN WG,

	If you would like to request a time-slot for the WG session at =
IETF 90-Toronto, please reply to us by Friday 07/04/2014 along with the =
following information:

	1) Draft title
	2) Presenter name
	3) Requested duration

	Please, make sure that the subject of you reply is for ease of =
tracking: Re:[eman] Agenda 	Slot Requests for EMAN IETF 90 Toronto

	Requests for slots must have had the drafts discussed on the =
mailing list a priori.=20

	The cutoff date for all draft submissions is:

	2014-07-04 (Friday): Internet Draft submission cut-off (for all =
drafts, including -00) by UTC 23:5, upload using IETF ID Submission =
Tool.


	Thanks,

	Tom and Juergen=20

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

--Apple-Mail=_22CD75B7-E4A1-4F79-A0D7-613F8841921F
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJToF1lAAoJEPcO+I7eiUJZ564QAImzdJaxIFL/qoT0WKfH6wpx
7cfMGbHf33CeTSTNDnwDDsehzwno/WEbh/5BAGLbaZM+GU6igE6zA1ZltTO+MqfY
eoohd5NnCzxqroCb5wEWl2/e1P4FLEjZCR/JPUi7NttG7IDXdG2QJCgb0gjAbheN
mzSbdAZS0jt0Gzzq54FqaSaROL84krcb6pfbL8RTA9lrPyH1JlPLhJKGEHWy5j/3
+M9oEP/gSqKI4ZZ7yjFCf34lVeSP5dsYCZ26bVL3FtkyXGs4ZB136/quhSg2eYsB
/+B8FmpSL8u8Wb6rUwu2PUd4l7ZuQl2+pN2MwJPABUqwlTIPV/wiMeNGSLS2PC2w
trYsEGw96A+q4yuk13dS+LbSBVjmTgLIEEBuKJRV5ZwHmaUrsgSfJcNVr7MJT7np
CGqdcHrZTRHTn4wrOFsNHRsFU/+Eo9QG2JsSoKvnkyY1Pf2diV+Ftxm9Sb/g8YrX
WwES7mrl2Fcs0I0VVBAxDg5s8G3kVG01ki9Dq45pCxQl9CQERSV839HN8deA1vv+
/VrpRhkEu41g+k9BAP10DbhSMCTIUcIcwk5kQJQv0TJ5DhV4lEeGmM2ox1TSfvRq
DXuVkAvDCvHtgIBsjNO5BABjiFf+Sxm0J6lfKRnenCiRSLDmcJFtePEjNBqf3GNX
K2LmDnnenGkUzlysbR15
=2kd6
-----END PGP SIGNATURE-----

--Apple-Mail=_22CD75B7-E4A1-4F79-A0D7-613F8841921F--


From nobody Tue Jun 17 08:25:49 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0533B1A0061 for ; Tue, 17 Jun 2014 08:25:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u3ytaB0nxkOB for ; Tue, 17 Jun 2014 08:25:43 -0700 (PDT)
Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1lp0017.outbound.protection.outlook.com [213.199.154.17]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 275081A0087 for ; Tue, 17 Jun 2014 08:25:43 -0700 (PDT)
Received: from DBXPRD0610HT005.eurprd06.prod.outlook.com (157.56.252.181) by AMSPR07MB050.eurprd07.prod.outlook.com (10.242.81.24) with Microsoft SMTP Server (TLS) id 15.0.969.15; Tue, 17 Jun 2014 15:25:41 +0000
Message-ID: <00e601cf8a3f$f3f7a6a0$4001a8c0@gateway.2wire.net>
From: t.petch 
To: 
References: <20140617122005.10875.42631.idtracker@ietfa.amsl.com>
Date: Tue, 17 Jun 2014 16:21:52 +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.181]
X-ClientProxiedBy: DB3PR07CA001.eurprd07.prod.outlook.com (10.242.134.41) To AMSPR07MB050.eurprd07.prod.outlook.com (10.242.81.24)
X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:
X-Forefront-PRVS: 0245702D7B
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(6009001)(428001)(377424004)(13464003)(199002)(189002)(377454003)(51704005)(81342001)(92726001)(92566001)(77156001)(44716002)(79102001)(62236002)(76176999)(83322001)(19580405001)(50986999)(19580395003)(50466002)(93916002)(86362001)(81542001)(95666004)(33646001)(76482001)(74502001)(47776003)(62966002)(14496001)(46102001)(77982001)(23756003)(20776003)(64706001)(66066001)(80022001)(61296003)(31966008)(74662001)(77096002)(101416001)(15975445006)(21056001)(84392001)(105586001)(42186005)(87286001)(99396002)(89996001)(104166001)(87976001)(88136002)(102836001)(83072002)(15202345003)(85852003)(85306003)(44736004)(50226001)(4396001)(81816999)(81686999)(74416001)(7726001); DIR:OUT; SFP:; SCL:1; SRVR:AMSPR07MB050; H:DBXPRD0610HT005.eurprd06.prod.outlook.com; FPR:; MLV:nov; PTR:InfoNoRecords;  A:0; MX:1; LANG:en; 
Received-SPF: None (: btconnect.com does not designate permitted sender hosts)
Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; 
X-OriginatorOrg: btconnect.com
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/14uhS9o-rq_Fer-9BMoJWmPwngg
Cc: netmod@ietf.org
Subject: Re: [netmod] I-D Action: draft-litkowski-netmod-isis-cfg-00.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 17 Jun 2014 15:25:48 -0000

Good to see.

My initial reaction is one to the choice of names and 'uses'.

The more 'uses' there are, the harder it is for me to understand what
the model is, unless and until I know them off by heart - which probably
will not happen for a protocol-specific model.

And e.g. to call the operational state tree 'op' when the other models
use '-state' again hampers my comprehension, as does the use of things
like 'interface-cfg'.  I do like it when you include '-isis-' in object
names and would favour some more of that.  I know, with YANG you can
have the same object name in a thousand different places in different
branches of the schema tree, but that does not mean it is a good idea:-(


Tom Petch

----- Original Message -----
From: 
To: 
Sent: Tuesday, June 17, 2014 1:20 PM
Subject: I-D Action: draft-litkowski-netmod-isis-cfg-00.txt


>
> A New Internet-Draft is available from the on-line Internet-Drafts
directories.
>
>
>         Title           : Yang Data Model for ISIS protocol
>         Author          : Stephane Litkowski
> Filename        : draft-litkowski-netmod-isis-cfg-00.txt
> Pages           : 22
> Date            : 2014-06-17
>
> Abstract:
>    This document defines a YANG data model that can be used to
configure
>    and manage ISIS protocol.
>
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-litkowski-netmod-isis-cfg/
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-litkowski-netmod-isis-cfg-00
>
>
> Please note that it may take a couple of minutes from the time of
submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> I-D-Announce mailing list
> I-D-Announce@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


From nobody Tue Jun 17 09:19:07 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAC131A0043 for ; Tue, 17 Jun 2014 09:19:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.302
X-Spam-Level: 
X-Spam-Status: No, score=-1.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RP_MATCHES_RCVD=-0.651] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K8V-d5yD5IqD for ; Tue, 17 Jun 2014 09:19:05 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D43171A0027 for ; Tue, 17 Jun 2014 09:19:04 -0700 (PDT)
Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 74B9114017A for ; Tue, 17 Jun 2014 18:19:03 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1403021943; bh=sbMPSC9W78gcd+inP7kx38EUYwx1XUhETWbaXmFrMm4=; h=From:Content-Type:Content-Transfer-Encoding:Subject:Date: References:To:Message-Id:Mime-Version; b=LNvG4k+byqJikP+Z6+tq6i0nodz6UdgvdzMuQ27WXo3/ry/BvLOfcPEoSWs6xM0z1 N8TyLNNqWIv1f+9p9TMrgoPIIGr0XoGcj6J6t6D6ajEFdLPgavgznM138VPe/RRnn0 YmmOu8UEGxyVrA0VtkFyBcKmmy5a58ypTRgvhAL4=
From: Ladislav Lhotka 
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Date: Tue, 17 Jun 2014 18:19:02 +0200
References: <9D8A1B46-C3AB-4592-810A-2636320697AD@nic.cz>
To: NETMOD Working Group 
Message-Id: 
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
X-Mailer: Apple Mail (2.1878.2)
X-Virus-Scanned: clamav-milter 0.98.1 at mail
X-Virus-Status: Clean
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/okDGEcrlDCFwxwwWvrSZV9MdgjI
Subject: [netmod] Fwd: [Isis-wg] FW: New Version Notification for draft-litkowski-netmod-isis-cfg-00.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 17 Jun 2014 16:19:06 -0000

FYI, I didn=92t want to cross-post my reply.

Lada

Begin forwarded message:

> From: Ladislav Lhotka 
> Subject: Re: [Isis-wg] FW: New Version Notification for =
draft-litkowski-netmod-isis-cfg-00.txt
> Date: 17 Jun 2014 18:14:02 GMT+2
> To: stephane.litkowski@orange.com
> Cc: "isis-wg@ietf.org list \(isis-wg@ietf.org\)" 
>=20
> Hi Stephane,
>=20
> I am really pleased to see this I-D and the YANG module. I think =
though this work belongs to the ISIS WG where the exposure to routing =
experts=92 eyes will likely be much higher than in NETMOD. That said, =
I=92d be interested in helping you with further development of this =
module.
>=20
> Thanks, Lada
>=20
> On 17 Jun 2014, at 16:41,  =
 wrote:
>=20
>> Hi folks,
>>=20
>> FYI and comments ...
>>=20
>> Here is an initial draft proposal for a YANG model for ISIS.
>>=20
>>=20
>> Best Regards,
>>=20
>> Stephane
>>=20
>> -----Original Message-----
>> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]=20
>> Sent: Tuesday, June 17, 2014 14:20
>> To: LITKOWSKI Stephane SCE/IBNF; LITKOWSKI Stephane SCE/IBNF
>> Subject: New Version Notification for =
draft-litkowski-netmod-isis-cfg-00.txt
>>=20
>>=20
>> A new version of I-D, draft-litkowski-netmod-isis-cfg-00.txt
>> has been successfully submitted by Stephane Litkowski and posted to =
the IETF repository.
>>=20
>> Name:		draft-litkowski-netmod-isis-cfg
>> Revision:	00
>> Title:		Yang Data Model for ISIS protocol
>> Document date:	2014-06-17
>> Group:		Individual Submission
>> Pages:		22
>> URL:            =
http://www.ietf.org/internet-drafts/draft-litkowski-netmod-isis-cfg-00.txt=

>> Status:         =
https://datatracker.ietf.org/doc/draft-litkowski-netmod-isis-cfg/
>> Htmlized:       =
http://tools.ietf.org/html/draft-litkowski-netmod-isis-cfg-00
>>=20
>>=20
>> Abstract:
>>  This document defines a YANG data model that can be used to =
configure
>>  and manage ISIS protocol.
>>=20
>>=20
>>=20
>>=20
>>=20
>> Please note that it may take a couple of minutes from the time of =
submission until the htmlized version and diff are available at =
tools.ietf.org.
>>=20
>> The IETF Secretariat
>>=20
>>=20
>> =
__________________________________________________________________________=
_______________________________________________
>>=20
>> Ce message et ses pieces jointes peuvent contenir des informations =
confidentielles ou privilegiees et ne doivent donc
>> pas etre diffuses, exploites ou copies sans autorisation. Si vous =
avez recu ce message par erreur, veuillez le signaler
>> a l'expediteur et le detruire ainsi que les pieces jointes. Les =
messages electroniques etant susceptibles d'alteration,
>> Orange decline toute responsabilite si ce message a ete altere, =
deforme ou falsifie. Merci.
>>=20
>> This message and its attachments may contain confidential or =
privileged information that may be protected by law;
>> they should not be distributed, used or copied without authorisation.
>> If you have received this email in error, please notify the sender =
and delete this message and its attachments.
>> As emails may be altered, Orange is not liable for messages that have =
been modified, changed or falsified.
>> Thank you.
>>=20
>> _______________________________________________
>> Isis-wg mailing list
>> Isis-wg@ietf.org
>> https://www.ietf.org/mailman/listinfo/isis-wg
>=20
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>=20
>=20
>=20
>=20
> _______________________________________________
> Isis-wg mailing list
> Isis-wg@ietf.org
> https://www.ietf.org/mailman/listinfo/isis-wg

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





From nobody Tue Jun 17 09:32:12 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C605B1A0086 for ; Tue, 17 Jun 2014 09:32:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.702
X-Spam-Level: 
X-Spam-Status: No, score=-0.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, J_CHICKENPOX_15=0.6, RP_MATCHES_RCVD=-0.651] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id edH2l3_I9_XZ for ; Tue, 17 Jun 2014 09:32:09 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69D9B1A0027 for ; Tue, 17 Jun 2014 09:32:09 -0700 (PDT)
Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 399D614017A; Tue, 17 Jun 2014 18:32:07 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1403022727; bh=PHWm+7e9hTEHV2SnKuWcsGGX+0FuT/EeIHn/O2Xrozw=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=wAktpsx/Zpmsk43VJ8T87vxa6PJnxmGztpqAKBkYuPhe4yE3WEzwJs2qYG8V+0H2w FtkIh+nSICfnVKjJsoMr2UP81OgRPciS1HK9RRCK5DGaoD0FFsLGv8CqYhd6yV9/NQ 0XJ1inowEQ2qdnroJSNkcxtK0BkzenoXqAahhWgM=
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
Content-Type: text/plain; charset=windows-1252
From: Ladislav Lhotka 
X-Priority: 3
In-Reply-To: <00e601cf8a3f$f3f7a6a0$4001a8c0@gateway.2wire.net>
Date: Tue, 17 Jun 2014 18:32:06 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <20140617122005.10875.42631.idtracker@ietfa.amsl.com> <00e601cf8a3f$f3f7a6a0$4001a8c0@gateway.2wire.net>
To: "t.petch" 
X-Mailer: Apple Mail (2.1878.2)
X-Virus-Scanned: clamav-milter 0.98.1 at mail
X-Virus-Status: Clean
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/BJGP5ARRrpvuXFwf_k4ABQZAsBw
Cc: netmod@ietf.org
Subject: Re: [netmod] I-D Action: draft-litkowski-netmod-isis-cfg-00.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 17 Jun 2014 16:32:11 -0000

On 17 Jun 2014, at 17:21, t.petch  wrote:

> Good to see.

Absolutely.

>=20
> My initial reaction is one to the choice of names and 'uses'.
>=20
> The more 'uses' there are, the harder it is for me to understand what
> the model is, unless and until I know them off by heart - which =
probably
> will not happen for a protocol-specific model.

Personally, I also prefer to use groupings only for node collections =
that are reused/reusable in multiple places. On the other hand, the =
IPFIX/PSAMP data model in RFC 6728 also uses lots of groupings but there =
it=92s much more comprehensible because the groupings follow a uniform =
logic and are also nicely connected to the diagrams.=20

>=20
> And e.g. to call the operational state tree 'op' when the other models
> use '-state' again hampers my comprehension, as does the use of things
> like 'interface-cfg'.  I do like it when you include '-isis-' in =
object
> names and would favour some more of that.  I know, with YANG you can
> have the same object name in a thousand different places in different
> branches of the schema tree, but that does not mean it is a good =
idea:-(

I think this should be judged carefully on a case-by-case basis.

Lada

>=20
>=20
> Tom Petch
>=20
> ----- Original Message -----
> From: 
> To: 
> Sent: Tuesday, June 17, 2014 1:20 PM
> Subject: I-D Action: draft-litkowski-netmod-isis-cfg-00.txt
>=20
>=20
>>=20
>> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>>=20
>>=20
>>        Title           : Yang Data Model for ISIS protocol
>>        Author          : Stephane Litkowski
>> Filename        : draft-litkowski-netmod-isis-cfg-00.txt
>> Pages           : 22
>> Date            : 2014-06-17
>>=20
>> Abstract:
>>   This document defines a YANG data model that can be used to
> configure
>>   and manage ISIS protocol.
>>=20
>>=20
>>=20
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-litkowski-netmod-isis-cfg/
>>=20
>> There's also a htmlized version available at:
>> http://tools.ietf.org/html/draft-litkowski-netmod-isis-cfg-00
>>=20
>>=20
>> Please note that it may take a couple of minutes from the time of
> submission
>> until the htmlized version and diff are available at tools.ietf.org.
>>=20
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>=20
>> _______________________________________________
>> I-D-Announce mailing list
>> I-D-Announce@ietf.org
>> https://www.ietf.org/mailman/listinfo/i-d-announce
>> Internet-Draft directories: http://www.ietf.org/shadow.html
>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>=20
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

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





From nobody Tue Jun 17 15:21:44 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FCD31A0191 for ; Tue, 17 Jun 2014 15:21:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.151
X-Spam-Level: 
X-Spam-Status: No, score=-15.151 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4hpxd5Bx9kkp for ; Tue, 17 Jun 2014 15:21:39 -0700 (PDT)
Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CA8C1A017F for ; Tue, 17 Jun 2014 15:21:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13690; q=dns/txt; s=iport; t=1403043699; x=1404253299; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=GYbhIS3T3y4jmeaGeAt59uDLERI1UmS5XtmE9Gllmek=; b=JZKGbzlmwZVaBhkNi/2M39hGqBqsiRr9FOBN15UdjLua3I61Mn/Q/O+8 GmdFSM/g1xtdU4eraXj2z8OtLpJNrrmd1cQZzBq/+hg0yY9EyAFvNlaf1 q1wwfbarhzGyn/zO3IudBU3nb/zjDsIPFzkWpHQ20OOrh0eEwl3LLIHWy w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhAHAGm+oFOtJA2E/2dsb2JhbABagkZHgSyqBwEBAQEBAQUBgleWTwGBEBZ1hAMBAgSBCwEIFQIoORQJCAIEARKILgMRyn8XhWOGcIIqAoRBBIVekFaCF4F4jViGAINAgjA
X-IronPort-AV: E=Sophos; i="5.01,497,1400025600"; d="scan'208,217"; a="53886668"
Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-4.cisco.com with ESMTP; 17 Jun 2014 22:21:38 +0000
Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id s5HMLcpn019345 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 17 Jun 2014 22:21:38 GMT
Received: from xmb-aln-x03.cisco.com ([169.254.6.12]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.03.0123.003; Tue, 17 Jun 2014 17:21:37 -0500
From: "Lisa Huang (yihuan)" 
To: YuekunLi , "netmod@ietf.org" 
Thread-Topic: [netmod]  Discussion on draft-huang-netmod-acl-03
Thread-Index: AQHPinqBy2krKiaj1E22xLoHavPx7w==
Date: Tue, 17 Jun 2014 22:21:37 +0000
Message-ID: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.2.3.120616
x-originating-ip: [10.154.204.117]
Content-Type: multipart/alternative; boundary="_000_CFC601ED16EA2yihuanciscocom_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/rMx5ragpvXTWZmvO41B3axFFPnk
Subject: Re: [netmod] Discussion on draft-huang-netmod-acl-03
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 17 Jun 2014 22:21:42 -0000

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

Yuekun,

Thank you for the comments. Responded in line. Thanks,

Lisa

From: YuekunLi >
To: "netmod@ietf.org" >
Subject: [netmod] Discussion on draft-huang-netmod-acl-03


Hi Lisa/Alex/Andy,

I went through 'draft-huang-netmod-acl-03' and had a few points that I woul=
d like to discuss with you guys.

1. I have some concern on the name of the feature we're modeling here.
   'Stateless Packet Filter' is accurate to describe this feature.
   However, none of the major vendors in the industry named their features =
as such.
   Aligning with some major vendors would be appropriate since we're settin=
g a standard.
   From this perspective, I would suggest using 'Access Control List (ACL)'=
.

 It was one of the WG discussion conclusion to use 'Stateless Packet =
Filter'. The reason was the people thought that Access Control was too rest=
rictive in application domain, and really what was specified are stateless =
packet filters of which access control is only one possible application. Pe=
rsonally, I think ACL is a better name and the first version of draft was u=
sing ACL instead of 'Stateless Packet Filter'.

2. The latest revision of this doc briefly mentioned how a SPF (ACL) is app=
lied to a target.
   I can see that section 3.3.4 covers the topic of attaching a SPF (ACL) t=
o an interface.
   In this case, SPF (ACL) is used for traffic filtering.
   There are quite some scenarios, however, SPFs (ACLs) are deployed in oth=
er client applications such as QoS policy and routing protocols (e.g. BGP a=
nd OSPF).
   In most of these cases, SPF (ACL) is used for classification or filterin=
g some routing information.
   Would you consider to initiate a new draft dedicated to topics of applyi=
ng SPF (ACL) to each type of targets?

 ACL is a complex and widely used component. This draft could not cov=
er all ACL implementations, but the design of the module is easy to extend.=
 If there is a need for a new module, it can be created easily by following=
 the same design pattern as SPF-IP or SPF-MAC. The new model can augment, r=
estrict or uses grouping on the existing modules.


3. This document has had a detailed coverage on object-groups (both port ob=
ject-groups and network object-groups).
   Could we consider to put object-groups in a separate module?
   The benefit of this practice is that it's easy for object-groups to be r=
e-used by other modules besides SPF (ACL).
 I will move the object-groups out in a different module in the new v=
ersion of the draft.


4. The packet-capture feature may not be appropriate in SPF (ACL) module.
   This feature actually introduces some new 'actions' to execute after we =
found a match between packet and SPE (ACE).
   These actions (forward and copy) are not purely filtering actions.
   Therefore, they may not fit in the SPF (ACL) module very well.

There is no packet-capture in the ACL module, instead it is just a pa=
cket-capture enabler configuration leaf. Is the name itself made you bring =
the comment? If so, I can rename the packet-capture feature to avoid confus=
ion.


5. In current SPF (ACL) module, each SPE (ACE) is assigned a string as its =
name.
   This may be too expensive in terms of memory consumption.
   Instead, a sequence number for each entry should be sufficient and easy =
to implement.
   Besides, sequence number does give uses the flexibilty to insert an entr=
y to certain position of an existing SPF (ACL).

This is a topic that has been discussed before.  Since not all system=
 are using sequence number, as a standard, it is trying to be generic to co=
ver more cases. If the system only support integer as the key and memory is=
 a concern, the key can be cast before storing.
The ACE list is an order-by-user list. This could let the user control the =
ACE sequence. The existing system uses sequence number to implement order b=
y user feature. Netconf  operation has "insert" attribute whic=
h can take the values "first", "last", "before" and "after" to indicate exa=
ctly where the ACE will go to.


6. Is it better to have a higher level abstraction above SPF (ACL) module?
   By this, I mean creating a separate module that defines some common type=
def/groupings.
   And not container in this module.
   Is this going to be an improvement for the modularity?


In the new draft, I have moved typedef and grouping related object-gr=
oups to a new module. Hope this will help the readability.

Please let me know if there is any confusion on above points.


Thanks

---------------
Yuekun Li

--_000_CFC601ED16EA2yihuanciscocom_
Content-Type: text/html; charset="us-ascii"
Content-ID: <5B5EF02863A424439F8070DEF802C875@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable







Yuekun,







Thank you for the comments. Responded =
in line. Thanks,







Lisa









From: YuekunLi <yuekunli@hotmail.com>

To: "netmod@ietf.org" <=
netmod@ietf.org>

Subject: [netmod] Discussion on dra=
ft-huang-netmod-acl-03













 

Hi Lisa/Alex/Andy,



I went through 'draft-huang-netmod-acl-03' and had a few points that I=
 would like to discuss with you guys.

 

1. I have some concern on the name of the f=
eature we're modeling here.

   'Stateless Packet Filter' is accurate to describe this feature=
.

   However, none of the major vendors in the industry named their=
 features as such.

   Aligning with some major vendors would be appropriate since we=
're setting a standard.

   From this perspective, I would suggest using 'Access Control L=
ist (ACL)'.

 







<Lisa> It was one of the WG discussion conclusion to use 'Statel=
ess Packet Filter'. The reason was the people thought that Access Control w=
as too restrictive in application domain, and really what
 was specified are stateless packet filters of which access control is only=
 one possible application. Personally, I think ACL is a better =
name and the first version of draft was using ACL instead of 'Stateless Pac=
ket Filter'. 









2. The latest revision of this doc briefly =
mentioned how a SPF (ACL) is applied to a target.

   I can see that section 3.3.4 covers the topic of attaching a S=
PF (ACL) to an interface.

   In this case, SPF (ACL) is used for traffic filtering.

   There are quite some scenarios, however, SPFs (ACLs) are deplo=
yed in other client applications such as QoS policy and routing protocols (=
e.g. BGP and OSPF).

   In most of these cases, SPF (ACL) is used for classification o=
r filtering some routing information.

   Would you consider to initiate a new draft dedicated to topics=
 of applying SPF (ACL) to each type of targets?












<Lisa> ACL is a complex and widely used component. This draft co=
uld not cover all ACL implementations, but the design of the module is easy=
 to extend. If there is a need for a new module, it can be created easily b=
y following the same design pattern as
 SPF-IP or SPF-MAC. The new model can augment, restrict or uses grouping on=
 the existing modules.









 

3. This document has had a detailed coverag=
e on object-groups (both port object-groups and network object-groups).

   Could we consider to put object-groups in a separate module?
   The benefit of this practice is that it's easy for object-grou=
ps to be re-used by other modules besides SPF (ACL).







<Lisa> I will move the object-groups out in a different module i=
n the new version of the draft.









 

4. The packet-capture feature may not be ap=
propriate in SPF (ACL) module.

   This feature actually introduces some new 'actions' to execute=
 after we found a match between packet and SPE (ACE).

   These actions (forward and copy) are not purely filtering acti=
ons. 

   Therefore, they may not fit in the SPF (ACL) module very well.=













<Lisa>There is no packet-capture in the ACL module, instead it i=
s just a packet-capture enabler configuration leaf. Is the name itself made=
 you bring the comment? If so, I can rename the packet-capture feature to a=
void confusion.









 

5. In current SPF (ACL) module, each SPE (A=
CE) is assigned a string as its name.

   This may be too expensive in terms of memory consumption.

   Instead, a sequence number for each entry should be sufficient=
 and easy to implement.

   Besides, sequence number does give uses the flexibilty to inse=
rt an entry to certain position of an existing SPF (ACL).












<Lisa>This is a topic that has been discussed before.  Sinc=
e not all system are using sequence number, as a standard, it is trying to =
be generic to cover more cases. If the system only support integer as the k=
ey and memory is a concern, the key can be
 cast before storing.


The ACE list is an order-by-user list. This could let the user control=
 the ACE sequence. The existing system uses sequence number to implement or=
der by user feature. Netconf <edit-config> operation has "insert=
" attribute which can take the values "first",
 "last", "before" and "after" to indicate exa=
ctly where the ACE will go to. 







 







6. Is it better to have a =
higher level abstraction above SPF (ACL) module?

   By this, I mean creating a separate module that defines some c=
ommon typedef/groupings.

   And not container in this module.

   Is this going to be an improvement for the modularity?<=
/div>


















<Lisa>In the new draft, I have moved =
typedef and grouping related object-groups to a new module. Hope this will =
help the readability.

 

Please let me know if there is any confusion on above points.

 

 

Thanks

 

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

Yuekun Li











--_000_CFC601ED16EA2yihuanciscocom_--


From nobody Tue Jun 17 16:28:25 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C40281A01F5; Tue, 17 Jun 2014 16:28:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.853
X-Spam-Level: 
X-Spam-Status: No, score=-104.853 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BVvqVd8rlL_k; Tue, 17 Jun 2014 16:28:19 -0700 (PDT)
Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id C93DB1A01E5; Tue, 17 Jun 2014 16:28:17 -0700 (PDT)
Received: by rfc-editor.org (Postfix, from userid 30) id AD30C1801C2; Tue, 17 Jun 2014 16:27:04 -0700 (PDT)
To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org
X-PHP-Originating-Script: 6000:ams_util_lib.php
From: rfc-editor@rfc-editor.org
Message-Id: <20140617232704.AD30C1801C2@rfc-editor.org>
Date: Tue, 17 Jun 2014 16:27:04 -0700 (PDT)
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/gAsAe_bKMYQB8w1Xv_vkjEq0Y6s
Cc: drafts-update-ref@iana.org, netmod@ietf.org, rfc-editor@rfc-editor.org
Subject: [netmod] RFC 7277 on A YANG Data Model for IP Management
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 17 Jun 2014 23:28:24 -0000

A new Request for Comments is now available in online RFC libraries.

        
        RFC 7277

        Title:      A YANG Data Model for IP Management 
        Author:     M. Bjorklund
        Status:     Standards Track
        Stream:     IETF
        Date:       June 2014
        Mailbox:    mbj@tail-f.com
        Pages:      30
        Characters: 50043
        Updates/Obsoletes/SeeAlso:   None

        I-D Tag:    draft-ietf-netmod-ip-cfg-14.txt

        URL:        http://www.rfc-editor.org/rfc/rfc7277.txt

This document defines a YANG data model for management of IP
implementations.  The data model includes configuration data and
state data.

This document is a product of the NETCONF Data Modeling Language Working Group of the IETF.

This is now a Proposed Standard.

STANDARDS TRACK: This document specifies an Internet standards track
protocol for the Internet community,and requests discussion and suggestions
for improvements.  Please refer to the current edition of the Internet
Official Protocol Standards (STD 1) for the standardization state and
status of this protocol.  Distribution of this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  http://www.ietf.org/mailman/listinfo/ietf-announce
  http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see http://www.rfc-editor.org/search
For downloading RFCs, see http://www.rfc-editor.org/rfc.html

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-editor@rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC



From nobody Wed Jun 18 00:58:27 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68B0A1A00DA for ; Wed, 18 Jun 2014 00:58:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.299
X-Spam-Level: 
X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kpRnIDQSklIa for ; Wed, 18 Jun 2014 00:58:24 -0700 (PDT)
Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9CEC1A00C6 for ; Wed, 18 Jun 2014 00:58:23 -0700 (PDT)
Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda11.si.francetelecom.fr (ESMTP service) with ESMTP id 8E9041B824B; Wed, 18 Jun 2014 09:58:21 +0200 (CEST)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.56]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id 71E03384073; Wed, 18 Jun 2014 09:58:21 +0200 (CEST)
Received: from OPEXCLILM34.corporate.adroot.infra.ftgroup ([169.254.4.50]) by OPEXCLILH04.corporate.adroot.infra.ftgroup ([10.114.31.56]) with mapi id 14.03.0181.006; Wed, 18 Jun 2014 09:58:21 +0200
From: 
To: t.petch 
Thread-Topic: I-D Action: draft-litkowski-netmod-isis-cfg-00.txt
Thread-Index: AQHPiiaGYeZj4MgYr0CKhMuCvSX6c5t1bIHXgAETrUA=
Date: Wed, 18 Jun 2014 07:58:21 +0000
Message-ID: <30514_1403078301_53A1469D_30514_16766_1_9E32478DFA9976438E7A22F69B08FF92021A2F@OPEXCLILM34.corporate.adroot.infra.ftgroup>
References: <20140617122005.10875.42631.idtracker@ietfa.amsl.com> <00e601cf8a3f$f3f7a6a0$4001a8c0@gateway.2wire.net>
In-Reply-To: <00e601cf8a3f$f3f7a6a0$4001a8c0@gateway.2wire.net>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.168.234.5]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.6.18.64220
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/xi_RTbtWVW6_4CkYJgnsSFQPtxc
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] I-D Action: draft-litkowski-netmod-isis-cfg-00.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 18 Jun 2014 07:58:25 -0000

Hi Tom,

Thanks for the feedback ...
It's my first YANG model coding, so sorry for some inconsistencies that I w=
ould be able to be fixed in future version ...

Regarding usage of "uses", I agree with your point that it may sort of comp=
lexify in a way, but in another way, it facilitates updates of the model by=
 putting diffs only in one place (less errors). It may also simplify readin=
g of big containers.

Regarding the "op" vs "state" , I would fix it ... regarding naming of obje=
ct and containers I also agree with you, and I will fix by adding "isis" st=
atement in names.


Stephane
=20

-----Original Message-----
From: t.petch [mailto:ietfc@btconnect.com]=20
Sent: Tuesday, June 17, 2014 17:22
To: LITKOWSKI Stephane SCE/IBNF
Cc: netmod@ietf.org
Subject: Re: I-D Action: draft-litkowski-netmod-isis-cfg-00.txt

Good to see.

My initial reaction is one to the choice of names and 'uses'.

The more 'uses' there are, the harder it is for me to understand what the m=
odel is, unless and until I know them off by heart - which probably will no=
t happen for a protocol-specific model.

And e.g. to call the operational state tree 'op' when the other models use =
'-state' again hampers my comprehension, as does the use of things like 'in=
terface-cfg'.  I do like it when you include '-isis-' in object names and w=
ould favour some more of that.  I know, with YANG you can have the same obj=
ect name in a thousand different places in different branches of the schema=
 tree, but that does not mean it is a good idea:-(


Tom Petch

----- Original Message -----
From: 
To: 
Sent: Tuesday, June 17, 2014 1:20 PM
Subject: I-D Action: draft-litkowski-netmod-isis-cfg-00.txt


>
> A New Internet-Draft is available from the on-line Internet-Drafts
directories.
>
>
>         Title           : Yang Data Model for ISIS protocol
>         Author          : Stephane Litkowski
> Filename        : draft-litkowski-netmod-isis-cfg-00.txt
> Pages           : 22
> Date            : 2014-06-17
>
> Abstract:
>    This document defines a YANG data model that can be used to
configure
>    and manage ISIS protocol.
>
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-litkowski-netmod-isis-cfg/
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-litkowski-netmod-isis-cfg-00
>
>
> Please note that it may take a couple of minutes from the time of
submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> I-D-Announce mailing list
> I-D-Announce@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html or=20
> ftp://ftp.ietf.org/ietf/1shadow-sites.txt


___________________________________________________________________________=
______________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.


From nobody Wed Jun 18 01:03:09 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED6E61A007C for ; Wed, 18 Jun 2014 01:03:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.131
X-Spam-Level: 
X-Spam-Status: No, score=-9.131 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MISSING_HEADERS=1.021, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zgtNbAp-PjiQ for ; Wed, 18 Jun 2014 01:03:05 -0700 (PDT)
Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 593C51A005D for ; Wed, 18 Jun 2014 01:03:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2134; q=dns/txt; s=iport; t=1403078585; x=1404288185; h=message-id:date:from:mime-version:cc:subject:references: in-reply-to:content-transfer-encoding; bh=qq25weG60jrO2wtgVWWSDR/u4NMVKraqPpGLlheqilE=; b=WqgLWOTr3M6ydzXlVm2URAZSL+xAKk5GMQ6vPwmASeCZkd8H9mESSGOD xVCa693xlahzTa91qyYAHu1z/KpMFERo9a4QPH68yUUnRlM4QjQWJw0Qu gHGv/Nv0OZEyvXs8qTkWTReDkTO1wIC1nCNSLNIR53jHxssMNhx71HyYY k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ak8HAI5GoVOtJssW/2dsb2JhbABag1+qLjcBAQEBAQeRaYZsUwElgQF1g3sJAQEEAQEBNRYgCgEQCxQNAxMPCQMCAQIBFQomEwEFAgEBBQsHAgSFVYJMDctEF4VihXSCTFMHgwaBPQEDmkOBQ4U3hmGFfYNEOy+BCw
X-IronPort-AV: E=Sophos;i="5.01,499,1400025600"; d="scan'208";a="85352234"
Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP; 18 Jun 2014 08:03:02 +0000
Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s5I832qm008834 for ; Wed, 18 Jun 2014 08:03:02 GMT
Message-ID: <53A147B6.2040400@cisco.com>
Date: Wed, 18 Jun 2014 10:03:02 +0200
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
CC: netmod@ietf.org
References: <20140617232704.AD30C1801C2@rfc-editor.org>
In-Reply-To: <20140617232704.AD30C1801C2@rfc-editor.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/qeiaK3mTf8vtwTyQVzO7wYGsCOM
Subject: Re: [netmod] RFC 7277 on A YANG Data Model for IP Management
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 18 Jun 2014 08:03:07 -0000

Congrats to the Martin and entire community.

Regards, B.
> A new Request for Comments is now available in online RFC libraries.
>
>          
>          RFC 7277
>
>          Title:      A YANG Data Model for IP Management
>          Author:     M. Bjorklund
>          Status:     Standards Track
>          Stream:     IETF
>          Date:       June 2014
>          Mailbox:    mbj@tail-f.com
>          Pages:      30
>          Characters: 50043
>          Updates/Obsoletes/SeeAlso:   None
>
>          I-D Tag:    draft-ietf-netmod-ip-cfg-14.txt
>
>          URL:        http://www.rfc-editor.org/rfc/rfc7277.txt
>
> This document defines a YANG data model for management of IP
> implementations.  The data model includes configuration data and
> state data.
>
> This document is a product of the NETCONF Data Modeling Language Working Group of the IETF.
>
> This is now a Proposed Standard.
>
> STANDARDS TRACK: This document specifies an Internet standards track
> protocol for the Internet community,and requests discussion and suggestions
> for improvements.  Please refer to the current edition of the Internet
> Official Protocol Standards (STD 1) for the standardization state and
> status of this protocol.  Distribution of this memo is unlimited.
>
> This announcement is sent to the IETF-Announce and rfc-dist lists.
> To subscribe or unsubscribe, see
>    http://www.ietf.org/mailman/listinfo/ietf-announce
>    http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist
>
> For searching the RFC series, see http://www.rfc-editor.org/search
> For downloading RFCs, see http://www.rfc-editor.org/rfc.html
>
> Requests for special distribution should be addressed to either the
> author of the RFC in question, or to rfc-editor@rfc-editor.org.  Unless
> specifically noted otherwise on the RFC itself, all RFCs are for
> unlimited distribution.
>
>
> The RFC Editor Team
> Association Management Solutions, LLC
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
> .
>


From nobody Wed Jun 18 01:11:42 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD7841A005D; Wed, 18 Jun 2014 01:11:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iay4zpG52AFV; Wed, 18 Jun 2014 01:11:26 -0700 (PDT)
Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 497D01A002E; Wed, 18 Jun 2014 01:11:26 -0700 (PDT)
Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id E19302DC1F7; Wed, 18 Jun 2014 10:11:24 +0200 (CEST)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.55]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id BF09A238067; Wed, 18 Jun 2014 10:11:24 +0200 (CEST)
Received: from OPEXCLILM34.corporate.adroot.infra.ftgroup ([169.254.4.50]) by OPEXCLILH03.corporate.adroot.infra.ftgroup ([10.114.31.55]) with mapi id 14.03.0181.006; Wed, 18 Jun 2014 10:11:24 +0200
From: 
To: Ladislav Lhotka 
Thread-Topic: [Isis-wg] FW: New Version Notification for draft-litkowski-netmod-isis-cfg-00.txt
Thread-Index: AQHPiiaBbiuORN4vMkWkQRJKVSRR3Jt1X8Mg///4twCAASue0A==
Date: Wed, 18 Jun 2014 08:11:24 +0000
Message-ID: <15719_1403079084_53A149AC_15719_5687_1_9E32478DFA9976438E7A22F69B08FF92021AC0@OPEXCLILM34.corporate.adroot.infra.ftgroup>
References: <20140617122005.10875.31180.idtracker@ietfa.amsl.com> <24554_1403016065_53A05381_24554_4972_1_9E32478DFA9976438E7A22F69B08FF920215BB@OPEXCLILM34.corporate.adroot.infra.ftgroup> <9D8A1B46-C3AB-4592-810A-2636320697AD@nic.cz>
In-Reply-To: <9D8A1B46-C3AB-4592-810A-2636320697AD@nic.cz>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.168.234.5]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.6.18.34819
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/IMvorfo_-7dYSPtDcrXp2C3UDI8
Cc: "isis-wg@ietf.org list \(isis-wg@ietf.org\)" , "netmod@ietf.org" 
Subject: Re: [netmod] [Isis-wg] FW: New Version Notification for draft-litkowski-netmod-isis-cfg-00.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 18 Jun 2014 08:11:33 -0000

Hi Lada,

For sure ISIS WG need to be involved, for ownership of the draft, I don't r=
eally know which WG need to be "owner". Maybe chairs can provide their feed=
back or we could discuss this point in Toronto.
I'm would like to present this first version in both WG if possible.

I would be happy to welcome any contributions, so if you have any point to =
raise or if you want to co-author by adding some text, don't hesitate.

Thanks,

Stephane


-----Original Message-----
From: Ladislav Lhotka [mailto:lhotka@nic.cz]=20
Sent: Tuesday, June 17, 2014 18:14
To: LITKOWSKI Stephane SCE/IBNF
Cc: isis-wg@ietf.org list (isis-wg@ietf.org)
Subject: Re: [Isis-wg] FW: New Version Notification for draft-litkowski-net=
mod-isis-cfg-00.txt

Hi Stephane,

I am really pleased to see this I-D and the YANG module. I think though thi=
s work belongs to the ISIS WG where the exposure to routing experts' eyes w=
ill likely be much higher than in NETMOD. That said, I'd be interested in h=
elping you with further development of this module.

Thanks, Lada

On 17 Jun 2014, at 16:41,   wrote:

> Hi folks,
>=20
> FYI and comments ...
>=20
> Here is an initial draft proposal for a YANG model for ISIS.
>=20
>=20
> Best Regards,
>=20
> Stephane
>=20
> -----Original Message-----
> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
> Sent: Tuesday, June 17, 2014 14:20
> To: LITKOWSKI Stephane SCE/IBNF; LITKOWSKI Stephane SCE/IBNF
> Subject: New Version Notification for=20
> draft-litkowski-netmod-isis-cfg-00.txt
>=20
>=20
> A new version of I-D, draft-litkowski-netmod-isis-cfg-00.txt
> has been successfully submitted by Stephane Litkowski and posted to the I=
ETF repository.
>=20
> Name:		draft-litkowski-netmod-isis-cfg
> Revision:	00
> Title:		Yang Data Model for ISIS protocol
> Document date:	2014-06-17
> Group:		Individual Submission
> Pages:		22
> URL:            http://www.ietf.org/internet-drafts/draft-litkowski-netmo=
d-isis-cfg-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-litkowski-netmod-i=
sis-cfg/
> Htmlized:       http://tools.ietf.org/html/draft-litkowski-netmod-isis-cf=
g-00
>=20
>=20
> Abstract:
>   This document defines a YANG data model that can be used to configure
>   and manage ISIS protocol.
>=20
>=20
>=20
>=20
>=20
> Please note that it may take a couple of minutes from the time of submiss=
ion until the htmlized version and diff are available at tools.ietf.org.
>=20
> The IETF Secretariat
>=20
>=20
> ______________________________________________________________________
> ___________________________________________________
>=20
> Ce message et ses pieces jointes peuvent contenir des informations=20
> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20
> exploites ou copies sans autorisation. Si vous avez recu ce message=20
> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que =
les pieces jointes. Les messages electroniques etant susceptibles d'alterat=
ion, Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.
>=20
> This message and its attachments may contain confidential or=20
> privileged information that may be protected by law; they should not be d=
istributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and de=
lete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have bee=
n modified, changed or falsified.
> Thank you.
>=20
> _______________________________________________
> Isis-wg mailing list
> Isis-wg@ietf.org
> https://www.ietf.org/mailman/listinfo/isis-wg

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





___________________________________________________________________________=
______________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.


From nobody Wed Jun 18 01:30:23 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3EAD1A008C; Wed, 18 Jun 2014 01:30:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.201
X-Spam-Level: 
X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rFC7gEx0cZoB; Wed, 18 Jun 2014 01:30:19 -0700 (PDT)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FE5D1A008B; Wed, 18 Jun 2014 01:30:19 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 28F27762; Wed, 18 Jun 2014 10:30:17 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id A0X4aqaxuMvs; Wed, 18 Jun 2014 10:30:06 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 18 Jun 2014 10:30:16 +0200 (CEST)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id D90082002C; Wed, 18 Jun 2014 10:30:16 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 9iaYCPbQeN1W; Wed, 18 Jun 2014 10:30:15 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2495320017; Wed, 18 Jun 2014 10:30:15 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id C5C292D9122C; Wed, 18 Jun 2014 10:30:13 +0200 (CEST)
Date: Wed, 18 Jun 2014 10:30:13 +0200
From: Juergen Schoenwaelder 
To: stephane.litkowski@orange.com
Message-ID: <20140618083011.GB6055@elstar.local>
Mail-Followup-To: stephane.litkowski@orange.com, Ladislav Lhotka , "isis-wg@ietf.org list (isis-wg@ietf.org)" , "netmod@ietf.org" 
References: <20140617122005.10875.31180.idtracker@ietfa.amsl.com> <24554_1403016065_53A05381_24554_4972_1_9E32478DFA9976438E7A22F69B08FF920215BB@OPEXCLILM34.corporate.adroot.infra.ftgroup> <9D8A1B46-C3AB-4592-810A-2636320697AD@nic.cz> <15719_1403079084_53A149AC_15719_5687_1_9E32478DFA9976438E7A22F69B08FF92021AC0@OPEXCLILM34.corporate.adroot.infra.ftgroup>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <15719_1403079084_53A149AC_15719_5687_1_9E32478DFA9976438E7A22F69B08FF92021AC0@OPEXCLILM34.corporate.adroot.infra.ftgroup>
User-Agent: Mutt/1.4.2.3i
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/1hS0zKgsRjADRG0J4hIHwWgAkH8
Cc: "netmod@ietf.org" , "isis-wg@ietf.org list \(isis-wg@ietf.org\)" 
Subject: Re: [netmod] [Isis-wg] FW: New Version Notification for draft-litkowski-netmod-isis-cfg-00.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 18 Jun 2014 08:30:22 -0000

On Wed, Jun 18, 2014 at 08:11:24AM +0000, stephane.litkowski@orange.com wrote:
> Hi Lada,
> 
> For sure ISIS WG need to be involved, for ownership of the draft, I don't really know which WG need to be "owner". Maybe chairs can provide their feedback or we could discuss this point in Toronto.
> I'm would like to present this first version in both WG if possible.
> 

As a general principle, I prefer that data models are done in the WGs
that understand what is being modeled. Hence, this work should ideally
be done in the ISIS WG.

Since I am not following the ISIS WG myself, I ended up looking at the
WG charter page in order to get a clue what they are working on and
what I found is that apparently their milestones have not been updated
since 2009 (and the additional page pointed to in the charter,
, does not look more recent
either). So it remains somewhat difficult to judge whether ISIS may be
able to pick up this work.

/js

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


From nobody Wed Jun 18 01:33:19 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72E5D1A0113 for ; Wed, 18 Jun 2014 01:33:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.201
X-Spam-Level: 
X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8d3LOjiCnLTc for ; Wed, 18 Jun 2014 01:33:14 -0700 (PDT)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 247511A008C for ; Wed, 18 Jun 2014 01:33:13 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 82155762 for ; Wed, 18 Jun 2014 10:33:11 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id a8Lkp8meKNN0 for ; Wed, 18 Jun 2014 10:33:00 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Wed, 18 Jun 2014 10:33:10 +0200 (CEST)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 38C712002C for ; Wed, 18 Jun 2014 10:33:11 +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 kLRCLNwKCe4L; Wed, 18 Jun 2014 10:33:10 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 63AD920017; Wed, 18 Jun 2014 10:33:10 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 9CB392D91278; Wed, 18 Jun 2014 10:33:09 +0200 (CEST)
Date: Wed, 18 Jun 2014 10:33:09 +0200
From: Juergen Schoenwaelder 
To: netmod@ietf.org
Message-ID: <20140618083309.GA6153@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.4.2.3i
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/TT9a9C3fqwViDh9H6gLie7-BT5o
Subject: [netmod] no virtual interim meeting on 2014-06-18 (today) and on 2014-06-25
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 18 Jun 2014 08:33:16 -0000

Hi,

as already noted in the minutes of the last virtual interim meeting,
there will be no virtual interim meeting 2014-06-18 (today) and on
2014-06-25 (next week).

/js

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


From nobody Wed Jun 18 01:53:44 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 286B31A008B; Wed, 18 Jun 2014 01:53:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.302
X-Spam-Level: 
X-Spam-Status: No, score=-1.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RP_MATCHES_RCVD=-0.651] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qdB__-iZHIyf; Wed, 18 Jun 2014 01:53:39 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BCCC1A00A9; Wed, 18 Jun 2014 01:53:39 -0700 (PDT)
Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 6220613FE21; Wed, 18 Jun 2014 10:53:37 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1403081617; bh=9nxhuKU3t6qeTiNO8LxSkZORnsqYqb2gXzA3QnKavWQ=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=AIV0+yIJ8waJZRY15zgI/6lQ3SaznCWjT6PoULb/7Ur6mnpaLiIHSDXANGcJ0/mCF r9Grdt9d0xGty5HusM+IsIyFdf1IRDf7iw51/Ogq+sTGG+FqRex73rRotV1oE2YEHN PaDi1o95qIUWtt46/5U5JIVS6QtA1XQ1VEySof6c=
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
From: Ladislav Lhotka 
In-Reply-To: <15719_1403079084_53A149AC_15719_5687_1_9E32478DFA9976438E7A22F69B08FF92021AC0@OPEXCLILM34.corporate.adroot.infra.ftgroup>
Date: Wed, 18 Jun 2014 10:53:37 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <6FA76F99-FA52-438C-AFAE-C21C999A41F0@nic.cz>
References: <20140617122005.10875.31180.idtracker@ietfa.amsl.com> <24554_1403016065_53A05381_24554_4972_1_9E32478DFA9976438E7A22F69B08FF920215BB@OPEXCLILM34.corporate.adroot.infra.ftgroup> <9D8A1B46-C3AB-4592-810A-2636320697AD@nic.cz> <15719_1403079084_53A149AC_15719_5687_1_9E32478DFA9976438E7A22F69B08FF92021AC0@OPEXCLILM34.corporate.adroot.infra.ftgroup>
To: stephane.litkowski@orange.com
X-Mailer: Apple Mail (2.1878.2)
X-Virus-Scanned: clamav-milter 0.98.1 at mail
X-Virus-Status: Clean
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/Y-iP0Vq9lwrZAJrA25XrEj5VAFU
Cc: "isis-wg@ietf.org list \(isis-wg@ietf.org\)" , "netmod@ietf.org" 
Subject: Re: [netmod] [Isis-wg] FW: New Version Notification for draft-litkowski-netmod-isis-cfg-00.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 18 Jun 2014 08:53:41 -0000

On 18 Jun 2014, at 10:11,  =
 wrote:

> Hi Lada,
>=20
> For sure ISIS WG need to be involved, for ownership of the draft, I =
don't really know which WG need to be "owner". Maybe chairs can provide =
their feedback or we could discuss this point in Toronto.

Yes, and I see Juergen has already started this discussion.

> I'm would like to present this first version in both WG if possible.

That=92s fine and welcome, I think.

>=20
> I would be happy to welcome any contributions, so if you have any =
point to raise or if you want to co-author by adding some text, don't =
hesitate.

To start with, I plan a thorough review of the module, mainly from the =
YANG point of view. My first impressions are quite positive though. :-)

Lada

>=20
> Thanks,
>=20
> Stephane
>=20
>=20
> -----Original Message-----
> From: Ladislav Lhotka [mailto:lhotka@nic.cz]=20
> Sent: Tuesday, June 17, 2014 18:14
> To: LITKOWSKI Stephane SCE/IBNF
> Cc: isis-wg@ietf.org list (isis-wg@ietf.org)
> Subject: Re: [Isis-wg] FW: New Version Notification for =
draft-litkowski-netmod-isis-cfg-00.txt
>=20
> Hi Stephane,
>=20
> I am really pleased to see this I-D and the YANG module. I think =
though this work belongs to the ISIS WG where the exposure to routing =
experts' eyes will likely be much higher than in NETMOD. That said, I'd =
be interested in helping you with further development of this module.
>=20
> Thanks, Lada
>=20
> On 17 Jun 2014, at 16:41,  =
 wrote:
>=20
>> Hi folks,
>>=20
>> FYI and comments ...
>>=20
>> Here is an initial draft proposal for a YANG model for ISIS.
>>=20
>>=20
>> Best Regards,
>>=20
>> Stephane
>>=20
>> -----Original Message-----
>> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
>> Sent: Tuesday, June 17, 2014 14:20
>> To: LITKOWSKI Stephane SCE/IBNF; LITKOWSKI Stephane SCE/IBNF
>> Subject: New Version Notification for=20
>> draft-litkowski-netmod-isis-cfg-00.txt
>>=20
>>=20
>> A new version of I-D, draft-litkowski-netmod-isis-cfg-00.txt
>> has been successfully submitted by Stephane Litkowski and posted to =
the IETF repository.
>>=20
>> Name:		draft-litkowski-netmod-isis-cfg
>> Revision:	00
>> Title:		Yang Data Model for ISIS protocol
>> Document date:	2014-06-17
>> Group:		Individual Submission
>> Pages:		22
>> URL:            =
http://www.ietf.org/internet-drafts/draft-litkowski-netmod-isis-cfg-00.txt=

>> Status:         =
https://datatracker.ietf.org/doc/draft-litkowski-netmod-isis-cfg/
>> Htmlized:       =
http://tools.ietf.org/html/draft-litkowski-netmod-isis-cfg-00
>>=20
>>=20
>> Abstract:
>>  This document defines a YANG data model that can be used to =
configure
>>  and manage ISIS protocol.
>>=20
>>=20
>>=20
>>=20
>>=20
>> Please note that it may take a couple of minutes from the time of =
submission until the htmlized version and diff are available at =
tools.ietf.org.
>>=20
>> The IETF Secretariat
>>=20
>>=20
>> =
______________________________________________________________________
>> ___________________________________________________
>>=20
>> Ce message et ses pieces jointes peuvent contenir des informations=20
>> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20=

>> exploites ou copies sans autorisation. Si vous avez recu ce message=20=

>> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi =
que les pieces jointes. Les messages electroniques etant susceptibles =
d'alteration, Orange decline toute responsabilite si ce message a ete =
altere, deforme ou falsifie. Merci.
>>=20
>> This message and its attachments may contain confidential or=20
>> privileged information that may be protected by law; they should not =
be distributed, used or copied without authorisation.
>> If you have received this email in error, please notify the sender =
and delete this message and its attachments.
>> As emails may be altered, Orange is not liable for messages that have =
been modified, changed or falsified.
>> Thank you.
>>=20
>> _______________________________________________
>> Isis-wg mailing list
>> Isis-wg@ietf.org
>> https://www.ietf.org/mailman/listinfo/isis-wg
>=20
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>=20
>=20
>=20
>=20
>=20
> =
__________________________________________________________________________=
_______________________________________________
>=20
> Ce message et ses pieces jointes peuvent contenir des informations =
confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez =
recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les =
messages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, =
deforme ou falsifie. Merci.
>=20
> This message and its attachments may contain confidential or =
privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and =
delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have =
been modified, changed or falsified.
> Thank you.
>=20

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





From nobody Wed Jun 18 07:22:09 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA7AB1A0292 for ; Wed, 18 Jun 2014 07:22:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level: 
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CaA-ZdhNQd91 for ; Wed, 18 Jun 2014 07:22:03 -0700 (PDT)
Received: from mail-qa0-f43.google.com (mail-qa0-f43.google.com [209.85.216.43]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5F981A028A for ; Wed, 18 Jun 2014 07:22:02 -0700 (PDT)
Received: by mail-qa0-f43.google.com with SMTP id k15so756066qaq.30 for ; Wed, 18 Jun 2014 07:22:01 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=MZAqlk/+0F93C+qt/nUmEwPACC1kIQ+EC5JBGUGl6Lg=; b=ZE2sVHa1F1hhRYYnQ0ZiqTaRl244KRxrH+JiZNyhyocDOnvMxbGl3tjOUXrjK79Pg/ JpvF8Nw5o9RkepkeB6Zn2PSHt3eUyUuV5ohcTngGVFub/F6eU6quwZz/7ZGURWEXnYIk 5RhC3R3zh+LpmS5koeJxSRNiQA65r4xqYLxL+3p1Lu1ZgO5hlYIueHME6qle+cwHUsVd qjk9b5rxhlqdwQjl6f/0IbS8zUoGLMTxylwMbSJFwyJ/CsakuTAEHArH9hEN5QjGYaIm oWasDAcISRV6w3QXAi61/mkfsxvpGX/d+ZvJb/2S0sQ+wsoENBg6h7+d4zbgc/EuC5M6 4UbA==
X-Gm-Message-State: ALoCoQlJAitZ2bZnng2TTsdo9aJZApT0LQTrU+RRCi+iqvyOhCCAlaFLzyZoYP9Do7Zfc2N4pki7
MIME-Version: 1.0
X-Received: by 10.140.41.113 with SMTP id y104mr3434586qgy.34.1403101321720; Wed, 18 Jun 2014 07:22:01 -0700 (PDT)
Received: by 10.140.104.48 with HTTP; Wed, 18 Jun 2014 07:22:01 -0700 (PDT)
In-Reply-To: <6FA76F99-FA52-438C-AFAE-C21C999A41F0@nic.cz>
References: <20140617122005.10875.31180.idtracker@ietfa.amsl.com> <24554_1403016065_53A05381_24554_4972_1_9E32478DFA9976438E7A22F69B08FF920215BB@OPEXCLILM34.corporate.adroot.infra.ftgroup> <9D8A1B46-C3AB-4592-810A-2636320697AD@nic.cz> <15719_1403079084_53A149AC_15719_5687_1_9E32478DFA9976438E7A22F69B08FF92021AC0@OPEXCLILM34.corporate.adroot.infra.ftgroup> <6FA76F99-FA52-438C-AFAE-C21C999A41F0@nic.cz>
Date: Wed, 18 Jun 2014 07:22:01 -0700
Message-ID: 
From: Andy Bierman 
To: Ladislav Lhotka 
Content-Type: multipart/alternative; boundary=001a11c121b0dd8c7204fc1cfbda
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/jF1lxTKVgxe94OgYctfyR4iTnp0
Cc: "isis-wg@ietf.org list \(isis-wg@ietf.org\)" , "netmod@ietf.org" 
Subject: Re: [netmod] [Isis-wg] FW: New Version Notification for draft-litkowski-netmod-isis-cfg-00.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 18 Jun 2014 14:22:06 -0000

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

Hi,

It is great to see new YANG modules proposed for standardization.
It would be even better if the data model is explained in some plain text.
IMO, a YANG tree diagram is not a substitute for a summary of the module.

Many of the data definitions have no description-stmt at all.
(Use pyang -ietf mode to identity the issues.)  Some ISIS protocol
reference-stmts
would also help readers understand this YANG module better.

thanks,
Andy


On Wed, Jun 18, 2014 at 1:53 AM, Ladislav Lhotka  wrote:

>
> On 18 Jun 2014, at 10:11,  <
> stephane.litkowski@orange.com> wrote:
>
> > Hi Lada,
> >
> > For sure ISIS WG need to be involved, for ownership of the draft, I
> don't really know which WG need to be "owner". Maybe chairs can provide
> their feedback or we could discuss this point in Toronto.
>
> Yes, and I see Juergen has already started this discussion.
>
> > I'm would like to present this first version in both WG if possible.
>
> That's fine and welcome, I think.
>
> >
> > I would be happy to welcome any contributions, so if you have any point
> to raise or if you want to co-author by adding some text, don't hesitate.
>
> To start with, I plan a thorough review of the module, mainly from the
> YANG point of view. My first impressions are quite positive though. :-)
>
> Lada
>
> >
> > Thanks,
> >
> > Stephane
> >
> >
> > -----Original Message-----
> > From: Ladislav Lhotka [mailto:lhotka@nic.cz]
> > Sent: Tuesday, June 17, 2014 18:14
> > To: LITKOWSKI Stephane SCE/IBNF
> > Cc: isis-wg@ietf.org list (isis-wg@ietf.org)
> > Subject: Re: [Isis-wg] FW: New Version Notification for
> draft-litkowski-netmod-isis-cfg-00.txt
> >
> > Hi Stephane,
> >
> > I am really pleased to see this I-D and the YANG module. I think though
> this work belongs to the ISIS WG where the exposure to routing experts'
> eyes will likely be much higher than in NETMOD. That said, I'd be
> interested in helping you with further development of this module.
> >
> > Thanks, Lada
> >
> > On 17 Jun 2014, at 16:41,  <
> stephane.litkowski@orange.com> wrote:
> >
> >> Hi folks,
> >>
> >> FYI and comments ...
> >>
> >> Here is an initial draft proposal for a YANG model for ISIS.
> >>
> >>
> >> Best Regards,
> >>
> >> Stephane
> >>
> >> -----Original Message-----
> >> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
> >> Sent: Tuesday, June 17, 2014 14:20
> >> To: LITKOWSKI Stephane SCE/IBNF; LITKOWSKI Stephane SCE/IBNF
> >> Subject: New Version Notification for
> >> draft-litkowski-netmod-isis-cfg-00.txt
> >>
> >>
> >> A new version of I-D, draft-litkowski-netmod-isis-cfg-00.txt
> >> has been successfully submitted by Stephane Litkowski and posted to the
> IETF repository.
> >>
> >> Name:                draft-litkowski-netmod-isis-cfg
> >> Revision:    00
> >> Title:               Yang Data Model for ISIS protocol
> >> Document date:       2014-06-17
> >> Group:               Individual Submission
> >> Pages:               22
> >> URL:
> http://www.ietf.org/internet-drafts/draft-litkowski-netmod-isis-cfg-00.txt
> >> Status:
> https://datatracker.ietf.org/doc/draft-litkowski-netmod-isis-cfg/
> >> Htmlized:
> http://tools.ietf.org/html/draft-litkowski-netmod-isis-cfg-00
> >>
> >>
> >> Abstract:
> >>  This document defines a YANG data model that can be used to configure
> >>  and manage ISIS protocol.
> >>
> >>
> >>
> >>
> >>
> >> Please note that it may take a couple of minutes from the time of
> submission until the htmlized version and diff are available at
> tools.ietf.org.
> >>
> >> The IETF Secretariat
> >>
> >>
> >> ______________________________________________________________________
> >> ___________________________________________________
> >>
> >> Ce message et ses pieces jointes peuvent contenir des informations
> >> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,
> >> exploites ou copies sans autorisation. Si vous avez recu ce message
> >> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi
> que les pieces jointes. Les messages electroniques etant susceptibles
> d'alteration, Orange decline toute responsabilite si ce message a ete
> altere, deforme ou falsifie. Merci.
> >>
> >> This message and its attachments may contain confidential or
> >> privileged information that may be protected by law; they should not be
> distributed, used or copied without authorisation.
> >> If you have received this email in error, please notify the sender and
> delete this message and its attachments.
> >> As emails may be altered, Orange is not liable for messages that have
> been modified, changed or falsified.
> >> Thank you.
> >>
> >> _______________________________________________
> >> Isis-wg mailing list
> >> Isis-wg@ietf.org
> >> https://www.ietf.org/mailman/listinfo/isis-wg
> >
> > --
> > Ladislav Lhotka, CZ.NIC Labs
> > PGP Key ID: E74E8C0C
> >
> >
> >
> >
> >
> >
> _________________________________________________________________________________________________________________________
> >
> > Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc
> > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez
> recu ce message par erreur, veuillez le signaler
> > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
> electroniques etant susceptibles d'alteration,
> > Orange decline toute responsabilite si ce message a ete altere, deforme
> ou falsifie. Merci.
> >
> > This message and its attachments may contain confidential or privileged
> information that may be protected by law;
> > they should not be distributed, used or copied without authorisation.
> > If you have received this email in error, please notify the sender and
> delete this message and its attachments.
> > As emails may be altered, Orange is not liable for messages that have
> been modified, changed or falsified.
> > Thank you.
> >
>
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>
>
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>

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


Hi,

It is great to see new YANG modules=
 proposed for standardization.
It would be even better if the dat=
a model is explained in some plain text.
IMO, a YANG tree diagram=
 is not a substitute for a summary of the module.



Many of the data definitions have no description-stmt a=
t all.
(Use pyang -ietf mode to identity the issues.)  Some =
ISIS protocol reference-stmts
would also help readers understand =
this YANG module better.



thanks=
,
Andy

=

On Wed, Jun 18, 2014 at 1:53 AM, Ladislav Lh=
otka <lhotka@nic.cz> wrote:




On 18 Jun 2014, at 10:11, <stephane.litkowski@orange.com> <stephane.litkowski@orange.com> wrote:



> Hi Lada,

>

> For sure ISIS WG need to be involved, for ownership of the draft, I do=
n't really know which WG need to be "owner". Maybe chairs can=
 provide their feedback or we could discuss this point in Toronto.




Yes, and I see Juergen has already started this discussion.



> I'm would like to present this first version in both WG if possibl=
e.



That’s fine and welcome, I think.



>

> I would be happy to welcome any contributions, so if you have any poin=
t to raise or if you want to co-author by adding some text, don't hesit=
ate.



To start with, I plan a thorough review of the module, mainly from the YANG=
 point of view. My first impressions are quite positive though. :-)



Lada



>

> Thanks,

>

> Stephane

>

>

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

> From: Ladislav Lhotka [mailto:lhotka@=
nic.cz]

> Sent: Tuesday, June 17, 2014 18:14

> To: LITKOWSKI Stephane SCE/IBNF

> Cc: isis-wg@ietf.org list (isis-wg@ietf.org)

> Subject: Re: [Isis-wg] FW: New Version Notification for draft-litkowsk=
i-netmod-isis-cfg-00.txt

>

> Hi Stephane,

>

> I am really pleased to see this I-D and the YANG module. I think thoug=
h this work belongs to the ISIS WG where the exposure to routing experts=
9; eyes will likely be much higher than in NETMOD. That said, I'd be in=
terested in helping you with further development of this module.


>

> Thanks, Lada

>

> On 17 Jun 2014, at 16:41, <stephane.litkowski@orange.com> <stephane.litkowski@orange.com> wrote:

>

>> Hi folks,

>>

>> FYI and comments ...

>>

>> Here is an initial draft proposal for a YANG model for ISIS.

>>

>>

>> Best Regards,

>>

>> Stephane

>>

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

>> From: internet-drafts@=
ietf.org [mailto:internet-d=
rafts@ietf.org]

>> Sent: Tuesday, June 17, 2014 14:20

>> To: LITKOWSKI Stephane SCE/IBNF; LITKOWSKI Stephane SCE/IBNF

>> Subject: New Version Notification for

>> draft-litkowski-netmod-isis-cfg-00.txt

>>

>>

>> A new version of I-D, draft-litkowski-netmod-isis-cfg-00.txt

>> has been successfully submitted by Stephane Litkowski and posted t=
o the IETF repository.

>>

>> Name:                draft=
-litkowski-netmod-isis-cfg

>> Revision:    00

>> Title:               Yang Data =
Model for ISIS protocol

>> Document date:       2014-06-17

>> Group:               Individual=
 Submission

>> Pages:               22

>> URL:            http://www.ietf.org/internet-drafts/draft-litkowski-netmod-isis=
-cfg-00.txt

>> Status:         https://d=
atatracker.ietf.org/doc/draft-litkowski-netmod-isis-cfg/

>> Htmlized:       http://tools.ietf.=
org/html/draft-litkowski-netmod-isis-cfg-00

>>

>>

>> Abstract:

>>  This document defines a YANG data model that can be used to =
configure

>>  and manage ISIS protocol.

>>

>>

>>

>>

>>

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

>>

>> The IETF Secretariat

>>

>>

>> __________________________________________________________________=
____

>> ___________________________________________________

>>

>> Ce message et ses pieces jointes peuvent contenir des informations=


>> confidentielles ou privilegiees et ne doivent donc pas etre diffus=
es,

>> exploites ou copies sans autorisation. Si vous avez recu ce messag=
e

>> par erreur, veuillez le signaler a l'expediteur et le detruire=
 ainsi que les pieces jointes. Les messages electroniques etant susceptible=
s d'alteration, Orange decline toute responsabilite si ce message a ete=
 altere, deforme ou falsifie. Merci.


>>

>> This message and its attachments may contain confidential or

>> privileged information that may be protected by law; they should n=
ot be distributed, used or copied without authorisation.

>> If you have received this email in error, please notify the sender=
 and delete this message and its attachments.

>> As emails may be altered, Orange is not liable for messages that h=
ave been modified, changed or falsified.

>> Thank you.

>>

>> _______________________________________________

>> Isis-wg mailing list

>> Isis-wg@ietf.org

>> https://www.ietf.org/mailman/listinfo/isis-wg

>

> --

> Ladislav Lhotka, CZ.NIC Labs

> PGP Key ID: E74E8C0C

>

>

>

>

>

> ______________________________________________________________________=
___________________________________________________

>

> Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles ou privilegiees et ne doivent donc

> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez=
 recu ce message par erreur, veuillez le signaler

> a l'expediteur et le detruire ainsi que les pieces jointes. Les me=
ssages electroniques etant susceptibles d'alteration,

> Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.

>

> This message and its attachments may contain confidential or privilege=
d information that may be protected by law;

> they should not be distributed, used or copied without authorisation.<=
br>
> If you have received this email in error, please notify the sender and=
 delete this message and its attachments.

> As emails may be altered, Orange is not liable for messages that have =
been modified, changed or falsified.

> Thank you.

>



--

Ladislav Lhotka, CZ.NIC Labs

PGP Key ID: E74E8C0C









_______________________________________________

netmod mailing list

netmod@ietf.org

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





--001a11c121b0dd8c7204fc1cfbda--


From nobody Wed Jun 18 10:26:59 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E28D61A0102; Wed, 18 Jun 2014 10:26:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.999
X-Spam-Level: 
X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dTXlpnge5LWk; Wed, 18 Jun 2014 10:26:57 -0700 (PDT)
Received: from mail-yk0-x232.google.com (mail-yk0-x232.google.com [IPv6:2607:f8b0:4002:c07::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4A6A1A0051; Wed, 18 Jun 2014 10:26:56 -0700 (PDT)
Received: by mail-yk0-f178.google.com with SMTP id q9so816826ykb.9 for ; Wed, 18 Jun 2014 10:26:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=kldgifmVBjVHJIhB/liuETEYU0v57k/+AW5vQi91zTY=; b=X7+hx8/ayu2KZSYQxQ7MLei3V3xAL8oPddcBLlDg9Fyvv7t06wDbCB5uel3jOauhGO uGWebaXUMLm6fK/IZsYeafor7qTwOtZ0t73ZfpBeA8exq3r0R7wJl8Rsk0vUGlGSM7HA efmjUCpN/EUvvBRFs5ExYt19vb3yxyEVgijCBX0umvfRcVUwSXNq9S6rEMRmVEmJiXde gmZIktuxBLfx6jpsTHSw2zmyaifDn1Y2x0V6shwFImsgF/IPbvHkbepOLNb59ODqYr66 Xt0EF9VeXqcQyUHhYUCfgUuAsucRaP+pHj0QMY77NCYnthpXGjIUGNLoTjgr9t/OhnuE EMTQ==
MIME-Version: 1.0
X-Received: by 10.236.135.228 with SMTP id u64mr449104yhi.18.1403112416285; Wed, 18 Jun 2014 10:26:56 -0700 (PDT)
Received: by 10.170.52.75 with HTTP; Wed, 18 Jun 2014 10:26:56 -0700 (PDT)
In-Reply-To: <20140618083011.GB6055@elstar.local>
References: <20140617122005.10875.31180.idtracker@ietfa.amsl.com> <24554_1403016065_53A05381_24554_4972_1_9E32478DFA9976438E7A22F69B08FF920215BB@OPEXCLILM34.corporate.adroot.infra.ftgroup> <9D8A1B46-C3AB-4592-810A-2636320697AD@nic.cz> <15719_1403079084_53A149AC_15719_5687_1_9E32478DFA9976438E7A22F69B08FF92021AC0@OPEXCLILM34.corporate.adroot.infra.ftgroup> <20140618083011.GB6055@elstar.local>
Date: Wed, 18 Jun 2014 13:26:56 -0400
Message-ID: 
From: Alia Atlas 
To: Juergen Schoenwaelder ,  Stephane Litkowski , Ladislav Lhotka ,  "isis-wg@ietf.org list (isis-wg@ietf.org)" , "netmod@ietf.org" 
Content-Type: multipart/alternative; boundary=20cf301af3f5271bac04fc1f9107
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/ldb4W3Ke_-wXe7y37UYMY_6UGAE
Subject: Re: [netmod] [Isis-wg] FW: New Version Notification for draft-litkowski-netmod-isis-cfg-00.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 18 Jun 2014 17:26:59 -0000

--20cf301af3f5271bac04fc1f9107
Content-Type: text/plain; charset=UTF-8

isis-wg is the right place.

Alia


On Wed, Jun 18, 2014 at 4:30 AM, Juergen Schoenwaelder <
j.schoenwaelder@jacobs-university.de> wrote:

> On Wed, Jun 18, 2014 at 08:11:24AM +0000, stephane.litkowski@orange.com
> wrote:
> > Hi Lada,
> >
> > For sure ISIS WG need to be involved, for ownership of the draft, I
> don't really know which WG need to be "owner". Maybe chairs can provide
> their feedback or we could discuss this point in Toronto.
> > I'm would like to present this first version in both WG if possible.
> >
>
> As a general principle, I prefer that data models are done in the WGs
> that understand what is being modeled. Hence, this work should ideally
> be done in the ISIS WG.
>
> Since I am not following the ISIS WG myself, I ended up looking at the
> WG charter page in order to get a clue what they are working on and
> what I found is that apparently their milestones have not been updated
> since 2009 (and the additional page pointed to in the charter,
> , does not look more recent
> either). So it remains somewhat difficult to judge whether ISIS may be
> able to pick up this work.
>
> /js
>
> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
> Fax:   +49 421 200 3103         
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>

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


isis-wg is the right place.

Alia
<=
/div>


On Wed, =
Jun 18, 2014 at 4:30 AM, Juergen Schoenwaelder <j.schoe=
nwaelder@jacobs-university.de> wrote:


On Wed, Jun 18, 2014 at 08:1=
1:24AM +0000, stephane.lit=
kowski@orange.com wrote:


> Hi Lada,

>

> For sure ISIS WG need to be involved, for ownership of the draft, I do=
n't really know which WG need to be "owner". Maybe chairs can=
 provide their feedback or we could discuss this point in Toronto.


> I'm would like to present this first version in both WG if possibl=
e.

>




As a general principle, I prefer that data models are done in the WGs=


that understand what is being modeled. Hence, this work should ideally

be done in the ISIS WG.



Since I am not following the ISIS WG myself, I ended up looking at the

WG charter page in order to get a clue what they are working on and

what I found is that apparently their milestones have not been updated

since 2009 (and the additional page pointed to in the charter,

<htt=
p://skat.usc.edu/~tli/Schedule.htm>, does not look more recent

either). So it remains somewhat difficult to judge whether ISIS may be

able to pick up this work.



/js



--

Juergen Schoenwaelder =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Jacobs University =
Bremen gGmbH

Phone: +49=
 421 200 3587 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Campus Ring 1, 28759 Bremen, =
Germany

Fax: =C2=A0 +49 421 200 3103 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <http://www.jacobs-university.de/=
>




_______________________________________________

netmod mailing list

netmod@ietf.org

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





--20cf301af3f5271bac04fc1f9107--


From nobody Thu Jun 19 01:07:02 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27CEC1A0359; Thu, 19 Jun 2014 01:06:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level: 
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pgG3Xk4BxXXY; Thu, 19 Jun 2014 01:06:56 -0700 (PDT)
Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CFE31A030E; Thu, 19 Jun 2014 01:06:56 -0700 (PDT)
Received: from omfeda05.si.francetelecom.fr (unknown [xx.xx.xx.198]) by omfeda14.si.francetelecom.fr (ESMTP service) with ESMTP id 05E742AC3FB; Thu, 19 Jun 2014 10:06:54 +0200 (CEST)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.55]) by omfeda05.si.francetelecom.fr (ESMTP service) with ESMTP id D246C180059; Thu, 19 Jun 2014 10:06:53 +0200 (CEST)
Received: from OPEXCLILM34.corporate.adroot.infra.ftgroup ([169.254.4.50]) by OPEXCLILH03.corporate.adroot.infra.ftgroup ([10.114.31.55]) with mapi id 14.03.0181.006; Thu, 19 Jun 2014 10:06:53 +0200
From: 
To: Alia Atlas , Juergen Schoenwaelder , Ladislav Lhotka , "isis-wg@ietf.org list (isis-wg@ietf.org)" , "netmod@ietf.org" 
Thread-Topic: [netmod] [Isis-wg] FW: New Version Notification for draft-litkowski-netmod-isis-cfg-00.txt
Thread-Index: AQHPiiaBbiuORN4vMkWkQRJKVSRR3Jt1X8Mg///4twCAASue0P//5SCAgACV9QCAARZSYA==
Date: Thu, 19 Jun 2014 08:06:53 +0000
Message-ID: <23516_1403165213_53A29A1D_23516_5180_1_9E32478DFA9976438E7A22F69B08FF9202205C@OPEXCLILM34.corporate.adroot.infra.ftgroup>
References: <20140617122005.10875.31180.idtracker@ietfa.amsl.com> <24554_1403016065_53A05381_24554_4972_1_9E32478DFA9976438E7A22F69B08FF920215BB@OPEXCLILM34.corporate.adroot.infra.ftgroup> <9D8A1B46-C3AB-4592-810A-2636320697AD@nic.cz> <15719_1403079084_53A149AC_15719_5687_1_9E32478DFA9976438E7A22F69B08FF92021AC0@OPEXCLILM34.corporate.adroot.infra.ftgroup> <20140618083011.GB6055@elstar.local> 
In-Reply-To: 
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.168.234.3]
Content-Type: multipart/alternative; boundary="_000_9E32478DFA9976438E7A22F69B08FF9202205COPEXCLILM34corpor_"
MIME-Version: 1.0
X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.6.19.30021
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/X_KdNvZMoOE7uBPaFH4o_qAoouY
Subject: Re: [netmod] [Isis-wg] FW: New Version Notification for draft-litkowski-netmod-isis-cfg-00.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 19 Jun 2014 08:06:59 -0000

--_000_9E32478DFA9976438E7A22F69B08FF9202205COPEXCLILM34corpor_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

VGhhbmtzIEFsaWEgZm9yIHRoZSBjbGFyaWZpY2F0aW9uLg0KVGhlIG5leHQgdXBkYXRlIHdpbGwg
YmUgcmVuYW1lZCB3aXRoIOKAnGlzaXPigJ0gd2cgc3RhdGVtZW50Lg0KDQpJIHRoaW5rIGl0IG1h
eSBiZSB2YWx1YWJsZSB0byBrZWVwIHNvbWUgY3Jvc3MtZGlzY3Vzc2lvbnMgd2l0aCBOZXRtb2Qg
YXMgWUFORyBleHBlcnRpc2UgaXMgSU1PIG1vcmUgaW4gTmV0bW9kLg0KDQoNCkZyb206IEFsaWEg
QXRsYXMgW21haWx0bzpha2F0bGFzQGdtYWlsLmNvbV0NClNlbnQ6IFdlZG5lc2RheSwgSnVuZSAx
OCwgMjAxNCAxOToyNw0KVG86IEp1ZXJnZW4gU2Nob2Vud2FlbGRlcjsgTElUS09XU0tJIFN0ZXBo
YW5lIFNDRS9JQk5GOyBMYWRpc2xhdiBMaG90a2E7IGlzaXMtd2dAaWV0Zi5vcmcgbGlzdCAoaXNp
cy13Z0BpZXRmLm9yZyk7IG5ldG1vZEBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtuZXRtb2RdIFtJ
c2lzLXdnXSBGVzogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1saXRrb3dza2kt
bmV0bW9kLWlzaXMtY2ZnLTAwLnR4dA0KDQppc2lzLXdnIGlzIHRoZSByaWdodCBwbGFjZS4NCg0K
QWxpYQ0KDQpPbiBXZWQsIEp1biAxOCwgMjAxNCBhdCA0OjMwIEFNLCBKdWVyZ2VuIFNjaG9lbndh
ZWxkZXIgPGouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZTxtYWlsdG86ai5zY2hv
ZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRlPj4gd3JvdGU6DQpPbiBXZWQsIEp1biAxOCwg
MjAxNCBhdCAwODoxMToyNEFNICswMDAwLCBzdGVwaGFuZS5saXRrb3dza2lAb3JhbmdlLmNvbTxt
YWlsdG86c3RlcGhhbmUubGl0a293c2tpQG9yYW5nZS5jb20+IHdyb3RlOg0KPiBIaSBMYWRhLA0K
Pg0KPiBGb3Igc3VyZSBJU0lTIFdHIG5lZWQgdG8gYmUgaW52b2x2ZWQsIGZvciBvd25lcnNoaXAg
b2YgdGhlIGRyYWZ0LCBJIGRvbid0IHJlYWxseSBrbm93IHdoaWNoIFdHIG5lZWQgdG8gYmUgIm93
bmVyIi4gTWF5YmUgY2hhaXJzIGNhbiBwcm92aWRlIHRoZWlyIGZlZWRiYWNrIG9yIHdlIGNvdWxk
IGRpc2N1c3MgdGhpcyBwb2ludCBpbiBUb3JvbnRvLg0KPiBJJ20gd291bGQgbGlrZSB0byBwcmVz
ZW50IHRoaXMgZmlyc3QgdmVyc2lvbiBpbiBib3RoIFdHIGlmIHBvc3NpYmxlLg0KPg0KQXMgYSBn
ZW5lcmFsIHByaW5jaXBsZSwgSSBwcmVmZXIgdGhhdCBkYXRhIG1vZGVscyBhcmUgZG9uZSBpbiB0
aGUgV0dzDQp0aGF0IHVuZGVyc3RhbmQgd2hhdCBpcyBiZWluZyBtb2RlbGVkLiBIZW5jZSwgdGhp
cyB3b3JrIHNob3VsZCBpZGVhbGx5DQpiZSBkb25lIGluIHRoZSBJU0lTIFdHLg0KDQpTaW5jZSBJ
IGFtIG5vdCBmb2xsb3dpbmcgdGhlIElTSVMgV0cgbXlzZWxmLCBJIGVuZGVkIHVwIGxvb2tpbmcg
YXQgdGhlDQpXRyBjaGFydGVyIHBhZ2UgaW4gb3JkZXIgdG8gZ2V0IGEgY2x1ZSB3aGF0IHRoZXkg
YXJlIHdvcmtpbmcgb24gYW5kDQp3aGF0IEkgZm91bmQgaXMgdGhhdCBhcHBhcmVudGx5IHRoZWly
IG1pbGVzdG9uZXMgaGF2ZSBub3QgYmVlbiB1cGRhdGVkDQpzaW5jZSAyMDA5IChhbmQgdGhlIGFk
ZGl0aW9uYWwgcGFnZSBwb2ludGVkIHRvIGluIHRoZSBjaGFydGVyLA0KPGh0dHA6Ly9za2F0LnVz
Yy5lZHUvfnRsaS9TY2hlZHVsZS5odG0+LCBkb2VzIG5vdCBsb29rIG1vcmUgcmVjZW50DQplaXRo
ZXIpLiBTbyBpdCByZW1haW5zIHNvbWV3aGF0IGRpZmZpY3VsdCB0byBqdWRnZSB3aGV0aGVyIElT
SVMgbWF5IGJlDQphYmxlIHRvIHBpY2sgdXAgdGhpcyB3b3JrLg0KDQovanMNCg0KLS0NCkp1ZXJn
ZW4gU2Nob2Vud2FlbGRlciAgICAgICAgICAgSmFjb2JzIFVuaXZlcnNpdHkgQnJlbWVuIGdHbWJI
DQpQaG9uZTogKzQ5IDQyMSAyMDAgMzU4Nzx0ZWw6JTJCNDklMjA0MjElMjAyMDAlMjAzNTg3PiAg
ICAgICAgIENhbXB1cyBSaW5nIDEsIDI4NzU5IEJyZW1lbiwgR2VybWFueQ0KRmF4OiAgICs0OSA0
MjEgMjAwIDMxMDM8dGVsOiUyQjQ5JTIwNDIxJTIwMjAwJTIwMzEwMz4gICAgICAgICA8aHR0cDov
L3d3dy5qYWNvYnMtdW5pdmVyc2l0eS5kZS8+DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fDQpuZXRtb2QgbWFpbGluZyBsaXN0DQpuZXRtb2RAaWV0Zi5v
cmc8bWFpbHRvOm5ldG1vZEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v
bGlzdGluZm8vbmV0bW9kDQoNCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fCgpDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9p
bnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91
IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMKcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxv
aXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1l
c3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXIKYSBsJ2V4cGVkaXRldXIgZXQg
bGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVs
ZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwKT3JhbmdlIGRlY2xp
bmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9y
bWUgb3UgZmFsc2lmaWUuIE1lcmNpLgoKVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMg
bWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBt
YXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsKdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1
c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uCklmIHlvdSBoYXZlIHJlY2VpdmVk
IHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRl
IHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLgpBcyBlbWFpbHMgbWF5IGJlIGFsdGVy
ZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2Rp
ZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuClRoYW5rIHlvdS4KCg==

--_000_9E32478DFA9976438E7A22F69B08FF9202205COPEXCLILM34corpor_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ
e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov
KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z
b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp
emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps
aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6
Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I
eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl
Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5ob2VuemINCgl7bXNvLXN0eWxl
LW5hbWU6aG9lbnpiO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNv
bmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6
IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsN
Cglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCkBwYWdlIFdvcmRTZWN0aW9u
MQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47
fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwh
LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3Bp
ZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s
Pg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRh
dGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8
Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNz
PSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl
cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoYW5rcyBBbGlhIGZvciB0aGUgY2xhcmlmaWNhdGlv
bi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90
O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhlIG5leHQgdXBkYXRlIHdpbGwgYmUg
cmVuYW1lZCB3aXRoIOKAnGlzaXPigJ0gd2cgc3RhdGVtZW50LjxvOnA+PC9vOnA+PC9zcGFuPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv
cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp
YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSB0aGluayBp
dCBtYXkgYmUgdmFsdWFibGUgdG8ga2VlcCBzb21lIGNyb3NzLWRpc2N1c3Npb25zIHdpdGggTmV0
bW9kIGFzIFlBTkcgZXhwZXJ0aXNlIGlzIElNTyBtb3JlIGluIE5ldG1vZC48bzpwPjwvbzpwPjwv
c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx
LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv
dDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxv
OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90Oywm
cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2Vy
aWYmcXVvdDsiPiBBbGlhIEF0bGFzIFttYWlsdG86YWthdGxhc0BnbWFpbC5jb21dDQo8YnI+DQo8
Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBKdW5lIDE4LCAyMDE0IDE5OjI3PGJyPg0KPGI+VG86PC9i
PiBKdWVyZ2VuIFNjaG9lbndhZWxkZXI7IExJVEtPV1NLSSBTdGVwaGFuZSBTQ0UvSUJORjsgTGFk
aXNsYXYgTGhvdGthOyBpc2lzLXdnQGlldGYub3JnIGxpc3QgKGlzaXMtd2dAaWV0Zi5vcmcpOyBu
ZXRtb2RAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtuZXRtb2RdIFtJc2lzLXdn
XSBGVzogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1saXRrb3dza2ktbmV0bW9k
LWlzaXMtY2ZnLTAwLnR4dDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmlz
aXMtd2cgaXMgdGhlIHJpZ2h0IHBsYWNlLjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+QWxpYTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxvOnA+
Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFdlZCwgSnVu
IDE4LCAyMDE0IGF0IDQ6MzAgQU0sIEp1ZXJnZW4gU2Nob2Vud2FlbGRlciAmbHQ7PGEgaHJlZj0i
bWFpbHRvOmouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZSIgdGFyZ2V0PSJfYmxh
bmsiPmouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZTwvYT4mZ3Q7IHdyb3RlOjxv
OnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t
Ym90dG9tOjEyLjBwdCI+T24gV2VkLCBKdW4gMTgsIDIwMTQgYXQgMDg6MTE6MjRBTSAmIzQzOzAw
MDAsDQo8YSBocmVmPSJtYWlsdG86c3RlcGhhbmUubGl0a293c2tpQG9yYW5nZS5jb20iPnN0ZXBo
YW5lLmxpdGtvd3NraUBvcmFuZ2UuY29tPC9hPiB3cm90ZTo8YnI+DQomZ3Q7IEhpIExhZGEsPGJy
Pg0KJmd0Ozxicj4NCiZndDsgRm9yIHN1cmUgSVNJUyBXRyBuZWVkIHRvIGJlIGludm9sdmVkLCBm
b3Igb3duZXJzaGlwIG9mIHRoZSBkcmFmdCwgSSBkb24ndCByZWFsbHkga25vdyB3aGljaCBXRyBu
ZWVkIHRvIGJlICZxdW90O293bmVyJnF1b3Q7LiBNYXliZSBjaGFpcnMgY2FuIHByb3ZpZGUgdGhl
aXIgZmVlZGJhY2sgb3Igd2UgY291bGQgZGlzY3VzcyB0aGlzIHBvaW50IGluIFRvcm9udG8uPGJy
Pg0KJmd0OyBJJ20gd291bGQgbGlrZSB0byBwcmVzZW50IHRoaXMgZmlyc3QgdmVyc2lvbiBpbiBi
b3RoIFdHIGlmIHBvc3NpYmxlLjxicj4NCiZndDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+QXMgYSBnZW5lcmFsIHByaW5jaXBsZSwgSSBwcmVmZXIgdGhhdCBk
YXRhIG1vZGVscyBhcmUgZG9uZSBpbiB0aGUgV0dzPGJyPg0KdGhhdCB1bmRlcnN0YW5kIHdoYXQg
aXMgYmVpbmcgbW9kZWxlZC4gSGVuY2UsIHRoaXMgd29yayBzaG91bGQgaWRlYWxseTxicj4NCmJl
IGRvbmUgaW4gdGhlIElTSVMgV0cuPGJyPg0KPGJyPg0KU2luY2UgSSBhbSBub3QgZm9sbG93aW5n
IHRoZSBJU0lTIFdHIG15c2VsZiwgSSBlbmRlZCB1cCBsb29raW5nIGF0IHRoZTxicj4NCldHIGNo
YXJ0ZXIgcGFnZSBpbiBvcmRlciB0byBnZXQgYSBjbHVlIHdoYXQgdGhleSBhcmUgd29ya2luZyBv
biBhbmQ8YnI+DQp3aGF0IEkgZm91bmQgaXMgdGhhdCBhcHBhcmVudGx5IHRoZWlyIG1pbGVzdG9u
ZXMgaGF2ZSBub3QgYmVlbiB1cGRhdGVkPGJyPg0Kc2luY2UgMjAwOSAoYW5kIHRoZSBhZGRpdGlv
bmFsIHBhZ2UgcG9pbnRlZCB0byBpbiB0aGUgY2hhcnRlciw8YnI+DQombHQ7PGEgaHJlZj0iaHR0
cDovL3NrYXQudXNjLmVkdS9+dGxpL1NjaGVkdWxlLmh0bSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6
Ly9za2F0LnVzYy5lZHUvfnRsaS9TY2hlZHVsZS5odG08L2E+Jmd0OywgZG9lcyBub3QgbG9vayBt
b3JlIHJlY2VudDxicj4NCmVpdGhlcikuIFNvIGl0IHJlbWFpbnMgc29tZXdoYXQgZGlmZmljdWx0
IHRvIGp1ZGdlIHdoZXRoZXIgSVNJUyBtYXkgYmU8YnI+DQphYmxlIHRvIHBpY2sgdXAgdGhpcyB3
b3JrLjxicj4NCjxzcGFuIHN0eWxlPSJjb2xvcjojODg4ODg4Ij48YnI+DQo8c3BhbiBjbGFzcz0i
aG9lbnpiIj4vanM8L3NwYW4+PGJyPg0KPGJyPg0KPHNwYW4gY2xhc3M9ImhvZW56YiI+LS08L3Nw
YW4+PGJyPg0KPHNwYW4gY2xhc3M9ImhvZW56YiI+SnVlcmdlbiBTY2hvZW53YWVsZGVyICZuYnNw
OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgSmFjb2JzIFVuaXZlcnNpdHkgQnJlbWVuIGdH
bWJIPC9zcGFuPjxicj4NCjxzcGFuIGNsYXNzPSJob2VuemIiPlBob25lOiA8YSBocmVmPSJ0ZWw6
JTJCNDklMjA0MjElMjAyMDAlMjAzNTg3Ij4mIzQzOzQ5IDQyMSAyMDAgMzU4NzwvYT4gJm5ic3A7
ICZuYnNwOyAmbmJzcDsgJm5ic3A7IENhbXB1cyBSaW5nIDEsIDI4NzU5IEJyZW1lbiwgR2VybWFu
eTwvc3Bhbj48YnI+DQo8c3BhbiBjbGFzcz0iaG9lbnpiIj5GYXg6ICZuYnNwOyA8YSBocmVmPSJ0
ZWw6JTJCNDklMjA0MjElMjAyMDAlMjAzMTAzIj4mIzQzOzQ5IDQyMSAyMDAgMzEwMzwvYT4gJm5i
c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZsdDs8YSBocmVmPSJodHRwOi8vd3d3LmphY29icy11
bml2ZXJzaXR5LmRlLyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly93d3cuamFjb2JzLXVuaXZlcnNp
dHkuZGUvPC9hPiZndDs8L3NwYW4+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fXzxicj4NCm5ldG1vZCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVm
PSJtYWlsdG86bmV0bW9kQGlldGYub3JnIj5uZXRtb2RAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJl
Zj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QiIHRhcmdldD0i
X2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZDwvYT48
bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxQUkU+X19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwoK
Q2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5m
b3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBk
b25jCnBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0
aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxl
IHNpZ25hbGVyCmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGll
Y2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxl
cyBkJ2FsdGVyYXRpb24sCk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNl
IG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4KClRoaXMg
bWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBw
cml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7CnRoZXkg
c2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jp
c2F0aW9uLgpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ug
bm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2ht
ZW50cy4KQXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3Ig
bWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLgpU
aGFuayB5b3UuCjwvUFJFPjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_9E32478DFA9976438E7A22F69B08FF9202205COPEXCLILM34corpor_--


From nobody Thu Jun 19 01:23:51 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A4C41A0040; Thu, 19 Jun 2014 01:23:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.201
X-Spam-Level: 
X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A5kKRCg-pKc8; Thu, 19 Jun 2014 01:23:44 -0700 (PDT)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21EC71A0033; Thu, 19 Jun 2014 01:23:44 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 2687CFAB; Thu, 19 Jun 2014 10:23:42 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 5F9Oe1-v2iW0; Thu, 19 Jun 2014 10:23:26 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 19 Jun 2014 10:23:41 +0200 (CEST)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7A6ED2002C; Thu, 19 Jun 2014 10:23:41 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id acbmh9fn1bdH; Thu, 19 Jun 2014 10:23:39 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0D4E720017; Thu, 19 Jun 2014 10:23:40 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id A7AEA2D930A3; Thu, 19 Jun 2014 10:23:38 +0200 (CEST)
Date: Thu, 19 Jun 2014 10:23:38 +0200
From: Juergen Schoenwaelder 
To: stephane.litkowski@orange.com
Message-ID: <20140619082336.GC9041@elstar.local>
Mail-Followup-To: stephane.litkowski@orange.com, Alia Atlas , Ladislav Lhotka , "isis-wg@ietf.org list (isis-wg@ietf.org)" , "netmod@ietf.org" 
References: <20140617122005.10875.31180.idtracker@ietfa.amsl.com> <24554_1403016065_53A05381_24554_4972_1_9E32478DFA9976438E7A22F69B08FF920215BB@OPEXCLILM34.corporate.adroot.infra.ftgroup> <9D8A1B46-C3AB-4592-810A-2636320697AD@nic.cz> <15719_1403079084_53A149AC_15719_5687_1_9E32478DFA9976438E7A22F69B08FF92021AC0@OPEXCLILM34.corporate.adroot.infra.ftgroup> <20140618083011.GB6055@elstar.local>  <23516_1403165213_53A29A1D_23516_5180_1_9E32478DFA9976438E7A22F69B08FF9202205C@OPEXCLILM34.corporate.adroot.infra.ftgroup>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <23516_1403165213_53A29A1D_23516_5180_1_9E32478DFA9976438E7A22F69B08FF9202205C@OPEXCLILM34.corporate.adroot.infra.ftgroup>
User-Agent: Mutt/1.4.2.3i
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/Dgt3h_EHj5I_-XiosQmTYotIhVs
Cc: "isis-wg@ietf.org list \(isis-wg@ietf.org\)" , "netmod@ietf.org" 
Subject: Re: [netmod] [Isis-wg] FW: New Version Notification for draft-litkowski-netmod-isis-cfg-00.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 19 Jun 2014 08:23:48 -0000

Hi,

it is surely good to keep the NETMOD WG updated about such activities
going on in other WGs. However, NETMOD is not functioning as a YANG
review team as stated on the NETMOD charter:

  The NETMOD Working Group will not serve as a review team for YANG
  modules developed by other working groups. The YANG doctors,
  organized by the OPS area director responsible for network
  management, can act as advisors for other working groups and they
  provide YANG reviews for the OPS area directors.

Since Lada indicated interest in this work and he is also a YANG
doctor, I think we are in a pretty good shape (and I am sure that Lada
will raise any issues that are more fundamental (should they show up)
when it is appropriate).

/js

On Thu, Jun 19, 2014 at 08:06:53AM +0000, stephane.litkowski@orange.com wrote:
> Thanks Alia for the clarification.
> The next update will be renamed with “isis†wg statement.
> 
> I think it may be valuable to keep some cross-discussions with Netmod as YANG expertise is IMO more in Netmod.
> 
> 
> From: Alia Atlas [mailto:akatlas@gmail.com]
> Sent: Wednesday, June 18, 2014 19:27
> To: Juergen Schoenwaelder; LITKOWSKI Stephane SCE/IBNF; Ladislav Lhotka; isis-wg@ietf.org list (isis-wg@ietf.org); netmod@ietf.org
> Subject: Re: [netmod] [Isis-wg] FW: New Version Notification for draft-litkowski-netmod-isis-cfg-00.txt
> 
> isis-wg is the right place.
> 
> Alia
> 
> On Wed, Jun 18, 2014 at 4:30 AM, Juergen Schoenwaelder > wrote:
> On Wed, Jun 18, 2014 at 08:11:24AM +0000, stephane.litkowski@orange.com wrote:
> > Hi Lada,
> >
> > For sure ISIS WG need to be involved, for ownership of the draft, I don't really know which WG need to be "owner". Maybe chairs can provide their feedback or we could discuss this point in Toronto.
> > I'm would like to present this first version in both WG if possible.
> >
> As a general principle, I prefer that data models are done in the WGs
> that understand what is being modeled. Hence, this work should ideally
> be done in the ISIS WG.
> 
> Since I am not following the ISIS WG myself, I ended up looking at the
> WG charter page in order to get a clue what they are working on and
> what I found is that apparently their milestones have not been updated
> since 2009 (and the additional page pointed to in the charter,
> , does not look more recent
> either). So it remains somewhat difficult to judge whether ISIS may be
> able to pick up this work.
> 
> /js
> 
> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
> Fax:   +49 421 200 3103         
> 
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
> 
> 
> _________________________________________________________________________________________________________________________
> 
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
> 
> This message and its attachments may contain confidential or privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
> Thank you.
> 

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


From nobody Thu Jun 19 03:49:00 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EF9D1A0139; Thu, 19 Jun 2014 03:48:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hsGEAHQPMNtX; Thu, 19 Jun 2014 03:48:50 -0700 (PDT)
Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC29F1A011F; Thu, 19 Jun 2014 03:48:49 -0700 (PDT)
Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 1E19E32414C; Thu, 19 Jun 2014 12:48:48 +0200 (CEST)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.55]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id ECDC023807E; Thu, 19 Jun 2014 12:48:47 +0200 (CEST)
Received: from OPEXCLILM34.corporate.adroot.infra.ftgroup ([169.254.4.50]) by OPEXCLILH03.corporate.adroot.infra.ftgroup ([10.114.31.55]) with mapi id 14.03.0181.006; Thu, 19 Jun 2014 12:48:48 +0200
From: 
To: Juergen Schoenwaelder 
Thread-Topic: [netmod] [Isis-wg] FW: New Version Notification for draft-litkowski-netmod-isis-cfg-00.txt
Thread-Index: AQHPiiaBbiuORN4vMkWkQRJKVSRR3Jt1X8Mg///4twCAASue0P//5SCAgACV9QCAARwYoYAAKHNA
Date: Thu, 19 Jun 2014 10:48:47 +0000
Message-ID: <31786_1403174928_53A2C00F_31786_5630_1_9E32478DFA9976438E7A22F69B08FF92022201@OPEXCLILM34.corporate.adroot.infra.ftgroup>
References: <20140617122005.10875.31180.idtracker@ietfa.amsl.com> <24554_1403016065_53A05381_24554_4972_1_9E32478DFA9976438E7A22F69B08FF920215BB@OPEXCLILM34.corporate.adroot.infra.ftgroup> <9D8A1B46-C3AB-4592-810A-2636320697AD@nic.cz> <15719_1403079084_53A149AC_15719_5687_1_9E32478DFA9976438E7A22F69B08FF92021AC0@OPEXCLILM34.corporate.adroot.infra.ftgroup> <20140618083011.GB6055@elstar.local>  <23516_1403165213_53A29A1D_23516_5180_1_9E32478DFA9976438E7A22F69B08FF9202205C@OPEXCLILM34.corporate.adroot.infra.ftgroup> <20140619082336.GC9041@elstar.local>
In-Reply-To: <20140619082336.GC9041@elstar.local>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.168.234.3]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.6.19.93024
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/DNJSL22CKg834qpjBrP24Iu1NWE
Cc: "isis-wg@ietf.org list \(isis-wg@ietf.org\)" , "netmod@ietf.org" 
Subject: Re: [netmod] [Isis-wg] FW: New Version Notification for draft-litkowski-netmod-isis-cfg-00.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 19 Jun 2014 10:48:52 -0000

VGhhbmtzIGZvciB0aGUgY2xhcmlmaWNhdGlvbi4NCg0KU3RlcGhhbmUNCg0KLS0tLS1PcmlnaW5h
bCBNZXNzYWdlLS0tLS0NCkZyb206IEp1ZXJnZW4gU2Nob2Vud2FlbGRlciBbbWFpbHRvOmouc2No
b2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZV0gDQpTZW50OiBUaHVyc2RheSwgSnVuZSAx
OSwgMjAxNCAxMDoyNA0KVG86IExJVEtPV1NLSSBTdGVwaGFuZSBTQ0UvSUJORg0KQ2M6IEFsaWEg
QXRsYXM7IExhZGlzbGF2IExob3RrYTsgaXNpcy13Z0BpZXRmLm9yZyBsaXN0IChpc2lzLXdnQGll
dGYub3JnKTsgbmV0bW9kQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW25ldG1vZF0gW0lzaXMtd2dd
IEZXOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWxpdGtvd3NraS1uZXRtb2Qt
aXNpcy1jZmctMDAudHh0DQoNCkhpLA0KDQppdCBpcyBzdXJlbHkgZ29vZCB0byBrZWVwIHRoZSBO
RVRNT0QgV0cgdXBkYXRlZCBhYm91dCBzdWNoIGFjdGl2aXRpZXMgZ29pbmcgb24gaW4gb3RoZXIg
V0dzLiBIb3dldmVyLCBORVRNT0QgaXMgbm90IGZ1bmN0aW9uaW5nIGFzIGEgWUFORyByZXZpZXcg
dGVhbSBhcyBzdGF0ZWQgb24gdGhlIE5FVE1PRCBjaGFydGVyOg0KDQogIFRoZSBORVRNT0QgV29y
a2luZyBHcm91cCB3aWxsIG5vdCBzZXJ2ZSBhcyBhIHJldmlldyB0ZWFtIGZvciBZQU5HDQogIG1v
ZHVsZXMgZGV2ZWxvcGVkIGJ5IG90aGVyIHdvcmtpbmcgZ3JvdXBzLiBUaGUgWUFORyBkb2N0b3Jz
LA0KICBvcmdhbml6ZWQgYnkgdGhlIE9QUyBhcmVhIGRpcmVjdG9yIHJlc3BvbnNpYmxlIGZvciBu
ZXR3b3JrDQogIG1hbmFnZW1lbnQsIGNhbiBhY3QgYXMgYWR2aXNvcnMgZm9yIG90aGVyIHdvcmtp
bmcgZ3JvdXBzIGFuZCB0aGV5DQogIHByb3ZpZGUgWUFORyByZXZpZXdzIGZvciB0aGUgT1BTIGFy
ZWEgZGlyZWN0b3JzLg0KDQpTaW5jZSBMYWRhIGluZGljYXRlZCBpbnRlcmVzdCBpbiB0aGlzIHdv
cmsgYW5kIGhlIGlzIGFsc28gYSBZQU5HIGRvY3RvciwgSSB0aGluayB3ZSBhcmUgaW4gYSBwcmV0
dHkgZ29vZCBzaGFwZSAoYW5kIEkgYW0gc3VyZSB0aGF0IExhZGEgd2lsbCByYWlzZSBhbnkgaXNz
dWVzIHRoYXQgYXJlIG1vcmUgZnVuZGFtZW50YWwgKHNob3VsZCB0aGV5IHNob3cgdXApIHdoZW4g
aXQgaXMgYXBwcm9wcmlhdGUpLg0KDQovanMNCg0KT24gVGh1LCBKdW4gMTksIDIwMTQgYXQgMDg6
MDY6NTNBTSArMDAwMCwgc3RlcGhhbmUubGl0a293c2tpQG9yYW5nZS5jb20gd3JvdGU6DQo+IFRo
YW5rcyBBbGlhIGZvciB0aGUgY2xhcmlmaWNhdGlvbi4NCj4gVGhlIG5leHQgdXBkYXRlIHdpbGwg
YmUgcmVuYW1lZCB3aXRoIOKAnGlzaXPigJ0gd2cgc3RhdGVtZW50Lg0KPiANCj4gSSB0aGluayBp
dCBtYXkgYmUgdmFsdWFibGUgdG8ga2VlcCBzb21lIGNyb3NzLWRpc2N1c3Npb25zIHdpdGggTmV0
bW9kIGFzIFlBTkcgZXhwZXJ0aXNlIGlzIElNTyBtb3JlIGluIE5ldG1vZC4NCj4gDQo+IA0KPiBG
cm9tOiBBbGlhIEF0bGFzIFttYWlsdG86YWthdGxhc0BnbWFpbC5jb21dDQo+IFNlbnQ6IFdlZG5l
c2RheSwgSnVuZSAxOCwgMjAxNCAxOToyNw0KPiBUbzogSnVlcmdlbiBTY2hvZW53YWVsZGVyOyBM
SVRLT1dTS0kgU3RlcGhhbmUgU0NFL0lCTkY7IExhZGlzbGF2IA0KPiBMaG90a2E7IGlzaXMtd2dA
aWV0Zi5vcmcgbGlzdCAoaXNpcy13Z0BpZXRmLm9yZyk7IG5ldG1vZEBpZXRmLm9yZw0KPiBTdWJq
ZWN0OiBSZTogW25ldG1vZF0gW0lzaXMtd2ddIEZXOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24g
Zm9yIA0KPiBkcmFmdC1saXRrb3dza2ktbmV0bW9kLWlzaXMtY2ZnLTAwLnR4dA0KPiANCj4gaXNp
cy13ZyBpcyB0aGUgcmlnaHQgcGxhY2UuDQo+IA0KPiBBbGlhDQo+IA0KPiBPbiBXZWQsIEp1biAx
OCwgMjAxNCBhdCA0OjMwIEFNLCBKdWVyZ2VuIFNjaG9lbndhZWxkZXIgPGouc2Nob2Vud2FlbGRl
ckBqYWNvYnMtdW5pdmVyc2l0eS5kZTxtYWlsdG86ai5zY2hvZW53YWVsZGVyQGphY29icy11bml2
ZXJzaXR5LmRlPj4gd3JvdGU6DQo+IE9uIFdlZCwgSnVuIDE4LCAyMDE0IGF0IDA4OjExOjI0QU0g
KzAwMDAsIHN0ZXBoYW5lLmxpdGtvd3NraUBvcmFuZ2UuY29tPG1haWx0bzpzdGVwaGFuZS5saXRr
b3dza2lAb3JhbmdlLmNvbT4gd3JvdGU6DQo+ID4gSGkgTGFkYSwNCj4gPg0KPiA+IEZvciBzdXJl
IElTSVMgV0cgbmVlZCB0byBiZSBpbnZvbHZlZCwgZm9yIG93bmVyc2hpcCBvZiB0aGUgZHJhZnQs
IEkgZG9uJ3QgcmVhbGx5IGtub3cgd2hpY2ggV0cgbmVlZCB0byBiZSAib3duZXIiLiBNYXliZSBj
aGFpcnMgY2FuIHByb3ZpZGUgdGhlaXIgZmVlZGJhY2sgb3Igd2UgY291bGQgZGlzY3VzcyB0aGlz
IHBvaW50IGluIFRvcm9udG8uDQo+ID4gSSdtIHdvdWxkIGxpa2UgdG8gcHJlc2VudCB0aGlzIGZp
cnN0IHZlcnNpb24gaW4gYm90aCBXRyBpZiBwb3NzaWJsZS4NCj4gPg0KPiBBcyBhIGdlbmVyYWwg
cHJpbmNpcGxlLCBJIHByZWZlciB0aGF0IGRhdGEgbW9kZWxzIGFyZSBkb25lIGluIHRoZSBXR3Mg
DQo+IHRoYXQgdW5kZXJzdGFuZCB3aGF0IGlzIGJlaW5nIG1vZGVsZWQuIEhlbmNlLCB0aGlzIHdv
cmsgc2hvdWxkIGlkZWFsbHkgDQo+IGJlIGRvbmUgaW4gdGhlIElTSVMgV0cuDQo+IA0KPiBTaW5j
ZSBJIGFtIG5vdCBmb2xsb3dpbmcgdGhlIElTSVMgV0cgbXlzZWxmLCBJIGVuZGVkIHVwIGxvb2tp
bmcgYXQgdGhlIA0KPiBXRyBjaGFydGVyIHBhZ2UgaW4gb3JkZXIgdG8gZ2V0IGEgY2x1ZSB3aGF0
IHRoZXkgYXJlIHdvcmtpbmcgb24gYW5kIA0KPiB3aGF0IEkgZm91bmQgaXMgdGhhdCBhcHBhcmVu
dGx5IHRoZWlyIG1pbGVzdG9uZXMgaGF2ZSBub3QgYmVlbiB1cGRhdGVkIA0KPiBzaW5jZSAyMDA5
IChhbmQgdGhlIGFkZGl0aW9uYWwgcGFnZSBwb2ludGVkIHRvIGluIHRoZSBjaGFydGVyLCANCj4g
PGh0dHA6Ly9za2F0LnVzYy5lZHUvfnRsaS9TY2hlZHVsZS5odG0+LCBkb2VzIG5vdCBsb29rIG1v
cmUgcmVjZW50IA0KPiBlaXRoZXIpLiBTbyBpdCByZW1haW5zIHNvbWV3aGF0IGRpZmZpY3VsdCB0
byBqdWRnZSB3aGV0aGVyIElTSVMgbWF5IGJlIA0KPiBhYmxlIHRvIHBpY2sgdXAgdGhpcyB3b3Jr
Lg0KPiANCj4gL2pzDQo+IA0KPiAtLQ0KPiBKdWVyZ2VuIFNjaG9lbndhZWxkZXIgICAgICAgICAg
IEphY29icyBVbml2ZXJzaXR5IEJyZW1lbiBnR21iSA0KPiBQaG9uZTogKzQ5IDQyMSAyMDAgMzU4
Nzx0ZWw6JTJCNDklMjA0MjElMjAyMDAlMjAzNTg3PiAgICAgICAgIENhbXB1cyBSaW5nIDEsIDI4
NzU5IEJyZW1lbiwgR2VybWFueQ0KPiBGYXg6ICAgKzQ5IDQyMSAyMDAgMzEwMzx0ZWw6JTJCNDkl
MjA0MjElMjAyMDAlMjAzMTAzPiAgICAgICAgIDxodHRwOi8vd3d3LmphY29icy11bml2ZXJzaXR5
LmRlLz4NCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fDQo+IG5ldG1vZCBtYWlsaW5nIGxpc3QNCj4gbmV0bW9kQGlldGYub3JnPG1haWx0bzpuZXRt
b2RAaWV0Zi5vcmc+DQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0
bW9kDQo+IA0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBfX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gDQo+IENlIG1lc3NhZ2UgZXQgc2VzIHBpZWNl
cyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyANCj4gY29uZmlkZW50
aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMgcGFzIGV0cmUgZGlmZnVz
ZXMsIA0KPiBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2
ZXogcmVjdSBjZSBtZXNzYWdlIA0KPiBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlciBh
IGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVz
LiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0
aW9uLCBPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEg
ZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuDQo+IA0KPiBUaGlzIG1lc3Nh
Z2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgDQo+IHBy
aXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsgdGhleSBz
aG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlz
YXRpb24uDQo+IElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFz
ZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFj
aG1lbnRzLg0KPiBBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxl
IGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZp
ZWQuDQo+IFRoYW5rIHlvdS4NCj4gDQoNCi0tIA0KSnVlcmdlbiBTY2hvZW53YWVsZGVyICAgICAg
ICAgICBKYWNvYnMgVW5pdmVyc2l0eSBCcmVtZW4gZ0dtYkgNClBob25lOiArNDkgNDIxIDIwMCAz
NTg3ICAgICAgICAgQ2FtcHVzIFJpbmcgMSwgMjg3NTkgQnJlbWVuLCBHZXJtYW55DQpGYXg6ICAg
KzQ5IDQyMSAyMDAgMzEwMyAgICAgICAgIDxodHRwOi8vd3d3LmphY29icy11bml2ZXJzaXR5LmRl
Lz4NCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fCgpDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNv
bnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBl
dCBuZSBkb2l2ZW50IGRvbmMKcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMg
c2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1
ciwgdmV1aWxsZXogbGUgc2lnbmFsZXIKYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWlu
c2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRh
bnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwKT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9u
c2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUu
IE1lcmNpLgoKVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29u
ZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVk
IGJ5IGxhdzsKdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3
aXRob3V0IGF1dGhvcmlzYXRpb24uCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4g
ZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBh
bmQgaXRzIGF0dGFjaG1lbnRzLgpBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBu
b3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBv
ciBmYWxzaWZpZWQuClRoYW5rIHlvdS4KCg==


From nobody Thu Jun 19 05:58:04 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1DED1A039C; Thu, 19 Jun 2014 05:58:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.552
X-Spam-Level: 
X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VS5vOseueSlY; Thu, 19 Jun 2014 05:58:00 -0700 (PDT)
Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 728131A01B0; Thu, 19 Jun 2014 05:57:59 -0700 (PDT)
Received: from [192.168.1.110] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id A485527EB881; Thu, 19 Jun 2014 08:57:58 -0400 (EDT)
Content-Type: multipart/signed; boundary="Apple-Mail=_B5B3E7AC-7841-4E57-ABC9-7880D0FA8980"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
From: "Thomas D. Nadeau" 
In-Reply-To: <23516_1403165213_53A29A1D_23516_5180_1_9E32478DFA9976438E7A22F69B08FF9202205C@OPEXCLILM34.corporate.adroot.infra.ftgroup>
Date: Thu, 19 Jun 2014 08:57:50 -0400
Message-Id: 
References: <20140617122005.10875.31180.idtracker@ietfa.amsl.com> <24554_1403016065_53A05381_24554_4972_1_9E32478DFA9976438E7A22F69B08FF920215BB@OPEXCLILM34.corporate.adroot.infra.ftgroup> <9D8A1B46-C3AB-4592-810A-2636320697AD@nic.cz> <15719_1403079084_53A149AC_15719_5687_1_9E32478DFA9976438E7A22F69B08FF92021AC0@OPEXCLILM34.corporate.adroot.infra.ftgroup> <20140618083011.GB6055@elstar.local>  <23516_1403165213_53A29A1D_23516_5180_1_9E32478DFA9976438E7A22F69B08FF9202205C@OPEXCLILM34.corporate.adroot.infra.ftgroup>
To: stephane.litkowski@orange.com
X-Mailer: Apple Mail (2.1878.2)
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/R-j2NwElTQCQo-nESWf1M6p3GbE
Cc: "isis-wg@ietf.org list \(isis-wg@ietf.org\)" , "netmod@ietf.org" 
Subject: Re: [netmod] [Isis-wg] FW: New Version Notification for draft-litkowski-netmod-isis-cfg-00.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 19 Jun 2014 12:58:03 -0000

--Apple-Mail=_B5B3E7AC-7841-4E57-ABC9-7880D0FA8980
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_20FCE58C-AA7D-4EB8-A512-61C694E8C77C"


--Apple-Mail=_20FCE58C-AA7D-4EB8-A512-61C694E8C77C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252


On Jun 19, 2014:4:06 AM, at 4:06 AM,  =
 wrote:

> Thanks Alia for the clarification.
> The next update will be renamed with =93isis=94 wg statement.
> =20
> I think it may be valuable to keep some cross-discussions with Netmod =
as YANG expertise is IMO more in Netmod.

	That is definitely the intent here.  The general idea is that =
specific WGs take on the actual model documents and
manage them, but netmod and YangDoctors will help the document authors =
with expert advice in the
design of the module.=20

	--Tom


> =20
> =20
> From: Alia Atlas [mailto:akatlas@gmail.com]=20
> Sent: Wednesday, June 18, 2014 19:27
> To: Juergen Schoenwaelder; LITKOWSKI Stephane SCE/IBNF; Ladislav =
Lhotka; isis-wg@ietf.org list (isis-wg@ietf.org); netmod@ietf.org
> Subject: Re: [netmod] [Isis-wg] FW: New Version Notification for =
draft-litkowski-netmod-isis-cfg-00.txt
> =20
> isis-wg is the right place.
> =20
> Alia
> =20
>=20
> On Wed, Jun 18, 2014 at 4:30 AM, Juergen Schoenwaelder =
 wrote:
> On Wed, Jun 18, 2014 at 08:11:24AM +0000, =
stephane.litkowski@orange.com wrote:
> > Hi Lada,
> >
> > For sure ISIS WG need to be involved, for ownership of the draft, I =
don't really know which WG need to be "owner". Maybe chairs can provide =
their feedback or we could discuss this point in Toronto.
> > I'm would like to present this first version in both WG if possible.
> >
>=20
> As a general principle, I prefer that data models are done in the WGs
> that understand what is being modeled. Hence, this work should ideally
> be done in the ISIS WG.
>=20
> Since I am not following the ISIS WG myself, I ended up looking at the
> WG charter page in order to get a clue what they are working on and
> what I found is that apparently their milestones have not been updated
> since 2009 (and the additional page pointed to in the charter,
> , does not look more recent
> either). So it remains somewhat difficult to judge whether ISIS may be
> able to pick up this work.
>=20
> /js
>=20
> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
> Fax:   +49 421 200 3103         
>=20
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
> =20
> =
__________________________________________________________________________=
_______________________________________________
>=20
> Ce message et ses pieces jointes peuvent contenir des informations =
confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez =
recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les =
messages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, =
deforme ou falsifie. Merci.
>=20
> This message and its attachments may contain confidential or =
privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and =
delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have =
been modified, changed or falsified.
> Thank you.
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


--Apple-Mail=_20FCE58C-AA7D-4EB8-A512-61C694E8C77C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252


On Jun 19, 2014:4:06 AM, at 4:06 AM, =
<stephane.litkowski@orange.co=
m> <stephane.litkowski@orange.co=
m> wrote:

Thanks Alia for the =
clarification.
The next update will be renamed with =93isis=94 wg =
statement.
 
I think it may be valuable to keep some =
cross-discussions with Netmod as YANG expertise is IMO more in =
Netmod.

	That is =
definitely the intent here.  The general idea is that specific WGs =
take on the actual model documents and
manage them, but netmod =
and YangDoctors will help the document authors with expert advice in =
the
design of the module. 

	=
--Tom


 
 
From: Alia Atlas [mailto:akatlas@gmail.com] 
Sent: Wednesday, June 18, 2014 =
19:27
To: Juergen Schoenwaelder; =
LITKOWSKI Stephane SCE/IBNF; Ladislav Lhotka; isis-wg@ietf.org list (isis-wg@ietf.org); netmod@ietf.org
Subject: Re: [netmod] [Isis-wg] FW: =
New Version Notification for =
draft-litkowski-netmod-isis-cfg-00.txt
 
isis-wg is the right place.
 
Alia
 
On Wed, Jun 18, 2014 at 4:30 AM, Juergen =
Schoenwaelder <j.schoenwaelder@jacobs-university.de> =
wrote:
On =
Wed, Jun 18, 2014 at 08:11:24AM +0000, stephane.litkowski@orange.com wrote:
> Hi =
Lada,
>
> For sure ISIS WG need to be involved, for =
ownership of the draft, I don't really know which WG need to be "owner". =
Maybe chairs can provide their feedback or we could discuss this point =
in Toronto.
> I'm would like to present this first version in both =
WG if possible.
>
As a general principle, I prefer that data models are done in =
the WGs
that understand what is being modeled. Hence, this work =
should ideally
be done in the ISIS WG.

Since I am not =
following the ISIS WG myself, I ended up looking at the
WG charter =
page in order to get a clue what they are working on and
what I found =
is that apparently their milestones have not been updated
since 2009 =
(and the additional page pointed to in the charter,
<http://skat.usc.edu/~tli/Schedule.htm>, does not look =
more recent
either). So it remains somewhat difficult to judge =
whether ISIS may be
able to pick up this work.

/js

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

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

Ce message et ses pieces jointes peuvent contenir des informations =
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez =
recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages =
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme =
ou falsifie. Merci.

This message and its attachments may contain confidential or privileged =
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and =
delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have =
been modified, changed or falsified.
Thank you.

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

=

--Apple-Mail=_20FCE58C-AA7D-4EB8-A512-61C694E8C77C--

--Apple-Mail=_B5B3E7AC-7841-4E57-ABC9-7880D0FA8980
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJTot5OAAoJEPcO+I7eiUJZg6MP/1A3PctXPaaev1fm0rS3AdNA
ba8ZqB3X7gkHiZNqs227xUh7izKbtlUHy++Z/XGXeiWayXS787JvJgcJjrekV3gu
GopLdn2tuv9TUWe+GTXTHLleuCW8FKvWzbwl1nCkdFDqtpvWYd70M2XGMAiiqCtQ
Lvrwj0L92YXFyMnNqj63+jPwePz8aGpHBhRiQ2sUey4iRR47OyD6yS54RXIM83vg
1hcl1JcxT+TuXRT5Sau2WnjhZUGhlyFHxCizBuc5KhMdiWhXgNcMr6WxRUGmdqTI
MVEFVyOPlMzObK7saDvfWdx5RoWlXM59BW2hMaHgYrDAXRmG6AF1HABepfj9gmdt
rxiWEEJ2BJaXB53dtjFr+qtVwjR/kLR2mX7qtOHoWrprcXTMaQUjJaCN8F+G+k0O
f1jbdf/Z17OkVZvh11aB1XaDQzxSG63lGenMNfyx8NuPBhBvPxVexng6BLRFKMvz
KKODYPSKmhqTy1sFbdYWv3L7mdq5VpfahcmrVc5OMtaQ6jebY3sBsKzAujltYOyc
01JsJ6WohzrGmPQoBEYnemh15hK1o4OBwdySb/mrh3en902l/aXRDeaw6K8jJXnu
WGLsMHCb64lYVJDW3oLuUEn9aK80Lb19gurgDPMRZ5BEw94uJZnSVbGHOckrLJyd
dvUyRyiG88z2PMCCV548
=nd4e
-----END PGP SIGNATURE-----

--Apple-Mail=_B5B3E7AC-7841-4E57-ABC9-7880D0FA8980--


From nobody Thu Jun 19 06:17:14 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A58CD1A03A0 for ; Thu, 19 Jun 2014 06:17:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.002
X-Spam-Level: 
X-Spam-Status: No, score=-1.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.651] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xT1JBv4ljcBn for ; Thu, 19 Jun 2014 06:17:09 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B6611A01DE for ; Thu, 19 Jun 2014 06:17:09 -0700 (PDT)
Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id D6C3A13F9D0; Thu, 19 Jun 2014 15:17:07 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1403183828; bh=BZAr3KdErfnMZWs/tuUo53XvSdAGPeAnDq3x7b6o6vA=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=QiVJjcskRCjNNgVOaAUMxVaxfKm9jtLnDU4FsFnbu0Pg7txls5MGaGqdRlK7faz2F Odwwn6XCetaRAVj2YY700jiGxMxMyuPU8v/NKuEsp/y72N29crR9SHn4We0i7KbHb/ BAk4fTDE1S1kysxxa2ENpLraIolXOTcSSt50Uq28=
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
From: Ladislav Lhotka 
In-Reply-To: <20140619082336.GC9041@elstar.local>
Date: Thu, 19 Jun 2014 15:17:07 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <2BEAD3C0-615D-4480-98F6-B21CE7A52DC5@nic.cz>
References: <20140617122005.10875.31180.idtracker@ietfa.amsl.com> <24554_1403016065_53A05381_24554_4972_1_9E32478DFA9976438E7A22F69B08FF920215BB@OPEXCLILM34.corporate.adroot.infra.ftgroup> <9D8A1B46-C3AB-4592-810A-2636320697AD@nic.cz> <15719_1403079084_53A149AC_15719_5687_1_9E32478DFA9976438E7A22F69B08FF92021AC0@OPEXCLILM34.corporate.adroot.infra.ftgroup> <20140618083011.GB6055@elstar.local>  <23516_1403165213_53A29A1D_23516_5180_1_9E32478DFA9976438E7A22F69B08FF9202205C@OPEXCLILM34.corporate.adroot.infra.ftgroup> <20140619082336.GC9041@elstar.local>
To: =?windows-1252?Q?J=FCrgen_Sch=F6nw=E4lder?= 
X-Mailer: Apple Mail (2.1878.2)
X-Virus-Scanned: clamav-milter 0.98.1 at mail
X-Virus-Status: Clean
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/A1WW83-ZahQEkarneIoPRvWzWIE
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] [Isis-wg] FW: New Version Notification for draft-litkowski-netmod-isis-cfg-00.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 19 Jun 2014 13:17:11 -0000

On 19 Jun 2014, at 10:23, Juergen Schoenwaelder =
 wrote:

> Hi,
>=20
> it is surely good to keep the NETMOD WG updated about such activities
> going on in other WGs. However, NETMOD is not functioning as a YANG
> review team as stated on the NETMOD charter:
>=20
>  The NETMOD Working Group will not serve as a review team for YANG
>  modules developed by other working groups. The YANG doctors,
>  organized by the OPS area director responsible for network
>  management, can act as advisors for other working groups and they
>  provide YANG reviews for the OPS area directors.
>=20
> Since Lada indicated interest in this work and he is also a YANG
> doctor, I think we are in a pretty good shape (and I am sure that Lada
> will raise any issues that are more fundamental (should they show up)
> when it is appropriate).

I am writing a review of this I-D, concentrating mainly on YANG issues =
and the integration with the core routing model. But I wonder - where =
should I send it? NETMOD or YANG doctors mailing list?

Lada

>=20
> /js
>=20
> On Thu, Jun 19, 2014 at 08:06:53AM +0000, =
stephane.litkowski@orange.com wrote:
>> Thanks Alia for the clarification.
>> The next update will be renamed with =93isis=94 wg statement.
>>=20
>> I think it may be valuable to keep some cross-discussions with Netmod =
as YANG expertise is IMO more in Netmod.
>>=20
>>=20
>> From: Alia Atlas [mailto:akatlas@gmail.com]
>> Sent: Wednesday, June 18, 2014 19:27
>> To: Juergen Schoenwaelder; LITKOWSKI Stephane SCE/IBNF; Ladislav =
Lhotka; isis-wg@ietf.org list (isis-wg@ietf.org); netmod@ietf.org
>> Subject: Re: [netmod] [Isis-wg] FW: New Version Notification for =
draft-litkowski-netmod-isis-cfg-00.txt
>>=20
>> isis-wg is the right place.
>>=20
>> Alia
>>=20
>> On Wed, Jun 18, 2014 at 4:30 AM, Juergen Schoenwaelder =
> wrote:
>> On Wed, Jun 18, 2014 at 08:11:24AM =
+0000,stephane.litkowski@orange.com =
wrote:
>>> Hi Lada,
>>>=20
>>> For sure ISIS WG need to be involved, for ownership of the draft, I =
don't really know which WG need to be "owner". Maybe chairs can provide =
their feedback or we could discuss this point in Toronto.
>>> I'm would like to present this first version in both WG if possible.
>>>=20
>> As a general principle, I prefer that data models are done in the WGs
>> that understand what is being modeled. Hence, this work should =
ideally
>> be done in the ISIS WG.
>>=20
>> Since I am not following the ISIS WG myself, I ended up looking at =
the
>> WG charter page in order to get a clue what they are working on and
>> what I found is that apparently their milestones have not been =
updated
>> since 2009 (and the additional page pointed to in the charter,
>> , does not look more recent
>> either). So it remains somewhat difficult to judge whether ISIS may =
be
>> able to pick up this work.
>>=20
>> /js
>>=20
>> --
>> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
>> Phone: +49 421 200 3587         Campus =
Ring 1, 28759 Bremen, Germany
>> Fax:   +49 421 200 3103         =

>>=20
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>>=20
>>=20
>> =
__________________________________________________________________________=
_______________________________________________
>>=20
>> Ce message et ses pieces jointes peuvent contenir des informations =
confidentielles ou privilegiees et ne doivent donc
>> pas etre diffuses, exploites ou copies sans autorisation. Si vous =
avez recu ce message par erreur, veuillez le signaler
>> a l'expediteur et le detruire ainsi que les pieces jointes. Les =
messages electroniques etant susceptibles d'alteration,
>> Orange decline toute responsabilite si ce message a ete altere, =
deforme ou falsifie. Merci.
>>=20
>> This message and its attachments may contain confidential or =
privileged information that may be protected by law;
>> they should not be distributed, used or copied without authorisation.
>> If you have received this email in error, please notify the sender =
and delete this message and its attachments.
>> As emails may be altered, Orange is not liable for messages that have =
been modified, changed or falsified.
>> Thank you.
>>=20
>=20
> --=20
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
> Fax:   +49 421 200 3103         

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





From nobody Thu Jun 19 07:34:34 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 156D91A0278 for ; Thu, 19 Jun 2014 07:34:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.3
X-Spam-Level: 
X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_44=0.6] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SgjHc_k58Dvh for ; Thu, 19 Jun 2014 07:34:31 -0700 (PDT)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D73BD1A0213 for ; Thu, 19 Jun 2014 07:34:30 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id BFE2854073B; Thu, 19 Jun 2014 16:34:28 +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 pTN999smBJJb; Thu, 19 Jun 2014 16:34:24 +0200 (CEST)
Received: from localhost (unknown [172.29.2.202]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id C45665403EC; Thu, 19 Jun 2014 16:34:23 +0200 (CEST)
From: Ladislav Lhotka 
To: netmod@ietf.org, stephane.litkowski@orange.com
User-Agent: Notmuch/0.18 (http://notmuchmail.org) Emacs/24.3.50.2 (x86_64-apple-darwin13.0.0)
Date: Thu, 19 Jun 2014 16:34:22 +0200
Message-ID: 
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=-=-="
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/KHMvKaWeg-JBeqQVLFxUUCrOLLM
Subject: [netmod] review of draft-litkowski-netmod-isis-cfg-00
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 19 Jun 2014 14:34:33 -0000

--=-=-=
Content-Type: text/plain

Hi,

I reviewed the isis module and I-D. I think it is a good start, although some adjustments will be needed to make it work with the core routing data model, see below. I don't address any specific issues of IS-IS configuration.

*** General Comments
    - As Andy already pointed out, descriptions are often missing or
      too brief, and the prose in the I-D is also extremely scarce.
    - An example instance document would be useful, e.g. a reply to
       as in Appendix A of RFC 7277. (The "sample-skeleton"
      plugin of pyang can help with generating it.)  

*** YANG module design
    - Entries of the "rt:routing-protocol" list (under both "routing"
      and "routing-state") are designed to support multiple instances
      of the same protocol. In configuration it means not only that
      the nodes "isis-cfg", "instances" and "instance" are
      superfluous, but this design also prevents connecting different
      ISIS instances to different RIBs.
    - Similarly, state data for each ISIS instance should go straight
      to the corresponding entry of "routing-protocol" under
      "routing-state".
    - Nodes in state data should use descriptive names rather than
      "TLVnnn". TLV numbers are important for the protocol but IMO
      there is no need to expose operators to them. For instance,
      "dynamic-hostname" is better than "TLV137".
    - Grouping "interface-cfg" is used only once, so it is not
      needed. Other groupings are used at least twice.
    - A type definition for ISO addresses might be useful.

*** Specific YANG issues
    - The module is invalid, I am attaching a diff file with
      necessary changes. Module validity should always be verified
      before posting an I-D, e.g. with pyang.
    - The argument of "namespace" should be an URI, e.g. urn:TBD.
    - Arguments of some "augment" statements are broken, see the
      attached diff. In particular, they must not contain trailing
      slashes, see ABNF production "absolute-schema-nodeid".
    - The module should follow the guidelines of RFC 6087, they can
      be checked using

      pyang --ietf isis.yang

*** Formal issues
    - The module text should be wrapped in

       file "isis@2014-XX-XX.yang"
      ...
      

      so that it can be easily extracted with rfcstrip. 
    - Assuming the module is bound for standard track, its name
      should be "ietf-isis".
    - Some descriptions exceed the line length limit of 72 characters,
      line breaks should be inserted.

Lada

--=-=-=
Content-Type: text/x-patch
Content-Disposition: attachment; filename=isis.yang.diff
Content-Description: Changes needed for validity

--- isis.yang.orig	2014-06-19 10:34:44.000000000 +0200
+++ isis.yang	2014-06-19 10:46:31.000000000 +0200
@@ -1,5 +1,5 @@
 module isis {
-    namespace TBD;
+    namespace "urn:TBD";
 
     prefix isis;
 
@@ -73,14 +73,14 @@
         }
     }
 
-    augment "/rt:routing/rt:routing-state/rt:ribs/rt:rib/rt:routes/rt:route" {
+    augment "/rt:routing-state/rt:ribs/rt:rib/rt:routes/rt:route" {
         when "rt:source-protocol = 'isis:isis'" {
             description "ISIS-specific route attributes.";
         }
         uses isis-route-content;
       }
 
-    augment "/rt:active-route/rt:output/rt:route/"
+    augment "/rt:active-route/rt:output/rt:route"
        {
         description "ISIS-specific route attributes.";
         uses isis-route-content;
@@ -406,7 +406,7 @@
         description "ISIS is enabled on interfaces that have an entry in this list, unless 'enabled' is set to 'false' for that entry.";
         leaf name {
             type leafref {
-                path "/rt:routing/rt:router/rt:interfaces/rt:interfaces/rt:interface/rt:name";
+                path "/rt:routing/rt:routing-instance/rt:interfaces/rt:interface/rt:name";
             }
         }
         leaf level {
@@ -529,7 +529,7 @@
         }
     }
 
-    augment "/rt:routing/rt:routing-instance/rt:routing-protocols/rt:routing-protocol/" {
+    augment "/rt:routing/rt:routing-instance/rt:routing-protocols/rt:routing-protocol" {
         when "rt:type = 'isis:isis'" {
             description "This augment is only valid when routing protocol instance type is isis.";
         }

--=-=-=
Content-Type: text/plain


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

--=-=-=--


From nobody Thu Jun 19 09:35:45 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EA351A03E2; Thu, 19 Jun 2014 09:35:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eCJvTWxHd0gD; Thu, 19 Jun 2014 09:35:40 -0700 (PDT)
Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1lp0012.outbound.protection.outlook.com [213.199.154.12]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 738DD1A02B2; Thu, 19 Jun 2014 09:35:38 -0700 (PDT)
Received: from AMXPRD0310HT001.eurprd03.prod.outlook.com (157.56.248.133) by AMXPR07MB053.eurprd07.prod.outlook.com (10.242.67.142) with Microsoft SMTP Server (TLS) id 15.0.969.15; Thu, 19 Jun 2014 16:35:36 +0000
Message-ID: <00a001cf8bdc$0bdc80e0$4001a8c0@gateway.2wire.net>
From: t.petch 
To: Alia Atlas , Juergen Schoenwaelder , Stephane Litkowski , Ladislav Lhotka , , 
References: <20140617122005.10875.31180.idtracker@ietfa.amsl.com> <24554_1403016065_53A05381_24554_4972_1_9E32478DFA9976438E7A22F69B08FF920215BB@OPEXCLILM34.corporate.adroot.infra.ftgroup> <9D8A1B46-C3AB-4592-810A-2636320697AD@nic.cz> <15719_1403079084_53A149AC_15719_5687_1_9E32478DFA9976438E7A22F69B08FF92021AC0@OPEXCLILM34.corporate.adroot.infra.ftgroup> <20140618083011.GB6055@elstar.local> 
Date: Thu, 19 Jun 2014 17:31:24 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Originating-IP: [157.56.248.133]
X-ClientProxiedBy: DB3PR07CA009.eurprd07.prod.outlook.com (10.242.134.49) To AMXPR07MB053.eurprd07.prod.outlook.com (10.242.67.142)
X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:
X-Forefront-PRVS: 02475B2A01
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(6009001)(428001)(51444003)(24454002)(377454003)(199002)(189002)(13464003)(51704005)(89996001)(88136002)(83072002)(85852003)(105586002)(79102001)(74662001)(31966008)(80022001)(47776003)(44736004)(50226001)(20776003)(64706001)(4396001)(95666004)(102836001)(50466002)(62966002)(77982001)(99396002)(87286001)(87976001)(81342001)(66066001)(81542001)(62236002)(44716002)(85306003)(50986999)(77096002)(93886003)(61296003)(81686999)(81816999)(42186005)(77156001)(21056001)(76176999)(104166001)(101416001)(84392001)(33646001)(93916002)(23676002)(76482001)(92566001)(86362001)(92726001)(14496001)(46102001)(2201001)(19580405001)(19580395003)(74502001)(15975445006)(83322001)(74416001)(7726001); DIR:OUT; SFP:; SCL:1; SRVR:AMXPR07MB053; H:AMXPRD0310HT001.eurprd03.prod.outlook.com; FPR:; MLV:nov; PTR:InfoNoRecords;  A:0; MX:1; LANG:en; 
Received-SPF: None (: btconnect.com does not designate permitted sender hosts)
Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; 
X-OriginatorOrg: btconnect.com
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/b3Ow3jodliyZAr23ePz46wcOeI0
Subject: Re: [netmod] [Isis-wg] FW: New Version Notification for draft-litkowski-netmod-isis-cfg-00.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 19 Jun 2014 16:35:43 -0000

----- Original Message -----
From: "Alia Atlas" 
Sent: Wednesday, June 18, 2014 6:26 PM

> isis-wg is the right place.

Alia

In a year or two, I expect that I would agree with you but right now,
the netmod WG has only just produced the basic models and in doing so,
found the need for some necessary modifications to YANG; and, in the
past 18 months, radically changed (IMO) the layout of most modules, to
the twin trees, cfg and state approach.

Give a year or two's experience of writing modules and there will
doubtless be guidelines on what to do and what not to do, but right now,
I think that the active involvement of the netmod group is essential.

I propose a three part approach; start in netmod to get the current
thinking of how to tackle common problems (the sort of things that Lada
has addressed although I disagree with him over the use of TLV - that is
how isis does things:-)

Then move to isis to get technicalities of the protocol correct, what to
model, what is config, defaults, etc

Then back to netmod to see that it still aligns with netmod best
practice (which likely will have moved on)

Tom Petch

> Alia
>
>
> On Wed, Jun 18, 2014 at 4:30 AM, Juergen Schoenwaelder <
> j.schoenwaelder@jacobs-university.de> wrote:
>
> > On Wed, Jun 18, 2014 at 08:11:24AM +0000,
stephane.litkowski@orange.com
> > wrote:
> > > Hi Lada,
> > >
> > > For sure ISIS WG need to be involved, for ownership of the draft,
I
> > don't really know which WG need to be "owner". Maybe chairs can
provide
> > their feedback or we could discuss this point in Toronto.
> > > I'm would like to present this first version in both WG if
possible.
> > >
> >
> > As a general principle, I prefer that data models are done in the
WGs
> > that understand what is being modeled. Hence, this work should
ideally
> > be done in the ISIS WG.
> >
> > Since I am not following the ISIS WG myself, I ended up looking at
the
> > WG charter page in order to get a clue what they are working on and
> > what I found is that apparently their milestones have not been
updated
> > since 2009 (and the additional page pointed to in the charter,
> > , does not look more recent
> > either). So it remains somewhat difficult to judge whether ISIS may
be
> > able to pick up this work.
> >
> > /js
> >
> > --
> > Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> > Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
> > Fax:   +49 421 200 3103         
> >
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> >
>


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


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


From nobody Thu Jun 19 10:06:28 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 398791A02A4 for ; Thu, 19 Jun 2014 10:06:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.378
X-Spam-Level: 
X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21zaDo-n0KmK for ; Thu, 19 Jun 2014 10:06:24 -0700 (PDT)
Received: from mail-qa0-f46.google.com (mail-qa0-f46.google.com [209.85.216.46]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F2881A006E for ; Thu, 19 Jun 2014 10:06:24 -0700 (PDT)
Received: by mail-qa0-f46.google.com with SMTP id i13so2155970qae.19 for ; Thu, 19 Jun 2014 10:06:23 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=c9and1lAUlPS0VIiYv8aV7s5+y8I8I+ucnrHCynOI5Q=; b=SNzHIThtvErm9QFPWMIsCZbDUne8gaqKJ3yOCFVPOaV+1n9uJhVRh6VGv1qTGOGGOx ItnUuYhtplAa5q10bFsQIKxHGoZWVVxr9s0clrbnDBDLzF/Sz5N2fDNAmBqN7rF93kTy bxl9TpNRJKVQ3KC350B7B5TbHa6F5AecaFdfkyhYA1FOZINlqj24xbdZBep7uqiyF8Jr MMlwaVyE2Ykq3oN/N+LfCmxoHmbqb6MafZLTLKdFFmaKgPVRQ7eDafdYnJ0MCnkA+9f9 huBLo8ZFGsZw8iJJ0SNyQH7y2I78+fCz1SOrCV8KEfhl2LaJPw+TDiTtzxm78TzzPBqq 2spQ==
X-Gm-Message-State: ALoCoQlQvZEAzfPI5lXbTS1nn5ej08ngel3cerQ2p2M0hYnb8pjFi40r09u5uWYKpnQdFFUd2/4p
MIME-Version: 1.0
X-Received: by 10.140.27.23 with SMTP id 23mr8461392qgw.94.1403197583058; Thu, 19 Jun 2014 10:06:23 -0700 (PDT)
Received: by 10.140.104.48 with HTTP; Thu, 19 Jun 2014 10:06:22 -0700 (PDT)
In-Reply-To: <00a001cf8bdc$0bdc80e0$4001a8c0@gateway.2wire.net>
References: <20140617122005.10875.31180.idtracker@ietfa.amsl.com> <24554_1403016065_53A05381_24554_4972_1_9E32478DFA9976438E7A22F69B08FF920215BB@OPEXCLILM34.corporate.adroot.infra.ftgroup> <9D8A1B46-C3AB-4592-810A-2636320697AD@nic.cz> <15719_1403079084_53A149AC_15719_5687_1_9E32478DFA9976438E7A22F69B08FF92021AC0@OPEXCLILM34.corporate.adroot.infra.ftgroup> <20140618083011.GB6055@elstar.local>  <00a001cf8bdc$0bdc80e0$4001a8c0@gateway.2wire.net>
Date: Thu, 19 Jun 2014 10:06:22 -0700
Message-ID: 
From: Andy Bierman 
To: "t.petch" 
Content-Type: multipart/alternative; boundary=001a11c14a7c7d3cd004fc33656e
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/so4xslpcw7bvht_fxfThYvBcFQ4
Cc: "isis-wg@ietf.org list \(isis-wg@ietf.org\)" , "netmod@ietf.org" 
Subject: Re: [netmod] [Isis-wg] FW: New Version Notification for draft-litkowski-netmod-isis-cfg-00.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 19 Jun 2014 17:06:27 -0000

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

On Thu, Jun 19, 2014 at 9:31 AM, t.petch  wrote:

>
> ----- Original Message -----
> From: "Alia Atlas" 
> Sent: Wednesday, June 18, 2014 6:26 PM
>
> > isis-wg is the right place.
>
> Alia
>
> In a year or two, I expect that I would agree with you but right now,
> the netmod WG has only just produced the basic models and in doing so,
> found the need for some necessary modifications to YANG; and, in the
> past 18 months, radically changed (IMO) the layout of most modules, to
> the twin trees, cfg and state approach.
>
> Give a year or two's experience of writing modules and there will
> doubtless be guidelines on what to do and what not to do, but right now,
> I think that the active involvement of the netmod group is essential.
>
>
I do not see config vs. operational subtrees as a major architecture change.
The expansion of functionality needs to be done with clue. Supporting
pre-provisioning and protocol controlled operational state may require
a separate tree, depending on the data model. IMO this should not a generic
solution.

The guidelines are bound to change the more standard functionality we addl
This should not slow down WGs using the existing functionality.



> I propose a three part approach; start in netmod to get the current
> thinking of how to tackle common problems (the sort of things that Lada
> has addressed although I disagree with him over the use of TLV - that is
> how isis does things:-)
>
>
The problem with this approach is that the NETMOD WG is a "plain old" WG,
with a charter to produce YANG 1.1 and other documents.  It is not chartered
to be the YANG Help Desk for the IETF. That is YANG Doctors' job.

It does not really scale well either (as we have seen from several YANG
proposals
that are waiting years to get chartered). NETMOD is already a bottleneck.
IMO, NETMOD should work on YANG 1.1, YANG Conformance,
and YANG Usage Guidelines.  It is time for domain-specific WGs to
work on YANG modules for their protocols.



Then move to isis to get technicalities of the protocol correct, what to
> model, what is config, defaults, etc
>
>
A YANG Doctor (Lada) will help the isis WG.
The proper YANG usage is actually much easier to achieve than agreeing
on the exact text of every single protocol knob (by a mile),.
The protocol experts pay attention to the protocol WGs, not NETMOD.
Their review is easily missed if all YANG work is done in NETMOD.


Then back to netmod to see that it still aligns with netmod best
> practice (which likely will have moved on)
>
>
This will happen as part of the AD review process.
I don't think YANG best practices are changing so rapidly that rewrites
will be required.
We will see wrt/ I2RS and YANG 1.1, but that should not affect any WG that
wants to standardize YANG configuration data models with YANG 1.0.




> Tom Petch
>
>

Andy



> > Alia
> >
> >
> > On Wed, Jun 18, 2014 at 4:30 AM, Juergen Schoenwaelder <
> > j.schoenwaelder@jacobs-university.de> wrote:
> >
> > > On Wed, Jun 18, 2014 at 08:11:24AM +0000,
> stephane.litkowski@orange.com
> > > wrote:
> > > > Hi Lada,
> > > >
> > > > For sure ISIS WG need to be involved, for ownership of the draft,
> I
> > > don't really know which WG need to be "owner". Maybe chairs can
> provide
> > > their feedback or we could discuss this point in Toronto.
> > > > I'm would like to present this first version in both WG if
> possible.
> > > >
> > >
> > > As a general principle, I prefer that data models are done in the
> WGs
> > > that understand what is being modeled. Hence, this work should
> ideally
> > > be done in the ISIS WG.
> > >
> > > Since I am not following the ISIS WG myself, I ended up looking at
> the
> > > WG charter page in order to get a clue what they are working on and
> > > what I found is that apparently their milestones have not been
> updated
> > > since 2009 (and the additional page pointed to in the charter,
> > > , does not look more recent
> > > either). So it remains somewhat difficult to judge whether ISIS may
> be
> > > able to pick up this work.
> > >
> > > /js
> > >
> > > --
> > > Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> > > Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
> > > Fax:   +49 421 200 3103         
> > >
> > > _______________________________________________
> > > netmod mailing list
> > > netmod@ietf.org
> > > https://www.ietf.org/mailman/listinfo/netmod
> > >
> >
>
>
> ------------------------------------------------------------------------
> --------
>
>
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> >
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>

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





On Thu, Jun 19, 2014 at 9:31 AM, t.petch <ietfc@btconnect.com> wrote:




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

From: "Alia Atlas" <akatl=
as@gmail.com>

Sent: Wednesday, June 18, 2014 6:26 PM



> isis-wg is the right place.



Alia



In a year or two, I expect that I would agree with you but right now,

the netmod WG has only just produced the basic models and in doing so,

found the need for some necessary modifications to YANG; and, in the

past 18 months, radically changed (IMO) the layout of most modules, to

the twin trees, cfg and state approach.



Give a year or two's experience of writing modules and there will

doubtless be guidelines on what to do and what not to do, but right now,
I think that the active involvement of the netmod group is essential.



I do not see config vs. operational su=
btrees as a major architecture change.
The expansion of functiona=
lity needs to be done with clue. Supporting
pre-provisioning and =
protocol controlled operational state may require


a separate tree, depending on the data model. IMO this should not a ge=
neric
solution.

The guidelines are bound=
 to change the more standard functionality we addl
This should no=
t slow down WGs using the existing functionality.



=A0

I propose a three part approach; start in netmod to get the current

thinking of how to tackle common problems (the sort of things that Lada

has addressed although I disagree with him over the use of TLV - that is
how isis does things:-)



The problem with this approach is that=
 the NETMOD WG is a "plain old" WG,
with a charter to p=
roduce YANG 1.1 and other documents. =A0It is not chartered
to be=
 the YANG Help Desk for the IETF. That is YANG Doctors' job.



It does not really scale well either (as we have seen f=
rom several YANG proposals
that are waiting years to get chartere=
d). NETMOD is already a bottleneck.
IMO, NETMOD should work on YA=
NG 1.1, YANG Conformance,


and YANG Usage Guidelines. =A0It is time for domain-specific WGs to
work on YANG modules for their protocols.

=




Then move to isis to get technicalities of the protocol correct, what to
model, what is config, defaults, etc



A YANG Doctor (Lada) will help the isi=
s WG.
The proper YANG usage is actually much easier to achieve th=
an agreeing
on the exact text of every single protocol knob (by a=
 mile),.


The protocol experts pay attention to the protocol WGs, not NETMOD.
Their review is easily missed if all YANG work is done in NETMOD.




Then back to netmod to see that it still aligns with netmod best

practice (which likely will have moved on)



This will happen as part of the AD rev=
iew process.
I don't think YANG best practices are changing s=
o rapidly that rewrites will be required.
We will see wrt/ I2RS a=
nd YANG 1.1, but that should not affect any WG that


wants to standardize YANG configuration data models with YANG 1.0.


=A0


Tom Petch




Andy

=A0


> Alia

>

>

> On Wed, Jun 18, 2014 at 4:30 AM, Juergen Schoenwaelder <

> j.schoenwaelde=
r@jacobs-university.de> wrote:

>

> > On Wed, Jun 18, 2014 at 08:11:24AM +0000,

stephane.litkowski@orange.=
com

> > wrote:

> > > Hi Lada,

> > >

> > > For sure ISIS WG need to be involved, for ownership of the d=
raft,

I

> > don't really know which WG need to be "owner". Mayb=
e chairs can

provide

> > their feedback or we could discuss this point in Toronto.

> > > I'm would like to present this first version in both WG =
if

possible.

> > >

> >

> > As a general principle, I prefer that data models are done in the=


WGs

> > that understand what is being modeled. Hence, this work should
ideally

> > be done in the ISIS WG.

> >

> > Since I am not following the ISIS WG myself, I ended up looking a=
t

the

> > WG charter page in order to get a clue what they are working on a=
nd

> > what I found is that apparently their milestones have not been
updated

> > since 2009 (and the additional page pointed to in the charter,
> > <http://skat.usc.edu/~tli/Schedule.htm>, does not look more re=
cent

> > either). So it remains somewhat difficult to judge whether ISIS m=
ay

be

> > able to pick up this work.

> >

> > /js

> >

> > --

> > Juergen Schoenwaelder =A0 =A0 =A0 =A0 =A0 Jacobs University Breme=
n gGmbH

> > Phone: +49 421 200 3587 =A0 =A0 =A0 =A0 Campus Ring 1, 28759 Brem=
en, Germany

> > Fax: =A0 +49 421 200 3103 =A0 =A0 =A0 =A0 <http://www.jacobs-university.de=
/>

> >

> > _______________________________________________

> > netmod mailing list

> > netmod@ietf.org

> > https://www.ietf.org/mailman/listinfo/netmod

> >

>





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





> _______________________________________________

> 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





--001a11c14a7c7d3cd004fc33656e--


From nobody Thu Jun 19 11:28:54 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6D831A0291 for ; Thu, 19 Jun 2014 11:28:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kw2rHU03LIds for ; Thu, 19 Jun 2014 11:28:49 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0185.outbound.protection.outlook.com [207.46.163.185]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C37BD1A025A for ; Thu, 19 Jun 2014 11:28:48 -0700 (PDT)
Received: from BY2PR05MB079.namprd05.prod.outlook.com (10.242.38.16) by BLUPR05MB417.namprd05.prod.outlook.com (10.141.27.15) with Microsoft SMTP Server (TLS) id 15.0.954.9; Thu, 19 Jun 2014 18:28:46 +0000
Received: from BY2PR05MB079.namprd05.prod.outlook.com ([169.254.8.252]) by BY2PR05MB079.namprd05.prod.outlook.com ([169.254.8.206]) with mapi id 15.00.0949.001; Thu, 19 Jun 2014 18:28:44 +0000
From: "Jeffrey (Zhaohui) Zhang" 
To: "lhotka@nic.cz" , Dean Bogdanovic , "netmod@ietf.org" 
Thread-Topic: Questions/comments on draft-ietf-netmod-routing-cfg
Thread-Index: Ac+L5mG6QCip6E9wRnWAlQy1vx1Ydg==
Date: Thu, 19 Jun 2014 18:28:41 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [66.129.241.12]
x-microsoft-antispam: BL:0; ACTION:Default; RISK:Low; SCL:0; SPMLVL:NotSpam; PCL:0; RULEID:
x-forefront-prvs: 02475B2A01
x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(428001)(25584003)(199002)(189002)(77096002)(85306003)(76482001)(105586002)(87936001)(99286002)(2656002)(81542001)(81342001)(77982001)(21056001)(95666004)(46102001)(79102001)(4396001)(83322001)(99396002)(83072002)(20776003)(64706001)(66066001)(80022001)(85852003)(50986999)(101416001)(33646001)(74662001)(54356999)(31966008)(74502001)(76576001)(74316001)(86362001)(92566001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR05MB417; H:BY2PR05MB079.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; 
received-spf: None (: juniper.net does not designate permitted sender hosts)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=zzhang@juniper.net; 
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/m4OhZQ_WGn5p9LeEHPqKBW7qKqU
Cc: Kiran Agrahara Sreenivasa 
Subject: [netmod] Questions/comments on draft-ietf-netmod-routing-cfg
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 19 Jun 2014 18:28:51 -0000

Ladislav,

Dean and I have some late questions and comments. We came across these whil=
e trying to work on the OSPF YANG model.

-----------

The spec mentions in several places something like the following:

=A0=A0 Each routing protocol instance is connected to exactly one RIB for
=A0=A0 each address family that the routing protocol instance supports.

My understanding is that the address family mentioned above does not includ=
e SAFI. Because of that, a routing protocol like BGP may connect to multipl=
e RIBs in the same family (RIB for unicast and RIB for multicast RPF purpos=
e in case of incongruent multicast topology) so the above statement is not =
correct.

This is also a problem in case of Multi-topology. Each topology has its own=
 RIB and a protocol instance like OSPF can connect to multiple MT RIBs.

------

5.1.  Routing Instance

   Each routing instance in the core routing data model represents a
   logical router.  The exact semantics of this term are left to
   implementations.  For example, routing instances may be completely
   isolated virtual routers or, alternatively, they may internally share
   certain information.

   ...

   An implementation MAY support multiple types of logical routers
   simultaneously.  Instances of all routing instance types are
   organized as entries of the same flat "routing-instance" list.  In
   order to discriminate routing instances belonging to different types,
   the "type" leaf is defined as a child of the "routing-instance" node.

The spec purposely left it fuzzy as to what a "routing instance" is. Howeve=
r we definitely should have clear definitions for the three terms mentioned=
: routing-instance, logical router and virtual router.

Logical router is a very overload term. Today vendors have virtualized thei=
r routing capabilities in the system and provide 3 different levels of rout=
ing virtualization. Logical systems, logical routers are some of the names =
used by vendors and those offer routing and management separation. Each log=
ical system has its own routing instances and routing instances can have mu=
ltiple routing tables, so it is very important to have very precise definit=
ion of what is routing instance (and not compare it with logical router)

=A0=A0=A0=A0 identity standard-routing-instance {
=A0=A0=A0=A0=A0=A0 base routing-instance-type;
=A0=A0=A0=A0=A0=A0 description
=A0=A0=A0=A0=A0=A0=A0=A0 "This identity represents a default routing instan=
ce.";
=A0=A0=A0=A0 }

What is a "standard-routing-instance"? Would "default-routing-instance" be =
better? "standard" wording leads to "standard vs. non-standard" question an=
d hints on that the two are different types. "default" vs. "non-default" do=
es not have that (at least to me).

Should this spec distinguish VRF/VR/LR and have corresponding identities de=
fined?

=A0=A0=A0=A0=A0=A0=A0=A0 leaf type {
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 type identityref {
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 base routing-instance-type;
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 }
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 description
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 "The routing instance type, primarily =
intended for
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 discriminating among different type=
s of logical routers,
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 route virtualization, master-slave =
arrangements etc.,
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 while keeping all routing instances=
 in the same flat
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 list.";
=A0=A0=A0=A0=A0=A0=A0=A0 }

What is the "master-slave arrangements"?

Depending on the definition of "logical router" and "route virtualization",=
 there may also be concerns with keeping all those kinds of in the same fla=
t list.

Jeffrey Zhang
Dean Bogdanovic


From nobody Thu Jun 19 12:55:52 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C4CC1A02FA; Thu, 19 Jun 2014 12:55:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.399
X-Spam-Level: 
X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KAnH8B6GNllW; Thu, 19 Jun 2014 12:55:47 -0700 (PDT)
Received: from mail-yh0-x234.google.com (mail-yh0-x234.google.com [IPv6:2607:f8b0:4002:c01::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 325F91A0302; Thu, 19 Jun 2014 12:55:47 -0700 (PDT)
Received: by mail-yh0-f52.google.com with SMTP id a41so2111172yho.11 for ; Thu, 19 Jun 2014 12:55:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/0p7tGwB1K7AFsxmsvy9Zq+rWBKwx/n/5g+oRB/S9gI=; b=S6AGVueHL8GgEGiOSNwGDv4x2BHmJo20o0YogO6cBqBRohFOfCLHymCZxlOyJ2MpMJ Q3WWPoH3r1eXJAqJkwXBB4AWqHQotXmaP+dHOZ+VW0JY5nOCgUIlPJvZ7CQoD0WluPsa QtSYS1eZ16dIlm5W8Yp8g9+CPC/hkRGkc+pC84KDLs/AW2kFOSDm9siHiE0hBOd/Wzi8 SENveaq+xldEoA+2GberYt3OYKSwrVokGUGr4yrnZK+Kse/s/aJasVRiX7ZKMpOImZZU 5PtzfZb0vJx0zBqqNpyc5H4WSn1bI3aklHg52GljpG5qvsa1h5yfdexXXbF6Q3h+HW1H DuZQ==
MIME-Version: 1.0
X-Received: by 10.236.103.135 with SMTP id f7mr11132355yhg.102.1403207746421;  Thu, 19 Jun 2014 12:55:46 -0700 (PDT)
Received: by 10.170.58.10 with HTTP; Thu, 19 Jun 2014 12:55:46 -0700 (PDT)
In-Reply-To: 
References: <20140617122005.10875.31180.idtracker@ietfa.amsl.com> <24554_1403016065_53A05381_24554_4972_1_9E32478DFA9976438E7A22F69B08FF920215BB@OPEXCLILM34.corporate.adroot.infra.ftgroup> <9D8A1B46-C3AB-4592-810A-2636320697AD@nic.cz> <15719_1403079084_53A149AC_15719_5687_1_9E32478DFA9976438E7A22F69B08FF92021AC0@OPEXCLILM34.corporate.adroot.infra.ftgroup> <20140618083011.GB6055@elstar.local>  <00a001cf8bdc$0bdc80e0$4001a8c0@gateway.2wire.net> 
Date: Thu, 19 Jun 2014 15:55:46 -0400
Message-ID: 
From: Alia Atlas 
To: Andy Bierman 
Content-Type: multipart/alternative; boundary=001a11332a2e458ad704fc35c3f8
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/hxuDVkgUyldbrgVVHdZUorhgkmI
Cc: "isis-wg@ietf.org list \(isis-wg@ietf.org\)" , "netmod@ietf.org" 
Subject: Re: [netmod] [Isis-wg] FW: New Version Notification for draft-litkowski-netmod-isis-cfg-00.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 19 Jun 2014 19:55:50 -0000

--001a11332a2e458ad704fc35c3f8
Content-Type: text/plain; charset=UTF-8

Tom,

I agree with Andy.  Benoit and I have spoken about the best plan to enable
good fast YANG models and it is critical
to have the subject matter experts working on it and getting the structure
and knobs right.  That is where a lot of the
work is.  The hope is that YANG-doctors will provide the necessary advice.

If it proves too hard and that only specific experts in YANG can write good
useful models, that'll be a problem for the technology.

Alia


On Thu, Jun 19, 2014 at 1:06 PM, Andy Bierman  wrote:

>
>
>
> On Thu, Jun 19, 2014 at 9:31 AM, t.petch  wrote:
>
>>
>> ----- Original Message -----
>> From: "Alia Atlas" 
>> Sent: Wednesday, June 18, 2014 6:26 PM
>>
>> > isis-wg is the right place.
>>
>> Alia
>>
>> In a year or two, I expect that I would agree with you but right now,
>> the netmod WG has only just produced the basic models and in doing so,
>> found the need for some necessary modifications to YANG; and, in the
>> past 18 months, radically changed (IMO) the layout of most modules, to
>> the twin trees, cfg and state approach.
>>
>> Give a year or two's experience of writing modules and there will
>> doubtless be guidelines on what to do and what not to do, but right now,
>> I think that the active involvement of the netmod group is essential.
>>
>>
> I do not see config vs. operational subtrees as a major architecture
> change.
> The expansion of functionality needs to be done with clue. Supporting
> pre-provisioning and protocol controlled operational state may require
> a separate tree, depending on the data model. IMO this should not a generic
> solution.
>
> The guidelines are bound to change the more standard functionality we addl
> This should not slow down WGs using the existing functionality.
>
>
>
>> I propose a three part approach; start in netmod to get the current
>> thinking of how to tackle common problems (the sort of things that Lada
>> has addressed although I disagree with him over the use of TLV - that is
>> how isis does things:-)
>>
>>
> The problem with this approach is that the NETMOD WG is a "plain old" WG,
> with a charter to produce YANG 1.1 and other documents.  It is not
> chartered
> to be the YANG Help Desk for the IETF. That is YANG Doctors' job.
>
> It does not really scale well either (as we have seen from several YANG
> proposals
> that are waiting years to get chartered). NETMOD is already a bottleneck.
> IMO, NETMOD should work on YANG 1.1, YANG Conformance,
> and YANG Usage Guidelines.  It is time for domain-specific WGs to
> work on YANG modules for their protocols.
>
>
>
> Then move to isis to get technicalities of the protocol correct, what to
>> model, what is config, defaults, etc
>>
>>
> A YANG Doctor (Lada) will help the isis WG.
> The proper YANG usage is actually much easier to achieve than agreeing
> on the exact text of every single protocol knob (by a mile),.
> The protocol experts pay attention to the protocol WGs, not NETMOD.
> Their review is easily missed if all YANG work is done in NETMOD.
>
>
> Then back to netmod to see that it still aligns with netmod best
>> practice (which likely will have moved on)
>>
>>
> This will happen as part of the AD review process.
> I don't think YANG best practices are changing so rapidly that rewrites
> will be required.
> We will see wrt/ I2RS and YANG 1.1, but that should not affect any WG that
> wants to standardize YANG configuration data models with YANG 1.0.
>
>
>
>
>> Tom Petch
>>
>>
>
> Andy
>
>
>
>> > Alia
>> >
>> >
>> > On Wed, Jun 18, 2014 at 4:30 AM, Juergen Schoenwaelder <
>> > j.schoenwaelder@jacobs-university.de> wrote:
>> >
>> > > On Wed, Jun 18, 2014 at 08:11:24AM +0000,
>> stephane.litkowski@orange.com
>> > > wrote:
>> > > > Hi Lada,
>> > > >
>> > > > For sure ISIS WG need to be involved, for ownership of the draft,
>> I
>> > > don't really know which WG need to be "owner". Maybe chairs can
>> provide
>> > > their feedback or we could discuss this point in Toronto.
>> > > > I'm would like to present this first version in both WG if
>> possible.
>> > > >
>> > >
>> > > As a general principle, I prefer that data models are done in the
>> WGs
>> > > that understand what is being modeled. Hence, this work should
>> ideally
>> > > be done in the ISIS WG.
>> > >
>> > > Since I am not following the ISIS WG myself, I ended up looking at
>> the
>> > > WG charter page in order to get a clue what they are working on and
>> > > what I found is that apparently their milestones have not been
>> updated
>> > > since 2009 (and the additional page pointed to in the charter,
>> > > , does not look more recent
>> > > either). So it remains somewhat difficult to judge whether ISIS may
>> be
>> > > able to pick up this work.
>> > >
>> > > /js
>> > >
>> > > --
>> > > Juergen Schoenwaelder           Jacobs University Bremen gGmbH
>> > > Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
>> > > Fax:   +49 421 200 3103         
>> > >
>> > > _______________________________________________
>> > > netmod mailing list
>> > > netmod@ietf.org
>> > > https://www.ietf.org/mailman/listinfo/netmod
>> > >
>> >
>>
>>
>> ------------------------------------------------------------------------
>> --------
>>
>>
>> > _______________________________________________
>> > netmod mailing list
>> > netmod@ietf.org
>> > https://www.ietf.org/mailman/listinfo/netmod
>> >
>>
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>>
>
>

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


Tom,

I agree with Andy. =C2=A0Benoit an=
d I have spoken about the best plan to enable good fast YANG models and it =
is critical
to have the subject matter experts working on it and =
getting the structure and knobs right. =C2=A0That is where a lot of the

work is. =C2=A0The hope is that YANG-doctors will provide the necessar=
y advice.

If it proves too hard and that only spec=
ific experts in YANG can write good useful models, that'll be a problem=
 for the technology.



Alia


On Thu, Jun 19, 2014 at 1:06 PM, Andy Bierman <and=
y@yumaworks.com> wrote:





On Thu, Jun 19, 2014=
 at 9:31 AM, t.petch <ietfc@btconnect.com> wrote:





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

From: "Alia Atlas" <akatlas@gmail.com>

Sent: Wednesday, June 18, 2014 6:26 PM



> isis-wg is the right place.



Alia



In a year or two, I expect that I would agree with you but right now,

the netmod WG has only just produced the basic models and in doing so,

found the need for some necessary modifications to YANG; and, in the

past 18 months, radically changed (IMO) the layout of most modules, to

the twin trees, cfg and state approach.



Give a year or two's experience of writing modules and there will

doubtless be guidelines on what to do and what not to do, but right now,
I think that the active involvement of the netmod group is essential.



I do not see config vs. operatio=
nal subtrees as a major architecture change.
The expansion of fun=
ctionality needs to be done with clue. Supporting
pre-provisionin=
g and protocol controlled operational state may require



a separate tree, depending on the data model. IMO this should not a ge=
neric
solution.

The guidelines are bound=
 to change the more standard functionality we addl
This should no=
t slow down WGs using the existing functionality.





=C2=A0

I propose a three part approach; start in netmod to get the current

thinking of how to tackle common problems (the sort of things that Lada

has addressed although I disagree with him over the use of TLV - that is
how isis does things:-)



The problem with this approach i=
s that the NETMOD WG is a "plain old" WG,
with a charte=
r to produce YANG 1.1 and other documents. =C2=A0It is not chartered
<=
div>
to be the YANG Help Desk for the IETF. That is YANG Doctors' job.



It does not really scale well either (as we have seen f=
rom several YANG proposals
that are waiting years to get chartere=
d). NETMOD is already a bottleneck.
IMO, NETMOD should work on YA=
NG 1.1, YANG Conformance,



and YANG Usage Guidelines. =C2=A0It is time for domain-specific WGs to=

work on YANG modules for their protocols.
<=
div>





Then move to isis to get technicalities of the protocol correct, what to
model, what is config, defaults, etc



A YANG Doctor (Lada) will help t=
he isis WG.
The proper YANG usage is actually much easier to achi=
eve than agreeing
on the exact text of every single protocol knob=
 (by a mile),.



The protocol experts pay attention to the protocol WGs, not NETMOD.
Their review is easily missed if all YANG work is done in NETMOD.





Then back to netmod to see that it still aligns with netmod best

practice (which likely will have moved on)



This will happen as part of the =
AD review process.
I don't think YANG best practices are chan=
ging so rapidly that rewrites will be required.
We will see wrt/ =
I2RS and YANG 1.1, but that should not affect any WG that



wants to standardize YANG configuration data models with YANG 1.0.


=C2=A0



Tom Petch




Andy

=C2=A0



> Alia

>

>

> On Wed, Jun 18, 2014 at 4:30 AM, Juergen Schoenwaelder <

> j.schoenwaelder@jacobs-university.de> wrote:

>

> > On Wed, Jun 18, 2014 at 08:11:24AM +0000,

stephane=
.litkowski@orange.com

> > wrote:

> > > Hi Lada,

> > >

> > > For sure ISIS WG need to be involved, for ownership of the d=
raft,

I

> > don't really know which WG need to be "owner". Mayb=
e chairs can

provide

> > their feedback or we could discuss this point in Toronto.

> > > I'm would like to present this first version in both WG =
if

possible.

> > >

> >

> > As a general principle, I prefer that data models are done in the=


WGs

> > that understand what is being modeled. Hence, this work should
ideally

> > be done in the ISIS WG.

> >

> > Since I am not following the ISIS WG myself, I ended up looking a=
t

the

> > WG charter page in order to get a clue what they are working on a=
nd

> > what I found is that apparently their milestones have not been
updated

> > since 2009 (and the additional page pointed to in the charter,
> > <http://skat.usc.edu/~tli/Schedule.htm>, does not look more re=
cent

> > either). So it remains somewhat difficult to judge whether ISIS m=
ay

be

> > able to pick up this work.

> >

> > /js

> >

> > --

> > Juergen Schoenwaelder =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Jacobs U=
niversity Bremen gGmbH

> > Phone: +49 421 200 3587 =C2=A0 =C2=A0 =C2=A0 =C2=A0 C=
ampus Ring 1, 28759 Bremen, Germany

> > Fax: =C2=A0 +49 421 200 3103 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 <http=
://www.jacobs-university.de/>


> >

> > _______________________________________________

> > 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

>



_______________________________________________

netmod mailing list

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








--001a11332a2e458ad704fc35c3f8--


From nobody Fri Jun 20 01:05:17 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B4BA1B27A1 for ; Fri, 20 Jun 2014 01:05:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.299
X-Spam-Level: 
X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JTl-_6p3Jydq for ; Fri, 20 Jun 2014 01:05:13 -0700 (PDT)
Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57A5F1B279B for ; Fri, 20 Jun 2014 01:05:13 -0700 (PDT)
Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id 783572DC0BE; Fri, 20 Jun 2014 10:05:11 +0200 (CEST)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.5]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 59CC1238062; Fri, 20 Jun 2014 10:05:11 +0200 (CEST)
Received: from OPEXCLILM34.corporate.adroot.infra.ftgroup ([169.254.4.50]) by OPEXCLILH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0181.006; Fri, 20 Jun 2014 10:05:11 +0200
From: 
To: Ladislav Lhotka , "netmod@ietf.org" 
Thread-Topic: review of draft-litkowski-netmod-isis-cfg-00
Thread-Index: AQHPi8uWJFGHlwdDlUmsWj3oo3i2J5t5ob4g
Date: Fri, 20 Jun 2014 08:05:10 +0000
Message-ID: <26974_1403251511_53A3EB37_26974_17823_1_9E32478DFA9976438E7A22F69B08FF92022780@OPEXCLILM34.corporate.adroot.infra.ftgroup>
References: 
In-Reply-To: 
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.168.234.1]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.6.19.215119
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/YnG-TFfgDFBVShFVj6bEuXh_zcY
Subject: Re: [netmod] review of draft-litkowski-netmod-isis-cfg-00
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 20 Jun 2014 08:05:15 -0000

Hi Lada,

Thanks for your review.

Please find inline comments.

Best regards,

Stephane


-----Original Message-----
From: Ladislav Lhotka [mailto:lhotka@nic.cz]=20
Sent: Thursday, June 19, 2014 16:34
To: netmod@ietf.org; LITKOWSKI Stephane SCE/IBNF
Subject: review of draft-litkowski-netmod-isis-cfg-00

Hi,

I reviewed the isis module and I-D. I think it is a good start, although so=
me adjustments will be needed to make it work with the core routing data mo=
del, see below. I don't address any specific issues of IS-IS configuration.

*** General Comments
    - As Andy already pointed out, descriptions are often missing or
      too brief, and the prose in the I-D is also extremely scarce.
    - An example instance document would be useful, e.g. a reply to
       as in Appendix A of RFC 7277. (The "sample-skeleton"
      plugin of pyang can help with generating it.)=20=20

[SLI] Sure I will take this into account.

*** YANG module design
    - Entries of the "rt:routing-protocol" list (under both "routing"
      and "routing-state") are designed to support multiple instances
      of the same protocol. In configuration it means not only that
      the nodes "isis-cfg", "instances" and "instance" are
      superfluous, but this design also prevents connecting different
      ISIS instances to different RIBs.

[SLI] Ok I didn't catch this point, for me there was only one protocol inst=
ance per type indexed by its name "isis" or "ospf" in the same routing inst=
ance.
If it's not the case, I would remove the instances for ISIS.
The OSPF model (draft-yeung-netmod-ospf) sounds also to implement a list of=
 instances for OSPF protocol :
" augment "/rt:routing/rt:routing-instance/rt:routing-protocols/"
         + "rt:routing-protocol" {
     list ospf-router {

       description
         "This is a top-level container for the OSPF router.";

       when "./type=3Dospf";

       key "version name";
       leaf version {
         description
           "OSPF version.";
         type uint8 {
           range "2..3";
         }
       }
"


    - Similarly, state data for each ISIS instance should go straight
      to the corresponding entry of "routing-protocol" under
      "routing-state".

[SLI] Ack

    - Nodes in state data should use descriptive names rather than
      "TLVnnn". TLV numbers are important for the protocol but IMO
      there is no need to expose operators to them. For instance,
      "dynamic-hostname" is better than "TLV137".

[SLI] Ok, sometimes TLV numbers are more understable than descriptions :)

    - Grouping "interface-cfg" is used only once, so it is not
      needed. Other groupings are used at least twice.

  [SLI] Ack

    - A type definition for ISO addresses might be useful.

[SLI] Ack

*** Specific YANG issues
    - The module is invalid, I am attaching a diff file with
      necessary changes. Module validity should always be verified
      before posting an I-D, e.g. with pyang.

[SLI] Ok , I checked it but without importing modules, so only syntax check=
ing was done.

    - The argument of "namespace" should be an URI, e.g. urn:TBD.

[SLI] Ok

    - Arguments of some "augment" statements are broken, see the
      attached diff. In particular, they must not contain trailing
      slashes, see ABNF production "absolute-schema-nodeid".
    - The module should follow the guidelines of RFC 6087, they can
      be checked using

      pyang --ietf isis.yang

*** Formal issues
    - The module text should be wrapped in

       file "isis@2014-XX-XX.yang"
      ...
      

      so that it can be easily extracted with rfcstrip.=20
    - Assuming the module is bound for standard track, its name
      should be "ietf-isis".
    - Some descriptions exceed the line length limit of 72 characters,
      line breaks should be inserted.

[SLI] Will be fixed.


Lada

___________________________________________________________________________=
______________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.


From nobody Fri Jun 20 01:12:09 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CAF91AD6B1 for ; Fri, 20 Jun 2014 01:12:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.201
X-Spam-Level: 
X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v9_KdRk0ky41 for ; Fri, 20 Jun 2014 01:12:00 -0700 (PDT)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C43611A05C0 for ; Fri, 20 Jun 2014 01:11:59 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 5C4356EC; Fri, 20 Jun 2014 10:11:57 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id hHQVy3fqP3oW; Fri, 20 Jun 2014 10:11:37 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Fri, 20 Jun 2014 10:11:56 +0200 (CEST)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 62F1A2002C; Fri, 20 Jun 2014 10:11:57 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id iJ3OB_w56wC9; Fri, 20 Jun 2014 10:11:56 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 31BFC20017; Fri, 20 Jun 2014 10:11:56 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 42A1F2D9410A; Fri, 20 Jun 2014 10:11:54 +0200 (CEST)
Date: Fri, 20 Jun 2014 10:11:54 +0200
From: Juergen Schoenwaelder 
To: Ladislav Lhotka 
Message-ID: <20140620081154.GA11501@elstar.local>
Mail-Followup-To: Ladislav Lhotka , stephane.litkowski@orange.com, Alia Atlas , "netmod@ietf.org" 
References: <20140617122005.10875.31180.idtracker@ietfa.amsl.com> <24554_1403016065_53A05381_24554_4972_1_9E32478DFA9976438E7A22F69B08FF920215BB@OPEXCLILM34.corporate.adroot.infra.ftgroup> <9D8A1B46-C3AB-4592-810A-2636320697AD@nic.cz> <15719_1403079084_53A149AC_15719_5687_1_9E32478DFA9976438E7A22F69B08FF92021AC0@OPEXCLILM34.corporate.adroot.infra.ftgroup> <20140618083011.GB6055@elstar.local>  <23516_1403165213_53A29A1D_23516_5180_1_9E32478DFA9976438E7A22F69B08FF9202205C@OPEXCLILM34.corporate.adroot.infra.ftgroup> <20140619082336.GC9041@elstar.local> <2BEAD3C0-615D-4480-98F6-B21CE7A52DC5@nic.cz>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <2BEAD3C0-615D-4480-98F6-B21CE7A52DC5@nic.cz>
User-Agent: Mutt/1.4.2.3i
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/LHNcDCcZ2o15lET23KONlSAwcCo
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] [Isis-wg] FW: New Version Notification for draft-litkowski-netmod-isis-cfg-00.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 20 Jun 2014 08:12:03 -0000

On Thu, Jun 19, 2014 at 03:17:07PM +0200, Ladislav Lhotka wrote:
> 
> On 19 Jun 2014, at 10:23, Juergen Schoenwaelder  wrote:
> 
> > Hi,
> > 
> > it is surely good to keep the NETMOD WG updated about such activities
> > going on in other WGs. However, NETMOD is not functioning as a YANG
> > review team as stated on the NETMOD charter:
> > 
> >  The NETMOD Working Group will not serve as a review team for YANG
> >  modules developed by other working groups. The YANG doctors,
> >  organized by the OPS area director responsible for network
> >  management, can act as advisors for other working groups and they
> >  provide YANG reviews for the OPS area directors.
> > 
> > Since Lada indicated interest in this work and he is also a YANG
> > doctor, I think we are in a pretty good shape (and I am sure that Lada
> > will raise any issues that are more fundamental (should they show up)
> > when it is appropriate).
> 
> I am writing a review of this I-D, concentrating mainly on YANG issues and the integration with the core routing model. But I wonder - where should I send it? NETMOD or YANG doctors mailing list?
> 

I guess the isis mailing list with a CC to the YANG doctors would be
the right approach. If YANG doctors then start debating certain
elements of your review, we may have to consider to extract these
issues and send them to the NETMOD wg. This is more or less how MIB
doctors work.

/js

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


From nobody Fri Jun 20 03:41:36 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76D811A0371 for ; Fri, 20 Jun 2014 03:41:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level: 
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sOTcoKHXx9YE for ; Fri, 20 Jun 2014 03:41:30 -0700 (PDT)
Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1lp0017.outbound.protection.outlook.com [213.199.154.17]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6FC51A00BA for ; Fri, 20 Jun 2014 03:41:29 -0700 (PDT)
Received: from AMXPRD0310HT002.eurprd03.prod.outlook.com (157.56.248.133) by DB3PR07MB060.eurprd07.prod.outlook.com (10.242.137.151) with Microsoft SMTP Server (TLS) id 15.0.969.15; Fri, 20 Jun 2014 10:41:27 +0000
Message-ID: <03a401cf8c73$bc2e1ca0$4001a8c0@gateway.2wire.net>
From: t.petch 
To: , Ladislav Lhotka , 
References:  <26974_1403251511_53A3EB37_26974_17823_1_9E32478DFA9976438E7A22F69B08FF92022780@OPEXCLILM34.corporate.adroot.infra.ftgroup>
Date: Fri, 20 Jun 2014 11:33:58 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Originating-IP: [157.56.248.133]
X-ClientProxiedBy: DBXPR07CA005.eurprd07.prod.outlook.com (10.255.191.163) To DB3PR07MB060.eurprd07.prod.outlook.com (10.242.137.151)
X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:
X-Forefront-PRVS: 024847EE92
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(6009001)(428001)(13464003)(189002)(199002)(51704005)(377454003)(14496001)(21056001)(87286001)(83322001)(19580405001)(101416001)(106356001)(83072002)(19580395003)(81342001)(81542001)(99396002)(42186005)(64706001)(15975445006)(20776003)(105586002)(47776003)(104166001)(84392001)(85306003)(31966008)(50986999)(89996001)(62236002)(85852003)(81816999)(95666004)(44716002)(74662001)(88136002)(76176999)(4396001)(81686999)(87976001)(77982001)(50466002)(50226001)(76482001)(23756003)(77156001)(93916002)(44736004)(92566001)(61296003)(92726001)(102836001)(80022001)(66066001)(77096002)(79102001)(74502001)(62966002)(86362001)(46102001)(33646001)(74416001)(7726001); DIR:OUT; SFP:; SCL:1; SRVR:DB3PR07MB060; H:AMXPRD0310HT002.eurprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords;  MX:1; A:0; LANG:en; 
Received-SPF: None (: btconnect.com does not designate permitted sender hosts)
Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; 
X-OriginatorOrg: btconnect.com
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/Ee8HeAEFBZcpemfCyUDW-dx-Eoo
Subject: Re: [netmod] review of draft-litkowski-netmod-isis-cfg-00
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 20 Jun 2014 10:41:33 -0000

I would consult the isis list about the use of TLVnnn as names.

For me, that is very much a part of is-is, that is, when I see TLVnnn I
know I am dealing with someone who is familiar with is-is.

Tom Petch


----- Original Message -----
From: 
To: "Ladislav Lhotka" ; 
Sent: Friday, June 20, 2014 9:05 AM
Subject: Re: [netmod] review of draft-litkowski-netmod-isis-cfg-00


> Hi Lada,
>
> Thanks for your review.
>
> Please find inline comments.
>
> Best regards,
>
> Stephane
>
>
> -----Original Message-----
> From: Ladislav Lhotka [mailto:lhotka@nic.cz]
> Sent: Thursday, June 19, 2014 16:34
> To: netmod@ietf.org; LITKOWSKI Stephane SCE/IBNF
> Subject: review of draft-litkowski-netmod-isis-cfg-00
>
> Hi,
>
> I reviewed the isis module and I-D. I think it is a good start,
although some adjustments will be needed to make it work with the core
routing data model, see below. I don't address any specific issues of
IS-IS configuration.
>
> *** General Comments
>     - As Andy already pointed out, descriptions are often missing or
>       too brief, and the prose in the I-D is also extremely scarce.
>     - An example instance document would be useful, e.g. a reply to
>        as in Appendix A of RFC 7277. (The "sample-skeleton"
>       plugin of pyang can help with generating it.)
>
> [SLI] Sure I will take this into account.
>
> *** YANG module design
>     - Entries of the "rt:routing-protocol" list (under both "routing"
>       and "routing-state") are designed to support multiple instances
>       of the same protocol. In configuration it means not only that
>       the nodes "isis-cfg", "instances" and "instance" are
>       superfluous, but this design also prevents connecting different
>       ISIS instances to different RIBs.
>
> [SLI] Ok I didn't catch this point, for me there was only one protocol
instance per type indexed by its name "isis" or "ospf" in the same
routing instance.
> If it's not the case, I would remove the instances for ISIS.
> The OSPF model (draft-yeung-netmod-ospf) sounds also to implement a
list of instances for OSPF protocol :
> " augment "/rt:routing/rt:routing-instance/rt:routing-protocols/"
>          + "rt:routing-protocol" {
>      list ospf-router {
>
>        description
>          "This is a top-level container for the OSPF router.";
>
>        when "./type=ospf";
>
>        key "version name";
>        leaf version {
>          description
>            "OSPF version.";
>          type uint8 {
>            range "2..3";
>          }
>        }
> "
>
>
>     - Similarly, state data for each ISIS instance should go straight
>       to the corresponding entry of "routing-protocol" under
>       "routing-state".
>
> [SLI] Ack
>
>     - Nodes in state data should use descriptive names rather than
>       "TLVnnn". TLV numbers are important for the protocol but IMO
>       there is no need to expose operators to them. For instance,
>       "dynamic-hostname" is better than "TLV137".
>
> [SLI] Ok, sometimes TLV numbers are more understable than descriptions
:)
>
>     - Grouping "interface-cfg" is used only once, so it is not
>       needed. Other groupings are used at least twice.
>
>   [SLI] Ack
>
>     - A type definition for ISO addresses might be useful.
>
> [SLI] Ack
>
> *** Specific YANG issues
>     - The module is invalid, I am attaching a diff file with
>       necessary changes. Module validity should always be verified
>       before posting an I-D, e.g. with pyang.
>
> [SLI] Ok , I checked it but without importing modules, so only syntax
checking was done.
>
>     - The argument of "namespace" should be an URI, e.g. urn:TBD.
>
> [SLI] Ok
>
>     - Arguments of some "augment" statements are broken, see the
>       attached diff. In particular, they must not contain trailing
>       slashes, see ABNF production "absolute-schema-nodeid".
>     - The module should follow the guidelines of RFC 6087, they can
>       be checked using
>
>       pyang --ietf isis.yang
>
> *** Formal issues
>     - The module text should be wrapped in
>
>        file "isis@2014-XX-XX.yang"
>       ...
>       
>
>       so that it can be easily extracted with rfcstrip.
>     - Assuming the module is bound for standard track, its name
>       should be "ietf-isis".
>     - Some descriptions exceed the line length limit of 72 characters,
>       line breaks should be inserted.
>
> [SLI] Will be fixed.
>
>
> Lada
>
>
________________________________________________________________________
_________________________________________________
>
> Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez
recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les
messages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere,
deforme ou falsifie. Merci.
>
> This message and its attachments may contain confidential or
privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and
delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have
been modified, changed or falsified.
> Thank you.
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


From nobody Fri Jun 20 03:58:44 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4E281A0371 for ; Fri, 20 Jun 2014 03:58:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.699
X-Spam-Level: 
X-Spam-Status: No, score=-0.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, J_CHICKENPOX_15=0.6, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RJUstCOx1fC1 for ; Fri, 20 Jun 2014 03:58:40 -0700 (PDT)
Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DADE1A00EC for ; Fri, 20 Jun 2014 03:58:40 -0700 (PDT)
Received: from omfeda06.si.francetelecom.fr (unknown [xx.xx.xx.199]) by omfeda11.si.francetelecom.fr (ESMTP service) with ESMTP id 80BE21B82A6; Fri, 20 Jun 2014 12:58:38 +0200 (CEST)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.16]) by omfeda06.si.francetelecom.fr (ESMTP service) with ESMTP id 60B25C80D4; Fri, 20 Jun 2014 12:58:38 +0200 (CEST)
Received: from OPEXCLILM34.corporate.adroot.infra.ftgroup ([169.254.4.50]) by OPEXCLILH05.corporate.adroot.infra.ftgroup ([10.114.31.16]) with mapi id 14.03.0181.006; Fri, 20 Jun 2014 12:58:38 +0200
From: 
To: t.petch , Ladislav Lhotka , "netmod@ietf.org" 
Thread-Topic: [netmod] review of draft-litkowski-netmod-isis-cfg-00
Thread-Index: AQHPi8uWJFGHlwdDlUmsWj3oo3i2J5t5ob4ggAAvEDCAAAQx0A==
Date: Fri, 20 Jun 2014 10:58:37 +0000
Message-ID: <8037_1403261918_53A413DE_8037_5683_1_9E32478DFA9976438E7A22F69B08FF920228FC@OPEXCLILM34.corporate.adroot.infra.ftgroup>
References:  <26974_1403251511_53A3EB37_26974_17823_1_9E32478DFA9976438E7A22F69B08FF92022780@OPEXCLILM34.corporate.adroot.infra.ftgroup> <03a401cf8c73$bc2e1ca0$4001a8c0@gateway.2wire.net>
In-Reply-To: <03a401cf8c73$bc2e1ca0$4001a8c0@gateway.2wire.net>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.168.234.1]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.6.20.19
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/13jjQyweY9_r0qs9B-v-EHKKF7M
Subject: Re: [netmod] review of draft-litkowski-netmod-isis-cfg-00
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 20 Jun 2014 10:58:42 -0000

Tom,

Another approach could be to put TLV reference in description ...
I agree that TLV number is something meaningful for ISIS people.

I hold on this point waiting discussion with ISIS wg.

Stephane


-----Original Message-----
From: t.petch [mailto:ietfc@btconnect.com]=20
Sent: Friday, June 20, 2014 12:34
To: LITKOWSKI Stephane SCE/IBNF; Ladislav Lhotka; netmod@ietf.org
Subject: Re: [netmod] review of draft-litkowski-netmod-isis-cfg-00

I would consult the isis list about the use of TLVnnn as names.

For me, that is very much a part of is-is, that is, when I see TLVnnn I kno=
w I am dealing with someone who is familiar with is-is.

Tom Petch


----- Original Message -----
From: 
To: "Ladislav Lhotka" ; 
Sent: Friday, June 20, 2014 9:05 AM
Subject: Re: [netmod] review of draft-litkowski-netmod-isis-cfg-00


> Hi Lada,
>
> Thanks for your review.
>
> Please find inline comments.
>
> Best regards,
>
> Stephane
>
>
> -----Original Message-----
> From: Ladislav Lhotka [mailto:lhotka@nic.cz]
> Sent: Thursday, June 19, 2014 16:34
> To: netmod@ietf.org; LITKOWSKI Stephane SCE/IBNF
> Subject: review of draft-litkowski-netmod-isis-cfg-00
>
> Hi,
>
> I reviewed the isis module and I-D. I think it is a good start,
although some adjustments will be needed to make it work with the core rout=
ing data model, see below. I don't address any specific issues of IS-IS con=
figuration.
>
> *** General Comments
>     - As Andy already pointed out, descriptions are often missing or
>       too brief, and the prose in the I-D is also extremely scarce.
>     - An example instance document would be useful, e.g. a reply to
>        as in Appendix A of RFC 7277. (The "sample-skeleton"
>       plugin of pyang can help with generating it.)
>
> [SLI] Sure I will take this into account.
>
> *** YANG module design
>     - Entries of the "rt:routing-protocol" list (under both "routing"
>       and "routing-state") are designed to support multiple instances
>       of the same protocol. In configuration it means not only that
>       the nodes "isis-cfg", "instances" and "instance" are
>       superfluous, but this design also prevents connecting different
>       ISIS instances to different RIBs.
>
> [SLI] Ok I didn't catch this point, for me there was only one protocol
instance per type indexed by its name "isis" or "ospf" in the same routing =
instance.
> If it's not the case, I would remove the instances for ISIS.
> The OSPF model (draft-yeung-netmod-ospf) sounds also to implement a
list of instances for OSPF protocol :
> " augment "/rt:routing/rt:routing-instance/rt:routing-protocols/"
>          + "rt:routing-protocol" {
>      list ospf-router {
>
>        description
>          "This is a top-level container for the OSPF router.";
>
>        when "./type=3Dospf";
>
>        key "version name";
>        leaf version {
>          description
>            "OSPF version.";
>          type uint8 {
>            range "2..3";
>          }
>        }
> "
>
>
>     - Similarly, state data for each ISIS instance should go straight
>       to the corresponding entry of "routing-protocol" under
>       "routing-state".
>
> [SLI] Ack
>
>     - Nodes in state data should use descriptive names rather than
>       "TLVnnn". TLV numbers are important for the protocol but IMO
>       there is no need to expose operators to them. For instance,
>       "dynamic-hostname" is better than "TLV137".
>
> [SLI] Ok, sometimes TLV numbers are more understable than descriptions
:)
>
>     - Grouping "interface-cfg" is used only once, so it is not
>       needed. Other groupings are used at least twice.
>
>   [SLI] Ack
>
>     - A type definition for ISO addresses might be useful.
>
> [SLI] Ack
>
> *** Specific YANG issues
>     - The module is invalid, I am attaching a diff file with
>       necessary changes. Module validity should always be verified
>       before posting an I-D, e.g. with pyang.
>
> [SLI] Ok , I checked it but without importing modules, so only syntax
checking was done.
>
>     - The argument of "namespace" should be an URI, e.g. urn:TBD.
>
> [SLI] Ok
>
>     - Arguments of some "augment" statements are broken, see the
>       attached diff. In particular, they must not contain trailing
>       slashes, see ABNF production "absolute-schema-nodeid".
>     - The module should follow the guidelines of RFC 6087, they can
>       be checked using
>
>       pyang --ietf isis.yang
>
> *** Formal issues
>     - The module text should be wrapped in
>
>        file "isis@2014-XX-XX.yang"
>       ...
>       
>
>       so that it can be easily extracted with rfcstrip.
>     - Assuming the module is bound for standard track, its name
>       should be "ietf-isis".
>     - Some descriptions exceed the line length limit of 72 characters,
>       line breaks should be inserted.
>
> [SLI] Will be fixed.
>
>
> Lada
>
>
________________________________________________________________________
_________________________________________________
>
> Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez
recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les
messages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere,
deforme ou falsifie. Merci.
>
> This message and its attachments may contain confidential or
privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and
delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have
been modified, changed or falsified.
> Thank you.
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


___________________________________________________________________________=
______________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.


From nobody Fri Jun 20 04:26:44 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 273AD1B27AB for ; Fri, 20 Jun 2014 04:26:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id En73oTqYhg0U for ; Fri, 20 Jun 2014 04:26:39 -0700 (PDT)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4562D1A0114 for ; Fri, 20 Jun 2014 04:26:38 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id EFDAD54080E; Fri, 20 Jun 2014 13:26:35 +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 chdah7xWgMqm; Fri, 20 Jun 2014 13:26:31 +0200 (CEST)
Received: from localhost (unknown [172.29.2.201]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id C0B025403EC; Fri, 20 Jun 2014 13:26:29 +0200 (CEST)
From: Ladislav Lhotka 
To: "Jeffrey \(Zhaohui\) Zhang" , Dean Bogdanovic , "netmod\@ietf.org" 
In-Reply-To: 
References: 
User-Agent: Notmuch/0.18 (http://notmuchmail.org) Emacs/24.3.50.2 (x86_64-apple-darwin13.0.0)
Date: Fri, 20 Jun 2014 13:26:27 +0200
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/O4676reWvkWWghkN2qK6LVS_Kc4
Cc: Kiran Agrahara Sreenivasa 
Subject: Re: [netmod] Questions/comments on draft-ietf-netmod-routing-cfg
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 20 Jun 2014 11:26:42 -0000

"Jeffrey (Zhaohui) Zhang"  writes:

> Ladislav,
>
> Dean and I have some late questions and comments. We came across these wh=
ile trying to work on the OSPF YANG model.
>
> -----------
>
> The spec mentions in several places something like the following:
>
> =C2=A0=C2=A0 Each routing protocol instance is connected to exactly one R=
IB for
> =C2=A0=C2=A0 each address family that the routing protocol instance suppo=
rts.
>
> My understanding is that the address family mentioned above does not incl=
ude SAFI. Because of that, a routing protocol like BGP may connect to multi=
ple RIBs in the same family (RIB for unicast and RIB for multicast RPF purp=
ose in case of incongruent multicast topology) so the above statement is no=
t correct.

This is quite flexible since address family is defined via identities. I ca=
n imagine one implementation using only "ipv4" and "ipv6" (defined in ietf-=
routing) whilst other implementation could use "ipv[46]-unicast" (defined i=
n ietf-ipv[46]-unicast-routing) and "ipv[46]-multicast" (to be defined in a=
 module for unicast routing), that means including SAFI.

>
> This is also a problem in case of Multi-topology. Each topology has its o=
wn RIB and a protocol instance like OSPF can connect to multiple MT RIBs.

Two possible solutions come to my mind:

1. You could derive new address family identities from "ipv4-unicast" etc. =
so that you can assign a unique address family to multiple tables.

2. You could have one connected RIB e.g. for "ipv4-unicast" and define two =
or more RIBs for each topology as recipients of the connected RIB. So, in e=
ffect, the (single) connected RIB contains routes for all topologies and th=
ese are then split via route filters to the per-topology RIBs.

Does it make sense?

>
> ------
>
> 5.1.  Routing Instance
>
>    Each routing instance in the core routing data model represents a
>    logical router.  The exact semantics of this term are left to
>    implementations.  For example, routing instances may be completely
>    isolated virtual routers or, alternatively, they may internally share
>    certain information.
>
>    ...
>
>    An implementation MAY support multiple types of logical routers
>    simultaneously.  Instances of all routing instance types are
>    organized as entries of the same flat "routing-instance" list.  In
>    order to discriminate routing instances belonging to different types,
>    the "type" leaf is defined as a child of the "routing-instance" node.
>
> The spec purposely left it fuzzy as to what a "routing instance" is. Howe=
ver we definitely should have clear definitions for the three terms mention=
ed: routing-instance, logical router and virtual router.

Yes, this is by design open-ended because otherwise we would probably never=
 reach consensus on what these terms exactly mean.

>
> Logical router is a very overload term. Today vendors have virtualized th=
eir routing capabilities in the system and provide 3 different levels of ro=
uting virtualization. Logical systems, logical routers are some of the name=
s used by vendors and those offer routing and management separation. Each l=
ogical system has its own routing instances and routing instances can have =
multiple routing tables, so it is very important to have very precise defin=
ition of what is routing instance (and not compare it with logical router)
>
> =C2=A0=C2=A0=C2=A0=C2=A0 identity standard-routing-instance {
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 base routing-instance-type;
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 description
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "This identity represent=
s a default routing instance.";
> =C2=A0=C2=A0=C2=A0=C2=A0 }
>
> What is a "standard-routing-instance"? Would "default-routing-instance" b=
e better? "standard" wording leads to "standard vs. non-standard" question =
and hints on that the two are different types. "default" vs. "non-default" =
does not have that (at least to me).

Well, "default" is overloaded, too, and also has a specific meaning in YANG=
. Standard is supposed to mean plain vanilla router. It is just a name.

>
> Should this spec distinguish VRF/VR/LR and have corresponding identities =
defined?

The idea is this will be done in other modules that define data models for =
these types of routing instances. Then the "routing-instance" container can=
 be augmented with arbitrary data, but conditionally for that routing insta=
nce type.

An implementation may actually use multiple routing-instance types at the s=
ame time.

>
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 leaf type {
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 type identit=
yref {
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
base routing-instance-type;
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 }
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 description
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
"The routing instance type, primarily intended for
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 discriminating among different types of logical routers,
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 route virtualization, master-slave arrangements etc.,
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 while keeping all routing instances in the same flat
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 list.";
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 }
>
> What is the "master-slave arrangements"?

This came from an early review by Thomas Morin, it has to do with MPLS/BGP =
VPNs where a master routing-instance exchanges selected routes with each VP=
N/VRF.

>
> Depending on the definition of "logical router" and "route virtualization=
", there may also be concerns with keeping all those kinds of in the same f=
lat list.

It is similar to interfaces, where physical and logical interfaces of all k=
inds live in the same flat list and are distinguished by the type. I think =
it could work, relationships among the individual routing instances can be =
expressed in other data.

Having a single flat list has its advantages, for example you can then easi=
ly refer to routing instances via leafrefs (which allow only one path).

Cheers, Lada

>
> Jeffrey Zhang
> Dean Bogdanovic

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


From nobody Fri Jun 20 05:22:21 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78D561A037B for ; Fri, 20 Jun 2014 05:22:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2f0t4VGyp3xD for ; Fri, 20 Jun 2014 05:22:16 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0186.outbound.protection.outlook.com [207.46.163.186]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9C191A0114 for ; Fri, 20 Jun 2014 05:22:15 -0700 (PDT)
Received: from BY2PR05MB079.namprd05.prod.outlook.com (10.242.38.16) by BN1PR05MB423.namprd05.prod.outlook.com (10.141.58.146) with Microsoft SMTP Server (TLS) id 15.0.954.9; Fri, 20 Jun 2014 12:22:13 +0000
Received: from BY2PR05MB079.namprd05.prod.outlook.com ([169.254.8.252]) by BY2PR05MB079.namprd05.prod.outlook.com ([169.254.8.206]) with mapi id 15.00.0949.001; Fri, 20 Jun 2014 12:22:11 +0000
From: "Jeffrey (Zhaohui) Zhang" 
To: Ladislav Lhotka , Dean Bogdanovic , "netmod@ietf.org" 
Thread-Topic: Questions/comments on draft-ietf-netmod-routing-cfg
Thread-Index: Ac+L5mG6QCip6E9wRnWAlQy1vx1YdgAlBfOAAACoQiA=
Date: Fri, 20 Jun 2014 12:22:11 +0000
Message-ID: <18cd777ffb9d4df6b0966dd1b3dd822b@BY2PR05MB079.namprd05.prod.outlook.com>
References:  
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [66.129.241.12]
x-microsoft-antispam: BL:0; ACTION:Default; RISK:Low; SCL:0; SPMLVL:NotSpam; PCL:0; RULEID:
x-forefront-prvs: 024847EE92
x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(428001)(377454003)(25584003)(199002)(13464003)(189002)(51704005)(83322001)(19580395003)(19580405001)(33646001)(2656002)(87936001)(46102001)(54356999)(74662001)(77982001)(101416001)(76482001)(50986999)(31966008)(1941001)(83072002)(4396001)(85852003)(79102001)(99396002)(80022001)(66066001)(64706001)(74502001)(20776003)(105586002)(85306003)(92566001)(81542001)(86362001)(81342001)(76176999)(95666004)(76576001)(77096002)(106356001)(74316001)(99286002)(575784001)(21056001)(24736002)(106276001); DIR:OUT; SFP:; SCL:1; SRVR:BN1PR05MB423; H:BY2PR05MB079.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; 
received-spf: None (: juniper.net does not designate permitted sender hosts)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=zzhang@juniper.net; 
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/pYcUCz6V289XWiiYBUE0xNfqsO4
Cc: Kiran Agrahara Sreenivasa 
Subject: Re: [netmod] Questions/comments on draft-ietf-netmod-routing-cfg
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 20 Jun 2014 12:22:19 -0000

TGFkYSwNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBMYWRpc2xhdiBM
aG90a2EgW21haWx0bzpsaG90a2FAbmljLmN6XQ0KPiBTZW50OiBGcmlkYXksIEp1bmUgMjAsIDIw
MTQgNzoyNiBBTQ0KPiBUbzogSmVmZnJleSAoWmhhb2h1aSkgWmhhbmc7IERlYW4gQm9nZGFub3Zp
YzsgbmV0bW9kQGlldGYub3JnDQo+IENjOiBEZXJlayBNYW4tS2l0IFlldW5nIChteWV1bmcpOyBL
aXJhbiBBZ3JhaGFyYSBTcmVlbml2YXNhDQo+IFN1YmplY3Q6IFJlOiBRdWVzdGlvbnMvY29tbWVu
dHMgb24gZHJhZnQtaWV0Zi1uZXRtb2Qtcm91dGluZy1jZmcNCj4gDQo+ICJKZWZmcmV5IChaaGFv
aHVpKSBaaGFuZyIgPHp6aGFuZ0BqdW5pcGVyLm5ldD4gd3JpdGVzOg0KPiANCj4gPiBMYWRpc2xh
diwNCj4gPg0KPiA+IERlYW4gYW5kIEkgaGF2ZSBzb21lIGxhdGUgcXVlc3Rpb25zIGFuZCBjb21t
ZW50cy4gV2UgY2FtZSBhY3Jvc3MgdGhlc2UNCj4gd2hpbGUgdHJ5aW5nIHRvIHdvcmsgb24gdGhl
IE9TUEYgWUFORyBtb2RlbC4NCj4gPg0KPiA+IC0tLS0tLS0tLS0tDQo+ID4NCj4gPiBUaGUgc3Bl
YyBtZW50aW9ucyBpbiBzZXZlcmFsIHBsYWNlcyBzb21ldGhpbmcgbGlrZSB0aGUgZm9sbG93aW5n
Og0KPiA+DQo+ID4gwqDCoCBFYWNoIHJvdXRpbmcgcHJvdG9jb2wgaW5zdGFuY2UgaXMgY29ubmVj
dGVkIHRvIGV4YWN0bHkgb25lIFJJQiBmb3INCj4gPiDCoMKgIGVhY2ggYWRkcmVzcyBmYW1pbHkg
dGhhdCB0aGUgcm91dGluZyBwcm90b2NvbCBpbnN0YW5jZSBzdXBwb3J0cy4NCj4gPg0KPiA+IE15
IHVuZGVyc3RhbmRpbmcgaXMgdGhhdCB0aGUgYWRkcmVzcyBmYW1pbHkgbWVudGlvbmVkIGFib3Zl
IGRvZXMgbm90DQo+IGluY2x1ZGUgU0FGSS4gQmVjYXVzZSBvZiB0aGF0LCBhIHJvdXRpbmcgcHJv
dG9jb2wgbGlrZSBCR1AgbWF5IGNvbm5lY3QNCj4gdG8gbXVsdGlwbGUgUklCcyBpbiB0aGUgc2Ft
ZSBmYW1pbHkgKFJJQiBmb3IgdW5pY2FzdCBhbmQgUklCIGZvcg0KPiBtdWx0aWNhc3QgUlBGIHB1
cnBvc2UgaW4gY2FzZSBvZiBpbmNvbmdydWVudCBtdWx0aWNhc3QgdG9wb2xvZ3kpIHNvIHRoZQ0K
PiBhYm92ZSBzdGF0ZW1lbnQgaXMgbm90IGNvcnJlY3QuDQo+IA0KPiBUaGlzIGlzIHF1aXRlIGZs
ZXhpYmxlIHNpbmNlIGFkZHJlc3MgZmFtaWx5IGlzIGRlZmluZWQgdmlhIGlkZW50aXRpZXMuIEkN
Cj4gY2FuIGltYWdpbmUgb25lIGltcGxlbWVudGF0aW9uIHVzaW5nIG9ubHkgImlwdjQiIGFuZCAi
aXB2NiIgKGRlZmluZWQgaW4NCj4gaWV0Zi1yb3V0aW5nKSB3aGlsc3Qgb3RoZXIgaW1wbGVtZW50
YXRpb24gY291bGQgdXNlICJpcHZbNDZdLXVuaWNhc3QiDQo+IChkZWZpbmVkIGluIGlldGYtaXB2
WzQ2XS11bmljYXN0LXJvdXRpbmcpIGFuZCAiaXB2WzQ2XS1tdWx0aWNhc3QiICh0byBiZQ0KPiBk
ZWZpbmVkIGluIGEgbW9kdWxlIGZvciB1bmljYXN0IHJvdXRpbmcpLCB0aGF0IG1lYW5zIGluY2x1
ZGluZyBTQUZJLg0KDQpBZGRyZXNzIEZhbWlseSBoYXMgdmVyeSBzcGVjaWZpYyBtZWFuaW5ncywg
dHlwaWNhbGx5IG9ubHkgcmVmZXIgdG8gSVB2NC9JUHY2IHRvIG15IHVuZGVyc3RhbmRpbmcuIElm
IHdlIHdhbnQgdG8gZXh0ZW5kIHRoYXQgdG8gaW5jbHVkZSBTQUZJLCB0aGVuIHRoZSBzcGVjIG11
c3QgcG9pbnQgaXQgb3V0LiBNb3JlIGJlbG93IHJlbGF0ZWQgdG8gTVQuDQoNCj4gDQo+ID4NCj4g
PiBUaGlzIGlzIGFsc28gYSBwcm9ibGVtIGluIGNhc2Ugb2YgTXVsdGktdG9wb2xvZ3kuIEVhY2gg
dG9wb2xvZ3kgaGFzDQo+IGl0cyBvd24gUklCIGFuZCBhIHByb3RvY29sIGluc3RhbmNlIGxpa2Ug
T1NQRiBjYW4gY29ubmVjdCB0byBtdWx0aXBsZSBNVA0KPiBSSUJzLg0KPiANCj4gVHdvIHBvc3Np
YmxlIHNvbHV0aW9ucyBjb21lIHRvIG15IG1pbmQ6DQo+IA0KPiAxLiBZb3UgY291bGQgZGVyaXZl
IG5ldyBhZGRyZXNzIGZhbWlseSBpZGVudGl0aWVzIGZyb20gImlwdjQtdW5pY2FzdCINCj4gZXRj
LiBzbyB0aGF0IHlvdSBjYW4gYXNzaWduIGEgdW5pcXVlIGFkZHJlc3MgZmFtaWx5IHRvIG11bHRp
cGxlIHRhYmxlcy4NCj4gDQo+IDIuIFlvdSBjb3VsZCBoYXZlIG9uZSBjb25uZWN0ZWQgUklCIGUu
Zy4gZm9yICJpcHY0LXVuaWNhc3QiIGFuZCBkZWZpbmUNCj4gdHdvIG9yIG1vcmUgUklCcyBmb3Ig
ZWFjaCB0b3BvbG9neSBhcyByZWNpcGllbnRzIG9mIHRoZSBjb25uZWN0ZWQgUklCLg0KPiBTbywg
aW4gZWZmZWN0LCB0aGUgKHNpbmdsZSkgY29ubmVjdGVkIFJJQiBjb250YWlucyByb3V0ZXMgZm9y
IGFsbA0KPiB0b3BvbG9naWVzIGFuZCB0aGVzZSBhcmUgdGhlbiBzcGxpdCB2aWEgcm91dGUgZmls
dGVycyB0byB0aGUgcGVyLQ0KPiB0b3BvbG9neSBSSUJzLg0KPiANCj4gRG9lcyBpdCBtYWtlIHNl
bnNlPw0KDQpDb21wYXJlIHRoZSB0d28sIEkgZG9uJ3QgbGlrZSAjMiBiZWNhdXNlIGl0IGFkZHMg
YW4gdW5uZWNlc3NhcnkgaW5kaXJlY3Rpb24uIEkgZG9uJ3QgdGhpbmsgd2Ugd2FudCB0byBvdmVy
bG9hZCAiQWRkcmVzcyBGYW1pbHkiIGZ1cnRoZXIgdG8gaW5jbHVkZSB0b3BvbG9neSBlaXRoZXIu
IEluIG1hbnkgaW1wbGVtZW50YXRpb25zLCBhY3R1YWwgUklCcyBhcmUgcGVyIChyb3V0aW5nLWlu
c3RhbmNlLCBBRkksIFNBRkksIHRvcG9sb2d5KSBhbmQgaXQgbWF5IGJlIGV4dGVuZGVkIGZ1cnRo
ZXIuIFRoZXJlZm9yZSwgdGhlIGJlc3Qgb3B0aW9uIGlzIHRvIHNpbXBseSByZW1vdmUgdGhlIHJl
c3RyaWN0aW9uIHRoYXQgb25lIHByb3RvY29sIGluc3RhbmNlIGlzIGNvbm5lY3RlZCB0byBleGFj
dGx5IG9uZSBSSUIgcGVyIGFkZHJlc3MgZmFtaWx5Lg0KDQo+IA0KPiA+DQo+ID4gLS0tLS0tDQo+
ID4NCj4gPiA1LjEuICBSb3V0aW5nIEluc3RhbmNlDQo+ID4NCj4gPiAgICBFYWNoIHJvdXRpbmcg
aW5zdGFuY2UgaW4gdGhlIGNvcmUgcm91dGluZyBkYXRhIG1vZGVsIHJlcHJlc2VudHMgYQ0KPiA+
ICAgIGxvZ2ljYWwgcm91dGVyLiAgVGhlIGV4YWN0IHNlbWFudGljcyBvZiB0aGlzIHRlcm0gYXJl
IGxlZnQgdG8NCj4gPiAgICBpbXBsZW1lbnRhdGlvbnMuICBGb3IgZXhhbXBsZSwgcm91dGluZyBp
bnN0YW5jZXMgbWF5IGJlIGNvbXBsZXRlbHkNCj4gPiAgICBpc29sYXRlZCB2aXJ0dWFsIHJvdXRl
cnMgb3IsIGFsdGVybmF0aXZlbHksIHRoZXkgbWF5IGludGVybmFsbHkgc2hhcmUNCj4gPiAgICBj
ZXJ0YWluIGluZm9ybWF0aW9uLg0KPiA+DQo+ID4gICAgLi4uDQo+ID4NCj4gPiAgICBBbiBpbXBs
ZW1lbnRhdGlvbiBNQVkgc3VwcG9ydCBtdWx0aXBsZSB0eXBlcyBvZiBsb2dpY2FsIHJvdXRlcnMN
Cj4gPiAgICBzaW11bHRhbmVvdXNseS4gIEluc3RhbmNlcyBvZiBhbGwgcm91dGluZyBpbnN0YW5j
ZSB0eXBlcyBhcmUNCj4gPiAgICBvcmdhbml6ZWQgYXMgZW50cmllcyBvZiB0aGUgc2FtZSBmbGF0
ICJyb3V0aW5nLWluc3RhbmNlIiBsaXN0LiAgSW4NCj4gPiAgICBvcmRlciB0byBkaXNjcmltaW5h
dGUgcm91dGluZyBpbnN0YW5jZXMgYmVsb25naW5nIHRvIGRpZmZlcmVudCB0eXBlcywNCj4gPiAg
ICB0aGUgInR5cGUiIGxlYWYgaXMgZGVmaW5lZCBhcyBhIGNoaWxkIG9mIHRoZSAicm91dGluZy1p
bnN0YW5jZSIgbm9kZS4NCj4gPg0KPiA+IFRoZSBzcGVjIHB1cnBvc2VseSBsZWZ0IGl0IGZ1enp5
IGFzIHRvIHdoYXQgYSAicm91dGluZyBpbnN0YW5jZSIgaXMuDQo+IEhvd2V2ZXIgd2UgZGVmaW5p
dGVseSBzaG91bGQgaGF2ZSBjbGVhciBkZWZpbml0aW9ucyBmb3IgdGhlIHRocmVlIHRlcm1zDQo+
IG1lbnRpb25lZDogcm91dGluZy1pbnN0YW5jZSwgbG9naWNhbCByb3V0ZXIgYW5kIHZpcnR1YWwg
cm91dGVyLg0KPiANCj4gWWVzLCB0aGlzIGlzIGJ5IGRlc2lnbiBvcGVuLWVuZGVkIGJlY2F1c2Ug
b3RoZXJ3aXNlIHdlIHdvdWxkIHByb2JhYmx5DQo+IG5ldmVyIHJlYWNoIGNvbnNlbnN1cyBvbiB3
aGF0IHRoZXNlIHRlcm1zIGV4YWN0bHkgbWVhbi4NCg0KV2hpbGUgdGhlIGRlc2lnbiBuZWVkcyB0
byBiZSBvcGVuLWVuZGVkIGEgc3RhbmRhcmQgc3BlY2lmaWNhdGlvbiBuZWVkcyB0byBiZSBwcmVj
aXNlIGFuZCB1bmFtYmlndW91cy4gVGhlIG5hbWVzIGNhbiBiZSBkaXNjdXNzZWQgYW5kIGNvbXBy
b21pc2VkIGJ1dCB0aGUgbWVhbmluZyBtdXN0IGJlIGNsZWFyLiBGb3IgZXhhbXBsZSwgQ2lzY28g
InZpcnR1YWwgcm91dGVyIiBhbmQgSnVuaXBlciAibG9naWNhbCByb3V0ZXIvc3lzdGVtIiBhcmUg
dGhlIHNhbWUgYnV0IEp1bmlwZXIgInZpcnR1YWwgcm91dGVyIiBhbmQgQ2lzY28gIlZSRi1saXRl
IiBhcmUgdGhlIHNhbWUuIFdoYXQgZG9lcyB0aGUgImxvZ2ljYWwgcm91dGVyIiBpbiB0aGlzIHNw
ZWMgbWVhbj8gV2UgY2FuJ3QganVzdCBzYXkgdGhhdCAiaXQgY2FuIG1lYW4gYW55IG9mIHRob3Nl
Ii4gRm9yIGV4YW1wbGUgaWYgaXQgbWVhbnMgQ2lzY28ncyAidmlydHVhbCByb3V0ZXIiIG9yIEp1
bmlwZXIncyAibG9naWNhbCBzeXN0ZW0iLCBhIGZ1cnRoZXIgZGlzY3Vzc2lvbiBtYXkgYmUgLSBz
aG91bGQgdGhpcyBtb2R1bGUgcmVhbGx5IGNvdmVyIHRoYXQuDQoNCj4gDQo+ID4NCj4gPiBMb2dp
Y2FsIHJvdXRlciBpcyBhIHZlcnkgb3ZlcmxvYWQgdGVybS4gVG9kYXkgdmVuZG9ycyBoYXZlIHZp
cnR1YWxpemVkDQo+IHRoZWlyIHJvdXRpbmcgY2FwYWJpbGl0aWVzIGluIHRoZSBzeXN0ZW0gYW5k
IHByb3ZpZGUgMyBkaWZmZXJlbnQgbGV2ZWxzDQo+IG9mIHJvdXRpbmcgdmlydHVhbGl6YXRpb24u
IExvZ2ljYWwgc3lzdGVtcywgbG9naWNhbCByb3V0ZXJzIGFyZSBzb21lIG9mDQo+IHRoZSBuYW1l
cyB1c2VkIGJ5IHZlbmRvcnMgYW5kIHRob3NlIG9mZmVyIHJvdXRpbmcgYW5kIG1hbmFnZW1lbnQN
Cj4gc2VwYXJhdGlvbi4gRWFjaCBsb2dpY2FsIHN5c3RlbSBoYXMgaXRzIG93biByb3V0aW5nIGlu
c3RhbmNlcyBhbmQNCj4gcm91dGluZyBpbnN0YW5jZXMgY2FuIGhhdmUgbXVsdGlwbGUgcm91dGlu
ZyB0YWJsZXMsIHNvIGl0IGlzIHZlcnkNCj4gaW1wb3J0YW50IHRvIGhhdmUgdmVyeSBwcmVjaXNl
IGRlZmluaXRpb24gb2Ygd2hhdCBpcyByb3V0aW5nIGluc3RhbmNlDQo+IChhbmQgbm90IGNvbXBh
cmUgaXQgd2l0aCBsb2dpY2FsIHJvdXRlcikNCj4gPg0KPiA+IMKgwqDCoMKgIGlkZW50aXR5IHN0
YW5kYXJkLXJvdXRpbmctaW5zdGFuY2Ugew0KPiA+IMKgwqDCoMKgwqDCoCBiYXNlIHJvdXRpbmct
aW5zdGFuY2UtdHlwZTsNCj4gPiDCoMKgwqDCoMKgwqAgZGVzY3JpcHRpb24NCj4gPiDCoMKgwqDC
oMKgwqDCoMKgICJUaGlzIGlkZW50aXR5IHJlcHJlc2VudHMgYSBkZWZhdWx0IHJvdXRpbmcgaW5z
dGFuY2UuIjsNCj4gPiDCoMKgwqDCoCB9DQo+ID4NCj4gPiBXaGF0IGlzIGEgInN0YW5kYXJkLXJv
dXRpbmctaW5zdGFuY2UiPyBXb3VsZCAiZGVmYXVsdC1yb3V0aW5nLQ0KPiBpbnN0YW5jZSIgYmUg
YmV0dGVyPyAic3RhbmRhcmQiIHdvcmRpbmcgbGVhZHMgdG8gInN0YW5kYXJkIHZzLiBub24tDQo+
IHN0YW5kYXJkIiBxdWVzdGlvbiBhbmQgaGludHMgb24gdGhhdCB0aGUgdHdvIGFyZSBkaWZmZXJl
bnQgdHlwZXMuDQo+ICJkZWZhdWx0IiB2cy4gIm5vbi1kZWZhdWx0IiBkb2VzIG5vdCBoYXZlIHRo
YXQgKGF0IGxlYXN0IHRvIG1lKS4NCj4gDQo+IFdlbGwsICJkZWZhdWx0IiBpcyBvdmVybG9hZGVk
LCB0b28sIGFuZCBhbHNvIGhhcyBhIHNwZWNpZmljIG1lYW5pbmcgaW4NCj4gWUFORy4gU3RhbmRh
cmQgaXMgc3VwcG9zZWQgdG8gbWVhbiBwbGFpbiB2YW5pbGxhIHJvdXRlci4gSXQgaXMganVzdCBh
DQo+IG5hbWUuDQoNCkkgZG9uJ3QgaGF2ZSB0byBzcGxpdCBoYWlyIGJldHdlZW4gInN0YW5kYXJk
IiBhbmQgImRlZmF1bHQiIGJ1dCB0aGUgc3BlYyBtdXN0IHBvaW50IG91dCB3aGF0IGEgInN0YW5k
YXJkLXJvdXRpbmctaW5zdGFuY2UiIGlzIC0gaXMgaXQgdGhlIGRlZmF1bHQvYmFzZS9tYXN0ZXIg
bG9naWNhbC1zeXN0ZW0gKENpc2NvIHZpcnR1YWwtcm91dGVyKSBvciB0aGUgZGVmYXVsdC9iYXNl
L21hc3RlciAicm91dGluZy1pbnN0YW5jZSIgKGEgImxvZ2ljYWwtc3lzdGVtIiB3b3VsZCBpbmNs
dWRlIG1hbnkgInJvdXRpbmctaW5zdGFuY2VzIiBsaWtlIFZSRnMpLg0KDQo+IA0KPiA+DQo+ID4g
U2hvdWxkIHRoaXMgc3BlYyBkaXN0aW5ndWlzaCBWUkYvVlIvTFIgYW5kIGhhdmUgY29ycmVzcG9u
ZGluZw0KPiBpZGVudGl0aWVzIGRlZmluZWQ/DQo+IA0KPiBUaGUgaWRlYSBpcyB0aGlzIHdpbGwg
YmUgZG9uZSBpbiBvdGhlciBtb2R1bGVzIHRoYXQgZGVmaW5lIGRhdGEgbW9kZWxzDQo+IGZvciB0
aGVzZSB0eXBlcyBvZiByb3V0aW5nIGluc3RhbmNlcy4gVGhlbiB0aGUgInJvdXRpbmctaW5zdGFu
Y2UiDQo+IGNvbnRhaW5lciBjYW4gYmUgYXVnbWVudGVkIHdpdGggYXJiaXRyYXJ5IGRhdGEsIGJ1
dCBjb25kaXRpb25hbGx5IGZvcg0KPiB0aGF0IHJvdXRpbmcgaW5zdGFuY2UgdHlwZS4NCg0KSSB0
aGluayBpdCBpcyBpbXBvcnRhbnQgdG8gZGVmaW5lIGEgZmV3IHdlbGwga25vd24gcm91dGluZyBp
bnN0YW5jZSB0eXBlcyBpbiB0aGUgYmFzZSBzcGVjIGFzIGEgZ29vZCBmb3VuZGF0aW9uIGZvciBv
dGhlciBtb2R1bGVzLg0KDQo+IA0KPiBBbiBpbXBsZW1lbnRhdGlvbiBtYXkgYWN0dWFsbHkgdXNl
IG11bHRpcGxlIHJvdXRpbmctaW5zdGFuY2UgdHlwZXMgYXQNCj4gdGhlIHNhbWUgdGltZS4NCg0K
VGhhdCdzIGZvciBzdXJlIGFuZCBub3Qgd2hhdCBJJ20gY29uY2VybmVkIHdpdGguDQoNCj4gDQo+
ID4NCj4gPiDCoMKgwqDCoMKgwqDCoMKgIGxlYWYgdHlwZSB7DQo+ID4gwqDCoMKgwqDCoMKgwqDC
oMKgwqAgdHlwZSBpZGVudGl0eXJlZiB7DQo+ID4gwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIGJh
c2Ugcm91dGluZy1pbnN0YW5jZS10eXBlOw0KPiA+IMKgwqDCoMKgwqDCoMKgwqDCoMKgIH0NCj4g
PiDCoMKgwqDCoMKgwqDCoMKgwqDCoCBkZXNjcmlwdGlvbg0KPiA+IMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoCAiVGhlIHJvdXRpbmcgaW5zdGFuY2UgdHlwZSwgcHJpbWFyaWx5IGludGVuZGVkIGZv
cg0KPiA+IMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIGRpc2NyaW1pbmF0aW5nIGFtb25nIGRp
ZmZlcmVudCB0eXBlcyBvZiBsb2dpY2FsIHJvdXRlcnMsDQo+ID4gwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqAgcm91dGUgdmlydHVhbGl6YXRpb24sIG1hc3Rlci1zbGF2ZSBhcnJhbmdlbWVudHMg
ZXRjLiwNCj4gPiDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB3aGlsZSBrZWVwaW5nIGFsbCBy
b3V0aW5nIGluc3RhbmNlcyBpbiB0aGUgc2FtZSBmbGF0DQo+ID4gwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqAgbGlzdC4iOw0KPiA+IMKgwqDCoMKgwqDCoMKgwqAgfQ0KPiA+DQo+ID4gV2hhdCBp
cyB0aGUgIm1hc3Rlci1zbGF2ZSBhcnJhbmdlbWVudHMiPw0KPiANCj4gVGhpcyBjYW1lIGZyb20g
YW4gZWFybHkgcmV2aWV3IGJ5IFRob21hcyBNb3JpbiwgaXQgaGFzIHRvIGRvIHdpdGgNCj4gTVBM
Uy9CR1AgVlBOcyB3aGVyZSBhIG1hc3RlciByb3V0aW5nLWluc3RhbmNlIGV4Y2hhbmdlcyBzZWxl
Y3RlZCByb3V0ZXMNCj4gd2l0aCBlYWNoIFZQTi9WUkYuDQoNCkVpdGhlciBpdCBuZWVkcyB0byBi
ZSBjbGFyaWZpZWQgaW4gdGhlIHNwZWMsIG9yIGl0IGNvdWxkIHNpbXBseSBiZSByZW1vdmVkIHRv
IGF2b2lkIGNvbmZ1c2lvbiBzaW5jZSAicm91dGUgdmlydHVhbGl6YXRpb24iIGNvdmVycyB0aGF0
IGFscmVhZHkuDQoNCj4gDQo+ID4NCj4gPiBEZXBlbmRpbmcgb24gdGhlIGRlZmluaXRpb24gb2Yg
ImxvZ2ljYWwgcm91dGVyIiBhbmQgInJvdXRlDQo+IHZpcnR1YWxpemF0aW9uIiwgdGhlcmUgbWF5
IGFsc28gYmUgY29uY2VybnMgd2l0aCBrZWVwaW5nIGFsbCB0aG9zZSBraW5kcw0KPiBvZiBpbiB0
aGUgc2FtZSBmbGF0IGxpc3QuDQo+IA0KPiBJdCBpcyBzaW1pbGFyIHRvIGludGVyZmFjZXMsIHdo
ZXJlIHBoeXNpY2FsIGFuZCBsb2dpY2FsIGludGVyZmFjZXMgb2YNCj4gYWxsIGtpbmRzIGxpdmUg
aW4gdGhlIHNhbWUgZmxhdCBsaXN0IGFuZCBhcmUgZGlzdGluZ3Vpc2hlZCBieSB0aGUgdHlwZS4N
Cj4gSSB0aGluayBpdCBjb3VsZCB3b3JrLCByZWxhdGlvbnNoaXBzIGFtb25nIHRoZSBpbmRpdmlk
dWFsIHJvdXRpbmcNCj4gaW5zdGFuY2VzIGNhbiBiZSBleHByZXNzZWQgaW4gb3RoZXIgZGF0YS4N
Cg0KSSB3aWxsIGRlZmVyIHRvIG90aGVycyBhYm91dCB0aGUgbWVyaXRzIG9mIGEgZmxhdCBsaXN0
LCBidXQgZm9yIGEgZmxhdCBsaXN0LCB0aGUgYmFzZSBzcGVjIG5lZWRzIHRvIHByb3ZpZGUgYSB3
YXkgdG8gZXhwcmVzcyB0aGUgcmVsYXRpb25zaGlwLg0KDQpKZWZmcmV5DQoNCj4gDQo+IEhhdmlu
ZyBhIHNpbmdsZSBmbGF0IGxpc3QgaGFzIGl0cyBhZHZhbnRhZ2VzLCBmb3IgZXhhbXBsZSB5b3Ug
Y2FuIHRoZW4NCj4gZWFzaWx5IHJlZmVyIHRvIHJvdXRpbmcgaW5zdGFuY2VzIHZpYSBsZWFmcmVm
cyAod2hpY2ggYWxsb3cgb25seSBvbmUNCj4gcGF0aCkuDQo+IA0KPiBDaGVlcnMsIExhZGENCj4g
DQo+ID4NCj4gPiBKZWZmcmV5IFpoYW5nDQo+ID4gRGVhbiBCb2dkYW5vdmljDQo+IA0KPiAtLQ0K
PiBMYWRpc2xhdiBMaG90a2EsIENaLk5JQyBMYWJzDQo+IFBHUCBLZXkgSUQ6IEU3NEU4QzBDDQo=


From nobody Sat Jun 21 05:52:23 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53F401B27C3 for ; Sat, 21 Jun 2014 05:52:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.3
X-Spam-Level: 
X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_44=0.6] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zg8Io3W_cxtu for ; Sat, 21 Jun 2014 05:52:19 -0700 (PDT)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D3BC1B2907 for ; Sat, 21 Jun 2014 05:52:18 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id B513C5407AF; Sat, 21 Jun 2014 14:52: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 SugOQN2gCMgG; Sat, 21 Jun 2014 14:52:11 +0200 (CEST)
Received: from localhost (unknown [172.29.2.202]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 0A45A5403EC; Sat, 21 Jun 2014 14:52:10 +0200 (CEST)
From: Ladislav Lhotka 
To: stephane.litkowski@orange.com, "netmod\@ietf.org" 
In-Reply-To: <26974_1403251511_53A3EB37_26974_17823_1_9E32478DFA9976438E7A22F69B08FF92022780@OPEXCLILM34.corporate.adroot.infra.ftgroup>
References:  <26974_1403251511_53A3EB37_26974_17823_1_9E32478DFA9976438E7A22F69B08FF92022780@OPEXCLILM34.corporate.adroot.infra.ftgroup>
User-Agent: Notmuch/0.18 (http://notmuchmail.org) Emacs/24.3.50.2 (x86_64-apple-darwin13.0.0)
Date: Sat, 21 Jun 2014 14:52:09 +0200
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/5FtxD9DXrU0H95haK8_pesXympI
Subject: Re: [netmod] review of draft-litkowski-netmod-isis-cfg-00
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 21 Jun 2014 12:52:21 -0000

stephane.litkowski@orange.com writes:

> Hi Lada,
>
> Thanks for your review.
>
> Please find inline comments.
>
> Best regards,
>
> Stephane
>
>
> -----Original Message-----
> From: Ladislav Lhotka [mailto:lhotka@nic.cz] 
> Sent: Thursday, June 19, 2014 16:34
> To: netmod@ietf.org; LITKOWSKI Stephane SCE/IBNF
> Subject: review of draft-litkowski-netmod-isis-cfg-00
>
> Hi,
>
> I reviewed the isis module and I-D. I think it is a good start, although some adjustments will be needed to make it work with the core routing data model, see below. I don't address any specific issues of IS-IS configuration.
>
> *** General Comments
>     - As Andy already pointed out, descriptions are often missing or
>       too brief, and the prose in the I-D is also extremely scarce.
>     - An example instance document would be useful, e.g. a reply to
>        as in Appendix A of RFC 7277. (The "sample-skeleton"
>       plugin of pyang can help with generating it.)  
>
> [SLI] Sure I will take this into account.
>
> *** YANG module design
>     - Entries of the "rt:routing-protocol" list (under both "routing"
>       and "routing-state") are designed to support multiple instances
>       of the same protocol. In configuration it means not only that
>       the nodes "isis-cfg", "instances" and "instance" are
>       superfluous, but this design also prevents connecting different
>       ISIS instances to different RIBs.
>
> [SLI] Ok I didn't catch this point, for me there was only one protocol instance per type indexed by its name "isis" or "ospf" in the same routing instance.
> If it's not the case, I would remove the instances for ISIS.

Yes, please. Maybe the routing-cfg draft can be more explicit about the possibility of having multiple instances of the same protocol in the "routing-protocol" list.

> The OSPF model (draft-yeung-netmod-ospf) sounds also to implement a list of instances for OSPF protocol :
> " augment "/rt:routing/rt:routing-instance/rt:routing-protocols/"
>          + "rt:routing-protocol" {
>      list ospf-router {
>
>        description
>          "This is a top-level container for the OSPF router.";
>
>        when "./type=ospf";
>
>        key "version name";
>        leaf version {
>          description
>            "OSPF version.";
>          type uint8 {
>            range "2..3";
>          }
>        }
> "

This should be changed, too.

Lada

>
>
>     - Similarly, state data for each ISIS instance should go straight
>       to the corresponding entry of "routing-protocol" under
>       "routing-state".
>
> [SLI] Ack
>
>     - Nodes in state data should use descriptive names rather than
>       "TLVnnn". TLV numbers are important for the protocol but IMO
>       there is no need to expose operators to them. For instance,
>       "dynamic-hostname" is better than "TLV137".
>
> [SLI] Ok, sometimes TLV numbers are more understable than descriptions :)
>
>     - Grouping "interface-cfg" is used only once, so it is not
>       needed. Other groupings are used at least twice.
>
>   [SLI] Ack
>
>     - A type definition for ISO addresses might be useful.
>
> [SLI] Ack
>
> *** Specific YANG issues
>     - The module is invalid, I am attaching a diff file with
>       necessary changes. Module validity should always be verified
>       before posting an I-D, e.g. with pyang.
>
> [SLI] Ok , I checked it but without importing modules, so only syntax checking was done.
>
>     - The argument of "namespace" should be an URI, e.g. urn:TBD.
>
> [SLI] Ok
>
>     - Arguments of some "augment" statements are broken, see the
>       attached diff. In particular, they must not contain trailing
>       slashes, see ABNF production "absolute-schema-nodeid".
>     - The module should follow the guidelines of RFC 6087, they can
>       be checked using
>
>       pyang --ietf isis.yang
>
> *** Formal issues
>     - The module text should be wrapped in
>
>        file "isis@2014-XX-XX.yang"
>       ...
>       
>
>       so that it can be easily extracted with rfcstrip. 
>     - Assuming the module is bound for standard track, its name
>       should be "ietf-isis".
>     - Some descriptions exceed the line length limit of 72 characters,
>       line breaks should be inserted.
>
> [SLI] Will be fixed.
>
>
> Lada
>
> _________________________________________________________________________________________________________________________
>
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
> Thank you.
>

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


From nobody Sat Jun 21 06:11:51 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 966301A01C9 for ; Sat, 21 Jun 2014 06:11:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.3
X-Spam-Level: 
X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_44=0.6] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QyRAjfswosQ4 for ; Sat, 21 Jun 2014 06:11:42 -0700 (PDT)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE8D81A0387 for ; Sat, 21 Jun 2014 06:11:41 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 11E305407AF; Sat, 21 Jun 2014 15:11:40 +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 8aEkMWN3mICw; Sat, 21 Jun 2014 15:11:34 +0200 (CEST)
Received: from localhost (unknown [172.29.2.202]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 6D4365403EC; Sat, 21 Jun 2014 15:11:33 +0200 (CEST)
From: Ladislav Lhotka 
To: "t.petch" , stephane.litkowski@orange.com, netmod@ietf.org
In-Reply-To: <03a401cf8c73$bc2e1ca0$4001a8c0@gateway.2wire.net>
References:  <26974_1403251511_53A3EB37_26974_17823_1_9E32478DFA9976438E7A22F69B08FF92022780@OPEXCLILM34.corporate.adroot.infra.ftgroup> <03a401cf8c73$bc2e1ca0$4001a8c0@gateway.2wire.net>
User-Agent: Notmuch/0.18 (http://notmuchmail.org) Emacs/24.3.50.2 (x86_64-apple-darwin13.0.0)
Date: Sat, 21 Jun 2014 15:11:32 +0200
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/v866kg_xrOXT59aHOCR2Dfa1TAs
Subject: Re: [netmod] review of draft-litkowski-netmod-isis-cfg-00
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 21 Jun 2014 13:11:48 -0000

"t.petch"  writes:

> I would consult the isis list about the use of TLVnnn as names.
>
> For me, that is very much a part of is-is, that is, when I see TLVnnn I
> know I am dealing with someone who is familiar with is-is.

Yes, it's like those monks telling jokes just by calling out numbers. :-)

Anyway, the output of "show isis" commands in the major CLIs doesn't contain these numbers.

Lada  

>
> Tom Petch
>
>
> ----- Original Message -----
> From: 
> To: "Ladislav Lhotka" ; 
> Sent: Friday, June 20, 2014 9:05 AM
> Subject: Re: [netmod] review of draft-litkowski-netmod-isis-cfg-00
>
>
>> Hi Lada,
>>
>> Thanks for your review.
>>
>> Please find inline comments.
>>
>> Best regards,
>>
>> Stephane
>>
>>
>> -----Original Message-----
>> From: Ladislav Lhotka [mailto:lhotka@nic.cz]
>> Sent: Thursday, June 19, 2014 16:34
>> To: netmod@ietf.org; LITKOWSKI Stephane SCE/IBNF
>> Subject: review of draft-litkowski-netmod-isis-cfg-00
>>
>> Hi,
>>
>> I reviewed the isis module and I-D. I think it is a good start,
> although some adjustments will be needed to make it work with the core
> routing data model, see below. I don't address any specific issues of
> IS-IS configuration.
>>
>> *** General Comments
>>     - As Andy already pointed out, descriptions are often missing or
>>       too brief, and the prose in the I-D is also extremely scarce.
>>     - An example instance document would be useful, e.g. a reply to
>>        as in Appendix A of RFC 7277. (The "sample-skeleton"
>>       plugin of pyang can help with generating it.)
>>
>> [SLI] Sure I will take this into account.
>>
>> *** YANG module design
>>     - Entries of the "rt:routing-protocol" list (under both "routing"
>>       and "routing-state") are designed to support multiple instances
>>       of the same protocol. In configuration it means not only that
>>       the nodes "isis-cfg", "instances" and "instance" are
>>       superfluous, but this design also prevents connecting different
>>       ISIS instances to different RIBs.
>>
>> [SLI] Ok I didn't catch this point, for me there was only one protocol
> instance per type indexed by its name "isis" or "ospf" in the same
> routing instance.
>> If it's not the case, I would remove the instances for ISIS.
>> The OSPF model (draft-yeung-netmod-ospf) sounds also to implement a
> list of instances for OSPF protocol :
>> " augment "/rt:routing/rt:routing-instance/rt:routing-protocols/"
>>          + "rt:routing-protocol" {
>>      list ospf-router {
>>
>>        description
>>          "This is a top-level container for the OSPF router.";
>>
>>        when "./type=ospf";
>>
>>        key "version name";
>>        leaf version {
>>          description
>>            "OSPF version.";
>>          type uint8 {
>>            range "2..3";
>>          }
>>        }
>> "
>>
>>
>>     - Similarly, state data for each ISIS instance should go straight
>>       to the corresponding entry of "routing-protocol" under
>>       "routing-state".
>>
>> [SLI] Ack
>>
>>     - Nodes in state data should use descriptive names rather than
>>       "TLVnnn". TLV numbers are important for the protocol but IMO
>>       there is no need to expose operators to them. For instance,
>>       "dynamic-hostname" is better than "TLV137".
>>
>> [SLI] Ok, sometimes TLV numbers are more understable than descriptions
> :)
>>
>>     - Grouping "interface-cfg" is used only once, so it is not
>>       needed. Other groupings are used at least twice.
>>
>>   [SLI] Ack
>>
>>     - A type definition for ISO addresses might be useful.
>>
>> [SLI] Ack
>>
>> *** Specific YANG issues
>>     - The module is invalid, I am attaching a diff file with
>>       necessary changes. Module validity should always be verified
>>       before posting an I-D, e.g. with pyang.
>>
>> [SLI] Ok , I checked it but without importing modules, so only syntax
> checking was done.
>>
>>     - The argument of "namespace" should be an URI, e.g. urn:TBD.
>>
>> [SLI] Ok
>>
>>     - Arguments of some "augment" statements are broken, see the
>>       attached diff. In particular, they must not contain trailing
>>       slashes, see ABNF production "absolute-schema-nodeid".
>>     - The module should follow the guidelines of RFC 6087, they can
>>       be checked using
>>
>>       pyang --ietf isis.yang
>>
>> *** Formal issues
>>     - The module text should be wrapped in
>>
>>        file "isis@2014-XX-XX.yang"
>>       ...
>>       
>>
>>       so that it can be easily extracted with rfcstrip.
>>     - Assuming the module is bound for standard track, its name
>>       should be "ietf-isis".
>>     - Some descriptions exceed the line length limit of 72 characters,
>>       line breaks should be inserted.
>>
>> [SLI] Will be fixed.
>>
>>
>> Lada
>>
>>
> ________________________________________________________________________
> _________________________________________________
>>
>> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc
>> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez
> recu ce message par erreur, veuillez le signaler
>> a l'expediteur et le detruire ainsi que les pieces jointes. Les
> messages electroniques etant susceptibles d'alteration,
>> Orange decline toute responsabilite si ce message a ete altere,
> deforme ou falsifie. Merci.
>>
>> This message and its attachments may contain confidential or
> privileged information that may be protected by law;
>> they should not be distributed, used or copied without authorisation.
>> If you have received this email in error, please notify the sender and
> delete this message and its attachments.
>> As emails may be altered, Orange is not liable for messages that have
> been modified, changed or falsified.
>> Thank you.
>>
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>

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


From nobody Mon Jun 23 01:26:26 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89C301B28BB for ; Mon, 23 Jun 2014 01:26:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.8
X-Spam-Level: 
X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eDdiuSHJAGva for ; Mon, 23 Jun 2014 01:26:21 -0700 (PDT)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E2A01B28AC for ; Mon, 23 Jun 2014 01:26:21 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id E0CFC5403C5; Mon, 23 Jun 2014 10:26:18 +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 b3IHrKx4wqa3; Mon, 23 Jun 2014 10:26:13 +0200 (CEST)
Received: from localhost (unknown [172.29.2.201]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id CD9BD540336; Mon, 23 Jun 2014 10:26:11 +0200 (CEST)
From: Ladislav Lhotka 
To: "Jeffrey \(Zhaohui\) Zhang" , Dean Bogdanovic , "netmod\@ietf.org" 
In-Reply-To: <18cd777ffb9d4df6b0966dd1b3dd822b@BY2PR05MB079.namprd05.prod.outlook.com>
References:   <18cd777ffb9d4df6b0966dd1b3dd822b@BY2PR05MB079.namprd05.prod.outlook.com>
User-Agent: Notmuch/0.18 (http://notmuchmail.org) Emacs/24.3.50.2 (x86_64-apple-darwin13.0.0)
Date: Mon, 23 Jun 2014 10:26:08 +0200
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/dG3MUNttx_ubke-kBRT3zZEyAVc
Cc: Kiran Agrahara Sreenivasa 
Subject: Re: [netmod] Questions/comments on draft-ietf-netmod-routing-cfg
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 23 Jun 2014 08:26:24 -0000

"Jeffrey (Zhaohui) Zhang"  writes:

> Lada,
>
>> -----Original Message-----
>> From: Ladislav Lhotka [mailto:lhotka@nic.cz]
>> Sent: Friday, June 20, 2014 7:26 AM
>> To: Jeffrey (Zhaohui) Zhang; Dean Bogdanovic; netmod@ietf.org
>> Cc: Derek Man-Kit Yeung (myeung); Kiran Agrahara Sreenivasa
>> Subject: Re: Questions/comments on draft-ietf-netmod-routing-cfg
>>=20
>> "Jeffrey (Zhaohui) Zhang"  writes:
>>=20
>> > Ladislav,
>> >
>> > Dean and I have some late questions and comments. We came across these
>> while trying to work on the OSPF YANG model.
>> >
>> > -----------
>> >
>> > The spec mentions in several places something like the following:
>> >
>> > =C2=A0=C2=A0 Each routing protocol instance is connected to exactly on=
e RIB for
>> > =C2=A0=C2=A0 each address family that the routing protocol instance su=
pports.
>> >
>> > My understanding is that the address family mentioned above does not
>> include SAFI. Because of that, a routing protocol like BGP may connect
>> to multiple RIBs in the same family (RIB for unicast and RIB for
>> multicast RPF purpose in case of incongruent multicast topology) so the
>> above statement is not correct.
>>=20
>> This is quite flexible since address family is defined via identities. I
>> can imagine one implementation using only "ipv4" and "ipv6" (defined in
>> ietf-routing) whilst other implementation could use "ipv[46]-unicast"
>> (defined in ietf-ipv[46]-unicast-routing) and "ipv[46]-multicast" (to be
>> defined in a module for unicast routing), that means including SAFI.
>
> Address Family has very specific meanings, typically only refer to IPv4/I=
Pv6 to my understanding. If we want to extend that to include SAFI, then th=
e spec must point it out. More below related to MT.

Both Cisco and Juniper docs use terms like "IPv6 multicast address family" =
or "MCAST-VPN address family" that clearly include SAFI as well.=20=20=20=20

For better or worse, in the ietf-routing YANG module "address-family" leaf =
is defined with the type

         type identityref {
           base address-family;
         }

so its meaning follows from that, including the fact that the identity is e=
xtensible. In my view, it is a feature, not bug.

>
>>=20
>> >
>> > This is also a problem in case of Multi-topology. Each topology has
>> its own RIB and a protocol instance like OSPF can connect to multiple MT
>> RIBs.
>>=20
>> Two possible solutions come to my mind:
>>=20
>> 1. You could derive new address family identities from "ipv4-unicast"
>> etc. so that you can assign a unique address family to multiple tables.
>>=20
>> 2. You could have one connected RIB e.g. for "ipv4-unicast" and define
>> two or more RIBs for each topology as recipients of the connected RIB.
>> So, in effect, the (single) connected RIB contains routes for all
>> topologies and these are then split via route filters to the per-
>> topology RIBs.
>>=20
>> Does it make sense?
>
> Compare the two, I don't like #2 because it adds an unnecessary indirecti=
on. I don't think we want to overload "Address Family" further to include t=
opology either. In many implementations, actual RIBs are per (routing-insta=
nce, AFI, SAFI, topology) and it may be extended further. Therefore, the be=
st option is to simply remove the restriction that one protocol instance is=
 connected to exactly one RIB per address family.

This restriction is only relevant for the "connected-rib" list. If you want=
, you can add configuration parameters to associate other RIBs directly wit=
h a routing protocol instance.

IMO, the common use case for MT are incongruent IPv4 and IPv6 topologies, a=
nd the core routing data model can handle this directly and easily.

Also note that the "routing-cfg" document has already been submitted to IES=
G for publication, so your comments come really late.=20=20=20

>
>>=20
>> >
>> > ------
>> >
>> > 5.1.  Routing Instance
>> >
>> >    Each routing instance in the core routing data model represents a
>> >    logical router.  The exact semantics of this term are left to
>> >    implementations.  For example, routing instances may be completely
>> >    isolated virtual routers or, alternatively, they may internally sha=
re
>> >    certain information.
>> >
>> >    ...
>> >
>> >    An implementation MAY support multiple types of logical routers
>> >    simultaneously.  Instances of all routing instance types are
>> >    organized as entries of the same flat "routing-instance" list.  In
>> >    order to discriminate routing instances belonging to different type=
s,
>> >    the "type" leaf is defined as a child of the "routing-instance" nod=
e.
>> >
>> > The spec purposely left it fuzzy as to what a "routing instance" is.
>> However we definitely should have clear definitions for the three terms
>> mentioned: routing-instance, logical router and virtual router.
>>=20
>> Yes, this is by design open-ended because otherwise we would probably
>> never reach consensus on what these terms exactly mean.
>
> While the design needs to be open-ended a standard specification needs to=
 be precise and unambiguous. The names can be discussed and compromised but=
 the meaning must be clear. For example, Cisco "virtual router" and Juniper=
 "logical router/system" are the same but Juniper "virtual router" and Cisc=
o "VRF-lite" are the same. What does the "logical router" in this spec mean=
? We can't just say that "it can mean any of those". For example if it mean=
s Cisco's "virtual router" or Juniper's "logical system", a further discuss=
ion may be - should this module really cover that.

The term "logical router" is used in a very general sense, and the document=
 clearly says so ("no semantics"). The other terms are used only as example=
s what it could possibly mean, to make the spec more accessible.

>
>>=20
>> >
>> > Logical router is a very overload term. Today vendors have virtualized
>> their routing capabilities in the system and provide 3 different levels
>> of routing virtualization. Logical systems, logical routers are some of
>> the names used by vendors and those offer routing and management
>> separation. Each logical system has its own routing instances and
>> routing instances can have multiple routing tables, so it is very
>> important to have very precise definition of what is routing instance
>> (and not compare it with logical router)
>> >
>> > =C2=A0=C2=A0=C2=A0=C2=A0 identity standard-routing-instance {
>> > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 base routing-instance-type;
>> > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 description
>> > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "This identity repres=
ents a default routing instance.";
>> > =C2=A0=C2=A0=C2=A0=C2=A0 }
>> >
>> > What is a "standard-routing-instance"? Would "default-routing-
>> instance" be better? "standard" wording leads to "standard vs. non-
>> standard" question and hints on that the two are different types.
>> "default" vs. "non-default" does not have that (at least to me).
>>=20
>> Well, "default" is overloaded, too, and also has a specific meaning in
>> YANG. Standard is supposed to mean plain vanilla router. It is just a
>> name.
>
> I don't have to split hair between "standard" and "default" but the spec =
must point out what a "standard-routing-instance" is - is it the default/ba=
se/master logical-system (Cisco virtual-router) or the default/base/master =
"routing-instance" (a "logical-system" would include many "routing-instance=
s" like VRFs).
>

I think the ietf-routing module makes it pretty clear:

         leaf type {
           type identityref {
             base routing-instance-type;
           }
           default "rt:standard-routing-instance";
           description
             "The type of the routing instance.";
         }

The purpose of the "type" is to allow for defining a new routing instance t=
ype and augment configuration or state data conditionally for that type. Th=
e "standard-routing-instance" is just the default value to start from, it h=
as no other meaning.=20


>>=20
>> >
>> > Should this spec distinguish VRF/VR/LR and have corresponding
>> identities defined?
>>=20
>> The idea is this will be done in other modules that define data models
>> for these types of routing instances. Then the "routing-instance"
>> container can be augmented with arbitrary data, but conditionally for
>> that routing instance type.
>
> I think it is important to define a few well known routing instance types=
 in the base spec as a good foundation for other modules.

This is outside the scope of the core routing data model, and should be don=
e by routing experts, not in the NETMOD group. There are other indispensabl=
e elements that have to be worked out before the routing data model can be =
really useful, e.g. routing protocols and route filters.

>
>>=20
>> An implementation may actually use multiple routing-instance types at
>> the same time.
>
> That's for sure and not what I'm concerned with.
>
>>=20
>> >
>> > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 leaf type {
>> > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 type iden=
tityref {
>> > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 base routing-instance-type;
>> > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 }
>> > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 descripti=
on
>> > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 "The routing instance type, primarily intended for
>> > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 discriminating among different types of logical routers,
>> > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 route virtualization, master-slave arrangements etc.,
>> > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 while keeping all routing instances in the same flat
>> > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 list.";
>> > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 }
>> >
>> > What is the "master-slave arrangements"?
>>=20
>> This came from an early review by Thomas Morin, it has to do with
>> MPLS/BGP VPNs where a master routing-instance exchanges selected routes
>> with each VPN/VRF.
>
> Either it needs to be clarified in the spec, or it could simply be remove=
d to avoid confusion since "route virtualization" covers that already.

This is actually a typo - it should be "router virtualization". My understa=
nding of this term is that a virtual router is isolated and exchanges routi=
ng information with other routers only through routing protocols.

Anyway, these are really only examples and I think it is sufficiently clear=
 that the core routing data model doesn't use these terms for defining any =
semantics.=20=20

Lada

>
>>=20
>> >
>> > Depending on the definition of "logical router" and "route
>> virtualization", there may also be concerns with keeping all those kinds
>> of in the same flat list.
>>=20
>> It is similar to interfaces, where physical and logical interfaces of
>> all kinds live in the same flat list and are distinguished by the type.
>> I think it could work, relationships among the individual routing
>> instances can be expressed in other data.
>
> I will defer to others about the merits of a flat list, but for a flat li=
st, the base spec needs to provide a way to express the relationship.
>
> Jeffrey
>
>>=20
>> Having a single flat list has its advantages, for example you can then
>> easily refer to routing instances via leafrefs (which allow only one
>> path).
>>=20
>> Cheers, Lada
>>=20
>> >
>> > Jeffrey Zhang
>> > Dean Bogdanovic
>>=20
>> --
>> Ladislav Lhotka, CZ.NIC Labs
>> PGP Key ID: E74E8C0C

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


From nobody Mon Jun 23 02:28:19 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2FAC1B2A26; Mon, 23 Jun 2014 02:28:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.499
X-Spam-Level: 
X-Spam-Status: No, score=0.499 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OvlNcEjo1aEG; Mon, 23 Jun 2014 02:28:13 -0700 (PDT)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BCAA1B2791; Mon, 23 Jun 2014 02:28:12 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id A51C03A44; Mon, 23 Jun 2014 11:28:10 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id yEfhQZIQvOue; Mon, 23 Jun 2014 11:28:07 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 23 Jun 2014 11:28:09 +0200 (CEST)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5DF702002F; Mon, 23 Jun 2014 11:28:09 +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 QUG7ZK4p349B; Mon, 23 Jun 2014 11:28:07 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 45D362002C; Mon, 23 Jun 2014 11:28:07 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 418132D9535B; Mon, 23 Jun 2014 11:28:07 +0200 (CEST)
Date: Mon, 23 Jun 2014 11:28:07 +0200
From: Juergen Schoenwaelder 
To: proceedings@ietf.org
Message-ID: <20140623092807.GA16737@elstar.local>
Mail-Followup-To: proceedings@ietf.org, netmod@ietf.org
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="oyUTqETQ0mS9luUI"
Content-Disposition: inline
User-Agent: Mutt/1.4.2.3i
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/BifgkUhyNTlaMlrrlgij-fKqq7k
Cc: netmod@ietf.org
Subject: [netmod] minutes of the NETMOD 2014-06-11 virtual interim meeting
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
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, 23 Jun 2014 09:28:16 -0000

--oyUTqETQ0mS9luUI
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

Hi,

attached please find the minutes of the NETMOD virtual interim
meeting that took place on 2014-06-11.

/js

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

--oyUTqETQ0mS9luUI
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="netmod-2014-06-11-minutes.txt"

=============================================================
NETCONF Data Modeling Language WG (netmod)
2nd YANG 1.1 Virtual Interim
Wednesday, June 11th, 2014, 16:00-16:00 CEST
Minutes Juergen Schoenwaelder
=============================================================

* Participants

  - JS = Juergen Schoenwaelder
  - AB = Andy Bierman
  - KW = Kent Watsen
  - MB = Martin Bjorklund
  - PO = Peyman Owladi
  - DR = David Reid
  - AZ = Alex Zhankin
  - LL = Lada Lotka
  - PH = Peter van Horne
  - GH = Giles Heron

* Summary

  After a short review of the outcome of the last virtual interim
  meeting, the group started going through the open issues in order to
  discussion solutions. Strawman proposals for solutions were
  identified for Y01-Y06. Since MB will be unavailable the next two
  weeks, it was decided to skip the next two virtual interim meetings
  and to continue on July 2nd.

  It was agreed that JS will track the state changes of the issues in
  the issues list.  MB will start work on a first I-D for YANG 1.1. It
  will contain a section with a high-level summary of the changes since
  RFC 6020 that will be part of the final RFC plus an additional
  section in the appendix cross referencing the issues list. This
  section is intended to make reviews of changes easier and will be
  removed from the final RFC.

* Y55 clarify type in union

  MB added this issue as discussed in the last virtual interim
  meeting.

  Proposal: Open this issue. JS to confirm this on the mailing list.

* additional clarification issue on the mailing list

  AB: Did recently send an additional clarification issues to the
      list. 
  MB: I believe this falls into an existing issue (Y41)
  AB: Why is the server making decisions whether or not to return nodes?
  MB: I am not sure I understand the question. It always depends on the
      semantics of the particular leaf.
  AB: A mandatory false node will not be returned if and only if it
      does not exist (ignoring filters and access control for a
      moment).
  MB: Depends on the semantics of the leaf.
  PO: Non-existence can have specific meaning.
  KW: Mandatory true would mean that a leaf always exist.
  MB: Is this something to be clarified?
  AB: I will take a look at the text to see whether something needs
      changing.

* Y01: allow boolean if-feature

  AB: I am fine with accepting Y01-01, the specification should get 
      the operator precedence right.
  AB: There might be an issue with a feature called 'and'.
  JS: This clash should only be an issue for
         if-feature and; 
      or
         if-feature or;
      and these can be handled as special cases.
  MB: Will add text to make sure that theoretical clashes with 
      features like 'and' and 'or' are well defined.

  Proposal: Adopt Y01-01, MB to work out the edits.

* Y02: allow must in input, output, and notification

  AB: Why do we need these top-level must expressions? When are
      they evaluated? I am fine with Y02-01, not sure about Y02-02.
  PO: I believe mandatory is essentially like a must in a top-level.
  AB: YANG does not allow top-level mandatories. The reason is that
      in practice not all servers may have mandatories all the time,
      e.g. when a module is loaded.
  MB: If you load a module, you need to provide a factory default 
      because otherwise the module would be invalid.
  PO: Here is an example: There must not be more than 100 VLANs on
      this port. This must applies for a top-level list. The logical
      place for the must statement is at the top-level.
  MB: We have the same issue with an empty container.
  AB: What is the context node for the must? The root?
  AB: Should we also consider rpcs? Or does this only apply to data
      nodes?
  MB: It seems Y02-02 does not work because of unclear context, so we
      better go with Y02-01.

  Proposal: Adopt Y02-01. AB and MB support this. MB to work out the
  edits.

* Y03 allow if-feature in refine

  LL: What does it mean? Assume feature in A, grouping in B. 
      C imports B.
  MB: The grouping does not use the feature.
  LL: Yes, I got confused.
  AB: Are there any problems if a refine rewrites an if-feature,
      e.g., adding or removing something from the expression?
  MB: But grouping expansion happens in the usual way, you could always
      cut and paste the grouping and add the if-feature as you like.
  LL: I think this is OK.
  KW: Can this break existing clients?
  LL: No, a server would have to advertise a new module.
  KW: I am not sure whether there could be an issue.

  Proposal: Go along with Y03-01. KW to double check that there is no
  issue with dependencies and versioning.

* Y04 accessible tree in xpath in notifs and rpc

  JS: Where has this become a problem?
  MB: Look at the example.
  LL: Is this similar to something in the SMI?
  AB: This does never happen in SMI.
  MB: The current situation is somewhat wired.
  PO: If you define a type in a top-level module, you can't use that
      type inside of a notification?
  MB: Yes, this is kind of true. It depends on the path and whether
      you have the same structure in a notification.
  PO: Are we sure this is a corner case? Reusing a type in a 
      notification may happen more frequently.
  MB: If we make this change (Y04-01), then existing notifications
      may be illegal.
  AB: We need to rule out solutions that make YANG 1.0 modules
      illegal.
  MB: This is really a bug in the YANG 1.0 specification and we better
      fix it.
  AB: I am in favor of Y04-04.
  MB: But how do we make the bref path legal in YANG 1.0?
  AB: When is this path expression actually evaluated? When the
      event occurs, when the notification is being prepared?
  PO: This seems to tighten the restrictions but conflicts with
      backward compatibility.
  AB: Why do we need to be able to reference things in the
      notification?
  AB: If the notification is returning copies of stuff in the data
      tree, everything should be fine. I am concerned about breaking
      things by changing the meaning of the path statement.
  AB: I believe this is a really corner case and any solution must
      keep existing notifications valid. It may require a new keyword
      to introduce different semantics.
  MB: What is the initial context node of a path statement in a
      notification?
  MB: LL, is the example in Y04 is valid?
  LL: It could be valid - current() means the bref in the
      notification.
  PO: Solution Y04-02 is _not_ problematic since top-level names can't
      clash according to RFC 6020 section 6.2.1.

  Proposal: Go along with Y04-02 now that we have realized that it
  actually works.

* Y05 unprefixed path in top-level typedef

  AB: I am fine with the first solution.
  PO: The binding should be done where the typedef is evaluated.
  JS: I agree with PO.
  MB: This would be solution Y05-03.

  Proposal: MB to write down solution Y05-03 and once done we get back
  to this issue.

* Y06 escaped characters in double quoted strings

  LL: A third solution is that \x means x.
  MB: Randy Presuhn likes Y06-02.
  LL: There may be backwards compatibility issue.
  PO: We pay attention to existing implementations or, if something is
      undefined, we are free to choose any interpretation.
  JS: What does "all known implementations" mean?
  MB: At least YumaPro and Tail-f.
  JS: This is a much more narrow statement.
  MB: Guidelines should say better use single quotes for pattern.
  PO: Could others have copied RFC 6536 style?
  MB: The only hard backwards compatible solution is to leave this
      undefined forever.
  LL: I am in favor for Y06-02.
  KW: I think this is the best option.
  MB: I am in favor of Y06-02.
  JS: I am in favor of Y06-02 as well.
  AB: I am fine with this, it seems a regression bug fix.

  Proposal: Move forward with Y06-02.

--oyUTqETQ0mS9luUI--


From nobody Mon Jun 23 05:59:15 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5E341B293F for ; Mon, 23 Jun 2014 05:59:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p8Pg82DFTX7a for ; Mon, 23 Jun 2014 05:59:10 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0188.outbound.protection.outlook.com [207.46.163.188]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8897D1B2939 for ; Mon, 23 Jun 2014 05:59:09 -0700 (PDT)
Received: from BY2PR05MB079.namprd05.prod.outlook.com (10.242.38.16) by CO1PR05MB426.namprd05.prod.outlook.com (10.141.74.24) with Microsoft SMTP Server (TLS) id 15.0.959.24; Mon, 23 Jun 2014 12:59:06 +0000
Received: from BY2PR05MB079.namprd05.prod.outlook.com ([169.254.8.228]) by BY2PR05MB079.namprd05.prod.outlook.com ([169.254.8.228]) with mapi id 15.00.0969.007; Mon, 23 Jun 2014 12:59:05 +0000
From: "Jeffrey (Zhaohui) Zhang" 
To: Ladislav Lhotka , Dean Bogdanovic , "netmod@ietf.org" 
Thread-Topic: Questions/comments on draft-ietf-netmod-routing-cfg
Thread-Index: Ac+L5mG6QCip6E9wRnWAlQy1vx1YdgAlBfOAAACoQiAAj+tmAAAIpPrQ
Date: Mon, 23 Jun 2014 12:59:04 +0000
Message-ID: 
References:   <18cd777ffb9d4df6b0966dd1b3dd822b@BY2PR05MB079.namprd05.prod.outlook.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [66.129.241.13]
x-microsoft-antispam: BCL:0;PCL:0;RULEID:
x-forefront-prvs: 025100C802
x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(428001)(25584003)(13464003)(377454003)(52314003)(199002)(51704005)(189002)(81342001)(54356999)(575784001)(74316001)(76176999)(81542001)(77096002)(4396001)(92566001)(19580395003)(76482001)(85852003)(80022001)(21056001)(83322001)(66066001)(50986999)(64706001)(74502001)(46102001)(20776003)(74662001)(99286002)(95666004)(105586002)(87936001)(101416001)(83072002)(33646001)(85306003)(19580405001)(77982001)(99396002)(31966008)(93886003)(79102001)(76576001)(106356001)(86362001)(2656002)(106276001); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR05MB426; H:BY2PR05MB079.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; 
received-spf: None (: juniper.net does not designate permitted sender hosts)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=zzhang@juniper.net; 
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/8OQy4xkZb104QcbfZviB20m7C6k
Cc: Kiran Agrahara Sreenivasa 
Subject: Re: [netmod] Questions/comments on draft-ietf-netmod-routing-cfg
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 23 Jun 2014 12:59:14 -0000

TGFkYSwNCg0KVGhlIGRpc2N1c3Npb25zIGJhc2ljYWxseSBib2lsIGRvd24gdG8gdHdvIG1haW4g
cG9pbnRzOg0KDQotIEkgYmVsaWV2ZSB0aGUgc3BlYyBzaG91bGQgaGF2ZSB3ZWxsIGRlZmluZWQg
c2VtYW50aWNzIGZvciBzb21lIHdlbGwta25vd24gdHlwZXMgb2YgInJvdXRpbmctaW5zdGFuY2Vz
Ii4gT3RoZXJ3aXNlIGl0IGlzIHRvbyBsb29zZSB0byBiZSB0aGUgZm91bmRhdGlvbiBmb3IgZnV0
dXJlIHdvcmsgKGUuZy4gdGhlIG9uLWdvaW5nIE9TUEYgWUFORyBtb2RlbCB3b3JrKS4gVGhhdCBk
b2VzIG5vdCBwcmV2ZW50IHRoZSBmbGV4aWJpbGl0eSBmb3IgZnV0dXJlIGV4dGVuc2lvbnMuDQoN
Ci0gSSB0aGluayB0aGUgc3BlYyBpcyB0b28gcmVzdHJpY3RpdmUgaW4gc2F5aW5nICJFYWNoIHJv
dXRpbmcgcHJvdG9jb2wgaW5zdGFuY2UgaXMgY29ubmVjdGVkIHRvIGV4YWN0bHkgb25lIFJJQiBm
b3IgZWFjaCBhZGRyZXNzIGZhbWlseSB0aGF0IHRoZSByb3V0aW5nIHByb3RvY29sIGluc3RhbmNl
IHN1cHBvcnRzIi4gV2UgY2FuIG1peCBBRiBhbmQgU0FGIHRvZ2V0aGVyIGFuZCBzaW1wbHkgc2F5
IEFkZHJlc3MgRmFtaWx5IChpZiB3ZSBtYWtlIGl0IGNsZWFyKSBidXQgd2l0aCB0aGUgY29uc2lk
ZXJhdGlvbiBvZiBNVCB0aGUgc3RhdGVtZW50IGlzIGp1c3Qgbm90IGNvcnJlY3QuDQoNCkkgYW0g
bW9yZSBjb25jZXJuZWQgd2l0aCB0aGUgZmlyc3QgcG9pbnQuDQoNCkkgZG9uJ3QgdGhpbmsgdGhp
cyBpcyB0b28gbGF0ZS4gVGhlcmUgaXMgc3RpbGwgSUVURiBsYXN0IGNhbGwgYW5kIEkgYW0gcG9z
dGluZyBteSBjb21tZW50cyBoZXJlLiBJZiB0aGVyZSBpcyBlbm91Z2ggY29uc2Vuc3VzIHRvIG15
IHBvaW50cywgdGhlbiBuZWNlc3NhcnkgY2hhbmdlcyBuZWVkIHRvIGhhcHBlbi4gSWYgbm90LCBJ
J2xsIGFjY2VwdCB0aGF0Lg0KDQpUaGFua3MuDQpKZWZmcmV5DQoNCj4gLS0tLS1PcmlnaW5hbCBN
ZXNzYWdlLS0tLS0NCj4gRnJvbTogTGFkaXNsYXYgTGhvdGthIFttYWlsdG86bGhvdGthQG5pYy5j
el0NCj4gU2VudDogTW9uZGF5LCBKdW5lIDIzLCAyMDE0IDQ6MjYgQU0NCj4gVG86IEplZmZyZXkg
KFpoYW9odWkpIFpoYW5nOyBEZWFuIEJvZ2Rhbm92aWM7IG5ldG1vZEBpZXRmLm9yZw0KPiBDYzog
RGVyZWsgTWFuLUtpdCBZZXVuZyAobXlldW5nKTsgS2lyYW4gQWdyYWhhcmEgU3JlZW5pdmFzYQ0K
PiBTdWJqZWN0OiBSRTogUXVlc3Rpb25zL2NvbW1lbnRzIG9uIGRyYWZ0LWlldGYtbmV0bW9kLXJv
dXRpbmctY2ZnDQo+IA0KPiAiSmVmZnJleSAoWmhhb2h1aSkgWmhhbmciIDx6emhhbmdAanVuaXBl
ci5uZXQ+IHdyaXRlczoNCj4gDQo+ID4gTGFkYSwNCj4gPg0KPiA+PiAtLS0tLU9yaWdpbmFsIE1l
c3NhZ2UtLS0tLQ0KPiA+PiBGcm9tOiBMYWRpc2xhdiBMaG90a2EgW21haWx0bzpsaG90a2FAbmlj
LmN6XQ0KPiA+PiBTZW50OiBGcmlkYXksIEp1bmUgMjAsIDIwMTQgNzoyNiBBTQ0KPiA+PiBUbzog
SmVmZnJleSAoWmhhb2h1aSkgWmhhbmc7IERlYW4gQm9nZGFub3ZpYzsgbmV0bW9kQGlldGYub3Jn
DQo+ID4+IENjOiBEZXJlayBNYW4tS2l0IFlldW5nIChteWV1bmcpOyBLaXJhbiBBZ3JhaGFyYSBT
cmVlbml2YXNhDQo+ID4+IFN1YmplY3Q6IFJlOiBRdWVzdGlvbnMvY29tbWVudHMgb24gZHJhZnQt
aWV0Zi1uZXRtb2Qtcm91dGluZy1jZmcNCj4gPj4NCj4gPj4gIkplZmZyZXkgKFpoYW9odWkpIFpo
YW5nIiA8enpoYW5nQGp1bmlwZXIubmV0PiB3cml0ZXM6DQo+ID4+DQo+ID4+ID4gTGFkaXNsYXYs
DQo+ID4+ID4NCj4gPj4gPiBEZWFuIGFuZCBJIGhhdmUgc29tZSBsYXRlIHF1ZXN0aW9ucyBhbmQg
Y29tbWVudHMuIFdlIGNhbWUgYWNyb3NzDQo+IHRoZXNlDQo+ID4+IHdoaWxlIHRyeWluZyB0byB3
b3JrIG9uIHRoZSBPU1BGIFlBTkcgbW9kZWwuDQo+ID4+ID4NCj4gPj4gPiAtLS0tLS0tLS0tLQ0K
PiA+PiA+DQo+ID4+ID4gVGhlIHNwZWMgbWVudGlvbnMgaW4gc2V2ZXJhbCBwbGFjZXMgc29tZXRo
aW5nIGxpa2UgdGhlIGZvbGxvd2luZzoNCj4gPj4gPg0KPiA+PiA+IMKgwqAgRWFjaCByb3V0aW5n
IHByb3RvY29sIGluc3RhbmNlIGlzIGNvbm5lY3RlZCB0byBleGFjdGx5IG9uZSBSSUINCj4gZm9y
DQo+ID4+ID4gwqDCoCBlYWNoIGFkZHJlc3MgZmFtaWx5IHRoYXQgdGhlIHJvdXRpbmcgcHJvdG9j
b2wgaW5zdGFuY2Ugc3VwcG9ydHMuDQo+ID4+ID4NCj4gPj4gPiBNeSB1bmRlcnN0YW5kaW5nIGlz
IHRoYXQgdGhlIGFkZHJlc3MgZmFtaWx5IG1lbnRpb25lZCBhYm92ZSBkb2VzDQo+IG5vdA0KPiA+
PiBpbmNsdWRlIFNBRkkuIEJlY2F1c2Ugb2YgdGhhdCwgYSByb3V0aW5nIHByb3RvY29sIGxpa2Ug
QkdQIG1heQ0KPiBjb25uZWN0DQo+ID4+IHRvIG11bHRpcGxlIFJJQnMgaW4gdGhlIHNhbWUgZmFt
aWx5IChSSUIgZm9yIHVuaWNhc3QgYW5kIFJJQiBmb3INCj4gPj4gbXVsdGljYXN0IFJQRiBwdXJw
b3NlIGluIGNhc2Ugb2YgaW5jb25ncnVlbnQgbXVsdGljYXN0IHRvcG9sb2d5KSBzbw0KPiB0aGUN
Cj4gPj4gYWJvdmUgc3RhdGVtZW50IGlzIG5vdCBjb3JyZWN0Lg0KPiA+Pg0KPiA+PiBUaGlzIGlz
IHF1aXRlIGZsZXhpYmxlIHNpbmNlIGFkZHJlc3MgZmFtaWx5IGlzIGRlZmluZWQgdmlhIGlkZW50
aXRpZXMuDQo+IEkNCj4gPj4gY2FuIGltYWdpbmUgb25lIGltcGxlbWVudGF0aW9uIHVzaW5nIG9u
bHkgImlwdjQiIGFuZCAiaXB2NiIgKGRlZmluZWQNCj4gaW4NCj4gPj4gaWV0Zi1yb3V0aW5nKSB3
aGlsc3Qgb3RoZXIgaW1wbGVtZW50YXRpb24gY291bGQgdXNlICJpcHZbNDZdLXVuaWNhc3QiDQo+
ID4+IChkZWZpbmVkIGluIGlldGYtaXB2WzQ2XS11bmljYXN0LXJvdXRpbmcpIGFuZCAiaXB2WzQ2
XS1tdWx0aWNhc3QiICh0bw0KPiBiZQ0KPiA+PiBkZWZpbmVkIGluIGEgbW9kdWxlIGZvciB1bmlj
YXN0IHJvdXRpbmcpLCB0aGF0IG1lYW5zIGluY2x1ZGluZyBTQUZJLg0KPiA+DQo+ID4gQWRkcmVz
cyBGYW1pbHkgaGFzIHZlcnkgc3BlY2lmaWMgbWVhbmluZ3MsIHR5cGljYWxseSBvbmx5IHJlZmVy
IHRvDQo+IElQdjQvSVB2NiB0byBteSB1bmRlcnN0YW5kaW5nLiBJZiB3ZSB3YW50IHRvIGV4dGVu
ZCB0aGF0IHRvIGluY2x1ZGUgU0FGSSwNCj4gdGhlbiB0aGUgc3BlYyBtdXN0IHBvaW50IGl0IG91
dC4gTW9yZSBiZWxvdyByZWxhdGVkIHRvIE1ULg0KPiANCj4gQm90aCBDaXNjbyBhbmQgSnVuaXBl
ciBkb2NzIHVzZSB0ZXJtcyBsaWtlICJJUHY2IG11bHRpY2FzdCBhZGRyZXNzDQo+IGZhbWlseSIg
b3IgIk1DQVNULVZQTiBhZGRyZXNzIGZhbWlseSIgdGhhdCBjbGVhcmx5IGluY2x1ZGUgU0FGSSBh
cyB3ZWxsLg0KPiANCj4gRm9yIGJldHRlciBvciB3b3JzZSwgaW4gdGhlIGlldGYtcm91dGluZyBZ
QU5HIG1vZHVsZSAiYWRkcmVzcy1mYW1pbHkiDQo+IGxlYWYgaXMgZGVmaW5lZCB3aXRoIHRoZSB0
eXBlDQo+IA0KPiAgICAgICAgICB0eXBlIGlkZW50aXR5cmVmIHsNCj4gICAgICAgICAgICBiYXNl
IGFkZHJlc3MtZmFtaWx5Ow0KPiAgICAgICAgICB9DQo+IA0KPiBzbyBpdHMgbWVhbmluZyBmb2xs
b3dzIGZyb20gdGhhdCwgaW5jbHVkaW5nIHRoZSBmYWN0IHRoYXQgdGhlIGlkZW50aXR5DQo+IGlz
IGV4dGVuc2libGUuIEluIG15IHZpZXcsIGl0IGlzIGEgZmVhdHVyZSwgbm90IGJ1Zy4NCj4gDQo+
ID4NCj4gPj4NCj4gPj4gPg0KPiA+PiA+IFRoaXMgaXMgYWxzbyBhIHByb2JsZW0gaW4gY2FzZSBv
ZiBNdWx0aS10b3BvbG9neS4gRWFjaCB0b3BvbG9neSBoYXMNCj4gPj4gaXRzIG93biBSSUIgYW5k
IGEgcHJvdG9jb2wgaW5zdGFuY2UgbGlrZSBPU1BGIGNhbiBjb25uZWN0IHRvIG11bHRpcGxlDQo+
IE1UDQo+ID4+IFJJQnMuDQo+ID4+DQo+ID4+IFR3byBwb3NzaWJsZSBzb2x1dGlvbnMgY29tZSB0
byBteSBtaW5kOg0KPiA+Pg0KPiA+PiAxLiBZb3UgY291bGQgZGVyaXZlIG5ldyBhZGRyZXNzIGZh
bWlseSBpZGVudGl0aWVzIGZyb20gImlwdjQtdW5pY2FzdCINCj4gPj4gZXRjLiBzbyB0aGF0IHlv
dSBjYW4gYXNzaWduIGEgdW5pcXVlIGFkZHJlc3MgZmFtaWx5IHRvIG11bHRpcGxlDQo+IHRhYmxl
cy4NCj4gPj4NCj4gPj4gMi4gWW91IGNvdWxkIGhhdmUgb25lIGNvbm5lY3RlZCBSSUIgZS5nLiBm
b3IgImlwdjQtdW5pY2FzdCIgYW5kDQo+IGRlZmluZQ0KPiA+PiB0d28gb3IgbW9yZSBSSUJzIGZv
ciBlYWNoIHRvcG9sb2d5IGFzIHJlY2lwaWVudHMgb2YgdGhlIGNvbm5lY3RlZCBSSUIuDQo+ID4+
IFNvLCBpbiBlZmZlY3QsIHRoZSAoc2luZ2xlKSBjb25uZWN0ZWQgUklCIGNvbnRhaW5zIHJvdXRl
cyBmb3IgYWxsDQo+ID4+IHRvcG9sb2dpZXMgYW5kIHRoZXNlIGFyZSB0aGVuIHNwbGl0IHZpYSBy
b3V0ZSBmaWx0ZXJzIHRvIHRoZSBwZXItDQo+ID4+IHRvcG9sb2d5IFJJQnMuDQo+ID4+DQo+ID4+
IERvZXMgaXQgbWFrZSBzZW5zZT8NCj4gPg0KPiA+IENvbXBhcmUgdGhlIHR3bywgSSBkb24ndCBs
aWtlICMyIGJlY2F1c2UgaXQgYWRkcyBhbiB1bm5lY2Vzc2FyeQ0KPiBpbmRpcmVjdGlvbi4gSSBk
b24ndCB0aGluayB3ZSB3YW50IHRvIG92ZXJsb2FkICJBZGRyZXNzIEZhbWlseSIgZnVydGhlcg0K
PiB0byBpbmNsdWRlIHRvcG9sb2d5IGVpdGhlci4gSW4gbWFueSBpbXBsZW1lbnRhdGlvbnMsIGFj
dHVhbCBSSUJzIGFyZSBwZXINCj4gKHJvdXRpbmctaW5zdGFuY2UsIEFGSSwgU0FGSSwgdG9wb2xv
Z3kpIGFuZCBpdCBtYXkgYmUgZXh0ZW5kZWQgZnVydGhlci4NCj4gVGhlcmVmb3JlLCB0aGUgYmVz
dCBvcHRpb24gaXMgdG8gc2ltcGx5IHJlbW92ZSB0aGUgcmVzdHJpY3Rpb24gdGhhdCBvbmUNCj4g
cHJvdG9jb2wgaW5zdGFuY2UgaXMgY29ubmVjdGVkIHRvIGV4YWN0bHkgb25lIFJJQiBwZXIgYWRk
cmVzcyBmYW1pbHkuDQo+IA0KPiBUaGlzIHJlc3RyaWN0aW9uIGlzIG9ubHkgcmVsZXZhbnQgZm9y
IHRoZSAiY29ubmVjdGVkLXJpYiIgbGlzdC4gSWYgeW91DQo+IHdhbnQsIHlvdSBjYW4gYWRkIGNv
bmZpZ3VyYXRpb24gcGFyYW1ldGVycyB0byBhc3NvY2lhdGUgb3RoZXIgUklCcw0KPiBkaXJlY3Rs
eSB3aXRoIGEgcm91dGluZyBwcm90b2NvbCBpbnN0YW5jZS4NCj4gDQo+IElNTywgdGhlIGNvbW1v
biB1c2UgY2FzZSBmb3IgTVQgYXJlIGluY29uZ3J1ZW50IElQdjQgYW5kIElQdjYgdG9wb2xvZ2ll
cywNCj4gYW5kIHRoZSBjb3JlIHJvdXRpbmcgZGF0YSBtb2RlbCBjYW4gaGFuZGxlIHRoaXMgZGly
ZWN0bHkgYW5kIGVhc2lseS4NCj4gDQo+IEFsc28gbm90ZSB0aGF0IHRoZSAicm91dGluZy1jZmci
IGRvY3VtZW50IGhhcyBhbHJlYWR5IGJlZW4gc3VibWl0dGVkIHRvDQo+IElFU0cgZm9yIHB1Ymxp
Y2F0aW9uLCBzbyB5b3VyIGNvbW1lbnRzIGNvbWUgcmVhbGx5IGxhdGUuDQo+IA0KPiA+DQo+ID4+
DQo+ID4+ID4NCj4gPj4gPiAtLS0tLS0NCj4gPj4gPg0KPiA+PiA+IDUuMS4gIFJvdXRpbmcgSW5z
dGFuY2UNCj4gPj4gPg0KPiA+PiA+ICAgIEVhY2ggcm91dGluZyBpbnN0YW5jZSBpbiB0aGUgY29y
ZSByb3V0aW5nIGRhdGEgbW9kZWwgcmVwcmVzZW50cw0KPiBhDQo+ID4+ID4gICAgbG9naWNhbCBy
b3V0ZXIuICBUaGUgZXhhY3Qgc2VtYW50aWNzIG9mIHRoaXMgdGVybSBhcmUgbGVmdCB0bw0KPiA+
PiA+ICAgIGltcGxlbWVudGF0aW9ucy4gIEZvciBleGFtcGxlLCByb3V0aW5nIGluc3RhbmNlcyBt
YXkgYmUNCj4gY29tcGxldGVseQ0KPiA+PiA+ICAgIGlzb2xhdGVkIHZpcnR1YWwgcm91dGVycyBv
ciwgYWx0ZXJuYXRpdmVseSwgdGhleSBtYXkgaW50ZXJuYWxseQ0KPiBzaGFyZQ0KPiA+PiA+ICAg
IGNlcnRhaW4gaW5mb3JtYXRpb24uDQo+ID4+ID4NCj4gPj4gPiAgICAuLi4NCj4gPj4gPg0KPiA+
PiA+ICAgIEFuIGltcGxlbWVudGF0aW9uIE1BWSBzdXBwb3J0IG11bHRpcGxlIHR5cGVzIG9mIGxv
Z2ljYWwgcm91dGVycw0KPiA+PiA+ICAgIHNpbXVsdGFuZW91c2x5LiAgSW5zdGFuY2VzIG9mIGFs
bCByb3V0aW5nIGluc3RhbmNlIHR5cGVzIGFyZQ0KPiA+PiA+ICAgIG9yZ2FuaXplZCBhcyBlbnRy
aWVzIG9mIHRoZSBzYW1lIGZsYXQgInJvdXRpbmctaW5zdGFuY2UiIGxpc3QuDQo+IEluDQo+ID4+
ID4gICAgb3JkZXIgdG8gZGlzY3JpbWluYXRlIHJvdXRpbmcgaW5zdGFuY2VzIGJlbG9uZ2luZyB0
byBkaWZmZXJlbnQNCj4gdHlwZXMsDQo+ID4+ID4gICAgdGhlICJ0eXBlIiBsZWFmIGlzIGRlZmlu
ZWQgYXMgYSBjaGlsZCBvZiB0aGUgInJvdXRpbmctaW5zdGFuY2UiDQo+IG5vZGUuDQo+ID4+ID4N
Cj4gPj4gPiBUaGUgc3BlYyBwdXJwb3NlbHkgbGVmdCBpdCBmdXp6eSBhcyB0byB3aGF0IGEgInJv
dXRpbmcgaW5zdGFuY2UiIGlzLg0KPiA+PiBIb3dldmVyIHdlIGRlZmluaXRlbHkgc2hvdWxkIGhh
dmUgY2xlYXIgZGVmaW5pdGlvbnMgZm9yIHRoZSB0aHJlZQ0KPiB0ZXJtcw0KPiA+PiBtZW50aW9u
ZWQ6IHJvdXRpbmctaW5zdGFuY2UsIGxvZ2ljYWwgcm91dGVyIGFuZCB2aXJ0dWFsIHJvdXRlci4N
Cj4gPj4NCj4gPj4gWWVzLCB0aGlzIGlzIGJ5IGRlc2lnbiBvcGVuLWVuZGVkIGJlY2F1c2Ugb3Ro
ZXJ3aXNlIHdlIHdvdWxkIHByb2JhYmx5DQo+ID4+IG5ldmVyIHJlYWNoIGNvbnNlbnN1cyBvbiB3
aGF0IHRoZXNlIHRlcm1zIGV4YWN0bHkgbWVhbi4NCj4gPg0KPiA+IFdoaWxlIHRoZSBkZXNpZ24g
bmVlZHMgdG8gYmUgb3Blbi1lbmRlZCBhIHN0YW5kYXJkIHNwZWNpZmljYXRpb24gbmVlZHMNCj4g
dG8gYmUgcHJlY2lzZSBhbmQgdW5hbWJpZ3VvdXMuIFRoZSBuYW1lcyBjYW4gYmUgZGlzY3Vzc2Vk
IGFuZA0KPiBjb21wcm9taXNlZCBidXQgdGhlIG1lYW5pbmcgbXVzdCBiZSBjbGVhci4gRm9yIGV4
YW1wbGUsIENpc2NvICJ2aXJ0dWFsDQo+IHJvdXRlciIgYW5kIEp1bmlwZXIgImxvZ2ljYWwgcm91
dGVyL3N5c3RlbSIgYXJlIHRoZSBzYW1lIGJ1dCBKdW5pcGVyDQo+ICJ2aXJ0dWFsIHJvdXRlciIg
YW5kIENpc2NvICJWUkYtbGl0ZSIgYXJlIHRoZSBzYW1lLiBXaGF0IGRvZXMgdGhlDQo+ICJsb2dp
Y2FsIHJvdXRlciIgaW4gdGhpcyBzcGVjIG1lYW4/IFdlIGNhbid0IGp1c3Qgc2F5IHRoYXQgIml0
IGNhbiBtZWFuDQo+IGFueSBvZiB0aG9zZSIuIEZvciBleGFtcGxlIGlmIGl0IG1lYW5zIENpc2Nv
J3MgInZpcnR1YWwgcm91dGVyIiBvcg0KPiBKdW5pcGVyJ3MgImxvZ2ljYWwgc3lzdGVtIiwgYSBm
dXJ0aGVyIGRpc2N1c3Npb24gbWF5IGJlIC0gc2hvdWxkIHRoaXMNCj4gbW9kdWxlIHJlYWxseSBj
b3ZlciB0aGF0Lg0KPiANCj4gVGhlIHRlcm0gImxvZ2ljYWwgcm91dGVyIiBpcyB1c2VkIGluIGEg
dmVyeSBnZW5lcmFsIHNlbnNlLCBhbmQgdGhlDQo+IGRvY3VtZW50IGNsZWFybHkgc2F5cyBzbyAo
Im5vIHNlbWFudGljcyIpLiBUaGUgb3RoZXIgdGVybXMgYXJlIHVzZWQgb25seQ0KPiBhcyBleGFt
cGxlcyB3aGF0IGl0IGNvdWxkIHBvc3NpYmx5IG1lYW4sIHRvIG1ha2UgdGhlIHNwZWMgbW9yZQ0K
PiBhY2Nlc3NpYmxlLg0KPiANCj4gPg0KPiA+Pg0KPiA+PiA+DQo+ID4+ID4gTG9naWNhbCByb3V0
ZXIgaXMgYSB2ZXJ5IG92ZXJsb2FkIHRlcm0uIFRvZGF5IHZlbmRvcnMgaGF2ZQ0KPiB2aXJ0dWFs
aXplZA0KPiA+PiB0aGVpciByb3V0aW5nIGNhcGFiaWxpdGllcyBpbiB0aGUgc3lzdGVtIGFuZCBw
cm92aWRlIDMgZGlmZmVyZW50DQo+IGxldmVscw0KPiA+PiBvZiByb3V0aW5nIHZpcnR1YWxpemF0
aW9uLiBMb2dpY2FsIHN5c3RlbXMsIGxvZ2ljYWwgcm91dGVycyBhcmUgc29tZQ0KPiBvZg0KPiA+
PiB0aGUgbmFtZXMgdXNlZCBieSB2ZW5kb3JzIGFuZCB0aG9zZSBvZmZlciByb3V0aW5nIGFuZCBt
YW5hZ2VtZW50DQo+ID4+IHNlcGFyYXRpb24uIEVhY2ggbG9naWNhbCBzeXN0ZW0gaGFzIGl0cyBv
d24gcm91dGluZyBpbnN0YW5jZXMgYW5kDQo+ID4+IHJvdXRpbmcgaW5zdGFuY2VzIGNhbiBoYXZl
IG11bHRpcGxlIHJvdXRpbmcgdGFibGVzLCBzbyBpdCBpcyB2ZXJ5DQo+ID4+IGltcG9ydGFudCB0
byBoYXZlIHZlcnkgcHJlY2lzZSBkZWZpbml0aW9uIG9mIHdoYXQgaXMgcm91dGluZyBpbnN0YW5j
ZQ0KPiA+PiAoYW5kIG5vdCBjb21wYXJlIGl0IHdpdGggbG9naWNhbCByb3V0ZXIpDQo+ID4+ID4N
Cj4gPj4gPiDCoMKgwqDCoCBpZGVudGl0eSBzdGFuZGFyZC1yb3V0aW5nLWluc3RhbmNlIHsNCj4g
Pj4gPiDCoMKgwqDCoMKgwqAgYmFzZSByb3V0aW5nLWluc3RhbmNlLXR5cGU7DQo+ID4+ID4gwqDC
oMKgwqDCoMKgIGRlc2NyaXB0aW9uDQo+ID4+ID4gwqDCoMKgwqDCoMKgwqDCoCAiVGhpcyBpZGVu
dGl0eSByZXByZXNlbnRzIGEgZGVmYXVsdCByb3V0aW5nIGluc3RhbmNlLiI7DQo+ID4+ID4gwqDC
oMKgwqAgfQ0KPiA+PiA+DQo+ID4+ID4gV2hhdCBpcyBhICJzdGFuZGFyZC1yb3V0aW5nLWluc3Rh
bmNlIj8gV291bGQgImRlZmF1bHQtcm91dGluZy0NCj4gPj4gaW5zdGFuY2UiIGJlIGJldHRlcj8g
InN0YW5kYXJkIiB3b3JkaW5nIGxlYWRzIHRvICJzdGFuZGFyZCB2cy4gbm9uLQ0KPiA+PiBzdGFu
ZGFyZCIgcXVlc3Rpb24gYW5kIGhpbnRzIG9uIHRoYXQgdGhlIHR3byBhcmUgZGlmZmVyZW50IHR5
cGVzLg0KPiA+PiAiZGVmYXVsdCIgdnMuICJub24tZGVmYXVsdCIgZG9lcyBub3QgaGF2ZSB0aGF0
IChhdCBsZWFzdCB0byBtZSkuDQo+ID4+DQo+ID4+IFdlbGwsICJkZWZhdWx0IiBpcyBvdmVybG9h
ZGVkLCB0b28sIGFuZCBhbHNvIGhhcyBhIHNwZWNpZmljIG1lYW5pbmcNCj4gaW4NCj4gPj4gWUFO
Ry4gU3RhbmRhcmQgaXMgc3VwcG9zZWQgdG8gbWVhbiBwbGFpbiB2YW5pbGxhIHJvdXRlci4gSXQg
aXMganVzdCBhDQo+ID4+IG5hbWUuDQo+ID4NCj4gPiBJIGRvbid0IGhhdmUgdG8gc3BsaXQgaGFp
ciBiZXR3ZWVuICJzdGFuZGFyZCIgYW5kICJkZWZhdWx0IiBidXQgdGhlDQo+IHNwZWMgbXVzdCBw
b2ludCBvdXQgd2hhdCBhICJzdGFuZGFyZC1yb3V0aW5nLWluc3RhbmNlIiBpcyAtIGlzIGl0IHRo
ZQ0KPiBkZWZhdWx0L2Jhc2UvbWFzdGVyIGxvZ2ljYWwtc3lzdGVtIChDaXNjbyB2aXJ0dWFsLXJv
dXRlcikgb3IgdGhlDQo+IGRlZmF1bHQvYmFzZS9tYXN0ZXIgInJvdXRpbmctaW5zdGFuY2UiIChh
ICJsb2dpY2FsLXN5c3RlbSIgd291bGQgaW5jbHVkZQ0KPiBtYW55ICJyb3V0aW5nLWluc3RhbmNl
cyIgbGlrZSBWUkZzKS4NCj4gPg0KPiANCj4gSSB0aGluayB0aGUgaWV0Zi1yb3V0aW5nIG1vZHVs
ZSBtYWtlcyBpdCBwcmV0dHkgY2xlYXI6DQo+IA0KPiAgICAgICAgICBsZWFmIHR5cGUgew0KPiAg
ICAgICAgICAgIHR5cGUgaWRlbnRpdHlyZWYgew0KPiAgICAgICAgICAgICAgYmFzZSByb3V0aW5n
LWluc3RhbmNlLXR5cGU7DQo+ICAgICAgICAgICAgfQ0KPiAgICAgICAgICAgIGRlZmF1bHQgInJ0
OnN0YW5kYXJkLXJvdXRpbmctaW5zdGFuY2UiOw0KPiAgICAgICAgICAgIGRlc2NyaXB0aW9uDQo+
ICAgICAgICAgICAgICAiVGhlIHR5cGUgb2YgdGhlIHJvdXRpbmcgaW5zdGFuY2UuIjsNCj4gICAg
ICAgICAgfQ0KPiANCj4gVGhlIHB1cnBvc2Ugb2YgdGhlICJ0eXBlIiBpcyB0byBhbGxvdyBmb3Ig
ZGVmaW5pbmcgYSBuZXcgcm91dGluZw0KPiBpbnN0YW5jZSB0eXBlIGFuZCBhdWdtZW50IGNvbmZp
Z3VyYXRpb24gb3Igc3RhdGUgZGF0YSBjb25kaXRpb25hbGx5IGZvcg0KPiB0aGF0IHR5cGUuIFRo
ZSAic3RhbmRhcmQtcm91dGluZy1pbnN0YW5jZSIgaXMganVzdCB0aGUgZGVmYXVsdCB2YWx1ZSB0
bw0KPiBzdGFydCBmcm9tLCBpdCBoYXMgbm8gb3RoZXIgbWVhbmluZy4NCj4gDQo+IA0KPiA+Pg0K
PiA+PiA+DQo+ID4+ID4gU2hvdWxkIHRoaXMgc3BlYyBkaXN0aW5ndWlzaCBWUkYvVlIvTFIgYW5k
IGhhdmUgY29ycmVzcG9uZGluZw0KPiA+PiBpZGVudGl0aWVzIGRlZmluZWQ/DQo+ID4+DQo+ID4+
IFRoZSBpZGVhIGlzIHRoaXMgd2lsbCBiZSBkb25lIGluIG90aGVyIG1vZHVsZXMgdGhhdCBkZWZp
bmUgZGF0YQ0KPiBtb2RlbHMNCj4gPj4gZm9yIHRoZXNlIHR5cGVzIG9mIHJvdXRpbmcgaW5zdGFu
Y2VzLiBUaGVuIHRoZSAicm91dGluZy1pbnN0YW5jZSINCj4gPj4gY29udGFpbmVyIGNhbiBiZSBh
dWdtZW50ZWQgd2l0aCBhcmJpdHJhcnkgZGF0YSwgYnV0IGNvbmRpdGlvbmFsbHkgZm9yDQo+ID4+
IHRoYXQgcm91dGluZyBpbnN0YW5jZSB0eXBlLg0KPiA+DQo+ID4gSSB0aGluayBpdCBpcyBpbXBv
cnRhbnQgdG8gZGVmaW5lIGEgZmV3IHdlbGwga25vd24gcm91dGluZyBpbnN0YW5jZQ0KPiB0eXBl
cyBpbiB0aGUgYmFzZSBzcGVjIGFzIGEgZ29vZCBmb3VuZGF0aW9uIGZvciBvdGhlciBtb2R1bGVz
Lg0KPiANCj4gVGhpcyBpcyBvdXRzaWRlIHRoZSBzY29wZSBvZiB0aGUgY29yZSByb3V0aW5nIGRh
dGEgbW9kZWwsIGFuZCBzaG91bGQgYmUNCj4gZG9uZSBieSByb3V0aW5nIGV4cGVydHMsIG5vdCBp
biB0aGUgTkVUTU9EIGdyb3VwLiBUaGVyZSBhcmUgb3RoZXINCj4gaW5kaXNwZW5zYWJsZSBlbGVt
ZW50cyB0aGF0IGhhdmUgdG8gYmUgd29ya2VkIG91dCBiZWZvcmUgdGhlIHJvdXRpbmcNCj4gZGF0
YSBtb2RlbCBjYW4gYmUgcmVhbGx5IHVzZWZ1bCwgZS5nLiByb3V0aW5nIHByb3RvY29scyBhbmQg
cm91dGUNCj4gZmlsdGVycy4NCj4gDQo+ID4NCj4gPj4NCj4gPj4gQW4gaW1wbGVtZW50YXRpb24g
bWF5IGFjdHVhbGx5IHVzZSBtdWx0aXBsZSByb3V0aW5nLWluc3RhbmNlIHR5cGVzIGF0DQo+ID4+
IHRoZSBzYW1lIHRpbWUuDQo+ID4NCj4gPiBUaGF0J3MgZm9yIHN1cmUgYW5kIG5vdCB3aGF0IEkn
bSBjb25jZXJuZWQgd2l0aC4NCj4gPg0KPiA+Pg0KPiA+PiA+DQo+ID4+ID4gwqDCoMKgwqDCoMKg
wqDCoCBsZWFmIHR5cGUgew0KPiA+PiA+IMKgwqDCoMKgwqDCoMKgwqDCoMKgIHR5cGUgaWRlbnRp
dHlyZWYgew0KPiA+PiA+IMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBiYXNlIHJvdXRpbmctaW5z
dGFuY2UtdHlwZTsNCj4gPj4gPiDCoMKgwqDCoMKgwqDCoMKgwqDCoCB9DQo+ID4+ID4gwqDCoMKg
wqDCoMKgwqDCoMKgwqAgZGVzY3JpcHRpb24NCj4gPj4gPiDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqAgIlRoZSByb3V0aW5nIGluc3RhbmNlIHR5cGUsIHByaW1hcmlseSBpbnRlbmRlZCBmb3INCj4g
Pj4gPiDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBkaXNjcmltaW5hdGluZyBhbW9uZyBkaWZm
ZXJlbnQgdHlwZXMgb2YgbG9naWNhbA0KPiByb3V0ZXJzLA0KPiA+PiA+IMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgIHJvdXRlIHZpcnR1YWxpemF0aW9uLCBtYXN0ZXItc2xhdmUgYXJyYW5nZW1l
bnRzIGV0Yy4sDQo+ID4+ID4gwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgd2hpbGUga2VlcGlu
ZyBhbGwgcm91dGluZyBpbnN0YW5jZXMgaW4gdGhlIHNhbWUgZmxhdA0KPiA+PiA+IMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgIGxpc3QuIjsNCj4gPj4gPiDCoMKgwqDCoMKgwqDCoMKgIH0NCj4g
Pj4gPg0KPiA+PiA+IFdoYXQgaXMgdGhlICJtYXN0ZXItc2xhdmUgYXJyYW5nZW1lbnRzIj8NCj4g
Pj4NCj4gPj4gVGhpcyBjYW1lIGZyb20gYW4gZWFybHkgcmV2aWV3IGJ5IFRob21hcyBNb3Jpbiwg
aXQgaGFzIHRvIGRvIHdpdGgNCj4gPj4gTVBMUy9CR1AgVlBOcyB3aGVyZSBhIG1hc3RlciByb3V0
aW5nLWluc3RhbmNlIGV4Y2hhbmdlcyBzZWxlY3RlZA0KPiByb3V0ZXMNCj4gPj4gd2l0aCBlYWNo
IFZQTi9WUkYuDQo+ID4NCj4gPiBFaXRoZXIgaXQgbmVlZHMgdG8gYmUgY2xhcmlmaWVkIGluIHRo
ZSBzcGVjLCBvciBpdCBjb3VsZCBzaW1wbHkgYmUNCj4gcmVtb3ZlZCB0byBhdm9pZCBjb25mdXNp
b24gc2luY2UgInJvdXRlIHZpcnR1YWxpemF0aW9uIiBjb3ZlcnMgdGhhdA0KPiBhbHJlYWR5Lg0K
PiANCj4gVGhpcyBpcyBhY3R1YWxseSBhIHR5cG8gLSBpdCBzaG91bGQgYmUgInJvdXRlciB2aXJ0
dWFsaXphdGlvbiIuIE15DQo+IHVuZGVyc3RhbmRpbmcgb2YgdGhpcyB0ZXJtIGlzIHRoYXQgYSB2
aXJ0dWFsIHJvdXRlciBpcyBpc29sYXRlZCBhbmQNCj4gZXhjaGFuZ2VzIHJvdXRpbmcgaW5mb3Jt
YXRpb24gd2l0aCBvdGhlciByb3V0ZXJzIG9ubHkgdGhyb3VnaCByb3V0aW5nDQo+IHByb3RvY29s
cy4NCj4gDQo+IEFueXdheSwgdGhlc2UgYXJlIHJlYWxseSBvbmx5IGV4YW1wbGVzIGFuZCBJIHRo
aW5rIGl0IGlzIHN1ZmZpY2llbnRseQ0KPiBjbGVhciB0aGF0IHRoZSBjb3JlIHJvdXRpbmcgZGF0
YSBtb2RlbCBkb2Vzbid0IHVzZSB0aGVzZSB0ZXJtcyBmb3INCj4gZGVmaW5pbmcgYW55IHNlbWFu
dGljcy4NCj4gDQo+IExhZGENCj4gDQo+ID4NCj4gPj4NCj4gPj4gPg0KPiA+PiA+IERlcGVuZGlu
ZyBvbiB0aGUgZGVmaW5pdGlvbiBvZiAibG9naWNhbCByb3V0ZXIiIGFuZCAicm91dGUNCj4gPj4g
dmlydHVhbGl6YXRpb24iLCB0aGVyZSBtYXkgYWxzbyBiZSBjb25jZXJucyB3aXRoIGtlZXBpbmcg
YWxsIHRob3NlDQo+IGtpbmRzDQo+ID4+IG9mIGluIHRoZSBzYW1lIGZsYXQgbGlzdC4NCj4gPj4N
Cj4gPj4gSXQgaXMgc2ltaWxhciB0byBpbnRlcmZhY2VzLCB3aGVyZSBwaHlzaWNhbCBhbmQgbG9n
aWNhbCBpbnRlcmZhY2VzIG9mDQo+ID4+IGFsbCBraW5kcyBsaXZlIGluIHRoZSBzYW1lIGZsYXQg
bGlzdCBhbmQgYXJlIGRpc3Rpbmd1aXNoZWQgYnkgdGhlDQo+IHR5cGUuDQo+ID4+IEkgdGhpbmsg
aXQgY291bGQgd29yaywgcmVsYXRpb25zaGlwcyBhbW9uZyB0aGUgaW5kaXZpZHVhbCByb3V0aW5n
DQo+ID4+IGluc3RhbmNlcyBjYW4gYmUgZXhwcmVzc2VkIGluIG90aGVyIGRhdGEuDQo+ID4NCj4g
PiBJIHdpbGwgZGVmZXIgdG8gb3RoZXJzIGFib3V0IHRoZSBtZXJpdHMgb2YgYSBmbGF0IGxpc3Qs
IGJ1dCBmb3IgYSBmbGF0DQo+IGxpc3QsIHRoZSBiYXNlIHNwZWMgbmVlZHMgdG8gcHJvdmlkZSBh
IHdheSB0byBleHByZXNzIHRoZSByZWxhdGlvbnNoaXAuDQo+ID4NCj4gPiBKZWZmcmV5DQo+ID4N
Cj4gPj4NCj4gPj4gSGF2aW5nIGEgc2luZ2xlIGZsYXQgbGlzdCBoYXMgaXRzIGFkdmFudGFnZXMs
IGZvciBleGFtcGxlIHlvdSBjYW4NCj4gdGhlbg0KPiA+PiBlYXNpbHkgcmVmZXIgdG8gcm91dGlu
ZyBpbnN0YW5jZXMgdmlhIGxlYWZyZWZzICh3aGljaCBhbGxvdyBvbmx5IG9uZQ0KPiA+PiBwYXRo
KS4NCj4gPj4NCj4gPj4gQ2hlZXJzLCBMYWRhDQo+ID4+DQo+ID4+ID4NCj4gPj4gPiBKZWZmcmV5
IFpoYW5nDQo+ID4+ID4gRGVhbiBCb2dkYW5vdmljDQo+ID4+DQo+ID4+IC0tDQo+ID4+IExhZGlz
bGF2IExob3RrYSwgQ1ouTklDIExhYnMNCj4gPj4gUEdQIEtleSBJRDogRTc0RThDMEMNCj4gDQo+
IC0tDQo+IExhZGlzbGF2IExob3RrYSwgQ1ouTklDIExhYnMNCj4gUEdQIEtleSBJRDogRTc0RThD
MEMNCg==


From nobody Mon Jun 23 07:39:02 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC49E1B296A for ; Mon, 23 Jun 2014 07:38:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lZo0Ri0uTDlX for ; Mon, 23 Jun 2014 07:38:56 -0700 (PDT)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 912ED1B2961 for ; Mon, 23 Jun 2014 07:38:55 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 9ACA65403C5; Mon, 23 Jun 2014 16:38:53 +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 waxDvZyH8PQ9; Mon, 23 Jun 2014 16:38:47 +0200 (CEST)
Received: from localhost (unknown [172.29.2.202]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 17E31540336; Mon, 23 Jun 2014 16:38:45 +0200 (CEST)
From: Ladislav Lhotka 
To: "Jeffrey \(Zhaohui\) Zhang" , Dean Bogdanovic , "netmod\@ietf.org" 
In-Reply-To: 
References:   <18cd777ffb9d4df6b0966dd1b3dd822b@BY2PR05MB079.namprd05.prod.outlook.com>  
User-Agent: Notmuch/0.18 (http://notmuchmail.org) Emacs/24.3.50.2 (x86_64-apple-darwin13.0.0)
Date: Mon, 23 Jun 2014 16:38:45 +0200
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/2Nt49xE6DK4xKYXdaBtt5T_Zs8k
Cc: Kiran Agrahara Sreenivasa 
Subject: Re: [netmod] Questions/comments on draft-ietf-netmod-routing-cfg
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 23 Jun 2014 14:39:00 -0000

"Jeffrey (Zhaohui) Zhang"  writes:

> Lada,
>
> The discussions basically boil down to two main points:
>
> - I believe the spec should have well defined semantics for some well-kno=
wn types of "routing-instances". Otherwise it is too loose to be the founda=
tion for future work (e.g. the on-going OSPF YANG model work). That does no=
t prevent the flexibility for future extensions.

The OSPF (and more recent ISIS) module can work just fine with "standard-ro=
uting-instance". On smaller router platforms (OpenWRT with Quagga or BIRD d=
aemons) this is all that's needed. I don't know why specific routing instan=
ce types couldn't be defined in separate modules.=20

>
> - I think the spec is too restrictive in saying "Each routing protocol in=
stance is connected to exactly one RIB for each address family that the rou=
ting protocol instance supports". We can mix AF and SAF together and simply=
 say Address Family (if we make it clear) but with the consideration of MT =
the statement is just not correct.

There are currently three possible solutions:

1. Subdivide each address family via identity derivation, e.g. with respect=
 to type of service.

2. Distribute routes from the connected RIB selectively to any number other=
 RIBs via "recipient-rib" mechanism.

3. Augment the "routing-protocol" subtrees with new parameters. For example=
, one could introduce protocol "sub-instances", one for each topology, and =
then different sub-instances could use the same address family (this is by =
the way another advantage of having a flat list of routing protocol instanc=
es).

In my view, this choice should be sufficient.


>
> I am more concerned with the first point.
>
> I don't think this is too late. There is still IETF last call and I am po=
sting my comments here. If there is enough consensus to my points, then nec=
essary changes need to happen. If not, I'll accept that.

The routing-cfg document is already long overdue. We've already had several=
 rounds of relatively significant redesigns based on reviewers' comments, a=
nd I think now it's time to deliver the result. The data model may not be p=
erfect and I am open to returning to it after we gain some experience, but =
IMO we first need to fill the gaps by developing modules for routing protoc=
ols, route filters and, of course, specific types of routing instances.

Lada

>
> Thanks.
> Jeffrey
>
>> -----Original Message-----
>> From: Ladislav Lhotka [mailto:lhotka@nic.cz]
>> Sent: Monday, June 23, 2014 4:26 AM
>> To: Jeffrey (Zhaohui) Zhang; Dean Bogdanovic; netmod@ietf.org
>> Cc: Derek Man-Kit Yeung (myeung); Kiran Agrahara Sreenivasa
>> Subject: RE: Questions/comments on draft-ietf-netmod-routing-cfg
>>=20
>> "Jeffrey (Zhaohui) Zhang"  writes:
>>=20
>> > Lada,
>> >
>> >> -----Original Message-----
>> >> From: Ladislav Lhotka [mailto:lhotka@nic.cz]
>> >> Sent: Friday, June 20, 2014 7:26 AM
>> >> To: Jeffrey (Zhaohui) Zhang; Dean Bogdanovic; netmod@ietf.org
>> >> Cc: Derek Man-Kit Yeung (myeung); Kiran Agrahara Sreenivasa
>> >> Subject: Re: Questions/comments on draft-ietf-netmod-routing-cfg
>> >>
>> >> "Jeffrey (Zhaohui) Zhang"  writes:
>> >>
>> >> > Ladislav,
>> >> >
>> >> > Dean and I have some late questions and comments. We came across
>> these
>> >> while trying to work on the OSPF YANG model.
>> >> >
>> >> > -----------
>> >> >
>> >> > The spec mentions in several places something like the following:
>> >> >
>> >> > =C2=A0=C2=A0 Each routing protocol instance is connected to exactly=
 one RIB
>> for
>> >> > =C2=A0=C2=A0 each address family that the routing protocol instance=
 supports.
>> >> >
>> >> > My understanding is that the address family mentioned above does
>> not
>> >> include SAFI. Because of that, a routing protocol like BGP may
>> connect
>> >> to multiple RIBs in the same family (RIB for unicast and RIB for
>> >> multicast RPF purpose in case of incongruent multicast topology) so
>> the
>> >> above statement is not correct.
>> >>
>> >> This is quite flexible since address family is defined via identities.
>> I
>> >> can imagine one implementation using only "ipv4" and "ipv6" (defined
>> in
>> >> ietf-routing) whilst other implementation could use "ipv[46]-unicast"
>> >> (defined in ietf-ipv[46]-unicast-routing) and "ipv[46]-multicast" (to
>> be
>> >> defined in a module for unicast routing), that means including SAFI.
>> >
>> > Address Family has very specific meanings, typically only refer to
>> IPv4/IPv6 to my understanding. If we want to extend that to include SAFI,
>> then the spec must point it out. More below related to MT.
>>=20
>> Both Cisco and Juniper docs use terms like "IPv6 multicast address
>> family" or "MCAST-VPN address family" that clearly include SAFI as well.
>>=20
>> For better or worse, in the ietf-routing YANG module "address-family"
>> leaf is defined with the type
>>=20
>>          type identityref {
>>            base address-family;
>>          }
>>=20
>> so its meaning follows from that, including the fact that the identity
>> is extensible. In my view, it is a feature, not bug.
>>=20
>> >
>> >>
>> >> >
>> >> > This is also a problem in case of Multi-topology. Each topology has
>> >> its own RIB and a protocol instance like OSPF can connect to multiple
>> MT
>> >> RIBs.
>> >>
>> >> Two possible solutions come to my mind:
>> >>
>> >> 1. You could derive new address family identities from "ipv4-unicast"
>> >> etc. so that you can assign a unique address family to multiple
>> tables.
>> >>
>> >> 2. You could have one connected RIB e.g. for "ipv4-unicast" and
>> define
>> >> two or more RIBs for each topology as recipients of the connected RIB.
>> >> So, in effect, the (single) connected RIB contains routes for all
>> >> topologies and these are then split via route filters to the per-
>> >> topology RIBs.
>> >>
>> >> Does it make sense?
>> >
>> > Compare the two, I don't like #2 because it adds an unnecessary
>> indirection. I don't think we want to overload "Address Family" further
>> to include topology either. In many implementations, actual RIBs are per
>> (routing-instance, AFI, SAFI, topology) and it may be extended further.
>> Therefore, the best option is to simply remove the restriction that one
>> protocol instance is connected to exactly one RIB per address family.
>>=20
>> This restriction is only relevant for the "connected-rib" list. If you
>> want, you can add configuration parameters to associate other RIBs
>> directly with a routing protocol instance.
>>=20
>> IMO, the common use case for MT are incongruent IPv4 and IPv6 topologies,
>> and the core routing data model can handle this directly and easily.
>>=20
>> Also note that the "routing-cfg" document has already been submitted to
>> IESG for publication, so your comments come really late.
>>=20
>> >
>> >>
>> >> >
>> >> > ------
>> >> >
>> >> > 5.1.  Routing Instance
>> >> >
>> >> >    Each routing instance in the core routing data model represents
>> a
>> >> >    logical router.  The exact semantics of this term are left to
>> >> >    implementations.  For example, routing instances may be
>> completely
>> >> >    isolated virtual routers or, alternatively, they may internally
>> share
>> >> >    certain information.
>> >> >
>> >> >    ...
>> >> >
>> >> >    An implementation MAY support multiple types of logical routers
>> >> >    simultaneously.  Instances of all routing instance types are
>> >> >    organized as entries of the same flat "routing-instance" list.
>> In
>> >> >    order to discriminate routing instances belonging to different
>> types,
>> >> >    the "type" leaf is defined as a child of the "routing-instance"
>> node.
>> >> >
>> >> > The spec purposely left it fuzzy as to what a "routing instance" is.
>> >> However we definitely should have clear definitions for the three
>> terms
>> >> mentioned: routing-instance, logical router and virtual router.
>> >>
>> >> Yes, this is by design open-ended because otherwise we would probably
>> >> never reach consensus on what these terms exactly mean.
>> >
>> > While the design needs to be open-ended a standard specification needs
>> to be precise and unambiguous. The names can be discussed and
>> compromised but the meaning must be clear. For example, Cisco "virtual
>> router" and Juniper "logical router/system" are the same but Juniper
>> "virtual router" and Cisco "VRF-lite" are the same. What does the
>> "logical router" in this spec mean? We can't just say that "it can mean
>> any of those". For example if it means Cisco's "virtual router" or
>> Juniper's "logical system", a further discussion may be - should this
>> module really cover that.
>>=20
>> The term "logical router" is used in a very general sense, and the
>> document clearly says so ("no semantics"). The other terms are used only
>> as examples what it could possibly mean, to make the spec more
>> accessible.
>>=20
>> >
>> >>
>> >> >
>> >> > Logical router is a very overload term. Today vendors have
>> virtualized
>> >> their routing capabilities in the system and provide 3 different
>> levels
>> >> of routing virtualization. Logical systems, logical routers are some
>> of
>> >> the names used by vendors and those offer routing and management
>> >> separation. Each logical system has its own routing instances and
>> >> routing instances can have multiple routing tables, so it is very
>> >> important to have very precise definition of what is routing instance
>> >> (and not compare it with logical router)
>> >> >
>> >> > =C2=A0=C2=A0=C2=A0=C2=A0 identity standard-routing-instance {
>> >> > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 base routing-instance-type;
>> >> > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 description
>> >> > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "This identity rep=
resents a default routing instance.";
>> >> > =C2=A0=C2=A0=C2=A0=C2=A0 }
>> >> >
>> >> > What is a "standard-routing-instance"? Would "default-routing-
>> >> instance" be better? "standard" wording leads to "standard vs. non-
>> >> standard" question and hints on that the two are different types.
>> >> "default" vs. "non-default" does not have that (at least to me).
>> >>
>> >> Well, "default" is overloaded, too, and also has a specific meaning
>> in
>> >> YANG. Standard is supposed to mean plain vanilla router. It is just a
>> >> name.
>> >
>> > I don't have to split hair between "standard" and "default" but the
>> spec must point out what a "standard-routing-instance" is - is it the
>> default/base/master logical-system (Cisco virtual-router) or the
>> default/base/master "routing-instance" (a "logical-system" would include
>> many "routing-instances" like VRFs).
>> >
>>=20
>> I think the ietf-routing module makes it pretty clear:
>>=20
>>          leaf type {
>>            type identityref {
>>              base routing-instance-type;
>>            }
>>            default "rt:standard-routing-instance";
>>            description
>>              "The type of the routing instance.";
>>          }
>>=20
>> The purpose of the "type" is to allow for defining a new routing
>> instance type and augment configuration or state data conditionally for
>> that type. The "standard-routing-instance" is just the default value to
>> start from, it has no other meaning.
>>=20
>>=20
>> >>
>> >> >
>> >> > Should this spec distinguish VRF/VR/LR and have corresponding
>> >> identities defined?
>> >>
>> >> The idea is this will be done in other modules that define data
>> models
>> >> for these types of routing instances. Then the "routing-instance"
>> >> container can be augmented with arbitrary data, but conditionally for
>> >> that routing instance type.
>> >
>> > I think it is important to define a few well known routing instance
>> types in the base spec as a good foundation for other modules.
>>=20
>> This is outside the scope of the core routing data model, and should be
>> done by routing experts, not in the NETMOD group. There are other
>> indispensable elements that have to be worked out before the routing
>> data model can be really useful, e.g. routing protocols and route
>> filters.
>>=20
>> >
>> >>
>> >> An implementation may actually use multiple routing-instance types at
>> >> the same time.
>> >
>> > That's for sure and not what I'm concerned with.
>> >
>> >>
>> >> >
>> >> > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 leaf type {
>> >> > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 type i=
dentityref {
>> >> > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 base routing-instance-type;
>> >> > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 }
>> >> > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 descri=
ption
>> >> > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 "The routing instance type, primarily intended for
>> >> > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 discriminating among different types of logical
>> routers,
>> >> > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 route virtualization, master-slave arrangements etc.,
>> >> > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 while keeping all routing instances in the same flat
>> >> > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 list.";
>> >> > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 }
>> >> >
>> >> > What is the "master-slave arrangements"?
>> >>
>> >> This came from an early review by Thomas Morin, it has to do with
>> >> MPLS/BGP VPNs where a master routing-instance exchanges selected
>> routes
>> >> with each VPN/VRF.
>> >
>> > Either it needs to be clarified in the spec, or it could simply be
>> removed to avoid confusion since "route virtualization" covers that
>> already.
>>=20
>> This is actually a typo - it should be "router virtualization". My
>> understanding of this term is that a virtual router is isolated and
>> exchanges routing information with other routers only through routing
>> protocols.
>>=20
>> Anyway, these are really only examples and I think it is sufficiently
>> clear that the core routing data model doesn't use these terms for
>> defining any semantics.
>>=20
>> Lada
>>=20
>> >
>> >>
>> >> >
>> >> > Depending on the definition of "logical router" and "route
>> >> virtualization", there may also be concerns with keeping all those
>> kinds
>> >> of in the same flat list.
>> >>
>> >> It is similar to interfaces, where physical and logical interfaces of
>> >> all kinds live in the same flat list and are distinguished by the
>> type.
>> >> I think it could work, relationships among the individual routing
>> >> instances can be expressed in other data.
>> >
>> > I will defer to others about the merits of a flat list, but for a flat
>> list, the base spec needs to provide a way to express the relationship.
>> >
>> > Jeffrey
>> >
>> >>
>> >> Having a single flat list has its advantages, for example you can
>> then
>> >> easily refer to routing instances via leafrefs (which allow only one
>> >> path).
>> >>
>> >> Cheers, Lada
>> >>
>> >> >
>> >> > Jeffrey Zhang
>> >> > Dean Bogdanovic
>> >>
>> >> --
>> >> Ladislav Lhotka, CZ.NIC Labs
>> >> PGP Key ID: E74E8C0C
>>=20
>> --
>> Ladislav Lhotka, CZ.NIC Labs
>> PGP Key ID: E74E8C0C

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


From nobody Mon Jun 23 07:42:28 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C2ED1A0653 for ; Mon, 23 Jun 2014 07:42:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CRdhRN9rAzer for ; Mon, 23 Jun 2014 07:42:17 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0141.outbound.protection.outlook.com [207.46.163.141]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1645D1B296B for ; Mon, 23 Jun 2014 07:42:17 -0700 (PDT)
Received: from BN1PR05MB424.namprd05.prod.outlook.com (10.141.58.148) by BN1PR05MB073.namprd05.prod.outlook.com (10.255.199.11) with Microsoft SMTP Server (TLS) id 15.0.954.9; Mon, 23 Jun 2014 14:42:15 +0000
Received: from BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.141]) by BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.155]) with mapi id 15.00.0954.000; Mon, 23 Jun 2014 14:42:15 +0000
From: Dean Bogdanovic 
To: "Jeffrey (Zhaohui) Zhang" , Ladislav Lhotka 
Thread-Topic: Questions/comments on draft-ietf-netmod-routing-cfg
Thread-Index: Ac+L5mG6QCip6E9wRnWAlQy1vx1YdgAlBfOAAACoQiAAj+tmAAAIpPrQAAR9eIA=
Date: Mon, 23 Jun 2014 14:42:15 +0000
Message-ID: 
References:   <18cd777ffb9d4df6b0966dd1b3dd822b@BY2PR05MB079.namprd05.prod.outlook.com>  
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-mailer: Apple Mail (2.1510)
x-originating-ip: [66.129.241.10]
x-microsoft-antispam: BL:0; ACTION:Default; RISK:Low; SCL:0; SPMLVL:NotSpam; PCL:0; RULEID:
x-forefront-prvs: 025100C802
x-forefront-antispam-report: SFV:NSPM; SFS:(428001)(24454002)(13464003)(199002)(189002)(377454003)(52314003)(87286001)(20776003)(87936001)(2656002)(79102001)(62966002)(77096002)(16236675004)(21056001)(80022001)(64706001)(50986999)(76176999)(81342001)(81542001)(74662001)(74502001)(31966008)(4396001)(89996001)(50226001)(93886003)(85852003)(83072002)(36756003)(92566001)(92726001)(15975445006)(93916002)(86362001)(575784001)(99396002)(99286002)(85306003)(83716003)(95666004)(15202345003)(105586002)(19580395003)(66066001)(101416001)(19580405001)(1941001)(83322001)(82746002)(104166001)(106356001)(77156001)(57306001)(46102001)(77982001)(33656002)(76482001)(104396001); DIR:OUT; SFP:; SCL:1; SRVR:BN1PR05MB073; H:BN1PR05MB424.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; 
received-spf: None (: juniper.net does not designate permitted sender hosts)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=deanb@juniper.net; 
Content-Type: multipart/alternative; boundary="_000_D8E0BD65D9F141009AA4A3B1A69F916Djunipernet_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/60q93MWT_U110KWIh8mANG7L3Ow
Cc: Kiran Agrahara Sreenivasa , "netmod@ietf.org" 
Subject: Re: [netmod] Questions/comments on draft-ietf-netmod-routing-cfg
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 23 Jun 2014 14:42:23 -0000

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

Lada,

Semantics has to be precise, otherwise it can be very differently reinterpr=
eted and then standards becomes not useful.

My take on this is we need a two abstractions
1. routing table - which is a container of routes
and
2. container of routing tables - this container has to have a precise name

If the 2. container name is not well specified and IMO, it is not in your d=
raft, it will be hard to use your draft as foundation. Right now your defin=
ition allows free definition of container of routing tables and container o=
f containers of routing tables. We don't need a definition of container of =
containers of routing tables. If we can come to agreement for the above two=
, that would be great.

The document is with IESG, but there is still possibility to bring DISCUSS =
and COMMENT items
http://tools.ietf.org/html/rfc4858#section-3.3


On Jun 23, 2014, at 8:59 AM, Jeffrey (Zhaohui) Zhang > wrote:

Lada,

The discussions basically boil down to two main points:

- I believe the spec should have well defined semantics for some well-known=
 types of "routing-instances". Otherwise it is too loose to be the foundati=
on for future work (e.g. the on-going OSPF YANG model work). That does not =
prevent the flexibility for future extensions.

I agree with this one very strongly.

- I think the spec is too restrictive in saying "Each routing protocol inst=
ance is connected to exactly one RIB for each address family that the routi=
ng protocol instance supports". We can mix AF and SAF together and simply s=
ay Address Family (if we make it clear) but with the consideration of MT th=
e statement is just not correct.

I am more concerned with the first point.

I don't think this is too late. There is still IETF last call and I am post=
ing my comments here. If there is enough consensus to my points, then neces=
sary changes need to happen. If not, I'll accept that.

Thanks.
Jeffrey

-----Original Message-----
From: Ladislav Lhotka [mailto:lhotka@nic.cz]
Sent: Monday, June 23, 2014 4:26 AM
To: Jeffrey (Zhaohui) Zhang; Dean Bogdanovic; netmod@ietf.org
Cc: Derek Man-Kit Yeung (myeung); Kiran Agrahara Sreenivasa
Subject: RE: Questions/comments on draft-ietf-netmod-routing-cfg

"Jeffrey (Zhaohui) Zhang" > w=
rites:

Lada,

-----Original Message-----
From: Ladislav Lhotka [mailto:lhotka@nic.cz]
Sent: Friday, June 20, 2014 7:26 AM
To: Jeffrey (Zhaohui) Zhang; Dean Bogdanovic; netmod@ietf.org
Cc: Derek Man-Kit Yeung (myeung); Kiran Agrahara Sreenivasa
Subject: Re: Questions/comments on draft-ietf-netmod-routing-cfg

"Jeffrey (Zhaohui) Zhang" > w=
rites:

Ladislav,

Dean and I have some late questions and comments. We came across
these
while trying to work on the OSPF YANG model.

-----------

The spec mentions in several places something like the following:

   Each routing protocol instance is connected to exactly one RIB
for
   each address family that the routing protocol instance supports.

My understanding is that the address family mentioned above does
not
include SAFI. Because of that, a routing protocol like BGP may
connect
to multiple RIBs in the same family (RIB for unicast and RIB for
multicast RPF purpose in case of incongruent multicast topology) so
the
above statement is not correct.

This is quite flexible since address family is defined via identities.
I
can imagine one implementation using only "ipv4" and "ipv6" (defined
in
ietf-routing) whilst other implementation could use "ipv[46]-unicast"
(defined in ietf-ipv[46]-unicast-routing) and "ipv[46]-multicast" (to
be
defined in a module for unicast routing), that means including SAFI.

Address Family has very specific meanings, typically only refer to
IPv4/IPv6 to my understanding. If we want to extend that to include SAFI,
then the spec must point it out. More below related to MT.

Both Cisco and Juniper docs use terms like "IPv6 multicast address
family" or "MCAST-VPN address family" that clearly include SAFI as well.

For better or worse, in the ietf-routing YANG module "address-family"
leaf is defined with the type

        type identityref {
          base address-family;
        }

so its meaning follows from that, including the fact that the identity
is extensible. In my view, it is a feature, not bug.




This is also a problem in case of Multi-topology. Each topology has
its own RIB and a protocol instance like OSPF can connect to multiple
MT
RIBs.

Two possible solutions come to my mind:

1. You could derive new address family identities from "ipv4-unicast"
etc. so that you can assign a unique address family to multiple
tables.

2. You could have one connected RIB e.g. for "ipv4-unicast" and
define
two or more RIBs for each topology as recipients of the connected RIB.
So, in effect, the (single) connected RIB contains routes for all
topologies and these are then split via route filters to the per-
topology RIBs.

Does it make sense?

Compare the two, I don't like #2 because it adds an unnecessary
indirection. I don't think we want to overload "Address Family" further
to include topology either. In many implementations, actual RIBs are per
(routing-instance, AFI, SAFI, topology) and it may be extended further.
Therefore, the best option is to simply remove the restriction that one
protocol instance is connected to exactly one RIB per address family.

This restriction is only relevant for the "connected-rib" list. If you
want, you can add configuration parameters to associate other RIBs
directly with a routing protocol instance.

IMO, the common use case for MT are incongruent IPv4 and IPv6 topologies,
and the core routing data model can handle this directly and easily.

Also note that the "routing-cfg" document has already been submitted to
IESG for publication, so your comments come really late.




------

5.1.  Routing Instance

  Each routing instance in the core routing data model represents
a
  logical router.  The exact semantics of this term are left to
  implementations.  For example, routing instances may be
completely
  isolated virtual routers or, alternatively, they may internally
share
  certain information.

  ...

  An implementation MAY support multiple types of logical routers
  simultaneously.  Instances of all routing instance types are
  organized as entries of the same flat "routing-instance" list.
In
  order to discriminate routing instances belonging to different
types,
  the "type" leaf is defined as a child of the "routing-instance"
node.

The spec purposely left it fuzzy as to what a "routing instance" is.
However we definitely should have clear definitions for the three
terms
mentioned: routing-instance, logical router and virtual router.

Yes, this is by design open-ended because otherwise we would probably
never reach consensus on what these terms exactly mean.

While the design needs to be open-ended a standard specification needs
to be precise and unambiguous. The names can be discussed and
compromised but the meaning must be clear. For example, Cisco "virtual
router" and Juniper "logical router/system" are the same but Juniper
"virtual router" and Cisco "VRF-lite" are the same. What does the
"logical router" in this spec mean? We can't just say that "it can mean
any of those". For example if it means Cisco's "virtual router" or
Juniper's "logical system", a further discussion may be - should this
module really cover that.

The term "logical router" is used in a very general sense, and the
document clearly says so ("no semantics"). The other terms are used only
as examples what it could possibly mean, to make the spec more
accessible.




Logical router is a very overload term. Today vendors have
virtualized
their routing capabilities in the system and provide 3 different
levels
of routing virtualization. Logical systems, logical routers are some
of
the names used by vendors and those offer routing and management
separation. Each logical system has its own routing instances and
routing instances can have multiple routing tables, so it is very
important to have very precise definition of what is routing instance
(and not compare it with logical router)

     identity standard-routing-instance {
       base routing-instance-type;
       description
         "This identity represents a default routing instance.";
     }

What is a "standard-routing-instance"? Would "default-routing-
instance" be better? "standard" wording leads to "standard vs. non-
standard" question and hints on that the two are different types.
"default" vs. "non-default" does not have that (at least to me).

Well, "default" is overloaded, too, and also has a specific meaning
in
YANG. Standard is supposed to mean plain vanilla router. It is just a
name.

I don't have to split hair between "standard" and "default" but the
spec must point out what a "standard-routing-instance" is - is it the
default/base/master logical-system (Cisco virtual-router) or the
default/base/master "routing-instance" (a "logical-system" would include
many "routing-instances" like VRFs).


I think the ietf-routing module makes it pretty clear:

        leaf type {
          type identityref {
            base routing-instance-type;
          }
          default "rt:standard-routing-instance";
          description
            "The type of the routing instance.";
        }

The purpose of the "type" is to allow for defining a new routing
instance type and augment configuration or state data conditionally for
that type. The "standard-routing-instance" is just the default value to
start from, it has no other meaning.




Should this spec distinguish VRF/VR/LR and have corresponding
identities defined?

The idea is this will be done in other modules that define data
models
for these types of routing instances. Then the "routing-instance"
container can be augmented with arbitrary data, but conditionally for
that routing instance type.

I think it is important to define a few well known routing instance
types in the base spec as a good foundation for other modules.

This is outside the scope of the core routing data model, and should be
done by routing experts, not in the NETMOD group. There are other
indispensable elements that have to be worked out before the routing
data model can be really useful, e.g. routing protocols and route
filters.



An implementation may actually use multiple routing-instance types at
the same time.

That's for sure and not what I'm concerned with.



         leaf type {
           type identityref {
             base routing-instance-type;
           }
           description
             "The routing instance type, primarily intended for
              discriminating among different types of logical
routers,
              route virtualization, master-slave arrangements etc.,
              while keeping all routing instances in the same flat
              list.";
         }

What is the "master-slave arrangements"?

This came from an early review by Thomas Morin, it has to do with
MPLS/BGP VPNs where a master routing-instance exchanges selected
routes
with each VPN/VRF.

Either it needs to be clarified in the spec, or it could simply be
removed to avoid confusion since "route virtualization" covers that
already.

This is actually a typo - it should be "router virtualization". My
understanding of this term is that a virtual router is isolated and
exchanges routing information with other routers only through routing
protocols.

Anyway, these are really only examples and I think it is sufficiently
clear that the core routing data model doesn't use these terms for
defining any semantics.

Lada




Depending on the definition of "logical router" and "route
virtualization", there may also be concerns with keeping all those
kinds
of in the same flat list.

It is similar to interfaces, where physical and logical interfaces of
all kinds live in the same flat list and are distinguished by the
type.
I think it could work, relationships among the individual routing
instances can be expressed in other data.

I will defer to others about the merits of a flat list, but for a flat
list, the base spec needs to provide a way to express the relationship.

Jeffrey


Having a single flat list has its advantages, for example you can
then
easily refer to routing instances via leafrefs (which allow only one
path).

Cheers, Lada


Jeffrey Zhang
Dean Bogdanovic

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

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


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






Lada,






Semantics has to be precise, otherwise it can be very differently rein=
terpreted and then standards becomes not useful.







My take on this is we need a two abstractions


1. routing table - which is a container of routes


and


2. container of routing tables - this container has to have a precise =
name







If the 2. container name is not well specified and IMO, it is not in y=
our draft, it will be hard to use your draft as foundation. Right now your =
definition allows free definition of container of routing tables and contai=
ner of containers of routing tables.
 We don't need a definition of container of containers of routing tables. I=
f we can come to agreement for the above two, that would be great. 






The document is with IESG, but there is still possibility to bring DIS=
CUSS and COMMENT items

















On Jun 23, 2014, at 8:59 AM, Jeffrey (Zhaohui) Zhang <zzhang@juniper.net> wrote:




Lada,



The discussions basically boil down to two main points:



- I believe the spec should have well defined semantics for some well-known=
 types of "routing-instances". Otherwise it is too loose to be th=
e foundation for future work (e.g. the on-going OSPF YANG model work). That=
 does not prevent the flexibility for future
 extensions.








I agree with this one very strongly. 




- I think the spec is too restrictive in saying "Each routing protocol=
 instance is connected to exactly one RIB for each address family that the =
routing protocol instance supports". We can mix AF and SAF together an=
d simply say Address Family (if we make it
 clear) but with the consideration of MT the statement is just not correct.=




I am more concerned with the first point.



I don't think this is too late. There is still IETF last call and I am post=
ing my comments here. If there is enough consensus to my points, then neces=
sary changes need to happen. If not, I'll accept that.



Thanks.

Jeffrey




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

From: Ladislav Lhotka [mailto:lhotka@nic.cz]

Sent: Monday, June 23, 2014 4:26 AM

To: Jeffrey (Zhaohui) Zhang; Dean Bogdanovic; netmod@ietf.org

Cc: Derek Man-Kit Yeung (myeung); Kiran Agrahara Sreenivasa

Subject: RE: Questions/comments on draft-ietf-netmod-routing-cfg



"Jeffrey (Zhaohui) Zhang" <zzhang@juniper.net> writes:




Lada,




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

From: Ladislav Lhotka [mailto:lhotka@nic.cz]

Sent: Friday, June 20, 2014 7:26 AM

To: Jeffrey (Zhaohui) Zhang; Dean Bogdanovic; netmod@ietf.org

Cc: Derek Man-Kit Yeung (myeung); Kiran Agrahara Sreenivasa

Subject: Re: Questions/comments on draft-ietf-netmod-routing-cfg



"Jeffrey (Zhaohui) Zhang" <zzhang@juniper.net> writes:




Ladislav,



Dean and I have some late questions and comments. We came across







these




while trying to work on the OSPF YANG model.




-----------



The spec mentions in several places something like the following:



   Each routing protocol instance is connected to exactly one RIB=








for






   each address family that the routing=
 protocol instance supports.



My understanding is that the address family mentioned above does







not




include SAFI. Because of that, a routing protocol=
 like BGP may





connect




to multiple RIBs in the same family (RIB for unic=
ast and RIB for

multicast RPF purpose in case of incongruent multicast topology) so





the




above statement is not correct.



This is quite flexible since address family is defined via identities.





I




can imagine one implementation using only "i=
pv4" and "ipv6" (defined





in




ietf-routing) whilst other implementation could u=
se "ipv[46]-unicast"

(defined in ietf-ipv[46]-unicast-routing) and "ipv[46]-multicast"=
 (to





be




defined in a module for unicast routing), that me=
ans including SAFI.





Address Family has very specific meanings, typically only refer to



IPv4/IPv6 to my understanding. If we want to extend that to include SAFI,
then the spec must point it out. More below related to MT.



Both Cisco and Juniper docs use terms like "IPv6 multicast address

family" or "MCAST-VPN address family" that clearly include S=
AFI as well.



For better or worse, in the ietf-routing YANG module "address-family&q=
uot;

leaf is defined with the type



        type identityref {

          base address-fa=
mily;

        }



so its meaning follows from that, including the fact that the identity

is extensible. In my view, it is a feature, not bug.












This is also a problem in case of Multi-topology. Each topology has



its own RIB and a protocol instance like OSPF can connect to multiple





MT




RIBs.



Two possible solutions come to my mind:



1. You could derive new address family identities from "ipv4-unicast&q=
uot;

etc. so that you can assign a unique address family to multiple





tables.






2. You could have one connected RIB e.g. for "ipv4-unicast" and




define




two or more RIBs for each topology as recipients =
of the connected RIB.

So, in effect, the (single) connected RIB contains routes for all

topologies and these are then split via route filters to the per-

topology RIBs.



Does it make sense?





Compare the two, I don't like #2 because it adds an unnecessary



indirection. I don't think we want to overload "Address Family" f=
urther

to include topology either. In many implementations, actual RIBs are per
(routing-instance, AFI, SAFI, topology) and it may be extended further.

Therefore, the best option is to simply remove the restriction that one

protocol instance is connected to exactly one RIB per address family.



This restriction is only relevant for the "connected-rib" list. I=
f you

want, you can add configuration parameters to associate other RIBs

directly with a routing protocol instance.



IMO, the common use case for MT are incongruent IPv4 and IPv6 topologies,
and the core routing data model can handle this directly and easily.



Also note that the "routing-cfg" document has already been submit=
ted to

IESG for publication, so your comments come really late.












------



5.1.  Routing Instance



  Each routing instance in the core routing data model represents=








a






  logical router.  The exact seman=
tics of this term are left to

  implementations.  For example, routing instances may be






completely






  isolated virtual routers or, alternat=
ively, they may internally







share






  certain information.



  ...



  An implementation MAY support multiple types of logical routers=


  simultaneously.  Instances of all routing instance types a=
re

  organized as entries of the same flat "routing-instance&qu=
ot; list.







In






  order to discriminate routing instanc=
es belonging to different







types,






  the "type" leaf is defined =
as a child of the "routing-instance"







node.








The spec purposely left it fuzzy as to what a "routing instance" =
is.



However we definitely should have clear definitions for the three





terms




mentioned: routing-instance, logical router and v=
irtual router.



Yes, this is by design open-ended because otherwise we would probably

never reach consensus on what these terms exactly mean.





While the design needs to be open-ended a standard specification needs



to be precise and unambiguous. The names can be discussed and

compromised but the meaning must be clear. For example, Cisco "virtual=


router" and Juniper "logical router/system" are the same but=
 Juniper

"virtual router" and Cisco "VRF-lite" are the same. Wha=
t does the

"logical router" in this spec mean? We can't just say that "=
it can mean

any of those". For example if it means Cisco's "virtual router&qu=
ot; or

Juniper's "logical system", a further discussion may be - should =
this

module really cover that.



The term "logical router" is used in a very general sense, and th=
e

document clearly says so ("no semantics"). The other terms are us=
ed only

as examples what it could possibly mean, to make the spec more

accessible.












Logical router is a very overload term. Today vendors have







virtualized




their routing capabilities in the system and prov=
ide 3 different





levels




of routing virtualization. Logical systems, logic=
al routers are some





of




the names used by vendors and those offer routing=
 and management

separation. Each logical system has its own routing instances and

routing instances can have multiple routing tables, so it is very

important to have very precise definition of what is routing instance

(and not compare it with logical router)




     identity standard-routing-instance {

       base routing-instance-type;

       description

         "This identity repres=
ents a default routing instance.";

     }



What is a "standard-routing-instance"? Would "default-routin=
g-



instance" be better? "standard" wording leads to "stand=
ard vs. non-

standard" question and hints on that the two are different types.

"default" vs. "non-default" does not have that (at leas=
t to me).



Well, "default" is overloaded, too, and also has a specific meani=
ng





in




YANG. Standard is supposed to mean plain vanilla =
router. It is just a

name.





I don't have to split hair between "standard" and "default&q=
uot; but the



spec must point out what a "standard-routing-instance" is - is it=
 the

default/base/master logical-system (Cisco virtual-router) or the

default/base/master "routing-instance" (a "logical-system&qu=
ot; would include

many "routing-instances" like VRFs).








I think the ietf-routing module makes it pretty clear:



        leaf type {

          type identityre=
f {

            bas=
e routing-instance-type;

          }

          default "r=
t:standard-routing-instance";

          description

            &qu=
ot;The type of the routing instance.";

        }



The purpose of the "type" is to allow for defining a new routing<=
br>
instance type and augment configuration or state data conditionally for

that type. The "standard-routing-instance" is just the default va=
lue to

start from, it has no other meaning.













Should this spec distinguish VRF/VR/LR and have corresponding



identities defined?



The idea is this will be done in other modules that define data





models




for these types of routing instances. Then the &q=
uot;routing-instance"

container can be augmented with arbitrary data, but conditionally for

that routing instance type.





I think it is important to define a few well known routing instance



types in the base spec as a good foundation for other modules.



This is outside the scope of the core routing data model, and should be

done by routing experts, not in the NETMOD group. There are other

indispensable elements that have to be worked out before the routing

data model can be really useful, e.g. routing protocols and route

filters.









An implementation may actually use multiple routing-instance types at

the same time.





That's for sure and not what I'm concerned with.









         leaf type {

           type identityr=
ef {

             ba=
se routing-instance-type;

           }

           description
             &q=
uot;The routing instance type, primarily intended for

            &nb=
sp; discriminating among different types of logical







routers,






        &=
nbsp;     route virtualization, master-slave arrangemen=
ts etc.,

            &nb=
sp; while keeping all routing instances in the same flat

            &nb=
sp; list.";

         }



What is the "master-slave arrangements"?





This came from an early review by Thomas Morin, it has to do with

MPLS/BGP VPNs where a master routing-instance exchanges selected





routes




with each VPN/VRF.





Either it needs to be clarified in the spec, or it could simply be



removed to avoid confusion since "route virtualization" covers th=
at

already.



This is actually a typo - it should be "router virtualization". M=
y

understanding of this term is that a virtual router is isolated and

exchanges routing information with other routers only through routing

protocols.



Anyway, these are really only examples and I think it is sufficiently

clear that the core routing data model doesn't use these terms for

defining any semantics.



Lada












Depending on the definition of "logical router" and "route


virtualization", there may also be concerns with keeping all those





kinds




of in the same flat list.



It is similar to interfaces, where physical and logical interfaces of

all kinds live in the same flat list and are distinguished by the





type.




I think it could work, relationships among the in=
dividual routing

instances can be expressed in other data.





I will defer to others about the merits of a flat list, but for a flat



list, the base spec needs to provide a way to express the relationship.




Jeffrey






Having a single flat list has its advantages, for example you can





then




easily refer to routing instances via leafrefs (w=
hich allow only one

path).



Cheers, Lada






Jeffrey Zhang

Dean Bogdanovic





--

Ladislav Lhotka, CZ.NIC Labs

PGP Key ID: E74E8C0C







--

Ladislav Lhotka, CZ.NIC Labs

PGP Key ID: E74E8C0C














--_000_D8E0BD65D9F141009AA4A3B1A69F916Djunipernet_--


From nobody Mon Jun 23 08:12:47 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2F071B297B for ; Mon, 23 Jun 2014 08:12:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.602
X-Spam-Level: 
X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s9F_1bozUPUc for ; Mon, 23 Jun 2014 08:12:39 -0700 (PDT)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0244.outbound.protection.outlook.com [207.46.163.244]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEE751B2AF3 for ; Mon, 23 Jun 2014 08:12:14 -0700 (PDT)
Received: from BY2PR05MB079.namprd05.prod.outlook.com (10.242.38.16) by BLUPR05MB420.namprd05.prod.outlook.com (10.141.27.26) with Microsoft SMTP Server (TLS) id 15.0.959.24; Mon, 23 Jun 2014 15:12:10 +0000
Received: from BY2PR05MB079.namprd05.prod.outlook.com ([169.254.8.228]) by BY2PR05MB079.namprd05.prod.outlook.com ([169.254.8.228]) with mapi id 15.00.0969.007; Mon, 23 Jun 2014 15:12:09 +0000
From: "Jeffrey (Zhaohui) Zhang" 
To: Ladislav Lhotka , Dean Bogdanovic , "netmod@ietf.org" 
Thread-Topic: [netmod] Questions/comments on draft-ietf-netmod-routing-cfg
Thread-Index: Ac+L5mG6QCip6E9wRnWAlQy1vx1YdgAlBfOAAACoQiAAj+tmAAAIpPrQAAReeoAAASpEcA==
Date: Mon, 23 Jun 2014 15:12:08 +0000
Message-ID: 
References:   <18cd777ffb9d4df6b0966dd1b3dd822b@BY2PR05MB079.namprd05.prod.outlook.com>   
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [66.129.241.13]
x-microsoft-antispam: BCL:0;PCL:0;RULEID:
x-forefront-prvs: 025100C802
x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(428001)(13464003)(377454003)(199002)(189002)(52314003)(52034003)(76176999)(54356999)(77096002)(1941001)(99396002)(76576001)(50986999)(33646001)(2656002)(31966008)(74662001)(74502001)(74316001)(21056001)(4396001)(83322001)(87936001)(19580395003)(19580405001)(46102001)(92566001)(86362001)(575784001)(85852003)(83072002)(77982001)(93886003)(76482001)(81542001)(101416001)(106356001)(95666004)(81342001)(64706001)(105586002)(80022001)(79102001)(85306003)(66066001)(99286002)(20776003)(24736002)(106276001); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR05MB420; H:BY2PR05MB079.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:3; LANG:en; 
received-spf: None (: juniper.net does not designate permitted sender hosts)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=zzhang@juniper.net; 
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/m0mkMYVDyYT2NB_id7dPNfA7lxY
Cc: Kiran Agrahara Sreenivasa 
Subject: Re: [netmod] Questions/comments on draft-ietf-netmod-routing-cfg
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 23 Jun 2014 15:12:45 -0000

TGFkYSwNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBMYWRpc2xhdiBM
aG90a2EgW21haWx0bzpsaG90a2FAbmljLmN6XQ0KPiBTZW50OiBNb25kYXksIEp1bmUgMjMsIDIw
MTQgMTA6MzkgQU0NCj4gVG86IEplZmZyZXkgKFpoYW9odWkpIFpoYW5nOyBEZWFuIEJvZ2Rhbm92
aWM7IG5ldG1vZEBpZXRmLm9yZw0KPiBDYzogS2lyYW4gQWdyYWhhcmEgU3JlZW5pdmFzYQ0KPiBT
dWJqZWN0OiBSZTogW25ldG1vZF0gUXVlc3Rpb25zL2NvbW1lbnRzIG9uIGRyYWZ0LWlldGYtbmV0
bW9kLXJvdXRpbmctDQo+IGNmZw0KPiANCj4gIkplZmZyZXkgKFpoYW9odWkpIFpoYW5nIiA8enpo
YW5nQGp1bmlwZXIubmV0PiB3cml0ZXM6DQo+IA0KPiA+IExhZGEsDQo+ID4NCj4gPiBUaGUgZGlz
Y3Vzc2lvbnMgYmFzaWNhbGx5IGJvaWwgZG93biB0byB0d28gbWFpbiBwb2ludHM6DQo+ID4NCj4g
PiAtIEkgYmVsaWV2ZSB0aGUgc3BlYyBzaG91bGQgaGF2ZSB3ZWxsIGRlZmluZWQgc2VtYW50aWNz
IGZvciBzb21lIHdlbGwtDQo+IGtub3duIHR5cGVzIG9mICJyb3V0aW5nLWluc3RhbmNlcyIuIE90
aGVyd2lzZSBpdCBpcyB0b28gbG9vc2UgdG8gYmUgdGhlDQo+IGZvdW5kYXRpb24gZm9yIGZ1dHVy
ZSB3b3JrIChlLmcuIHRoZSBvbi1nb2luZyBPU1BGIFlBTkcgbW9kZWwgd29yaykuDQo+IFRoYXQg
ZG9lcyBub3QgcHJldmVudCB0aGUgZmxleGliaWxpdHkgZm9yIGZ1dHVyZSBleHRlbnNpb25zLg0K
PiANCj4gVGhlIE9TUEYgKGFuZCBtb3JlIHJlY2VudCBJU0lTKSBtb2R1bGUgY2FuIHdvcmsganVz
dCBmaW5lIHdpdGgNCj4gInN0YW5kYXJkLXJvdXRpbmctaW5zdGFuY2UiLiBPbiBzbWFsbGVyIHJv
dXRlciBwbGF0Zm9ybXMgKE9wZW5XUlQgd2l0aA0KPiBRdWFnZ2Egb3IgQklSRCBkYWVtb25zKSB0
aGlzIGlzIGFsbCB0aGF0J3MgbmVlZGVkLiBJIGRvbid0IGtub3cgd2h5DQo+IHNwZWNpZmljIHJv
dXRpbmcgaW5zdGFuY2UgdHlwZXMgY291bGRuJ3QgYmUgZGVmaW5lZCBpbiBzZXBhcmF0ZSBtb2R1
bGVzLg0KPiANCj4gPg0KPiA+IC0gSSB0aGluayB0aGUgc3BlYyBpcyB0b28gcmVzdHJpY3RpdmUg
aW4gc2F5aW5nICJFYWNoIHJvdXRpbmcgcHJvdG9jb2wNCj4gaW5zdGFuY2UgaXMgY29ubmVjdGVk
IHRvIGV4YWN0bHkgb25lIFJJQiBmb3IgZWFjaCBhZGRyZXNzIGZhbWlseSB0aGF0DQo+IHRoZSBy
b3V0aW5nIHByb3RvY29sIGluc3RhbmNlIHN1cHBvcnRzIi4gV2UgY2FuIG1peCBBRiBhbmQgU0FG
IHRvZ2V0aGVyDQo+IGFuZCBzaW1wbHkgc2F5IEFkZHJlc3MgRmFtaWx5IChpZiB3ZSBtYWtlIGl0
IGNsZWFyKSBidXQgd2l0aCB0aGUNCj4gY29uc2lkZXJhdGlvbiBvZiBNVCB0aGUgc3RhdGVtZW50
IGlzIGp1c3Qgbm90IGNvcnJlY3QuDQo+IA0KPiBUaGVyZSBhcmUgY3VycmVudGx5IHRocmVlIHBv
c3NpYmxlIHNvbHV0aW9uczoNCj4gDQo+IDEuIFN1YmRpdmlkZSBlYWNoIGFkZHJlc3MgZmFtaWx5
IHZpYSBpZGVudGl0eSBkZXJpdmF0aW9uLCBlLmcuIHdpdGgNCj4gcmVzcGVjdCB0byB0eXBlIG9m
IHNlcnZpY2UuDQo+IA0KPiAyLiBEaXN0cmlidXRlIHJvdXRlcyBmcm9tIHRoZSBjb25uZWN0ZWQg
UklCIHNlbGVjdGl2ZWx5IHRvIGFueSBudW1iZXINCj4gb3RoZXIgUklCcyB2aWEgInJlY2lwaWVu
dC1yaWIiIG1lY2hhbmlzbS4NCj4gDQo+IDMuIEF1Z21lbnQgdGhlICJyb3V0aW5nLXByb3RvY29s
IiBzdWJ0cmVlcyB3aXRoIG5ldyBwYXJhbWV0ZXJzLiBGb3INCj4gZXhhbXBsZSwgb25lIGNvdWxk
IGludHJvZHVjZSBwcm90b2NvbCAic3ViLWluc3RhbmNlcyIsIG9uZSBmb3IgZWFjaA0KPiB0b3Bv
bG9neSwgYW5kIHRoZW4gZGlmZmVyZW50IHN1Yi1pbnN0YW5jZXMgY291bGQgdXNlIHRoZSBzYW1l
IGFkZHJlc3MNCj4gZmFtaWx5ICh0aGlzIGlzIGJ5IHRoZSB3YXkgYW5vdGhlciBhZHZhbnRhZ2Ug
b2YgaGF2aW5nIGEgZmxhdCBsaXN0IG9mDQo+IHJvdXRpbmcgcHJvdG9jb2wgaW5zdGFuY2VzKS4N
Cj4gDQo+IEluIG15IHZpZXcsIHRoaXMgY2hvaWNlIHNob3VsZCBiZSBzdWZmaWNpZW50Lg0KDQpI
b3cgYWJvdXQgc2ltcGx5IHJlbW92ZSB0aGF0IHJlc3RyaWN0aW9uIHRoYXQgb25lIHByb3RvY29s
IGluc3RhbmNlIGNvbm5lY3RzIHRvIG9ubHkgb25lIFJJQiBwZXIgYWRkcmVzcyBmYW1pbHk/DQoN
Cj4gDQo+IA0KPiA+DQo+ID4gSSBhbSBtb3JlIGNvbmNlcm5lZCB3aXRoIHRoZSBmaXJzdCBwb2lu
dC4NCj4gPg0KPiA+IEkgZG9uJ3QgdGhpbmsgdGhpcyBpcyB0b28gbGF0ZS4gVGhlcmUgaXMgc3Rp
bGwgSUVURiBsYXN0IGNhbGwgYW5kIEkgYW0NCj4gcG9zdGluZyBteSBjb21tZW50cyBoZXJlLiBJ
ZiB0aGVyZSBpcyBlbm91Z2ggY29uc2Vuc3VzIHRvIG15IHBvaW50cywNCj4gdGhlbiBuZWNlc3Nh
cnkgY2hhbmdlcyBuZWVkIHRvIGhhcHBlbi4gSWYgbm90LCBJJ2xsIGFjY2VwdCB0aGF0Lg0KPiAN
Cj4gVGhlIHJvdXRpbmctY2ZnIGRvY3VtZW50IGlzIGFscmVhZHkgbG9uZyBvdmVyZHVlLiBXZSd2
ZSBhbHJlYWR5IGhhZA0KPiBzZXZlcmFsIHJvdW5kcyBvZiByZWxhdGl2ZWx5IHNpZ25pZmljYW50
IHJlZGVzaWducyBiYXNlZCBvbiByZXZpZXdlcnMnDQo+IGNvbW1lbnRzLCBhbmQgSSB0aGluayBu
b3cgaXQncyB0aW1lIHRvIGRlbGl2ZXIgdGhlIHJlc3VsdC4gVGhlIGRhdGENCj4gbW9kZWwgbWF5
IG5vdCBiZSBwZXJmZWN0IGFuZCBJIGFtIG9wZW4gdG8gcmV0dXJuaW5nIHRvIGl0IGFmdGVyIHdl
IGdhaW4NCj4gc29tZSBleHBlcmllbmNlLCBidXQgSU1PIHdlIGZpcnN0IG5lZWQgdG8gZmlsbCB0
aGUgZ2FwcyBieSBkZXZlbG9waW5nDQo+IG1vZHVsZXMgZm9yIHJvdXRpbmcgcHJvdG9jb2xzLCBy
b3V0ZSBmaWx0ZXJzIGFuZCwgb2YgY291cnNlLCBzcGVjaWZpYw0KPiB0eXBlcyBvZiByb3V0aW5n
IGluc3RhbmNlcy4NCg0KV2UncmUgZGV2ZWxvcGluZyBwcm90b2NvbCBtb2R1bGVzLCBhbmQgaXQg
aXMgZHVyaW5nIHRoYXQgcHJvY2VzcyAoZm9yIE9TUEYgWUFORyBtb2R1bGUpIHRoYXQgdGhlIGlz
c3VlIHdpdGggInJvdXRpbmctaW5zdGFuY2UiIGNhbWUgdXAuIEl0J3MgYmV0dGVyIHRvIGFkZHJl
c3MgdGhhdCBpbiB0aGUgbmV0bW9kLXJvdXRpbmctY2ZnIHNwZWMgbm93IHRoYW4gbGF0ZXIvc2Vw
YXJhdGVseS4NCg0KSmVmZnJleQ0KDQo+IA0KPiBMYWRhDQo+IA0KPiA+DQo+ID4gVGhhbmtzLg0K
PiA+IEplZmZyZXkNCj4gPg0KPiA+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+PiBG
cm9tOiBMYWRpc2xhdiBMaG90a2EgW21haWx0bzpsaG90a2FAbmljLmN6XQ0KPiA+PiBTZW50OiBN
b25kYXksIEp1bmUgMjMsIDIwMTQgNDoyNiBBTQ0KPiA+PiBUbzogSmVmZnJleSAoWmhhb2h1aSkg
Wmhhbmc7IERlYW4gQm9nZGFub3ZpYzsgbmV0bW9kQGlldGYub3JnDQo+ID4+IENjOiBEZXJlayBN
YW4tS2l0IFlldW5nIChteWV1bmcpOyBLaXJhbiBBZ3JhaGFyYSBTcmVlbml2YXNhDQo+ID4+IFN1
YmplY3Q6IFJFOiBRdWVzdGlvbnMvY29tbWVudHMgb24gZHJhZnQtaWV0Zi1uZXRtb2Qtcm91dGlu
Zy1jZmcNCj4gPj4NCj4gPj4gIkplZmZyZXkgKFpoYW9odWkpIFpoYW5nIiA8enpoYW5nQGp1bmlw
ZXIubmV0PiB3cml0ZXM6DQo+ID4+DQo+ID4+ID4gTGFkYSwNCj4gPj4gPg0KPiA+PiA+PiAtLS0t
LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+PiA+PiBGcm9tOiBMYWRpc2xhdiBMaG90a2EgW21h
aWx0bzpsaG90a2FAbmljLmN6XQ0KPiA+PiA+PiBTZW50OiBGcmlkYXksIEp1bmUgMjAsIDIwMTQg
NzoyNiBBTQ0KPiA+PiA+PiBUbzogSmVmZnJleSAoWmhhb2h1aSkgWmhhbmc7IERlYW4gQm9nZGFu
b3ZpYzsgbmV0bW9kQGlldGYub3JnDQo+ID4+ID4+IENjOiBEZXJlayBNYW4tS2l0IFlldW5nICht
eWV1bmcpOyBLaXJhbiBBZ3JhaGFyYSBTcmVlbml2YXNhDQo+ID4+ID4+IFN1YmplY3Q6IFJlOiBR
dWVzdGlvbnMvY29tbWVudHMgb24gZHJhZnQtaWV0Zi1uZXRtb2Qtcm91dGluZy1jZmcNCj4gPj4g
Pj4NCj4gPj4gPj4gIkplZmZyZXkgKFpoYW9odWkpIFpoYW5nIiA8enpoYW5nQGp1bmlwZXIubmV0
PiB3cml0ZXM6DQo+ID4+ID4+DQo+ID4+ID4+ID4gTGFkaXNsYXYsDQo+ID4+ID4+ID4NCj4gPj4g
Pj4gPiBEZWFuIGFuZCBJIGhhdmUgc29tZSBsYXRlIHF1ZXN0aW9ucyBhbmQgY29tbWVudHMuIFdl
IGNhbWUgYWNyb3NzDQo+ID4+IHRoZXNlDQo+ID4+ID4+IHdoaWxlIHRyeWluZyB0byB3b3JrIG9u
IHRoZSBPU1BGIFlBTkcgbW9kZWwuDQo+ID4+ID4+ID4NCj4gPj4gPj4gPiAtLS0tLS0tLS0tLQ0K
PiA+PiA+PiA+DQo+ID4+ID4+ID4gVGhlIHNwZWMgbWVudGlvbnMgaW4gc2V2ZXJhbCBwbGFjZXMg
c29tZXRoaW5nIGxpa2UgdGhlIGZvbGxvd2luZzoNCj4gPj4gPj4gPg0KPiA+PiA+PiA+IMKgwqAg
RWFjaCByb3V0aW5nIHByb3RvY29sIGluc3RhbmNlIGlzIGNvbm5lY3RlZCB0byBleGFjdGx5IG9u
ZQ0KPiBSSUINCj4gPj4gZm9yDQo+ID4+ID4+ID4gwqDCoCBlYWNoIGFkZHJlc3MgZmFtaWx5IHRo
YXQgdGhlIHJvdXRpbmcgcHJvdG9jb2wgaW5zdGFuY2UNCj4gc3VwcG9ydHMuDQo+ID4+ID4+ID4N
Cj4gPj4gPj4gPiBNeSB1bmRlcnN0YW5kaW5nIGlzIHRoYXQgdGhlIGFkZHJlc3MgZmFtaWx5IG1l
bnRpb25lZCBhYm92ZSBkb2VzDQo+ID4+IG5vdA0KPiA+PiA+PiBpbmNsdWRlIFNBRkkuIEJlY2F1
c2Ugb2YgdGhhdCwgYSByb3V0aW5nIHByb3RvY29sIGxpa2UgQkdQIG1heQ0KPiA+PiBjb25uZWN0
DQo+ID4+ID4+IHRvIG11bHRpcGxlIFJJQnMgaW4gdGhlIHNhbWUgZmFtaWx5IChSSUIgZm9yIHVu
aWNhc3QgYW5kIFJJQiBmb3INCj4gPj4gPj4gbXVsdGljYXN0IFJQRiBwdXJwb3NlIGluIGNhc2Ug
b2YgaW5jb25ncnVlbnQgbXVsdGljYXN0IHRvcG9sb2d5KQ0KPiBzbw0KPiA+PiB0aGUNCj4gPj4g
Pj4gYWJvdmUgc3RhdGVtZW50IGlzIG5vdCBjb3JyZWN0Lg0KPiA+PiA+Pg0KPiA+PiA+PiBUaGlz
IGlzIHF1aXRlIGZsZXhpYmxlIHNpbmNlIGFkZHJlc3MgZmFtaWx5IGlzIGRlZmluZWQgdmlhDQo+
IGlkZW50aXRpZXMuDQo+ID4+IEkNCj4gPj4gPj4gY2FuIGltYWdpbmUgb25lIGltcGxlbWVudGF0
aW9uIHVzaW5nIG9ubHkgImlwdjQiIGFuZCAiaXB2NiINCj4gKGRlZmluZWQNCj4gPj4gaW4NCj4g
Pj4gPj4gaWV0Zi1yb3V0aW5nKSB3aGlsc3Qgb3RoZXIgaW1wbGVtZW50YXRpb24gY291bGQgdXNl
ICJpcHZbNDZdLQ0KPiB1bmljYXN0Ig0KPiA+PiA+PiAoZGVmaW5lZCBpbiBpZXRmLWlwdls0Nl0t
dW5pY2FzdC1yb3V0aW5nKSBhbmQgImlwdls0Nl0tbXVsdGljYXN0Ig0KPiAodG8NCj4gPj4gYmUN
Cj4gPj4gPj4gZGVmaW5lZCBpbiBhIG1vZHVsZSBmb3IgdW5pY2FzdCByb3V0aW5nKSwgdGhhdCBt
ZWFucyBpbmNsdWRpbmcNCj4gU0FGSS4NCj4gPj4gPg0KPiA+PiA+IEFkZHJlc3MgRmFtaWx5IGhh
cyB2ZXJ5IHNwZWNpZmljIG1lYW5pbmdzLCB0eXBpY2FsbHkgb25seSByZWZlciB0bw0KPiA+PiBJ
UHY0L0lQdjYgdG8gbXkgdW5kZXJzdGFuZGluZy4gSWYgd2Ugd2FudCB0byBleHRlbmQgdGhhdCB0
byBpbmNsdWRlDQo+IFNBRkksDQo+ID4+IHRoZW4gdGhlIHNwZWMgbXVzdCBwb2ludCBpdCBvdXQu
IE1vcmUgYmVsb3cgcmVsYXRlZCB0byBNVC4NCj4gPj4NCj4gPj4gQm90aCBDaXNjbyBhbmQgSnVu
aXBlciBkb2NzIHVzZSB0ZXJtcyBsaWtlICJJUHY2IG11bHRpY2FzdCBhZGRyZXNzDQo+ID4+IGZh
bWlseSIgb3IgIk1DQVNULVZQTiBhZGRyZXNzIGZhbWlseSIgdGhhdCBjbGVhcmx5IGluY2x1ZGUg
U0FGSSBhcw0KPiB3ZWxsLg0KPiA+Pg0KPiA+PiBGb3IgYmV0dGVyIG9yIHdvcnNlLCBpbiB0aGUg
aWV0Zi1yb3V0aW5nIFlBTkcgbW9kdWxlICJhZGRyZXNzLWZhbWlseSINCj4gPj4gbGVhZiBpcyBk
ZWZpbmVkIHdpdGggdGhlIHR5cGUNCj4gPj4NCj4gPj4gICAgICAgICAgdHlwZSBpZGVudGl0eXJl
ZiB7DQo+ID4+ICAgICAgICAgICAgYmFzZSBhZGRyZXNzLWZhbWlseTsNCj4gPj4gICAgICAgICAg
fQ0KPiA+Pg0KPiA+PiBzbyBpdHMgbWVhbmluZyBmb2xsb3dzIGZyb20gdGhhdCwgaW5jbHVkaW5n
IHRoZSBmYWN0IHRoYXQgdGhlDQo+IGlkZW50aXR5DQo+ID4+IGlzIGV4dGVuc2libGUuIEluIG15
IHZpZXcsIGl0IGlzIGEgZmVhdHVyZSwgbm90IGJ1Zy4NCj4gPj4NCj4gPj4gPg0KPiA+PiA+Pg0K
PiA+PiA+PiA+DQo+ID4+ID4+ID4gVGhpcyBpcyBhbHNvIGEgcHJvYmxlbSBpbiBjYXNlIG9mIE11
bHRpLXRvcG9sb2d5LiBFYWNoIHRvcG9sb2d5DQo+IGhhcw0KPiA+PiA+PiBpdHMgb3duIFJJQiBh
bmQgYSBwcm90b2NvbCBpbnN0YW5jZSBsaWtlIE9TUEYgY2FuIGNvbm5lY3QgdG8NCj4gbXVsdGlw
bGUNCj4gPj4gTVQNCj4gPj4gPj4gUklCcy4NCj4gPj4gPj4NCj4gPj4gPj4gVHdvIHBvc3NpYmxl
IHNvbHV0aW9ucyBjb21lIHRvIG15IG1pbmQ6DQo+ID4+ID4+DQo+ID4+ID4+IDEuIFlvdSBjb3Vs
ZCBkZXJpdmUgbmV3IGFkZHJlc3MgZmFtaWx5IGlkZW50aXRpZXMgZnJvbSAiaXB2NC0NCj4gdW5p
Y2FzdCINCj4gPj4gPj4gZXRjLiBzbyB0aGF0IHlvdSBjYW4gYXNzaWduIGEgdW5pcXVlIGFkZHJl
c3MgZmFtaWx5IHRvIG11bHRpcGxlDQo+ID4+IHRhYmxlcy4NCj4gPj4gPj4NCj4gPj4gPj4gMi4g
WW91IGNvdWxkIGhhdmUgb25lIGNvbm5lY3RlZCBSSUIgZS5nLiBmb3IgImlwdjQtdW5pY2FzdCIg
YW5kDQo+ID4+IGRlZmluZQ0KPiA+PiA+PiB0d28gb3IgbW9yZSBSSUJzIGZvciBlYWNoIHRvcG9s
b2d5IGFzIHJlY2lwaWVudHMgb2YgdGhlIGNvbm5lY3RlZA0KPiBSSUIuDQo+ID4+ID4+IFNvLCBp
biBlZmZlY3QsIHRoZSAoc2luZ2xlKSBjb25uZWN0ZWQgUklCIGNvbnRhaW5zIHJvdXRlcyBmb3Ig
YWxsDQo+ID4+ID4+IHRvcG9sb2dpZXMgYW5kIHRoZXNlIGFyZSB0aGVuIHNwbGl0IHZpYSByb3V0
ZSBmaWx0ZXJzIHRvIHRoZSBwZXItDQo+ID4+ID4+IHRvcG9sb2d5IFJJQnMuDQo+ID4+ID4+DQo+
ID4+ID4+IERvZXMgaXQgbWFrZSBzZW5zZT8NCj4gPj4gPg0KPiA+PiA+IENvbXBhcmUgdGhlIHR3
bywgSSBkb24ndCBsaWtlICMyIGJlY2F1c2UgaXQgYWRkcyBhbiB1bm5lY2Vzc2FyeQ0KPiA+PiBp
bmRpcmVjdGlvbi4gSSBkb24ndCB0aGluayB3ZSB3YW50IHRvIG92ZXJsb2FkICJBZGRyZXNzIEZh
bWlseSINCj4gZnVydGhlcg0KPiA+PiB0byBpbmNsdWRlIHRvcG9sb2d5IGVpdGhlci4gSW4gbWFu
eSBpbXBsZW1lbnRhdGlvbnMsIGFjdHVhbCBSSUJzIGFyZQ0KPiBwZXINCj4gPj4gKHJvdXRpbmct
aW5zdGFuY2UsIEFGSSwgU0FGSSwgdG9wb2xvZ3kpIGFuZCBpdCBtYXkgYmUgZXh0ZW5kZWQNCj4g
ZnVydGhlci4NCj4gPj4gVGhlcmVmb3JlLCB0aGUgYmVzdCBvcHRpb24gaXMgdG8gc2ltcGx5IHJl
bW92ZSB0aGUgcmVzdHJpY3Rpb24gdGhhdA0KPiBvbmUNCj4gPj4gcHJvdG9jb2wgaW5zdGFuY2Ug
aXMgY29ubmVjdGVkIHRvIGV4YWN0bHkgb25lIFJJQiBwZXIgYWRkcmVzcyBmYW1pbHkuDQo+ID4+
DQo+ID4+IFRoaXMgcmVzdHJpY3Rpb24gaXMgb25seSByZWxldmFudCBmb3IgdGhlICJjb25uZWN0
ZWQtcmliIiBsaXN0LiBJZg0KPiB5b3UNCj4gPj4gd2FudCwgeW91IGNhbiBhZGQgY29uZmlndXJh
dGlvbiBwYXJhbWV0ZXJzIHRvIGFzc29jaWF0ZSBvdGhlciBSSUJzDQo+ID4+IGRpcmVjdGx5IHdp
dGggYSByb3V0aW5nIHByb3RvY29sIGluc3RhbmNlLg0KPiA+Pg0KPiA+PiBJTU8sIHRoZSBjb21t
b24gdXNlIGNhc2UgZm9yIE1UIGFyZSBpbmNvbmdydWVudCBJUHY0IGFuZCBJUHY2DQo+IHRvcG9s
b2dpZXMsDQo+ID4+IGFuZCB0aGUgY29yZSByb3V0aW5nIGRhdGEgbW9kZWwgY2FuIGhhbmRsZSB0
aGlzIGRpcmVjdGx5IGFuZCBlYXNpbHkuDQo+ID4+DQo+ID4+IEFsc28gbm90ZSB0aGF0IHRoZSAi
cm91dGluZy1jZmciIGRvY3VtZW50IGhhcyBhbHJlYWR5IGJlZW4gc3VibWl0dGVkDQo+IHRvDQo+
ID4+IElFU0cgZm9yIHB1YmxpY2F0aW9uLCBzbyB5b3VyIGNvbW1lbnRzIGNvbWUgcmVhbGx5IGxh
dGUuDQo+ID4+DQo+ID4+ID4NCj4gPj4gPj4NCj4gPj4gPj4gPg0KPiA+PiA+PiA+IC0tLS0tLQ0K
PiA+PiA+PiA+DQo+ID4+ID4+ID4gNS4xLiAgUm91dGluZyBJbnN0YW5jZQ0KPiA+PiA+PiA+DQo+
ID4+ID4+ID4gICAgRWFjaCByb3V0aW5nIGluc3RhbmNlIGluIHRoZSBjb3JlIHJvdXRpbmcgZGF0
YSBtb2RlbA0KPiByZXByZXNlbnRzDQo+ID4+IGENCj4gPj4gPj4gPiAgICBsb2dpY2FsIHJvdXRl
ci4gIFRoZSBleGFjdCBzZW1hbnRpY3Mgb2YgdGhpcyB0ZXJtIGFyZSBsZWZ0IHRvDQo+ID4+ID4+
ID4gICAgaW1wbGVtZW50YXRpb25zLiAgRm9yIGV4YW1wbGUsIHJvdXRpbmcgaW5zdGFuY2VzIG1h
eSBiZQ0KPiA+PiBjb21wbGV0ZWx5DQo+ID4+ID4+ID4gICAgaXNvbGF0ZWQgdmlydHVhbCByb3V0
ZXJzIG9yLCBhbHRlcm5hdGl2ZWx5LCB0aGV5IG1heQ0KPiBpbnRlcm5hbGx5DQo+ID4+IHNoYXJl
DQo+ID4+ID4+ID4gICAgY2VydGFpbiBpbmZvcm1hdGlvbi4NCj4gPj4gPj4gPg0KPiA+PiA+PiA+
ICAgIC4uLg0KPiA+PiA+PiA+DQo+ID4+ID4+ID4gICAgQW4gaW1wbGVtZW50YXRpb24gTUFZIHN1
cHBvcnQgbXVsdGlwbGUgdHlwZXMgb2YgbG9naWNhbA0KPiByb3V0ZXJzDQo+ID4+ID4+ID4gICAg
c2ltdWx0YW5lb3VzbHkuICBJbnN0YW5jZXMgb2YgYWxsIHJvdXRpbmcgaW5zdGFuY2UgdHlwZXMg
YXJlDQo+ID4+ID4+ID4gICAgb3JnYW5pemVkIGFzIGVudHJpZXMgb2YgdGhlIHNhbWUgZmxhdCAi
cm91dGluZy1pbnN0YW5jZSIgbGlzdC4NCj4gPj4gSW4NCj4gPj4gPj4gPiAgICBvcmRlciB0byBk
aXNjcmltaW5hdGUgcm91dGluZyBpbnN0YW5jZXMgYmVsb25naW5nIHRvDQo+IGRpZmZlcmVudA0K
PiA+PiB0eXBlcywNCj4gPj4gPj4gPiAgICB0aGUgInR5cGUiIGxlYWYgaXMgZGVmaW5lZCBhcyBh
IGNoaWxkIG9mIHRoZSAicm91dGluZy0NCj4gaW5zdGFuY2UiDQo+ID4+IG5vZGUuDQo+ID4+ID4+
ID4NCj4gPj4gPj4gPiBUaGUgc3BlYyBwdXJwb3NlbHkgbGVmdCBpdCBmdXp6eSBhcyB0byB3aGF0
IGEgInJvdXRpbmcgaW5zdGFuY2UiDQo+IGlzLg0KPiA+PiA+PiBIb3dldmVyIHdlIGRlZmluaXRl
bHkgc2hvdWxkIGhhdmUgY2xlYXIgZGVmaW5pdGlvbnMgZm9yIHRoZSB0aHJlZQ0KPiA+PiB0ZXJt
cw0KPiA+PiA+PiBtZW50aW9uZWQ6IHJvdXRpbmctaW5zdGFuY2UsIGxvZ2ljYWwgcm91dGVyIGFu
ZCB2aXJ0dWFsIHJvdXRlci4NCj4gPj4gPj4NCj4gPj4gPj4gWWVzLCB0aGlzIGlzIGJ5IGRlc2ln
biBvcGVuLWVuZGVkIGJlY2F1c2Ugb3RoZXJ3aXNlIHdlIHdvdWxkDQo+IHByb2JhYmx5DQo+ID4+
ID4+IG5ldmVyIHJlYWNoIGNvbnNlbnN1cyBvbiB3aGF0IHRoZXNlIHRlcm1zIGV4YWN0bHkgbWVh
bi4NCj4gPj4gPg0KPiA+PiA+IFdoaWxlIHRoZSBkZXNpZ24gbmVlZHMgdG8gYmUgb3Blbi1lbmRl
ZCBhIHN0YW5kYXJkIHNwZWNpZmljYXRpb24NCj4gbmVlZHMNCj4gPj4gdG8gYmUgcHJlY2lzZSBh
bmQgdW5hbWJpZ3VvdXMuIFRoZSBuYW1lcyBjYW4gYmUgZGlzY3Vzc2VkIGFuZA0KPiA+PiBjb21w
cm9taXNlZCBidXQgdGhlIG1lYW5pbmcgbXVzdCBiZSBjbGVhci4gRm9yIGV4YW1wbGUsIENpc2Nv
DQo+ICJ2aXJ0dWFsDQo+ID4+IHJvdXRlciIgYW5kIEp1bmlwZXIgImxvZ2ljYWwgcm91dGVyL3N5
c3RlbSIgYXJlIHRoZSBzYW1lIGJ1dCBKdW5pcGVyDQo+ID4+ICJ2aXJ0dWFsIHJvdXRlciIgYW5k
IENpc2NvICJWUkYtbGl0ZSIgYXJlIHRoZSBzYW1lLiBXaGF0IGRvZXMgdGhlDQo+ID4+ICJsb2dp
Y2FsIHJvdXRlciIgaW4gdGhpcyBzcGVjIG1lYW4/IFdlIGNhbid0IGp1c3Qgc2F5IHRoYXQgIml0
IGNhbg0KPiBtZWFuDQo+ID4+IGFueSBvZiB0aG9zZSIuIEZvciBleGFtcGxlIGlmIGl0IG1lYW5z
IENpc2NvJ3MgInZpcnR1YWwgcm91dGVyIiBvcg0KPiA+PiBKdW5pcGVyJ3MgImxvZ2ljYWwgc3lz
dGVtIiwgYSBmdXJ0aGVyIGRpc2N1c3Npb24gbWF5IGJlIC0gc2hvdWxkIHRoaXMNCj4gPj4gbW9k
dWxlIHJlYWxseSBjb3ZlciB0aGF0Lg0KPiA+Pg0KPiA+PiBUaGUgdGVybSAibG9naWNhbCByb3V0
ZXIiIGlzIHVzZWQgaW4gYSB2ZXJ5IGdlbmVyYWwgc2Vuc2UsIGFuZCB0aGUNCj4gPj4gZG9jdW1l
bnQgY2xlYXJseSBzYXlzIHNvICgibm8gc2VtYW50aWNzIikuIFRoZSBvdGhlciB0ZXJtcyBhcmUg
dXNlZA0KPiBvbmx5DQo+ID4+IGFzIGV4YW1wbGVzIHdoYXQgaXQgY291bGQgcG9zc2libHkgbWVh
biwgdG8gbWFrZSB0aGUgc3BlYyBtb3JlDQo+ID4+IGFjY2Vzc2libGUuDQo+ID4+DQo+ID4+ID4N
Cj4gPj4gPj4NCj4gPj4gPj4gPg0KPiA+PiA+PiA+IExvZ2ljYWwgcm91dGVyIGlzIGEgdmVyeSBv
dmVybG9hZCB0ZXJtLiBUb2RheSB2ZW5kb3JzIGhhdmUNCj4gPj4gdmlydHVhbGl6ZWQNCj4gPj4g
Pj4gdGhlaXIgcm91dGluZyBjYXBhYmlsaXRpZXMgaW4gdGhlIHN5c3RlbSBhbmQgcHJvdmlkZSAz
IGRpZmZlcmVudA0KPiA+PiBsZXZlbHMNCj4gPj4gPj4gb2Ygcm91dGluZyB2aXJ0dWFsaXphdGlv
bi4gTG9naWNhbCBzeXN0ZW1zLCBsb2dpY2FsIHJvdXRlcnMgYXJlDQo+IHNvbWUNCj4gPj4gb2YN
Cj4gPj4gPj4gdGhlIG5hbWVzIHVzZWQgYnkgdmVuZG9ycyBhbmQgdGhvc2Ugb2ZmZXIgcm91dGlu
ZyBhbmQgbWFuYWdlbWVudA0KPiA+PiA+PiBzZXBhcmF0aW9uLiBFYWNoIGxvZ2ljYWwgc3lzdGVt
IGhhcyBpdHMgb3duIHJvdXRpbmcgaW5zdGFuY2VzIGFuZA0KPiA+PiA+PiByb3V0aW5nIGluc3Rh
bmNlcyBjYW4gaGF2ZSBtdWx0aXBsZSByb3V0aW5nIHRhYmxlcywgc28gaXQgaXMgdmVyeQ0KPiA+
PiA+PiBpbXBvcnRhbnQgdG8gaGF2ZSB2ZXJ5IHByZWNpc2UgZGVmaW5pdGlvbiBvZiB3aGF0IGlz
IHJvdXRpbmcNCj4gaW5zdGFuY2UNCj4gPj4gPj4gKGFuZCBub3QgY29tcGFyZSBpdCB3aXRoIGxv
Z2ljYWwgcm91dGVyKQ0KPiA+PiA+PiA+DQo+ID4+ID4+ID4gwqDCoMKgwqAgaWRlbnRpdHkgc3Rh
bmRhcmQtcm91dGluZy1pbnN0YW5jZSB7DQo+ID4+ID4+ID4gwqDCoMKgwqDCoMKgIGJhc2Ugcm91
dGluZy1pbnN0YW5jZS10eXBlOw0KPiA+PiA+PiA+IMKgwqDCoMKgwqDCoCBkZXNjcmlwdGlvbg0K
PiA+PiA+PiA+IMKgwqDCoMKgwqDCoMKgwqAgIlRoaXMgaWRlbnRpdHkgcmVwcmVzZW50cyBhIGRl
ZmF1bHQgcm91dGluZyBpbnN0YW5jZS4iOw0KPiA+PiA+PiA+IMKgwqDCoMKgIH0NCj4gPj4gPj4g
Pg0KPiA+PiA+PiA+IFdoYXQgaXMgYSAic3RhbmRhcmQtcm91dGluZy1pbnN0YW5jZSI/IFdvdWxk
ICJkZWZhdWx0LXJvdXRpbmctDQo+ID4+ID4+IGluc3RhbmNlIiBiZSBiZXR0ZXI/ICJzdGFuZGFy
ZCIgd29yZGluZyBsZWFkcyB0byAic3RhbmRhcmQgdnMuDQo+IG5vbi0NCj4gPj4gPj4gc3RhbmRh
cmQiIHF1ZXN0aW9uIGFuZCBoaW50cyBvbiB0aGF0IHRoZSB0d28gYXJlIGRpZmZlcmVudCB0eXBl
cy4NCj4gPj4gPj4gImRlZmF1bHQiIHZzLiAibm9uLWRlZmF1bHQiIGRvZXMgbm90IGhhdmUgdGhh
dCAoYXQgbGVhc3QgdG8gbWUpLg0KPiA+PiA+Pg0KPiA+PiA+PiBXZWxsLCAiZGVmYXVsdCIgaXMg
b3ZlcmxvYWRlZCwgdG9vLCBhbmQgYWxzbyBoYXMgYSBzcGVjaWZpYw0KPiBtZWFuaW5nDQo+ID4+
IGluDQo+ID4+ID4+IFlBTkcuIFN0YW5kYXJkIGlzIHN1cHBvc2VkIHRvIG1lYW4gcGxhaW4gdmFu
aWxsYSByb3V0ZXIuIEl0IGlzDQo+IGp1c3QgYQ0KPiA+PiA+PiBuYW1lLg0KPiA+PiA+DQo+ID4+
ID4gSSBkb24ndCBoYXZlIHRvIHNwbGl0IGhhaXIgYmV0d2VlbiAic3RhbmRhcmQiIGFuZCAiZGVm
YXVsdCIgYnV0IHRoZQ0KPiA+PiBzcGVjIG11c3QgcG9pbnQgb3V0IHdoYXQgYSAic3RhbmRhcmQt
cm91dGluZy1pbnN0YW5jZSIgaXMgLSBpcyBpdCB0aGUNCj4gPj4gZGVmYXVsdC9iYXNlL21hc3Rl
ciBsb2dpY2FsLXN5c3RlbSAoQ2lzY28gdmlydHVhbC1yb3V0ZXIpIG9yIHRoZQ0KPiA+PiBkZWZh
dWx0L2Jhc2UvbWFzdGVyICJyb3V0aW5nLWluc3RhbmNlIiAoYSAibG9naWNhbC1zeXN0ZW0iIHdv
dWxkDQo+IGluY2x1ZGUNCj4gPj4gbWFueSAicm91dGluZy1pbnN0YW5jZXMiIGxpa2UgVlJGcyku
DQo+ID4+ID4NCj4gPj4NCj4gPj4gSSB0aGluayB0aGUgaWV0Zi1yb3V0aW5nIG1vZHVsZSBtYWtl
cyBpdCBwcmV0dHkgY2xlYXI6DQo+ID4+DQo+ID4+ICAgICAgICAgIGxlYWYgdHlwZSB7DQo+ID4+
ICAgICAgICAgICAgdHlwZSBpZGVudGl0eXJlZiB7DQo+ID4+ICAgICAgICAgICAgICBiYXNlIHJv
dXRpbmctaW5zdGFuY2UtdHlwZTsNCj4gPj4gICAgICAgICAgICB9DQo+ID4+ICAgICAgICAgICAg
ZGVmYXVsdCAicnQ6c3RhbmRhcmQtcm91dGluZy1pbnN0YW5jZSI7DQo+ID4+ICAgICAgICAgICAg
ZGVzY3JpcHRpb24NCj4gPj4gICAgICAgICAgICAgICJUaGUgdHlwZSBvZiB0aGUgcm91dGluZyBp
bnN0YW5jZS4iOw0KPiA+PiAgICAgICAgICB9DQo+ID4+DQo+ID4+IFRoZSBwdXJwb3NlIG9mIHRo
ZSAidHlwZSIgaXMgdG8gYWxsb3cgZm9yIGRlZmluaW5nIGEgbmV3IHJvdXRpbmcNCj4gPj4gaW5z
dGFuY2UgdHlwZSBhbmQgYXVnbWVudCBjb25maWd1cmF0aW9uIG9yIHN0YXRlIGRhdGEgY29uZGl0
aW9uYWxseQ0KPiBmb3INCj4gPj4gdGhhdCB0eXBlLiBUaGUgInN0YW5kYXJkLXJvdXRpbmctaW5z
dGFuY2UiIGlzIGp1c3QgdGhlIGRlZmF1bHQgdmFsdWUNCj4gdG8NCj4gPj4gc3RhcnQgZnJvbSwg
aXQgaGFzIG5vIG90aGVyIG1lYW5pbmcuDQo+ID4+DQo+ID4+DQo+ID4+ID4+DQo+ID4+ID4+ID4N
Cj4gPj4gPj4gPiBTaG91bGQgdGhpcyBzcGVjIGRpc3Rpbmd1aXNoIFZSRi9WUi9MUiBhbmQgaGF2
ZSBjb3JyZXNwb25kaW5nDQo+ID4+ID4+IGlkZW50aXRpZXMgZGVmaW5lZD8NCj4gPj4gPj4NCj4g
Pj4gPj4gVGhlIGlkZWEgaXMgdGhpcyB3aWxsIGJlIGRvbmUgaW4gb3RoZXIgbW9kdWxlcyB0aGF0
IGRlZmluZSBkYXRhDQo+ID4+IG1vZGVscw0KPiA+PiA+PiBmb3IgdGhlc2UgdHlwZXMgb2Ygcm91
dGluZyBpbnN0YW5jZXMuIFRoZW4gdGhlICJyb3V0aW5nLWluc3RhbmNlIg0KPiA+PiA+PiBjb250
YWluZXIgY2FuIGJlIGF1Z21lbnRlZCB3aXRoIGFyYml0cmFyeSBkYXRhLCBidXQgY29uZGl0aW9u
YWxseQ0KPiBmb3INCj4gPj4gPj4gdGhhdCByb3V0aW5nIGluc3RhbmNlIHR5cGUuDQo+ID4+ID4N
Cj4gPj4gPiBJIHRoaW5rIGl0IGlzIGltcG9ydGFudCB0byBkZWZpbmUgYSBmZXcgd2VsbCBrbm93
biByb3V0aW5nIGluc3RhbmNlDQo+ID4+IHR5cGVzIGluIHRoZSBiYXNlIHNwZWMgYXMgYSBnb29k
IGZvdW5kYXRpb24gZm9yIG90aGVyIG1vZHVsZXMuDQo+ID4+DQo+ID4+IFRoaXMgaXMgb3V0c2lk
ZSB0aGUgc2NvcGUgb2YgdGhlIGNvcmUgcm91dGluZyBkYXRhIG1vZGVsLCBhbmQgc2hvdWxkDQo+
IGJlDQo+ID4+IGRvbmUgYnkgcm91dGluZyBleHBlcnRzLCBub3QgaW4gdGhlIE5FVE1PRCBncm91
cC4gVGhlcmUgYXJlIG90aGVyDQo+ID4+IGluZGlzcGVuc2FibGUgZWxlbWVudHMgdGhhdCBoYXZl
IHRvIGJlIHdvcmtlZCBvdXQgYmVmb3JlIHRoZSByb3V0aW5nDQo+ID4+IGRhdGEgbW9kZWwgY2Fu
IGJlIHJlYWxseSB1c2VmdWwsIGUuZy4gcm91dGluZyBwcm90b2NvbHMgYW5kIHJvdXRlDQo+ID4+
IGZpbHRlcnMuDQo+ID4+DQo+ID4+ID4NCj4gPj4gPj4NCj4gPj4gPj4gQW4gaW1wbGVtZW50YXRp
b24gbWF5IGFjdHVhbGx5IHVzZSBtdWx0aXBsZSByb3V0aW5nLWluc3RhbmNlIHR5cGVzDQo+IGF0
DQo+ID4+ID4+IHRoZSBzYW1lIHRpbWUuDQo+ID4+ID4NCj4gPj4gPiBUaGF0J3MgZm9yIHN1cmUg
YW5kIG5vdCB3aGF0IEknbSBjb25jZXJuZWQgd2l0aC4NCj4gPj4gPg0KPiA+PiA+Pg0KPiA+PiA+
PiA+DQo+ID4+ID4+ID4gwqDCoMKgwqDCoMKgwqDCoCBsZWFmIHR5cGUgew0KPiA+PiA+PiA+IMKg
wqDCoMKgwqDCoMKgwqDCoMKgIHR5cGUgaWRlbnRpdHlyZWYgew0KPiA+PiA+PiA+IMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoCBiYXNlIHJvdXRpbmctaW5zdGFuY2UtdHlwZTsNCj4gPj4gPj4gPiDC
oMKgwqDCoMKgwqDCoMKgwqDCoCB9DQo+ID4+ID4+ID4gwqDCoMKgwqDCoMKgwqDCoMKgwqAgZGVz
Y3JpcHRpb24NCj4gPj4gPj4gPiDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgIlRoZSByb3V0aW5n
IGluc3RhbmNlIHR5cGUsIHByaW1hcmlseSBpbnRlbmRlZCBmb3INCj4gPj4gPj4gPiDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoCBkaXNjcmltaW5hdGluZyBhbW9uZyBkaWZmZXJlbnQgdHlwZXMg
b2YgbG9naWNhbA0KPiA+PiByb3V0ZXJzLA0KPiA+PiA+PiA+IMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgIHJvdXRlIHZpcnR1YWxpemF0aW9uLCBtYXN0ZXItc2xhdmUgYXJyYW5nZW1lbnRzDQo+
IGV0Yy4sDQo+ID4+ID4+ID4gwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgd2hpbGUga2VlcGlu
ZyBhbGwgcm91dGluZyBpbnN0YW5jZXMgaW4gdGhlIHNhbWUNCj4gZmxhdA0KPiA+PiA+PiA+IMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIGxpc3QuIjsNCj4gPj4gPj4gPiDCoMKgwqDCoMKgwqDC
oMKgIH0NCj4gPj4gPj4gPg0KPiA+PiA+PiA+IFdoYXQgaXMgdGhlICJtYXN0ZXItc2xhdmUgYXJy
YW5nZW1lbnRzIj8NCj4gPj4gPj4NCj4gPj4gPj4gVGhpcyBjYW1lIGZyb20gYW4gZWFybHkgcmV2
aWV3IGJ5IFRob21hcyBNb3JpbiwgaXQgaGFzIHRvIGRvIHdpdGgNCj4gPj4gPj4gTVBMUy9CR1Ag
VlBOcyB3aGVyZSBhIG1hc3RlciByb3V0aW5nLWluc3RhbmNlIGV4Y2hhbmdlcyBzZWxlY3RlZA0K
PiA+PiByb3V0ZXMNCj4gPj4gPj4gd2l0aCBlYWNoIFZQTi9WUkYuDQo+ID4+ID4NCj4gPj4gPiBF
aXRoZXIgaXQgbmVlZHMgdG8gYmUgY2xhcmlmaWVkIGluIHRoZSBzcGVjLCBvciBpdCBjb3VsZCBz
aW1wbHkgYmUNCj4gPj4gcmVtb3ZlZCB0byBhdm9pZCBjb25mdXNpb24gc2luY2UgInJvdXRlIHZp
cnR1YWxpemF0aW9uIiBjb3ZlcnMgdGhhdA0KPiA+PiBhbHJlYWR5Lg0KPiA+Pg0KPiA+PiBUaGlz
IGlzIGFjdHVhbGx5IGEgdHlwbyAtIGl0IHNob3VsZCBiZSAicm91dGVyIHZpcnR1YWxpemF0aW9u
Ii4gTXkNCj4gPj4gdW5kZXJzdGFuZGluZyBvZiB0aGlzIHRlcm0gaXMgdGhhdCBhIHZpcnR1YWwg
cm91dGVyIGlzIGlzb2xhdGVkIGFuZA0KPiA+PiBleGNoYW5nZXMgcm91dGluZyBpbmZvcm1hdGlv
biB3aXRoIG90aGVyIHJvdXRlcnMgb25seSB0aHJvdWdoIHJvdXRpbmcNCj4gPj4gcHJvdG9jb2xz
Lg0KPiA+Pg0KPiA+PiBBbnl3YXksIHRoZXNlIGFyZSByZWFsbHkgb25seSBleGFtcGxlcyBhbmQg
SSB0aGluayBpdCBpcyBzdWZmaWNpZW50bHkNCj4gPj4gY2xlYXIgdGhhdCB0aGUgY29yZSByb3V0
aW5nIGRhdGEgbW9kZWwgZG9lc24ndCB1c2UgdGhlc2UgdGVybXMgZm9yDQo+ID4+IGRlZmluaW5n
IGFueSBzZW1hbnRpY3MuDQo+ID4+DQo+ID4+IExhZGENCj4gPj4NCj4gPj4gPg0KPiA+PiA+Pg0K
PiA+PiA+PiA+DQo+ID4+ID4+ID4gRGVwZW5kaW5nIG9uIHRoZSBkZWZpbml0aW9uIG9mICJsb2dp
Y2FsIHJvdXRlciIgYW5kICJyb3V0ZQ0KPiA+PiA+PiB2aXJ0dWFsaXphdGlvbiIsIHRoZXJlIG1h
eSBhbHNvIGJlIGNvbmNlcm5zIHdpdGgga2VlcGluZyBhbGwgdGhvc2UNCj4gPj4ga2luZHMNCj4g
Pj4gPj4gb2YgaW4gdGhlIHNhbWUgZmxhdCBsaXN0Lg0KPiA+PiA+Pg0KPiA+PiA+PiBJdCBpcyBz
aW1pbGFyIHRvIGludGVyZmFjZXMsIHdoZXJlIHBoeXNpY2FsIGFuZCBsb2dpY2FsIGludGVyZmFj
ZXMNCj4gb2YNCj4gPj4gPj4gYWxsIGtpbmRzIGxpdmUgaW4gdGhlIHNhbWUgZmxhdCBsaXN0IGFu
ZCBhcmUgZGlzdGluZ3Vpc2hlZCBieSB0aGUNCj4gPj4gdHlwZS4NCj4gPj4gPj4gSSB0aGluayBp
dCBjb3VsZCB3b3JrLCByZWxhdGlvbnNoaXBzIGFtb25nIHRoZSBpbmRpdmlkdWFsIHJvdXRpbmcN
Cj4gPj4gPj4gaW5zdGFuY2VzIGNhbiBiZSBleHByZXNzZWQgaW4gb3RoZXIgZGF0YS4NCj4gPj4g
Pg0KPiA+PiA+IEkgd2lsbCBkZWZlciB0byBvdGhlcnMgYWJvdXQgdGhlIG1lcml0cyBvZiBhIGZs
YXQgbGlzdCwgYnV0IGZvciBhDQo+IGZsYXQNCj4gPj4gbGlzdCwgdGhlIGJhc2Ugc3BlYyBuZWVk
cyB0byBwcm92aWRlIGEgd2F5IHRvIGV4cHJlc3MgdGhlDQo+IHJlbGF0aW9uc2hpcC4NCj4gPj4g
Pg0KPiA+PiA+IEplZmZyZXkNCj4gPj4gPg0KPiA+PiA+Pg0KPiA+PiA+PiBIYXZpbmcgYSBzaW5n
bGUgZmxhdCBsaXN0IGhhcyBpdHMgYWR2YW50YWdlcywgZm9yIGV4YW1wbGUgeW91IGNhbg0KPiA+
PiB0aGVuDQo+ID4+ID4+IGVhc2lseSByZWZlciB0byByb3V0aW5nIGluc3RhbmNlcyB2aWEgbGVh
ZnJlZnMgKHdoaWNoIGFsbG93IG9ubHkNCj4gb25lDQo+ID4+ID4+IHBhdGgpLg0KPiA+PiA+Pg0K
PiA+PiA+PiBDaGVlcnMsIExhZGENCj4gPj4gPj4NCj4gPj4gPj4gPg0KPiA+PiA+PiA+IEplZmZy
ZXkgWmhhbmcNCj4gPj4gPj4gPiBEZWFuIEJvZ2Rhbm92aWMNCj4gPj4gPj4NCj4gPj4gPj4gLS0N
Cj4gPj4gPj4gTGFkaXNsYXYgTGhvdGthLCBDWi5OSUMgTGFicw0KPiA+PiA+PiBQR1AgS2V5IElE
OiBFNzRFOEMwQw0KPiA+Pg0KPiA+PiAtLQ0KPiA+PiBMYWRpc2xhdiBMaG90a2EsIENaLk5JQyBM
YWJzDQo+ID4+IFBHUCBLZXkgSUQ6IEU3NEU4QzBDDQo+IA0KPiAtLQ0KPiBMYWRpc2xhdiBMaG90
a2EsIENaLk5JQyBMYWJzDQo+IFBHUCBLZXkgSUQ6IEU3NEU4QzBDDQo+IA0KDQo=


From nobody Mon Jun 23 08:32:52 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F3631B2AF3 for ; Mon, 23 Jun 2014 08:32:51 -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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BxqwskMWkZ3K for ; Mon, 23 Jun 2014 08:32:45 -0700 (PDT)
Received: from mail-yk0-x22b.google.com (mail-yk0-x22b.google.com [IPv6:2607:f8b0:4002:c07::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 287671B296A for ; Mon, 23 Jun 2014 08:32:45 -0700 (PDT)
Received: by mail-yk0-f171.google.com with SMTP id 200so4861655ykr.2 for ; Mon, 23 Jun 2014 08:32:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=aJ6PgUp3TqXcBqyLBHDvV5a1zf3Kg9XiUvCrSoUwIE4=; b=mOmq8aXvYgKz+1oM0/hbLvYvmV9oggO9ZMC3WGm+OSfMCPWn4+LC8meSQz6kRPuwe1 r7FYA9xnuU6IwyoeFh63sNHeV8bwRO1GYga/Kz7Af2eD9uwB3vJQvKxpY1bmqkZj9WQh CjnrRu4azY6pm7Xw7s//riLEmmBW8ME9Ekzxe4+FivZasQjDDUqFkeT2/yllxDRA3vrj rUhBz7SAopoPeCT+TSl40IF8P+E59WpO0w90WUF64BK9MerF29632Ui4Vh0fIqMlo4PS x6rpp5+drGWdbNx9sTyr+Hm8OadhVbOlhPYoF7/zoqkvILfDQZyQ9C62eg4pYEPd3R+a ceTA==
MIME-Version: 1.0
X-Received: by 10.236.39.109 with SMTP id c73mr5440649yhb.139.1403537564345; Mon, 23 Jun 2014 08:32:44 -0700 (PDT)
Received: by 10.170.58.10 with HTTP; Mon, 23 Jun 2014 08:32:44 -0700 (PDT)
In-Reply-To: 
References:   <18cd777ffb9d4df6b0966dd1b3dd822b@BY2PR05MB079.namprd05.prod.outlook.com>   
Date: Mon, 23 Jun 2014 11:32:44 -0400
Message-ID: 
From: Alia Atlas 
To: Ladislav Lhotka 
Content-Type: multipart/alternative; boundary=001a1136bfcef3ad3204fc828de8
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/o6Aw8ySfEksVznLi9FPMir__Z8U
Cc: "Jeffrey \(Zhaohui\) Zhang" , Kiran Agrahara Sreenivasa , "netmod@ietf.org" 
Subject: Re: [netmod] Questions/comments on draft-ietf-netmod-routing-cfg
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 23 Jun 2014 15:32:51 -0000

--001a1136bfcef3ad3204fc828de8
Content-Type: text/plain; charset=UTF-8

Lada,

On Mon, Jun 23, 2014 at 10:38 AM, Ladislav Lhotka  wrote:

> "Jeffrey (Zhaohui) Zhang"  writes:
>
> > Lada,
> >
> > The discussions basically boil down to two main points:
> >
> > - I believe the spec should have well defined semantics for some
> well-known types of "routing-instances". Otherwise it is too loose to be
> the foundation for future work (e.g. the on-going OSPF YANG model work).
> That does not prevent the flexibility for future extensions.
>
> The OSPF (and more recent ISIS) module can work just fine with
> "standard-routing-instance". On smaller router platforms (OpenWRT with
> Quagga or BIRD daemons) this is all that's needed. I don't know why
> specific routing instance types couldn't be defined in separate modules.
>
>
Supporting very common features (L3VPNs, logical routers, multiple routing
instances) can
make routers significantly more complex than Quagga supports.  While Quagga
certainly has some useful features, I do not think it has kept pace.  What
is needed for routing is more.


> >
> > - I think the spec is too restrictive in saying "Each routing protocol
> instance is connected to exactly one RIB for each address family that the
> routing protocol instance supports". We can mix AF and SAF together and
> simply say Address Family (if we make it clear) but with the consideration
> of MT the statement is just not correct.
>
> There are currently three possible solutions:
>
> 1. Subdivide each address family via identity derivation, e.g. with
> respect to type of service.
>
> 2. Distribute routes from the connected RIB selectively to any number
> other RIBs via "recipient-rib" mechanism.
>
> 3. Augment the "routing-protocol" subtrees with new parameters. For
> example, one could introduce protocol "sub-instances", one for each
> topology, and then different sub-instances could use the same address
> family (this is by the way another advantage of having a flat list of
> routing protocol instances).
>
> In my view, this choice should be sufficient.
>
>
> >
> > I am more concerned with the first point.
> >
> > I don't think this is too late. There is still IETF last call and I am
> posting my comments here. If there is enough consensus to my points, then
> necessary changes need to happen. If not, I'll accept that.
>
> The routing-cfg document is already long overdue. We've already had
> several rounds of relatively significant redesigns based on reviewers'
> comments, and I think now it's time to deliver the result. The data model
> may not be perfect and I am open to returning to it after we gain some
> experience, but IMO we first need to fill the gaps by developing modules
> for routing protocols, route filters and, of course, specific types of
> routing instances.
>

Jeffrey is coming in, trying to work on an OSPF YANG model, as a routing
person very familiar with one implementation.  If this draft is not a
sufficient base on which to build the other routing models, how should we
proceed?  I have requested yet another routing directorate review on this
draft; I'd expect that review before the upcoming IETF.

I can appreciate the frustration in the time it is taking to get this draft
done.  Cross-area review does frequently happen after WGLC.

Alia

Lada
>
> >
> > Thanks.
> > Jeffrey
> >
> >> -----Original Message-----
> >> From: Ladislav Lhotka [mailto:lhotka@nic.cz]
> >> Sent: Monday, June 23, 2014 4:26 AM
> >> To: Jeffrey (Zhaohui) Zhang; Dean Bogdanovic; netmod@ietf.org
> >> Cc: Derek Man-Kit Yeung (myeung); Kiran Agrahara Sreenivasa
> >> Subject: RE: Questions/comments on draft-ietf-netmod-routing-cfg
> >>
> >> "Jeffrey (Zhaohui) Zhang"  writes:
> >>
> >> > Lada,
> >> >
> >> >> -----Original Message-----
> >> >> From: Ladislav Lhotka [mailto:lhotka@nic.cz]
> >> >> Sent: Friday, June 20, 2014 7:26 AM
> >> >> To: Jeffrey (Zhaohui) Zhang; Dean Bogdanovic; netmod@ietf.org
> >> >> Cc: Derek Man-Kit Yeung (myeung); Kiran Agrahara Sreenivasa
> >> >> Subject: Re: Questions/comments on draft-ietf-netmod-routing-cfg
> >> >>
> >> >> "Jeffrey (Zhaohui) Zhang"  writes:
> >> >>
> >> >> > Ladislav,
> >> >> >
> >> >> > Dean and I have some late questions and comments. We came across
> >> these
> >> >> while trying to work on the OSPF YANG model.
> >> >> >
> >> >> > -----------
> >> >> >
> >> >> > The spec mentions in several places something like the following:
> >> >> >
> >> >> >    Each routing protocol instance is connected to exactly one RIB
> >> for
> >> >> >    each address family that the routing protocol instance supports.
> >> >> >
> >> >> > My understanding is that the address family mentioned above does
> >> not
> >> >> include SAFI. Because of that, a routing protocol like BGP may
> >> connect
> >> >> to multiple RIBs in the same family (RIB for unicast and RIB for
> >> >> multicast RPF purpose in case of incongruent multicast topology) so
> >> the
> >> >> above statement is not correct.
> >> >>
> >> >> This is quite flexible since address family is defined via
> identities.
> >> I
> >> >> can imagine one implementation using only "ipv4" and "ipv6" (defined
> >> in
> >> >> ietf-routing) whilst other implementation could use "ipv[46]-unicast"
> >> >> (defined in ietf-ipv[46]-unicast-routing) and "ipv[46]-multicast" (to
> >> be
> >> >> defined in a module for unicast routing), that means including SAFI.
> >> >
> >> > Address Family has very specific meanings, typically only refer to
> >> IPv4/IPv6 to my understanding. If we want to extend that to include
> SAFI,
> >> then the spec must point it out. More below related to MT.
> >>
> >> Both Cisco and Juniper docs use terms like "IPv6 multicast address
> >> family" or "MCAST-VPN address family" that clearly include SAFI as well.
> >>
> >> For better or worse, in the ietf-routing YANG module "address-family"
> >> leaf is defined with the type
> >>
> >>          type identityref {
> >>            base address-family;
> >>          }
> >>
> >> so its meaning follows from that, including the fact that the identity
> >> is extensible. In my view, it is a feature, not bug.
> >>
> >> >
> >> >>
> >> >> >
> >> >> > This is also a problem in case of Multi-topology. Each topology has
> >> >> its own RIB and a protocol instance like OSPF can connect to multiple
> >> MT
> >> >> RIBs.
> >> >>
> >> >> Two possible solutions come to my mind:
> >> >>
> >> >> 1. You could derive new address family identities from "ipv4-unicast"
> >> >> etc. so that you can assign a unique address family to multiple
> >> tables.
> >> >>
> >> >> 2. You could have one connected RIB e.g. for "ipv4-unicast" and
> >> define
> >> >> two or more RIBs for each topology as recipients of the connected
> RIB.
> >> >> So, in effect, the (single) connected RIB contains routes for all
> >> >> topologies and these are then split via route filters to the per-
> >> >> topology RIBs.
> >> >>
> >> >> Does it make sense?
> >> >
> >> > Compare the two, I don't like #2 because it adds an unnecessary
> >> indirection. I don't think we want to overload "Address Family" further
> >> to include topology either. In many implementations, actual RIBs are per
> >> (routing-instance, AFI, SAFI, topology) and it may be extended further.
> >> Therefore, the best option is to simply remove the restriction that one
> >> protocol instance is connected to exactly one RIB per address family.
> >>
> >> This restriction is only relevant for the "connected-rib" list. If you
> >> want, you can add configuration parameters to associate other RIBs
> >> directly with a routing protocol instance.
> >>
> >> IMO, the common use case for MT are incongruent IPv4 and IPv6
> topologies,
> >> and the core routing data model can handle this directly and easily.
> >>
> >> Also note that the "routing-cfg" document has already been submitted to
> >> IESG for publication, so your comments come really late.
> >>
> >> >
> >> >>
> >> >> >
> >> >> > ------
> >> >> >
> >> >> > 5.1.  Routing Instance
> >> >> >
> >> >> >    Each routing instance in the core routing data model represents
> >> a
> >> >> >    logical router.  The exact semantics of this term are left to
> >> >> >    implementations.  For example, routing instances may be
> >> completely
> >> >> >    isolated virtual routers or, alternatively, they may internally
> >> share
> >> >> >    certain information.
> >> >> >
> >> >> >    ...
> >> >> >
> >> >> >    An implementation MAY support multiple types of logical routers
> >> >> >    simultaneously.  Instances of all routing instance types are
> >> >> >    organized as entries of the same flat "routing-instance" list.
> >> In
> >> >> >    order to discriminate routing instances belonging to different
> >> types,
> >> >> >    the "type" leaf is defined as a child of the "routing-instance"
> >> node.
> >> >> >
> >> >> > The spec purposely left it fuzzy as to what a "routing instance"
> is.
> >> >> However we definitely should have clear definitions for the three
> >> terms
> >> >> mentioned: routing-instance, logical router and virtual router.
> >> >>
> >> >> Yes, this is by design open-ended because otherwise we would probably
> >> >> never reach consensus on what these terms exactly mean.
> >> >
> >> > While the design needs to be open-ended a standard specification needs
> >> to be precise and unambiguous. The names can be discussed and
> >> compromised but the meaning must be clear. For example, Cisco "virtual
> >> router" and Juniper "logical router/system" are the same but Juniper
> >> "virtual router" and Cisco "VRF-lite" are the same. What does the
> >> "logical router" in this spec mean? We can't just say that "it can mean
> >> any of those". For example if it means Cisco's "virtual router" or
> >> Juniper's "logical system", a further discussion may be - should this
> >> module really cover that.
> >>
> >> The term "logical router" is used in a very general sense, and the
> >> document clearly says so ("no semantics"). The other terms are used only
> >> as examples what it could possibly mean, to make the spec more
> >> accessible.
> >>
> >> >
> >> >>
> >> >> >
> >> >> > Logical router is a very overload term. Today vendors have
> >> virtualized
> >> >> their routing capabilities in the system and provide 3 different
> >> levels
> >> >> of routing virtualization. Logical systems, logical routers are some
> >> of
> >> >> the names used by vendors and those offer routing and management
> >> >> separation. Each logical system has its own routing instances and
> >> >> routing instances can have multiple routing tables, so it is very
> >> >> important to have very precise definition of what is routing instance
> >> >> (and not compare it with logical router)
> >> >> >
> >> >> >      identity standard-routing-instance {
> >> >> >        base routing-instance-type;
> >> >> >        description
> >> >> >          "This identity represents a default routing instance.";
> >> >> >      }
> >> >> >
> >> >> > What is a "standard-routing-instance"? Would "default-routing-
> >> >> instance" be better? "standard" wording leads to "standard vs. non-
> >> >> standard" question and hints on that the two are different types.
> >> >> "default" vs. "non-default" does not have that (at least to me).
> >> >>
> >> >> Well, "default" is overloaded, too, and also has a specific meaning
> >> in
> >> >> YANG. Standard is supposed to mean plain vanilla router. It is just a
> >> >> name.
> >> >
> >> > I don't have to split hair between "standard" and "default" but the
> >> spec must point out what a "standard-routing-instance" is - is it the
> >> default/base/master logical-system (Cisco virtual-router) or the
> >> default/base/master "routing-instance" (a "logical-system" would include
> >> many "routing-instances" like VRFs).
> >> >
> >>
> >> I think the ietf-routing module makes it pretty clear:
> >>
> >>          leaf type {
> >>            type identityref {
> >>              base routing-instance-type;
> >>            }
> >>            default "rt:standard-routing-instance";
> >>            description
> >>              "The type of the routing instance.";
> >>          }
> >>
> >> The purpose of the "type" is to allow for defining a new routing
> >> instance type and augment configuration or state data conditionally for
> >> that type. The "standard-routing-instance" is just the default value to
> >> start from, it has no other meaning.
> >>
> >>
> >> >>
> >> >> >
> >> >> > Should this spec distinguish VRF/VR/LR and have corresponding
> >> >> identities defined?
> >> >>
> >> >> The idea is this will be done in other modules that define data
> >> models
> >> >> for these types of routing instances. Then the "routing-instance"
> >> >> container can be augmented with arbitrary data, but conditionally for
> >> >> that routing instance type.
> >> >
> >> > I think it is important to define a few well known routing instance
> >> types in the base spec as a good foundation for other modules.
> >>
> >> This is outside the scope of the core routing data model, and should be
> >> done by routing experts, not in the NETMOD group. There are other
> >> indispensable elements that have to be worked out before the routing
> >> data model can be really useful, e.g. routing protocols and route
> >> filters.
> >>
> >> >
> >> >>
> >> >> An implementation may actually use multiple routing-instance types at
> >> >> the same time.
> >> >
> >> > That's for sure and not what I'm concerned with.
> >> >
> >> >>
> >> >> >
> >> >> >          leaf type {
> >> >> >            type identityref {
> >> >> >              base routing-instance-type;
> >> >> >            }
> >> >> >            description
> >> >> >              "The routing instance type, primarily intended for
> >> >> >               discriminating among different types of logical
> >> routers,
> >> >> >               route virtualization, master-slave arrangements etc.,
> >> >> >               while keeping all routing instances in the same flat
> >> >> >               list.";
> >> >> >          }
> >> >> >
> >> >> > What is the "master-slave arrangements"?
> >> >>
> >> >> This came from an early review by Thomas Morin, it has to do with
> >> >> MPLS/BGP VPNs where a master routing-instance exchanges selected
> >> routes
> >> >> with each VPN/VRF.
> >> >
> >> > Either it needs to be clarified in the spec, or it could simply be
> >> removed to avoid confusion since "route virtualization" covers that
> >> already.
> >>
> >> This is actually a typo - it should be "router virtualization". My
> >> understanding of this term is that a virtual router is isolated and
> >> exchanges routing information with other routers only through routing
> >> protocols.
> >>
> >> Anyway, these are really only examples and I think it is sufficiently
> >> clear that the core routing data model doesn't use these terms for
> >> defining any semantics.
> >>
> >> Lada
> >>
> >> >
> >> >>
> >> >> >
> >> >> > Depending on the definition of "logical router" and "route
> >> >> virtualization", there may also be concerns with keeping all those
> >> kinds
> >> >> of in the same flat list.
> >> >>
> >> >> It is similar to interfaces, where physical and logical interfaces of
> >> >> all kinds live in the same flat list and are distinguished by the
> >> type.
> >> >> I think it could work, relationships among the individual routing
> >> >> instances can be expressed in other data.
> >> >
> >> > I will defer to others about the merits of a flat list, but for a flat
> >> list, the base spec needs to provide a way to express the relationship.
> >> >
> >> > Jeffrey
> >> >
> >> >>
> >> >> Having a single flat list has its advantages, for example you can
> >> then
> >> >> easily refer to routing instances via leafrefs (which allow only one
> >> >> path).
> >> >>
> >> >> Cheers, Lada
> >> >>
> >> >> >
> >> >> > Jeffrey Zhang
> >> >> > Dean Bogdanovic
> >> >>
> >> >> --
> >> >> Ladislav Lhotka, CZ.NIC Labs
> >> >> PGP Key ID: E74E8C0C
> >>
> >> --
> >> Ladislav Lhotka, CZ.NIC Labs
> >> PGP Key ID: E74E8C0C
>
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>

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


Lada,

On Mon, Jun 23, 2014 at 10:38 AM, Ladislav Lhotka &l=
t;lhotka@nic.cz><=
/span> wrote:


"Jeffrey (Zhaohui) Zhan=
g" <zzhang@juniper.net>=
; writes:




> Lada,

>


> The discussions basically boil down to two main =
points:

>

> - I believe the spec should have well defined semantics for some well-=
known types of "routing-instances". Otherwise it is too loose to =
be the foundation for future work (e.g. the on-going OSPF YANG model work).=
 That does not prevent the flexibility for future extensions.





The OSPF (and more recent ISIS) module can work just fine with "=
standard-routing-instance". On smaller router platforms (OpenWRT with =
Quagga or BIRD daemons) this is all that's needed. I don't know why=
 specific routing instance types couldn't be defined in separate module=
s.





Supporting very =
common features (L3VPNs, logical routers, multiple routing instances) can
make routers significantly more complex than Quagga supports. =C2=
=A0While Quagga certainly has some useful features, I do not think it has k=
ept pace. =C2=A0What is needed for routing is more.


=C2=A0

>

> - I think the spec is too restrictive in saying "Each routing pro=
tocol instance is connected to exactly one RIB for each address family that=
 the routing protocol instance supports". We can mix AF and SAF togeth=
er and simply say Address Family (if we make it clear) but with the conside=
ration of MT the statement is just not correct.





There are currently three possible solutions:



1. Subdivide each address family via identity derivation, e.g. with respect=
 to type of service.



2. Distribute routes from the connected RIB selectively to any number other=
 RIBs via "recipient-rib" mechanism.



3. Augment the "routing-protocol" subtrees with new parameters. F=
or example, one could introduce protocol "sub-instances", one for=
 each topology, and then different sub-instances could use the same address=
 family (this is by the way another advantage of having a flat list of rout=
ing protocol instances).




In my view, this choice should be sufficient.






>

> I am more concerned with the first point.

>

> I don't think this is too late. There is still IETF last call and =
I am posting my comments here. If there is enough consensus to my points, t=
hen necessary changes need to happen. If not, I'll accept that.





The routing-cfg document is already long overdue. We've already h=
ad several rounds of relatively significant redesigns based on reviewers=
9; comments, and I think now it's time to deliver the result. The data =
model may not be perfect and I am open to returning to it after we gain som=
e experience, but IMO we first need to fill the gaps by developing modules =
for routing protocols, route filters and, of course, specific types of rout=
ing instances.



Jeffrey is coming in, trying to work on an=
 OSPF YANG model, as a routing person very familiar with one implementation=
. =C2=A0If this draft is not a sufficient base on which to build the other =
routing models, how should we proceed? =C2=A0I have requested yet another r=
outing directorate review on this draft; I'd expect that review before =
the upcoming IETF.



I can appreciate the frustration in the time it is taki=
ng to get this draft done. =C2=A0Cross-area review does frequently happen a=
fter WGLC.

Alia


Lada




>

> Thanks.

> Jeffrey

>

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

>> From: Ladislav Lhotka [mailto:lho=
tka@nic.cz]

>> Sent: Monday, June 23, 2014 4:26 AM

>> To: Jeffrey (Zhaohui) Zhang; Dean Bogdanovic; netmod@ietf.org

>> Cc: Derek Man-Kit Yeung (myeung); Kiran Agrahara Sreenivasa

>> Subject: RE: Questions/comments on draft-ietf-netmod-routing-cfg
>>

>> "Jeffrey (Zhaohui) Zhang" <zzhang@juniper.net> writes:

>>

>> > Lada,

>> >

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

>> >> From: Ladislav Lhotka [mailto:lhotka@nic.cz]

>> >> Sent: Friday, June 20, 2014 7:26 AM

>> >> To: Jeffrey (Zhaohui) Zhang; Dean Bogdanovic; netmod@ietf.org

>> >> Cc: Derek Man-Kit Yeung (myeung); Kiran Agrahara Sreeniva=
sa

>> >> Subject: Re: Questions/comments on draft-ietf-netmod-rout=
ing-cfg

>> >>

>> >> "Jeffrey (Zhaohui) Zhang" <zzhang@juniper.net> writes:

>> >>

>> >> > Ladislav,

>> >> >

>> >> > Dean and I have some late questions and comments. We=
 came across

>> these

>> >> while trying to work on the OSPF YANG model.

>> >> >

>> >> > -----------

>> >> >

>> >> > The spec mentions in several places something like t=
he following:

>> >> >

>> >> > =C2=A0=C2=A0 Each routing protocol instance is conne=
cted to exactly one RIB

>> for

>> >> > =C2=A0=C2=A0 each address family that the routing pr=
otocol instance supports.

>> >> >

>> >> > My understanding is that the address family mentione=
d above does

>> not

>> >> include SAFI. Because of that, a routing protocol like BG=
P may

>> connect

>> >> to multiple RIBs in the same family (RIB for unicast and =
RIB for

>> >> multicast RPF purpose in case of incongruent multicast to=
pology) so

>> the

>> >> above statement is not correct.

>> >>

>> >> This is quite flexible since address family is defined vi=
a identities.

>> I

>> >> can imagine one implementation using only "ipv4"=
; and "ipv6" (defined

>> in

>> >> ietf-routing) whilst other implementation could use "=
;ipv[46]-unicast"

>> >> (defined in ietf-ipv[46]-unicast-routing) and "ipv[4=
6]-multicast" (to

>> be

>> >> defined in a module for unicast routing), that means incl=
uding SAFI.

>> >

>> > Address Family has very specific meanings, typically only ref=
er to

>> IPv4/IPv6 to my understanding. If we want to extend that to includ=
e SAFI,

>> then the spec must point it out. More below related to MT.

>>

>> Both Cisco and Juniper docs use terms like "IPv6 multicast ad=
dress

>> family" or "MCAST-VPN address family" that clearly =
include SAFI as well.

>>

>> For better or worse, in the ietf-routing YANG module "address=
-family"

>> leaf is defined with the type

>>

>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type identityref {

>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0base address-family;

>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}

>>

>> so its meaning follows from that, including the fact that the iden=
tity

>> is extensible. In my view, it is a feature, not bug.

>>

>> >

>> >>

>> >> >

>> >> > This is also a problem in case of Multi-topology. Ea=
ch topology has

>> >> its own RIB and a protocol instance like OSPF can connect=
 to multiple

>> MT

>> >> RIBs.

>> >>

>> >> Two possible solutions come to my mind:

>> >>

>> >> 1. You could derive new address family identities from &q=
uot;ipv4-unicast"

>> >> etc. so that you can assign a unique address family to mu=
ltiple

>> tables.

>> >>

>> >> 2. You could have one connected RIB e.g. for "ipv4-u=
nicast" and

>> define

>> >> two or more RIBs for each topology as recipients of the c=
onnected RIB.

>> >> So, in effect, the (single) connected RIB contains routes=
 for all

>> >> topologies and these are then split via route filters to =
the per-

>> >> topology RIBs.

>> >>

>> >> Does it make sense?

>> >

>> > Compare the two, I don't like #2 because it adds an unnec=
essary

>> indirection. I don't think we want to overload "Address F=
amily" further

>> to include topology either. In many implementations, actual RIBs a=
re per

>> (routing-instance, AFI, SAFI, topology) and it may be extended fur=
ther.

>> Therefore, the best option is to simply remove the restriction tha=
t one

>> protocol instance is connected to exactly one RIB per address fami=
ly.

>>

>> This restriction is only relevant for the "connected-rib"=
; list. If you

>> want, you can add configuration parameters to associate other RIBs=


>> directly with a routing protocol instance.

>>

>> IMO, the common use case for MT are incongruent IPv4 and IPv6 topo=
logies,

>> and the core routing data model can handle this directly and easil=
y.

>>

>> Also note that the "routing-cfg" document has already be=
en submitted to

>> IESG for publication, so your comments come really late.

>>

>> >

>> >>

>> >> >

>> >> > ------

>> >> >

>> >> > 5.1. =C2=A0Routing Instance

>> >> >

>> >> > =C2=A0 =C2=A0Each routing instance in the core routi=
ng data model represents

>> a

>> >> > =C2=A0 =C2=A0logical router. =C2=A0The exact semanti=
cs of this term are left to

>> >> > =C2=A0 =C2=A0implementations. =C2=A0For example, rou=
ting instances may be

>> completely

>> >> > =C2=A0 =C2=A0isolated virtual routers or, alternativ=
ely, they may internally

>> share

>> >> > =C2=A0 =C2=A0certain information.

>> >> >

>> >> > =C2=A0 =C2=A0...

>> >> >

>> >> > =C2=A0 =C2=A0An implementation MAY support multiple =
types of logical routers

>> >> > =C2=A0 =C2=A0simultaneously. =C2=A0Instances of all =
routing instance types are

>> >> > =C2=A0 =C2=A0organized as entries of the same flat &=
quot;routing-instance" list.

>> In

>> >> > =C2=A0 =C2=A0order to discriminate routing instances=
 belonging to different

>> types,

>> >> > =C2=A0 =C2=A0the "type" leaf is defined as=
 a child of the "routing-instance"

>> node.

>> >> >

>> >> > The spec purposely left it fuzzy as to what a "=
routing instance" is.

>> >> However we definitely should have clear definitions for t=
he three

>> terms

>> >> mentioned: routing-instance, logical router and virtual r=
outer.

>> >>

>> >> Yes, this is by design open-ended because otherwise we wo=
uld probably

>> >> never reach consensus on what these terms exactly mean.
>> >

>> > While the design needs to be open-ended a standard specificat=
ion needs

>> to be precise and unambiguous. The names can be discussed and

>> compromised but the meaning must be clear. For example, Cisco &quo=
t;virtual

>> router" and Juniper "logical router/system" are the=
 same but Juniper

>> "virtual router" and Cisco "VRF-lite" are the =
same. What does the

>> "logical router" in this spec mean? We can't just sa=
y that "it can mean

>> any of those". For example if it means Cisco's "virt=
ual router" or

>> Juniper's "logical system", a further discussion may=
 be - should this

>> module really cover that.

>>

>> The term "logical router" is used in a very general sens=
e, and the

>> document clearly says so ("no semantics"). The other ter=
ms are used only

>> as examples what it could possibly mean, to make the spec more

>> accessible.

>>

>> >

>> >>

>> >> >

>> >> > Logical router is a very overload term. Today vendor=
s have

>> virtualized

>> >> their routing capabilities in the system and provide 3 di=
fferent

>> levels

>> >> of routing virtualization. Logical systems, logical route=
rs are some

>> of

>> >> the names used by vendors and those offer routing and man=
agement

>> >> separation. Each logical system has its own routing insta=
nces and

>> >> routing instances can have multiple routing tables, so it=
 is very

>> >> important to have very precise definition of what is rout=
ing instance

>> >> (and not compare it with logical router)

>> >> >

>> >> > =C2=A0=C2=A0=C2=A0=C2=A0 identity standard-routing-i=
nstance {

>> >> > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 base routing-in=
stance-type;

>> >> > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 description

>> >> > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 &qu=
ot;This identity represents a default routing instance.";

>> >> > =C2=A0=C2=A0=C2=A0=C2=A0 }

>> >> >

>> >> > What is a "standard-routing-instance"? Wou=
ld "default-routing-

>> >> instance" be better? "standard" wording le=
ads to "standard vs. non-

>> >> standard" question and hints on that the two are dif=
ferent types.

>> >> "default" vs. "non-default" does not =
have that (at least to me).

>> >>

>> >> Well, "default" is overloaded, too, and also ha=
s a specific meaning

>> in

>> >> YANG. Standard is supposed to mean plain vanilla router. =
It is just a

>> >> name.

>> >

>> > I don't have to split hair between "standard" a=
nd "default" but the

>> spec must point out what a "standard-routing-instance" i=
s - is it the

>> default/base/master logical-system (Cisco virtual-router) or the
>> default/base/master "routing-instance" (a "logical-=
system" would include

>> many "routing-instances" like VRFs).

>> >

>>

>> I think the ietf-routing module makes it pretty clear:

>>

>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0leaf type {

>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type identityref {

>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0base routing-insta=
nce-type;

>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}

>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0default "rt:standard=
-routing-instance";

>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0description

>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"The type of =
the routing instance.";

>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}

>>

>> The purpose of the "type" is to allow for defining a new=
 routing

>> instance type and augment configuration or state data conditionall=
y for

>> that type. The "standard-routing-instance" is just the d=
efault value to

>> start from, it has no other meaning.

>>

>>

>> >>

>> >> >

>> >> > Should this spec distinguish VRF/VR/LR and have corr=
esponding

>> >> identities defined?

>> >>

>> >> The idea is this will be done in other modules that defin=
e data

>> models

>> >> for these types of routing instances. Then the "rout=
ing-instance"

>> >> container can be augmented with arbitrary data, but condi=
tionally for

>> >> that routing instance type.

>> >

>> > I think it is important to define a few well known routing in=
stance

>> types in the base spec as a good foundation for other modules.

>>

>> This is outside the scope of the core routing data model, and shou=
ld be

>> done by routing experts, not in the NETMOD group. There are other<=
br>
>> indispensable elements that have to be worked out before the routi=
ng

>> data model can be really useful, e.g. routing protocols and route<=
br>
>> filters.

>>

>> >

>> >>

>> >> An implementation may actually use multiple routing-insta=
nce types at

>> >> the same time.

>> >

>> > That's for sure and not what I'm concerned with.

>> >

>> >>

>> >> >

>> >> > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 lea=
f type {

>> >> > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 type identityref {

>> >> > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 base routing-instance-type;

>> >> > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 }

>> >> > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 description

>> >> > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 "The routing instance type, primarily intended f=
or

>> >> > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 discriminating among different types of logical=


>> routers,

>> >> > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 route virtualization, master-slave arrangements=
 etc.,

>> >> > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 while keeping all routing instances in the same=
 flat

>> >> > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 list.";

>> >> > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 }
>> >> >

>> >> > What is the "master-slave arrangements"?
>> >>

>> >> This came from an early review by Thomas Morin, it has to=
 do with

>> >> MPLS/BGP VPNs where a master routing-instance exchanges s=
elected

>> routes

>> >> with each VPN/VRF.

>> >

>> > Either it needs to be clarified in the spec, or it could simp=
ly be

>> removed to avoid confusion since "route virtualization" =
covers that

>> already.

>>

>> This is actually a typo - it should be "router virtualization=
". My

>> understanding of this term is that a virtual router is isolated an=
d

>> exchanges routing information with other routers only through rout=
ing

>> protocols.

>>

>> Anyway, these are really only examples and I think it is sufficien=
tly

>> clear that the core routing data model doesn't use these terms=
 for

>> defining any semantics.

>>

>> Lada

>>

>> >

>> >>

>> >> >

>> >> > Depending on the definition of "logical router&=
quot; and "route

>> >> virtualization", there may also be concerns with kee=
ping all those

>> kinds

>> >> of in the same flat list.

>> >>

>> >> It is similar to interfaces, where physical and logical i=
nterfaces of

>> >> all kinds live in the same flat list and are distinguishe=
d by the

>> type.

>> >> I think it could work, relationships among the individual=
 routing

>> >> instances can be expressed in other data.

>> >

>> > I will defer to others about the merits of a flat list, but f=
or a flat

>> list, the base spec needs to provide a way to express the relation=
ship.

>> >

>> > Jeffrey

>> >

>> >>

>> >> Having a single flat list has its advantages, for example=
 you can

>> then

>> >> easily refer to routing instances via leafrefs (which all=
ow only one

>> >> path).

>> >>

>> >> Cheers, Lada

>> >>

>> >> >

>> >> > Jeffrey Zhang

>> >> > Dean Bogdanovic

>> >>

>> >> --

>> >> Ladislav Lhotka, CZ.NIC Labs

>> >> PGP Key ID: E74E8C0C

>>

>> --

>> Ladislav Lhotka, CZ.NIC Labs

>> PGP Key ID: E74E8C0C



--

Ladislav Lhotka, CZ.NIC Labs

PGP Key ID: E74E8C0C



_______________________________________________

netmod mailing list

netmod@ietf.org

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





--001a1136bfcef3ad3204fc828de8--


From nobody Mon Jun 23 11:16:50 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 619111B2BB7 for ; Mon, 23 Jun 2014 11:16:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.302
X-Spam-Level: 
X-Spam-Status: No, score=-1.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RP_MATCHES_RCVD=-0.651] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1gd4GDGyl63B for ; Mon, 23 Jun 2014 11:16:44 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 068B01B2BE5 for ; Mon, 23 Jun 2014 11:16:10 -0700 (PDT)
Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id C4C9A13FCDE; Mon, 23 Jun 2014 20:16:06 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1403547367; bh=6QtOjMJG0qrjR3lOqL1QsNJKsiApcYcrQHJCalY1tSs=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=thm2g++MjBIUVtEwJNSrGHEM+7qITidIp/xp1DZsVyCkj3ge8dYHAoFmuisn32SNV 8Rg1CxLPQPgAeEIja+jGxXltvcP+naKkSjPMqvJsPpXpj4ITJ6F6wzBJ4Bf7g2rZ24 QSTt2z7qyfxAZjZdE7kMPKYW+QRqtXk4drk4lsT4=
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
From: Ladislav Lhotka 
In-Reply-To: 
Date: Mon, 23 Jun 2014 20:16:03 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <45F6E463-82A0-4EF0-9EF7-E4B9D4EE7F80@nic.cz>
References:   <18cd777ffb9d4df6b0966dd1b3dd822b@BY2PR05MB079.namprd05.prod.outlook.com>    
To: Alia Atlas 
X-Mailer: Apple Mail (2.1878.2)
X-Virus-Scanned: clamav-milter 0.98.1 at mail
X-Virus-Status: Clean
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/fHZvMMWAesg2RRSeZ1L5-30cMuk
Cc: "Jeffrey \(Zhaohui\) Zhang" , Kiran Agrahara Sreenivasa , "netmod@ietf.org" 
Subject: Re: [netmod] Questions/comments on draft-ietf-netmod-routing-cfg
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 23 Jun 2014 18:16:47 -0000

Hi Alia,

On 23 Jun 2014, at 17:32, Alia Atlas  wrote:

> Lada,
>=20
> On Mon, Jun 23, 2014 at 10:38 AM, Ladislav Lhotka  =
wrote:
> "Jeffrey (Zhaohui) Zhang"  writes:
>=20
> > Lada,
> >
> > The discussions basically boil down to two main points:
> >
> > - I believe the spec should have well defined semantics for some =
well-known types of "routing-instances". Otherwise it is too loose to be =
the foundation for future work (e.g. the on-going OSPF YANG model work). =
That does not prevent the flexibility for future extensions.
>=20
> The OSPF (and more recent ISIS) module can work just fine with =
"standard-routing-instance". On smaller router platforms (OpenWRT with =
Quagga or BIRD daemons) this is all that's needed. I don't know why =
specific routing instance types couldn't be defined in separate modules.
>=20
>=20
> Supporting very common features (L3VPNs, logical routers, multiple =
routing instances) can
> make routers significantly more complex than Quagga supports.  While =
Quagga certainly has some useful features, I do not think it has kept =
pace.  What is needed for routing is more.

Right, but it doesn=92t mean this more has to be implemented by the core =
routing model. I think the important point is that such extensions are =
possible to do in other modules, and I am convinced it is the case.


> =20
> >
> > - I think the spec is too restrictive in saying "Each routing =
protocol instance is connected to exactly one RIB for each address =
family that the routing protocol instance supports". We can mix AF and =
SAF together and simply say Address Family (if we make it clear) but =
with the consideration of MT the statement is just not correct.
>=20
> There are currently three possible solutions:
>=20
> 1. Subdivide each address family via identity derivation, e.g. with =
respect to type of service.
>=20
> 2. Distribute routes from the connected RIB selectively to any number =
other RIBs via "recipient-rib" mechanism.
>=20
> 3. Augment the "routing-protocol" subtrees with new parameters. For =
example, one could introduce protocol "sub-instances", one for each =
topology, and then different sub-instances could use the same address =
family (this is by the way another advantage of having a flat list of =
routing protocol instances).
>=20
> In my view, this choice should be sufficient.
>=20
>=20
> >
> > I am more concerned with the first point.
> >
> > I don't think this is too late. There is still IETF last call and I =
am posting my comments here. If there is enough consensus to my points, =
then necessary changes need to happen. If not, I'll accept that.
>=20
> The routing-cfg document is already long overdue. We've already had =
several rounds of relatively significant redesigns based on reviewers' =
comments, and I think now it's time to deliver the result. The data =
model may not be perfect and I am open to returning to it after we gain =
some experience, but IMO we first need to fill the gaps by developing =
modules for routing protocols, route filters and, of course, specific =
types of routing instances.
>=20
> Jeffrey is coming in, trying to work on an OSPF YANG model, as a =
routing person very familiar with one implementation.  If this draft is =
not a sufficient base on which to build the other routing models, how =
should we proceed?  I have requested yet another routing directorate =
review on this draft; I'd expect that review before the upcoming IETF.

Yes, it is really challenging to combine YANG expertise (as YANG is a =
relatively new data modelling language) with domain-specific know-how. =
FWIW, I wrote an OSPF module for the BIRD daemon that perhaps may be =
used for comparison:

=
https://gitlab.labs.nic.cz/labs/yang-tools/blob/master/data-models/bird/bi=
rd-ospf.yang

Lada

>=20
> I can appreciate the frustration in the time it is taking to get this =
draft done.  Cross-area review does frequently happen after WGLC.
>=20
> Alia
>=20
> Lada
>=20
> >
> > Thanks.
> > Jeffrey
> >
> >> -----Original Message-----
> >> From: Ladislav Lhotka [mailto:lhotka@nic.cz]
> >> Sent: Monday, June 23, 2014 4:26 AM
> >> To: Jeffrey (Zhaohui) Zhang; Dean Bogdanovic; netmod@ietf.org
> >> Cc: Derek Man-Kit Yeung (myeung); Kiran Agrahara Sreenivasa
> >> Subject: RE: Questions/comments on draft-ietf-netmod-routing-cfg
> >>
> >> "Jeffrey (Zhaohui) Zhang"  writes:
> >>
> >> > Lada,
> >> >
> >> >> -----Original Message-----
> >> >> From: Ladislav Lhotka [mailto:lhotka@nic.cz]
> >> >> Sent: Friday, June 20, 2014 7:26 AM
> >> >> To: Jeffrey (Zhaohui) Zhang; Dean Bogdanovic; netmod@ietf.org
> >> >> Cc: Derek Man-Kit Yeung (myeung); Kiran Agrahara Sreenivasa
> >> >> Subject: Re: Questions/comments on draft-ietf-netmod-routing-cfg
> >> >>
> >> >> "Jeffrey (Zhaohui) Zhang"  writes:
> >> >>
> >> >> > Ladislav,
> >> >> >
> >> >> > Dean and I have some late questions and comments. We came =
across
> >> these
> >> >> while trying to work on the OSPF YANG model.
> >> >> >
> >> >> > -----------
> >> >> >
> >> >> > The spec mentions in several places something like the =
following:
> >> >> >
> >> >> >    Each routing protocol instance is connected to exactly one =
RIB
> >> for
> >> >> >    each address family that the routing protocol instance =
supports.
> >> >> >
> >> >> > My understanding is that the address family mentioned above =
does
> >> not
> >> >> include SAFI. Because of that, a routing protocol like BGP may
> >> connect
> >> >> to multiple RIBs in the same family (RIB for unicast and RIB for
> >> >> multicast RPF purpose in case of incongruent multicast topology) =
so
> >> the
> >> >> above statement is not correct.
> >> >>
> >> >> This is quite flexible since address family is defined via =
identities.
> >> I
> >> >> can imagine one implementation using only "ipv4" and "ipv6" =
(defined
> >> in
> >> >> ietf-routing) whilst other implementation could use =
"ipv[46]-unicast"
> >> >> (defined in ietf-ipv[46]-unicast-routing) and =
"ipv[46]-multicast" (to
> >> be
> >> >> defined in a module for unicast routing), that means including =
SAFI.
> >> >
> >> > Address Family has very specific meanings, typically only refer =
to
> >> IPv4/IPv6 to my understanding. If we want to extend that to include =
SAFI,
> >> then the spec must point it out. More below related to MT.
> >>
> >> Both Cisco and Juniper docs use terms like "IPv6 multicast address
> >> family" or "MCAST-VPN address family" that clearly include SAFI as =
well.
> >>
> >> For better or worse, in the ietf-routing YANG module =
"address-family"
> >> leaf is defined with the type
> >>
> >>          type identityref {
> >>            base address-family;
> >>          }
> >>
> >> so its meaning follows from that, including the fact that the =
identity
> >> is extensible. In my view, it is a feature, not bug.
> >>
> >> >
> >> >>
> >> >> >
> >> >> > This is also a problem in case of Multi-topology. Each =
topology has
> >> >> its own RIB and a protocol instance like OSPF can connect to =
multiple
> >> MT
> >> >> RIBs.
> >> >>
> >> >> Two possible solutions come to my mind:
> >> >>
> >> >> 1. You could derive new address family identities from =
"ipv4-unicast"
> >> >> etc. so that you can assign a unique address family to multiple
> >> tables.
> >> >>
> >> >> 2. You could have one connected RIB e.g. for "ipv4-unicast" and
> >> define
> >> >> two or more RIBs for each topology as recipients of the =
connected RIB.
> >> >> So, in effect, the (single) connected RIB contains routes for =
all
> >> >> topologies and these are then split via route filters to the =
per-
> >> >> topology RIBs.
> >> >>
> >> >> Does it make sense?
> >> >
> >> > Compare the two, I don't like #2 because it adds an unnecessary
> >> indirection. I don't think we want to overload "Address Family" =
further
> >> to include topology either. In many implementations, actual RIBs =
are per
> >> (routing-instance, AFI, SAFI, topology) and it may be extended =
further.
> >> Therefore, the best option is to simply remove the restriction that =
one
> >> protocol instance is connected to exactly one RIB per address =
family.
> >>
> >> This restriction is only relevant for the "connected-rib" list. If =
you
> >> want, you can add configuration parameters to associate other RIBs
> >> directly with a routing protocol instance.
> >>
> >> IMO, the common use case for MT are incongruent IPv4 and IPv6 =
topologies,
> >> and the core routing data model can handle this directly and =
easily.
> >>
> >> Also note that the "routing-cfg" document has already been =
submitted to
> >> IESG for publication, so your comments come really late.
> >>
> >> >
> >> >>
> >> >> >
> >> >> > ------
> >> >> >
> >> >> > 5.1.  Routing Instance
> >> >> >
> >> >> >    Each routing instance in the core routing data model =
represents
> >> a
> >> >> >    logical router.  The exact semantics of this term are left =
to
> >> >> >    implementations.  For example, routing instances may be
> >> completely
> >> >> >    isolated virtual routers or, alternatively, they may =
internally
> >> share
> >> >> >    certain information.
> >> >> >
> >> >> >    ...
> >> >> >
> >> >> >    An implementation MAY support multiple types of logical =
routers
> >> >> >    simultaneously.  Instances of all routing instance types =
are
> >> >> >    organized as entries of the same flat "routing-instance" =
list.
> >> In
> >> >> >    order to discriminate routing instances belonging to =
different
> >> types,
> >> >> >    the "type" leaf is defined as a child of the =
"routing-instance"
> >> node.
> >> >> >
> >> >> > The spec purposely left it fuzzy as to what a "routing =
instance" is.
> >> >> However we definitely should have clear definitions for the =
three
> >> terms
> >> >> mentioned: routing-instance, logical router and virtual router.
> >> >>
> >> >> Yes, this is by design open-ended because otherwise we would =
probably
> >> >> never reach consensus on what these terms exactly mean.
> >> >
> >> > While the design needs to be open-ended a standard specification =
needs
> >> to be precise and unambiguous. The names can be discussed and
> >> compromised but the meaning must be clear. For example, Cisco =
"virtual
> >> router" and Juniper "logical router/system" are the same but =
Juniper
> >> "virtual router" and Cisco "VRF-lite" are the same. What does the
> >> "logical router" in this spec mean? We can't just say that "it can =
mean
> >> any of those". For example if it means Cisco's "virtual router" or
> >> Juniper's "logical system", a further discussion may be - should =
this
> >> module really cover that.
> >>
> >> The term "logical router" is used in a very general sense, and the
> >> document clearly says so ("no semantics"). The other terms are used =
only
> >> as examples what it could possibly mean, to make the spec more
> >> accessible.
> >>
> >> >
> >> >>
> >> >> >
> >> >> > Logical router is a very overload term. Today vendors have
> >> virtualized
> >> >> their routing capabilities in the system and provide 3 different
> >> levels
> >> >> of routing virtualization. Logical systems, logical routers are =
some
> >> of
> >> >> the names used by vendors and those offer routing and management
> >> >> separation. Each logical system has its own routing instances =
and
> >> >> routing instances can have multiple routing tables, so it is =
very
> >> >> important to have very precise definition of what is routing =
instance
> >> >> (and not compare it with logical router)
> >> >> >
> >> >> >      identity standard-routing-instance {
> >> >> >        base routing-instance-type;
> >> >> >        description
> >> >> >          "This identity represents a default routing =
instance.";
> >> >> >      }
> >> >> >
> >> >> > What is a "standard-routing-instance"? Would "default-routing-
> >> >> instance" be better? "standard" wording leads to "standard vs. =
non-
> >> >> standard" question and hints on that the two are different =
types.
> >> >> "default" vs. "non-default" does not have that (at least to me).
> >> >>
> >> >> Well, "default" is overloaded, too, and also has a specific =
meaning
> >> in
> >> >> YANG. Standard is supposed to mean plain vanilla router. It is =
just a
> >> >> name.
> >> >
> >> > I don't have to split hair between "standard" and "default" but =
the
> >> spec must point out what a "standard-routing-instance" is - is it =
the
> >> default/base/master logical-system (Cisco virtual-router) or the
> >> default/base/master "routing-instance" (a "logical-system" would =
include
> >> many "routing-instances" like VRFs).
> >> >
> >>
> >> I think the ietf-routing module makes it pretty clear:
> >>
> >>          leaf type {
> >>            type identityref {
> >>              base routing-instance-type;
> >>            }
> >>            default "rt:standard-routing-instance";
> >>            description
> >>              "The type of the routing instance.";
> >>          }
> >>
> >> The purpose of the "type" is to allow for defining a new routing
> >> instance type and augment configuration or state data conditionally =
for
> >> that type. The "standard-routing-instance" is just the default =
value to
> >> start from, it has no other meaning.
> >>
> >>
> >> >>
> >> >> >
> >> >> > Should this spec distinguish VRF/VR/LR and have corresponding
> >> >> identities defined?
> >> >>
> >> >> The idea is this will be done in other modules that define data
> >> models
> >> >> for these types of routing instances. Then the =
"routing-instance"
> >> >> container can be augmented with arbitrary data, but =
conditionally for
> >> >> that routing instance type.
> >> >
> >> > I think it is important to define a few well known routing =
instance
> >> types in the base spec as a good foundation for other modules.
> >>
> >> This is outside the scope of the core routing data model, and =
should be
> >> done by routing experts, not in the NETMOD group. There are other
> >> indispensable elements that have to be worked out before the =
routing
> >> data model can be really useful, e.g. routing protocols and route
> >> filters.
> >>
> >> >
> >> >>
> >> >> An implementation may actually use multiple routing-instance =
types at
> >> >> the same time.
> >> >
> >> > That's for sure and not what I'm concerned with.
> >> >
> >> >>
> >> >> >
> >> >> >          leaf type {
> >> >> >            type identityref {
> >> >> >              base routing-instance-type;
> >> >> >            }
> >> >> >            description
> >> >> >              "The routing instance type, primarily intended =
for
> >> >> >               discriminating among different types of logical
> >> routers,
> >> >> >               route virtualization, master-slave arrangements =
etc.,
> >> >> >               while keeping all routing instances in the same =
flat
> >> >> >               list.";
> >> >> >          }
> >> >> >
> >> >> > What is the "master-slave arrangements"?
> >> >>
> >> >> This came from an early review by Thomas Morin, it has to do =
with
> >> >> MPLS/BGP VPNs where a master routing-instance exchanges selected
> >> routes
> >> >> with each VPN/VRF.
> >> >
> >> > Either it needs to be clarified in the spec, or it could simply =
be
> >> removed to avoid confusion since "route virtualization" covers that
> >> already.
> >>
> >> This is actually a typo - it should be "router virtualization". My
> >> understanding of this term is that a virtual router is isolated and
> >> exchanges routing information with other routers only through =
routing
> >> protocols.
> >>
> >> Anyway, these are really only examples and I think it is =
sufficiently
> >> clear that the core routing data model doesn't use these terms for
> >> defining any semantics.
> >>
> >> Lada
> >>
> >> >
> >> >>
> >> >> >
> >> >> > Depending on the definition of "logical router" and "route
> >> >> virtualization", there may also be concerns with keeping all =
those
> >> kinds
> >> >> of in the same flat list.
> >> >>
> >> >> It is similar to interfaces, where physical and logical =
interfaces of
> >> >> all kinds live in the same flat list and are distinguished by =
the
> >> type.
> >> >> I think it could work, relationships among the individual =
routing
> >> >> instances can be expressed in other data.
> >> >
> >> > I will defer to others about the merits of a flat list, but for a =
flat
> >> list, the base spec needs to provide a way to express the =
relationship.
> >> >
> >> > Jeffrey
> >> >
> >> >>
> >> >> Having a single flat list has its advantages, for example you =
can
> >> then
> >> >> easily refer to routing instances via leafrefs (which allow only =
one
> >> >> path).
> >> >>
> >> >> Cheers, Lada
> >> >>
> >> >> >
> >> >> > Jeffrey Zhang
> >> >> > Dean Bogdanovic
> >> >>
> >> >> --
> >> >> Ladislav Lhotka, CZ.NIC Labs
> >> >> PGP Key ID: E74E8C0C
> >>
> >> --
> >> Ladislav Lhotka, CZ.NIC Labs
> >> PGP Key ID: E74E8C0C
>=20
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>=20
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>=20

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





From nobody Mon Jun 23 11:43:34 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7C5B1B28C7 for ; Mon, 23 Jun 2014 11:43:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.302
X-Spam-Level: 
X-Spam-Status: No, score=-1.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RP_MATCHES_RCVD=-0.651] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q_bo4HYz3n1l for ; Mon, 23 Jun 2014 11:43:26 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC2C61B2C0F for ; Mon, 23 Jun 2014 11:43:13 -0700 (PDT)
Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id DE0041400FA; Mon, 23 Jun 2014 20:43:11 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1403548992; bh=uc0tj0JGRBQdhOdlACOJ3ngpGGa3lh19+8fdzrCriG4=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=OQpsWt5sXuw0RXQ9P0yMD4yX2Tpfunv7aKBGB39wuLVGPQDXWhxTZG8JDxRarlXKs 7czP2GSZYpcn256skzzYHJQfR3qTSthoHHWsONd1kJSVxY2EsnMGzN0VO3sBo0QzZC 7U7OzqY61o0V7u/l2E7bDVxNESHNngW75LeNV1kw=
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
From: Ladislav Lhotka 
In-Reply-To: 
Date: Mon, 23 Jun 2014 20:43:11 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:   <18cd777ffb9d4df6b0966dd1b3dd822b@BY2PR05MB079.namprd05.prod.outlook.com>   
To: Dean Bogdanovic 
X-Mailer: Apple Mail (2.1878.2)
X-Virus-Scanned: clamav-milter 0.98.1 at mail
X-Virus-Status: Clean
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/1Nj9U6clMNh9nOSA4u4xVg4l0Sc
Cc: "Jeffrey \(Zhaohui\) Zhang" , Kiran Agrahara Sreenivasa , "netmod@ietf.org" 
Subject: Re: [netmod] Questions/comments on draft-ietf-netmod-routing-cfg
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 23 Jun 2014 18:43:29 -0000

On 23 Jun 2014, at 16:42, Dean Bogdanovic  wrote:

> Lada,
>=20
> Semantics has to be precise, otherwise it can be very differently =
reinterpreted and then standards becomes not useful.
>=20
> My take on this is we need a two abstractions
> 1. routing table - which is a container of routes

This is called RIB in the ietf-routing module, after the terminology has =
been harmonized with the I2RS RIB info model.

> and
> 2. container of routing tables - this container has to have a precise =
name

I am not sure I understand - in the ietf-routing module, this container =
does have a precise name: =93ribs=94, i.e., every routing instance can =
use multiple RIBs.

>=20
> If the 2. container name is not well specified and IMO, it is not in =
your draft, it will be hard to use your draft as foundation. Right now =
your definition allows free definition of container of routing tables =
and container of containers of routing tables. We don't need a =
definition of container of containers of routing tables. If we can come =
to agreement for the above two, that would be great.

But routing instances are (among other things) exactly these containers =
of containers of RIBs, but IMO the various types of routing instances so =
far have been pretty much vendor-specific, even though there are some de =
facto standards. It would be great if these thing are standardised in =
the IETF, and corresponding YANG modules written.

> =20
>=20
> The document is with IESG, but there is still possibility to bring =
DISCUSS and COMMENT items
> http://tools.ietf.org/html/rfc4858#section-3.3

It sure is.

Lada

>=20
>=20
> On Jun 23, 2014, at 8:59 AM, Jeffrey (Zhaohui) Zhang =
 wrote:
>=20
>> Lada,
>>=20
>> The discussions basically boil down to two main points:
>>=20
>> - I believe the spec should have well defined semantics for some =
well-known types of "routing-instances". Otherwise it is too loose to be =
the foundation for future work (e.g. the on-going OSPF YANG model work). =
That does not prevent the flexibility for future extensions.
>=20
> I agree with this one very strongly.=20
>>=20
>> - I think the spec is too restrictive in saying "Each routing =
protocol instance is connected to exactly one RIB for each address =
family that the routing protocol instance supports". We can mix AF and =
SAF together and simply say Address Family (if we make it clear) but =
with the consideration of MT the statement is just not correct.
>>=20
>> I am more concerned with the first point.
>>=20
>> I don't think this is too late. There is still IETF last call and I =
am posting my comments here. If there is enough consensus to my points, =
then necessary changes need to happen. If not, I'll accept that.
>>=20
>> Thanks.
>> Jeffrey
>>=20
>>> -----Original Message-----
>>> From: Ladislav Lhotka [mailto:lhotka@nic.cz]
>>> Sent: Monday, June 23, 2014 4:26 AM
>>> To: Jeffrey (Zhaohui) Zhang; Dean Bogdanovic; netmod@ietf.org
>>> Cc: Derek Man-Kit Yeung (myeung); Kiran Agrahara Sreenivasa
>>> Subject: RE: Questions/comments on draft-ietf-netmod-routing-cfg
>>>=20
>>> "Jeffrey (Zhaohui) Zhang"  writes:
>>>=20
>>>> Lada,
>>>>=20
>>>>> -----Original Message-----
>>>>> From: Ladislav Lhotka [mailto:lhotka@nic.cz]
>>>>> Sent: Friday, June 20, 2014 7:26 AM
>>>>> To: Jeffrey (Zhaohui) Zhang; Dean Bogdanovic; netmod@ietf.org
>>>>> Cc: Derek Man-Kit Yeung (myeung); Kiran Agrahara Sreenivasa
>>>>> Subject: Re: Questions/comments on draft-ietf-netmod-routing-cfg
>>>>>=20
>>>>> "Jeffrey (Zhaohui) Zhang"  writes:
>>>>>=20
>>>>>> Ladislav,
>>>>>>=20
>>>>>> Dean and I have some late questions and comments. We came across
>>> these
>>>>> while trying to work on the OSPF YANG model.
>>>>>>=20
>>>>>> -----------
>>>>>>=20
>>>>>> The spec mentions in several places something like the following:
>>>>>>=20
>>>>>>    Each routing protocol instance is connected to exactly one RIB
>>> for
>>>>>>    each address family that the routing protocol instance =
supports.
>>>>>>=20
>>>>>> My understanding is that the address family mentioned above does
>>> not
>>>>> include SAFI. Because of that, a routing protocol like BGP may
>>> connect
>>>>> to multiple RIBs in the same family (RIB for unicast and RIB for
>>>>> multicast RPF purpose in case of incongruent multicast topology) =
so
>>> the
>>>>> above statement is not correct.
>>>>>=20
>>>>> This is quite flexible since address family is defined via =
identities.
>>> I
>>>>> can imagine one implementation using only "ipv4" and "ipv6" =
(defined
>>> in
>>>>> ietf-routing) whilst other implementation could use =
"ipv[46]-unicast"
>>>>> (defined in ietf-ipv[46]-unicast-routing) and "ipv[46]-multicast" =
(to
>>> be
>>>>> defined in a module for unicast routing), that means including =
SAFI.
>>>>=20
>>>> Address Family has very specific meanings, typically only refer to
>>> IPv4/IPv6 to my understanding. If we want to extend that to include =
SAFI,
>>> then the spec must point it out. More below related to MT.
>>>=20
>>> Both Cisco and Juniper docs use terms like "IPv6 multicast address
>>> family" or "MCAST-VPN address family" that clearly include SAFI as =
well.
>>>=20
>>> For better or worse, in the ietf-routing YANG module =
"address-family"
>>> leaf is defined with the type
>>>=20
>>>         type identityref {
>>>           base address-family;
>>>         }
>>>=20
>>> so its meaning follows from that, including the fact that the =
identity
>>> is extensible. In my view, it is a feature, not bug.
>>>=20
>>>>=20
>>>>>=20
>>>>>>=20
>>>>>> This is also a problem in case of Multi-topology. Each topology =
has
>>>>> its own RIB and a protocol instance like OSPF can connect to =
multiple
>>> MT
>>>>> RIBs.
>>>>>=20
>>>>> Two possible solutions come to my mind:
>>>>>=20
>>>>> 1. You could derive new address family identities from =
"ipv4-unicast"
>>>>> etc. so that you can assign a unique address family to multiple
>>> tables.
>>>>>=20
>>>>> 2. You could have one connected RIB e.g. for "ipv4-unicast" and
>>> define
>>>>> two or more RIBs for each topology as recipients of the connected =
RIB.
>>>>> So, in effect, the (single) connected RIB contains routes for all
>>>>> topologies and these are then split via route filters to the per-
>>>>> topology RIBs.
>>>>>=20
>>>>> Does it make sense?
>>>>=20
>>>> Compare the two, I don't like #2 because it adds an unnecessary
>>> indirection. I don't think we want to overload "Address Family" =
further
>>> to include topology either. In many implementations, actual RIBs are =
per
>>> (routing-instance, AFI, SAFI, topology) and it may be extended =
further.
>>> Therefore, the best option is to simply remove the restriction that =
one
>>> protocol instance is connected to exactly one RIB per address =
family.
>>>=20
>>> This restriction is only relevant for the "connected-rib" list. If =
you
>>> want, you can add configuration parameters to associate other RIBs
>>> directly with a routing protocol instance.
>>>=20
>>> IMO, the common use case for MT are incongruent IPv4 and IPv6 =
topologies,
>>> and the core routing data model can handle this directly and easily.
>>>=20
>>> Also note that the "routing-cfg" document has already been submitted =
to
>>> IESG for publication, so your comments come really late.
>>>=20
>>>>=20
>>>>>=20
>>>>>>=20
>>>>>> ------
>>>>>>=20
>>>>>> 5.1.  Routing Instance
>>>>>>=20
>>>>>>   Each routing instance in the core routing data model represents
>>> a
>>>>>>   logical router.  The exact semantics of this term are left to
>>>>>>   implementations.  For example, routing instances may be
>>> completely
>>>>>>   isolated virtual routers or, alternatively, they may internally
>>> share
>>>>>>   certain information.
>>>>>>=20
>>>>>>   ...
>>>>>>=20
>>>>>>   An implementation MAY support multiple types of logical routers
>>>>>>   simultaneously.  Instances of all routing instance types are
>>>>>>   organized as entries of the same flat "routing-instance" list.
>>> In
>>>>>>   order to discriminate routing instances belonging to different
>>> types,
>>>>>>   the "type" leaf is defined as a child of the "routing-instance"
>>> node.
>>>>>>=20
>>>>>> The spec purposely left it fuzzy as to what a "routing instance" =
is.
>>>>> However we definitely should have clear definitions for the three
>>> terms
>>>>> mentioned: routing-instance, logical router and virtual router.
>>>>>=20
>>>>> Yes, this is by design open-ended because otherwise we would =
probably
>>>>> never reach consensus on what these terms exactly mean.
>>>>=20
>>>> While the design needs to be open-ended a standard specification =
needs
>>> to be precise and unambiguous. The names can be discussed and
>>> compromised but the meaning must be clear. For example, Cisco =
"virtual
>>> router" and Juniper "logical router/system" are the same but Juniper
>>> "virtual router" and Cisco "VRF-lite" are the same. What does the
>>> "logical router" in this spec mean? We can't just say that "it can =
mean
>>> any of those". For example if it means Cisco's "virtual router" or
>>> Juniper's "logical system", a further discussion may be - should =
this
>>> module really cover that.
>>>=20
>>> The term "logical router" is used in a very general sense, and the
>>> document clearly says so ("no semantics"). The other terms are used =
only
>>> as examples what it could possibly mean, to make the spec more
>>> accessible.
>>>=20
>>>>=20
>>>>>=20
>>>>>>=20
>>>>>> Logical router is a very overload term. Today vendors have
>>> virtualized
>>>>> their routing capabilities in the system and provide 3 different
>>> levels
>>>>> of routing virtualization. Logical systems, logical routers are =
some
>>> of
>>>>> the names used by vendors and those offer routing and management
>>>>> separation. Each logical system has its own routing instances and
>>>>> routing instances can have multiple routing tables, so it is very
>>>>> important to have very precise definition of what is routing =
instance
>>>>> (and not compare it with logical router)
>>>>>>=20
>>>>>>      identity standard-routing-instance {
>>>>>>        base routing-instance-type;
>>>>>>        description
>>>>>>          "This identity represents a default routing instance.";
>>>>>>      }
>>>>>>=20
>>>>>> What is a "standard-routing-instance"? Would "default-routing-
>>>>> instance" be better? "standard" wording leads to "standard vs. =
non-
>>>>> standard" question and hints on that the two are different types.
>>>>> "default" vs. "non-default" does not have that (at least to me).
>>>>>=20
>>>>> Well, "default" is overloaded, too, and also has a specific =
meaning
>>> in
>>>>> YANG. Standard is supposed to mean plain vanilla router. It is =
just a
>>>>> name.
>>>>=20
>>>> I don't have to split hair between "standard" and "default" but the
>>> spec must point out what a "standard-routing-instance" is - is it =
the
>>> default/base/master logical-system (Cisco virtual-router) or the
>>> default/base/master "routing-instance" (a "logical-system" would =
include
>>> many "routing-instances" like VRFs).
>>>>=20
>>>=20
>>> I think the ietf-routing module makes it pretty clear:
>>>=20
>>>         leaf type {
>>>           type identityref {
>>>             base routing-instance-type;
>>>           }
>>>           default "rt:standard-routing-instance";
>>>           description
>>>             "The type of the routing instance.";
>>>         }
>>>=20
>>> The purpose of the "type" is to allow for defining a new routing
>>> instance type and augment configuration or state data conditionally =
for
>>> that type. The "standard-routing-instance" is just the default value =
to
>>> start from, it has no other meaning.
>>>=20
>>>=20
>>>>>=20
>>>>>>=20
>>>>>> Should this spec distinguish VRF/VR/LR and have corresponding
>>>>> identities defined?
>>>>>=20
>>>>> The idea is this will be done in other modules that define data
>>> models
>>>>> for these types of routing instances. Then the "routing-instance"
>>>>> container can be augmented with arbitrary data, but conditionally =
for
>>>>> that routing instance type.
>>>>=20
>>>> I think it is important to define a few well known routing instance
>>> types in the base spec as a good foundation for other modules.
>>>=20
>>> This is outside the scope of the core routing data model, and should =
be
>>> done by routing experts, not in the NETMOD group. There are other
>>> indispensable elements that have to be worked out before the routing
>>> data model can be really useful, e.g. routing protocols and route
>>> filters.
>>>=20
>>>>=20
>>>>>=20
>>>>> An implementation may actually use multiple routing-instance types =
at
>>>>> the same time.
>>>>=20
>>>> That's for sure and not what I'm concerned with.
>>>>=20
>>>>>=20
>>>>>>=20
>>>>>>          leaf type {
>>>>>>            type identityref {
>>>>>>              base routing-instance-type;
>>>>>>            }
>>>>>>            description
>>>>>>              "The routing instance type, primarily intended for
>>>>>>               discriminating among different types of logical
>>> routers,
>>>>>>               route virtualization, master-slave arrangements =
etc.,
>>>>>>               while keeping all routing instances in the same =
flat
>>>>>>               list.";
>>>>>>          }
>>>>>>=20
>>>>>> What is the "master-slave arrangements"?
>>>>>=20
>>>>> This came from an early review by Thomas Morin, it has to do with
>>>>> MPLS/BGP VPNs where a master routing-instance exchanges selected
>>> routes
>>>>> with each VPN/VRF.
>>>>=20
>>>> Either it needs to be clarified in the spec, or it could simply be
>>> removed to avoid confusion since "route virtualization" covers that
>>> already.
>>>=20
>>> This is actually a typo - it should be "router virtualization". My
>>> understanding of this term is that a virtual router is isolated and
>>> exchanges routing information with other routers only through =
routing
>>> protocols.
>>>=20
>>> Anyway, these are really only examples and I think it is =
sufficiently
>>> clear that the core routing data model doesn't use these terms for
>>> defining any semantics.
>>>=20
>>> Lada
>>>=20
>>>>=20
>>>>>=20
>>>>>>=20
>>>>>> Depending on the definition of "logical router" and "route
>>>>> virtualization", there may also be concerns with keeping all those
>>> kinds
>>>>> of in the same flat list.
>>>>>=20
>>>>> It is similar to interfaces, where physical and logical interfaces =
of
>>>>> all kinds live in the same flat list and are distinguished by the
>>> type.
>>>>> I think it could work, relationships among the individual routing
>>>>> instances can be expressed in other data.
>>>>=20
>>>> I will defer to others about the merits of a flat list, but for a =
flat
>>> list, the base spec needs to provide a way to express the =
relationship.
>>>>=20
>>>> Jeffrey
>>>>=20
>>>>>=20
>>>>> Having a single flat list has its advantages, for example you can
>>> then
>>>>> easily refer to routing instances via leafrefs (which allow only =
one
>>>>> path).
>>>>>=20
>>>>> Cheers, Lada
>>>>>=20
>>>>>>=20
>>>>>> Jeffrey Zhang
>>>>>> Dean Bogdanovic
>>>>>=20
>>>>> --
>>>>> Ladislav Lhotka, CZ.NIC Labs
>>>>> PGP Key ID: E74E8C0C
>>>=20
>>> --
>>> Ladislav Lhotka, CZ.NIC Labs
>>> PGP Key ID: E74E8C0C
>=20

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





From nobody Mon Jun 23 12:03:06 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16ACC1B2C40 for ; Mon, 23 Jun 2014 12:03:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HVo_3JF6ki_5 for ; Mon, 23 Jun 2014 12:02:58 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0185.outbound.protection.outlook.com [207.46.163.185]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3DA51B2C08 for ; Mon, 23 Jun 2014 11:59:06 -0700 (PDT)
Received: from BY2PR05MB079.namprd05.prod.outlook.com (10.242.38.16) by DM2PR05MB432.namprd05.prod.outlook.com (10.141.104.11) with Microsoft SMTP Server (TLS) id 15.0.969.15; Mon, 23 Jun 2014 18:59:04 +0000
Received: from BY2PR05MB079.namprd05.prod.outlook.com ([169.254.8.228]) by BY2PR05MB079.namprd05.prod.outlook.com ([169.254.8.228]) with mapi id 15.00.0969.007; Mon, 23 Jun 2014 18:59:03 +0000
From: "Jeffrey (Zhaohui) Zhang" 
To: Ladislav Lhotka , Alia Atlas 
Thread-Topic: [netmod] Questions/comments on draft-ietf-netmod-routing-cfg
Thread-Index: Ac+L5mG6QCip6E9wRnWAlQy1vx1YdgAlBfOAAACoQiAAj+tmAAAIpPrQAAReeoAAAeKmAAAFtCqAAAALMUA=
Date: Mon, 23 Jun 2014 18:59:01 +0000
Message-ID: 
References:   <18cd777ffb9d4df6b0966dd1b3dd822b@BY2PR05MB079.namprd05.prod.outlook.com>     <45F6E463-82A0-4EF0-9EF7-E4B9D4EE7F80@nic.cz>
In-Reply-To: <45F6E463-82A0-4EF0-9EF7-E4B9D4EE7F80@nic.cz>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [66.129.241.13]
x-microsoft-antispam: BCL:0;PCL:0;RULEID:
x-forefront-prvs: 025100C802
x-forefront-antispam-report: SFV:NSPM; SFS:(979002)(6009001)(428001)(52314003)(189002)(24454002)(51704005)(52034003)(199002)(13464003)(25584003)(377454003)(76482001)(76576001)(50986999)(19580405001)(83322001)(74502001)(81542001)(46102001)(15975445006)(54356999)(19580395003)(85306003)(93886003)(79102001)(77982001)(81342001)(77096002)(31966008)(74662001)(575784001)(86362001)(64706001)(4396001)(20776003)(106356001)(105586002)(2656002)(85852003)(101416001)(66066001)(83072002)(74316001)(76176999)(33646001)(99286002)(21056001)(95666004)(99396002)(80022001)(87936001)(92566001)(24736002)(106276001)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:; SCL:1; SRVR:DM2PR05MB432; H:BY2PR05MB079.namprd05.prod.outlook.com; FPR:; MLV:ovrnspm; PTR:InfoNoRecords; MX:1; A:1; LANG:en; 
received-spf: None (: juniper.net does not designate permitted sender hosts)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=zzhang@juniper.net; 
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/fU5mDK619-V2EKcXzIzqNgGVFMM
Cc: Kiran Agrahara Sreenivasa , "netmod@ietf.org" 
Subject: Re: [netmod] Questions/comments on draft-ietf-netmod-routing-cfg
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 23 Jun 2014 19:03:04 -0000

Lada,

> Right, but it doesn't mean this more has to be implemented by the core
> routing model. I think the important point is that such extensions are
> possible to do in other modules, and I am convinced it is the case

While we are trying to work on the OSPF YANG module, which is to base on ne=
tmod-routing-cfg, some interpret the "routing-instance" in netmod-routing-c=
fg as Juniper's "Logical Router/System" (i.e. Cisco's "Virtual Router"), wh=
ile some others interpret that as Juniper's VRF/VR (i.e., Cisco's VRF/VRF-l=
ite). That difference has a major impact on how OSPF YANG module is defined=
.

If netmod-routing-cfg is to allow both the above, it is critical for netmod=
-routing-cfg to be clear what the terms "logical router" and "virtual route=
r" mean, and then OSPF YANG module will proceed accordingly. It does not ma=
ke sense to defer that to another document.

There are even people who argue that it is not good to put the above two ty=
pes of routing instances into the same flat list. That's a separate topic a=
nd I am not trying to open up that discussion here, but it shows how import=
ant it is for the netmod-routing-cfg to be clear what a "routing-instances"=
 is instead of deferring to another document.

Jeffrey

> -----Original Message-----
> From: Ladislav Lhotka [mailto:lhotka@nic.cz]
> Sent: Monday, June 23, 2014 2:16 PM
> To: Alia Atlas
> Cc: Jeffrey (Zhaohui) Zhang; Dean Bogdanovic; netmod@ietf.org; Kiran
> Agrahara Sreenivasa
> Subject: Re: [netmod] Questions/comments on draft-ietf-netmod-routing-
> cfg
>=20
> Hi Alia,
>=20
> On 23 Jun 2014, at 17:32, Alia Atlas  wrote:
>=20
> > Lada,
> >
> > On Mon, Jun 23, 2014 at 10:38 AM, Ladislav Lhotka 
> wrote:
> > "Jeffrey (Zhaohui) Zhang"  writes:
> >
> > > Lada,
> > >
> > > The discussions basically boil down to two main points:
> > >
> > > - I believe the spec should have well defined semantics for some
> well-known types of "routing-instances". Otherwise it is too loose to be
> the foundation for future work (e.g. the on-going OSPF YANG model work).
> That does not prevent the flexibility for future extensions.
> >
> > The OSPF (and more recent ISIS) module can work just fine with
> "standard-routing-instance". On smaller router platforms (OpenWRT with
> Quagga or BIRD daemons) this is all that's needed. I don't know why
> specific routing instance types couldn't be defined in separate modules.
> >
> >
> > Supporting very common features (L3VPNs, logical routers, multiple
> routing instances) can
> > make routers significantly more complex than Quagga supports.  While
> Quagga certainly has some useful features, I do not think it has kept
> pace.  What is needed for routing is more.
>=20
> Right, but it doesn't mean this more has to be implemented by the core
> routing model. I think the important point is that such extensions are
> possible to do in other modules, and I am convinced it is the case.
>=20
>=20
> >
> > >
> > > - I think the spec is too restrictive in saying "Each routing
> protocol instance is connected to exactly one RIB for each address
> family that the routing protocol instance supports". We can mix AF and
> SAF together and simply say Address Family (if we make it clear) but
> with the consideration of MT the statement is just not correct.
> >
> > There are currently three possible solutions:
> >
> > 1. Subdivide each address family via identity derivation, e.g. with
> respect to type of service.
> >
> > 2. Distribute routes from the connected RIB selectively to any number
> other RIBs via "recipient-rib" mechanism.
> >
> > 3. Augment the "routing-protocol" subtrees with new parameters. For
> example, one could introduce protocol "sub-instances", one for each
> topology, and then different sub-instances could use the same address
> family (this is by the way another advantage of having a flat list of
> routing protocol instances).
> >
> > In my view, this choice should be sufficient.
> >
> >
> > >
> > > I am more concerned with the first point.
> > >
> > > I don't think this is too late. There is still IETF last call and I
> am posting my comments here. If there is enough consensus to my points,
> then necessary changes need to happen. If not, I'll accept that.
> >
> > The routing-cfg document is already long overdue. We've already had
> several rounds of relatively significant redesigns based on reviewers'
> comments, and I think now it's time to deliver the result. The data
> model may not be perfect and I am open to returning to it after we gain
> some experience, but IMO we first need to fill the gaps by developing
> modules for routing protocols, route filters and, of course, specific
> types of routing instances.
> >
> > Jeffrey is coming in, trying to work on an OSPF YANG model, as a
> routing person very familiar with one implementation.  If this draft is
> not a sufficient base on which to build the other routing models, how
> should we proceed?  I have requested yet another routing directorate
> review on this draft; I'd expect that review before the upcoming IETF.
>=20
> Yes, it is really challenging to combine YANG expertise (as YANG is a
> relatively new data modelling language) with domain-specific know-how.
> FWIW, I wrote an OSPF module for the BIRD daemon that perhaps may be
> used for comparison:
>=20
> https://gitlab.labs.nic.cz/labs/yang-tools/blob/master/data-
> models/bird/bird-ospf.yang
>=20
> Lada
>=20
> >
> > I can appreciate the frustration in the time it is taking to get this
> draft done.  Cross-area review does frequently happen after WGLC.
> >
> > Alia
> >
> > Lada
> >
> > >
> > > Thanks.
> > > Jeffrey
> > >
> > >> -----Original Message-----
> > >> From: Ladislav Lhotka [mailto:lhotka@nic.cz]
> > >> Sent: Monday, June 23, 2014 4:26 AM
> > >> To: Jeffrey (Zhaohui) Zhang; Dean Bogdanovic; netmod@ietf.org
> > >> Cc: Derek Man-Kit Yeung (myeung); Kiran Agrahara Sreenivasa
> > >> Subject: RE: Questions/comments on draft-ietf-netmod-routing-cfg
> > >>
> > >> "Jeffrey (Zhaohui) Zhang"  writes:
> > >>
> > >> > Lada,
> > >> >
> > >> >> -----Original Message-----
> > >> >> From: Ladislav Lhotka [mailto:lhotka@nic.cz]
> > >> >> Sent: Friday, June 20, 2014 7:26 AM
> > >> >> To: Jeffrey (Zhaohui) Zhang; Dean Bogdanovic; netmod@ietf.org
> > >> >> Cc: Derek Man-Kit Yeung (myeung); Kiran Agrahara Sreenivasa
> > >> >> Subject: Re: Questions/comments on draft-ietf-netmod-routing-cfg
> > >> >>
> > >> >> "Jeffrey (Zhaohui) Zhang"  writes:
> > >> >>
> > >> >> > Ladislav,
> > >> >> >
> > >> >> > Dean and I have some late questions and comments. We came
> across
> > >> these
> > >> >> while trying to work on the OSPF YANG model.
> > >> >> >
> > >> >> > -----------
> > >> >> >
> > >> >> > The spec mentions in several places something like the
> following:
> > >> >> >
> > >> >> >    Each routing protocol instance is connected to exactly one
> RIB
> > >> for
> > >> >> >    each address family that the routing protocol instance
> supports.
> > >> >> >
> > >> >> > My understanding is that the address family mentioned above
> does
> > >> not
> > >> >> include SAFI. Because of that, a routing protocol like BGP may
> > >> connect
> > >> >> to multiple RIBs in the same family (RIB for unicast and RIB for
> > >> >> multicast RPF purpose in case of incongruent multicast topology)
> so
> > >> the
> > >> >> above statement is not correct.
> > >> >>
> > >> >> This is quite flexible since address family is defined via
> identities.
> > >> I
> > >> >> can imagine one implementation using only "ipv4" and "ipv6"
> (defined
> > >> in
> > >> >> ietf-routing) whilst other implementation could use "ipv[46]-
> unicast"
> > >> >> (defined in ietf-ipv[46]-unicast-routing) and "ipv[46]-
> multicast" (to
> > >> be
> > >> >> defined in a module for unicast routing), that means including
> SAFI.
> > >> >
> > >> > Address Family has very specific meanings, typically only refer
> to
> > >> IPv4/IPv6 to my understanding. If we want to extend that to include
> SAFI,
> > >> then the spec must point it out. More below related to MT.
> > >>
> > >> Both Cisco and Juniper docs use terms like "IPv6 multicast address
> > >> family" or "MCAST-VPN address family" that clearly include SAFI as
> well.
> > >>
> > >> For better or worse, in the ietf-routing YANG module "address-
> family"
> > >> leaf is defined with the type
> > >>
> > >>          type identityref {
> > >>            base address-family;
> > >>          }
> > >>
> > >> so its meaning follows from that, including the fact that the
> identity
> > >> is extensible. In my view, it is a feature, not bug.
> > >>
> > >> >
> > >> >>
> > >> >> >
> > >> >> > This is also a problem in case of Multi-topology. Each
> topology has
> > >> >> its own RIB and a protocol instance like OSPF can connect to
> multiple
> > >> MT
> > >> >> RIBs.
> > >> >>
> > >> >> Two possible solutions come to my mind:
> > >> >>
> > >> >> 1. You could derive new address family identities from "ipv4-
> unicast"
> > >> >> etc. so that you can assign a unique address family to multiple
> > >> tables.
> > >> >>
> > >> >> 2. You could have one connected RIB e.g. for "ipv4-unicast" and
> > >> define
> > >> >> two or more RIBs for each topology as recipients of the
> connected RIB.
> > >> >> So, in effect, the (single) connected RIB contains routes for
> all
> > >> >> topologies and these are then split via route filters to the
> per-
> > >> >> topology RIBs.
> > >> >>
> > >> >> Does it make sense?
> > >> >
> > >> > Compare the two, I don't like #2 because it adds an unnecessary
> > >> indirection. I don't think we want to overload "Address Family"
> further
> > >> to include topology either. In many implementations, actual RIBs
> are per
> > >> (routing-instance, AFI, SAFI, topology) and it may be extended
> further.
> > >> Therefore, the best option is to simply remove the restriction that
> one
> > >> protocol instance is connected to exactly one RIB per address
> family.
> > >>
> > >> This restriction is only relevant for the "connected-rib" list. If
> you
> > >> want, you can add configuration parameters to associate other RIBs
> > >> directly with a routing protocol instance.
> > >>
> > >> IMO, the common use case for MT are incongruent IPv4 and IPv6
> topologies,
> > >> and the core routing data model can handle this directly and easily.
> > >>
> > >> Also note that the "routing-cfg" document has already been
> submitted to
> > >> IESG for publication, so your comments come really late.
> > >>
> > >> >
> > >> >>
> > >> >> >
> > >> >> > ------
> > >> >> >
> > >> >> > 5.1.  Routing Instance
> > >> >> >
> > >> >> >    Each routing instance in the core routing data model
> represents
> > >> a
> > >> >> >    logical router.  The exact semantics of this term are left
> to
> > >> >> >    implementations.  For example, routing instances may be
> > >> completely
> > >> >> >    isolated virtual routers or, alternatively, they may
> internally
> > >> share
> > >> >> >    certain information.
> > >> >> >
> > >> >> >    ...
> > >> >> >
> > >> >> >    An implementation MAY support multiple types of logical
> routers
> > >> >> >    simultaneously.  Instances of all routing instance types
> are
> > >> >> >    organized as entries of the same flat "routing-instance"
> list.
> > >> In
> > >> >> >    order to discriminate routing instances belonging to
> different
> > >> types,
> > >> >> >    the "type" leaf is defined as a child of the "routing-
> instance"
> > >> node.
> > >> >> >
> > >> >> > The spec purposely left it fuzzy as to what a "routing
> instance" is.
> > >> >> However we definitely should have clear definitions for the
> three
> > >> terms
> > >> >> mentioned: routing-instance, logical router and virtual router.
> > >> >>
> > >> >> Yes, this is by design open-ended because otherwise we would
> probably
> > >> >> never reach consensus on what these terms exactly mean.
> > >> >
> > >> > While the design needs to be open-ended a standard specification
> needs
> > >> to be precise and unambiguous. The names can be discussed and
> > >> compromised but the meaning must be clear. For example, Cisco
> "virtual
> > >> router" and Juniper "logical router/system" are the same but
> Juniper
> > >> "virtual router" and Cisco "VRF-lite" are the same. What does the
> > >> "logical router" in this spec mean? We can't just say that "it can
> mean
> > >> any of those". For example if it means Cisco's "virtual router" or
> > >> Juniper's "logical system", a further discussion may be - should
> this
> > >> module really cover that.
> > >>
> > >> The term "logical router" is used in a very general sense, and the
> > >> document clearly says so ("no semantics"). The other terms are used
> only
> > >> as examples what it could possibly mean, to make the spec more
> > >> accessible.
> > >>
> > >> >
> > >> >>
> > >> >> >
> > >> >> > Logical router is a very overload term. Today vendors have
> > >> virtualized
> > >> >> their routing capabilities in the system and provide 3 different
> > >> levels
> > >> >> of routing virtualization. Logical systems, logical routers are
> some
> > >> of
> > >> >> the names used by vendors and those offer routing and management
> > >> >> separation. Each logical system has its own routing instances
> and
> > >> >> routing instances can have multiple routing tables, so it is
> very
> > >> >> important to have very precise definition of what is routing
> instance
> > >> >> (and not compare it with logical router)
> > >> >> >
> > >> >> >      identity standard-routing-instance {
> > >> >> >        base routing-instance-type;
> > >> >> >        description
> > >> >> >          "This identity represents a default routing
> instance.";
> > >> >> >      }
> > >> >> >
> > >> >> > What is a "standard-routing-instance"? Would "default-routing-
> > >> >> instance" be better? "standard" wording leads to "standard vs.
> non-
> > >> >> standard" question and hints on that the two are different types.
> > >> >> "default" vs. "non-default" does not have that (at least to me).
> > >> >>
> > >> >> Well, "default" is overloaded, too, and also has a specific
> meaning
> > >> in
> > >> >> YANG. Standard is supposed to mean plain vanilla router. It is
> just a
> > >> >> name.
> > >> >
> > >> > I don't have to split hair between "standard" and "default" but
> the
> > >> spec must point out what a "standard-routing-instance" is - is it
> the
> > >> default/base/master logical-system (Cisco virtual-router) or the
> > >> default/base/master "routing-instance" (a "logical-system" would
> include
> > >> many "routing-instances" like VRFs).
> > >> >
> > >>
> > >> I think the ietf-routing module makes it pretty clear:
> > >>
> > >>          leaf type {
> > >>            type identityref {
> > >>              base routing-instance-type;
> > >>            }
> > >>            default "rt:standard-routing-instance";
> > >>            description
> > >>              "The type of the routing instance.";
> > >>          }
> > >>
> > >> The purpose of the "type" is to allow for defining a new routing
> > >> instance type and augment configuration or state data conditionally
> for
> > >> that type. The "standard-routing-instance" is just the default
> value to
> > >> start from, it has no other meaning.
> > >>
> > >>
> > >> >>
> > >> >> >
> > >> >> > Should this spec distinguish VRF/VR/LR and have corresponding
> > >> >> identities defined?
> > >> >>
> > >> >> The idea is this will be done in other modules that define data
> > >> models
> > >> >> for these types of routing instances. Then the "routing-
> instance"
> > >> >> container can be augmented with arbitrary data, but
> conditionally for
> > >> >> that routing instance type.
> > >> >
> > >> > I think it is important to define a few well known routing
> instance
> > >> types in the base spec as a good foundation for other modules.
> > >>
> > >> This is outside the scope of the core routing data model, and
> should be
> > >> done by routing experts, not in the NETMOD group. There are other
> > >> indispensable elements that have to be worked out before the
> routing
> > >> data model can be really useful, e.g. routing protocols and route
> > >> filters.
> > >>
> > >> >
> > >> >>
> > >> >> An implementation may actually use multiple routing-instance
> types at
> > >> >> the same time.
> > >> >
> > >> > That's for sure and not what I'm concerned with.
> > >> >
> > >> >>
> > >> >> >
> > >> >> >          leaf type {
> > >> >> >            type identityref {
> > >> >> >              base routing-instance-type;
> > >> >> >            }
> > >> >> >            description
> > >> >> >              "The routing instance type, primarily intended
> for
> > >> >> >               discriminating among different types of logical
> > >> routers,
> > >> >> >               route virtualization, master-slave arrangements
> etc.,
> > >> >> >               while keeping all routing instances in the same
> flat
> > >> >> >               list.";
> > >> >> >          }
> > >> >> >
> > >> >> > What is the "master-slave arrangements"?
> > >> >>
> > >> >> This came from an early review by Thomas Morin, it has to do
> with
> > >> >> MPLS/BGP VPNs where a master routing-instance exchanges selected
> > >> routes
> > >> >> with each VPN/VRF.
> > >> >
> > >> > Either it needs to be clarified in the spec, or it could simply
> be
> > >> removed to avoid confusion since "route virtualization" covers that
> > >> already.
> > >>
> > >> This is actually a typo - it should be "router virtualization". My
> > >> understanding of this term is that a virtual router is isolated and
> > >> exchanges routing information with other routers only through
> routing
> > >> protocols.
> > >>
> > >> Anyway, these are really only examples and I think it is
> sufficiently
> > >> clear that the core routing data model doesn't use these terms for
> > >> defining any semantics.
> > >>
> > >> Lada
> > >>
> > >> >
> > >> >>
> > >> >> >
> > >> >> > Depending on the definition of "logical router" and "route
> > >> >> virtualization", there may also be concerns with keeping all
> those
> > >> kinds
> > >> >> of in the same flat list.
> > >> >>
> > >> >> It is similar to interfaces, where physical and logical
> interfaces of
> > >> >> all kinds live in the same flat list and are distinguished by
> the
> > >> type.
> > >> >> I think it could work, relationships among the individual
> routing
> > >> >> instances can be expressed in other data.
> > >> >
> > >> > I will defer to others about the merits of a flat list, but for a
> flat
> > >> list, the base spec needs to provide a way to express the
> relationship.
> > >> >
> > >> > Jeffrey
> > >> >
> > >> >>
> > >> >> Having a single flat list has its advantages, for example you
> can
> > >> then
> > >> >> easily refer to routing instances via leafrefs (which allow only
> one
> > >> >> path).
> > >> >>
> > >> >> Cheers, Lada
> > >> >>
> > >> >> >
> > >> >> > Jeffrey Zhang
> > >> >> > Dean Bogdanovic
> > >> >>
> > >> >> --
> > >> >> Ladislav Lhotka, CZ.NIC Labs
> > >> >> PGP Key ID: E74E8C0C
> > >>
> > >> --
> > >> Ladislav Lhotka, CZ.NIC Labs
> > >> PGP Key ID: E74E8C0C
> >
> > --
> > Ladislav Lhotka, CZ.NIC Labs
> > PGP Key ID: E74E8C0C
> >
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> >
>=20
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>=20
>=20
>=20


From nobody Mon Jun 23 12:35:01 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29D001B2B0D for ; Mon, 23 Jun 2014 12:34:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.602
X-Spam-Level: 
X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DLL9vQ06Otzy for ; Mon, 23 Jun 2014 12:34:54 -0700 (PDT)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0205.outbound.protection.outlook.com [207.46.163.205]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F8D31B2ABD for ; Mon, 23 Jun 2014 12:34:54 -0700 (PDT)
Received: from BN1PR05MB424.namprd05.prod.outlook.com (10.141.58.148) by BN1PR05MB075.namprd05.prod.outlook.com (10.255.199.21) with Microsoft SMTP Server (TLS) id 15.0.954.9; Mon, 23 Jun 2014 19:34:44 +0000
Received: from BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.141]) by BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.155]) with mapi id 15.00.0954.000; Mon, 23 Jun 2014 19:34:44 +0000
From: Dean Bogdanovic 
To: Ladislav Lhotka 
Thread-Topic: Questions/comments on draft-ietf-netmod-routing-cfg
Thread-Index: Ac+L5mG6QCip6E9wRnWAlQy1vx1YdgAlBfOAAACoQiAAj+tmAAAIpPrQAAR9eIAACGppgAABzL6A
Date: Mon, 23 Jun 2014 19:34:44 +0000
Message-ID: <7917CA6C-86CD-4B4C-B308-98E4D0B364F5@juniper.net>
References:   <18cd777ffb9d4df6b0966dd1b3dd822b@BY2PR05MB079.namprd05.prod.outlook.com>    
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-mailer: Apple Mail (2.1510)
x-originating-ip: [66.129.241.14]
x-microsoft-antispam: BL:0; ACTION:Default; RISK:Low; SCL:0; SPMLVL:NotSpam; PCL:0; RULEID:
x-forefront-prvs: 025100C802
x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(428001)(199002)(189002)(24454002)(25584003)(13464003)(377454003)(51704005)(81342001)(4396001)(86362001)(93916002)(575784001)(105586002)(85306003)(74502001)(74662001)(106356001)(31966008)(50226001)(19580395003)(81542001)(83322001)(19580405001)(77156001)(92726001)(92566001)(36756003)(77096002)(87286001)(20776003)(87936001)(79102001)(104166001)(76482001)(89996001)(80022001)(15975445006)(66066001)(83716003)(21056001)(77982001)(64706001)(2656002)(83072002)(82746002)(85852003)(50986999)(46102001)(101416001)(57306001)(76176999)(15202345003)(93886003)(88136002)(33656002)(99286002)(95666004)(99396002)(62966002)(104396001); DIR:OUT; SFP:; SCL:1; SRVR:BN1PR05MB075; H:BN1PR05MB424.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; 
received-spf: None (: juniper.net does not designate permitted sender hosts)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=deanb@juniper.net; 
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <5899DEC30BE5444C84C22BC89561D5FA@namprd05.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/3PGbA2X3vkmYUzrMYLChwIKrQvI
Cc: "Jeffrey \(Zhaohui\) Zhang" , Kiran Agrahara Sreenivasa , "netmod@ietf.org" 
Subject: Re: [netmod] Questions/comments on draft-ietf-netmod-routing-cfg
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 23 Jun 2014 19:34:59 -0000

On Jun 23, 2014, at 2:43 PM, Ladislav Lhotka  wrote:

>=20
> On 23 Jun 2014, at 16:42, Dean Bogdanovic  wrote:
>=20
>> Lada,
>>=20
>> Semantics has to be precise, otherwise it can be very differently reinte=
rpreted and then standards becomes not useful.
>>=20
>> My take on this is we need a two abstractions
>> 1. routing table - which is a container of routes
>=20
> This is called RIB in the ietf-routing module, after the terminology has =
been harmonized with the I2RS RIB info model.
>=20
>> and
>> 2. container of routing tables - this container has to have a precise na=
me
>=20
> I am not sure I understand - in the ietf-routing module, this container d=
oes have a precise name: =93ribs=94, i.e., every routing instance can use m=
ultiple RIBs.
so based on your sentence routing instance is a container of RIBs?

>=20
>>=20
>> If the 2. container name is not well specified and IMO, it is not in you=
r draft, it will be hard to use your draft as foundation. Right now your de=
finition allows free definition of container of routing tables and containe=
r of containers of routing tables. We don't need a definition of container =
of containers of routing tables. If we can come to agreement for the above =
two, that would be great.
>=20
> But routing instances are (among other things) exactly these containers o=
f containers of RIBs, but IMO the various types of routing instances so far=
 have been pretty much vendor-specific, even though there are some de facto=
 standards. It would be great if these thing are standardised in the IETF, =
and corresponding YANG modules written.
>=20
here you are saying that routing instance is container of container of RIBs=
, which is one abstraction too many, based on your previous  sentence

>>=20
>>=20
>> The document is with IESG, but there is still possibility to bring DISCU=
SS and COMMENT items
>> http://tools.ietf.org/html/rfc4858#section-3.3
>=20
> It sure is.
>=20
> Lada
>=20
>>=20
>>=20
>> On Jun 23, 2014, at 8:59 AM, Jeffrey (Zhaohui) Zhang  wrote:
>>=20
>>> Lada,
>>>=20
>>> The discussions basically boil down to two main points:
>>>=20
>>> - I believe the spec should have well defined semantics for some well-k=
nown types of "routing-instances". Otherwise it is too loose to be the foun=
dation for future work (e.g. the on-going OSPF YANG model work). That does =
not prevent the flexibility for future extensions.
>>=20
>> I agree with this one very strongly.=20
>>>=20
>>> - I think the spec is too restrictive in saying "Each routing protocol =
instance is connected to exactly one RIB for each address family that the r=
outing protocol instance supports". We can mix AF and SAF together and simp=
ly say Address Family (if we make it clear) but with the consideration of M=
T the statement is just not correct.
>>>=20
>>> I am more concerned with the first point.
>>>=20
>>> I don't think this is too late. There is still IETF last call and I am =
posting my comments here. If there is enough consensus to my points, then n=
ecessary changes need to happen. If not, I'll accept that.
>>>=20
>>> Thanks.
>>> Jeffrey
>>>=20
>>>> -----Original Message-----
>>>> From: Ladislav Lhotka [mailto:lhotka@nic.cz]
>>>> Sent: Monday, June 23, 2014 4:26 AM
>>>> To: Jeffrey (Zhaohui) Zhang; Dean Bogdanovic; netmod@ietf.org
>>>> Cc: Derek Man-Kit Yeung (myeung); Kiran Agrahara Sreenivasa
>>>> Subject: RE: Questions/comments on draft-ietf-netmod-routing-cfg
>>>>=20
>>>> "Jeffrey (Zhaohui) Zhang"  writes:
>>>>=20
>>>>> Lada,
>>>>>=20
>>>>>> -----Original Message-----
>>>>>> From: Ladislav Lhotka [mailto:lhotka@nic.cz]
>>>>>> Sent: Friday, June 20, 2014 7:26 AM
>>>>>> To: Jeffrey (Zhaohui) Zhang; Dean Bogdanovic; netmod@ietf.org
>>>>>> Cc: Derek Man-Kit Yeung (myeung); Kiran Agrahara Sreenivasa
>>>>>> Subject: Re: Questions/comments on draft-ietf-netmod-routing-cfg
>>>>>>=20
>>>>>> "Jeffrey (Zhaohui) Zhang"  writes:
>>>>>>=20
>>>>>>> Ladislav,
>>>>>>>=20
>>>>>>> Dean and I have some late questions and comments. We came across
>>>> these
>>>>>> while trying to work on the OSPF YANG model.
>>>>>>>=20
>>>>>>> -----------
>>>>>>>=20
>>>>>>> The spec mentions in several places something like the following:
>>>>>>>=20
>>>>>>>   Each routing protocol instance is connected to exactly one RIB
>>>> for
>>>>>>>   each address family that the routing protocol instance supports.
>>>>>>>=20
>>>>>>> My understanding is that the address family mentioned above does
>>>> not
>>>>>> include SAFI. Because of that, a routing protocol like BGP may
>>>> connect
>>>>>> to multiple RIBs in the same family (RIB for unicast and RIB for
>>>>>> multicast RPF purpose in case of incongruent multicast topology) so
>>>> the
>>>>>> above statement is not correct.
>>>>>>=20
>>>>>> This is quite flexible since address family is defined via identitie=
s.
>>>> I
>>>>>> can imagine one implementation using only "ipv4" and "ipv6" (defined
>>>> in
>>>>>> ietf-routing) whilst other implementation could use "ipv[46]-unicast=
"
>>>>>> (defined in ietf-ipv[46]-unicast-routing) and "ipv[46]-multicast" (t=
o
>>>> be
>>>>>> defined in a module for unicast routing), that means including SAFI.
>>>>>=20
>>>>> Address Family has very specific meanings, typically only refer to
>>>> IPv4/IPv6 to my understanding. If we want to extend that to include SA=
FI,
>>>> then the spec must point it out. More below related to MT.
>>>>=20
>>>> Both Cisco and Juniper docs use terms like "IPv6 multicast address
>>>> family" or "MCAST-VPN address family" that clearly include SAFI as wel=
l.
>>>>=20
>>>> For better or worse, in the ietf-routing YANG module "address-family"
>>>> leaf is defined with the type
>>>>=20
>>>>        type identityref {
>>>>          base address-family;
>>>>        }
>>>>=20
>>>> so its meaning follows from that, including the fact that the identity
>>>> is extensible. In my view, it is a feature, not bug.
>>>>=20
>>>>>=20
>>>>>>=20
>>>>>>>=20
>>>>>>> This is also a problem in case of Multi-topology. Each topology has
>>>>>> its own RIB and a protocol instance like OSPF can connect to multipl=
e
>>>> MT
>>>>>> RIBs.
>>>>>>=20
>>>>>> Two possible solutions come to my mind:
>>>>>>=20
>>>>>> 1. You could derive new address family identities from "ipv4-unicast=
"
>>>>>> etc. so that you can assign a unique address family to multiple
>>>> tables.
>>>>>>=20
>>>>>> 2. You could have one connected RIB e.g. for "ipv4-unicast" and
>>>> define
>>>>>> two or more RIBs for each topology as recipients of the connected RI=
B.
>>>>>> So, in effect, the (single) connected RIB contains routes for all
>>>>>> topologies and these are then split via route filters to the per-
>>>>>> topology RIBs.
>>>>>>=20
>>>>>> Does it make sense?
>>>>>=20
>>>>> Compare the two, I don't like #2 because it adds an unnecessary
>>>> indirection. I don't think we want to overload "Address Family" furthe=
r
>>>> to include topology either. In many implementations, actual RIBs are p=
er
>>>> (routing-instance, AFI, SAFI, topology) and it may be extended further=
.
>>>> Therefore, the best option is to simply remove the restriction that on=
e
>>>> protocol instance is connected to exactly one RIB per address family.
>>>>=20
>>>> This restriction is only relevant for the "connected-rib" list. If you
>>>> want, you can add configuration parameters to associate other RIBs
>>>> directly with a routing protocol instance.
>>>>=20
>>>> IMO, the common use case for MT are incongruent IPv4 and IPv6 topologi=
es,
>>>> and the core routing data model can handle this directly and easily.
>>>>=20
>>>> Also note that the "routing-cfg" document has already been submitted t=
o
>>>> IESG for publication, so your comments come really late.
>>>>=20
>>>>>=20
>>>>>>=20
>>>>>>>=20
>>>>>>> ------
>>>>>>>=20
>>>>>>> 5.1.  Routing Instance
>>>>>>>=20
>>>>>>>  Each routing instance in the core routing data model represents
>>>> a
>>>>>>>  logical router.  The exact semantics of this term are left to
>>>>>>>  implementations.  For example, routing instances may be
>>>> completely
>>>>>>>  isolated virtual routers or, alternatively, they may internally
>>>> share
>>>>>>>  certain information.
>>>>>>>=20
>>>>>>>  ...
>>>>>>>=20
>>>>>>>  An implementation MAY support multiple types of logical routers
>>>>>>>  simultaneously.  Instances of all routing instance types are
>>>>>>>  organized as entries of the same flat "routing-instance" list.
>>>> In
>>>>>>>  order to discriminate routing instances belonging to different
>>>> types,
>>>>>>>  the "type" leaf is defined as a child of the "routing-instance"
>>>> node.
>>>>>>>=20
>>>>>>> The spec purposely left it fuzzy as to what a "routing instance" is=
.
>>>>>> However we definitely should have clear definitions for the three
>>>> terms
>>>>>> mentioned: routing-instance, logical router and virtual router.
>>>>>>=20
>>>>>> Yes, this is by design open-ended because otherwise we would probabl=
y
>>>>>> never reach consensus on what these terms exactly mean.
>>>>>=20
>>>>> While the design needs to be open-ended a standard specification need=
s
>>>> to be precise and unambiguous. The names can be discussed and
>>>> compromised but the meaning must be clear. For example, Cisco "virtual
>>>> router" and Juniper "logical router/system" are the same but Juniper
>>>> "virtual router" and Cisco "VRF-lite" are the same. What does the
>>>> "logical router" in this spec mean? We can't just say that "it can mea=
n
>>>> any of those". For example if it means Cisco's "virtual router" or
>>>> Juniper's "logical system", a further discussion may be - should this
>>>> module really cover that.
>>>>=20
>>>> The term "logical router" is used in a very general sense, and the
>>>> document clearly says so ("no semantics"). The other terms are used on=
ly
>>>> as examples what it could possibly mean, to make the spec more
>>>> accessible.
>>>>=20
>>>>>=20
>>>>>>=20
>>>>>>>=20
>>>>>>> Logical router is a very overload term. Today vendors have
>>>> virtualized
>>>>>> their routing capabilities in the system and provide 3 different
>>>> levels
>>>>>> of routing virtualization. Logical systems, logical routers are some
>>>> of
>>>>>> the names used by vendors and those offer routing and management
>>>>>> separation. Each logical system has its own routing instances and
>>>>>> routing instances can have multiple routing tables, so it is very
>>>>>> important to have very precise definition of what is routing instanc=
e
>>>>>> (and not compare it with logical router)
>>>>>>>=20
>>>>>>>     identity standard-routing-instance {
>>>>>>>       base routing-instance-type;
>>>>>>>       description
>>>>>>>         "This identity represents a default routing instance.";
>>>>>>>     }
>>>>>>>=20
>>>>>>> What is a "standard-routing-instance"? Would "default-routing-
>>>>>> instance" be better? "standard" wording leads to "standard vs. non-
>>>>>> standard" question and hints on that the two are different types.
>>>>>> "default" vs. "non-default" does not have that (at least to me).
>>>>>>=20
>>>>>> Well, "default" is overloaded, too, and also has a specific meaning
>>>> in
>>>>>> YANG. Standard is supposed to mean plain vanilla router. It is just =
a
>>>>>> name.
>>>>>=20
>>>>> I don't have to split hair between "standard" and "default" but the
>>>> spec must point out what a "standard-routing-instance" is - is it the
>>>> default/base/master logical-system (Cisco virtual-router) or the
>>>> default/base/master "routing-instance" (a "logical-system" would inclu=
de
>>>> many "routing-instances" like VRFs).
>>>>>=20
>>>>=20
>>>> I think the ietf-routing module makes it pretty clear:
>>>>=20
>>>>        leaf type {
>>>>          type identityref {
>>>>            base routing-instance-type;
>>>>          }
>>>>          default "rt:standard-routing-instance";
>>>>          description
>>>>            "The type of the routing instance.";
>>>>        }
>>>>=20
>>>> The purpose of the "type" is to allow for defining a new routing
>>>> instance type and augment configuration or state data conditionally fo=
r
>>>> that type. The "standard-routing-instance" is just the default value t=
o
>>>> start from, it has no other meaning.
>>>>=20
>>>>=20
>>>>>>=20
>>>>>>>=20
>>>>>>> Should this spec distinguish VRF/VR/LR and have corresponding
>>>>>> identities defined?
>>>>>>=20
>>>>>> The idea is this will be done in other modules that define data
>>>> models
>>>>>> for these types of routing instances. Then the "routing-instance"
>>>>>> container can be augmented with arbitrary data, but conditionally fo=
r
>>>>>> that routing instance type.
>>>>>=20
>>>>> I think it is important to define a few well known routing instance
>>>> types in the base spec as a good foundation for other modules.
>>>>=20
>>>> This is outside the scope of the core routing data model, and should b=
e
>>>> done by routing experts, not in the NETMOD group. There are other
>>>> indispensable elements that have to be worked out before the routing
>>>> data model can be really useful, e.g. routing protocols and route
>>>> filters.
>>>>=20
>>>>>=20
>>>>>>=20
>>>>>> An implementation may actually use multiple routing-instance types a=
t
>>>>>> the same time.
>>>>>=20
>>>>> That's for sure and not what I'm concerned with.
>>>>>=20
>>>>>>=20
>>>>>>>=20
>>>>>>>         leaf type {
>>>>>>>           type identityref {
>>>>>>>             base routing-instance-type;
>>>>>>>           }
>>>>>>>           description
>>>>>>>             "The routing instance type, primarily intended for
>>>>>>>              discriminating among different types of logical
>>>> routers,
>>>>>>>              route virtualization, master-slave arrangements etc.,
>>>>>>>              while keeping all routing instances in the same flat
>>>>>>>              list.";
>>>>>>>         }
>>>>>>>=20
>>>>>>> What is the "master-slave arrangements"?
>>>>>>=20
>>>>>> This came from an early review by Thomas Morin, it has to do with
>>>>>> MPLS/BGP VPNs where a master routing-instance exchanges selected
>>>> routes
>>>>>> with each VPN/VRF.
>>>>>=20
>>>>> Either it needs to be clarified in the spec, or it could simply be
>>>> removed to avoid confusion since "route virtualization" covers that
>>>> already.
>>>>=20
>>>> This is actually a typo - it should be "router virtualization". My
>>>> understanding of this term is that a virtual router is isolated and
>>>> exchanges routing information with other routers only through routing
>>>> protocols.
>>>>=20
>>>> Anyway, these are really only examples and I think it is sufficiently
>>>> clear that the core routing data model doesn't use these terms for
>>>> defining any semantics.
>>>>=20
>>>> Lada
>>>>=20
>>>>>=20
>>>>>>=20
>>>>>>>=20
>>>>>>> Depending on the definition of "logical router" and "route
>>>>>> virtualization", there may also be concerns with keeping all those
>>>> kinds
>>>>>> of in the same flat list.
>>>>>>=20
>>>>>> It is similar to interfaces, where physical and logical interfaces o=
f
>>>>>> all kinds live in the same flat list and are distinguished by the
>>>> type.
>>>>>> I think it could work, relationships among the individual routing
>>>>>> instances can be expressed in other data.
>>>>>=20
>>>>> I will defer to others about the merits of a flat list, but for a fla=
t
>>>> list, the base spec needs to provide a way to express the relationship=
.
>>>>>=20
>>>>> Jeffrey
>>>>>=20
>>>>>>=20
>>>>>> Having a single flat list has its advantages, for example you can
>>>> then
>>>>>> easily refer to routing instances via leafrefs (which allow only one
>>>>>> path).
>>>>>>=20
>>>>>> Cheers, Lada
>>>>>>=20
>>>>>>>=20
>>>>>>> Jeffrey Zhang
>>>>>>> Dean Bogdanovic
>>>>>>=20
>>>>>> --
>>>>>> Ladislav Lhotka, CZ.NIC Labs
>>>>>> PGP Key ID: E74E8C0C
>>>>=20
>>>> --
>>>> Ladislav Lhotka, CZ.NIC Labs
>>>> PGP Key ID: E74E8C0C
>>=20
>=20
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>=20
>=20
>=20
>=20


From nobody Mon Jun 23 12:42:52 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCD841B28F5 for ; Mon, 23 Jun 2014 12:42:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.302
X-Spam-Level: 
X-Spam-Status: No, score=-1.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RP_MATCHES_RCVD=-0.651] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l0Nl97bW0t2E for ; Mon, 23 Jun 2014 12:42:46 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E2401B2B1D for ; Mon, 23 Jun 2014 12:42:45 -0700 (PDT)
Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 8F39B1400FA; Mon, 23 Jun 2014 21:42:42 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1403552563; bh=VB/3PcQZJOFYcDfnzoOh9TZNXd1ZzpTw+7I30YiLwjg=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=WakBtRIs1uWtaecUiYusy9/vsljrkIs26qQDNFGRlv57Trr9OWApsV/vqSFyD4wNn iK4cSY0Tt0Kg/ALSx7ebPWnKzOyrRF9tR2xGOa+18+xH7QRHjN936RQR38h0496cza IH6/pQDRE1zdDW1rC1MpV6dLX4fDLD+2KFCGSDp4=
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
From: Ladislav Lhotka 
In-Reply-To: 
Date: Mon, 23 Jun 2014 21:42:41 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <4CC621BD-78B4-4945-91C8-D7FC0921CC91@nic.cz>
References:   <18cd777ffb9d4df6b0966dd1b3dd822b@BY2PR05MB079.namprd05.prod.outlook.com>     <45F6E463-82A0-4EF0-9EF7-E4B9D4EE7F80@nic.cz> 
To: "Jeffrey (Zhaohui) Zhang" 
X-Mailer: Apple Mail (2.1878.2)
X-Virus-Scanned: clamav-milter 0.98.1 at mail
X-Virus-Status: Clean
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/u7UwmHqllt-8lwCCCSYcL8GVQy8
Cc: Kiran Agrahara Sreenivasa , "netmod@ietf.org" 
Subject: Re: [netmod] Questions/comments on draft-ietf-netmod-routing-cfg
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 23 Jun 2014 19:42:50 -0000

On 23 Jun 2014, at 20:59, Jeffrey (Zhaohui) Zhang  =
wrote:

> Lada,
>=20
>> Right, but it doesn't mean this more has to be implemented by the =
core
>> routing model. I think the important point is that such extensions =
are
>> possible to do in other modules, and I am convinced it is the case
>=20
> While we are trying to work on the OSPF YANG module, which is to base =
on netmod-routing-cfg, some interpret the "routing-instance" in =
netmod-routing-cfg as Juniper's "Logical Router/System" (i.e. Cisco's =
"Virtual Router"), while some others interpret that as Juniper's VRF/VR =
(i.e., Cisco's VRF/VRF-lite). That difference has a major impact on how =
OSPF YANG module is defined.

It is none of the above, and I think the draft is pretty clear about =
this. You can consider the =93standard-routing-instance=94 to represent =
the situation before any logical/virtual routers were introduced, =
because that=92s what is standardized. It is not the job for the =
ietf-routing module to declare Cisco's virtualization model superior to =
Juniper=92s, or vice versa.
    =20
>=20
> If netmod-routing-cfg is to allow both the above, it is critical for =
netmod-routing-cfg to be clear what the terms "logical router" and =
"virtual router" mean, and then OSPF YANG module will proceed =
accordingly. It does not make sense to defer that to another document.

Why not? The amount of work needed for writing an extra module is pretty =
much the same as for adding it to ietf-routing and, importantly, it is a =
task for routing experts to decide what a standard logical/virtual =
router should be.

>=20
> There are even people who argue that it is not good to put the above =
two types of routing instances into the same flat list. That's a =
separate topic and I am not trying to open up that discussion here, but =
it shows how important it is for the netmod-routing-cfg to be clear what =
a "routing-instances" is instead of deferring to another document.

Those people should explain why it is not good.

Lada=20

>=20
> Jeffrey
>=20
>> -----Original Message-----
>> From: Ladislav Lhotka [mailto:lhotka@nic.cz]
>> Sent: Monday, June 23, 2014 2:16 PM
>> To: Alia Atlas
>> Cc: Jeffrey (Zhaohui) Zhang; Dean Bogdanovic; netmod@ietf.org; Kiran
>> Agrahara Sreenivasa
>> Subject: Re: [netmod] Questions/comments on =
draft-ietf-netmod-routing-
>> cfg
>>=20
>> Hi Alia,
>>=20
>> On 23 Jun 2014, at 17:32, Alia Atlas  wrote:
>>=20
>>> Lada,
>>>=20
>>> On Mon, Jun 23, 2014 at 10:38 AM, Ladislav Lhotka 
>> wrote:
>>> "Jeffrey (Zhaohui) Zhang"  writes:
>>>=20
>>>> Lada,
>>>>=20
>>>> The discussions basically boil down to two main points:
>>>>=20
>>>> - I believe the spec should have well defined semantics for some
>> well-known types of "routing-instances". Otherwise it is too loose to =
be
>> the foundation for future work (e.g. the on-going OSPF YANG model =
work).
>> That does not prevent the flexibility for future extensions.
>>>=20
>>> The OSPF (and more recent ISIS) module can work just fine with
>> "standard-routing-instance". On smaller router platforms (OpenWRT =
with
>> Quagga or BIRD daemons) this is all that's needed. I don't know why
>> specific routing instance types couldn't be defined in separate =
modules.
>>>=20
>>>=20
>>> Supporting very common features (L3VPNs, logical routers, multiple
>> routing instances) can
>>> make routers significantly more complex than Quagga supports.  While
>> Quagga certainly has some useful features, I do not think it has kept
>> pace.  What is needed for routing is more.
>>=20
>> Right, but it doesn't mean this more has to be implemented by the =
core
>> routing model. I think the important point is that such extensions =
are
>> possible to do in other modules, and I am convinced it is the case.
>>=20
>>=20
>>>=20
>>>>=20
>>>> - I think the spec is too restrictive in saying "Each routing
>> protocol instance is connected to exactly one RIB for each address
>> family that the routing protocol instance supports". We can mix AF =
and
>> SAF together and simply say Address Family (if we make it clear) but
>> with the consideration of MT the statement is just not correct.
>>>=20
>>> There are currently three possible solutions:
>>>=20
>>> 1. Subdivide each address family via identity derivation, e.g. with
>> respect to type of service.
>>>=20
>>> 2. Distribute routes from the connected RIB selectively to any =
number
>> other RIBs via "recipient-rib" mechanism.
>>>=20
>>> 3. Augment the "routing-protocol" subtrees with new parameters. For
>> example, one could introduce protocol "sub-instances", one for each
>> topology, and then different sub-instances could use the same address
>> family (this is by the way another advantage of having a flat list of
>> routing protocol instances).
>>>=20
>>> In my view, this choice should be sufficient.
>>>=20
>>>=20
>>>>=20
>>>> I am more concerned with the first point.
>>>>=20
>>>> I don't think this is too late. There is still IETF last call and I
>> am posting my comments here. If there is enough consensus to my =
points,
>> then necessary changes need to happen. If not, I'll accept that.
>>>=20
>>> The routing-cfg document is already long overdue. We've already had
>> several rounds of relatively significant redesigns based on =
reviewers'
>> comments, and I think now it's time to deliver the result. The data
>> model may not be perfect and I am open to returning to it after we =
gain
>> some experience, but IMO we first need to fill the gaps by developing
>> modules for routing protocols, route filters and, of course, specific
>> types of routing instances.
>>>=20
>>> Jeffrey is coming in, trying to work on an OSPF YANG model, as a
>> routing person very familiar with one implementation.  If this draft =
is
>> not a sufficient base on which to build the other routing models, how
>> should we proceed?  I have requested yet another routing directorate
>> review on this draft; I'd expect that review before the upcoming =
IETF.
>>=20
>> Yes, it is really challenging to combine YANG expertise (as YANG is a
>> relatively new data modelling language) with domain-specific =
know-how.
>> FWIW, I wrote an OSPF module for the BIRD daemon that perhaps may be
>> used for comparison:
>>=20
>> https://gitlab.labs.nic.cz/labs/yang-tools/blob/master/data-
>> models/bird/bird-ospf.yang
>>=20
>> Lada
>>=20
>>>=20
>>> I can appreciate the frustration in the time it is taking to get =
this
>> draft done.  Cross-area review does frequently happen after WGLC.
>>>=20
>>> Alia
>>>=20
>>> Lada
>>>=20
>>>>=20
>>>> Thanks.
>>>> Jeffrey
>>>>=20
>>>>> -----Original Message-----
>>>>> From: Ladislav Lhotka [mailto:lhotka@nic.cz]
>>>>> Sent: Monday, June 23, 2014 4:26 AM
>>>>> To: Jeffrey (Zhaohui) Zhang; Dean Bogdanovic; netmod@ietf.org
>>>>> Cc: Derek Man-Kit Yeung (myeung); Kiran Agrahara Sreenivasa
>>>>> Subject: RE: Questions/comments on draft-ietf-netmod-routing-cfg
>>>>>=20
>>>>> "Jeffrey (Zhaohui) Zhang"  writes:
>>>>>=20
>>>>>> Lada,
>>>>>>=20
>>>>>>> -----Original Message-----
>>>>>>> From: Ladislav Lhotka [mailto:lhotka@nic.cz]
>>>>>>> Sent: Friday, June 20, 2014 7:26 AM
>>>>>>> To: Jeffrey (Zhaohui) Zhang; Dean Bogdanovic; netmod@ietf.org
>>>>>>> Cc: Derek Man-Kit Yeung (myeung); Kiran Agrahara Sreenivasa
>>>>>>> Subject: Re: Questions/comments on draft-ietf-netmod-routing-cfg
>>>>>>>=20
>>>>>>> "Jeffrey (Zhaohui) Zhang"  writes:
>>>>>>>=20
>>>>>>>> Ladislav,
>>>>>>>>=20
>>>>>>>> Dean and I have some late questions and comments. We came
>> across
>>>>> these
>>>>>>> while trying to work on the OSPF YANG model.
>>>>>>>>=20
>>>>>>>> -----------
>>>>>>>>=20
>>>>>>>> The spec mentions in several places something like the
>> following:
>>>>>>>>=20
>>>>>>>>   Each routing protocol instance is connected to exactly one
>> RIB
>>>>> for
>>>>>>>>   each address family that the routing protocol instance
>> supports.
>>>>>>>>=20
>>>>>>>> My understanding is that the address family mentioned above
>> does
>>>>> not
>>>>>>> include SAFI. Because of that, a routing protocol like BGP may
>>>>> connect
>>>>>>> to multiple RIBs in the same family (RIB for unicast and RIB for
>>>>>>> multicast RPF purpose in case of incongruent multicast topology)
>> so
>>>>> the
>>>>>>> above statement is not correct.
>>>>>>>=20
>>>>>>> This is quite flexible since address family is defined via
>> identities.
>>>>> I
>>>>>>> can imagine one implementation using only "ipv4" and "ipv6"
>> (defined
>>>>> in
>>>>>>> ietf-routing) whilst other implementation could use "ipv[46]-
>> unicast"
>>>>>>> (defined in ietf-ipv[46]-unicast-routing) and "ipv[46]-
>> multicast" (to
>>>>> be
>>>>>>> defined in a module for unicast routing), that means including
>> SAFI.
>>>>>>=20
>>>>>> Address Family has very specific meanings, typically only refer
>> to
>>>>> IPv4/IPv6 to my understanding. If we want to extend that to =
include
>> SAFI,
>>>>> then the spec must point it out. More below related to MT.
>>>>>=20
>>>>> Both Cisco and Juniper docs use terms like "IPv6 multicast address
>>>>> family" or "MCAST-VPN address family" that clearly include SAFI as
>> well.
>>>>>=20
>>>>> For better or worse, in the ietf-routing YANG module "address-
>> family"
>>>>> leaf is defined with the type
>>>>>=20
>>>>>         type identityref {
>>>>>           base address-family;
>>>>>         }
>>>>>=20
>>>>> so its meaning follows from that, including the fact that the
>> identity
>>>>> is extensible. In my view, it is a feature, not bug.
>>>>>=20
>>>>>>=20
>>>>>>>=20
>>>>>>>>=20
>>>>>>>> This is also a problem in case of Multi-topology. Each
>> topology has
>>>>>>> its own RIB and a protocol instance like OSPF can connect to
>> multiple
>>>>> MT
>>>>>>> RIBs.
>>>>>>>=20
>>>>>>> Two possible solutions come to my mind:
>>>>>>>=20
>>>>>>> 1. You could derive new address family identities from "ipv4-
>> unicast"
>>>>>>> etc. so that you can assign a unique address family to multiple
>>>>> tables.
>>>>>>>=20
>>>>>>> 2. You could have one connected RIB e.g. for "ipv4-unicast" and
>>>>> define
>>>>>>> two or more RIBs for each topology as recipients of the
>> connected RIB.
>>>>>>> So, in effect, the (single) connected RIB contains routes for
>> all
>>>>>>> topologies and these are then split via route filters to the
>> per-
>>>>>>> topology RIBs.
>>>>>>>=20
>>>>>>> Does it make sense?
>>>>>>=20
>>>>>> Compare the two, I don't like #2 because it adds an unnecessary
>>>>> indirection. I don't think we want to overload "Address Family"
>> further
>>>>> to include topology either. In many implementations, actual RIBs
>> are per
>>>>> (routing-instance, AFI, SAFI, topology) and it may be extended
>> further.
>>>>> Therefore, the best option is to simply remove the restriction =
that
>> one
>>>>> protocol instance is connected to exactly one RIB per address
>> family.
>>>>>=20
>>>>> This restriction is only relevant for the "connected-rib" list. If
>> you
>>>>> want, you can add configuration parameters to associate other RIBs
>>>>> directly with a routing protocol instance.
>>>>>=20
>>>>> IMO, the common use case for MT are incongruent IPv4 and IPv6
>> topologies,
>>>>> and the core routing data model can handle this directly and =
easily.
>>>>>=20
>>>>> Also note that the "routing-cfg" document has already been
>> submitted to
>>>>> IESG for publication, so your comments come really late.
>>>>>=20
>>>>>>=20
>>>>>>>=20
>>>>>>>>=20
>>>>>>>> ------
>>>>>>>>=20
>>>>>>>> 5.1.  Routing Instance
>>>>>>>>=20
>>>>>>>>   Each routing instance in the core routing data model
>> represents
>>>>> a
>>>>>>>>   logical router.  The exact semantics of this term are left
>> to
>>>>>>>>   implementations.  For example, routing instances may be
>>>>> completely
>>>>>>>>   isolated virtual routers or, alternatively, they may
>> internally
>>>>> share
>>>>>>>>   certain information.
>>>>>>>>=20
>>>>>>>>   ...
>>>>>>>>=20
>>>>>>>>   An implementation MAY support multiple types of logical
>> routers
>>>>>>>>   simultaneously.  Instances of all routing instance types
>> are
>>>>>>>>   organized as entries of the same flat "routing-instance"
>> list.
>>>>> In
>>>>>>>>   order to discriminate routing instances belonging to
>> different
>>>>> types,
>>>>>>>>   the "type" leaf is defined as a child of the "routing-
>> instance"
>>>>> node.
>>>>>>>>=20
>>>>>>>> The spec purposely left it fuzzy as to what a "routing
>> instance" is.
>>>>>>> However we definitely should have clear definitions for the
>> three
>>>>> terms
>>>>>>> mentioned: routing-instance, logical router and virtual router.
>>>>>>>=20
>>>>>>> Yes, this is by design open-ended because otherwise we would
>> probably
>>>>>>> never reach consensus on what these terms exactly mean.
>>>>>>=20
>>>>>> While the design needs to be open-ended a standard specification
>> needs
>>>>> to be precise and unambiguous. The names can be discussed and
>>>>> compromised but the meaning must be clear. For example, Cisco
>> "virtual
>>>>> router" and Juniper "logical router/system" are the same but
>> Juniper
>>>>> "virtual router" and Cisco "VRF-lite" are the same. What does the
>>>>> "logical router" in this spec mean? We can't just say that "it can
>> mean
>>>>> any of those". For example if it means Cisco's "virtual router" or
>>>>> Juniper's "logical system", a further discussion may be - should
>> this
>>>>> module really cover that.
>>>>>=20
>>>>> The term "logical router" is used in a very general sense, and the
>>>>> document clearly says so ("no semantics"). The other terms are =
used
>> only
>>>>> as examples what it could possibly mean, to make the spec more
>>>>> accessible.
>>>>>=20
>>>>>>=20
>>>>>>>=20
>>>>>>>>=20
>>>>>>>> Logical router is a very overload term. Today vendors have
>>>>> virtualized
>>>>>>> their routing capabilities in the system and provide 3 different
>>>>> levels
>>>>>>> of routing virtualization. Logical systems, logical routers are
>> some
>>>>> of
>>>>>>> the names used by vendors and those offer routing and management
>>>>>>> separation. Each logical system has its own routing instances
>> and
>>>>>>> routing instances can have multiple routing tables, so it is
>> very
>>>>>>> important to have very precise definition of what is routing
>> instance
>>>>>>> (and not compare it with logical router)
>>>>>>>>=20
>>>>>>>>     identity standard-routing-instance {
>>>>>>>>       base routing-instance-type;
>>>>>>>>       description
>>>>>>>>         "This identity represents a default routing
>> instance.";
>>>>>>>>     }
>>>>>>>>=20
>>>>>>>> What is a "standard-routing-instance"? Would "default-routing-
>>>>>>> instance" be better? "standard" wording leads to "standard vs.
>> non-
>>>>>>> standard" question and hints on that the two are different =
types.
>>>>>>> "default" vs. "non-default" does not have that (at least to me).
>>>>>>>=20
>>>>>>> Well, "default" is overloaded, too, and also has a specific
>> meaning
>>>>> in
>>>>>>> YANG. Standard is supposed to mean plain vanilla router. It is
>> just a
>>>>>>> name.
>>>>>>=20
>>>>>> I don't have to split hair between "standard" and "default" but
>> the
>>>>> spec must point out what a "standard-routing-instance" is - is it
>> the
>>>>> default/base/master logical-system (Cisco virtual-router) or the
>>>>> default/base/master "routing-instance" (a "logical-system" would
>> include
>>>>> many "routing-instances" like VRFs).
>>>>>>=20
>>>>>=20
>>>>> I think the ietf-routing module makes it pretty clear:
>>>>>=20
>>>>>         leaf type {
>>>>>           type identityref {
>>>>>             base routing-instance-type;
>>>>>           }
>>>>>           default "rt:standard-routing-instance";
>>>>>           description
>>>>>             "The type of the routing instance.";
>>>>>         }
>>>>>=20
>>>>> The purpose of the "type" is to allow for defining a new routing
>>>>> instance type and augment configuration or state data =
conditionally
>> for
>>>>> that type. The "standard-routing-instance" is just the default
>> value to
>>>>> start from, it has no other meaning.
>>>>>=20
>>>>>=20
>>>>>>>=20
>>>>>>>>=20
>>>>>>>> Should this spec distinguish VRF/VR/LR and have corresponding
>>>>>>> identities defined?
>>>>>>>=20
>>>>>>> The idea is this will be done in other modules that define data
>>>>> models
>>>>>>> for these types of routing instances. Then the "routing-
>> instance"
>>>>>>> container can be augmented with arbitrary data, but
>> conditionally for
>>>>>>> that routing instance type.
>>>>>>=20
>>>>>> I think it is important to define a few well known routing
>> instance
>>>>> types in the base spec as a good foundation for other modules.
>>>>>=20
>>>>> This is outside the scope of the core routing data model, and
>> should be
>>>>> done by routing experts, not in the NETMOD group. There are other
>>>>> indispensable elements that have to be worked out before the
>> routing
>>>>> data model can be really useful, e.g. routing protocols and route
>>>>> filters.
>>>>>=20
>>>>>>=20
>>>>>>>=20
>>>>>>> An implementation may actually use multiple routing-instance
>> types at
>>>>>>> the same time.
>>>>>>=20
>>>>>> That's for sure and not what I'm concerned with.
>>>>>>=20
>>>>>>>=20
>>>>>>>>=20
>>>>>>>>         leaf type {
>>>>>>>>           type identityref {
>>>>>>>>             base routing-instance-type;
>>>>>>>>           }
>>>>>>>>           description
>>>>>>>>             "The routing instance type, primarily intended
>> for
>>>>>>>>              discriminating among different types of logical
>>>>> routers,
>>>>>>>>              route virtualization, master-slave arrangements
>> etc.,
>>>>>>>>              while keeping all routing instances in the same
>> flat
>>>>>>>>              list.";
>>>>>>>>         }
>>>>>>>>=20
>>>>>>>> What is the "master-slave arrangements"?
>>>>>>>=20
>>>>>>> This came from an early review by Thomas Morin, it has to do
>> with
>>>>>>> MPLS/BGP VPNs where a master routing-instance exchanges selected
>>>>> routes
>>>>>>> with each VPN/VRF.
>>>>>>=20
>>>>>> Either it needs to be clarified in the spec, or it could simply
>> be
>>>>> removed to avoid confusion since "route virtualization" covers =
that
>>>>> already.
>>>>>=20
>>>>> This is actually a typo - it should be "router virtualization". My
>>>>> understanding of this term is that a virtual router is isolated =
and
>>>>> exchanges routing information with other routers only through
>> routing
>>>>> protocols.
>>>>>=20
>>>>> Anyway, these are really only examples and I think it is
>> sufficiently
>>>>> clear that the core routing data model doesn't use these terms for
>>>>> defining any semantics.
>>>>>=20
>>>>> Lada
>>>>>=20
>>>>>>=20
>>>>>>>=20
>>>>>>>>=20
>>>>>>>> Depending on the definition of "logical router" and "route
>>>>>>> virtualization", there may also be concerns with keeping all
>> those
>>>>> kinds
>>>>>>> of in the same flat list.
>>>>>>>=20
>>>>>>> It is similar to interfaces, where physical and logical
>> interfaces of
>>>>>>> all kinds live in the same flat list and are distinguished by
>> the
>>>>> type.
>>>>>>> I think it could work, relationships among the individual
>> routing
>>>>>>> instances can be expressed in other data.
>>>>>>=20
>>>>>> I will defer to others about the merits of a flat list, but for a
>> flat
>>>>> list, the base spec needs to provide a way to express the
>> relationship.
>>>>>>=20
>>>>>> Jeffrey
>>>>>>=20
>>>>>>>=20
>>>>>>> Having a single flat list has its advantages, for example you
>> can
>>>>> then
>>>>>>> easily refer to routing instances via leafrefs (which allow only
>> one
>>>>>>> path).
>>>>>>>=20
>>>>>>> Cheers, Lada
>>>>>>>=20
>>>>>>>>=20
>>>>>>>> Jeffrey Zhang
>>>>>>>> Dean Bogdanovic
>>>>>>>=20
>>>>>>> --
>>>>>>> Ladislav Lhotka, CZ.NIC Labs
>>>>>>> PGP Key ID: E74E8C0C
>>>>>=20
>>>>> --
>>>>> Ladislav Lhotka, CZ.NIC Labs
>>>>> PGP Key ID: E74E8C0C
>>>=20
>>> --
>>> Ladislav Lhotka, CZ.NIC Labs
>>> PGP Key ID: E74E8C0C
>>>=20
>>> _______________________________________________
>>> netmod mailing list
>>> netmod@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netmod
>>>=20
>>=20
>> --
>> Ladislav Lhotka, CZ.NIC Labs
>> PGP Key ID: E74E8C0C
>>=20
>>=20
>>=20
>=20

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





From nobody Mon Jun 23 12:58:15 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6A561B2B77 for ; Mon, 23 Jun 2014 12:58:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.302
X-Spam-Level: 
X-Spam-Status: No, score=-1.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RP_MATCHES_RCVD=-0.651] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZRCSfMoydJxB for ; Mon, 23 Jun 2014 12:58:11 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D1E81B291C for ; Mon, 23 Jun 2014 12:58:10 -0700 (PDT)
Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 0EA1413FCDE; Mon, 23 Jun 2014 21:58:08 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1403553489; bh=eZYDebNJ7NkQ87X3k6oL4CLxdzdRTZhCUlgtnSmaebU=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=S9brzE2BOlkXkBAagsnWgioiJyKmKkmv0zTK7bk1OPRFao+W1eXMIEPuLCSP+1pFB ua5gfm1fRIHGr0paN4mv21eErWFc6AAyj9FVNjpn/+YbvGsdy8I1hY//q/8eKZos1C Lawo6sjZXQdVUKyMp4/NSZSBxK07SmhBpp5xJmS4=
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
From: Ladislav Lhotka 
In-Reply-To: 
Date: Mon, 23 Jun 2014 21:58:08 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <6E5BA386-4803-44BF-98DA-81A6673C85B3@nic.cz>
References:   <18cd777ffb9d4df6b0966dd1b3dd822b@BY2PR05MB079.namprd05.prod.outlook.com>     <89F86AF6-9114-47B2-888F-FD50CA4BA887@nic.cz> 
To: "Jeffrey (Zhaohui) Zhang" 
X-Mailer: Apple Mail (2.1878.2)
X-Virus-Scanned: clamav-milter 0.98.1 at mail
X-Virus-Status: Clean
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/hjddivvKMaz7T7jl_6-beB2q0Jw
Cc: NETMOD Working Group 
Subject: Re: [netmod] Questions/comments on draft-ietf-netmod-routing-cfg
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 23 Jun 2014 19:58:13 -0000

On 23 Jun 2014, at 21:05, Jeffrey (Zhaohui) Zhang  =
wrote:

> Lada,
>=20
>>> How about simply remove that restriction that one protocol instance
>> connects to only one RIB per address family?
>>=20
>> It has other implications: you have to have a way for specifying =
which
>> protocol routes go to which RIB, and also how the RIBs are used in =
the
>> data plane for forwarding packets.
>=20
> I am just saying to remove the restriction that one protocol instance =
only connects to one rib per family. It does not change anything else =
like what you are saying above.

I don=92t agree. If two different RIBs for, e.g., ipv4-unicast are =
connected to a routing protocol instance, then in which RIB the IPv4 =
unicast routes learned by that protocol instance are supposed to appear?
 =20
>=20
>> What is this issue with "routing-instance"? Could you be more =
specific?
>=20
> Please see my previous email that I just sent.

I don=92t know where the logical/virtual router type comes into play in =
the OSPF module. They certainly don=92t in the ISIS module.

Lada=20

>=20
> Jeffrey
>=20
>> -----Original Message-----
>> From: Ladislav Lhotka [mailto:lhotka@nic.cz]
>> Sent: Monday, June 23, 2014 2:23 PM
>> To: Jeffrey (Zhaohui) Zhang
>> Subject: Re: [netmod] Questions/comments on =
draft-ietf-netmod-routing-
>> cfg
>>=20
>>=20
>> On 23 Jun 2014, at 17:12, Jeffrey (Zhaohui) Zhang =

>> wrote:
>>=20
>>> Lada,
>>>=20
>>>> -----Original Message-----
>>>> From: Ladislav Lhotka [mailto:lhotka@nic.cz]
>>>> Sent: Monday, June 23, 2014 10:39 AM
>>>> To: Jeffrey (Zhaohui) Zhang; Dean Bogdanovic; netmod@ietf.org
>>>> Cc: Kiran Agrahara Sreenivasa
>>>> Subject: Re: [netmod] Questions/comments on draft-ietf-netmod-
>> routing-
>>>> cfg
>>>>=20
>>>> "Jeffrey (Zhaohui) Zhang"  writes:
>>>>=20
>>>>> Lada,
>>>>>=20
>>>>> The discussions basically boil down to two main points:
>>>>>=20
>>>>> - I believe the spec should have well defined semantics for some
>> well-
>>>> known types of "routing-instances". Otherwise it is too loose to be
>> the
>>>> foundation for future work (e.g. the on-going OSPF YANG model =
work).
>>>> That does not prevent the flexibility for future extensions.
>>>>=20
>>>> The OSPF (and more recent ISIS) module can work just fine with
>>>> "standard-routing-instance". On smaller router platforms (OpenWRT
>> with
>>>> Quagga or BIRD daemons) this is all that's needed. I don't know why
>>>> specific routing instance types couldn't be defined in separate
>> modules.
>>>>=20
>>>>>=20
>>>>> - I think the spec is too restrictive in saying "Each routing
>> protocol
>>>> instance is connected to exactly one RIB for each address family =
that
>>>> the routing protocol instance supports". We can mix AF and SAF
>> together
>>>> and simply say Address Family (if we make it clear) but with the
>>>> consideration of MT the statement is just not correct.
>>>>=20
>>>> There are currently three possible solutions:
>>>>=20
>>>> 1. Subdivide each address family via identity derivation, e.g. with
>>>> respect to type of service.
>>>>=20
>>>> 2. Distribute routes from the connected RIB selectively to any =
number
>>>> other RIBs via "recipient-rib" mechanism.
>>>>=20
>>>> 3. Augment the "routing-protocol" subtrees with new parameters. For
>>>> example, one could introduce protocol "sub-instances", one for each
>>>> topology, and then different sub-instances could use the same =
address
>>>> family (this is by the way another advantage of having a flat list =
of
>>>> routing protocol instances).
>>>>=20
>>>> In my view, this choice should be sufficient.
>>>=20
>>> How about simply remove that restriction that one protocol instance
>> connects to only one RIB per address family?
>>=20
>> It has other implications: you have to have a way for specifying =
which
>> protocol routes go to which RIB, and also how the RIBs are used in =
the
>> data plane for forwarding packets.
>>=20
>>>=20
>>>>=20
>>>>=20
>>>>>=20
>>>>> I am more concerned with the first point.
>>>>>=20
>>>>> I don't think this is too late. There is still IETF last call and =
I
>> am
>>>> posting my comments here. If there is enough consensus to my =
points,
>>>> then necessary changes need to happen. If not, I'll accept that.
>>>>=20
>>>> The routing-cfg document is already long overdue. We've already had
>>>> several rounds of relatively significant redesigns based on
>> reviewers'
>>>> comments, and I think now it's time to deliver the result. The data
>>>> model may not be perfect and I am open to returning to it after we
>> gain
>>>> some experience, but IMO we first need to fill the gaps by =
developing
>>>> modules for routing protocols, route filters and, of course, =
specific
>>>> types of routing instances.
>>>=20
>>> We're developing protocol modules, and it is during that process =
(for
>> OSPF YANG module) that the issue with "routing-instance" came up. =
It's
>> better to address that in the netmod-routing-cfg spec now than
>> later/separately.
>>=20
>> What is this issue with "routing-instance"? Could you be more =
specific?
>>=20
>> Lada
>>=20
>>>=20
>>> Jeffrey
>>>=20
>>>>=20
>>>> Lada
>>>>=20
>>>>>=20
>>>>> Thanks.
>>>>> Jeffrey
>>>>>=20
>>>>>> -----Original Message-----
>>>>>> From: Ladislav Lhotka [mailto:lhotka@nic.cz]
>>>>>> Sent: Monday, June 23, 2014 4:26 AM
>>>>>> To: Jeffrey (Zhaohui) Zhang; Dean Bogdanovic; netmod@ietf.org
>>>>>> Cc: Derek Man-Kit Yeung (myeung); Kiran Agrahara Sreenivasa
>>>>>> Subject: RE: Questions/comments on draft-ietf-netmod-routing-cfg
>>>>>>=20
>>>>>> "Jeffrey (Zhaohui) Zhang"  writes:
>>>>>>=20
>>>>>>> Lada,
>>>>>>>=20
>>>>>>>> -----Original Message-----
>>>>>>>> From: Ladislav Lhotka [mailto:lhotka@nic.cz]
>>>>>>>> Sent: Friday, June 20, 2014 7:26 AM
>>>>>>>> To: Jeffrey (Zhaohui) Zhang; Dean Bogdanovic; netmod@ietf.org
>>>>>>>> Cc: Derek Man-Kit Yeung (myeung); Kiran Agrahara Sreenivasa
>>>>>>>> Subject: Re: Questions/comments on =
draft-ietf-netmod-routing-cfg
>>>>>>>>=20
>>>>>>>> "Jeffrey (Zhaohui) Zhang"  writes:
>>>>>>>>=20
>>>>>>>>> Ladislav,
>>>>>>>>>=20
>>>>>>>>> Dean and I have some late questions and comments. We came =
across
>>>>>> these
>>>>>>>> while trying to work on the OSPF YANG model.
>>>>>>>>>=20
>>>>>>>>> -----------
>>>>>>>>>=20
>>>>>>>>> The spec mentions in several places something like the =
following:
>>>>>>>>>=20
>>>>>>>>>   Each routing protocol instance is connected to exactly one
>>>> RIB
>>>>>> for
>>>>>>>>>   each address family that the routing protocol instance
>>>> supports.
>>>>>>>>>=20
>>>>>>>>> My understanding is that the address family mentioned above =
does
>>>>>> not
>>>>>>>> include SAFI. Because of that, a routing protocol like BGP may
>>>>>> connect
>>>>>>>> to multiple RIBs in the same family (RIB for unicast and RIB =
for
>>>>>>>> multicast RPF purpose in case of incongruent multicast =
topology)
>>>> so
>>>>>> the
>>>>>>>> above statement is not correct.
>>>>>>>>=20
>>>>>>>> This is quite flexible since address family is defined via
>>>> identities.
>>>>>> I
>>>>>>>> can imagine one implementation using only "ipv4" and "ipv6"
>>>> (defined
>>>>>> in
>>>>>>>> ietf-routing) whilst other implementation could use "ipv[46]-
>>>> unicast"
>>>>>>>> (defined in ietf-ipv[46]-unicast-routing) and =
"ipv[46]-multicast"
>>>> (to
>>>>>> be
>>>>>>>> defined in a module for unicast routing), that means including
>>>> SAFI.
>>>>>>>=20
>>>>>>> Address Family has very specific meanings, typically only refer =
to
>>>>>> IPv4/IPv6 to my understanding. If we want to extend that to =
include
>>>> SAFI,
>>>>>> then the spec must point it out. More below related to MT.
>>>>>>=20
>>>>>> Both Cisco and Juniper docs use terms like "IPv6 multicast =
address
>>>>>> family" or "MCAST-VPN address family" that clearly include SAFI =
as
>>>> well.
>>>>>>=20
>>>>>> For better or worse, in the ietf-routing YANG module "address-
>> family"
>>>>>> leaf is defined with the type
>>>>>>=20
>>>>>>        type identityref {
>>>>>>          base address-family;
>>>>>>        }
>>>>>>=20
>>>>>> so its meaning follows from that, including the fact that the
>>>> identity
>>>>>> is extensible. In my view, it is a feature, not bug.
>>>>>>=20
>>>>>>>=20
>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>> This is also a problem in case of Multi-topology. Each =
topology
>>>> has
>>>>>>>> its own RIB and a protocol instance like OSPF can connect to
>>>> multiple
>>>>>> MT
>>>>>>>> RIBs.
>>>>>>>>=20
>>>>>>>> Two possible solutions come to my mind:
>>>>>>>>=20
>>>>>>>> 1. You could derive new address family identities from "ipv4-
>>>> unicast"
>>>>>>>> etc. so that you can assign a unique address family to multiple
>>>>>> tables.
>>>>>>>>=20
>>>>>>>> 2. You could have one connected RIB e.g. for "ipv4-unicast" and
>>>>>> define
>>>>>>>> two or more RIBs for each topology as recipients of the =
connected
>>>> RIB.
>>>>>>>> So, in effect, the (single) connected RIB contains routes for =
all
>>>>>>>> topologies and these are then split via route filters to the =
per-
>>>>>>>> topology RIBs.
>>>>>>>>=20
>>>>>>>> Does it make sense?
>>>>>>>=20
>>>>>>> Compare the two, I don't like #2 because it adds an unnecessary
>>>>>> indirection. I don't think we want to overload "Address Family"
>>>> further
>>>>>> to include topology either. In many implementations, actual RIBs
>> are
>>>> per
>>>>>> (routing-instance, AFI, SAFI, topology) and it may be extended
>>>> further.
>>>>>> Therefore, the best option is to simply remove the restriction =
that
>>>> one
>>>>>> protocol instance is connected to exactly one RIB per address
>> family.
>>>>>>=20
>>>>>> This restriction is only relevant for the "connected-rib" list. =
If
>>>> you
>>>>>> want, you can add configuration parameters to associate other =
RIBs
>>>>>> directly with a routing protocol instance.
>>>>>>=20
>>>>>> IMO, the common use case for MT are incongruent IPv4 and IPv6
>>>> topologies,
>>>>>> and the core routing data model can handle this directly and =
easily.
>>>>>>=20
>>>>>> Also note that the "routing-cfg" document has already been
>> submitted
>>>> to
>>>>>> IESG for publication, so your comments come really late.
>>>>>>=20
>>>>>>>=20
>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>> ------
>>>>>>>>>=20
>>>>>>>>> 5.1.  Routing Instance
>>>>>>>>>=20
>>>>>>>>>  Each routing instance in the core routing data model
>>>> represents
>>>>>> a
>>>>>>>>>  logical router.  The exact semantics of this term are left to
>>>>>>>>>  implementations.  For example, routing instances may be
>>>>>> completely
>>>>>>>>>  isolated virtual routers or, alternatively, they may
>>>> internally
>>>>>> share
>>>>>>>>>  certain information.
>>>>>>>>>=20
>>>>>>>>>  ...
>>>>>>>>>=20
>>>>>>>>>  An implementation MAY support multiple types of logical
>>>> routers
>>>>>>>>>  simultaneously.  Instances of all routing instance types are
>>>>>>>>>  organized as entries of the same flat "routing-instance" =
list.
>>>>>> In
>>>>>>>>>  order to discriminate routing instances belonging to
>>>> different
>>>>>> types,
>>>>>>>>>  the "type" leaf is defined as a child of the "routing-
>>>> instance"
>>>>>> node.
>>>>>>>>>=20
>>>>>>>>> The spec purposely left it fuzzy as to what a "routing =
instance"
>>>> is.
>>>>>>>> However we definitely should have clear definitions for the =
three
>>>>>> terms
>>>>>>>> mentioned: routing-instance, logical router and virtual router.
>>>>>>>>=20
>>>>>>>> Yes, this is by design open-ended because otherwise we would
>>>> probably
>>>>>>>> never reach consensus on what these terms exactly mean.
>>>>>>>=20
>>>>>>> While the design needs to be open-ended a standard specification
>>>> needs
>>>>>> to be precise and unambiguous. The names can be discussed and
>>>>>> compromised but the meaning must be clear. For example, Cisco
>>>> "virtual
>>>>>> router" and Juniper "logical router/system" are the same but
>> Juniper
>>>>>> "virtual router" and Cisco "VRF-lite" are the same. What does the
>>>>>> "logical router" in this spec mean? We can't just say that "it =
can
>>>> mean
>>>>>> any of those". For example if it means Cisco's "virtual router" =
or
>>>>>> Juniper's "logical system", a further discussion may be - should
>> this
>>>>>> module really cover that.
>>>>>>=20
>>>>>> The term "logical router" is used in a very general sense, and =
the
>>>>>> document clearly says so ("no semantics"). The other terms are =
used
>>>> only
>>>>>> as examples what it could possibly mean, to make the spec more
>>>>>> accessible.
>>>>>>=20
>>>>>>>=20
>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>> Logical router is a very overload term. Today vendors have
>>>>>> virtualized
>>>>>>>> their routing capabilities in the system and provide 3 =
different
>>>>>> levels
>>>>>>>> of routing virtualization. Logical systems, logical routers are
>>>> some
>>>>>> of
>>>>>>>> the names used by vendors and those offer routing and =
management
>>>>>>>> separation. Each logical system has its own routing instances =
and
>>>>>>>> routing instances can have multiple routing tables, so it is =
very
>>>>>>>> important to have very precise definition of what is routing
>>>> instance
>>>>>>>> (and not compare it with logical router)
>>>>>>>>>=20
>>>>>>>>>     identity standard-routing-instance {
>>>>>>>>>       base routing-instance-type;
>>>>>>>>>       description
>>>>>>>>>         "This identity represents a default routing =
instance.";
>>>>>>>>>     }
>>>>>>>>>=20
>>>>>>>>> What is a "standard-routing-instance"? Would "default-routing-
>>>>>>>> instance" be better? "standard" wording leads to "standard vs.
>>>> non-
>>>>>>>> standard" question and hints on that the two are different =
types.
>>>>>>>> "default" vs. "non-default" does not have that (at least to =
me).
>>>>>>>>=20
>>>>>>>> Well, "default" is overloaded, too, and also has a specific
>>>> meaning
>>>>>> in
>>>>>>>> YANG. Standard is supposed to mean plain vanilla router. It is
>>>> just a
>>>>>>>> name.
>>>>>>>=20
>>>>>>> I don't have to split hair between "standard" and "default" but
>> the
>>>>>> spec must point out what a "standard-routing-instance" is - is it
>> the
>>>>>> default/base/master logical-system (Cisco virtual-router) or the
>>>>>> default/base/master "routing-instance" (a "logical-system" would
>>>> include
>>>>>> many "routing-instances" like VRFs).
>>>>>>>=20
>>>>>>=20
>>>>>> I think the ietf-routing module makes it pretty clear:
>>>>>>=20
>>>>>>        leaf type {
>>>>>>          type identityref {
>>>>>>            base routing-instance-type;
>>>>>>          }
>>>>>>          default "rt:standard-routing-instance";
>>>>>>          description
>>>>>>            "The type of the routing instance.";
>>>>>>        }
>>>>>>=20
>>>>>> The purpose of the "type" is to allow for defining a new routing
>>>>>> instance type and augment configuration or state data =
conditionally
>>>> for
>>>>>> that type. The "standard-routing-instance" is just the default
>> value
>>>> to
>>>>>> start from, it has no other meaning.
>>>>>>=20
>>>>>>=20
>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>> Should this spec distinguish VRF/VR/LR and have corresponding
>>>>>>>> identities defined?
>>>>>>>>=20
>>>>>>>> The idea is this will be done in other modules that define data
>>>>>> models
>>>>>>>> for these types of routing instances. Then the =
"routing-instance"
>>>>>>>> container can be augmented with arbitrary data, but =
conditionally
>>>> for
>>>>>>>> that routing instance type.
>>>>>>>=20
>>>>>>> I think it is important to define a few well known routing
>> instance
>>>>>> types in the base spec as a good foundation for other modules.
>>>>>>=20
>>>>>> This is outside the scope of the core routing data model, and
>> should
>>>> be
>>>>>> done by routing experts, not in the NETMOD group. There are other
>>>>>> indispensable elements that have to be worked out before the
>> routing
>>>>>> data model can be really useful, e.g. routing protocols and route
>>>>>> filters.
>>>>>>=20
>>>>>>>=20
>>>>>>>>=20
>>>>>>>> An implementation may actually use multiple routing-instance
>> types
>>>> at
>>>>>>>> the same time.
>>>>>>>=20
>>>>>>> That's for sure and not what I'm concerned with.
>>>>>>>=20
>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>>         leaf type {
>>>>>>>>>           type identityref {
>>>>>>>>>             base routing-instance-type;
>>>>>>>>>           }
>>>>>>>>>           description
>>>>>>>>>             "The routing instance type, primarily intended for
>>>>>>>>>              discriminating among different types of logical
>>>>>> routers,
>>>>>>>>>              route virtualization, master-slave arrangements
>>>> etc.,
>>>>>>>>>              while keeping all routing instances in the same
>>>> flat
>>>>>>>>>              list.";
>>>>>>>>>         }
>>>>>>>>>=20
>>>>>>>>> What is the "master-slave arrangements"?
>>>>>>>>=20
>>>>>>>> This came from an early review by Thomas Morin, it has to do =
with
>>>>>>>> MPLS/BGP VPNs where a master routing-instance exchanges =
selected
>>>>>> routes
>>>>>>>> with each VPN/VRF.
>>>>>>>=20
>>>>>>> Either it needs to be clarified in the spec, or it could simply =
be
>>>>>> removed to avoid confusion since "route virtualization" covers =
that
>>>>>> already.
>>>>>>=20
>>>>>> This is actually a typo - it should be "router virtualization". =
My
>>>>>> understanding of this term is that a virtual router is isolated =
and
>>>>>> exchanges routing information with other routers only through
>> routing
>>>>>> protocols.
>>>>>>=20
>>>>>> Anyway, these are really only examples and I think it is
>> sufficiently
>>>>>> clear that the core routing data model doesn't use these terms =
for
>>>>>> defining any semantics.
>>>>>>=20
>>>>>> Lada
>>>>>>=20
>>>>>>>=20
>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>> Depending on the definition of "logical router" and "route
>>>>>>>> virtualization", there may also be concerns with keeping all
>> those
>>>>>> kinds
>>>>>>>> of in the same flat list.
>>>>>>>>=20
>>>>>>>> It is similar to interfaces, where physical and logical
>> interfaces
>>>> of
>>>>>>>> all kinds live in the same flat list and are distinguished by =
the
>>>>>> type.
>>>>>>>> I think it could work, relationships among the individual =
routing
>>>>>>>> instances can be expressed in other data.
>>>>>>>=20
>>>>>>> I will defer to others about the merits of a flat list, but for =
a
>>>> flat
>>>>>> list, the base spec needs to provide a way to express the
>>>> relationship.
>>>>>>>=20
>>>>>>> Jeffrey
>>>>>>>=20
>>>>>>>>=20
>>>>>>>> Having a single flat list has its advantages, for example you =
can
>>>>>> then
>>>>>>>> easily refer to routing instances via leafrefs (which allow =
only
>>>> one
>>>>>>>> path).
>>>>>>>>=20
>>>>>>>> Cheers, Lada
>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>> Jeffrey Zhang
>>>>>>>>> Dean Bogdanovic
>>>>>>>>=20
>>>>>>>> --
>>>>>>>> Ladislav Lhotka, CZ.NIC Labs
>>>>>>>> PGP Key ID: E74E8C0C
>>>>>>=20
>>>>>> --
>>>>>> Ladislav Lhotka, CZ.NIC Labs
>>>>>> PGP Key ID: E74E8C0C
>>>>=20
>>>> --
>>>> Ladislav Lhotka, CZ.NIC Labs
>>>> PGP Key ID: E74E8C0C
>>=20
>> --
>> Ladislav Lhotka, CZ.NIC Labs
>> PGP Key ID: E74E8C0C
>>=20
>>=20
>>=20
>=20

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





From nobody Mon Jun 23 13:00:37 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 163F71B2C0C for ; Mon, 23 Jun 2014 13:00:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.602
X-Spam-Level: 
X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iO8LZtK-STuf for ; Mon, 23 Jun 2014 13:00:29 -0700 (PDT)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0203.outbound.protection.outlook.com [207.46.163.203]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DCCF1B2B11 for ; Mon, 23 Jun 2014 13:00:29 -0700 (PDT)
Received: from BY2PR05MB079.namprd05.prod.outlook.com (10.242.38.16) by BN1PR05MB422.namprd05.prod.outlook.com (10.141.58.142) with Microsoft SMTP Server (TLS) id 15.0.954.9; Mon, 23 Jun 2014 20:00:21 +0000
Received: from BY2PR05MB079.namprd05.prod.outlook.com ([169.254.8.228]) by BY2PR05MB079.namprd05.prod.outlook.com ([169.254.8.228]) with mapi id 15.00.0969.007; Mon, 23 Jun 2014 20:00:19 +0000
From: "Jeffrey (Zhaohui) Zhang" 
To: Ladislav Lhotka 
Thread-Topic: [netmod] Questions/comments on draft-ietf-netmod-routing-cfg
Thread-Index: Ac+L5mG6QCip6E9wRnWAlQy1vx1YdgAlBfOAAACoQiAAj+tmAAAIpPrQAAReeoAAAeKmAAAFtCqAAAALMUAAAvtfgAAAFSEA
Date: Mon, 23 Jun 2014 20:00:19 +0000
Message-ID: <200d38920939408c9c426339e3fcf3e7@BY2PR05MB079.namprd05.prod.outlook.com>
References:   <18cd777ffb9d4df6b0966dd1b3dd822b@BY2PR05MB079.namprd05.prod.outlook.com>     <45F6E463-82A0-4EF0-9EF7-E4B9D4EE7F80@nic.cz>  <4CC621BD-78B4-4945-91C8-D7FC0921CC91@nic.cz>
In-Reply-To: <4CC621BD-78B4-4945-91C8-D7FC0921CC91@nic.cz>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [66.129.241.13]
x-microsoft-antispam: BL:0; ACTION:Default; RISK:Low; SCL:0; SPMLVL:NotSpam; PCL:0; RULEID:
x-forefront-prvs: 025100C802
x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(428001)(377454003)(189002)(199002)(25584003)(13464003)(24454002)(51704005)(52034003)(79102001)(76176999)(64706001)(101416001)(575784001)(92566001)(86362001)(99396002)(106356001)(77982001)(81542001)(83322001)(31966008)(74316001)(80022001)(54356999)(85306003)(19580395003)(81342001)(85852003)(4396001)(33646001)(105586002)(76482001)(74662001)(77096002)(46102001)(21056001)(76576001)(99286002)(19580405001)(93886003)(66066001)(95666004)(50986999)(20776003)(15975445006)(74502001)(87936001)(2656002)(83072002)(24736002)(106276001)(579004); DIR:OUT; SFP:; SCL:1; SRVR:BN1PR05MB422; H:BY2PR05MB079.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; 
received-spf: None (: juniper.net does not designate permitted sender hosts)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=zzhang@juniper.net; 
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/5QPfzpuB5MFwtPlo5yWvAmxcqg0
Cc: Kiran Agrahara Sreenivasa , "netmod@ietf.org" 
Subject: Re: [netmod] Questions/comments on draft-ietf-netmod-routing-cfg
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 23 Jun 2014 20:00:35 -0000

Lada,

> -----Original Message-----
> From: Ladislav Lhotka [mailto:lhotka@nic.cz]
> Sent: Monday, June 23, 2014 3:43 PM
> To: Jeffrey (Zhaohui) Zhang
> Cc: Alia Atlas; Dean Bogdanovic; netmod@ietf.org; Kiran Agrahara
> Sreenivasa
> Subject: Re: [netmod] Questions/comments on draft-ietf-netmod-routing-
> cfg
>=20
>=20
> On 23 Jun 2014, at 20:59, Jeffrey (Zhaohui) Zhang 
> wrote:
>=20
> > Lada,
> >
> >> Right, but it doesn't mean this more has to be implemented by the
> core
> >> routing model. I think the important point is that such extensions
> are
> >> possible to do in other modules, and I am convinced it is the case
> >
> > While we are trying to work on the OSPF YANG module, which is to base
> on netmod-routing-cfg, some interpret the "routing-instance" in netmod-
> routing-cfg as Juniper's "Logical Router/System" (i.e. Cisco's "Virtual
> Router"), while some others interpret that as Juniper's VRF/VR (i.e.,
> Cisco's VRF/VRF-lite). That difference has a major impact on how OSPF
> YANG module is defined.
>=20
> It is none of the above, and I think the draft is pretty clear about
> this. You can consider the "standard-routing-instance" to represent the
> situation before any logical/virtual routers were introduced, because
> that's what is standardized. It is not the job for the ietf-routing
> module to declare Cisco's virtualization model superior to Juniper's, or
> vice versa.

Nobody is trying to argue which is better. I used this example to show that=
 people from Cisco and Juniper interpreted the "routing-instance" different=
 - a clear sign that the draft is far from "pretty clear".

>=20
> >
> > If netmod-routing-cfg is to allow both the above, it is critical for
> netmod-routing-cfg to be clear what the terms "logical router" and
> "virtual router" mean, and then OSPF YANG module will proceed
> accordingly. It does not make sense to defer that to another document.
>=20
> Why not? The amount of work needed for writing an extra module is pretty
> much the same as for adding it to ietf-routing and, importantly, it is a
> task for routing experts to decide what a standard logical/virtual
> router should be.

The argument is that this spec needs to have that definition, or at least u=
sing examples to illustrate.

>=20
> >
> > There are even people who argue that it is not good to put the above
> two types of routing instances into the same flat list. That's a
> separate topic and I am not trying to open up that discussion here, but
> it shows how important it is for the netmod-routing-cfg to be clear what
> a "routing-instances" is instead of deferring to another document.
>=20
> Those people should explain why it is not good.

I will defer to those; it is fine if they don't speak up, but I mention it =
here to show the importance of having clear definitions.

Jeffrey

>=20
> Lada
>=20
> >
> > Jeffrey
> >
> >> -----Original Message-----
> >> From: Ladislav Lhotka [mailto:lhotka@nic.cz]
> >> Sent: Monday, June 23, 2014 2:16 PM
> >> To: Alia Atlas
> >> Cc: Jeffrey (Zhaohui) Zhang; Dean Bogdanovic; netmod@ietf.org; Kiran
> >> Agrahara Sreenivasa
> >> Subject: Re: [netmod] Questions/comments on draft-ietf-netmod-
> routing-
> >> cfg
> >>
> >> Hi Alia,
> >>
> >> On 23 Jun 2014, at 17:32, Alia Atlas  wrote:
> >>
> >>> Lada,
> >>>
> >>> On Mon, Jun 23, 2014 at 10:38 AM, Ladislav Lhotka 
> >> wrote:
> >>> "Jeffrey (Zhaohui) Zhang"  writes:
> >>>
> >>>> Lada,
> >>>>
> >>>> The discussions basically boil down to two main points:
> >>>>
> >>>> - I believe the spec should have well defined semantics for some
> >> well-known types of "routing-instances". Otherwise it is too loose to
> be
> >> the foundation for future work (e.g. the on-going OSPF YANG model
> work).
> >> That does not prevent the flexibility for future extensions.
> >>>
> >>> The OSPF (and more recent ISIS) module can work just fine with
> >> "standard-routing-instance". On smaller router platforms (OpenWRT
> with
> >> Quagga or BIRD daemons) this is all that's needed. I don't know why
> >> specific routing instance types couldn't be defined in separate
> modules.
> >>>
> >>>
> >>> Supporting very common features (L3VPNs, logical routers, multiple
> >> routing instances) can
> >>> make routers significantly more complex than Quagga supports.  While
> >> Quagga certainly has some useful features, I do not think it has kept
> >> pace.  What is needed for routing is more.
> >>
> >> Right, but it doesn't mean this more has to be implemented by the
> core
> >> routing model. I think the important point is that such extensions
> are
> >> possible to do in other modules, and I am convinced it is the case.
> >>
> >>
> >>>
> >>>>
> >>>> - I think the spec is too restrictive in saying "Each routing
> >> protocol instance is connected to exactly one RIB for each address
> >> family that the routing protocol instance supports". We can mix AF
> and
> >> SAF together and simply say Address Family (if we make it clear) but
> >> with the consideration of MT the statement is just not correct.
> >>>
> >>> There are currently three possible solutions:
> >>>
> >>> 1. Subdivide each address family via identity derivation, e.g. with
> >> respect to type of service.
> >>>
> >>> 2. Distribute routes from the connected RIB selectively to any
> number
> >> other RIBs via "recipient-rib" mechanism.
> >>>
> >>> 3. Augment the "routing-protocol" subtrees with new parameters. For
> >> example, one could introduce protocol "sub-instances", one for each
> >> topology, and then different sub-instances could use the same address
> >> family (this is by the way another advantage of having a flat list of
> >> routing protocol instances).
> >>>
> >>> In my view, this choice should be sufficient.
> >>>
> >>>
> >>>>
> >>>> I am more concerned with the first point.
> >>>>
> >>>> I don't think this is too late. There is still IETF last call and I
> >> am posting my comments here. If there is enough consensus to my
> points,
> >> then necessary changes need to happen. If not, I'll accept that.
> >>>
> >>> The routing-cfg document is already long overdue. We've already had
> >> several rounds of relatively significant redesigns based on
> reviewers'
> >> comments, and I think now it's time to deliver the result. The data
> >> model may not be perfect and I am open to returning to it after we
> gain
> >> some experience, but IMO we first need to fill the gaps by developing
> >> modules for routing protocols, route filters and, of course, specific
> >> types of routing instances.
> >>>
> >>> Jeffrey is coming in, trying to work on an OSPF YANG model, as a
> >> routing person very familiar with one implementation.  If this draft
> is
> >> not a sufficient base on which to build the other routing models, how
> >> should we proceed?  I have requested yet another routing directorate
> >> review on this draft; I'd expect that review before the upcoming IETF.
> >>
> >> Yes, it is really challenging to combine YANG expertise (as YANG is a
> >> relatively new data modelling language) with domain-specific know-how.
> >> FWIW, I wrote an OSPF module for the BIRD daemon that perhaps may be
> >> used for comparison:
> >>
> >> https://gitlab.labs.nic.cz/labs/yang-tools/blob/master/data-
> >> models/bird/bird-ospf.yang
> >>
> >> Lada
> >>
> >>>
> >>> I can appreciate the frustration in the time it is taking to get
> this
> >> draft done.  Cross-area review does frequently happen after WGLC.
> >>>
> >>> Alia
> >>>
> >>> Lada
> >>>
> >>>>
> >>>> Thanks.
> >>>> Jeffrey
> >>>>
> >>>>> -----Original Message-----
> >>>>> From: Ladislav Lhotka [mailto:lhotka@nic.cz]
> >>>>> Sent: Monday, June 23, 2014 4:26 AM
> >>>>> To: Jeffrey (Zhaohui) Zhang; Dean Bogdanovic; netmod@ietf.org
> >>>>> Cc: Derek Man-Kit Yeung (myeung); Kiran Agrahara Sreenivasa
> >>>>> Subject: RE: Questions/comments on draft-ietf-netmod-routing-cfg
> >>>>>
> >>>>> "Jeffrey (Zhaohui) Zhang"  writes:
> >>>>>
> >>>>>> Lada,
> >>>>>>
> >>>>>>> -----Original Message-----
> >>>>>>> From: Ladislav Lhotka [mailto:lhotka@nic.cz]
> >>>>>>> Sent: Friday, June 20, 2014 7:26 AM
> >>>>>>> To: Jeffrey (Zhaohui) Zhang; Dean Bogdanovic; netmod@ietf.org
> >>>>>>> Cc: Derek Man-Kit Yeung (myeung); Kiran Agrahara Sreenivasa
> >>>>>>> Subject: Re: Questions/comments on draft-ietf-netmod-routing-cfg
> >>>>>>>
> >>>>>>> "Jeffrey (Zhaohui) Zhang"  writes:
> >>>>>>>
> >>>>>>>> Ladislav,
> >>>>>>>>
> >>>>>>>> Dean and I have some late questions and comments. We came
> >> across
> >>>>> these
> >>>>>>> while trying to work on the OSPF YANG model.
> >>>>>>>>
> >>>>>>>> -----------
> >>>>>>>>
> >>>>>>>> The spec mentions in several places something like the
> >> following:
> >>>>>>>>
> >>>>>>>>   Each routing protocol instance is connected to exactly one
> >> RIB
> >>>>> for
> >>>>>>>>   each address family that the routing protocol instance
> >> supports.
> >>>>>>>>
> >>>>>>>> My understanding is that the address family mentioned above
> >> does
> >>>>> not
> >>>>>>> include SAFI. Because of that, a routing protocol like BGP may
> >>>>> connect
> >>>>>>> to multiple RIBs in the same family (RIB for unicast and RIB for
> >>>>>>> multicast RPF purpose in case of incongruent multicast topology)
> >> so
> >>>>> the
> >>>>>>> above statement is not correct.
> >>>>>>>
> >>>>>>> This is quite flexible since address family is defined via
> >> identities.
> >>>>> I
> >>>>>>> can imagine one implementation using only "ipv4" and "ipv6"
> >> (defined
> >>>>> in
> >>>>>>> ietf-routing) whilst other implementation could use "ipv[46]-
> >> unicast"
> >>>>>>> (defined in ietf-ipv[46]-unicast-routing) and "ipv[46]-
> >> multicast" (to
> >>>>> be
> >>>>>>> defined in a module for unicast routing), that means including
> >> SAFI.
> >>>>>>
> >>>>>> Address Family has very specific meanings, typically only refer
> >> to
> >>>>> IPv4/IPv6 to my understanding. If we want to extend that to
> include
> >> SAFI,
> >>>>> then the spec must point it out. More below related to MT.
> >>>>>
> >>>>> Both Cisco and Juniper docs use terms like "IPv6 multicast address
> >>>>> family" or "MCAST-VPN address family" that clearly include SAFI as
> >> well.
> >>>>>
> >>>>> For better or worse, in the ietf-routing YANG module "address-
> >> family"
> >>>>> leaf is defined with the type
> >>>>>
> >>>>>         type identityref {
> >>>>>           base address-family;
> >>>>>         }
> >>>>>
> >>>>> so its meaning follows from that, including the fact that the
> >> identity
> >>>>> is extensible. In my view, it is a feature, not bug.
> >>>>>
> >>>>>>
> >>>>>>>
> >>>>>>>>
> >>>>>>>> This is also a problem in case of Multi-topology. Each
> >> topology has
> >>>>>>> its own RIB and a protocol instance like OSPF can connect to
> >> multiple
> >>>>> MT
> >>>>>>> RIBs.
> >>>>>>>
> >>>>>>> Two possible solutions come to my mind:
> >>>>>>>
> >>>>>>> 1. You could derive new address family identities from "ipv4-
> >> unicast"
> >>>>>>> etc. so that you can assign a unique address family to multiple
> >>>>> tables.
> >>>>>>>
> >>>>>>> 2. You could have one connected RIB e.g. for "ipv4-unicast" and
> >>>>> define
> >>>>>>> two or more RIBs for each topology as recipients of the
> >> connected RIB.
> >>>>>>> So, in effect, the (single) connected RIB contains routes for
> >> all
> >>>>>>> topologies and these are then split via route filters to the
> >> per-
> >>>>>>> topology RIBs.
> >>>>>>>
> >>>>>>> Does it make sense?
> >>>>>>
> >>>>>> Compare the two, I don't like #2 because it adds an unnecessary
> >>>>> indirection. I don't think we want to overload "Address Family"
> >> further
> >>>>> to include topology either. In many implementations, actual RIBs
> >> are per
> >>>>> (routing-instance, AFI, SAFI, topology) and it may be extended
> >> further.
> >>>>> Therefore, the best option is to simply remove the restriction
> that
> >> one
> >>>>> protocol instance is connected to exactly one RIB per address
> >> family.
> >>>>>
> >>>>> This restriction is only relevant for the "connected-rib" list. If
> >> you
> >>>>> want, you can add configuration parameters to associate other RIBs
> >>>>> directly with a routing protocol instance.
> >>>>>
> >>>>> IMO, the common use case for MT are incongruent IPv4 and IPv6
> >> topologies,
> >>>>> and the core routing data model can handle this directly and
> easily.
> >>>>>
> >>>>> Also note that the "routing-cfg" document has already been
> >> submitted to
> >>>>> IESG for publication, so your comments come really late.
> >>>>>
> >>>>>>
> >>>>>>>
> >>>>>>>>
> >>>>>>>> ------
> >>>>>>>>
> >>>>>>>> 5.1.  Routing Instance
> >>>>>>>>
> >>>>>>>>   Each routing instance in the core routing data model
> >> represents
> >>>>> a
> >>>>>>>>   logical router.  The exact semantics of this term are left
> >> to
> >>>>>>>>   implementations.  For example, routing instances may be
> >>>>> completely
> >>>>>>>>   isolated virtual routers or, alternatively, they may
> >> internally
> >>>>> share
> >>>>>>>>   certain information.
> >>>>>>>>
> >>>>>>>>   ...
> >>>>>>>>
> >>>>>>>>   An implementation MAY support multiple types of logical
> >> routers
> >>>>>>>>   simultaneously.  Instances of all routing instance types
> >> are
> >>>>>>>>   organized as entries of the same flat "routing-instance"
> >> list.
> >>>>> In
> >>>>>>>>   order to discriminate routing instances belonging to
> >> different
> >>>>> types,
> >>>>>>>>   the "type" leaf is defined as a child of the "routing-
> >> instance"
> >>>>> node.
> >>>>>>>>
> >>>>>>>> The spec purposely left it fuzzy as to what a "routing
> >> instance" is.
> >>>>>>> However we definitely should have clear definitions for the
> >> three
> >>>>> terms
> >>>>>>> mentioned: routing-instance, logical router and virtual router.
> >>>>>>>
> >>>>>>> Yes, this is by design open-ended because otherwise we would
> >> probably
> >>>>>>> never reach consensus on what these terms exactly mean.
> >>>>>>
> >>>>>> While the design needs to be open-ended a standard specification
> >> needs
> >>>>> to be precise and unambiguous. The names can be discussed and
> >>>>> compromised but the meaning must be clear. For example, Cisco
> >> "virtual
> >>>>> router" and Juniper "logical router/system" are the same but
> >> Juniper
> >>>>> "virtual router" and Cisco "VRF-lite" are the same. What does the
> >>>>> "logical router" in this spec mean? We can't just say that "it can
> >> mean
> >>>>> any of those". For example if it means Cisco's "virtual router" or
> >>>>> Juniper's "logical system", a further discussion may be - should
> >> this
> >>>>> module really cover that.
> >>>>>
> >>>>> The term "logical router" is used in a very general sense, and the
> >>>>> document clearly says so ("no semantics"). The other terms are
> used
> >> only
> >>>>> as examples what it could possibly mean, to make the spec more
> >>>>> accessible.
> >>>>>
> >>>>>>
> >>>>>>>
> >>>>>>>>
> >>>>>>>> Logical router is a very overload term. Today vendors have
> >>>>> virtualized
> >>>>>>> their routing capabilities in the system and provide 3 different
> >>>>> levels
> >>>>>>> of routing virtualization. Logical systems, logical routers are
> >> some
> >>>>> of
> >>>>>>> the names used by vendors and those offer routing and management
> >>>>>>> separation. Each logical system has its own routing instances
> >> and
> >>>>>>> routing instances can have multiple routing tables, so it is
> >> very
> >>>>>>> important to have very precise definition of what is routing
> >> instance
> >>>>>>> (and not compare it with logical router)
> >>>>>>>>
> >>>>>>>>     identity standard-routing-instance {
> >>>>>>>>       base routing-instance-type;
> >>>>>>>>       description
> >>>>>>>>         "This identity represents a default routing
> >> instance.";
> >>>>>>>>     }
> >>>>>>>>
> >>>>>>>> What is a "standard-routing-instance"? Would "default-routing-
> >>>>>>> instance" be better? "standard" wording leads to "standard vs.
> >> non-
> >>>>>>> standard" question and hints on that the two are different types.
> >>>>>>> "default" vs. "non-default" does not have that (at least to me).
> >>>>>>>
> >>>>>>> Well, "default" is overloaded, too, and also has a specific
> >> meaning
> >>>>> in
> >>>>>>> YANG. Standard is supposed to mean plain vanilla router. It is
> >> just a
> >>>>>>> name.
> >>>>>>
> >>>>>> I don't have to split hair between "standard" and "default" but
> >> the
> >>>>> spec must point out what a "standard-routing-instance" is - is it
> >> the
> >>>>> default/base/master logical-system (Cisco virtual-router) or the
> >>>>> default/base/master "routing-instance" (a "logical-system" would
> >> include
> >>>>> many "routing-instances" like VRFs).
> >>>>>>
> >>>>>
> >>>>> I think the ietf-routing module makes it pretty clear:
> >>>>>
> >>>>>         leaf type {
> >>>>>           type identityref {
> >>>>>             base routing-instance-type;
> >>>>>           }
> >>>>>           default "rt:standard-routing-instance";
> >>>>>           description
> >>>>>             "The type of the routing instance.";
> >>>>>         }
> >>>>>
> >>>>> The purpose of the "type" is to allow for defining a new routing
> >>>>> instance type and augment configuration or state data
> conditionally
> >> for
> >>>>> that type. The "standard-routing-instance" is just the default
> >> value to
> >>>>> start from, it has no other meaning.
> >>>>>
> >>>>>
> >>>>>>>
> >>>>>>>>
> >>>>>>>> Should this spec distinguish VRF/VR/LR and have corresponding
> >>>>>>> identities defined?
> >>>>>>>
> >>>>>>> The idea is this will be done in other modules that define data
> >>>>> models
> >>>>>>> for these types of routing instances. Then the "routing-
> >> instance"
> >>>>>>> container can be augmented with arbitrary data, but
> >> conditionally for
> >>>>>>> that routing instance type.
> >>>>>>
> >>>>>> I think it is important to define a few well known routing
> >> instance
> >>>>> types in the base spec as a good foundation for other modules.
> >>>>>
> >>>>> This is outside the scope of the core routing data model, and
> >> should be
> >>>>> done by routing experts, not in the NETMOD group. There are other
> >>>>> indispensable elements that have to be worked out before the
> >> routing
> >>>>> data model can be really useful, e.g. routing protocols and route
> >>>>> filters.
> >>>>>
> >>>>>>
> >>>>>>>
> >>>>>>> An implementation may actually use multiple routing-instance
> >> types at
> >>>>>>> the same time.
> >>>>>>
> >>>>>> That's for sure and not what I'm concerned with.
> >>>>>>
> >>>>>>>
> >>>>>>>>
> >>>>>>>>         leaf type {
> >>>>>>>>           type identityref {
> >>>>>>>>             base routing-instance-type;
> >>>>>>>>           }
> >>>>>>>>           description
> >>>>>>>>             "The routing instance type, primarily intended
> >> for
> >>>>>>>>              discriminating among different types of logical
> >>>>> routers,
> >>>>>>>>              route virtualization, master-slave arrangements
> >> etc.,
> >>>>>>>>              while keeping all routing instances in the same
> >> flat
> >>>>>>>>              list.";
> >>>>>>>>         }
> >>>>>>>>
> >>>>>>>> What is the "master-slave arrangements"?
> >>>>>>>
> >>>>>>> This came from an early review by Thomas Morin, it has to do
> >> with
> >>>>>>> MPLS/BGP VPNs where a master routing-instance exchanges selected
> >>>>> routes
> >>>>>>> with each VPN/VRF.
> >>>>>>
> >>>>>> Either it needs to be clarified in the spec, or it could simply
> >> be
> >>>>> removed to avoid confusion since "route virtualization" covers
> that
> >>>>> already.
> >>>>>
> >>>>> This is actually a typo - it should be "router virtualization". My
> >>>>> understanding of this term is that a virtual router is isolated
> and
> >>>>> exchanges routing information with other routers only through
> >> routing
> >>>>> protocols.
> >>>>>
> >>>>> Anyway, these are really only examples and I think it is
> >> sufficiently
> >>>>> clear that the core routing data model doesn't use these terms for
> >>>>> defining any semantics.
> >>>>>
> >>>>> Lada
> >>>>>
> >>>>>>
> >>>>>>>
> >>>>>>>>
> >>>>>>>> Depending on the definition of "logical router" and "route
> >>>>>>> virtualization", there may also be concerns with keeping all
> >> those
> >>>>> kinds
> >>>>>>> of in the same flat list.
> >>>>>>>
> >>>>>>> It is similar to interfaces, where physical and logical
> >> interfaces of
> >>>>>>> all kinds live in the same flat list and are distinguished by
> >> the
> >>>>> type.
> >>>>>>> I think it could work, relationships among the individual
> >> routing
> >>>>>>> instances can be expressed in other data.
> >>>>>>
> >>>>>> I will defer to others about the merits of a flat list, but for a
> >> flat
> >>>>> list, the base spec needs to provide a way to express the
> >> relationship.
> >>>>>>
> >>>>>> Jeffrey
> >>>>>>
> >>>>>>>
> >>>>>>> Having a single flat list has its advantages, for example you
> >> can
> >>>>> then
> >>>>>>> easily refer to routing instances via leafrefs (which allow only
> >> one
> >>>>>>> path).
> >>>>>>>
> >>>>>>> Cheers, Lada
> >>>>>>>
> >>>>>>>>
> >>>>>>>> Jeffrey Zhang
> >>>>>>>> Dean Bogdanovic
> >>>>>>>
> >>>>>>> --
> >>>>>>> Ladislav Lhotka, CZ.NIC Labs
> >>>>>>> PGP Key ID: E74E8C0C
> >>>>>
> >>>>> --
> >>>>> Ladislav Lhotka, CZ.NIC Labs
> >>>>> PGP Key ID: E74E8C0C
> >>>
> >>> --
> >>> Ladislav Lhotka, CZ.NIC Labs
> >>> PGP Key ID: E74E8C0C
> >>>
> >>> _______________________________________________
> >>> netmod mailing list
> >>> netmod@ietf.org
> >>> https://www.ietf.org/mailman/listinfo/netmod
> >>>
> >>
> >> --
> >> Ladislav Lhotka, CZ.NIC Labs
> >> PGP Key ID: E74E8C0C
> >>
> >>
> >>
> >
>=20
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>=20
>=20
>=20


From nobody Mon Jun 23 13:02:52 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9401D1B2B1D for ; Mon, 23 Jun 2014 13:02:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.302
X-Spam-Level: 
X-Spam-Status: No, score=-1.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RP_MATCHES_RCVD=-0.651] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ajeqkHH_i4QK for ; Mon, 23 Jun 2014 13:02:47 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4028B1A0389 for ; Mon, 23 Jun 2014 13:02:47 -0700 (PDT)
Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 6884513FCDE; Mon, 23 Jun 2014 22:02:45 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1403553765; bh=QFwt2wgs/bNO8LmavYLICF1fpSVI07+Xbw1l3E7Blso=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=KJ9MKQXfyZlhwPZKPXw/+1HBMxucnYrNja/gu0TJxaLtr3q+Y5eUQj5UHGmem6siM NtElXz5zpNbOJZ4lV5pBkjWctw1/TdG3baKMTjSWu0hRbYcO9zeKNl3G0smPlrGZNs bNmHIUqwwRib6JxZfYoZPAbwOL4QnO6KG0KzugpQ=
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
From: Ladislav Lhotka 
In-Reply-To: <7917CA6C-86CD-4B4C-B308-98E4D0B364F5@juniper.net>
Date: Mon, 23 Jun 2014 22:02:44 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <90156A1B-A619-445B-8603-B62CC681AC91@nic.cz>
References:   <18cd777ffb9d4df6b0966dd1b3dd822b@BY2PR05MB079.namprd05.prod.outlook.com>     <7917CA6C-86CD-4B4C-B308-98E4D0B364F5@juniper.net>
To: Dean Bogdanovic 
X-Mailer: Apple Mail (2.1878.2)
X-Virus-Scanned: clamav-milter 0.98.1 at mail
X-Virus-Status: Clean
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/DcX9bIwBMB5MjLx6u_HT0qAHaCc
Cc: "Jeffrey \(Zhaohui\) Zhang" , Kiran Agrahara Sreenivasa , "netmod@ietf.org" 
Subject: Re: [netmod] Questions/comments on draft-ietf-netmod-routing-cfg
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 23 Jun 2014 20:02:49 -0000

On 23 Jun 2014, at 21:34, Dean Bogdanovic  wrote:

>=20
> On Jun 23, 2014, at 2:43 PM, Ladislav Lhotka  wrote:
>=20
>>=20
>> On 23 Jun 2014, at 16:42, Dean Bogdanovic  wrote:
>>=20
>>> Lada,
>>>=20
>>> Semantics has to be precise, otherwise it can be very differently =
reinterpreted and then standards becomes not useful.
>>>=20
>>> My take on this is we need a two abstractions
>>> 1. routing table - which is a container of routes
>>=20
>> This is called RIB in the ietf-routing module, after the terminology =
has been harmonized with the I2RS RIB info model.
>>=20
>>> and
>>> 2. container of routing tables - this container has to have a =
precise name
>>=20
>> I am not sure I understand - in the ietf-routing module, this =
container does have a precise name: =93ribs=94, i.e., every routing =
instance can use multiple RIBs.
> so based on your sentence routing instance is a container of RIBs?
>=20
>>=20
>>>=20
>>> If the 2. container name is not well specified and IMO, it is not in =
your draft, it will be hard to use your draft as foundation. Right now =
your definition allows free definition of container of routing tables =
and container of containers of routing tables. We don't need a =
definition of container of containers of routing tables. If we can come =
to agreement for the above two, that would be great.
>>=20
>> But routing instances are (among other things) exactly these =
containers of containers of RIBs, but IMO the various types of routing =
instances so far have been pretty much vendor-specific, even though =
there are some de facto standards. It would be great if these thing are =
standardised in the IETF, and corresponding YANG modules written.
>>=20
> here you are saying that routing instance is container of container of =
RIBs, which is one abstraction too many, based on your previous  =
sentence

Each routing instance defines a flat list of RIBs available to it, but =
these RIBs are divided into subsets (or rather dependency graphs) =
through the mechanisms of connected RIBs and recipient RIBs.

Lada

>=20
>>>=20
>>>=20
>>> The document is with IESG, but there is still possibility to bring =
DISCUSS and COMMENT items
>>> http://tools.ietf.org/html/rfc4858#section-3.3
>>=20
>> It sure is.
>>=20
>> Lada
>>=20
>>>=20
>>>=20
>>> On Jun 23, 2014, at 8:59 AM, Jeffrey (Zhaohui) Zhang =
 wrote:
>>>=20
>>>> Lada,
>>>>=20
>>>> The discussions basically boil down to two main points:
>>>>=20
>>>> - I believe the spec should have well defined semantics for some =
well-known types of "routing-instances". Otherwise it is too loose to be =
the foundation for future work (e.g. the on-going OSPF YANG model work). =
That does not prevent the flexibility for future extensions.
>>>=20
>>> I agree with this one very strongly.=20
>>>>=20
>>>> - I think the spec is too restrictive in saying "Each routing =
protocol instance is connected to exactly one RIB for each address =
family that the routing protocol instance supports". We can mix AF and =
SAF together and simply say Address Family (if we make it clear) but =
with the consideration of MT the statement is just not correct.
>>>>=20
>>>> I am more concerned with the first point.
>>>>=20
>>>> I don't think this is too late. There is still IETF last call and I =
am posting my comments here. If there is enough consensus to my points, =
then necessary changes need to happen. If not, I'll accept that.
>>>>=20
>>>> Thanks.
>>>> Jeffrey
>>>>=20
>>>>> -----Original Message-----
>>>>> From: Ladislav Lhotka [mailto:lhotka@nic.cz]
>>>>> Sent: Monday, June 23, 2014 4:26 AM
>>>>> To: Jeffrey (Zhaohui) Zhang; Dean Bogdanovic; netmod@ietf.org
>>>>> Cc: Derek Man-Kit Yeung (myeung); Kiran Agrahara Sreenivasa
>>>>> Subject: RE: Questions/comments on draft-ietf-netmod-routing-cfg
>>>>>=20
>>>>> "Jeffrey (Zhaohui) Zhang"  writes:
>>>>>=20
>>>>>> Lada,
>>>>>>=20
>>>>>>> -----Original Message-----
>>>>>>> From: Ladislav Lhotka [mailto:lhotka@nic.cz]
>>>>>>> Sent: Friday, June 20, 2014 7:26 AM
>>>>>>> To: Jeffrey (Zhaohui) Zhang; Dean Bogdanovic; netmod@ietf.org
>>>>>>> Cc: Derek Man-Kit Yeung (myeung); Kiran Agrahara Sreenivasa
>>>>>>> Subject: Re: Questions/comments on draft-ietf-netmod-routing-cfg
>>>>>>>=20
>>>>>>> "Jeffrey (Zhaohui) Zhang"  writes:
>>>>>>>=20
>>>>>>>> Ladislav,
>>>>>>>>=20
>>>>>>>> Dean and I have some late questions and comments. We came =
across
>>>>> these
>>>>>>> while trying to work on the OSPF YANG model.
>>>>>>>>=20
>>>>>>>> -----------
>>>>>>>>=20
>>>>>>>> The spec mentions in several places something like the =
following:
>>>>>>>>=20
>>>>>>>>  Each routing protocol instance is connected to exactly one RIB
>>>>> for
>>>>>>>>  each address family that the routing protocol instance =
supports.
>>>>>>>>=20
>>>>>>>> My understanding is that the address family mentioned above =
does
>>>>> not
>>>>>>> include SAFI. Because of that, a routing protocol like BGP may
>>>>> connect
>>>>>>> to multiple RIBs in the same family (RIB for unicast and RIB for
>>>>>>> multicast RPF purpose in case of incongruent multicast topology) =
so
>>>>> the
>>>>>>> above statement is not correct.
>>>>>>>=20
>>>>>>> This is quite flexible since address family is defined via =
identities.
>>>>> I
>>>>>>> can imagine one implementation using only "ipv4" and "ipv6" =
(defined
>>>>> in
>>>>>>> ietf-routing) whilst other implementation could use =
"ipv[46]-unicast"
>>>>>>> (defined in ietf-ipv[46]-unicast-routing) and =
"ipv[46]-multicast" (to
>>>>> be
>>>>>>> defined in a module for unicast routing), that means including =
SAFI.
>>>>>>=20
>>>>>> Address Family has very specific meanings, typically only refer =
to
>>>>> IPv4/IPv6 to my understanding. If we want to extend that to =
include SAFI,
>>>>> then the spec must point it out. More below related to MT.
>>>>>=20
>>>>> Both Cisco and Juniper docs use terms like "IPv6 multicast address
>>>>> family" or "MCAST-VPN address family" that clearly include SAFI as =
well.
>>>>>=20
>>>>> For better or worse, in the ietf-routing YANG module =
"address-family"
>>>>> leaf is defined with the type
>>>>>=20
>>>>>       type identityref {
>>>>>         base address-family;
>>>>>       }
>>>>>=20
>>>>> so its meaning follows from that, including the fact that the =
identity
>>>>> is extensible. In my view, it is a feature, not bug.
>>>>>=20
>>>>>>=20
>>>>>>>=20
>>>>>>>>=20
>>>>>>>> This is also a problem in case of Multi-topology. Each topology =
has
>>>>>>> its own RIB and a protocol instance like OSPF can connect to =
multiple
>>>>> MT
>>>>>>> RIBs.
>>>>>>>=20
>>>>>>> Two possible solutions come to my mind:
>>>>>>>=20
>>>>>>> 1. You could derive new address family identities from =
"ipv4-unicast"
>>>>>>> etc. so that you can assign a unique address family to multiple
>>>>> tables.
>>>>>>>=20
>>>>>>> 2. You could have one connected RIB e.g. for "ipv4-unicast" and
>>>>> define
>>>>>>> two or more RIBs for each topology as recipients of the =
connected RIB.
>>>>>>> So, in effect, the (single) connected RIB contains routes for =
all
>>>>>>> topologies and these are then split via route filters to the =
per-
>>>>>>> topology RIBs.
>>>>>>>=20
>>>>>>> Does it make sense?
>>>>>>=20
>>>>>> Compare the two, I don't like #2 because it adds an unnecessary
>>>>> indirection. I don't think we want to overload "Address Family" =
further
>>>>> to include topology either. In many implementations, actual RIBs =
are per
>>>>> (routing-instance, AFI, SAFI, topology) and it may be extended =
further.
>>>>> Therefore, the best option is to simply remove the restriction =
that one
>>>>> protocol instance is connected to exactly one RIB per address =
family.
>>>>>=20
>>>>> This restriction is only relevant for the "connected-rib" list. If =
you
>>>>> want, you can add configuration parameters to associate other RIBs
>>>>> directly with a routing protocol instance.
>>>>>=20
>>>>> IMO, the common use case for MT are incongruent IPv4 and IPv6 =
topologies,
>>>>> and the core routing data model can handle this directly and =
easily.
>>>>>=20
>>>>> Also note that the "routing-cfg" document has already been =
submitted to
>>>>> IESG for publication, so your comments come really late.
>>>>>=20
>>>>>>=20
>>>>>>>=20
>>>>>>>>=20
>>>>>>>> ------
>>>>>>>>=20
>>>>>>>> 5.1.  Routing Instance
>>>>>>>>=20
>>>>>>>> Each routing instance in the core routing data model represents
>>>>> a
>>>>>>>> logical router.  The exact semantics of this term are left to
>>>>>>>> implementations.  For example, routing instances may be
>>>>> completely
>>>>>>>> isolated virtual routers or, alternatively, they may internally
>>>>> share
>>>>>>>> certain information.
>>>>>>>>=20
>>>>>>>> ...
>>>>>>>>=20
>>>>>>>> An implementation MAY support multiple types of logical routers
>>>>>>>> simultaneously.  Instances of all routing instance types are
>>>>>>>> organized as entries of the same flat "routing-instance" list.
>>>>> In
>>>>>>>> order to discriminate routing instances belonging to different
>>>>> types,
>>>>>>>> the "type" leaf is defined as a child of the "routing-instance"
>>>>> node.
>>>>>>>>=20
>>>>>>>> The spec purposely left it fuzzy as to what a "routing =
instance" is.
>>>>>>> However we definitely should have clear definitions for the =
three
>>>>> terms
>>>>>>> mentioned: routing-instance, logical router and virtual router.
>>>>>>>=20
>>>>>>> Yes, this is by design open-ended because otherwise we would =
probably
>>>>>>> never reach consensus on what these terms exactly mean.
>>>>>>=20
>>>>>> While the design needs to be open-ended a standard specification =
needs
>>>>> to be precise and unambiguous. The names can be discussed and
>>>>> compromised but the meaning must be clear. For example, Cisco =
"virtual
>>>>> router" and Juniper "logical router/system" are the same but =
Juniper
>>>>> "virtual router" and Cisco "VRF-lite" are the same. What does the
>>>>> "logical router" in this spec mean? We can't just say that "it can =
mean
>>>>> any of those". For example if it means Cisco's "virtual router" or
>>>>> Juniper's "logical system", a further discussion may be - should =
this
>>>>> module really cover that.
>>>>>=20
>>>>> The term "logical router" is used in a very general sense, and the
>>>>> document clearly says so ("no semantics"). The other terms are =
used only
>>>>> as examples what it could possibly mean, to make the spec more
>>>>> accessible.
>>>>>=20
>>>>>>=20
>>>>>>>=20
>>>>>>>>=20
>>>>>>>> Logical router is a very overload term. Today vendors have
>>>>> virtualized
>>>>>>> their routing capabilities in the system and provide 3 different
>>>>> levels
>>>>>>> of routing virtualization. Logical systems, logical routers are =
some
>>>>> of
>>>>>>> the names used by vendors and those offer routing and management
>>>>>>> separation. Each logical system has its own routing instances =
and
>>>>>>> routing instances can have multiple routing tables, so it is =
very
>>>>>>> important to have very precise definition of what is routing =
instance
>>>>>>> (and not compare it with logical router)
>>>>>>>>=20
>>>>>>>>    identity standard-routing-instance {
>>>>>>>>      base routing-instance-type;
>>>>>>>>      description
>>>>>>>>        "This identity represents a default routing instance.";
>>>>>>>>    }
>>>>>>>>=20
>>>>>>>> What is a "standard-routing-instance"? Would "default-routing-
>>>>>>> instance" be better? "standard" wording leads to "standard vs. =
non-
>>>>>>> standard" question and hints on that the two are different =
types.
>>>>>>> "default" vs. "non-default" does not have that (at least to me).
>>>>>>>=20
>>>>>>> Well, "default" is overloaded, too, and also has a specific =
meaning
>>>>> in
>>>>>>> YANG. Standard is supposed to mean plain vanilla router. It is =
just a
>>>>>>> name.
>>>>>>=20
>>>>>> I don't have to split hair between "standard" and "default" but =
the
>>>>> spec must point out what a "standard-routing-instance" is - is it =
the
>>>>> default/base/master logical-system (Cisco virtual-router) or the
>>>>> default/base/master "routing-instance" (a "logical-system" would =
include
>>>>> many "routing-instances" like VRFs).
>>>>>>=20
>>>>>=20
>>>>> I think the ietf-routing module makes it pretty clear:
>>>>>=20
>>>>>       leaf type {
>>>>>         type identityref {
>>>>>           base routing-instance-type;
>>>>>         }
>>>>>         default "rt:standard-routing-instance";
>>>>>         description
>>>>>           "The type of the routing instance.";
>>>>>       }
>>>>>=20
>>>>> The purpose of the "type" is to allow for defining a new routing
>>>>> instance type and augment configuration or state data =
conditionally for
>>>>> that type. The "standard-routing-instance" is just the default =
value to
>>>>> start from, it has no other meaning.
>>>>>=20
>>>>>=20
>>>>>>>=20
>>>>>>>>=20
>>>>>>>> Should this spec distinguish VRF/VR/LR and have corresponding
>>>>>>> identities defined?
>>>>>>>=20
>>>>>>> The idea is this will be done in other modules that define data
>>>>> models
>>>>>>> for these types of routing instances. Then the =
"routing-instance"
>>>>>>> container can be augmented with arbitrary data, but =
conditionally for
>>>>>>> that routing instance type.
>>>>>>=20
>>>>>> I think it is important to define a few well known routing =
instance
>>>>> types in the base spec as a good foundation for other modules.
>>>>>=20
>>>>> This is outside the scope of the core routing data model, and =
should be
>>>>> done by routing experts, not in the NETMOD group. There are other
>>>>> indispensable elements that have to be worked out before the =
routing
>>>>> data model can be really useful, e.g. routing protocols and route
>>>>> filters.
>>>>>=20
>>>>>>=20
>>>>>>>=20
>>>>>>> An implementation may actually use multiple routing-instance =
types at
>>>>>>> the same time.
>>>>>>=20
>>>>>> That's for sure and not what I'm concerned with.
>>>>>>=20
>>>>>>>=20
>>>>>>>>=20
>>>>>>>>        leaf type {
>>>>>>>>          type identityref {
>>>>>>>>            base routing-instance-type;
>>>>>>>>          }
>>>>>>>>          description
>>>>>>>>            "The routing instance type, primarily intended for
>>>>>>>>             discriminating among different types of logical
>>>>> routers,
>>>>>>>>             route virtualization, master-slave arrangements =
etc.,
>>>>>>>>             while keeping all routing instances in the same =
flat
>>>>>>>>             list.";
>>>>>>>>        }
>>>>>>>>=20
>>>>>>>> What is the "master-slave arrangements"?
>>>>>>>=20
>>>>>>> This came from an early review by Thomas Morin, it has to do =
with
>>>>>>> MPLS/BGP VPNs where a master routing-instance exchanges selected
>>>>> routes
>>>>>>> with each VPN/VRF.
>>>>>>=20
>>>>>> Either it needs to be clarified in the spec, or it could simply =
be
>>>>> removed to avoid confusion since "route virtualization" covers =
that
>>>>> already.
>>>>>=20
>>>>> This is actually a typo - it should be "router virtualization". My
>>>>> understanding of this term is that a virtual router is isolated =
and
>>>>> exchanges routing information with other routers only through =
routing
>>>>> protocols.
>>>>>=20
>>>>> Anyway, these are really only examples and I think it is =
sufficiently
>>>>> clear that the core routing data model doesn't use these terms for
>>>>> defining any semantics.
>>>>>=20
>>>>> Lada
>>>>>=20
>>>>>>=20
>>>>>>>=20
>>>>>>>>=20
>>>>>>>> Depending on the definition of "logical router" and "route
>>>>>>> virtualization", there may also be concerns with keeping all =
those
>>>>> kinds
>>>>>>> of in the same flat list.
>>>>>>>=20
>>>>>>> It is similar to interfaces, where physical and logical =
interfaces of
>>>>>>> all kinds live in the same flat list and are distinguished by =
the
>>>>> type.
>>>>>>> I think it could work, relationships among the individual =
routing
>>>>>>> instances can be expressed in other data.
>>>>>>=20
>>>>>> I will defer to others about the merits of a flat list, but for a =
flat
>>>>> list, the base spec needs to provide a way to express the =
relationship.
>>>>>>=20
>>>>>> Jeffrey
>>>>>>=20
>>>>>>>=20
>>>>>>> Having a single flat list has its advantages, for example you =
can
>>>>> then
>>>>>>> easily refer to routing instances via leafrefs (which allow only =
one
>>>>>>> path).
>>>>>>>=20
>>>>>>> Cheers, Lada
>>>>>>>=20
>>>>>>>>=20
>>>>>>>> Jeffrey Zhang
>>>>>>>> Dean Bogdanovic
>>>>>>>=20
>>>>>>> --
>>>>>>> Ladislav Lhotka, CZ.NIC Labs
>>>>>>> PGP Key ID: E74E8C0C
>>>>>=20
>>>>> --
>>>>> Ladislav Lhotka, CZ.NIC Labs
>>>>> PGP Key ID: E74E8C0C
>>>=20
>>=20
>> --
>> Ladislav Lhotka, CZ.NIC Labs
>> PGP Key ID: E74E8C0C

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





From nobody Mon Jun 23 13:03:42 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50FE71A0308 for ; Mon, 23 Jun 2014 13:03:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.602
X-Spam-Level: 
X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tux0hHssq35M for ; Mon, 23 Jun 2014 13:03:22 -0700 (PDT)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0235.outbound.protection.outlook.com [207.46.163.235]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60EF31B2B77 for ; Mon, 23 Jun 2014 13:03:22 -0700 (PDT)
Received: from BY2PR05MB079.namprd05.prod.outlook.com (10.242.38.16) by BY2PR05MB078.namprd05.prod.outlook.com (10.242.38.12) with Microsoft SMTP Server (TLS) id 15.0.969.15; Mon, 23 Jun 2014 20:03:20 +0000
Received: from BY2PR05MB079.namprd05.prod.outlook.com ([169.254.8.228]) by BY2PR05MB079.namprd05.prod.outlook.com ([169.254.8.228]) with mapi id 15.00.0969.007; Mon, 23 Jun 2014 20:03:19 +0000
From: "Jeffrey (Zhaohui) Zhang" 
To: Ladislav Lhotka 
Thread-Topic: [netmod] Questions/comments on draft-ietf-netmod-routing-cfg
Thread-Index: Ac+L5mG6QCip6E9wRnWAlQy1vx1YdgAlBfOAAACoQiAAj+tmAAAIpPrQAAReeoAAASpEcAAGqHOAAAFOUKAAAgZ7AAAAHc+w
Date: Mon, 23 Jun 2014 20:03:19 +0000
Message-ID: 
References:   <18cd777ffb9d4df6b0966dd1b3dd822b@BY2PR05MB079.namprd05.prod.outlook.com>     <89F86AF6-9114-47B2-888F-FD50CA4BA887@nic.cz>  <6E5BA386-4803-44BF-98DA-81A6673C85B3@nic.cz>
In-Reply-To: <6E5BA386-4803-44BF-98DA-81A6673C85B3@nic.cz>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [66.129.241.13]
x-microsoft-antispam: BCL:0;PCL:0;RULEID:
x-forefront-prvs: 025100C802
x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(428001)(199002)(189002)(24454002)(52034003)(377454003)(25584003)(13464003)(51704005)(66066001)(101416001)(50986999)(80022001)(19580395003)(85306003)(79102001)(21056001)(87936001)(81342001)(2656002)(54356999)(64706001)(76576001)(33646001)(76176999)(20776003)(81542001)(4396001)(93886003)(99286002)(77096002)(74316001)(95666004)(92566001)(31966008)(19580405001)(83072002)(83322001)(99396002)(77982001)(106356001)(74502001)(85852003)(105586002)(86362001)(76482001)(46102001)(575784001)(74662001)(24736002)(106276001)(579004); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR05MB078; H:BY2PR05MB079.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; 
received-spf: None (: juniper.net does not designate permitted sender hosts)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=zzhang@juniper.net; 
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/5mxXDP7BhI3E7f10Z7kQtKfmlXI
Cc: NETMOD Working Group 
Subject: Re: [netmod] Questions/comments on draft-ietf-netmod-routing-cfg
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 23 Jun 2014 20:03:33 -0000

Lada,

> -----Original Message-----
> From: Ladislav Lhotka [mailto:lhotka@nic.cz]
> Sent: Monday, June 23, 2014 3:58 PM
> To: Jeffrey (Zhaohui) Zhang
> Cc: NETMOD Working Group
> Subject: Re: [netmod] Questions/comments on draft-ietf-netmod-routing-
> cfg
>=20
>=20
> On 23 Jun 2014, at 21:05, Jeffrey (Zhaohui) Zhang 
> wrote:
>=20
> > Lada,
> >
> >>> How about simply remove that restriction that one protocol instance
> >> connects to only one RIB per address family?
> >>
> >> It has other implications: you have to have a way for specifying which
> >> protocol routes go to which RIB, and also how the RIBs are used in the
> >> data plane for forwarding packets.
> >
> > I am just saying to remove the restriction that one protocol instance
> only connects to one rib per family. It does not change anything else
> like what you are saying above.
>=20
> I don't agree. If two different RIBs for, e.g., ipv4-unicast are
> connected to a routing protocol instance, then in which RIB the IPv4
> unicast routes learned by that protocol instance are supposed to appear?

That's what could deferred to an extension module :-)

>=20
> >
> >> What is this issue with "routing-instance"? Could you be more specific=
?
> >
> > Please see my previous email that I just sent.
>=20
> I don't know where the logical/virtual router type comes into play in
> the OSPF module. They certainly don't in the ISIS module.

We can include you in OSPF YANG discussions. I will also review the ISIS mo=
dule.

Jeffrey

>=20
> Lada
>=20
> >
> > Jeffrey
> >
> >> -----Original Message-----
> >> From: Ladislav Lhotka [mailto:lhotka@nic.cz]
> >> Sent: Monday, June 23, 2014 2:23 PM
> >> To: Jeffrey (Zhaohui) Zhang
> >> Subject: Re: [netmod] Questions/comments on draft-ietf-netmod-
> routing-
> >> cfg
> >>
> >>
> >> On 23 Jun 2014, at 17:12, Jeffrey (Zhaohui) Zhang 
> >> wrote:
> >>
> >>> Lada,
> >>>
> >>>> -----Original Message-----
> >>>> From: Ladislav Lhotka [mailto:lhotka@nic.cz]
> >>>> Sent: Monday, June 23, 2014 10:39 AM
> >>>> To: Jeffrey (Zhaohui) Zhang; Dean Bogdanovic; netmod@ietf.org
> >>>> Cc: Kiran Agrahara Sreenivasa
> >>>> Subject: Re: [netmod] Questions/comments on draft-ietf-netmod-
> >> routing-
> >>>> cfg
> >>>>
> >>>> "Jeffrey (Zhaohui) Zhang"  writes:
> >>>>
> >>>>> Lada,
> >>>>>
> >>>>> The discussions basically boil down to two main points:
> >>>>>
> >>>>> - I believe the spec should have well defined semantics for some
> >> well-
> >>>> known types of "routing-instances". Otherwise it is too loose to be
> >> the
> >>>> foundation for future work (e.g. the on-going OSPF YANG model work).
> >>>> That does not prevent the flexibility for future extensions.
> >>>>
> >>>> The OSPF (and more recent ISIS) module can work just fine with
> >>>> "standard-routing-instance". On smaller router platforms (OpenWRT
> >> with
> >>>> Quagga or BIRD daemons) this is all that's needed. I don't know why
> >>>> specific routing instance types couldn't be defined in separate
> >> modules.
> >>>>
> >>>>>
> >>>>> - I think the spec is too restrictive in saying "Each routing
> >> protocol
> >>>> instance is connected to exactly one RIB for each address family
> that
> >>>> the routing protocol instance supports". We can mix AF and SAF
> >> together
> >>>> and simply say Address Family (if we make it clear) but with the
> >>>> consideration of MT the statement is just not correct.
> >>>>
> >>>> There are currently three possible solutions:
> >>>>
> >>>> 1. Subdivide each address family via identity derivation, e.g. with
> >>>> respect to type of service.
> >>>>
> >>>> 2. Distribute routes from the connected RIB selectively to any
> number
> >>>> other RIBs via "recipient-rib" mechanism.
> >>>>
> >>>> 3. Augment the "routing-protocol" subtrees with new parameters. For
> >>>> example, one could introduce protocol "sub-instances", one for each
> >>>> topology, and then different sub-instances could use the same
> address
> >>>> family (this is by the way another advantage of having a flat list
> of
> >>>> routing protocol instances).
> >>>>
> >>>> In my view, this choice should be sufficient.
> >>>
> >>> How about simply remove that restriction that one protocol instance
> >> connects to only one RIB per address family?
> >>
> >> It has other implications: you have to have a way for specifying
> which
> >> protocol routes go to which RIB, and also how the RIBs are used in
> the
> >> data plane for forwarding packets.
> >>
> >>>
> >>>>
> >>>>
> >>>>>
> >>>>> I am more concerned with the first point.
> >>>>>
> >>>>> I don't think this is too late. There is still IETF last call and
> I
> >> am
> >>>> posting my comments here. If there is enough consensus to my points,
> >>>> then necessary changes need to happen. If not, I'll accept that.
> >>>>
> >>>> The routing-cfg document is already long overdue. We've already had
> >>>> several rounds of relatively significant redesigns based on
> >> reviewers'
> >>>> comments, and I think now it's time to deliver the result. The data
> >>>> model may not be perfect and I am open to returning to it after we
> >> gain
> >>>> some experience, but IMO we first need to fill the gaps by
> developing
> >>>> modules for routing protocols, route filters and, of course,
> specific
> >>>> types of routing instances.
> >>>
> >>> We're developing protocol modules, and it is during that process
> (for
> >> OSPF YANG module) that the issue with "routing-instance" came up.
> It's
> >> better to address that in the netmod-routing-cfg spec now than
> >> later/separately.
> >>
> >> What is this issue with "routing-instance"? Could you be more
> specific?
> >>
> >> Lada
> >>
> >>>
> >>> Jeffrey
> >>>
> >>>>
> >>>> Lada
> >>>>
> >>>>>
> >>>>> Thanks.
> >>>>> Jeffrey
> >>>>>
> >>>>>> -----Original Message-----
> >>>>>> From: Ladislav Lhotka [mailto:lhotka@nic.cz]
> >>>>>> Sent: Monday, June 23, 2014 4:26 AM
> >>>>>> To: Jeffrey (Zhaohui) Zhang; Dean Bogdanovic; netmod@ietf.org
> >>>>>> Cc: Derek Man-Kit Yeung (myeung); Kiran Agrahara Sreenivasa
> >>>>>> Subject: RE: Questions/comments on draft-ietf-netmod-routing-cfg
> >>>>>>
> >>>>>> "Jeffrey (Zhaohui) Zhang"  writes:
> >>>>>>
> >>>>>>> Lada,
> >>>>>>>
> >>>>>>>> -----Original Message-----
> >>>>>>>> From: Ladislav Lhotka [mailto:lhotka@nic.cz]
> >>>>>>>> Sent: Friday, June 20, 2014 7:26 AM
> >>>>>>>> To: Jeffrey (Zhaohui) Zhang; Dean Bogdanovic; netmod@ietf.org
> >>>>>>>> Cc: Derek Man-Kit Yeung (myeung); Kiran Agrahara Sreenivasa
> >>>>>>>> Subject: Re: Questions/comments on draft-ietf-netmod-routing-
> cfg
> >>>>>>>>
> >>>>>>>> "Jeffrey (Zhaohui) Zhang"  writes:
> >>>>>>>>
> >>>>>>>>> Ladislav,
> >>>>>>>>>
> >>>>>>>>> Dean and I have some late questions and comments. We came
> across
> >>>>>> these
> >>>>>>>> while trying to work on the OSPF YANG model.
> >>>>>>>>>
> >>>>>>>>> -----------
> >>>>>>>>>
> >>>>>>>>> The spec mentions in several places something like the
> following:
> >>>>>>>>>
> >>>>>>>>>   Each routing protocol instance is connected to exactly one
> >>>> RIB
> >>>>>> for
> >>>>>>>>>   each address family that the routing protocol instance
> >>>> supports.
> >>>>>>>>>
> >>>>>>>>> My understanding is that the address family mentioned above
> does
> >>>>>> not
> >>>>>>>> include SAFI. Because of that, a routing protocol like BGP may
> >>>>>> connect
> >>>>>>>> to multiple RIBs in the same family (RIB for unicast and RIB
> for
> >>>>>>>> multicast RPF purpose in case of incongruent multicast topology)
> >>>> so
> >>>>>> the
> >>>>>>>> above statement is not correct.
> >>>>>>>>
> >>>>>>>> This is quite flexible since address family is defined via
> >>>> identities.
> >>>>>> I
> >>>>>>>> can imagine one implementation using only "ipv4" and "ipv6"
> >>>> (defined
> >>>>>> in
> >>>>>>>> ietf-routing) whilst other implementation could use "ipv[46]-
> >>>> unicast"
> >>>>>>>> (defined in ietf-ipv[46]-unicast-routing) and "ipv[46]-
> multicast"
> >>>> (to
> >>>>>> be
> >>>>>>>> defined in a module for unicast routing), that means including
> >>>> SAFI.
> >>>>>>>
> >>>>>>> Address Family has very specific meanings, typically only refer
> to
> >>>>>> IPv4/IPv6 to my understanding. If we want to extend that to
> include
> >>>> SAFI,
> >>>>>> then the spec must point it out. More below related to MT.
> >>>>>>
> >>>>>> Both Cisco and Juniper docs use terms like "IPv6 multicast
> address
> >>>>>> family" or "MCAST-VPN address family" that clearly include SAFI
> as
> >>>> well.
> >>>>>>
> >>>>>> For better or worse, in the ietf-routing YANG module "address-
> >> family"
> >>>>>> leaf is defined with the type
> >>>>>>
> >>>>>>        type identityref {
> >>>>>>          base address-family;
> >>>>>>        }
> >>>>>>
> >>>>>> so its meaning follows from that, including the fact that the
> >>>> identity
> >>>>>> is extensible. In my view, it is a feature, not bug.
> >>>>>>
> >>>>>>>
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>> This is also a problem in case of Multi-topology. Each
> topology
> >>>> has
> >>>>>>>> its own RIB and a protocol instance like OSPF can connect to
> >>>> multiple
> >>>>>> MT
> >>>>>>>> RIBs.
> >>>>>>>>
> >>>>>>>> Two possible solutions come to my mind:
> >>>>>>>>
> >>>>>>>> 1. You could derive new address family identities from "ipv4-
> >>>> unicast"
> >>>>>>>> etc. so that you can assign a unique address family to multiple
> >>>>>> tables.
> >>>>>>>>
> >>>>>>>> 2. You could have one connected RIB e.g. for "ipv4-unicast" and
> >>>>>> define
> >>>>>>>> two or more RIBs for each topology as recipients of the
> connected
> >>>> RIB.
> >>>>>>>> So, in effect, the (single) connected RIB contains routes for
> all
> >>>>>>>> topologies and these are then split via route filters to the
> per-
> >>>>>>>> topology RIBs.
> >>>>>>>>
> >>>>>>>> Does it make sense?
> >>>>>>>
> >>>>>>> Compare the two, I don't like #2 because it adds an unnecessary
> >>>>>> indirection. I don't think we want to overload "Address Family"
> >>>> further
> >>>>>> to include topology either. In many implementations, actual RIBs
> >> are
> >>>> per
> >>>>>> (routing-instance, AFI, SAFI, topology) and it may be extended
> >>>> further.
> >>>>>> Therefore, the best option is to simply remove the restriction
> that
> >>>> one
> >>>>>> protocol instance is connected to exactly one RIB per address
> >> family.
> >>>>>>
> >>>>>> This restriction is only relevant for the "connected-rib" list.
> If
> >>>> you
> >>>>>> want, you can add configuration parameters to associate other
> RIBs
> >>>>>> directly with a routing protocol instance.
> >>>>>>
> >>>>>> IMO, the common use case for MT are incongruent IPv4 and IPv6
> >>>> topologies,
> >>>>>> and the core routing data model can handle this directly and
> easily.
> >>>>>>
> >>>>>> Also note that the "routing-cfg" document has already been
> >> submitted
> >>>> to
> >>>>>> IESG for publication, so your comments come really late.
> >>>>>>
> >>>>>>>
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>> ------
> >>>>>>>>>
> >>>>>>>>> 5.1.  Routing Instance
> >>>>>>>>>
> >>>>>>>>>  Each routing instance in the core routing data model
> >>>> represents
> >>>>>> a
> >>>>>>>>>  logical router.  The exact semantics of this term are left to
> >>>>>>>>>  implementations.  For example, routing instances may be
> >>>>>> completely
> >>>>>>>>>  isolated virtual routers or, alternatively, they may
> >>>> internally
> >>>>>> share
> >>>>>>>>>  certain information.
> >>>>>>>>>
> >>>>>>>>>  ...
> >>>>>>>>>
> >>>>>>>>>  An implementation MAY support multiple types of logical
> >>>> routers
> >>>>>>>>>  simultaneously.  Instances of all routing instance types are
> >>>>>>>>>  organized as entries of the same flat "routing-instance" list.
> >>>>>> In
> >>>>>>>>>  order to discriminate routing instances belonging to
> >>>> different
> >>>>>> types,
> >>>>>>>>>  the "type" leaf is defined as a child of the "routing-
> >>>> instance"
> >>>>>> node.
> >>>>>>>>>
> >>>>>>>>> The spec purposely left it fuzzy as to what a "routing
> instance"
> >>>> is.
> >>>>>>>> However we definitely should have clear definitions for the
> three
> >>>>>> terms
> >>>>>>>> mentioned: routing-instance, logical router and virtual router.
> >>>>>>>>
> >>>>>>>> Yes, this is by design open-ended because otherwise we would
> >>>> probably
> >>>>>>>> never reach consensus on what these terms exactly mean.
> >>>>>>>
> >>>>>>> While the design needs to be open-ended a standard specification
> >>>> needs
> >>>>>> to be precise and unambiguous. The names can be discussed and
> >>>>>> compromised but the meaning must be clear. For example, Cisco
> >>>> "virtual
> >>>>>> router" and Juniper "logical router/system" are the same but
> >> Juniper
> >>>>>> "virtual router" and Cisco "VRF-lite" are the same. What does the
> >>>>>> "logical router" in this spec mean? We can't just say that "it
> can
> >>>> mean
> >>>>>> any of those". For example if it means Cisco's "virtual router"
> or
> >>>>>> Juniper's "logical system", a further discussion may be - should
> >> this
> >>>>>> module really cover that.
> >>>>>>
> >>>>>> The term "logical router" is used in a very general sense, and
> the
> >>>>>> document clearly says so ("no semantics"). The other terms are
> used
> >>>> only
> >>>>>> as examples what it could possibly mean, to make the spec more
> >>>>>> accessible.
> >>>>>>
> >>>>>>>
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Logical router is a very overload term. Today vendors have
> >>>>>> virtualized
> >>>>>>>> their routing capabilities in the system and provide 3
> different
> >>>>>> levels
> >>>>>>>> of routing virtualization. Logical systems, logical routers are
> >>>> some
> >>>>>> of
> >>>>>>>> the names used by vendors and those offer routing and
> management
> >>>>>>>> separation. Each logical system has its own routing instances
> and
> >>>>>>>> routing instances can have multiple routing tables, so it is
> very
> >>>>>>>> important to have very precise definition of what is routing
> >>>> instance
> >>>>>>>> (and not compare it with logical router)
> >>>>>>>>>
> >>>>>>>>>     identity standard-routing-instance {
> >>>>>>>>>       base routing-instance-type;
> >>>>>>>>>       description
> >>>>>>>>>         "This identity represents a default routing instance.";
> >>>>>>>>>     }
> >>>>>>>>>
> >>>>>>>>> What is a "standard-routing-instance"? Would "default-routing-
> >>>>>>>> instance" be better? "standard" wording leads to "standard vs.
> >>>> non-
> >>>>>>>> standard" question and hints on that the two are different
> types.
> >>>>>>>> "default" vs. "non-default" does not have that (at least to me).
> >>>>>>>>
> >>>>>>>> Well, "default" is overloaded, too, and also has a specific
> >>>> meaning
> >>>>>> in
> >>>>>>>> YANG. Standard is supposed to mean plain vanilla router. It is
> >>>> just a
> >>>>>>>> name.
> >>>>>>>
> >>>>>>> I don't have to split hair between "standard" and "default" but
> >> the
> >>>>>> spec must point out what a "standard-routing-instance" is - is it
> >> the
> >>>>>> default/base/master logical-system (Cisco virtual-router) or the
> >>>>>> default/base/master "routing-instance" (a "logical-system" would
> >>>> include
> >>>>>> many "routing-instances" like VRFs).
> >>>>>>>
> >>>>>>
> >>>>>> I think the ietf-routing module makes it pretty clear:
> >>>>>>
> >>>>>>        leaf type {
> >>>>>>          type identityref {
> >>>>>>            base routing-instance-type;
> >>>>>>          }
> >>>>>>          default "rt:standard-routing-instance";
> >>>>>>          description
> >>>>>>            "The type of the routing instance.";
> >>>>>>        }
> >>>>>>
> >>>>>> The purpose of the "type" is to allow for defining a new routing
> >>>>>> instance type and augment configuration or state data
> conditionally
> >>>> for
> >>>>>> that type. The "standard-routing-instance" is just the default
> >> value
> >>>> to
> >>>>>> start from, it has no other meaning.
> >>>>>>
> >>>>>>
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Should this spec distinguish VRF/VR/LR and have corresponding
> >>>>>>>> identities defined?
> >>>>>>>>
> >>>>>>>> The idea is this will be done in other modules that define data
> >>>>>> models
> >>>>>>>> for these types of routing instances. Then the "routing-
> instance"
> >>>>>>>> container can be augmented with arbitrary data, but
> conditionally
> >>>> for
> >>>>>>>> that routing instance type.
> >>>>>>>
> >>>>>>> I think it is important to define a few well known routing
> >> instance
> >>>>>> types in the base spec as a good foundation for other modules.
> >>>>>>
> >>>>>> This is outside the scope of the core routing data model, and
> >> should
> >>>> be
> >>>>>> done by routing experts, not in the NETMOD group. There are other
> >>>>>> indispensable elements that have to be worked out before the
> >> routing
> >>>>>> data model can be really useful, e.g. routing protocols and route
> >>>>>> filters.
> >>>>>>
> >>>>>>>
> >>>>>>>>
> >>>>>>>> An implementation may actually use multiple routing-instance
> >> types
> >>>> at
> >>>>>>>> the same time.
> >>>>>>>
> >>>>>>> That's for sure and not what I'm concerned with.
> >>>>>>>
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>>         leaf type {
> >>>>>>>>>           type identityref {
> >>>>>>>>>             base routing-instance-type;
> >>>>>>>>>           }
> >>>>>>>>>           description
> >>>>>>>>>             "The routing instance type, primarily intended for
> >>>>>>>>>              discriminating among different types of logical
> >>>>>> routers,
> >>>>>>>>>              route virtualization, master-slave arrangements
> >>>> etc.,
> >>>>>>>>>              while keeping all routing instances in the same
> >>>> flat
> >>>>>>>>>              list.";
> >>>>>>>>>         }
> >>>>>>>>>
> >>>>>>>>> What is the "master-slave arrangements"?
> >>>>>>>>
> >>>>>>>> This came from an early review by Thomas Morin, it has to do
> with
> >>>>>>>> MPLS/BGP VPNs where a master routing-instance exchanges
> selected
> >>>>>> routes
> >>>>>>>> with each VPN/VRF.
> >>>>>>>
> >>>>>>> Either it needs to be clarified in the spec, or it could simply
> be
> >>>>>> removed to avoid confusion since "route virtualization" covers
> that
> >>>>>> already.
> >>>>>>
> >>>>>> This is actually a typo - it should be "router virtualization".
> My
> >>>>>> understanding of this term is that a virtual router is isolated
> and
> >>>>>> exchanges routing information with other routers only through
> >> routing
> >>>>>> protocols.
> >>>>>>
> >>>>>> Anyway, these are really only examples and I think it is
> >> sufficiently
> >>>>>> clear that the core routing data model doesn't use these terms
> for
> >>>>>> defining any semantics.
> >>>>>>
> >>>>>> Lada
> >>>>>>
> >>>>>>>
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Depending on the definition of "logical router" and "route
> >>>>>>>> virtualization", there may also be concerns with keeping all
> >> those
> >>>>>> kinds
> >>>>>>>> of in the same flat list.
> >>>>>>>>
> >>>>>>>> It is similar to interfaces, where physical and logical
> >> interfaces
> >>>> of
> >>>>>>>> all kinds live in the same flat list and are distinguished by
> the
> >>>>>> type.
> >>>>>>>> I think it could work, relationships among the individual
> routing
> >>>>>>>> instances can be expressed in other data.
> >>>>>>>
> >>>>>>> I will defer to others about the merits of a flat list, but for
> a
> >>>> flat
> >>>>>> list, the base spec needs to provide a way to express the
> >>>> relationship.
> >>>>>>>
> >>>>>>> Jeffrey
> >>>>>>>
> >>>>>>>>
> >>>>>>>> Having a single flat list has its advantages, for example you
> can
> >>>>>> then
> >>>>>>>> easily refer to routing instances via leafrefs (which allow
> only
> >>>> one
> >>>>>>>> path).
> >>>>>>>>
> >>>>>>>> Cheers, Lada
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Jeffrey Zhang
> >>>>>>>>> Dean Bogdanovic
> >>>>>>>>
> >>>>>>>> --
> >>>>>>>> Ladislav Lhotka, CZ.NIC Labs
> >>>>>>>> PGP Key ID: E74E8C0C
> >>>>>>
> >>>>>> --
> >>>>>> Ladislav Lhotka, CZ.NIC Labs
> >>>>>> PGP Key ID: E74E8C0C
> >>>>
> >>>> --
> >>>> Ladislav Lhotka, CZ.NIC Labs
> >>>> PGP Key ID: E74E8C0C
> >>
> >> --
> >> Ladislav Lhotka, CZ.NIC Labs
> >> PGP Key ID: E74E8C0C
> >>
> >>
> >>
> >
>=20
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>=20
>=20
>=20


From nobody Mon Jun 23 13:35:09 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E31BF1B2973 for ; Mon, 23 Jun 2014 13:35:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.302
X-Spam-Level: 
X-Spam-Status: No, score=-1.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RP_MATCHES_RCVD=-0.651] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jY7CnEHWa2Tw for ; Mon, 23 Jun 2014 13:35:03 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23F961B28FE for ; Mon, 23 Jun 2014 13:35:02 -0700 (PDT)
Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 0B68D13FCDE; Mon, 23 Jun 2014 22:34:59 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1403555700; bh=tXuL4MJ/AvyFlLneUe/ZZ2v3gglUpoprP2yOytKKLmw=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=dDfiPEWpRvLYWzEABNYJMpeg0+VXoEjnN+VEuGnGTDmvux8qIdlZE4PCWAJuiNuzE ls4ie0eVigO12lHz1nrs/eJhmBlc2GO1cB97EGRDDA9zzFWk1cxVPs8xduR7JQfmfh YessT9GZiXtsjsU4WfFF7vuGiVo7ffjamHkZIHVM=
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
From: Ladislav Lhotka 
In-Reply-To: <200d38920939408c9c426339e3fcf3e7@BY2PR05MB079.namprd05.prod.outlook.com>
Date: Mon, 23 Jun 2014 22:34:59 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <3E7175EC-B8B4-4306-8715-F50249FE4C8C@nic.cz>
References:   <18cd777ffb9d4df6b0966dd1b3dd822b@BY2PR05MB079.namprd05.prod.outlook.com>     <45F6E463-82A0-4EF0-9EF7-E4B9D4EE7F80@nic.cz>  <4CC621BD-78B4-4945-91C8-D7FC0921CC91@nic.cz> <200d38920939408c9c426339e3fcf3e7@BY2PR05MB079.namprd05.prod.outlook.com>
To: "Jeffrey (Zhaohui) Zhang" 
X-Mailer: Apple Mail (2.1878.2)
X-Virus-Scanned: clamav-milter 0.98.1 at mail
X-Virus-Status: Clean
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/Tt1dvxOO8WQ4D-SMF4vyudjULqw
Cc: Kiran Agrahara Sreenivasa , "netmod@ietf.org" 
Subject: Re: [netmod] Questions/comments on draft-ietf-netmod-routing-cfg
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 23 Jun 2014 20:35:09 -0000

On 23 Jun 2014, at 22:00, Jeffrey (Zhaohui) Zhang  =
wrote:

> Lada,
>=20
>> -----Original Message-----
>> From: Ladislav Lhotka [mailto:lhotka@nic.cz]
>> Sent: Monday, June 23, 2014 3:43 PM
>> To: Jeffrey (Zhaohui) Zhang
>> Cc: Alia Atlas; Dean Bogdanovic; netmod@ietf.org; Kiran Agrahara
>> Sreenivasa
>> Subject: Re: [netmod] Questions/comments on =
draft-ietf-netmod-routing-
>> cfg
>>=20
>>=20
>> On 23 Jun 2014, at 20:59, Jeffrey (Zhaohui) Zhang =

>> wrote:
>>=20
>>> Lada,
>>>=20
>>>> Right, but it doesn't mean this more has to be implemented by the
>> core
>>>> routing model. I think the important point is that such extensions
>> are
>>>> possible to do in other modules, and I am convinced it is the case
>>>=20
>>> While we are trying to work on the OSPF YANG module, which is to =
base
>> on netmod-routing-cfg, some interpret the "routing-instance" in =
netmod-
>> routing-cfg as Juniper's "Logical Router/System" (i.e. Cisco's =
"Virtual
>> Router"), while some others interpret that as Juniper's VRF/VR (i.e.,
>> Cisco's VRF/VRF-lite). That difference has a major impact on how OSPF
>> YANG module is defined.
>>=20
>> It is none of the above, and I think the draft is pretty clear about
>> this. You can consider the "standard-routing-instance" to represent =
the
>> situation before any logical/virtual routers were introduced, because
>> that's what is standardized. It is not the job for the ietf-routing
>> module to declare Cisco's virtualization model superior to Juniper's, =
or
>> vice versa.
>=20
> Nobody is trying to argue which is better. I used this example to show =
that people from Cisco and Juniper interpreted the "routing-instance" =
different - a clear sign that the draft is far from "pretty clear=94.

So which virtualization model do you want the ietf-routing module to =
adopt? I guess VMware people would have yet another idea of what a =
virtual router is.

I would actually expect Cisco and Juniper to either
- write proprietary YANG modules describing the semantic of their own =
routing instances, or
- find an agreement and propose a type for an IETF standard. =20

>=20
>>=20
>>>=20
>>> If netmod-routing-cfg is to allow both the above, it is critical for
>> netmod-routing-cfg to be clear what the terms "logical router" and
>> "virtual router" mean, and then OSPF YANG module will proceed
>> accordingly. It does not make sense to defer that to another =
document.
>>=20
>> Why not? The amount of work needed for writing an extra module is =
pretty
>> much the same as for adding it to ietf-routing and, importantly, it =
is a
>> task for routing experts to decide what a standard logical/virtual
>> router should be.
>=20
> The argument is that this spec needs to have that definition, or at =
least using examples to illustrate.

The spec only defines the =93standard-routing-instance=94, which has =
nothing to do with logical/virtual routers. The =93routing-instance=94 =
list (which was added in later stages of the module development) =
provides a mechanism for defining various routing instance types, =
nothing more.

Lada


>=20
>>=20
>>>=20
>>> There are even people who argue that it is not good to put the above
>> two types of routing instances into the same flat list. That's a
>> separate topic and I am not trying to open up that discussion here, =
but
>> it shows how important it is for the netmod-routing-cfg to be clear =
what
>> a "routing-instances" is instead of deferring to another document.
>>=20
>> Those people should explain why it is not good.
>=20
> I will defer to those; it is fine if they don't speak up, but I =
mention it here to show the importance of having clear definitions.
>=20
> Jeffrey
>=20
>>=20
>> Lada
>>=20
>>>=20
>>> Jeffrey
>>>=20
>>>> -----Original Message-----
>>>> From: Ladislav Lhotka [mailto:lhotka@nic.cz]
>>>> Sent: Monday, June 23, 2014 2:16 PM
>>>> To: Alia Atlas
>>>> Cc: Jeffrey (Zhaohui) Zhang; Dean Bogdanovic; netmod@ietf.org; =
Kiran
>>>> Agrahara Sreenivasa
>>>> Subject: Re: [netmod] Questions/comments on draft-ietf-netmod-
>> routing-
>>>> cfg
>>>>=20
>>>> Hi Alia,
>>>>=20
>>>> On 23 Jun 2014, at 17:32, Alia Atlas  wrote:
>>>>=20
>>>>> Lada,
>>>>>=20
>>>>> On Mon, Jun 23, 2014 at 10:38 AM, Ladislav Lhotka 
>>>> wrote:
>>>>> "Jeffrey (Zhaohui) Zhang"  writes:
>>>>>=20
>>>>>> Lada,
>>>>>>=20
>>>>>> The discussions basically boil down to two main points:
>>>>>>=20
>>>>>> - I believe the spec should have well defined semantics for some
>>>> well-known types of "routing-instances". Otherwise it is too loose =
to
>> be
>>>> the foundation for future work (e.g. the on-going OSPF YANG model
>> work).
>>>> That does not prevent the flexibility for future extensions.
>>>>>=20
>>>>> The OSPF (and more recent ISIS) module can work just fine with
>>>> "standard-routing-instance". On smaller router platforms (OpenWRT
>> with
>>>> Quagga or BIRD daemons) this is all that's needed. I don't know why
>>>> specific routing instance types couldn't be defined in separate
>> modules.
>>>>>=20
>>>>>=20
>>>>> Supporting very common features (L3VPNs, logical routers, multiple
>>>> routing instances) can
>>>>> make routers significantly more complex than Quagga supports.  =
While
>>>> Quagga certainly has some useful features, I do not think it has =
kept
>>>> pace.  What is needed for routing is more.
>>>>=20
>>>> Right, but it doesn't mean this more has to be implemented by the
>> core
>>>> routing model. I think the important point is that such extensions
>> are
>>>> possible to do in other modules, and I am convinced it is the case.
>>>>=20
>>>>=20
>>>>>=20
>>>>>>=20
>>>>>> - I think the spec is too restrictive in saying "Each routing
>>>> protocol instance is connected to exactly one RIB for each address
>>>> family that the routing protocol instance supports". We can mix AF
>> and
>>>> SAF together and simply say Address Family (if we make it clear) =
but
>>>> with the consideration of MT the statement is just not correct.
>>>>>=20
>>>>> There are currently three possible solutions:
>>>>>=20
>>>>> 1. Subdivide each address family via identity derivation, e.g. =
with
>>>> respect to type of service.
>>>>>=20
>>>>> 2. Distribute routes from the connected RIB selectively to any
>> number
>>>> other RIBs via "recipient-rib" mechanism.
>>>>>=20
>>>>> 3. Augment the "routing-protocol" subtrees with new parameters. =
For
>>>> example, one could introduce protocol "sub-instances", one for each
>>>> topology, and then different sub-instances could use the same =
address
>>>> family (this is by the way another advantage of having a flat list =
of
>>>> routing protocol instances).
>>>>>=20
>>>>> In my view, this choice should be sufficient.
>>>>>=20
>>>>>=20
>>>>>>=20
>>>>>> I am more concerned with the first point.
>>>>>>=20
>>>>>> I don't think this is too late. There is still IETF last call and =
I
>>>> am posting my comments here. If there is enough consensus to my
>> points,
>>>> then necessary changes need to happen. If not, I'll accept that.
>>>>>=20
>>>>> The routing-cfg document is already long overdue. We've already =
had
>>>> several rounds of relatively significant redesigns based on
>> reviewers'
>>>> comments, and I think now it's time to deliver the result. The data
>>>> model may not be perfect and I am open to returning to it after we
>> gain
>>>> some experience, but IMO we first need to fill the gaps by =
developing
>>>> modules for routing protocols, route filters and, of course, =
specific
>>>> types of routing instances.
>>>>>=20
>>>>> Jeffrey is coming in, trying to work on an OSPF YANG model, as a
>>>> routing person very familiar with one implementation.  If this =
draft
>> is
>>>> not a sufficient base on which to build the other routing models, =
how
>>>> should we proceed?  I have requested yet another routing =
directorate
>>>> review on this draft; I'd expect that review before the upcoming =
IETF.
>>>>=20
>>>> Yes, it is really challenging to combine YANG expertise (as YANG is =
a
>>>> relatively new data modelling language) with domain-specific =
know-how.
>>>> FWIW, I wrote an OSPF module for the BIRD daemon that perhaps may =
be
>>>> used for comparison:
>>>>=20
>>>> https://gitlab.labs.nic.cz/labs/yang-tools/blob/master/data-
>>>> models/bird/bird-ospf.yang
>>>>=20
>>>> Lada
>>>>=20
>>>>>=20
>>>>> I can appreciate the frustration in the time it is taking to get
>> this
>>>> draft done.  Cross-area review does frequently happen after WGLC.
>>>>>=20
>>>>> Alia
>>>>>=20
>>>>> Lada
>>>>>=20
>>>>>>=20
>>>>>> Thanks.
>>>>>> Jeffrey
>>>>>>=20
>>>>>>> -----Original Message-----
>>>>>>> From: Ladislav Lhotka [mailto:lhotka@nic.cz]
>>>>>>> Sent: Monday, June 23, 2014 4:26 AM
>>>>>>> To: Jeffrey (Zhaohui) Zhang; Dean Bogdanovic; netmod@ietf.org
>>>>>>> Cc: Derek Man-Kit Yeung (myeung); Kiran Agrahara Sreenivasa
>>>>>>> Subject: RE: Questions/comments on draft-ietf-netmod-routing-cfg
>>>>>>>=20
>>>>>>> "Jeffrey (Zhaohui) Zhang"  writes:
>>>>>>>=20
>>>>>>>> Lada,
>>>>>>>>=20
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: Ladislav Lhotka [mailto:lhotka@nic.cz]
>>>>>>>>> Sent: Friday, June 20, 2014 7:26 AM
>>>>>>>>> To: Jeffrey (Zhaohui) Zhang; Dean Bogdanovic; netmod@ietf.org
>>>>>>>>> Cc: Derek Man-Kit Yeung (myeung); Kiran Agrahara Sreenivasa
>>>>>>>>> Subject: Re: Questions/comments on =
draft-ietf-netmod-routing-cfg
>>>>>>>>>=20
>>>>>>>>> "Jeffrey (Zhaohui) Zhang"  writes:
>>>>>>>>>=20
>>>>>>>>>> Ladislav,
>>>>>>>>>>=20
>>>>>>>>>> Dean and I have some late questions and comments. We came
>>>> across
>>>>>>> these
>>>>>>>>> while trying to work on the OSPF YANG model.
>>>>>>>>>>=20
>>>>>>>>>> -----------
>>>>>>>>>>=20
>>>>>>>>>> The spec mentions in several places something like the
>>>> following:
>>>>>>>>>>=20
>>>>>>>>>>  Each routing protocol instance is connected to exactly one
>>>> RIB
>>>>>>> for
>>>>>>>>>>  each address family that the routing protocol instance
>>>> supports.
>>>>>>>>>>=20
>>>>>>>>>> My understanding is that the address family mentioned above
>>>> does
>>>>>>> not
>>>>>>>>> include SAFI. Because of that, a routing protocol like BGP may
>>>>>>> connect
>>>>>>>>> to multiple RIBs in the same family (RIB for unicast and RIB =
for
>>>>>>>>> multicast RPF purpose in case of incongruent multicast =
topology)
>>>> so
>>>>>>> the
>>>>>>>>> above statement is not correct.
>>>>>>>>>=20
>>>>>>>>> This is quite flexible since address family is defined via
>>>> identities.
>>>>>>> I
>>>>>>>>> can imagine one implementation using only "ipv4" and "ipv6"
>>>> (defined
>>>>>>> in
>>>>>>>>> ietf-routing) whilst other implementation could use "ipv[46]-
>>>> unicast"
>>>>>>>>> (defined in ietf-ipv[46]-unicast-routing) and "ipv[46]-
>>>> multicast" (to
>>>>>>> be
>>>>>>>>> defined in a module for unicast routing), that means including
>>>> SAFI.
>>>>>>>>=20
>>>>>>>> Address Family has very specific meanings, typically only refer
>>>> to
>>>>>>> IPv4/IPv6 to my understanding. If we want to extend that to
>> include
>>>> SAFI,
>>>>>>> then the spec must point it out. More below related to MT.
>>>>>>>=20
>>>>>>> Both Cisco and Juniper docs use terms like "IPv6 multicast =
address
>>>>>>> family" or "MCAST-VPN address family" that clearly include SAFI =
as
>>>> well.
>>>>>>>=20
>>>>>>> For better or worse, in the ietf-routing YANG module "address-
>>>> family"
>>>>>>> leaf is defined with the type
>>>>>>>=20
>>>>>>>        type identityref {
>>>>>>>          base address-family;
>>>>>>>        }
>>>>>>>=20
>>>>>>> so its meaning follows from that, including the fact that the
>>>> identity
>>>>>>> is extensible. In my view, it is a feature, not bug.
>>>>>>>=20
>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>> This is also a problem in case of Multi-topology. Each
>>>> topology has
>>>>>>>>> its own RIB and a protocol instance like OSPF can connect to
>>>> multiple
>>>>>>> MT
>>>>>>>>> RIBs.
>>>>>>>>>=20
>>>>>>>>> Two possible solutions come to my mind:
>>>>>>>>>=20
>>>>>>>>> 1. You could derive new address family identities from "ipv4-
>>>> unicast"
>>>>>>>>> etc. so that you can assign a unique address family to =
multiple
>>>>>>> tables.
>>>>>>>>>=20
>>>>>>>>> 2. You could have one connected RIB e.g. for "ipv4-unicast" =
and
>>>>>>> define
>>>>>>>>> two or more RIBs for each topology as recipients of the
>>>> connected RIB.
>>>>>>>>> So, in effect, the (single) connected RIB contains routes for
>>>> all
>>>>>>>>> topologies and these are then split via route filters to the
>>>> per-
>>>>>>>>> topology RIBs.
>>>>>>>>>=20
>>>>>>>>> Does it make sense?
>>>>>>>>=20
>>>>>>>> Compare the two, I don't like #2 because it adds an unnecessary
>>>>>>> indirection. I don't think we want to overload "Address Family"
>>>> further
>>>>>>> to include topology either. In many implementations, actual RIBs
>>>> are per
>>>>>>> (routing-instance, AFI, SAFI, topology) and it may be extended
>>>> further.
>>>>>>> Therefore, the best option is to simply remove the restriction
>> that
>>>> one
>>>>>>> protocol instance is connected to exactly one RIB per address
>>>> family.
>>>>>>>=20
>>>>>>> This restriction is only relevant for the "connected-rib" list. =
If
>>>> you
>>>>>>> want, you can add configuration parameters to associate other =
RIBs
>>>>>>> directly with a routing protocol instance.
>>>>>>>=20
>>>>>>> IMO, the common use case for MT are incongruent IPv4 and IPv6
>>>> topologies,
>>>>>>> and the core routing data model can handle this directly and
>> easily.
>>>>>>>=20
>>>>>>> Also note that the "routing-cfg" document has already been
>>>> submitted to
>>>>>>> IESG for publication, so your comments come really late.
>>>>>>>=20
>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>> ------
>>>>>>>>>>=20
>>>>>>>>>> 5.1.  Routing Instance
>>>>>>>>>>=20
>>>>>>>>>>  Each routing instance in the core routing data model
>>>> represents
>>>>>>> a
>>>>>>>>>>  logical router.  The exact semantics of this term are left
>>>> to
>>>>>>>>>>  implementations.  For example, routing instances may be
>>>>>>> completely
>>>>>>>>>>  isolated virtual routers or, alternatively, they may
>>>> internally
>>>>>>> share
>>>>>>>>>>  certain information.
>>>>>>>>>>=20
>>>>>>>>>>  ...
>>>>>>>>>>=20
>>>>>>>>>>  An implementation MAY support multiple types of logical
>>>> routers
>>>>>>>>>>  simultaneously.  Instances of all routing instance types
>>>> are
>>>>>>>>>>  organized as entries of the same flat "routing-instance"
>>>> list.
>>>>>>> In
>>>>>>>>>>  order to discriminate routing instances belonging to
>>>> different
>>>>>>> types,
>>>>>>>>>>  the "type" leaf is defined as a child of the "routing-
>>>> instance"
>>>>>>> node.
>>>>>>>>>>=20
>>>>>>>>>> The spec purposely left it fuzzy as to what a "routing
>>>> instance" is.
>>>>>>>>> However we definitely should have clear definitions for the
>>>> three
>>>>>>> terms
>>>>>>>>> mentioned: routing-instance, logical router and virtual =
router.
>>>>>>>>>=20
>>>>>>>>> Yes, this is by design open-ended because otherwise we would
>>>> probably
>>>>>>>>> never reach consensus on what these terms exactly mean.
>>>>>>>>=20
>>>>>>>> While the design needs to be open-ended a standard =
specification
>>>> needs
>>>>>>> to be precise and unambiguous. The names can be discussed and
>>>>>>> compromised but the meaning must be clear. For example, Cisco
>>>> "virtual
>>>>>>> router" and Juniper "logical router/system" are the same but
>>>> Juniper
>>>>>>> "virtual router" and Cisco "VRF-lite" are the same. What does =
the
>>>>>>> "logical router" in this spec mean? We can't just say that "it =
can
>>>> mean
>>>>>>> any of those". For example if it means Cisco's "virtual router" =
or
>>>>>>> Juniper's "logical system", a further discussion may be - should
>>>> this
>>>>>>> module really cover that.
>>>>>>>=20
>>>>>>> The term "logical router" is used in a very general sense, and =
the
>>>>>>> document clearly says so ("no semantics"). The other terms are
>> used
>>>> only
>>>>>>> as examples what it could possibly mean, to make the spec more
>>>>>>> accessible.
>>>>>>>=20
>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>> Logical router is a very overload term. Today vendors have
>>>>>>> virtualized
>>>>>>>>> their routing capabilities in the system and provide 3 =
different
>>>>>>> levels
>>>>>>>>> of routing virtualization. Logical systems, logical routers =
are
>>>> some
>>>>>>> of
>>>>>>>>> the names used by vendors and those offer routing and =
management
>>>>>>>>> separation. Each logical system has its own routing instances
>>>> and
>>>>>>>>> routing instances can have multiple routing tables, so it is
>>>> very
>>>>>>>>> important to have very precise definition of what is routing
>>>> instance
>>>>>>>>> (and not compare it with logical router)
>>>>>>>>>>=20
>>>>>>>>>>    identity standard-routing-instance {
>>>>>>>>>>      base routing-instance-type;
>>>>>>>>>>      description
>>>>>>>>>>        "This identity represents a default routing
>>>> instance.";
>>>>>>>>>>    }
>>>>>>>>>>=20
>>>>>>>>>> What is a "standard-routing-instance"? Would =
"default-routing-
>>>>>>>>> instance" be better? "standard" wording leads to "standard vs.
>>>> non-
>>>>>>>>> standard" question and hints on that the two are different =
types.
>>>>>>>>> "default" vs. "non-default" does not have that (at least to =
me).
>>>>>>>>>=20
>>>>>>>>> Well, "default" is overloaded, too, and also has a specific
>>>> meaning
>>>>>>> in
>>>>>>>>> YANG. Standard is supposed to mean plain vanilla router. It is
>>>> just a
>>>>>>>>> name.
>>>>>>>>=20
>>>>>>>> I don't have to split hair between "standard" and "default" but
>>>> the
>>>>>>> spec must point out what a "standard-routing-instance" is - is =
it
>>>> the
>>>>>>> default/base/master logical-system (Cisco virtual-router) or the
>>>>>>> default/base/master "routing-instance" (a "logical-system" would
>>>> include
>>>>>>> many "routing-instances" like VRFs).
>>>>>>>>=20
>>>>>>>=20
>>>>>>> I think the ietf-routing module makes it pretty clear:
>>>>>>>=20
>>>>>>>        leaf type {
>>>>>>>          type identityref {
>>>>>>>            base routing-instance-type;
>>>>>>>          }
>>>>>>>          default "rt:standard-routing-instance";
>>>>>>>          description
>>>>>>>            "The type of the routing instance.";
>>>>>>>        }
>>>>>>>=20
>>>>>>> The purpose of the "type" is to allow for defining a new routing
>>>>>>> instance type and augment configuration or state data
>> conditionally
>>>> for
>>>>>>> that type. The "standard-routing-instance" is just the default
>>>> value to
>>>>>>> start from, it has no other meaning.
>>>>>>>=20
>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>> Should this spec distinguish VRF/VR/LR and have corresponding
>>>>>>>>> identities defined?
>>>>>>>>>=20
>>>>>>>>> The idea is this will be done in other modules that define =
data
>>>>>>> models
>>>>>>>>> for these types of routing instances. Then the "routing-
>>>> instance"
>>>>>>>>> container can be augmented with arbitrary data, but
>>>> conditionally for
>>>>>>>>> that routing instance type.
>>>>>>>>=20
>>>>>>>> I think it is important to define a few well known routing
>>>> instance
>>>>>>> types in the base spec as a good foundation for other modules.
>>>>>>>=20
>>>>>>> This is outside the scope of the core routing data model, and
>>>> should be
>>>>>>> done by routing experts, not in the NETMOD group. There are =
other
>>>>>>> indispensable elements that have to be worked out before the
>>>> routing
>>>>>>> data model can be really useful, e.g. routing protocols and =
route
>>>>>>> filters.
>>>>>>>=20
>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>> An implementation may actually use multiple routing-instance
>>>> types at
>>>>>>>>> the same time.
>>>>>>>>=20
>>>>>>>> That's for sure and not what I'm concerned with.
>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>>        leaf type {
>>>>>>>>>>          type identityref {
>>>>>>>>>>            base routing-instance-type;
>>>>>>>>>>          }
>>>>>>>>>>          description
>>>>>>>>>>            "The routing instance type, primarily intended
>>>> for
>>>>>>>>>>             discriminating among different types of logical
>>>>>>> routers,
>>>>>>>>>>             route virtualization, master-slave arrangements
>>>> etc.,
>>>>>>>>>>             while keeping all routing instances in the same
>>>> flat
>>>>>>>>>>             list.";
>>>>>>>>>>        }
>>>>>>>>>>=20
>>>>>>>>>> What is the "master-slave arrangements"?
>>>>>>>>>=20
>>>>>>>>> This came from an early review by Thomas Morin, it has to do
>>>> with
>>>>>>>>> MPLS/BGP VPNs where a master routing-instance exchanges =
selected
>>>>>>> routes
>>>>>>>>> with each VPN/VRF.
>>>>>>>>=20
>>>>>>>> Either it needs to be clarified in the spec, or it could simply
>>>> be
>>>>>>> removed to avoid confusion since "route virtualization" covers
>> that
>>>>>>> already.
>>>>>>>=20
>>>>>>> This is actually a typo - it should be "router virtualization". =
My
>>>>>>> understanding of this term is that a virtual router is isolated
>> and
>>>>>>> exchanges routing information with other routers only through
>>>> routing
>>>>>>> protocols.
>>>>>>>=20
>>>>>>> Anyway, these are really only examples and I think it is
>>>> sufficiently
>>>>>>> clear that the core routing data model doesn't use these terms =
for
>>>>>>> defining any semantics.
>>>>>>>=20
>>>>>>> Lada
>>>>>>>=20
>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>> Depending on the definition of "logical router" and "route
>>>>>>>>> virtualization", there may also be concerns with keeping all
>>>> those
>>>>>>> kinds
>>>>>>>>> of in the same flat list.
>>>>>>>>>=20
>>>>>>>>> It is similar to interfaces, where physical and logical
>>>> interfaces of
>>>>>>>>> all kinds live in the same flat list and are distinguished by
>>>> the
>>>>>>> type.
>>>>>>>>> I think it could work, relationships among the individual
>>>> routing
>>>>>>>>> instances can be expressed in other data.
>>>>>>>>=20
>>>>>>>> I will defer to others about the merits of a flat list, but for =
a
>>>> flat
>>>>>>> list, the base spec needs to provide a way to express the
>>>> relationship.
>>>>>>>>=20
>>>>>>>> Jeffrey
>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>> Having a single flat list has its advantages, for example you
>>>> can
>>>>>>> then
>>>>>>>>> easily refer to routing instances via leafrefs (which allow =
only
>>>> one
>>>>>>>>> path).
>>>>>>>>>=20
>>>>>>>>> Cheers, Lada
>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>> Jeffrey Zhang
>>>>>>>>>> Dean Bogdanovic
>>>>>>>>>=20
>>>>>>>>> --
>>>>>>>>> Ladislav Lhotka, CZ.NIC Labs
>>>>>>>>> PGP Key ID: E74E8C0C
>>>>>>>=20
>>>>>>> --
>>>>>>> Ladislav Lhotka, CZ.NIC Labs
>>>>>>> PGP Key ID: E74E8C0C
>>>>>=20
>>>>> --
>>>>> Ladislav Lhotka, CZ.NIC Labs
>>>>> PGP Key ID: E74E8C0C
>>>>>=20
>>>>> _______________________________________________
>>>>> netmod mailing list
>>>>> netmod@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/netmod
>>>>>=20
>>>>=20
>>>> --
>>>> Ladislav Lhotka, CZ.NIC Labs
>>>> PGP Key ID: E74E8C0C
>>>>=20
>>>>=20
>>>>=20
>>>=20
>>=20
>> --
>> Ladislav Lhotka, CZ.NIC Labs
>> PGP Key ID: E74E8C0C
>>=20
>>=20
>>=20
>=20

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





From nobody Mon Jun 23 13:36:48 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE5EF1B2973 for ; Mon, 23 Jun 2014 13:36:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.302
X-Spam-Level: 
X-Spam-Status: No, score=-1.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RP_MATCHES_RCVD=-0.651] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o2-92WpIrFyG for ; Mon, 23 Jun 2014 13:36:43 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C4C71B28FE for ; Mon, 23 Jun 2014 13:36:43 -0700 (PDT)
Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id A8C6E13FCDE; Mon, 23 Jun 2014 22:36:41 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1403555802; bh=kly5Qng43BZjx/4fij2ea3+YiM4fQ5TYhFiU4/0+CIU=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=KVMcruRmzKMjbYHXid9NiUWA/yq5gpLS4KzGc/nm4wmGh6vqOBGTdhlGCsWZ+vlmI vuj5V1gWQ5gu5dhYUc8P7CQQDm/tDOF3uQnjJ/inWi/Y071OwRkzw48Pp23PZlIGqz VZwd6cUfV6Cp8wJwVt/2ggrcEBRblSHv98tRLUxc=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
From: Ladislav Lhotka 
In-Reply-To: 
Date: Mon, 23 Jun 2014 22:36:41 +0200
Content-Transfer-Encoding: 7bit
Message-Id: <797B0914-9A3A-4539-8721-2A66CCFA1C1C@nic.cz>
References:   <18cd777ffb9d4df6b0966dd1b3dd822b@BY2PR05MB079.namprd05.prod.outlook.com>     <89F86AF6-9114-47B2-888F-FD50CA4BA887@nic.cz>  <6E5BA386-4803-44BF-98DA-81A6673C85B3@nic.cz> 
To: "Jeffrey (Zhaohui) Zhang" 
X-Mailer: Apple Mail (2.1878.2)
X-Virus-Scanned: clamav-milter 0.98.1 at mail
X-Virus-Status: Clean
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/Q6a7vQ2hk1RihsGkemRtacKixAw
Cc: NETMOD Working Group 
Subject: Re: [netmod] Questions/comments on draft-ietf-netmod-routing-cfg
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 23 Jun 2014 20:36:46 -0000

On 23 Jun 2014, at 22:03, Jeffrey (Zhaohui) Zhang  wrote:

> Lada,
> 
>> -----Original Message-----
>> From: Ladislav Lhotka [mailto:lhotka@nic.cz]
>> Sent: Monday, June 23, 2014 3:58 PM
>> To: Jeffrey (Zhaohui) Zhang
>> Cc: NETMOD Working Group
>> Subject: Re: [netmod] Questions/comments on draft-ietf-netmod-routing-
>> cfg
>> 
>> 
>> On 23 Jun 2014, at 21:05, Jeffrey (Zhaohui) Zhang 
>> wrote:
>> 
>>> Lada,
>>> 
>>>>> How about simply remove that restriction that one protocol instance
>>>> connects to only one RIB per address family?
>>>> 
>>>> It has other implications: you have to have a way for specifying which
>>>> protocol routes go to which RIB, and also how the RIBs are used in the
>>>> data plane for forwarding packets.
>>> 
>>> I am just saying to remove the restriction that one protocol instance
>> only connects to one rib per family. It does not change anything else
>> like what you are saying above.
>> 
>> I don't agree. If two different RIBs for, e.g., ipv4-unicast are
>> connected to a routing protocol instance, then in which RIB the IPv4
>> unicast routes learned by that protocol instance are supposed to appear?
> 
> That's what could deferred to an extension module :-)
> 
>> 
>>> 
>>>> What is this issue with "routing-instance"? Could you be more specific?
>>> 
>>> Please see my previous email that I just sent.
>> 
>> I don't know where the logical/virtual router type comes into play in
>> the OSPF module. They certainly don't in the ISIS module.
> 
> We can include you in OSPF YANG discussions.

Yes, that would be useful.

Lada


> I will also review the ISIS module.
> 
> Jeffrey
> 
>> 
>> Lada
>> 
>>> 
>>> Jeffrey
>>> 
>>>> -----Original Message-----
>>>> From: Ladislav Lhotka [mailto:lhotka@nic.cz]
>>>> Sent: Monday, June 23, 2014 2:23 PM
>>>> To: Jeffrey (Zhaohui) Zhang
>>>> Subject: Re: [netmod] Questions/comments on draft-ietf-netmod-
>> routing-
>>>> cfg
>>>> 
>>>> 
>>>> On 23 Jun 2014, at 17:12, Jeffrey (Zhaohui) Zhang 
>>>> wrote:
>>>> 
>>>>> Lada,
>>>>> 
>>>>>> -----Original Message-----
>>>>>> From: Ladislav Lhotka [mailto:lhotka@nic.cz]
>>>>>> Sent: Monday, June 23, 2014 10:39 AM
>>>>>> To: Jeffrey (Zhaohui) Zhang; Dean Bogdanovic; netmod@ietf.org
>>>>>> Cc: Kiran Agrahara Sreenivasa
>>>>>> Subject: Re: [netmod] Questions/comments on draft-ietf-netmod-
>>>> routing-
>>>>>> cfg
>>>>>> 
>>>>>> "Jeffrey (Zhaohui) Zhang"  writes:
>>>>>> 
>>>>>>> Lada,
>>>>>>> 
>>>>>>> The discussions basically boil down to two main points:
>>>>>>> 
>>>>>>> - I believe the spec should have well defined semantics for some
>>>> well-
>>>>>> known types of "routing-instances". Otherwise it is too loose to be
>>>> the
>>>>>> foundation for future work (e.g. the on-going OSPF YANG model work).
>>>>>> That does not prevent the flexibility for future extensions.
>>>>>> 
>>>>>> The OSPF (and more recent ISIS) module can work just fine with
>>>>>> "standard-routing-instance". On smaller router platforms (OpenWRT
>>>> with
>>>>>> Quagga or BIRD daemons) this is all that's needed. I don't know why
>>>>>> specific routing instance types couldn't be defined in separate
>>>> modules.
>>>>>> 
>>>>>>> 
>>>>>>> - I think the spec is too restrictive in saying "Each routing
>>>> protocol
>>>>>> instance is connected to exactly one RIB for each address family
>> that
>>>>>> the routing protocol instance supports". We can mix AF and SAF
>>>> together
>>>>>> and simply say Address Family (if we make it clear) but with the
>>>>>> consideration of MT the statement is just not correct.
>>>>>> 
>>>>>> There are currently three possible solutions:
>>>>>> 
>>>>>> 1. Subdivide each address family via identity derivation, e.g. with
>>>>>> respect to type of service.
>>>>>> 
>>>>>> 2. Distribute routes from the connected RIB selectively to any
>> number
>>>>>> other RIBs via "recipient-rib" mechanism.
>>>>>> 
>>>>>> 3. Augment the "routing-protocol" subtrees with new parameters. For
>>>>>> example, one could introduce protocol "sub-instances", one for each
>>>>>> topology, and then different sub-instances could use the same
>> address
>>>>>> family (this is by the way another advantage of having a flat list
>> of
>>>>>> routing protocol instances).
>>>>>> 
>>>>>> In my view, this choice should be sufficient.
>>>>> 
>>>>> How about simply remove that restriction that one protocol instance
>>>> connects to only one RIB per address family?
>>>> 
>>>> It has other implications: you have to have a way for specifying
>> which
>>>> protocol routes go to which RIB, and also how the RIBs are used in
>> the
>>>> data plane for forwarding packets.
>>>> 
>>>>> 
>>>>>> 
>>>>>> 
>>>>>>> 
>>>>>>> I am more concerned with the first point.
>>>>>>> 
>>>>>>> I don't think this is too late. There is still IETF last call and
>> I
>>>> am
>>>>>> posting my comments here. If there is enough consensus to my points,
>>>>>> then necessary changes need to happen. If not, I'll accept that.
>>>>>> 
>>>>>> The routing-cfg document is already long overdue. We've already had
>>>>>> several rounds of relatively significant redesigns based on
>>>> reviewers'
>>>>>> comments, and I think now it's time to deliver the result. The data
>>>>>> model may not be perfect and I am open to returning to it after we
>>>> gain
>>>>>> some experience, but IMO we first need to fill the gaps by
>> developing
>>>>>> modules for routing protocols, route filters and, of course,
>> specific
>>>>>> types of routing instances.
>>>>> 
>>>>> We're developing protocol modules, and it is during that process
>> (for
>>>> OSPF YANG module) that the issue with "routing-instance" came up.
>> It's
>>>> better to address that in the netmod-routing-cfg spec now than
>>>> later/separately.
>>>> 
>>>> What is this issue with "routing-instance"? Could you be more
>> specific?
>>>> 
>>>> Lada
>>>> 
>>>>> 
>>>>> Jeffrey
>>>>> 
>>>>>> 
>>>>>> Lada
>>>>>> 
>>>>>>> 
>>>>>>> Thanks.
>>>>>>> Jeffrey
>>>>>>> 
>>>>>>>> -----Original Message-----
>>>>>>>> From: Ladislav Lhotka [mailto:lhotka@nic.cz]
>>>>>>>> Sent: Monday, June 23, 2014 4:26 AM
>>>>>>>> To: Jeffrey (Zhaohui) Zhang; Dean Bogdanovic; netmod@ietf.org
>>>>>>>> Cc: Derek Man-Kit Yeung (myeung); Kiran Agrahara Sreenivasa
>>>>>>>> Subject: RE: Questions/comments on draft-ietf-netmod-routing-cfg
>>>>>>>> 
>>>>>>>> "Jeffrey (Zhaohui) Zhang"  writes:
>>>>>>>> 
>>>>>>>>> Lada,
>>>>>>>>> 
>>>>>>>>>> -----Original Message-----
>>>>>>>>>> From: Ladislav Lhotka [mailto:lhotka@nic.cz]
>>>>>>>>>> Sent: Friday, June 20, 2014 7:26 AM
>>>>>>>>>> To: Jeffrey (Zhaohui) Zhang; Dean Bogdanovic; netmod@ietf.org
>>>>>>>>>> Cc: Derek Man-Kit Yeung (myeung); Kiran Agrahara Sreenivasa
>>>>>>>>>> Subject: Re: Questions/comments on draft-ietf-netmod-routing-
>> cfg
>>>>>>>>>> 
>>>>>>>>>> "Jeffrey (Zhaohui) Zhang"  writes:
>>>>>>>>>> 
>>>>>>>>>>> Ladislav,
>>>>>>>>>>> 
>>>>>>>>>>> Dean and I have some late questions and comments. We came
>> across
>>>>>>>> these
>>>>>>>>>> while trying to work on the OSPF YANG model.
>>>>>>>>>>> 
>>>>>>>>>>> -----------
>>>>>>>>>>> 
>>>>>>>>>>> The spec mentions in several places something like the
>> following:
>>>>>>>>>>> 
>>>>>>>>>>>  Each routing protocol instance is connected to exactly one
>>>>>> RIB
>>>>>>>> for
>>>>>>>>>>>  each address family that the routing protocol instance
>>>>>> supports.
>>>>>>>>>>> 
>>>>>>>>>>> My understanding is that the address family mentioned above
>> does
>>>>>>>> not
>>>>>>>>>> include SAFI. Because of that, a routing protocol like BGP may
>>>>>>>> connect
>>>>>>>>>> to multiple RIBs in the same family (RIB for unicast and RIB
>> for
>>>>>>>>>> multicast RPF purpose in case of incongruent multicast topology)
>>>>>> so
>>>>>>>> the
>>>>>>>>>> above statement is not correct.
>>>>>>>>>> 
>>>>>>>>>> This is quite flexible since address family is defined via
>>>>>> identities.
>>>>>>>> I
>>>>>>>>>> can imagine one implementation using only "ipv4" and "ipv6"
>>>>>> (defined
>>>>>>>> in
>>>>>>>>>> ietf-routing) whilst other implementation could use "ipv[46]-
>>>>>> unicast"
>>>>>>>>>> (defined in ietf-ipv[46]-unicast-routing) and "ipv[46]-
>> multicast"
>>>>>> (to
>>>>>>>> be
>>>>>>>>>> defined in a module for unicast routing), that means including
>>>>>> SAFI.
>>>>>>>>> 
>>>>>>>>> Address Family has very specific meanings, typically only refer
>> to
>>>>>>>> IPv4/IPv6 to my understanding. If we want to extend that to
>> include
>>>>>> SAFI,
>>>>>>>> then the spec must point it out. More below related to MT.
>>>>>>>> 
>>>>>>>> Both Cisco and Juniper docs use terms like "IPv6 multicast
>> address
>>>>>>>> family" or "MCAST-VPN address family" that clearly include SAFI
>> as
>>>>>> well.
>>>>>>>> 
>>>>>>>> For better or worse, in the ietf-routing YANG module "address-
>>>> family"
>>>>>>>> leaf is defined with the type
>>>>>>>> 
>>>>>>>>       type identityref {
>>>>>>>>         base address-family;
>>>>>>>>       }
>>>>>>>> 
>>>>>>>> so its meaning follows from that, including the fact that the
>>>>>> identity
>>>>>>>> is extensible. In my view, it is a feature, not bug.
>>>>>>>> 
>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> This is also a problem in case of Multi-topology. Each
>> topology
>>>>>> has
>>>>>>>>>> its own RIB and a protocol instance like OSPF can connect to
>>>>>> multiple
>>>>>>>> MT
>>>>>>>>>> RIBs.
>>>>>>>>>> 
>>>>>>>>>> Two possible solutions come to my mind:
>>>>>>>>>> 
>>>>>>>>>> 1. You could derive new address family identities from "ipv4-
>>>>>> unicast"
>>>>>>>>>> etc. so that you can assign a unique address family to multiple
>>>>>>>> tables.
>>>>>>>>>> 
>>>>>>>>>> 2. You could have one connected RIB e.g. for "ipv4-unicast" and
>>>>>>>> define
>>>>>>>>>> two or more RIBs for each topology as recipients of the
>> connected
>>>>>> RIB.
>>>>>>>>>> So, in effect, the (single) connected RIB contains routes for
>> all
>>>>>>>>>> topologies and these are then split via route filters to the
>> per-
>>>>>>>>>> topology RIBs.
>>>>>>>>>> 
>>>>>>>>>> Does it make sense?
>>>>>>>>> 
>>>>>>>>> Compare the two, I don't like #2 because it adds an unnecessary
>>>>>>>> indirection. I don't think we want to overload "Address Family"
>>>>>> further
>>>>>>>> to include topology either. In many implementations, actual RIBs
>>>> are
>>>>>> per
>>>>>>>> (routing-instance, AFI, SAFI, topology) and it may be extended
>>>>>> further.
>>>>>>>> Therefore, the best option is to simply remove the restriction
>> that
>>>>>> one
>>>>>>>> protocol instance is connected to exactly one RIB per address
>>>> family.
>>>>>>>> 
>>>>>>>> This restriction is only relevant for the "connected-rib" list.
>> If
>>>>>> you
>>>>>>>> want, you can add configuration parameters to associate other
>> RIBs
>>>>>>>> directly with a routing protocol instance.
>>>>>>>> 
>>>>>>>> IMO, the common use case for MT are incongruent IPv4 and IPv6
>>>>>> topologies,
>>>>>>>> and the core routing data model can handle this directly and
>> easily.
>>>>>>>> 
>>>>>>>> Also note that the "routing-cfg" document has already been
>>>> submitted
>>>>>> to
>>>>>>>> IESG for publication, so your comments come really late.
>>>>>>>> 
>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> ------
>>>>>>>>>>> 
>>>>>>>>>>> 5.1.  Routing Instance
>>>>>>>>>>> 
>>>>>>>>>>> Each routing instance in the core routing data model
>>>>>> represents
>>>>>>>> a
>>>>>>>>>>> logical router.  The exact semantics of this term are left to
>>>>>>>>>>> implementations.  For example, routing instances may be
>>>>>>>> completely
>>>>>>>>>>> isolated virtual routers or, alternatively, they may
>>>>>> internally
>>>>>>>> share
>>>>>>>>>>> certain information.
>>>>>>>>>>> 
>>>>>>>>>>> ...
>>>>>>>>>>> 
>>>>>>>>>>> An implementation MAY support multiple types of logical
>>>>>> routers
>>>>>>>>>>> simultaneously.  Instances of all routing instance types are
>>>>>>>>>>> organized as entries of the same flat "routing-instance" list.
>>>>>>>> In
>>>>>>>>>>> order to discriminate routing instances belonging to
>>>>>> different
>>>>>>>> types,
>>>>>>>>>>> the "type" leaf is defined as a child of the "routing-
>>>>>> instance"
>>>>>>>> node.
>>>>>>>>>>> 
>>>>>>>>>>> The spec purposely left it fuzzy as to what a "routing
>> instance"
>>>>>> is.
>>>>>>>>>> However we definitely should have clear definitions for the
>> three
>>>>>>>> terms
>>>>>>>>>> mentioned: routing-instance, logical router and virtual router.
>>>>>>>>>> 
>>>>>>>>>> Yes, this is by design open-ended because otherwise we would
>>>>>> probably
>>>>>>>>>> never reach consensus on what these terms exactly mean.
>>>>>>>>> 
>>>>>>>>> While the design needs to be open-ended a standard specification
>>>>>> needs
>>>>>>>> to be precise and unambiguous. The names can be discussed and
>>>>>>>> compromised but the meaning must be clear. For example, Cisco
>>>>>> "virtual
>>>>>>>> router" and Juniper "logical router/system" are the same but
>>>> Juniper
>>>>>>>> "virtual router" and Cisco "VRF-lite" are the same. What does the
>>>>>>>> "logical router" in this spec mean? We can't just say that "it
>> can
>>>>>> mean
>>>>>>>> any of those". For example if it means Cisco's "virtual router"
>> or
>>>>>>>> Juniper's "logical system", a further discussion may be - should
>>>> this
>>>>>>>> module really cover that.
>>>>>>>> 
>>>>>>>> The term "logical router" is used in a very general sense, and
>> the
>>>>>>>> document clearly says so ("no semantics"). The other terms are
>> used
>>>>>> only
>>>>>>>> as examples what it could possibly mean, to make the spec more
>>>>>>>> accessible.
>>>>>>>> 
>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> Logical router is a very overload term. Today vendors have
>>>>>>>> virtualized
>>>>>>>>>> their routing capabilities in the system and provide 3
>> different
>>>>>>>> levels
>>>>>>>>>> of routing virtualization. Logical systems, logical routers are
>>>>>> some
>>>>>>>> of
>>>>>>>>>> the names used by vendors and those offer routing and
>> management
>>>>>>>>>> separation. Each logical system has its own routing instances
>> and
>>>>>>>>>> routing instances can have multiple routing tables, so it is
>> very
>>>>>>>>>> important to have very precise definition of what is routing
>>>>>> instance
>>>>>>>>>> (and not compare it with logical router)
>>>>>>>>>>> 
>>>>>>>>>>>    identity standard-routing-instance {
>>>>>>>>>>>      base routing-instance-type;
>>>>>>>>>>>      description
>>>>>>>>>>>        "This identity represents a default routing instance.";
>>>>>>>>>>>    }
>>>>>>>>>>> 
>>>>>>>>>>> What is a "standard-routing-instance"? Would "default-routing-
>>>>>>>>>> instance" be better? "standard" wording leads to "standard vs.
>>>>>> non-
>>>>>>>>>> standard" question and hints on that the two are different
>> types.
>>>>>>>>>> "default" vs. "non-default" does not have that (at least to me).
>>>>>>>>>> 
>>>>>>>>>> Well, "default" is overloaded, too, and also has a specific
>>>>>> meaning
>>>>>>>> in
>>>>>>>>>> YANG. Standard is supposed to mean plain vanilla router. It is
>>>>>> just a
>>>>>>>>>> name.
>>>>>>>>> 
>>>>>>>>> I don't have to split hair between "standard" and "default" but
>>>> the
>>>>>>>> spec must point out what a "standard-routing-instance" is - is it
>>>> the
>>>>>>>> default/base/master logical-system (Cisco virtual-router) or the
>>>>>>>> default/base/master "routing-instance" (a "logical-system" would
>>>>>> include
>>>>>>>> many "routing-instances" like VRFs).
>>>>>>>>> 
>>>>>>>> 
>>>>>>>> I think the ietf-routing module makes it pretty clear:
>>>>>>>> 
>>>>>>>>       leaf type {
>>>>>>>>         type identityref {
>>>>>>>>           base routing-instance-type;
>>>>>>>>         }
>>>>>>>>         default "rt:standard-routing-instance";
>>>>>>>>         description
>>>>>>>>           "The type of the routing instance.";
>>>>>>>>       }
>>>>>>>> 
>>>>>>>> The purpose of the "type" is to allow for defining a new routing
>>>>>>>> instance type and augment configuration or state data
>> conditionally
>>>>>> for
>>>>>>>> that type. The "standard-routing-instance" is just the default
>>>> value
>>>>>> to
>>>>>>>> start from, it has no other meaning.
>>>>>>>> 
>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> Should this spec distinguish VRF/VR/LR and have corresponding
>>>>>>>>>> identities defined?
>>>>>>>>>> 
>>>>>>>>>> The idea is this will be done in other modules that define data
>>>>>>>> models
>>>>>>>>>> for these types of routing instances. Then the "routing-
>> instance"
>>>>>>>>>> container can be augmented with arbitrary data, but
>> conditionally
>>>>>> for
>>>>>>>>>> that routing instance type.
>>>>>>>>> 
>>>>>>>>> I think it is important to define a few well known routing
>>>> instance
>>>>>>>> types in the base spec as a good foundation for other modules.
>>>>>>>> 
>>>>>>>> This is outside the scope of the core routing data model, and
>>>> should
>>>>>> be
>>>>>>>> done by routing experts, not in the NETMOD group. There are other
>>>>>>>> indispensable elements that have to be worked out before the
>>>> routing
>>>>>>>> data model can be really useful, e.g. routing protocols and route
>>>>>>>> filters.
>>>>>>>> 
>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> An implementation may actually use multiple routing-instance
>>>> types
>>>>>> at
>>>>>>>>>> the same time.
>>>>>>>>> 
>>>>>>>>> That's for sure and not what I'm concerned with.
>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>>        leaf type {
>>>>>>>>>>>          type identityref {
>>>>>>>>>>>            base routing-instance-type;
>>>>>>>>>>>          }
>>>>>>>>>>>          description
>>>>>>>>>>>            "The routing instance type, primarily intended for
>>>>>>>>>>>             discriminating among different types of logical
>>>>>>>> routers,
>>>>>>>>>>>             route virtualization, master-slave arrangements
>>>>>> etc.,
>>>>>>>>>>>             while keeping all routing instances in the same
>>>>>> flat
>>>>>>>>>>>             list.";
>>>>>>>>>>>        }
>>>>>>>>>>> 
>>>>>>>>>>> What is the "master-slave arrangements"?
>>>>>>>>>> 
>>>>>>>>>> This came from an early review by Thomas Morin, it has to do
>> with
>>>>>>>>>> MPLS/BGP VPNs where a master routing-instance exchanges
>> selected
>>>>>>>> routes
>>>>>>>>>> with each VPN/VRF.
>>>>>>>>> 
>>>>>>>>> Either it needs to be clarified in the spec, or it could simply
>> be
>>>>>>>> removed to avoid confusion since "route virtualization" covers
>> that
>>>>>>>> already.
>>>>>>>> 
>>>>>>>> This is actually a typo - it should be "router virtualization".
>> My
>>>>>>>> understanding of this term is that a virtual router is isolated
>> and
>>>>>>>> exchanges routing information with other routers only through
>>>> routing
>>>>>>>> protocols.
>>>>>>>> 
>>>>>>>> Anyway, these are really only examples and I think it is
>>>> sufficiently
>>>>>>>> clear that the core routing data model doesn't use these terms
>> for
>>>>>>>> defining any semantics.
>>>>>>>> 
>>>>>>>> Lada
>>>>>>>> 
>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> Depending on the definition of "logical router" and "route
>>>>>>>>>> virtualization", there may also be concerns with keeping all
>>>> those
>>>>>>>> kinds
>>>>>>>>>> of in the same flat list.
>>>>>>>>>> 
>>>>>>>>>> It is similar to interfaces, where physical and logical
>>>> interfaces
>>>>>> of
>>>>>>>>>> all kinds live in the same flat list and are distinguished by
>> the
>>>>>>>> type.
>>>>>>>>>> I think it could work, relationships among the individual
>> routing
>>>>>>>>>> instances can be expressed in other data.
>>>>>>>>> 
>>>>>>>>> I will defer to others about the merits of a flat list, but for
>> a
>>>>>> flat
>>>>>>>> list, the base spec needs to provide a way to express the
>>>>>> relationship.
>>>>>>>>> 
>>>>>>>>> Jeffrey
>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> Having a single flat list has its advantages, for example you
>> can
>>>>>>>> then
>>>>>>>>>> easily refer to routing instances via leafrefs (which allow
>> only
>>>>>> one
>>>>>>>>>> path).
>>>>>>>>>> 
>>>>>>>>>> Cheers, Lada
>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> Jeffrey Zhang
>>>>>>>>>>> Dean Bogdanovic
>>>>>>>>>> 
>>>>>>>>>> --
>>>>>>>>>> Ladislav Lhotka, CZ.NIC Labs
>>>>>>>>>> PGP Key ID: E74E8C0C
>>>>>>>> 
>>>>>>>> --
>>>>>>>> Ladislav Lhotka, CZ.NIC Labs
>>>>>>>> PGP Key ID: E74E8C0C
>>>>>> 
>>>>>> --
>>>>>> Ladislav Lhotka, CZ.NIC Labs
>>>>>> PGP Key ID: E74E8C0C
>>>> 
>>>> --
>>>> Ladislav Lhotka, CZ.NIC Labs
>>>> PGP Key ID: E74E8C0C
>>>> 
>>>> 
>>>> 
>>> 
>> 
>> --
>> Ladislav Lhotka, CZ.NIC Labs
>> PGP Key ID: E74E8C0C

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





From nobody Mon Jun 23 14:01:54 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51B691B2BDA for ; Mon, 23 Jun 2014 14:01:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.602
X-Spam-Level: 
X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s3VH4OLG7Yb2 for ; Mon, 23 Jun 2014 14:01:51 -0700 (PDT)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0210.outbound.protection.outlook.com [207.46.163.210]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD2751A0350 for ; Mon, 23 Jun 2014 14:01:50 -0700 (PDT)
Received: from BY2PR05MB079.namprd05.prod.outlook.com (10.242.38.16) by CO1PR05MB427.namprd05.prod.outlook.com (10.141.74.12) with Microsoft SMTP Server (TLS) id 15.0.959.24; Mon, 23 Jun 2014 21:01:42 +0000
Received: from BY2PR05MB079.namprd05.prod.outlook.com ([169.254.8.228]) by BY2PR05MB079.namprd05.prod.outlook.com ([169.254.8.228]) with mapi id 15.00.0969.007; Mon, 23 Jun 2014 21:01:40 +0000
From: "Jeffrey (Zhaohui) Zhang" 
To: Ladislav Lhotka 
Thread-Topic: [netmod] Questions/comments on draft-ietf-netmod-routing-cfg
Thread-Index: Ac+L5mG6QCip6E9wRnWAlQy1vx1YdgAlBfOAAACoQiAAj+tmAAAIpPrQAAReeoAAAeKmAAAFtCqAAAALMUAAAvtfgAAAFSEAAAG+eIAAAA438A==
Date: Mon, 23 Jun 2014 21:01:40 +0000
Message-ID: <27912b34cb3e4cbcac7ec89cd714b38a@BY2PR05MB079.namprd05.prod.outlook.com>
References:   <18cd777ffb9d4df6b0966dd1b3dd822b@BY2PR05MB079.namprd05.prod.outlook.com>     <45F6E463-82A0-4EF0-9EF7-E4B9D4EE7F80@nic.cz>  <4CC621BD-78B4-4945-91C8-D7FC0921CC91@nic.cz> <200d38920939408c9c426339e3fcf3e7@BY2PR05MB079.namprd05.prod.outlook.com> <3E7175EC-B8B4-4306-8715-F50249FE4C8C@nic.cz>
In-Reply-To: <3E7175EC-B8B4-4306-8715-F50249FE4C8C@nic.cz>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [66.129.241.18]
x-microsoft-antispam: BCL:0;PCL:0;RULEID:
x-forefront-prvs: 025100C802
x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(428001)(189002)(199002)(51704005)(106356001)(87936001)(105586002)(99286002)(95666004)(85852003)(21056001)(54356999)(31966008)(77096002)(74316001)(2656002)(83322001)(46102001)(74502001)(85306003)(74662001)(99396002)(81542001)(50986999)(76176999)(4396001)(80022001)(93886003)(20776003)(81342001)(64706001)(76482001)(77982001)(76576001)(66066001)(79102001)(92566001)(33646001)(83072002)(101416001)(86362001)(24736002)(106276001); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR05MB427; H:BY2PR05MB079.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; 
received-spf: None (: juniper.net does not designate permitted sender hosts)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=zzhang@juniper.net; 
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/c_enjr5ZS6fC1CiZtogt7nyxDBw
Cc: Kiran Agrahara Sreenivasa , "netmod@ietf.org" 
Subject: Re: [netmod] Questions/comments on draft-ietf-netmod-routing-cfg
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 23 Jun 2014 21:01:53 -0000

Lada,

> > Nobody is trying to argue which is better. I used this example to show =
that people from Cisco and Juniper interpreted the "routing-instance" diffe=
rent - a clear sign that the draft is far from "pretty clear".

> So which virtualization model do you want the ietf-routing module to adop=
t? I guess VMware people would have yet another idea of what a virtual rout=
er is.

I am not asking to adopt or restrict to any particular one. I am asking the=
 following:

- what is the definition (or example of) "logical router" and "virtual rout=
er" in the current spec; you could say it covers "anything" with examples l=
ike Cisco's or Juniper's or some specific vendor's "logical router" and "VR=
F" and "VRF-lite", and that's fine with me.

- with the above Cisco/Juniper terms, VRF or VRF-lites belong to LRs. If th=
ey're put into a flat list of "routing-instances", then each "routing-insta=
nce" needs indicate its "parent" instance (e.g. which LR a VRF belongs to).=
 This is very basic functionality for a modern router and if that needs to =
be specified in an extension module, then all protocol modules need to refe=
r to that extension module. If that's eventually what happens I can accept =
that, but to me it is just a lot better to include that well-known function=
ality in the base spec.

Jeffrey


From nobody Mon Jun 23 14:49:04 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3F201B2D07 for ; Mon, 23 Jun 2014 14:49:01 -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=[BAYES_00=-1.9, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M6SiLADW8X1y for ; Mon, 23 Jun 2014 14:48:57 -0700 (PDT)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0237.outbound.protection.outlook.com [207.46.163.237]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 960441B2D06 for ; Mon, 23 Jun 2014 14:48:57 -0700 (PDT)
Received: from BY2PR05MB079.namprd05.prod.outlook.com (10.242.38.16) by DM2PR05MB432.namprd05.prod.outlook.com (10.141.104.11) with Microsoft SMTP Server (TLS) id 15.0.969.15; Mon, 23 Jun 2014 21:48:56 +0000
Received: from BY2PR05MB079.namprd05.prod.outlook.com ([169.254.8.228]) by BY2PR05MB079.namprd05.prod.outlook.com ([169.254.8.228]) with mapi id 15.00.0969.007; Mon, 23 Jun 2014 21:48:54 +0000
From: "Jeffrey (Zhaohui) Zhang" 
To: Ladislav Lhotka , "stephane.litkowski@orange.com" , "netmod@ietf.org" , "Derek Man-Kit Yeung (myeung)" , Dean Bogdanovic 
Thread-Topic: [netmod] review of draft-litkowski-netmod-isis-cfg-00
Thread-Index: AQHPjYMNP7P9/Ki1SUGEnobO3kLbtpt/NMkA
Date: Mon, 23 Jun 2014 21:48:54 +0000
Message-ID: <39d54e563d1941a88504df9fc026de99@BY2PR05MB079.namprd05.prod.outlook.com>
References:  <26974_1403251511_53A3EB37_26974_17823_1_9E32478DFA9976438E7A22F69B08FF92022780@OPEXCLILM34.corporate.adroot.infra.ftgroup> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [66.129.241.18]
x-microsoft-antispam: BCL:0;PCL:0;RULEID:
x-forefront-prvs: 025100C802
x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(428001)(51704005)(189002)(377454003)(13464003)(199002)(2656002)(15202345003)(105586002)(106116001)(2201001)(85852003)(86362001)(575784001)(20776003)(106356001)(64706001)(4396001)(92566001)(99396002)(80022001)(87936001)(74316001)(83072002)(66066001)(101416001)(21056001)(99286002)(95666004)(76176999)(33646001)(54356999)(1941001)(46102001)(19580395003)(83322001)(19580405001)(76576001)(50986999)(76482001)(81542001)(74502001)(77096002)(81342001)(77982001)(15975445006)(74662001)(31966008)(79102001)(85306003)(24736002)(106276001); DIR:OUT; SFP:; SCL:1; SRVR:DM2PR05MB432; H:BY2PR05MB079.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; 
received-spf: None (: juniper.net does not designate permitted sender hosts)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=zzhang@juniper.net; 
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/FNuY0aNHJI1JWTzoDXYQ5JrZypo
Subject: Re: [netmod] review of draft-litkowski-netmod-isis-cfg-00
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 23 Jun 2014 21:49:01 -0000

[+ Derek, Dean]

Please see below.

> -----Original Message-----
> From: Ladislav Lhotka [mailto:lhotka@nic.cz]
> Sent: Saturday, June 21, 2014 8:52 AM
> To: stephane.litkowski@orange.com; netmod@ietf.org
> Subject: Re: [netmod] review of draft-litkowski-netmod-isis-cfg-00
>=20
> stephane.litkowski@orange.com writes:
>=20
> > Hi Lada,
> >
> > Thanks for your review.
> >
> > Please find inline comments.
> >
> > Best regards,
> >
> > Stephane
> >
> >
> > -----Original Message-----
> > From: Ladislav Lhotka [mailto:lhotka@nic.cz]
> > Sent: Thursday, June 19, 2014 16:34
> > To: netmod@ietf.org; LITKOWSKI Stephane SCE/IBNF
> > Subject: review of draft-litkowski-netmod-isis-cfg-00
> >
> > Hi,
> >
> > I reviewed the isis module and I-D. I think it is a good start,
> although some adjustments will be needed to make it work with the core
> routing data model, see below. I don't address any specific issues of
> IS-IS configuration.
> >
> > *** General Comments
> >     - As Andy already pointed out, descriptions are often missing or
> >       too brief, and the prose in the I-D is also extremely scarce.
> >     - An example instance document would be useful, e.g. a reply to
> >        as in Appendix A of RFC 7277. (The "sample-skeleton"
> >       plugin of pyang can help with generating it.)
> >
> > [SLI] Sure I will take this into account.
> >
> > *** YANG module design
> >     - Entries of the "rt:routing-protocol" list (under both "routing"
> >       and "routing-state") are designed to support multiple instances
> >       of the same protocol. In configuration it means not only that
> >       the nodes "isis-cfg", "instances" and "instance" are
> >       superfluous, but this design also prevents connecting different
> >       ISIS instances to different RIBs.
> >
> > [SLI] Ok I didn't catch this point, for me there was only one protocol
> instance per type indexed by its name "isis" or "ospf" in the same
> routing instance.
> > If it's not the case, I would remove the instances for ISIS.

For OSPFv3, there is a specific instance concept in the protocol (see RFC 6=
969). For ISIS, I don't see it.

Stephane, with your original draft (before Lada's comment), what is your de=
finition of instance for ISIS? Using Cisco terms, is it that rt:routing-ins=
tnace is a "logical router" (http://www.cisco.com/c/en/us/td/docs/ios_xr_sw=
/iosxr_r3-2/interfaces/configuration/guide/int_c32/hc32logr.pdf) and for ea=
ch child VRF (or VRF-lite) there could be an ISIS instance, and those would=
 be listed in your list of instances under isis-cfg, and under a rt:routing=
-instance that is a VRF there will be no rt:routing-protocol for ISIS?


>=20
> Yes, please. Maybe the routing-cfg draft can be more explicit about the
> possibility of having multiple instances of the same protocol in the
> "routing-protocol" list.

Lada, Cisco supports the following configuration:

router ospfv3 1
!
address-family ipv4 unicast
exit-address-family
!
address-family ipv6 unicast
exit-address-family

IPv4/v6 address families will have their own protocol instance. If I unders=
tand you correctly, the "arbitrary name of the routing protocol instance" t=
hat is the key for the list of routing-protocols under an instance will nee=
d to include address family information, which is difficult.

>=20
> > The OSPF model (draft-yeung-netmod-ospf) sounds also to implement a
> list of instances for OSPF protocol :
> > " augment "/rt:routing/rt:routing-instance/rt:routing-protocols/"
> >          + "rt:routing-protocol" {
> >      list ospf-router {
> >
> >        description
> >          "This is a top-level container for the OSPF router.";
> >
> >        when "./type=3Dospf";
> >
> >        key "version name";
> >        leaf version {
> >          description
> >            "OSPF version.";
> >          type uint8 {
> >            range "2..3";
> >          }
> >        }
> > "
>=20
> This should be changed, too.

We need to discuss that. I'll forward you some email.

Jeffrey

>=20
> Lada
>=20
> >
> >
> >     - Similarly, state data for each ISIS instance should go straight
> >       to the corresponding entry of "routing-protocol" under
> >       "routing-state".
> >
> > [SLI] Ack
> >
> >     - Nodes in state data should use descriptive names rather than
> >       "TLVnnn". TLV numbers are important for the protocol but IMO
> >       there is no need to expose operators to them. For instance,
> >       "dynamic-hostname" is better than "TLV137".
> >
> > [SLI] Ok, sometimes TLV numbers are more understable than
> descriptions :)
> >
> >     - Grouping "interface-cfg" is used only once, so it is not
> >       needed. Other groupings are used at least twice.
> >
> >   [SLI] Ack
> >
> >     - A type definition for ISO addresses might be useful.
> >
> > [SLI] Ack
> >
> > *** Specific YANG issues
> >     - The module is invalid, I am attaching a diff file with
> >       necessary changes. Module validity should always be verified
> >       before posting an I-D, e.g. with pyang.
> >
> > [SLI] Ok , I checked it but without importing modules, so only syntax
> checking was done.
> >
> >     - The argument of "namespace" should be an URI, e.g. urn:TBD.
> >
> > [SLI] Ok
> >
> >     - Arguments of some "augment" statements are broken, see the
> >       attached diff. In particular, they must not contain trailing
> >       slashes, see ABNF production "absolute-schema-nodeid".
> >     - The module should follow the guidelines of RFC 6087, they can
> >       be checked using
> >
> >       pyang --ietf isis.yang
> >
> > *** Formal issues
> >     - The module text should be wrapped in
> >
> >        file "isis@2014-XX-XX.yang"
> >       ...
> >       
> >
> >       so that it can be easily extracted with rfcstrip.
> >     - Assuming the module is bound for standard track, its name
> >       should be "ietf-isis".
> >     - Some descriptions exceed the line length limit of 72 characters,
> >       line breaks should be inserted.
> >
> > [SLI] Will be fixed.
> >
> >
> > Lada
> >
> >
> ________________________________________________________________________
> _________________________________________________
> >
> > Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc
> > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez
> recu ce message par erreur, veuillez le signaler
> > a l'expediteur et le detruire ainsi que les pieces jointes. Les
> messages electroniques etant susceptibles d'alteration,
> > Orange decline toute responsabilite si ce message a ete altere,
> deforme ou falsifie. Merci.
> >
> > This message and its attachments may contain confidential or
> privileged information that may be protected by law;
> > they should not be distributed, used or copied without authorisation.
> > If you have received this email in error, please notify the sender and
> delete this message and its attachments.
> > As emails may be altered, Orange is not liable for messages that have
> been modified, changed or falsified.
> > Thank you.
> >
>=20
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>=20


From nobody Tue Jun 24 00:10:24 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AB581B2856 for ; Tue, 24 Jun 2014 00:10:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f9R2mdkWxjQj for ; Tue, 24 Jun 2014 00:10:20 -0700 (PDT)
Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25A811B285D for ; Tue, 24 Jun 2014 00:10:18 -0700 (PDT)
Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda09.si.francetelecom.fr (ESMTP service) with ESMTP id 13FA8C0B6B; Tue, 24 Jun 2014 09:10:16 +0200 (CEST)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.55]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id D9145158078; Tue, 24 Jun 2014 09:10:15 +0200 (CEST)
Received: from OPEXCLILM34.corporate.adroot.infra.ftgroup ([169.254.4.50]) by OPEXCLILH03.corporate.adroot.infra.ftgroup ([10.114.31.55]) with mapi id 14.03.0181.006; Tue, 24 Jun 2014 09:10:16 +0200
From: 
To: "Jeffrey (Zhaohui) Zhang" , Ladislav Lhotka , "netmod@ietf.org" , "Derek Man-Kit Yeung (myeung)" , Dean Bogdanovic 
Thread-Topic: [netmod] review of draft-litkowski-netmod-isis-cfg-00
Thread-Index: AQHPi8uWJFGHlwdDlUmsWj3oo3i2J5t5ob4ggAHEXYCAA7qhAIAAvL9A
Date: Tue, 24 Jun 2014 07:10:15 +0000
Message-ID: <17043_1403593815_53A92457_17043_2843_3_9E32478DFA9976438E7A22F69B08FF9202372E@OPEXCLILM34.corporate.adroot.infra.ftgroup>
References:  <26974_1403251511_53A3EB37_26974_17823_1_9E32478DFA9976438E7A22F69B08FF92022780@OPEXCLILM34.corporate.adroot.infra.ftgroup>  <39d54e563d1941a88504df9fc026de99@BY2PR05MB079.namprd05.prod.outlook.com>
In-Reply-To: <39d54e563d1941a88504df9fc026de99@BY2PR05MB079.namprd05.prod.outlook.com>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.168.234.1]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.6.24.40922
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/0SpilerJb4_3pFn_R5U1o9aC7gw
Subject: Re: [netmod] review of draft-litkowski-netmod-isis-cfg-00
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 Jun 2014 07:10:22 -0000

Hi Jeffrey,

Pls see inline comments


Best Regards,

Stephane


-----Original Message-----
From: Jeffrey (Zhaohui) Zhang [mailto:zzhang@juniper.net]=20
Sent: Monday, June 23, 2014 23:49
To: Ladislav Lhotka; LITKOWSKI Stephane SCE/IBNF; netmod@ietf.org; Derek Ma=
n-Kit Yeung (myeung); Dean Bogdanovic
Subject: RE: [netmod] review of draft-litkowski-netmod-isis-cfg-00

[+ Derek, Dean]

Please see below.

> >
> > *** YANG module design
> >     - Entries of the "rt:routing-protocol" list (under both "routing"
> >       and "routing-state") are designed to support multiple instances
> >       of the same protocol. In configuration it means not only that
> >       the nodes "isis-cfg", "instances" and "instance" are
> >       superfluous, but this design also prevents connecting different
> >       ISIS instances to different RIBs.
> >
> > [SLI] Ok I didn't catch this point, for me there was only one=20
> > protocol
> instance per type indexed by its name "isis" or "ospf" in the same=20
> routing instance.
> > If it's not the case, I would remove the instances for ISIS.

For OSPFv3, there is a specific instance concept in the protocol (see RFC 6=
969). For ISIS, I don't see it.

Stephane, with your original draft (before Lada's comment), what is your de=
finition of instance for ISIS? Using Cisco terms, is it that rt:routing-ins=
tnace is a "logical router" (http://www.cisco.com/c/en/us/td/docs/ios_xr_sw=
/iosxr_r3-2/interfaces/configuration/guide/int_c32/hc32logr.pdf) and for ea=
ch child VRF (or VRF-lite) there could be an ISIS instance, and those would=
 be listed in your list of instances under isis-cfg, and under a rt:routing=
-instance that is a VRF there will be no rt:routing-protocol for ISIS?


[SLI] No the idea was to be able to have multiple ISIS instance within the =
same routing-instance. Most of implementations are authorizing such behavio=
r (e.g. two L2 ISIS process within global routing table). This is similar f=
rom what exists with OSPF (even for v2) since years ...


___________________________________________________________________________=
______________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.


From nobody Tue Jun 24 01:30:29 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C028A1B299A for ; Tue, 24 Jun 2014 01:30:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D1obn-T46EDJ for ; Tue, 24 Jun 2014 01:30:23 -0700 (PDT)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 379EB1B299F for ; Tue, 24 Jun 2014 01:30:22 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 669495408D4; Tue, 24 Jun 2014 10:30:20 +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 OiUeOyyI5LvH; Tue, 24 Jun 2014 10:30:15 +0200 (CEST)
Received: from localhost (unknown [172.29.2.201]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 1A355540336; Tue, 24 Jun 2014 10:30:13 +0200 (CEST)
From: Ladislav Lhotka 
To: "Jeffrey \(Zhaohui\) Zhang" 
In-Reply-To: <27912b34cb3e4cbcac7ec89cd714b38a@BY2PR05MB079.namprd05.prod.outlook.com>
References:   <18cd777ffb9d4df6b0966dd1b3dd822b@BY2PR05MB079.namprd05.prod.outlook.com>     <45F6E463-82A0-4EF0-9EF7-E4B9D4EE7F80@nic.cz>  <4CC621BD-78B4-4945-91C8-D7FC0921CC91@nic.cz> <200d38920939408c9c426339e3fcf3e7@BY2PR05MB079.namprd05.prod.outlook.com> <3E7175EC-B8B4-4306-8715-F50249FE4C8C@nic.cz> <27912b34cb3e4cbcac7ec89cd714b38a@BY2PR05MB079.namprd05.prod.outlook.com>
User-Agent: Notmuch/0.18 (http://notmuchmail.org) Emacs/24.3.50.2 (x86_64-apple-darwin13.0.0)
Date: Tue, 24 Jun 2014 10:30:12 +0200
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/VEaz025sD6exB_uK0OOb1vOgApo
Cc: Kiran Agrahara Sreenivasa , "netmod@ietf.org" 
Subject: Re: [netmod] Questions/comments on draft-ietf-netmod-routing-cfg
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 Jun 2014 08:30:25 -0000

"Jeffrey (Zhaohui) Zhang"  writes:

> Lada,
>
>> > Nobody is trying to argue which is better. I used this example to show that people from Cisco and Juniper interpreted the "routing-instance" different - a clear sign that the draft is far from "pretty clear".
>
>> So which virtualization model do you want the ietf-routing module to adopt? I guess VMware people would have yet another idea of what a virtual router is.
>
> I am not asking to adopt or restrict to any particular one. I am asking the following:
>
> - what is the definition (or example of) "logical router" and "virtual router" in the current spec; you could say it covers "anything" with examples like Cisco's or Juniper's or some specific vendor's "logical router" and "VRF" and "VRF-lite", and that's fine with me.

Yes, this is how I understand the following paragraph in sec. 5.1:

   Each routing instance in the core routing data model represents a
   logical router.  The exact semantics of this term are left to
   implementations.  For example, routing instances may be completely
   isolated virtual routers or, alternatively, they may internally share
   certain information.

>
> - with the above Cisco/Juniper terms, VRF or VRF-lites belong to LRs. If they're put into a > flat list of "routing-instances", then each "routing-instance" needs indicate its "parent"
> instance (e.g. which LR a VRF belongs to). This is very basic functionality for a modern

Right, and this is what I'd expect a YANG module defining VRF or VRF-lite to do, using the "augment" statement. 

It is very similar to the ietf-interfaces, where the "interface" list is designed to contain anything that other modules define - physical or various logical interfaces.

> router and if that needs to be specified in an extension module, then all protocol modules
> need to refer to that extension module. If that's eventually what happens I can accept that, > but to me it is just a lot better to include that well-known functionality in the base spec.

Yes, implementations will have to advertise modules for specific routing instance type(s) they support. Just as they will have to advertise, e.g., an Ethernet module along with ietf-interfaces.

Lada

>
> Jeffrey

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


From nobody Tue Jun 24 01:53:10 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70BF41A0640 for ; Tue, 24 Jun 2014 01:53:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.3
X-Spam-Level: 
X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_44=0.6] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uV4xG2V9kHCN for ; Tue, 24 Jun 2014 01:53:05 -0700 (PDT)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E5551A041D for ; Tue, 24 Jun 2014 01:53:05 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 993CB5408D4; Tue, 24 Jun 2014 10:53:03 +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 jQ2KTU5GtTnz; Tue, 24 Jun 2014 10:52:58 +0200 (CEST)
Received: from localhost (unknown [172.29.2.201]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 6F742540647; Tue, 24 Jun 2014 10:52:57 +0200 (CEST)
From: Ladislav Lhotka 
To: "Jeffrey \(Zhaohui\) Zhang" , "stephane.litkowski\@orange.com" , "netmod\@ietf.org" , "Derek Man-Kit Yeung \(myeung\)" , Dean Bogdanovic 
In-Reply-To: <39d54e563d1941a88504df9fc026de99@BY2PR05MB079.namprd05.prod.outlook.com>
References:  <26974_1403251511_53A3EB37_26974_17823_1_9E32478DFA9976438E7A22F69B08FF92022780@OPEXCLILM34.corporate.adroot.infra.ftgroup>  <39d54e563d1941a88504df9fc026de99@BY2PR05MB079.namprd05.prod.outlook.com>
User-Agent: Notmuch/0.18 (http://notmuchmail.org) Emacs/24.3.50.2 (x86_64-apple-darwin13.0.0)
Date: Tue, 24 Jun 2014 10:52:56 +0200
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/Tu-ZaHKdKjjiie-9RDvO_tco0UE
Subject: Re: [netmod] review of draft-litkowski-netmod-isis-cfg-00
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 Jun 2014 08:53:08 -0000

"Jeffrey (Zhaohui) Zhang"  writes:

> [+ Derek, Dean]
>
> Please see below.
>
>> -----Original Message-----
>> From: Ladislav Lhotka [mailto:lhotka@nic.cz]
>> Sent: Saturday, June 21, 2014 8:52 AM
>> To: stephane.litkowski@orange.com; netmod@ietf.org
>> Subject: Re: [netmod] review of draft-litkowski-netmod-isis-cfg-00
>> 
>> stephane.litkowski@orange.com writes:
>> 
>> > Hi Lada,
>> >
>> > Thanks for your review.
>> >
>> > Please find inline comments.
>> >
>> > Best regards,
>> >
>> > Stephane
>> >
>> >
>> > -----Original Message-----
>> > From: Ladislav Lhotka [mailto:lhotka@nic.cz]
>> > Sent: Thursday, June 19, 2014 16:34
>> > To: netmod@ietf.org; LITKOWSKI Stephane SCE/IBNF
>> > Subject: review of draft-litkowski-netmod-isis-cfg-00
>> >
>> > Hi,
>> >
>> > I reviewed the isis module and I-D. I think it is a good start,
>> although some adjustments will be needed to make it work with the core
>> routing data model, see below. I don't address any specific issues of
>> IS-IS configuration.
>> >
>> > *** General Comments
>> >     - As Andy already pointed out, descriptions are often missing or
>> >       too brief, and the prose in the I-D is also extremely scarce.
>> >     - An example instance document would be useful, e.g. a reply to
>> >        as in Appendix A of RFC 7277. (The "sample-skeleton"
>> >       plugin of pyang can help with generating it.)
>> >
>> > [SLI] Sure I will take this into account.
>> >
>> > *** YANG module design
>> >     - Entries of the "rt:routing-protocol" list (under both "routing"
>> >       and "routing-state") are designed to support multiple instances
>> >       of the same protocol. In configuration it means not only that
>> >       the nodes "isis-cfg", "instances" and "instance" are
>> >       superfluous, but this design also prevents connecting different
>> >       ISIS instances to different RIBs.
>> >
>> > [SLI] Ok I didn't catch this point, for me there was only one protocol
>> instance per type indexed by its name "isis" or "ospf" in the same
>> routing instance.
>> > If it's not the case, I would remove the instances for ISIS.
>
> For OSPFv3, there is a specific instance concept in the protocol (see RFC 6969). For ISIS, I don't see it.
>
> Stephane, with your original draft (before Lada's comment), what is your definition of instance for ISIS? Using Cisco terms, is it that rt:routing-instnace is a "logical router" (http://www.cisco.com/c/en/us/td/docs/ios_xr_sw/iosxr_r3-2/interfaces/configuration/guide/int_c32/hc32logr.pdf) and for each child VRF (or VRF-lite) there could be an ISIS instance, and those would be listed in your list of instances under isis-cfg, and under a rt:routing-instance that is a VRF there will be no rt:routing-protocol for ISIS?

My understanding is that Stephane's draft deals with routing *protocol* instances (entries of the "routing-protocol" list), and not routing instances (entries of the "routing-instance" list). It may be a little confusing - the ietf-routing draft originally used the term "router" instead of "routing-instance" but this change in terminology was one of the "harmonisation" items with the I2RS RIB info model.  

>
>
>> 
>> Yes, please. Maybe the routing-cfg draft can be more explicit about the
>> possibility of having multiple instances of the same protocol in the
>> "routing-protocol" list.
>
> Lada, Cisco supports the following configuration:
>
> router ospfv3 1
> !
> address-family ipv4 unicast
> exit-address-family
> !
> address-family ipv6 unicast
> exit-address-family
>
> IPv4/v6 address families will have their own protocol instance. If I understand you

They may or may not, depending on how the protocol data model is designed.

> correctly, the "arbitrary name of the routing protocol instance" that is the key for the
> list of routing-protocols under an instance will need to include address family information, > which is difficult.

I don't tink so. Just add an "address-family" leaf under "routing-protocol" - or add a leaf-list or list that configures multiple address families within the same routing protocol instance.

>
>> 
>> > The OSPF model (draft-yeung-netmod-ospf) sounds also to implement a
>> list of instances for OSPF protocol :
>> > " augment "/rt:routing/rt:routing-instance/rt:routing-protocols/"
>> >          + "rt:routing-protocol" {
>> >      list ospf-router {
>> >
>> >        description
>> >          "This is a top-level container for the OSPF router.";
>> >
>> >        when "./type=ospf";
>> >
>> >        key "version name";
>> >        leaf version {
>> >          description
>> >            "OSPF version.";
>> >          type uint8 {
>> >            range "2..3";
>> >          }
>> >        }
>> > "
>> 
>> This should be changed, too.
>
> We need to discuss that. I'll forward you some email.

OK, but I think "ospf-router" should be a container, not a list, because "rt:routing-protocol" is already a list, and it can contain multiple instances of the same protocol.

Lada

>
> Jeffrey
>
>> 
>> Lada
>> 
>> >
>> >
>> >     - Similarly, state data for each ISIS instance should go straight
>> >       to the corresponding entry of "routing-protocol" under
>> >       "routing-state".
>> >
>> > [SLI] Ack
>> >
>> >     - Nodes in state data should use descriptive names rather than
>> >       "TLVnnn". TLV numbers are important for the protocol but IMO
>> >       there is no need to expose operators to them. For instance,
>> >       "dynamic-hostname" is better than "TLV137".
>> >
>> > [SLI] Ok, sometimes TLV numbers are more understable than
>> descriptions :)
>> >
>> >     - Grouping "interface-cfg" is used only once, so it is not
>> >       needed. Other groupings are used at least twice.
>> >
>> >   [SLI] Ack
>> >
>> >     - A type definition for ISO addresses might be useful.
>> >
>> > [SLI] Ack
>> >
>> > *** Specific YANG issues
>> >     - The module is invalid, I am attaching a diff file with
>> >       necessary changes. Module validity should always be verified
>> >       before posting an I-D, e.g. with pyang.
>> >
>> > [SLI] Ok , I checked it but without importing modules, so only syntax
>> checking was done.
>> >
>> >     - The argument of "namespace" should be an URI, e.g. urn:TBD.
>> >
>> > [SLI] Ok
>> >
>> >     - Arguments of some "augment" statements are broken, see the
>> >       attached diff. In particular, they must not contain trailing
>> >       slashes, see ABNF production "absolute-schema-nodeid".
>> >     - The module should follow the guidelines of RFC 6087, they can
>> >       be checked using
>> >
>> >       pyang --ietf isis.yang
>> >
>> > *** Formal issues
>> >     - The module text should be wrapped in
>> >
>> >        file "isis@2014-XX-XX.yang"
>> >       ...
>> >       
>> >
>> >       so that it can be easily extracted with rfcstrip.
>> >     - Assuming the module is bound for standard track, its name
>> >       should be "ietf-isis".
>> >     - Some descriptions exceed the line length limit of 72 characters,
>> >       line breaks should be inserted.
>> >
>> > [SLI] Will be fixed.
>> >
>> >
>> > Lada
>> >
>> >
>> ________________________________________________________________________
>> _________________________________________________
>> >
>> > Ce message et ses pieces jointes peuvent contenir des informations
>> confidentielles ou privilegiees et ne doivent donc
>> > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez
>> recu ce message par erreur, veuillez le signaler
>> > a l'expediteur et le detruire ainsi que les pieces jointes. Les
>> messages electroniques etant susceptibles d'alteration,
>> > Orange decline toute responsabilite si ce message a ete altere,
>> deforme ou falsifie. Merci.
>> >
>> > This message and its attachments may contain confidential or
>> privileged information that may be protected by law;
>> > they should not be distributed, used or copied without authorisation.
>> > If you have received this email in error, please notify the sender and
>> delete this message and its attachments.
>> > As emails may be altered, Orange is not liable for messages that have
>> been modified, changed or falsified.
>> > Thank you.
>> >
>> 
>> --
>> Ladislav Lhotka, CZ.NIC Labs
>> PGP Key ID: E74E8C0C
>> 
>

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


From nobody Tue Jun 24 05:39:02 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2820E1B2905 for ; Tue, 24 Jun 2014 05:38:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Yqycj_64s71 for ; Tue, 24 Jun 2014 05:38:55 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0184.outbound.protection.outlook.com [207.46.163.184]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D8151B2900 for ; Tue, 24 Jun 2014 05:38:54 -0700 (PDT)
Received: from BN1PR05MB424.namprd05.prod.outlook.com (10.141.58.148) by BN1PR05MB074.namprd05.prod.outlook.com (10.255.199.12) with Microsoft SMTP Server (TLS) id 15.0.954.9; Tue, 24 Jun 2014 12:38:51 +0000
Received: from BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.141]) by BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.155]) with mapi id 15.00.0954.000; Tue, 24 Jun 2014 12:38:52 +0000
From: Dean Bogdanovic 
To: Ladislav Lhotka 
Thread-Topic: [netmod] Questions/comments on draft-ietf-netmod-routing-cfg
Thread-Index: Ac+L5mG6QCip6E9wRnWAlQy1vx1YdgAlBfOAAACoQiAAj+tmAAAIpPrQAAReeoAAAeKmAAAFtCqAAAALMUAAAvtfgAAAFSEAAAG+eIAAAA438AAY7FIAAAiuzoA=
Date: Tue, 24 Jun 2014 12:38:51 +0000
Message-ID: 
References:   <18cd777ffb9d4df6b0966dd1b3dd822b@BY2PR05MB079.namprd05.prod.outlook.com>     <45F6E463-82A0-4EF0-9EF7-E4B9D4EE7F80@nic.cz>  <4CC621BD-78B4-4945-91C8-D7FC0921CC91@nic.cz> <200d38920939408c9c426339e3fcf3e7@BY2PR05MB079.namprd05.prod.outlook.com> <3E7175EC-B8B4-4306-8715-F50249FE4C8C@nic.cz> <27912b34cb3e4cbcac7ec89cd714b38a@BY2PR05MB079.namprd05.prod.outlook.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-mailer: Apple Mail (2.1510)
x-originating-ip: [66.129.241.14]
x-microsoft-antispam: BL:0; ACTION:Default; RISK:Low; SCL:0; SPMLVL:NotSpam; PCL:0; RULEID:
x-forefront-prvs: 02524402D6
x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(377454003)(51704005)(199002)(189002)(50986999)(76176999)(31966008)(77156001)(83072002)(85852003)(93886003)(46102001)(89996001)(92726001)(85306003)(74502001)(64706001)(87936001)(101416001)(20776003)(99396002)(21056001)(74662001)(87286001)(66066001)(33656002)(62966002)(2656002)(80022001)(19580395003)(104166001)(83322001)(19580405001)(575784001)(93916002)(36756003)(86362001)(81542001)(50226001)(83716003)(4396001)(106356001)(79102001)(81342001)(77096002)(105586002)(92566001)(82746002)(77982001)(76482001)(57306001)(99286002)(95666004)(104396001); DIR:OUT; SFP:; SCL:1; SRVR:BN1PR05MB074; H:BN1PR05MB424.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; 
Content-Type: text/plain; charset="us-ascii"
Content-ID: <8E1BC222E56E544EA14382B35D2FDA70@namprd05.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/jnamAV-i3sRPoLdF2N3QVC0tmlg
Cc: "Jeffrey \(Zhaohui\) Zhang" , Kiran Agrahara Sreenivasa , "netmod@ietf.org" 
Subject: Re: [netmod] Questions/comments on draft-ietf-netmod-routing-cfg
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 Jun 2014 12:38:59 -0000

On Jun 24, 2014, at 4:30 AM, Ladislav Lhotka  wrote:

> "Jeffrey (Zhaohui) Zhang"  writes:
>=20
>> Lada,
>>=20
>>>> Nobody is trying to argue which is better. I used this example to show=
 that people from Cisco and Juniper interpreted the "routing-instance" diff=
erent - a clear sign that the draft is far from "pretty clear".
>>=20
>>> So which virtualization model do you want the ietf-routing module to ad=
opt? I guess VMware people would have yet another idea of what a virtual ro=
uter is.
>>=20
>> I am not asking to adopt or restrict to any particular one. I am asking =
the following:
>>=20
>> - what is the definition (or example of) "logical router" and "virtual r=
outer" in the current spec; you could say it covers "anything" with example=
s like Cisco's or Juniper's or some specific vendor's "logical router" and =
"VRF" and "VRF-lite", and that's fine with me.
>=20
> Yes, this is how I understand the following paragraph in sec. 5.1:
>=20
>   Each routing instance in the core routing data model represents a
>   logical router.  The exact semantics of this term are left to
>   implementations.  For example, routing instances may be completely
>   isolated virtual routers or, alternatively, they may internally share
>   certain information.
But based on this you are saying that routing instance is logical router an=
d that is confusing with vendors understanding of logical router. Logical r=
outer is container of routing instances in Cisco and Juniper case

>=20
>>=20
>> - with the above Cisco/Juniper terms, VRF or VRF-lites belong to LRs. If=
 they're put into a > flat list of "routing-instances", then each "routing-=
instance" needs indicate its "parent"
>> instance (e.g. which LR a VRF belongs to). This is very basic functional=
ity for a modern
>=20
> Right, and this is what I'd expect a YANG module defining VRF or VRF-lite=
 to do, using the "augment" statement.=20
>=20
> It is very similar to the ietf-interfaces, where the "interface" list is =
designed to contain anything that other modules define - physical or variou=
s logical interfaces.
>=20
>> router and if that needs to be specified in an extension module, then al=
l protocol modules
>> need to refer to that extension module. If that's eventually what happen=
s I can accept that, > but to me it is just a lot better to include that we=
ll-known functionality in the base spec.
>=20
> Yes, implementations will have to advertise modules for specific routing =
instance type(s) they support. Just as they will have to advertise, e.g., a=
n Ethernet module along with ietf-interfaces.
>=20
> Lada
>=20
>>=20
>> Jeffrey
>=20
> --=20
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C


From nobody Tue Jun 24 06:28:05 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 219A11B29D3 for ; Tue, 24 Jun 2014 06:28:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.302
X-Spam-Level: 
X-Spam-Status: No, score=-1.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RP_MATCHES_RCVD=-0.651] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BNka16vtdPyJ for ; Tue, 24 Jun 2014 06:28:02 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 484F51B2935 for ; Tue, 24 Jun 2014 06:28: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 0FE951400FA; Tue, 24 Jun 2014 15:27:58 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1403616479; bh=e0vmadRN6Yl5DsA9gYOmoIrZXdYB5b2EX/DYq4tK+a8=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=MmckOTXvh/KrJ2lnLkt4+kj1pd+WefyQOnhHPIAqSjScUX06ObssHF+97TjwMVHDn OPLQqPL6ai1hpM50qCSW7o1jzH5S7jHF7/sjiCucqXo79PFfH3P4fQQIXgv8h0sVfj 9sigzBI3dt7iWL1c7aOvBcp3d7tSjY1XsD4600NA=
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
From: Ladislav Lhotka 
In-Reply-To: 
Date: Tue, 24 Jun 2014 15:27:58 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <474E3D5A-B5DF-4704-88C3-8EE8765FEDD0@nic.cz>
References:   <18cd777ffb9d4df6b0966dd1b3dd822b@BY2PR05MB079.namprd05.prod.outlook.com>     <45F6E463-82A0-4EF0-9EF7-E4B9D4EE7F80@nic.cz>  <4CC621BD-78B4-4945-91C8-D7FC0921CC91@nic.cz> <200d38920939408c9c426339e3fcf3e7@BY2PR05MB079.namprd05.prod.outlook.com> <3E7175EC-B8B4-4306-8715-F50249FE4C8C@nic.cz> <27912b34cb3e4cbcac7ec89cd714b38a@BY2PR05MB079.namprd05.prod.outlook.com>  
To: Dean Bogdanovic 
X-Mailer: Apple Mail (2.1878.2)
X-Virus-Scanned: clamav-milter 0.98.1 at mail
X-Virus-Status: Clean
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/yhIEZLMaJ82Lm-dPcc1sh6AaESQ
Cc: "Jeffrey \(Zhaohui\) Zhang" , Kiran Agrahara Sreenivasa , "netmod@ietf.org" 
Subject: Re: [netmod] Questions/comments on draft-ietf-netmod-routing-cfg
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 Jun 2014 13:28:04 -0000

On 24 Jun 2014, at 14:38, Dean Bogdanovic  wrote:

>=20
> On Jun 24, 2014, at 4:30 AM, Ladislav Lhotka  wrote:
>=20
>> "Jeffrey (Zhaohui) Zhang"  writes:
>>=20
>>> Lada,
>>>=20
>>>>> Nobody is trying to argue which is better. I used this example to =
show that people from Cisco and Juniper interpreted the =
"routing-instance" different - a clear sign that the draft is far from =
"pretty clear".
>>>=20
>>>> So which virtualization model do you want the ietf-routing module =
to adopt? I guess VMware people would have yet another idea of what a =
virtual router is.
>>>=20
>>> I am not asking to adopt or restrict to any particular one. I am =
asking the following:
>>>=20
>>> - what is the definition (or example of) "logical router" and =
"virtual router" in the current spec; you could say it covers "anything" =
with examples like Cisco's or Juniper's or some specific vendor's =
"logical router" and "VRF" and "VRF-lite", and that's fine with me.
>>=20
>> Yes, this is how I understand the following paragraph in sec. 5.1:
>>=20
>>  Each routing instance in the core routing data model represents a
>>  logical router.  The exact semantics of this term are left to
>>  implementations.  For example, routing instances may be completely
>>  isolated virtual routers or, alternatively, they may internally =
share
>>  certain information.
> But based on this you are saying that routing instance is logical =
router and that is confusing with vendors understanding of logical =
router. Logical router is container of routing instances in Cisco and =
Juniper case

Do you mean =93routing instance=94 to be an instance of a routing =
*protocol*? I do admit this is confusing but I2RS guys really insisted =
of the term =93routing instance=94. See also their definition in =
draft-ietf-i2rs-rib-info-model-03:

=93A routing instance, in the context of the RIB information model, is a =
collection of RIBs, interfaces, and routing parameters.  A routing =
instance creates a logical slice of the router and allows different =
logical slices =85=94

Isn=92t it what Cisco and Juniper call =93logical router=94?

Actually, now I see the above definition of =93routing instance=94 in =
the routing-cfg I-D could/should be improved. The intention is not to =
allow implementations to use an arbitrary concept of a logical router: =
its config/state data and semantics has to be defined in a YANG module =
together with its type identity, and only then it can be used.

Lada

>>=20
>>>=20
>>> - with the above Cisco/Juniper terms, VRF or VRF-lites belong to =
LRs. If they're put into a > flat list of "routing-instances", then each =
"routing-instance" needs indicate its "parent"
>>> instance (e.g. which LR a VRF belongs to). This is very basic =
functionality for a modern
>>=20
>> Right, and this is what I'd expect a YANG module defining VRF or =
VRF-lite to do, using the "augment" statement.=20
>>=20
>> It is very similar to the ietf-interfaces, where the "interface" list =
is designed to contain anything that other modules define - physical or =
various logical interfaces.
>>=20
>>> router and if that needs to be specified in an extension module, =
then all protocol modules
>>> need to refer to that extension module. If that's eventually what =
happens I can accept that, > but to me it is just a lot better to =
include that well-known functionality in the base spec.
>>=20
>> Yes, implementations will have to advertise modules for specific =
routing instance type(s) they support. Just as they will have to =
advertise, e.g., an Ethernet module along with ietf-interfaces.
>>=20
>> Lada
>>=20
>>>=20
>>> Jeffrey
>>=20
>> --=20
>> Ladislav Lhotka, CZ.NIC Labs
>> PGP Key ID: E74E8C0C
>=20

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





From nobody Tue Jun 24 06:51:04 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A22F61B29CF for ; Tue, 24 Jun 2014 06:51:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7OJaq-g3bq_u for ; Tue, 24 Jun 2014 06:50:58 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0140.outbound.protection.outlook.com [207.46.163.140]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EEBDF1B2951 for ; Tue, 24 Jun 2014 06:50:57 -0700 (PDT)
Received: from BY2PR05MB079.namprd05.prod.outlook.com (10.242.38.16) by CO1PR05MB427.namprd05.prod.outlook.com (10.141.74.12) with Microsoft SMTP Server (TLS) id 15.0.959.24; Tue, 24 Jun 2014 13:50:55 +0000
Received: from BY2PR05MB079.namprd05.prod.outlook.com ([169.254.8.228]) by BY2PR05MB079.namprd05.prod.outlook.com ([169.254.8.228]) with mapi id 15.00.0969.007; Tue, 24 Jun 2014 13:50:55 +0000
From: "Jeffrey (Zhaohui) Zhang" 
To: Ladislav Lhotka , Dean Bogdanovic 
Thread-Topic: [netmod] Questions/comments on draft-ietf-netmod-routing-cfg
Thread-Index: Ac+L5mG6QCip6E9wRnWAlQy1vx1YdgAlBfOAAACoQiAAj+tmAAAIpPrQAAReeoAAAeKmAAAFtCqAAAALMUAAAvtfgAAAFSEAAAG+eIAAAA438AAY7FIAAAiuzoAAAbdwAAAAkTww
Date: Tue, 24 Jun 2014 13:50:54 +0000
Message-ID: 
References:   <18cd777ffb9d4df6b0966dd1b3dd822b@BY2PR05MB079.namprd05.prod.outlook.com>     <45F6E463-82A0-4EF0-9EF7-E4B9D4EE7F80@nic.cz>  <4CC621BD-78B4-4945-91C8-D7FC0921CC91@nic.cz> <200d38920939408c9c426339e3fcf3e7@BY2PR05MB079.namprd05.prod.outlook.com> <3E7175EC-B8B4-4306-8715-F50249FE4C8C@nic.cz> <27912b34cb3e4cbcac7ec89cd714b38a@BY2PR05MB079.namprd05.prod.outlook.com>   <474E3D5A-B5DF-4704-88C3-8EE8765FEDD0@nic.cz>
In-Reply-To: <474E3D5A-B5DF-4704-88C3-8EE8765FEDD0@nic.cz>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [66.129.241.13]
x-microsoft-antispam: BCL:0;PCL:0;RULEID:
x-forefront-prvs: 02524402D6
x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(199002)(243025005)(189002)(377454003)(51704005)(13464003)(79102001)(83322001)(92566001)(81342001)(76576001)(76482001)(20776003)(80022001)(66066001)(93886003)(64706001)(77982001)(83072002)(86362001)(575784001)(33646001)(101416001)(15975445006)(74316001)(2656002)(105586002)(19580395003)(95666004)(99286002)(106356001)(87936001)(21056001)(85852003)(77096002)(54356999)(31966008)(4396001)(99396002)(50986999)(81542001)(76176999)(19580405001)(46102001)(85306003)(15202345003)(74502001)(74662001)(24736002)(106276001); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR05MB427; H:BY2PR05MB079.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; 
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/_7nBZegKCEge9HVpcGKyprlJS-Y
Cc: Kiran Agrahara Sreenivasa , "netmod@ietf.org" 
Subject: Re: [netmod] Questions/comments on draft-ietf-netmod-routing-cfg
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 Jun 2014 13:51:01 -0000

We're converging :-)

> -----Original Message-----
> From: Ladislav Lhotka [mailto:lhotka@nic.cz]
> Sent: Tuesday, June 24, 2014 9:28 AM
> To: Dean Bogdanovic
> Cc: Jeffrey (Zhaohui) Zhang; Alia Atlas; netmod@ietf.org; Kiran Agrahara
> Sreenivasa
> Subject: Re: [netmod] Questions/comments on draft-ietf-netmod-routing-
> cfg
>=20
>=20
> On 24 Jun 2014, at 14:38, Dean Bogdanovic  wrote:
>=20
> >
> > On Jun 24, 2014, at 4:30 AM, Ladislav Lhotka  wrote:
> >
> >> "Jeffrey (Zhaohui) Zhang"  writes:
> >>
> >>> Lada,
> >>>
> >>>>> Nobody is trying to argue which is better. I used this example to
> show that people from Cisco and Juniper interpreted the "routing-
> instance" different - a clear sign that the draft is far from "pretty
> clear".
> >>>
> >>>> So which virtualization model do you want the ietf-routing module
> to adopt? I guess VMware people would have yet another idea of what a
> virtual router is.
> >>>
> >>> I am not asking to adopt or restrict to any particular one. I am
> asking the following:
> >>>
> >>> - what is the definition (or example of) "logical router" and
> "virtual router" in the current spec; you could say it covers "anything"
> with examples like Cisco's or Juniper's or some specific vendor's
> "logical router" and "VRF" and "VRF-lite", and that's fine with me.
> >>
> >> Yes, this is how I understand the following paragraph in sec. 5.1:
> >>
> >>  Each routing instance in the core routing data model represents a
> >>  logical router.  The exact semantics of this term are left to
> >>  implementations.  For example, routing instances may be completely
> >>  isolated virtual routers or, alternatively, they may internally
> share
> >>  certain information.
> > But based on this you are saying that routing instance is logical
> router and that is confusing with vendors understanding of logical
> router. Logical router is container of routing instances in Cisco and
> Juniper case
>=20
> Do you mean "routing instance" to be an instance of a routing *protocol*?

No.

> I do admit this is confusing but I2RS guys really insisted of the term
> "routing instance". See also their definition in draft-ietf-i2rs-rib-
> info-model-03:
>=20
> "A routing instance, in the context of the RIB information model, is a
> collection of RIBs, interfaces, and routing parameters.  A routing
> instance creates a logical slice of the router and allows different
> logical slices ..."

Good that you dig out this definition :-)

That corresponds to Cisco's VRF/VRF-lite, or Juniper's VRF/VR, not logical =
router.

>=20
> Isn't it what Cisco and Juniper call "logical router"?

No. Cisco's and Juniper's logical routers are similar (I was told they were=
 different but apparently they are) and definitions are here:

http://www.cisco.com/c/en/us/td/docs/ios_xr_sw/iosxr_r3-2/interfaces/config=
uration/guide/int_c32/hc32logr.pdf
http://www.juniper.net/techpubs/en_US/junos13.3/topics/concept/logical-syst=
ems-overview-solutions.html

A single LR can have multiple VR or VRF-lites.

Jeffrey

>=20
> Actually, now I see the above definition of "routing instance" in the
> routing-cfg I-D could/should be improved. The intention is not to allow
> implementations to use an arbitrary concept of a logical router: its
> config/state data and semantics has to be defined in a YANG module
> together with its type identity, and only then it can be used.
>=20
> Lada
>=20
> >>
> >>>
> >>> - with the above Cisco/Juniper terms, VRF or VRF-lites belong to LRs.
> If they're put into a > flat list of "routing-instances", then each
> "routing-instance" needs indicate its "parent"
> >>> instance (e.g. which LR a VRF belongs to). This is very basic
> functionality for a modern
> >>
> >> Right, and this is what I'd expect a YANG module defining VRF or VRF-
> lite to do, using the "augment" statement.
> >>
> >> It is very similar to the ietf-interfaces, where the "interface" list
> is designed to contain anything that other modules define - physical or
> various logical interfaces.
> >>
> >>> router and if that needs to be specified in an extension module,
> then all protocol modules
> >>> need to refer to that extension module. If that's eventually what
> happens I can accept that, > but to me it is just a lot better to
> include that well-known functionality in the base spec.
> >>
> >> Yes, implementations will have to advertise modules for specific
> routing instance type(s) they support. Just as they will have to
> advertise, e.g., an Ethernet module along with ietf-interfaces.
> >>
> >> Lada
> >>
> >>>
> >>> Jeffrey
> >>
> >> --
> >> Ladislav Lhotka, CZ.NIC Labs
> >> PGP Key ID: E74E8C0C
> >
>=20
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>=20
>=20
>=20


From nobody Tue Jun 24 07:44:56 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 442281B2AAE for ; Tue, 24 Jun 2014 07:44:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d9GbLqvuvxVB for ; Tue, 24 Jun 2014 07:44:51 -0700 (PDT)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8ABD1B2A4E for ; Tue, 24 Jun 2014 07:44:50 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id CF4725408D4; Tue, 24 Jun 2014 16:44: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 F4dvoUQk+4bP; Tue, 24 Jun 2014 16:44:44 +0200 (CEST)
Received: from localhost (unknown [172.29.2.201]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id AC5E8540336; Tue, 24 Jun 2014 16:44:43 +0200 (CEST)
From: Ladislav Lhotka 
To: "Jeffrey \(Zhaohui\) Zhang" , Dean Bogdanovic 
In-Reply-To: 
References:   <18cd777ffb9d4df6b0966dd1b3dd822b@BY2PR05MB079.namprd05.prod.outlook.com>     <45F6E463-82A0-4EF0-9EF7-E4B9D4EE7F80@nic.cz>  <4CC621BD-78B4-4945-91C8-D7FC0921CC91@nic.cz> <200d38920939408c9c426339e3fcf3e7@BY2PR05MB079.namprd05.prod.outlook.com> <3E7175EC-B8B4-4306-8715-F50249FE4C8C@nic.cz> <27912b34cb3e4cbcac7ec89cd714b38a@BY2PR05MB079.namprd05.prod.outlook.com>   <474E3D5A-B5DF-4704-88C3-8EE8765FEDD0@nic.cz> 
User-Agent: Notmuch/0.18 (http://notmuchmail.org) Emacs/24.3.50.2 (x86_64-apple-darwin13.0.0)
Date: Tue, 24 Jun 2014 16:44:42 +0200
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/JCC6xNGyxvqn-yDLsYYmpEFIGk0
Cc: Kiran Agrahara Sreenivasa , "netmod@ietf.org" 
Subject: Re: [netmod] Questions/comments on draft-ietf-netmod-routing-cfg
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 Jun 2014 14:44:55 -0000

"Jeffrey (Zhaohui) Zhang"  writes:

> We're converging :-)

Good. :-)

...

>
> A single LR can have multiple VR or VRF-lites.
>

Right, and the truth is "routing-instance" list in the ietf-routing module is intended to harbour both! The organization can be for example as follows (in JSON):

"routing-instance":
  [
    { "name": "LR1",
      "type": "logical-router",
      ...
    },
    { "name": "VRF1",
      "type": "VRF-lite",
      "logical-router": "LR1",
      ...
    },
    { "name": "VRF2",
      "type": "VRF-lite",
      "logical-router": "LR1",
      ...
    }
  ]

Lada

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


From nobody Tue Jun 24 12:43:40 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B9381A037B for ; Tue, 24 Jun 2014 12:43:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.602
X-Spam-Level: 
X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oRgkCSBoamg3 for ; Tue, 24 Jun 2014 12:43:35 -0700 (PDT)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0240.outbound.protection.outlook.com [207.46.163.240]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58B391A02B0 for ; Tue, 24 Jun 2014 12:43:35 -0700 (PDT)
Received: from BY2PR05MB079.namprd05.prod.outlook.com (10.242.38.16) by BLUPR05MB417.namprd05.prod.outlook.com (10.141.27.15) with Microsoft SMTP Server (TLS) id 15.0.954.9; Tue, 24 Jun 2014 19:43:32 +0000
Received: from BY2PR05MB079.namprd05.prod.outlook.com ([169.254.8.228]) by BY2PR05MB079.namprd05.prod.outlook.com ([169.254.8.228]) with mapi id 15.00.0969.007; Tue, 24 Jun 2014 19:43:30 +0000
From: "Jeffrey (Zhaohui) Zhang" 
To: Ladislav Lhotka , Dean Bogdanovic , "stephane.litkowski@orange.com" 
Thread-Topic: [netmod] Questions/comments on draft-ietf-netmod-routing-cfg
Thread-Index: Ac+L5mG6QCip6E9wRnWAlQy1vx1YdgAlBfOAAACoQiAAj+tmAAAIpPrQAAReeoAAAeKmAAAFtCqAAAALMUAAAvtfgAAAFSEAAAG+eIAAAA438AAY7FIAAAiuzoAAAbdwAAAAkTwwAAIc0AAACkNB0A==
Date: Tue, 24 Jun 2014 19:43:30 +0000
Message-ID: <35c42b5636f848ad88d16f887e2e9853@BY2PR05MB079.namprd05.prod.outlook.com>
References:   <18cd777ffb9d4df6b0966dd1b3dd822b@BY2PR05MB079.namprd05.prod.outlook.com>     <45F6E463-82A0-4EF0-9EF7-E4B9D4EE7F80@nic.cz>  <4CC621BD-78B4-4945-91C8-D7FC0921CC91@nic.cz> <200d38920939408c9c426339e3fcf3e7@BY2PR05MB079.namprd05.prod.outlook.com> <3E7175EC-B8B4-4306-8715-F50249FE4C8C@nic.cz> <27912b34cb3e4cbcac7ec89cd714b38a@BY2PR05MB079.namprd05.prod.outlook.com>   <474E3D5A-B5DF-4704-88C3-8EE8765FEDD0@nic.cz>  
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [66.129.241.13]
x-microsoft-antispam: BL:0; ACTION:Default; RISK:Low; SCL:0; SPMLVL:NotSpam; PCL:0; RULEID:
x-forefront-prvs: 02524402D6
x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(377454003)(13464003)(51704005)(189002)(199002)(31966008)(92566001)(79102001)(66066001)(20776003)(74662001)(80022001)(81342001)(74316001)(76576001)(81542001)(64706001)(74502001)(99396002)(86362001)(575784001)(77096002)(4396001)(33646001)(99286002)(101416001)(76482001)(93886003)(105586002)(19580395003)(19580405001)(83322001)(77982001)(21056001)(2656002)(54356999)(85852003)(87936001)(76176999)(83072002)(95666004)(50986999)(46102001)(85306003)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR05MB417; H:BY2PR05MB079.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; 
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/pEw7JY9CDychwZ94Hkv3Poc4KIc
Cc: Kiran Agrahara Sreenivasa , "netmod@ietf.org" 
Subject: Re: [netmod] Questions/comments on draft-ietf-netmod-routing-cfg
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 Jun 2014 19:43:38 -0000

Lada,

I believe the definition of routing-instance in i2rs, as you quoted earlier=
, does not include LR? It's a "collection of RIBs, interfaces, and routing =
parameters" which maps to VR/VRF/VRF-lite, while an LR is a collection of r=
outing-instances.

Additionally, Stephane articulated very well in another thread (about ISIS =
YANG module) why LR should not be included.

Jeffrey

> -----Original Message-----
> From: Ladislav Lhotka [mailto:lhotka@nic.cz]
> Sent: Tuesday, June 24, 2014 10:45 AM
> To: Jeffrey (Zhaohui) Zhang; Dean Bogdanovic
> Cc: Alia Atlas; netmod@ietf.org; Kiran Agrahara Sreenivasa
> Subject: RE: [netmod] Questions/comments on draft-ietf-netmod-routing-
> cfg
>=20
> "Jeffrey (Zhaohui) Zhang"  writes:
>=20
> > We're converging :-)
>=20
> Good. :-)
>=20
> ...
>=20
> >
> > A single LR can have multiple VR or VRF-lites.
> >
>=20
> Right, and the truth is "routing-instance" list in the ietf-routing
> module is intended to harbour both! The organization can be for example
> as follows (in JSON):
>=20
> "routing-instance":
>   [
>     { "name": "LR1",
>       "type": "logical-router",
>       ...
>     },
>     { "name": "VRF1",
>       "type": "VRF-lite",
>       "logical-router": "LR1",
>       ...
>     },
>     { "name": "VRF2",
>       "type": "VRF-lite",
>       "logical-router": "LR1",
>       ...
>     }
>   ]
>=20
> Lada
>=20
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C


From nobody Tue Jun 24 14:22:12 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3899A1B296F for ; Tue, 24 Jun 2014 14:22:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.201
X-Spam-Level: 
X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RQTJr4zkiyBD for ; Tue, 24 Jun 2014 14:22:00 -0700 (PDT)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E51D51B29ED for ; Tue, 24 Jun 2014 14:11:19 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 660251442 for ; Tue, 24 Jun 2014 23:11:18 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id ZietTxi8NIyj for ; Tue, 24 Jun 2014 23:11:09 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Tue, 24 Jun 2014 23:11:17 +0200 (CEST)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9F4122003A for ; Tue, 24 Jun 2014 23:11:17 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id jPPJHuN6a15j; Tue, 24 Jun 2014 23:11:16 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 66C2A20039; Tue, 24 Jun 2014 23:11:16 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id D4CE32D9668F; Tue, 24 Jun 2014 23:11:15 +0200 (CEST)
Date: Tue, 24 Jun 2014 23:11:15 +0200
From: Juergen Schoenwaelder 
To: netmod@ietf.org
Message-ID: <20140624211115.GA19944@elstar.local>
Mail-Followup-To: netmod@ietf.org
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="r5Pyd7+fXNt84Ff3"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
User-Agent: Mutt/1.4.2.3i
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/Y-W3YRdpbLbrCrPvPKGgYHEQ04o
Subject: [netmod] [agenda@ietf.org: netmod - Requested session has been scheduled for IETF 90]
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
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, 24 Jun 2014 21:22:02 -0000

--r5Pyd7+fXNt84Ff3
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

Hi,

the draft agenda has our meeting scheduled for Monday morning. Note
that agenda changes are still possible but so far it seems we have
the NETMOD and NETCONF meetings on Mon/Tue (plus the YANG doctors
session in Sunday).

/js

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

--r5Pyd7+fXNt84Ff3
Content-Type: message/rfc822
Content-Disposition: inline
Content-Transfer-Encoding: 8bit

Received: from hermes.jacobs-university.de (212.201.44.23) by
 SHUBCAS02.jacobs.jacobs-university.de (10.70.0.128) with Microsoft SMTP
 Server (TLS) id 14.3.181.6; Mon, 23 Jun 2014 20:31:58 +0200
Received: from atlas1.jacobs-university.de (atlas1a.jacobs-university.de
 [212.201.44.13])	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384
 (256/256 bits))	(Client CN "atlas1.jacobs-university.de", Issuer "Jacobs
 University CA - G01" (verified OK))	by hermes.jacobs-university.de (Postfix)
 with ESMTPS id E585C2002C	for ; Mon, 23
 Jun 2014 20:31:58 +0200 (CEST)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47])	by
 atlas1.jacobs-university.de (Postfix) with ESMTP id D04046BC	for
 ; Mon, 23 Jun 2014 20:31:58 +0200
 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
X-Spam-Flag: NO
X-Spam-Score: -0.71
X-Spam-Level: 
X-Spam-Status: No, score=-0.71 tagged_above=-100 required=6.2
	tests=[BAYES_00=-1.5, KAM_ASCII_DIVIDERS=0.8, T_RP_MATCHES_RCVD=-0.01]
	autolearn=no
Received: from atlas1b.jacobs-university.de ([212.201.44.13])	by localhost
 (demetrius2.jacobs-university.de [212.201.44.47]) (amavisd-new, port 10030)
	with ESMTP id RbshDimHfReJ for ;	Mon,
 23 Jun 2014 20:31:58 +0200 (CEST)
X-JacobsISPWhiteListed: No
X-policyd-weight: using cached result; rate:hard: -6.1
Received: from mail.ietf.org (mail.ietf.org [4.31.198.44])	(using TLSv1.2 with
 cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))	(Client did not present a
 certificate)	by atlas1b.jacobs-university.de (Postfix) with ESMTPS	for
 ; Mon, 23 Jun 2014 20:31:58 +0200
 (CEST)
Received: from localhost (ietfa.amsl.com [127.0.0.1])	by ietfa.amsl.com
 (Postfix) with ESMTP id A1BF91B2C2F;	Mon, 23 Jun 2014 11:31:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
Received: from mail.ietf.org ([4.31.198.44])	by localhost (ietfa.amsl.com
 [127.0.0.1]) (amavisd-new, port 10024)	with ESMTP id apPI4eKJ6PyJ; Mon, 23
 Jun 2014 11:31:55 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1])	by ietfa.amsl.com
 (Postfix) with ESMTP id 76CF21B2C37;	Mon, 23 Jun 2014 11:31:17 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: "\"IETF Secretariat\"" 
To: 
CC: , ,
	
Subject: netmod - Requested session has been scheduled for IETF 90
X-Test-IDTracker: no
X-IETF-IDTracker: 5.5.0.p3
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20140623183117.30660.43058.idtracker@ietfa.amsl.com>
Date: Mon, 23 Jun 2014 11:31:17 -0700
Return-Path: agenda@ietf.org
X-MS-Exchange-Organization-AuthSource: SHUBCAS02.jacobs.jacobs-university.de
X-MS-Exchange-Organization-AuthAs: Anonymous
MIME-Version: 1.0

Dear Jürgen Schönwälder,

The session(s) that you have requested have been scheduled.
Below is the scheduled session information followed by
the original request. 

netmod Session 1 (2:30:00)
    Monday, Morning Session I 0900-1130
    Room Name: Salon B size: 120
    ---------------------------------------------
    


Request Information:


---------------------------------------------------------
Working Group Name: NETCONF Data Modeling Language
Area Name: Operations and Management Area
Session Requester: Jürgen Schönwälder

Number of Sessions: 1
Length of Session(s):  2.5 Hours
Number of Attendees: 50
Conflicts to Avoid: 
 First Priority: eman lmap i2rs opsawg opsarea netconf sfc
 Second Priority: ipfix 6lo



Special Requests:
  If possible please schedule NETCONF and NETMOD sessions on subsequent days or the same day, avoid Friday slots if possible.
---------------------------------------------------------


--r5Pyd7+fXNt84Ff3--


From nobody Wed Jun 25 01:26:52 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C3971B2B0D for ; Wed, 25 Jun 2014 01:26:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.092
X-Spam-Level: 
X-Spam-Status: No, score=-1.092 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RP_MATCHES_RCVD=-0.651, T_DKIM_INVALID=0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PaVzKFUd5yc5 for ; Wed, 25 Jun 2014 01:26:41 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 517241B2B0F for ; Wed, 25 Jun 2014 01:26:41 -0700 (PDT)
Received: from [IPv6:2001:1488:fffe:6:711a:266e:c94d:c7bc] (unknown [IPv6:2001:1488:fffe:6:711a:266e:c94d:c7bc]) by mail.nic.cz (Postfix) with ESMTPSA id 6BF9414026C; Wed, 25 Jun 2014 10:26:39 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1403684799; bh=NAGpOBZpOdXYcNvOLAX1wzjE00c4xPsTPyB9tlI7yHs=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=Og57TvtJ0iGdpJhODGE5RkmhECbxmttCTtxFNb30DJJkfzw/dVe/cL2LnXP54xi1t RmaT8XSFOUn5kM7QxbZyHv/eg5QGS2O7pw/hHuvmrfpbRmWdhVtopBIVqN5z6o/5FR DQU0ZfsZH+Xld7EVMhH0lKw+N/dwxiu6NhJbMmGs=
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
From: Ladislav Lhotka 
In-Reply-To: <35c42b5636f848ad88d16f887e2e9853@BY2PR05MB079.namprd05.prod.outlook.com>
Date: Wed, 25 Jun 2014 10:26:41 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:   <18cd777ffb9d4df6b0966dd1b3dd822b@BY2PR05MB079.namprd05.prod.outlook.com>     <45F6E463-82A0-4EF0-9EF7-E4B9D4EE7F80@nic.cz>  <4CC621BD-78B4-4945-91C8-D7FC0921CC91@nic.cz> <200d38920939408c9c426339e3fcf3e7@BY2PR05MB079.namprd05.prod.outlook.com> <3E7175EC-B8B4-4306-8715-F50249FE4C8C@nic.cz> <27912b34cb3e4cbcac7ec89cd714b38a@BY2PR05MB079.namprd05.prod.outlook.com>   <474E3D5A-B5DF-4704-88C3-8EE8765FEDD0@nic.cz>   <35c42b5636f848ad88d16f887e2e9853@BY 2PR05MB079.namprd05.prod.outlook.com>
To: "Jeffrey (Zhaohui) Zhang" 
X-Mailer: Apple Mail (2.1878.2)
X-Virus-Scanned: clamav-milter 0.98.1 at mail
X-Virus-Status: Clean
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/y8P2hkPrZQQjql0t-HVZgDmSW4s
Cc: Kiran Agrahara Sreenivasa , "netmod@ietf.org" 
Subject: Re: [netmod] Questions/comments on draft-ietf-netmod-routing-cfg
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 25 Jun 2014 08:26:43 -0000

On 24 Jun 2014, at 21:43, Jeffrey (Zhaohui) Zhang  =
wrote:

> Lada,
>=20
> I believe the definition of routing-instance in i2rs, as you quoted =
earlier, does not include LR? It's a "collection of RIBs, interfaces, =
and routing parameters" which maps to VR/VRF/VRF-lite, while an LR is a =
collection of routing-instances.

I am still not convinced the I2RS definition excludes logical =
routers/systems ("A routing instance creates a logical slice of the =
router =85=94).

In any case, the definition of routing instance in routing-cfg (sec. =
5.1) was really intended to include *both* logical routers/systems =
(=93completely isolated virtual routers=94) and VRFs that =93internally =
share certain information=94.

I think it was Phil Shafer of Juniper who requested the addition of the =
top-level list (originally =93router=94, now =93routing-instance=94) and =
I remember we explicitly discussed JUNOS logical systems.

>=20
> Additionally, Stephane articulated very well in another thread (about =
ISIS YANG module) why LR should not be included.

In this case it would suffice to write a module defining a data model =
for VRF/VRF-lite instances via augmenting =93routing-instance=94. I can =
help with it if you want.

Lada

>=20
> Jeffrey
>=20
>> -----Original Message-----
>> From: Ladislav Lhotka [mailto:lhotka@nic.cz]
>> Sent: Tuesday, June 24, 2014 10:45 AM
>> To: Jeffrey (Zhaohui) Zhang; Dean Bogdanovic
>> Cc: Alia Atlas; netmod@ietf.org; Kiran Agrahara Sreenivasa
>> Subject: RE: [netmod] Questions/comments on =
draft-ietf-netmod-routing-
>> cfg
>>=20
>> "Jeffrey (Zhaohui) Zhang"  writes:
>>=20
>>> We're converging :-)
>>=20
>> Good. :-)
>>=20
>> ...
>>=20
>>>=20
>>> A single LR can have multiple VR or VRF-lites.
>>>=20
>>=20
>> Right, and the truth is "routing-instance" list in the ietf-routing
>> module is intended to harbour both! The organization can be for =
example
>> as follows (in JSON):
>>=20
>> "routing-instance":
>>  [
>>    { "name": "LR1",
>>      "type": "logical-router",
>>      ...
>>    },
>>    { "name": "VRF1",
>>      "type": "VRF-lite",
>>      "logical-router": "LR1",
>>      ...
>>    },
>>    { "name": "VRF2",
>>      "type": "VRF-lite",
>>      "logical-router": "LR1",
>>      ...
>>    }
>>  ]
>>=20
>> Lada
>>=20
>> --
>> Ladislav Lhotka, CZ.NIC Labs
>> PGP Key ID: E74E8C0C

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





From nobody Wed Jun 25 06:51:40 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36E461B2CB6 for ; Wed, 25 Jun 2014 06:51:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.602
X-Spam-Level: 
X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UBABBCLUDKXw for ; Wed, 25 Jun 2014 06:51:34 -0700 (PDT)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0207.outbound.protection.outlook.com [207.46.163.207]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C576E1B2CB2 for ; Wed, 25 Jun 2014 06:51:33 -0700 (PDT)
Received: from BN1PR05MB424.namprd05.prod.outlook.com (10.141.58.148) by BN1PR05MB073.namprd05.prod.outlook.com (10.255.199.11) with Microsoft SMTP Server (TLS) id 15.0.954.9; Wed, 25 Jun 2014 13:51:30 +0000
Received: from BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.141]) by BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.155]) with mapi id 15.00.0954.000; Wed, 25 Jun 2014 13:51:30 +0000
From: Dean Bogdanovic 
To: "netmod@ietf.org" 
Thread-Topic: static routes in draft-ietf-netmod-routing-cfg-15
Thread-Index: AQHPkHyQ0orIXWpDoUyLtj2fzemmwQ==
Date: Wed, 25 Jun 2014 13:51:29 +0000
Message-ID: <6CCE7829-D078-41B0-8578-300563AD7CB8@juniper.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-mailer: Apple Mail (2.1510)
x-originating-ip: [66.129.241.14]
x-microsoft-antispam: BL:0; ACTION:Default; RISK:Low; SCL:0; SPMLVL:NotSpam; PCL:0; RULEID:
x-forefront-prvs: 02530BD3AA
x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(199002)(189002)(101416001)(77982001)(83072002)(85852003)(46102001)(104166001)(77156001)(50986999)(33656002)(92566001)(83322001)(87286001)(2656002)(86362001)(76482001)(92726001)(87936001)(21056001)(93916002)(82746002)(89996001)(106116001)(99396002)(50226001)(105586002)(62966002)(81542001)(106356001)(79102001)(99286002)(81342001)(95666004)(36756003)(88136002)(4396001)(66066001)(83716003)(77096002)(74662001)(31966008)(64706001)(80022001)(85306003)(74502001)(107046001)(20776003)(104396001); DIR:OUT; SFP:; SCL:1; SRVR:BN1PR05MB073; H:BN1PR05MB424.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; 
Content-Type: text/plain; charset="us-ascii"
Content-ID: <2CFD2183FFC3B348B8CB1DB2166ADE03@namprd05.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/5JfHylhHLeG5auCSkHWnXIRy2M4
Cc: "Jeffrey \(Zhaohui\) Zhang" 
Subject: [netmod] static routes in draft-ietf-netmod-routing-cfg-15
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 25 Jun 2014 13:51:36 -0000

Hi,

While reading routing-cfg, looking at the static route model
 augment "/rt:routing/rt:routing-instance/rt:routing-protocols/"
          + "rt:routing-protocol/rt:static-routes" {
      ...
      container ipv4 {
        description
          "Configuration of a 'static' pseudo-protocol instance
           consists of a list of routes.";
        list route {
          key "id";
          ordered-by "user";
          description
            "A user-ordered list of static routes.";
          leaf id {
            type uint32 {
              range "1..max";
            }
            description
              "Unique numeric identifier of the route.

               This value is unrelated to system-assigned 'id'
               parameters of routes in RIBs.";
          }

got confused that each static route is identified by an "id". Originally th=
ought it could be metric, but after reading description, wasn't sure.=20

Lada explained that the id is used in case same prefixes are configured, bu=
t have different metric. So why not use prefix and preference as unique ide=
ntifier? One could even argue that the base spec only needs to use prefix a=
s the key, and if an implementation supports multiple static routes for the=
 same prefix they can extend as an optional feature.

There was an email exchange on this topic offline and we are curious what d=
oes the WG think about this "id"?

Dean



From nobody Wed Jun 25 08:54:46 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DD271B2CC9 for ; Wed, 25 Jun 2014 08:54:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level: 
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cMSyvzEqTGGE for ; Wed, 25 Jun 2014 08:54:42 -0700 (PDT)
Received: from mail-qc0-f169.google.com (mail-qc0-f169.google.com [209.85.216.169]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 715DE1B2D25 for ; Wed, 25 Jun 2014 08:54:42 -0700 (PDT)
Received: by mail-qc0-f169.google.com with SMTP id c9so1914335qcz.14 for ; Wed, 25 Jun 2014 08:54:41 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=24C3MWIFC78qg6o5SJjfdIRaUJ44agoKbKRDg9t+qY8=; b=MEQ1XyCGSzy8tM+WG8+2I2MtPqrhyz2c1yOnUJJEFTROW48F+MPwxSPFsIh73bQrX6 v9gv2t0Tdi5kIGAshm4B1LAZwU3fHKAjik0fYXnMmWWj9kHPau1ZpASx1e0C8ZYptaH9 42NEIZiT30CCAkyFbuvCo+FVHpdDQ5Y15kZ2MyLw6fHfoTwZrUy6UiB8a30ajFRUXe7w qe/IlX3kBTqFPlWby2Wlhy4XQ8tYS9zxeYBlq9s5K6GObzk3vTZJr+fWRb9yvCBDZHib aE3rR9RXBO4CvsrVzgh/ledHnbnB8CPfHhPStzLlcmsyok/lkYzCpGKtzRbKX1VMSqWA qCKQ==
X-Gm-Message-State: ALoCoQkYhK3EITx44+RaLFvNAvoPIOeF/jw3tPH7QVowp4LivB3uP+GWjVdFq3NtsgfB4aVP/r8J
MIME-Version: 1.0
X-Received: by 10.140.103.74 with SMTP id x68mr12302530qge.34.1403711681274; Wed, 25 Jun 2014 08:54:41 -0700 (PDT)
Received: by 10.140.104.48 with HTTP; Wed, 25 Jun 2014 08:54:41 -0700 (PDT)
Date: Wed, 25 Jun 2014 08:54:41 -0700
Message-ID: 
From: Andy Bierman 
To: "netmod@ietf.org" 
Content-Type: multipart/alternative; boundary=001a1134eda823bb4604fcab1802
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/Ogdgbjr_D6H7XMsyjLgSyb05Wtg
Subject: [netmod] possible YANG 1.1 issue: node ordering
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 25 Jun 2014 15:54:44 -0000

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

Hi,

I am wondering if there is any interoperability issues with the lack
of data node ordering for top-level and augment nodes.

RFC 6020, sec. 5.1.2, para 2:

   NETCONF is capable of carrying any XML content as the payload in the
    and  elements.  The top-level nodes of YANG modules
   are encoded as child elements, in any order, within these elements.
   This encapsulation guarantees that the corresponding NETCONF messages
   are always well-formed XML documents.

sec. 7.15.2

   When a node is augmented, the augmenting child nodes are encoded as
   subelements to the augmented node, in any order.

Note the "in any order" in both sections.
Of course, system-ordered leaf-list and list nodes can be in any order as
well.
The text in 7.15.2 seems to say the augmenting nodes can be mixed
in with the augmented nodes, even though all examples show them
added at the end.

Do tools that compare configurations or server implementations consuming
a configuration care about the lack of standard canonical ordering?
I don't know if any normative changes are needed in YANG 1.1, but
there should (at least) be some warning against attempting to compare
XML instance documents (even from the same server seconds apart).


Andy

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


Hi,

I am wondering if there is any inte=
roperability issues with the lack
of data node ordering for top-l=
evel and augment nodes.

RFC 6020, sec. 5.1.2,=
 para 2:
   NETCONF is capable of carrying any X=
ML content as the payload in the
   <config> and <data> elements.  The top-level nodes of YANG m=
odules
   are encoded as child elements, in any order, within these elements.
   This encapsulation guarantees that the corresponding NETCONF messages
   are always well-formed XML documents.


sec. 7.15.2
   When a node is augmented, the augmenting child nodes =
are encoded as
   subelements to the augmented node, in any order.
Note the &qu=
ot;in any order" in both sections.
Of course, system-ordered=
 leaf-list and list nodes can be in any order as well.
The text i=
n 7.15.2 seems to say the augmenting nodes can be mixed


in with the augmented nodes, even though all examples show them
<=
div>added at the end.

Do tools that compare config=
urations or server implementations consuming
a configuration care=
 about the lack of standard canonical ordering?


I don't know if any normative changes are needed in YANG 1.1, but<=
/div>
there should (at least) be some warning against attempting to com=
pare
XML instance documents (even from the same server seconds ap=
art).




Andy


<=
/div>




--001a1134eda823bb4604fcab1802--


From nobody Wed Jun 25 09:53:35 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 979411B2A4F for ; Wed, 25 Jun 2014 09:53:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.302
X-Spam-Level: 
X-Spam-Status: No, score=-1.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RP_MATCHES_RCVD=-0.651] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LIzM1ZJGqhRj for ; Wed, 25 Jun 2014 09:53:31 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B70CA1B2A10 for ; Wed, 25 Jun 2014 09:53:29 -0700 (PDT)
Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 5516C140353; Wed, 25 Jun 2014 18:53:27 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1403715207; bh=OPseZaNxDccgQT8X650vi5DW1oouJIB/ISBnlPbN73k=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=hDYNbuqQbllXjNVVCbopTkAZjDm6901TWQHmENCPlwDl4bVht5HyZU86WKfGbLR2F g/7yT0GtnVLK89OlZjDIVFdqOVSoCrfzyiBjGBLRhYS8y0eNc13vTxF9WaM3Vdtulp bEIkGR+gjao8UaFTUOYf4LUkXGYsa06lLDb006wE=
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
From: Ladislav Lhotka 
In-Reply-To: <6CCE7829-D078-41B0-8578-300563AD7CB8@juniper.net>
Date: Wed, 25 Jun 2014 18:47:47 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <4F17ABF3-F1E4-4EA3-9F8F-02B02162554D@nic.cz>
References: <6CCE7829-D078-41B0-8578-300563AD7CB8@juniper.net>
To: Dean Bogdanovic 
X-Mailer: Apple Mail (2.1878.2)
X-Virus-Scanned: clamav-milter 0.98.1 at mail
X-Virus-Status: Clean
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/b02fdpzQBaqABFpPDlIV_VwVRJg
Cc: "Jeffrey \(Zhaohui\) Zhang" , "netmod@ietf.org" 
Subject: Re: [netmod] static routes in draft-ietf-netmod-routing-cfg-15
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 25 Jun 2014 16:53:33 -0000

On 25 Jun 2014, at 15:51, Dean Bogdanovic  wrote:

> Hi,
>=20
> While reading routing-cfg, looking at the static route model
> augment "/rt:routing/rt:routing-instance/rt:routing-protocols/"
>         + "rt:routing-protocol/rt:static-routes" {
>     ...
>     container ipv4 {
>       description
>         "Configuration of a 'static' pseudo-protocol instance
>          consists of a list of routes.";
>       list route {
>         key "id";
>         ordered-by "user";
>         description
>           "A user-ordered list of static routes.";
>         leaf id {
>           type uint32 {
>             range "1..max";
>           }
>           description
>             "Unique numeric identifier of the route.
>=20
>              This value is unrelated to system-assigned 'id'
>              parameters of routes in RIBs.";
>         }
>=20
> got confused that each static route is identified by an "id". =
Originally thought it could be metric, but after reading description, =
wasn't sure.=20
>=20
> Lada explained that the id is used in case same prefixes are =
configured, but have different metric. So why not use prefix and =
preference as unique identifier? One could even argue that the base spec =
only needs to use prefix as the key, and if an implementation supports =
multiple static routes for the same prefix they can extend as an =
optional feature.

YANG needs to specify key(s) for configuration lists, so we have to do =
it for static routes in ietf-routing, and this key cannot be changed or =
augmented from other modules.

Under these conditions, I am afraid we don=92t have any natural key(s) =
that would be universally acceptable. All systems use some additional =
parameters, be they called preference, metric or administrative =
distance, but the problem is that, depending on the system, they may be =
specified (i) per route, (ii) per destination prefix, or (iii) per =
protocol instance.

For Linux, the key would be the triple (dest. prefix, TOS, preference).

So, while I don=92t like the =93id=94 key at all, I don=92t see what =
else could be done. On the other hand, static routes are usually not =
defined in excessive quantities, so an extra parameter probably doesn=92t =
matter.

Another important thing to note is that the =93id=94 parameter of routes =
in RIBs (state data) is unrelated to the =93id=94 of static routes. It =
was added recently as a part of =93harmonization=94 with I2RS RIB info =
model (state lists don=92t have to have keys).   =20

Lada

>=20
> There was an email exchange on this topic offline and we are curious =
what does the WG think about this "id"?
>=20
> Dean
>=20
>=20

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





From nobody Wed Jun 25 12:03:21 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5A801B2E3F for ; Wed, 25 Jun 2014 12:03:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QvYFEXfU05Dh for ; Wed, 25 Jun 2014 12:03:13 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (dns-bn1lp0143.outbound.protection.outlook.com [207.46.163.143]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D8E31B2E2A for ; Wed, 25 Jun 2014 12:03:03 -0700 (PDT)
Received: from BY2PR05MB079.namprd05.prod.outlook.com (10.242.38.16) by CO1PR05MB428.namprd05.prod.outlook.com (10.141.74.15) with Microsoft SMTP Server (TLS) id 15.0.959.24; Wed, 25 Jun 2014 19:03:00 +0000
Received: from BY2PR05MB079.namprd05.prod.outlook.com ([169.254.8.228]) by BY2PR05MB079.namprd05.prod.outlook.com ([169.254.8.228]) with mapi id 15.00.0969.007; Wed, 25 Jun 2014 19:02:59 +0000
From: "Jeffrey (Zhaohui) Zhang" 
To: Ladislav Lhotka , Dean Bogdanovic 
Thread-Topic: static routes in draft-ietf-netmod-routing-cfg-15
Thread-Index: AQHPkHyQ0orIXWpDoUyLtj2fzemmwZuCCWmAgAAjBWA=
Date: Wed, 25 Jun 2014 19:02:58 +0000
Message-ID: 
References: <6CCE7829-D078-41B0-8578-300563AD7CB8@juniper.net> <4F17ABF3-F1E4-4EA3-9F8F-02B02162554D@nic.cz>
In-Reply-To: <4F17ABF3-F1E4-4EA3-9F8F-02B02162554D@nic.cz>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [66.129.241.13]
x-microsoft-antispam: BCL:0;PCL:0;RULEID:
x-forefront-prvs: 02530BD3AA
x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(189002)(199002)(51704005)(24454002)(13464003)(377454003)(87936001)(50986999)(21056001)(2656002)(76176999)(76576001)(95666004)(106356001)(54356999)(105586002)(107046001)(106116001)(20776003)(74316001)(101416001)(99396002)(81342001)(81542001)(80022001)(575784001)(76482001)(66066001)(83072002)(19580395003)(79102001)(92566001)(86362001)(1941001)(4396001)(77096002)(77982001)(85852003)(83322001)(85306003)(19580405001)(46102001)(99286002)(33646001)(31966008)(74502001)(74662001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR05MB428; H:BY2PR05MB079.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; 
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/HTURVfY2iYbXzIjK2S_jUkOhNjU
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] static routes in draft-ietf-netmod-routing-cfg-15
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 25 Jun 2014 19:03:18 -0000

Lada,

> -----Original Message-----
> From: Ladislav Lhotka [mailto:lhotka@nic.cz]
> Sent: Wednesday, June 25, 2014 12:48 PM
> To: Dean Bogdanovic
> Cc: netmod@ietf.org; Jeffrey (Zhaohui) Zhang
> Subject: Re: static routes in draft-ietf-netmod-routing-cfg-15
>=20
>=20
> On 25 Jun 2014, at 15:51, Dean Bogdanovic  wrote:
>=20
> > Hi,
> >
> > While reading routing-cfg, looking at the static route model
> > augment "/rt:routing/rt:routing-instance/rt:routing-protocols/"
> >         + "rt:routing-protocol/rt:static-routes" {
> >     ...
> >     container ipv4 {
> >       description
> >         "Configuration of a 'static' pseudo-protocol instance
> >          consists of a list of routes.";
> >       list route {
> >         key "id";
> >         ordered-by "user";
> >         description
> >           "A user-ordered list of static routes.";
> >         leaf id {
> >           type uint32 {
> >             range "1..max";
> >           }
> >           description
> >             "Unique numeric identifier of the route.
> >
> >              This value is unrelated to system-assigned 'id'
> >              parameters of routes in RIBs.";
> >         }
> >
> > got confused that each static route is identified by an "id".
> Originally thought it could be metric, but after reading description,
> wasn't sure.
> >
> > Lada explained that the id is used in case same prefixes are
> configured, but have different metric. So why not use prefix and
> preference as unique identifier? One could even argue that the base spec
> only needs to use prefix as the key, and if an implementation supports
> multiple static routes for the same prefix they can extend as an
> optional feature.
>=20
> YANG needs to specify key(s) for configuration lists, so we have to do
> it for static routes in ietf-routing, and this key cannot be changed or
> augmented from other modules.
>=20
> Under these conditions, I am afraid we don't have any natural key(s)
> that would be universally acceptable. All systems use some additional
> parameters, be they called preference, metric or administrative distance,
> but the problem is that, depending on the system, they may be specified
> (i) per route, (ii) per destination prefix, or (iii) per protocol
> instance.

What's the difference between "route" ((i) above) and "destination prefix" =
((ii) above)?
(iii) is irrelevant here - we're talking about "static-route", which is a "=
protocol instance" and does not need to be in the key for the static route =
entries.

>=20
> For Linux, the key would be the triple (dest. prefix, TOS, preference).

To me, routes with different TOS behavior could go into different RIBs; or,=
 just put the TOS in the prefix part. Then you're left with (prefix, prefer=
ence) - exactly what we were proposing as the key.

>=20
> So, while I don't like the "id" key at all, I don't see what else could
> be done. On the other hand, static routes are usually not defined in
> excessive quantities, so an extra parameter probably doesn't matter.
>=20
> Another important thing to note is that the "id" parameter of routes in
> RIBs (state data) is unrelated to the "id" of static routes. It was
> added recently as a part of "harmonization" with I2RS RIB info model
> (state lists don't have to have keys).

That's yet another separate discussion that is going on offline now. We'll =
loop back here when it's ready.

Jeffrey

>=20
> Lada
>=20
> >
> > There was an email exchange on this topic offline and we are curious
> what does the WG think about this "id"?
> >
> > Dean
> >
> >
>=20
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>=20
>=20
>=20


From nobody Thu Jun 26 01:41:38 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9694A1B2F44 for ; Thu, 26 Jun 2014 01:41:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ptb7KbL1owHI for ; Thu, 26 Jun 2014 01:41:33 -0700 (PDT)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 640A41B2CED for ; Thu, 26 Jun 2014 01:41:33 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 68D7D540704; Thu, 26 Jun 2014 10:41:31 +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 gjUg6ZZsCeMn; Thu, 26 Jun 2014 10:41:27 +0200 (CEST)
Received: from localhost (unknown [172.29.2.201]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 8D64E54047B; Thu, 26 Jun 2014 10:41:27 +0200 (CEST)
From: Ladislav Lhotka 
To: Andy Bierman , "netmod\@ietf.org" 
In-Reply-To: 
References: 
User-Agent: Notmuch/0.18 (http://notmuchmail.org) Emacs/24.3.50.2 (x86_64-apple-darwin13.0.0)
Date: Thu, 26 Jun 2014 10:41:26 +0200
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/cG-ixbWBXXQ0wGnBLTlGpCesgZs
Subject: Re: [netmod] possible YANG 1.1 issue: node ordering
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Jun 2014 08:41:35 -0000

Andy Bierman  writes:

> Hi,
>
> I am wondering if there is any interoperability issues with the lack
> of data node ordering for top-level and augment nodes.
>
> RFC 6020, sec. 5.1.2, para 2:
>
>    NETCONF is capable of carrying any XML content as the payload in the
>     and  elements.  The top-level nodes of YANG modules
>    are encoded as child elements, in any order, within these elements.
>    This encapsulation guarantees that the corresponding NETCONF messages
>    are always well-formed XML documents.
>
> sec. 7.15.2
>
>    When a node is augmented, the augmenting child nodes are encoded as
>    subelements to the augmented node, in any order.
>
> Note the "in any order" in both sections.
> Of course, system-ordered leaf-list and list nodes can be in any order as
> well.
> The text in 7.15.2 seems to say the augmenting nodes can be mixed
> in with the augmented nodes, even though all examples show them
> added at the end.

Yes, they can be mixed in.

>
> Do tools that compare configurations or server implementations consuming
> a configuration care about the lack of standard canonical ordering?
> I don't know if any normative changes are needed in YANG 1.1, but
> there should (at least) be some warning against attempting to compare
> XML instance documents (even from the same server seconds apart).

I think it is quite clear from the text that order of siblings is not significant (except few special cases), so any comparison should be done modulo reordering. For JSON it goes without saying.

Lada

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

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


From nobody Thu Jun 26 02:46:45 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C69C01B2F7D for ; Thu, 26 Jun 2014 02:46:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level: 
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uWr4KS5A7pqL for ; Thu, 26 Jun 2014 02:46:42 -0700 (PDT)
Received: from mail-qa0-f42.google.com (mail-qa0-f42.google.com [209.85.216.42]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B49821B2F7C for ; Thu, 26 Jun 2014 02:46:41 -0700 (PDT)
Received: by mail-qa0-f42.google.com with SMTP id dc16so2604145qab.15 for ; Thu, 26 Jun 2014 02:46:41 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=EpYLym6uklPv7aY+d+4eQN1RrREw9fE0cL1EcQGms6Y=; b=LBxHYfYEyLwhfquzKID/RCZ4VzhutukYhdWDMEDXKM/9UK7mb9A4QJ/MpqkSqrqzX0 uqNoZRsiflhOntdmqolGIbpl0flJcx+74fZFQZsYp0z93r7F5MSre+EsM8rNXWSqJg0c JsCaPatx3WUxAH+rPLF7EoRWZ/n7ZsfGFC/csyUD06/DuB/1/okgyip8jQYCNux0hp1P UynfWoTeSSheb+WiU5wYPd49JpV1c1QM2wWng1jlGPdYzxBb+u1BkVNzht4AEgOR9NKU QFkG0XFIPQfhfzGnsI1wDzx1rZyR0Rt7EElDtuwXFWefEHokEkaYdnHTqgYrbqMaslbK PPxQ==
X-Gm-Message-State: ALoCoQlfBQE45mwgZmPBArv0IyToV90XFlGYKeoX/AjA13ez3Jq4QFZLRI3t11ULcG4yan2EYNpn
MIME-Version: 1.0
X-Received: by 10.224.147.80 with SMTP id k16mr18192655qav.99.1403776000968; Thu, 26 Jun 2014 02:46:40 -0700 (PDT)
Received: by 10.140.104.48 with HTTP; Thu, 26 Jun 2014 02:46:40 -0700 (PDT)
In-Reply-To: 
References:  
Date: Thu, 26 Jun 2014 02:46:40 -0700
Message-ID: 
From: Andy Bierman 
To: Ladislav Lhotka 
Content-Type: multipart/alternative; boundary=089e01495134e1dfa904fcba11f4
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/vDiVTiUwYdU6pSfcylgjEeDCWcY
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] possible YANG 1.1 issue: node ordering
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Jun 2014 09:46:44 -0000

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

On Thu, Jun 26, 2014 at 1:41 AM, Ladislav Lhotka  wrote:

> Andy Bierman  writes:
>
> > Hi,
> >
> > I am wondering if there is any interoperability issues with the lack
> > of data node ordering for top-level and augment nodes.
> >
> > RFC 6020, sec. 5.1.2, para 2:
> >
> >    NETCONF is capable of carrying any XML content as the payload in the
> >     and  elements.  The top-level nodes of YANG modules
> >    are encoded as child elements, in any order, within these elements.
> >    This encapsulation guarantees that the corresponding NETCONF messages
> >    are always well-formed XML documents.
> >
> > sec. 7.15.2
> >
> >    When a node is augmented, the augmenting child nodes are encoded as
> >    subelements to the augmented node, in any order.
> >
> > Note the "in any order" in both sections.
> > Of course, system-ordered leaf-list and list nodes can be in any order as
> > well.
> > The text in 7.15.2 seems to say the augmenting nodes can be mixed
> > in with the augmented nodes, even though all examples show them
> > added at the end.
>
> Yes, they can be mixed in.
>

The examples should show them mixed in.


>
> >
> > Do tools that compare configurations or server implementations consuming
> > a configuration care about the lack of standard canonical ordering?
> > I don't know if any normative changes are needed in YANG 1.1, but
> > there should (at least) be some warning against attempting to compare
> > XML instance documents (even from the same server seconds apart).
>
> I think it is quite clear from the text that order of siblings is not
> significant (except few special cases), so any comparison should be done
> modulo reordering. For JSON it goes without saying.
>

OK - just as clear as 6 out of 36822 words can be.
JSON is irrelevant in NETCONF.
I wonder how many tools really handle YANG compare correctly vs. tools that
rely
on a canonical ordering from a given server.



> Lada
>
>
Andy


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

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





On Thu, Jun 26, 2014 at 1:41 AM, Ladislav Lhotka =
<lhotka@nic.cz>=
; wrote:


Andy Bierman <andy@yumaworks.com> writes:



> Hi,

>

> I am wondering if there is any interoperability issues with the lack
> of data node ordering for top-level and augment nodes.

>

> RFC 6020, sec. 5.1.2, para 2:

>

> =A0 =A0NETCONF is capable of carrying any XML content as the payload i=
n the

> =A0 =A0<config> and <data> elements. =A0The top-level node=
s of YANG modules

> =A0 =A0are encoded as child elements, in any order, within these eleme=
nts.

> =A0 =A0This encapsulation guarantees that the corresponding NETCONF me=
ssages

> =A0 =A0are always well-formed XML documents.

>

> sec. 7.15.2

>

> =A0 =A0When a node is augmented, the augmenting child nodes are encode=
d as

> =A0 =A0subelements to the augmented node, in any order.

>

> Note the "in any order" in both sections.

> Of course, system-ordered leaf-list and list nodes can be in any order=
 as

> well.

> The text in 7.15.2 seems to say the augmenting nodes can be mixed

> in with the augmented nodes, even though all examples show them

> added at the end.



Yes, they can be mixed in.

The examples=
 should show them mixed in.
=A0




>

> Do tools that compare configurations or server implementations consumi=
ng

> a configuration care about the lack of standard canonical ordering?
> I don't know if any normative changes are needed in YANG 1.1, but<=
br>
> there should (at least) be some warning against attempting to compare<=
br>
> XML instance documents (even from the same server seconds apart).



I think it is quite clear from the text that order of siblings is not signi=
ficant (except few special cases), so any comparison should be done modulo =
reordering. For JSON it goes without saying.



OK - just as clear as 6 out of 36822 words can be.
JSO=
N is irrelevant in NETCONF.
I wonder how many tools really handle=
 YANG compare correctly vs. tools that rely
on a canonical orderi=
ng from a given server.







Lada



Andy
=A0

>

>

> Andy

> _______________________________________________

> netmod mailing list

> netmod@ietf.org

> https://www.ietf.org/mailman/listinfo/netmod



--

Ladislav Lhotka, CZ.NIC Labs

PGP Key ID: E74E8C0C





--089e01495134e1dfa904fcba11f4--


From nobody Thu Jun 26 02:52:10 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 070961B2ADF for ; Thu, 26 Jun 2014 02:52:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w1lZglxIIjVi for ; Thu, 26 Jun 2014 02:52:07 -0700 (PDT)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9490F1B2F7E for ; Thu, 26 Jun 2014 02:52:05 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id C85CE540704; Thu, 26 Jun 2014 11:52:03 +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 j2hsUAmOfTxC; Thu, 26 Jun 2014 11:51:58 +0200 (CEST)
Received: from localhost (unknown [172.29.2.201]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 67EB4540149; Thu, 26 Jun 2014 11:51:57 +0200 (CEST)
From: Ladislav Lhotka 
To: "Jeffrey \(Zhaohui\) Zhang" , Dean Bogdanovic 
In-Reply-To: 
References: <6CCE7829-D078-41B0-8578-300563AD7CB8@juniper.net> <4F17ABF3-F1E4-4EA3-9F8F-02B02162554D@nic.cz> 
User-Agent: Notmuch/0.18 (http://notmuchmail.org) Emacs/24.3.50.2 (x86_64-apple-darwin13.0.0)
Date: Thu, 26 Jun 2014 11:51:56 +0200
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/lOktk2u8jaw2gQStLeYu63m2vYg
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] static routes in draft-ietf-netmod-routing-cfg-15
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Jun 2014 09:52:09 -0000

"Jeffrey (Zhaohui) Zhang"  writes:

> Lada,
>
>> -----Original Message-----
>> From: Ladislav Lhotka [mailto:lhotka@nic.cz]
>> Sent: Wednesday, June 25, 2014 12:48 PM
>> To: Dean Bogdanovic
>> Cc: netmod@ietf.org; Jeffrey (Zhaohui) Zhang
>> Subject: Re: static routes in draft-ietf-netmod-routing-cfg-15
>> 
>> 
>> On 25 Jun 2014, at 15:51, Dean Bogdanovic  wrote:
>> 
>> > Hi,
>> >
>> > While reading routing-cfg, looking at the static route model
>> > augment "/rt:routing/rt:routing-instance/rt:routing-protocols/"
>> >         + "rt:routing-protocol/rt:static-routes" {
>> >     ...
>> >     container ipv4 {
>> >       description
>> >         "Configuration of a 'static' pseudo-protocol instance
>> >          consists of a list of routes.";
>> >       list route {
>> >         key "id";
>> >         ordered-by "user";
>> >         description
>> >           "A user-ordered list of static routes.";
>> >         leaf id {
>> >           type uint32 {
>> >             range "1..max";
>> >           }
>> >           description
>> >             "Unique numeric identifier of the route.
>> >
>> >              This value is unrelated to system-assigned 'id'
>> >              parameters of routes in RIBs.";
>> >         }
>> >
>> > got confused that each static route is identified by an "id".
>> Originally thought it could be metric, but after reading description,
>> wasn't sure.
>> >
>> > Lada explained that the id is used in case same prefixes are
>> configured, but have different metric. So why not use prefix and
>> preference as unique identifier? One could even argue that the base spec
>> only needs to use prefix as the key, and if an implementation supports
>> multiple static routes for the same prefix they can extend as an
>> optional feature.
>> 
>> YANG needs to specify key(s) for configuration lists, so we have to do
>> it for static routes in ietf-routing, and this key cannot be changed or
>> augmented from other modules.
>> 
>> Under these conditions, I am afraid we don't have any natural key(s)
>> that would be universally acceptable. All systems use some additional
>> parameters, be they called preference, metric or administrative distance,
>> but the problem is that, depending on the system, they may be specified
>> (i) per route, (ii) per destination prefix, or (iii) per protocol
>> instance.
>
> What's the difference between "route" ((i) above) and "destination prefix" ((ii) above)?

Quagga can set distance either for a protocol

  distance 

or selectively

  distance  A.B.C.D/M

> (iii) is irrelevant here - we're talking about "static-route", which is a "protocol instance" and does not need to be in the key for the static route entries.

It is relevant. If we introduce preference as a route attribute in ietf-routing (as it is e.g. in JUNOS or BIRD), then implementations that don't have it (use only per-protocol distance) would be out of luck.

Lada

>
>> 
>> For Linux, the key would be the triple (dest. prefix, TOS, preference).
>
> To me, routes with different TOS behavior could go into different RIBs; or, just put the TOS in the prefix part. Then you're left with (prefix, preference) - exactly what we were proposing as the key.
>
>> 
>> So, while I don't like the "id" key at all, I don't see what else could
>> be done. On the other hand, static routes are usually not defined in
>> excessive quantities, so an extra parameter probably doesn't matter.
>> 
>> Another important thing to note is that the "id" parameter of routes in
>> RIBs (state data) is unrelated to the "id" of static routes. It was
>> added recently as a part of "harmonization" with I2RS RIB info model
>> (state lists don't have to have keys).
>
> That's yet another separate discussion that is going on offline now. We'll loop back here when it's ready.
>
> Jeffrey
>
>> 
>> Lada
>> 
>> >
>> > There was an email exchange on this topic offline and we are curious
>> what does the WG think about this "id"?
>> >
>> > Dean
>> >
>> >
>> 
>> --
>> Ladislav Lhotka, CZ.NIC Labs
>> PGP Key ID: E74E8C0C
>> 
>> 
>> 
>

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


From nobody Thu Jun 26 05:11:55 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20CD61B2B8C for ; Thu, 26 Jun 2014 05:11:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Flvvd8sm4Api for ; Thu, 26 Jun 2014 05:11:12 -0700 (PDT)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A67A1B2B7D for ; Thu, 26 Jun 2014 05:11:12 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 324FB540704; Thu, 26 Jun 2014 14:11:10 +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 Hv+jqYWvh1Zc; Thu, 26 Jun 2014 14:11:06 +0200 (CEST)
Received: from localhost (unknown [172.29.2.201]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 1B3C754047B; Thu, 26 Jun 2014 14:11:05 +0200 (CEST)
From: Ladislav Lhotka 
To: Dean Bogdanovic , "netmod\@ietf.org" 
In-Reply-To: <6CCE7829-D078-41B0-8578-300563AD7CB8@juniper.net>
References: <6CCE7829-D078-41B0-8578-300563AD7CB8@juniper.net>
User-Agent: Notmuch/0.18 (http://notmuchmail.org) Emacs/24.3.50.2 (x86_64-apple-darwin13.0.0)
Date: Thu, 26 Jun 2014 14:11:04 +0200
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/Xo_dIB31bvLiptwizJl-nZMp-ro
Cc: "Jeffrey \(Zhaohui\) Zhang" 
Subject: Re: [netmod] static routes in draft-ietf-netmod-routing-cfg-15
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Jun 2014 12:11:25 -0000

Dean Bogdanovic  writes:

> Hi,
>
> While reading routing-cfg, looking at the static route model
>  augment "/rt:routing/rt:routing-instance/rt:routing-protocols/"
>           + "rt:routing-protocol/rt:static-routes" {
>       ...
>       container ipv4 {
>         description
>           "Configuration of a 'static' pseudo-protocol instance
>            consists of a list of routes.";
>         list route {
>           key "id";
>           ordered-by "user";
>           description
>             "A user-ordered list of static routes.";
>           leaf id {
>             type uint32 {
>               range "1..max";
>             }
>             description
>               "Unique numeric identifier of the route.
>
>                This value is unrelated to system-assigned 'id'
>                parameters of routes in RIBs.";
>           }
>
> got confused that each static route is identified by an "id". Originally thought it could be metric, but after reading description, wasn't sure. 
>
> Lada explained that the id is used in case same prefixes are configured, but have different metric. So why not use prefix and preference as unique identifier? One could even argue that the base spec only needs to use prefix as the key, and if an implementation supports multiple static routes for the same prefix they can extend as an optional feature.

Back to Dean's proposal. What I think we could do is this:

1. Add "preference" leaf to the configuration and state data of "routing-protocol".

2. Define a new feature, "route-prerefence" and a new route attribute, "preference", dependent on that feature.

So, systems supporting per-route preferences will support that feature and use "preference" under "routing-protocol" as the default value for routes originated by the protocol instance.
And systems having only pre-protocol administrative distance won't support the feature and will use "preference" under "routing-protocol" as the administrative distance.

That said, I think we still can't remove the "id" from static routes because:

- some systems allow routes with the same dest. prefix and preference to appear in the same routing table;

- future modules may define new attributes for route selection (e.g. ToS), but these cannot be used as a part of the list key once the key is defined in ietf-routing.

Lada 
 


>
> There was an email exchange on this topic offline and we are curious what does the WG think about this "id"?
>
> Dean
>
>

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


From nobody Thu Jun 26 07:11:59 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A31261B2C09 for ; Thu, 26 Jun 2014 07:11:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yP_wUe7bv_Dk for ; Thu, 26 Jun 2014 07:11:48 -0700 (PDT)
Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93A4E1B303C for ; Thu, 26 Jun 2014 06:41:44 -0700 (PDT)
Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id C7C1618C246; Thu, 26 Jun 2014 15:41:42 +0200 (CEST)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.56]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id A4C66238056; Thu, 26 Jun 2014 15:41:42 +0200 (CEST)
Received: from OPEXCLILM34.corporate.adroot.infra.ftgroup ([169.254.4.50]) by OPEXCLILH04.corporate.adroot.infra.ftgroup ([10.114.31.56]) with mapi id 14.03.0181.006; Thu, 26 Jun 2014 15:41:42 +0200
From: 
To: Ladislav Lhotka , Dean Bogdanovic , "netmod@ietf.org" 
Thread-Topic: [netmod] static routes in draft-ietf-netmod-routing-cfg-15
Thread-Index: AQHPkHyQ0orIXWpDoUyLtj2fzemmwZuDLOcAgAA2T8A=
Date: Thu, 26 Jun 2014 13:41:42 +0000
Message-ID: <18032_1403790102_53AC2316_18032_2351_1_9E32478DFA9976438E7A22F69B08FF92024281@OPEXCLILM34.corporate.adroot.infra.ftgroup>
References: <6CCE7829-D078-41B0-8578-300563AD7CB8@juniper.net> 
In-Reply-To: 
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.168.234.1]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.6.26.132118
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/WnCAgJy1_X8QCVFaCugGVg1NY8Q
Cc: "Jeffrey \(Zhaohui\) Zhang" 
Subject: Re: [netmod] static routes in draft-ietf-netmod-routing-cfg-15
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Jun 2014 14:11:57 -0000

Hi,

Some comments inline

-----Original Message-----
From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Ladislav Lhotka
Sent: Thursday, June 26, 2014 14:11
To: Dean Bogdanovic; netmod@ietf.org
Cc: Jeffrey (Zhaohui) Zhang
Subject: Re: [netmod] static routes in draft-ietf-netmod-routing-cfg-15

Dean Bogdanovic  writes:

> Hi,
>
> While reading routing-cfg, looking at the static route model  augment=20
> "/rt:routing/rt:routing-instance/rt:routing-protocols/"
>           + "rt:routing-protocol/rt:static-routes" {
>       ...
>       container ipv4 {
>         description
>           "Configuration of a 'static' pseudo-protocol instance
>            consists of a list of routes.";
>         list route {
>           key "id";
>           ordered-by "user";
>           description
>             "A user-ordered list of static routes.";
>           leaf id {
>             type uint32 {
>               range "1..max";
>             }
>             description
>               "Unique numeric identifier of the route.
>
>                This value is unrelated to system-assigned 'id'
>                parameters of routes in RIBs.";
>           }
>
> got confused that each static route is identified by an "id". Originally =
thought it could be metric, but after reading description, wasn't sure.=20
>
> Lada explained that the id is used in case same prefixes are configured, =
but have different metric. So why not use prefix and preference as unique i=
dentifier? One could even argue that the base spec only needs to use prefix=
 as the key, and if an implementation supports multiple static routes for t=
he same prefix they can extend as an optional feature.

Back to Dean's proposal. What I think we could do is this:

1. Add "preference" leaf to the configuration and state data of "routing-pr=
otocol".

[SLI] Yes but some routing protocol are using multiple sets of preference (=
external vs internal routes for example), why not letting preference config=
uration, state for the protocol to the protocol itself ?
For ISIS model, I defined preference and external-preference leafs.

2. Define a new feature, "route-prerefence" and a new route attribute, "pre=
ference", dependent on that feature.
[SLI]
Setting of preference for static routes is definitively a need for configur=
ation

For the operational state of RIB, adding preference information to the rout=
e is also useful.
Regarding the operational state of RIB, what kind of RIB model do we expect=
 ?
do we want to display all routes in RIB (from all sources), or only used on=
es (lowest preference) ? If we authorize implementors to push all available=
 routes , may be there is a need for a new leaf
in route container to flag best routes.



Stephane



>
> There was an email exchange on this topic offline and we are curious what=
 does the WG think about this "id"?
>
> Dean
>
>

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

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

___________________________________________________________________________=
______________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.


From nobody Thu Jun 26 07:18:27 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E6F11B2D44 for ; Thu, 26 Jun 2014 07:18:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p6yOKzinHnQ0 for ; Thu, 26 Jun 2014 07:18:20 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (dns-bn1lp0143.outbound.protection.outlook.com [207.46.163.143]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04EDD1B3161 for ; Thu, 26 Jun 2014 06:50:53 -0700 (PDT)
Received: from BY2PR05MB079.namprd05.prod.outlook.com (10.242.38.16) by BN1PR05MB424.namprd05.prod.outlook.com (10.141.58.148) with Microsoft SMTP Server (TLS) id 15.0.954.9; Thu, 26 Jun 2014 13:50:45 +0000
Received: from BY2PR05MB079.namprd05.prod.outlook.com ([169.254.8.170]) by BY2PR05MB079.namprd05.prod.outlook.com ([169.254.8.170]) with mapi id 15.00.0969.007; Thu, 26 Jun 2014 13:50:44 +0000
From: "Jeffrey (Zhaohui) Zhang" 
To: Ladislav Lhotka , Dean Bogdanovic 
Thread-Topic: static routes in draft-ietf-netmod-routing-cfg-15
Thread-Index: AQHPkHyQ0orIXWpDoUyLtj2fzemmwZuCCWmAgAAjBWCAAPsgAIAAQPUA
Date: Thu, 26 Jun 2014 13:50:42 +0000
Message-ID: <236fa2a7df884545b6f8c4a1dd3e8d9a@BY2PR05MB079.namprd05.prod.outlook.com>
References: <6CCE7829-D078-41B0-8578-300563AD7CB8@juniper.net> <4F17ABF3-F1E4-4EA3-9F8F-02B02162554D@nic.cz>  
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [66.129.241.14]
x-microsoft-antispam: BL:0; ACTION:Default; RISK:Low; SCL:0; SPMLVL:NotSpam; PCL:0; RULEID:
x-forefront-prvs: 02543CD7CD
x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(189002)(199002)(24454002)(51704005)(377454003)(13464003)(93886003)(95666004)(19580395003)(83322001)(19580405001)(101416001)(33646001)(105586002)(99286002)(85306003)(21056001)(4396001)(81542001)(81342001)(106356001)(107046002)(99396002)(106116001)(1941001)(77096002)(54356999)(76176999)(50986999)(74316001)(74662001)(85852003)(83072002)(46102001)(74502001)(76576001)(2656002)(87936001)(79102001)(575784001)(76482001)(77982001)(64706001)(92566001)(31966008)(80022001)(66066001)(86362001)(20776003)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BN1PR05MB424; H:BY2PR05MB079.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; 
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/4AGEjvPbB9q0JlQJ0KYfQ_9jmV8
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] static routes in draft-ietf-netmod-routing-cfg-15
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Jun 2014 14:18:25 -0000

Lada,

> -----Original Message-----
> From: Ladislav Lhotka [mailto:lhotka@nic.cz]
> Sent: Thursday, June 26, 2014 5:52 AM
> To: Jeffrey (Zhaohui) Zhang; Dean Bogdanovic
> Cc: netmod@ietf.org
> Subject: RE: static routes in draft-ietf-netmod-routing-cfg-15
>=20
> "Jeffrey (Zhaohui) Zhang"  writes:
>=20
> > Lada,
> >
> >> -----Original Message-----
> >> From: Ladislav Lhotka [mailto:lhotka@nic.cz]
> >> Sent: Wednesday, June 25, 2014 12:48 PM
> >> To: Dean Bogdanovic
> >> Cc: netmod@ietf.org; Jeffrey (Zhaohui) Zhang
> >> Subject: Re: static routes in draft-ietf-netmod-routing-cfg-15
> >>
> >>
> >> On 25 Jun 2014, at 15:51, Dean Bogdanovic  wrote:
> >>
> >> > Hi,
> >> >
> >> > While reading routing-cfg, looking at the static route model
> >> > augment "/rt:routing/rt:routing-instance/rt:routing-protocols/"
> >> >         + "rt:routing-protocol/rt:static-routes" {
> >> >     ...
> >> >     container ipv4 {
> >> >       description
> >> >         "Configuration of a 'static' pseudo-protocol instance
> >> >          consists of a list of routes.";
> >> >       list route {
> >> >         key "id";
> >> >         ordered-by "user";
> >> >         description
> >> >           "A user-ordered list of static routes.";
> >> >         leaf id {
> >> >           type uint32 {
> >> >             range "1..max";
> >> >           }
> >> >           description
> >> >             "Unique numeric identifier of the route.
> >> >
> >> >              This value is unrelated to system-assigned 'id'
> >> >              parameters of routes in RIBs.";
> >> >         }
> >> >
> >> > got confused that each static route is identified by an "id".
> >> Originally thought it could be metric, but after reading description,
> >> wasn't sure.
> >> >
> >> > Lada explained that the id is used in case same prefixes are
> >> configured, but have different metric. So why not use prefix and
> >> preference as unique identifier? One could even argue that the base
> spec
> >> only needs to use prefix as the key, and if an implementation
> supports
> >> multiple static routes for the same prefix they can extend as an
> >> optional feature.
> >>
> >> YANG needs to specify key(s) for configuration lists, so we have to
> do
> >> it for static routes in ietf-routing, and this key cannot be changed
> or
> >> augmented from other modules.
> >>
> >> Under these conditions, I am afraid we don't have any natural key(s)
> >> that would be universally acceptable. All systems use some additional
> >> parameters, be they called preference, metric or administrative
> distance,
> >> but the problem is that, depending on the system, they may be
> specified
> >> (i) per route, (ii) per destination prefix, or (iii) per protocol
> >> instance.
> >
> > What's the difference between "route" ((i) above) and "destination
> prefix" ((ii) above)?
>=20
> Quagga can set distance either for a protocol
>=20
>   distance 
>=20
> or selectively
>=20
>   distance  A.B.C.D/M

I was asking the difference between "route" and "destination prefix". I gue=
ss a "route" means a particular entry (e.g. those with different nexthops o=
r in a broader context - from different protcools) for a prefix. Is that co=
rrect?

>=20
> > (iii) is irrelevant here - we're talking about "static-route", which
> is a "protocol instance" and does not need to be in the key for the
> static route entries.
>=20
> It is relevant. If we introduce preference as a route attribute in ietf-
> routing (as it is e.g. in JUNOS or BIRD), then implementations that
> don't have it (use only per-protocol distance) would be out of luck.

We are talking about specifying static routes. If an implementation does no=
t support multiple static route entries for the same prefix (e.g. using dif=
ferent nexthops), then the "preference" or whatever we call it would be a f=
ixed value say 0. If the implementation does support that, then it must pro=
vide a preference for each entry.

Jeffrey

>=20
> Lada
>=20
> >
> >>
> >> For Linux, the key would be the triple (dest. prefix, TOS,
> preference).
> >
> > To me, routes with different TOS behavior could go into different RIBs;
> or, just put the TOS in the prefix part. Then you're left with (prefix,
> preference) - exactly what we were proposing as the key.
> >
> >>
> >> So, while I don't like the "id" key at all, I don't see what else
> could
> >> be done. On the other hand, static routes are usually not defined in
> >> excessive quantities, so an extra parameter probably doesn't matter.
> >>
> >> Another important thing to note is that the "id" parameter of routes
> in
> >> RIBs (state data) is unrelated to the "id" of static routes. It was
> >> added recently as a part of "harmonization" with I2RS RIB info model
> >> (state lists don't have to have keys).
> >
> > That's yet another separate discussion that is going on offline now.
> We'll loop back here when it's ready.
> >
> > Jeffrey
> >
> >>
> >> Lada
> >>
> >> >
> >> > There was an email exchange on this topic offline and we are
> curious
> >> what does the WG think about this "id"?
> >> >
> >> > Dean
> >> >
> >> >
> >>
> >> --
> >> Ladislav Lhotka, CZ.NIC Labs
> >> PGP Key ID: E74E8C0C
> >>
> >>
> >>
> >
>=20
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C


From nobody Thu Jun 26 07:50:05 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56A7B1B31AF for ; Thu, 26 Jun 2014 07:50:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.602
X-Spam-Level: 
X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D5mSUG17gQO5 for ; Thu, 26 Jun 2014 07:49:57 -0700 (PDT)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0244.outbound.protection.outlook.com [207.46.163.244]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F3111B28CD for ; Thu, 26 Jun 2014 07:06:30 -0700 (PDT)
Received: from BY2PR05MB079.namprd05.prod.outlook.com (10.242.38.16) by BN1PR05MB423.namprd05.prod.outlook.com (10.141.58.146) with Microsoft SMTP Server (TLS) id 15.0.954.9; Thu, 26 Jun 2014 14:06:28 +0000
Received: from BY2PR05MB079.namprd05.prod.outlook.com ([169.254.8.170]) by BY2PR05MB079.namprd05.prod.outlook.com ([169.254.8.170]) with mapi id 15.00.0969.007; Thu, 26 Jun 2014 14:06:26 +0000
From: "Jeffrey (Zhaohui) Zhang" 
To: Ladislav Lhotka , Dean Bogdanovic , "netmod@ietf.org" 
Thread-Topic: static routes in draft-ietf-netmod-routing-cfg-15
Thread-Index: AQHPkHyQ0orIXWpDoUyLtj2fzemmwZuDTm4AgAAeelA=
Date: Thu, 26 Jun 2014 14:06:26 +0000
Message-ID: 
References: <6CCE7829-D078-41B0-8578-300563AD7CB8@juniper.net> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [66.129.241.14]
x-microsoft-antispam: BL:0; ACTION:Default; RISK:Low; SCL:0; SPMLVL:NotSpam; PCL:0; RULEID:
x-forefront-prvs: 02543CD7CD
x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(199002)(189002)(13464003)(51704005)(377454003)(561944003)(74502001)(76576001)(4396001)(74662001)(99286002)(83072002)(85852003)(95666004)(105586002)(107046002)(106356001)(106116001)(31966008)(85306003)(77096002)(86362001)(80022001)(575784001)(92566001)(20776003)(79102001)(77982001)(64706001)(101416001)(66066001)(1941001)(2656002)(87936001)(83322001)(19580395003)(99396002)(19580405001)(46102001)(21056001)(76482001)(54356999)(50986999)(76176999)(33646001)(81542001)(74316001)(81342001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BN1PR05MB423; H:BY2PR05MB079.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; 
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/V2KVW5zcFqC3OQs1bxruwBwQZ5Y
Subject: Re: [netmod] static routes in draft-ietf-netmod-routing-cfg-15
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Jun 2014 14:50:02 -0000

Lada,

We have been talking about between two static route entries for the same pr=
efix, say <10.0.0.0/24, nh1> and <10.0.0.0/24, nh2>, which one should be pr=
eferred.

While we used "preference" wording, that has nothing to do with the protoco=
l "preference" or "admin distance".

All that we need, is to specify how to order those two entries (that are fo=
r the same prefix). Call it "metric" or whatever. Even "index" is better th=
an "id".

But don't use that to order all static routes. Just use that to order stati=
c route entries for the same prefix. In other words, all the static route e=
ntries should be keyed on (prefix, index), not index alone.

Jeffrey

> -----Original Message-----
> From: Ladislav Lhotka [mailto:lhotka@nic.cz]
> Sent: Thursday, June 26, 2014 8:11 AM
> To: Dean Bogdanovic; netmod@ietf.org
> Cc: Jeffrey (Zhaohui) Zhang
> Subject: Re: static routes in draft-ietf-netmod-routing-cfg-15
>=20
> Dean Bogdanovic  writes:
>=20
> > Hi,
> >
> > While reading routing-cfg, looking at the static route model
> >  augment "/rt:routing/rt:routing-instance/rt:routing-protocols/"
> >           + "rt:routing-protocol/rt:static-routes" {
> >       ...
> >       container ipv4 {
> >         description
> >           "Configuration of a 'static' pseudo-protocol instance
> >            consists of a list of routes.";
> >         list route {
> >           key "id";
> >           ordered-by "user";
> >           description
> >             "A user-ordered list of static routes.";
> >           leaf id {
> >             type uint32 {
> >               range "1..max";
> >             }
> >             description
> >               "Unique numeric identifier of the route.
> >
> >                This value is unrelated to system-assigned 'id'
> >                parameters of routes in RIBs.";
> >           }
> >
> > got confused that each static route is identified by an "id".
> Originally thought it could be metric, but after reading description,
> wasn't sure.
> >
> > Lada explained that the id is used in case same prefixes are
> configured, but have different metric. So why not use prefix and
> preference as unique identifier? One could even argue that the base spec
> only needs to use prefix as the key, and if an implementation supports
> multiple static routes for the same prefix they can extend as an
> optional feature.
>=20
> Back to Dean's proposal. What I think we could do is this:
>=20
> 1. Add "preference" leaf to the configuration and state data of
> "routing-protocol".
>=20
> 2. Define a new feature, "route-prerefence" and a new route attribute,
> "preference", dependent on that feature.
>=20
> So, systems supporting per-route preferences will support that feature
> and use "preference" under "routing-protocol" as the default value for
> routes originated by the protocol instance.
> And systems having only pre-protocol administrative distance won't
> support the feature and will use "preference" under "routing-protocol"
> as the administrative distance.
>=20
> That said, I think we still can't remove the "id" from static routes
> because:
>=20
> - some systems allow routes with the same dest. prefix and preference to
> appear in the same routing table;
>=20
> - future modules may define new attributes for route selection (e.g.
> ToS), but these cannot be used as a part of the list key once the key is
> defined in ietf-routing.
>=20
> Lada
>=20
>=20
>=20
> >
> > There was an email exchange on this topic offline and we are curious
> what does the WG think about this "id"?
> >
> > Dean
> >
> >
>=20
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C


From nobody Thu Jun 26 08:16:55 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C7111B2EA9 for ; Thu, 26 Jun 2014 08:16:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.302
X-Spam-Level: 
X-Spam-Status: No, score=-1.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RP_MATCHES_RCVD=-0.651] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SnAfUSRe3vgV for ; Thu, 26 Jun 2014 08:16:49 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 495831B2ED7 for ; Thu, 26 Jun 2014 07:22: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 81FEC140B2F; Thu, 26 Jun 2014 16:22:38 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1403792558; bh=0lc9EngeRgc2amgmmsE5/JBAbthO/LpVsDdz8Sqzu68=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=dolmS8R+e0nc0J7pNdGBHOZvgzDT2KrXy+RQvepNcImRVEP9V8vM3yt769THVSJ/F AGseLal6jshsPKxzSliltA/SEJQK7WEV/ZSalNgc9TaZj5JRt3MRa+YLM15aQkgoSf WZxL60ShBXZz/Y1PLnPag2kiE3d3v6IoSoQ32Ykw=
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
From: Ladislav Lhotka 
In-Reply-To: <236fa2a7df884545b6f8c4a1dd3e8d9a@BY2PR05MB079.namprd05.prod.outlook.com>
Date: Thu, 26 Jun 2014 16:22:37 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <6CCE7829-D078-41B0-8578-300563AD7CB8@juniper.net> <4F17ABF3-F1E4-4EA3-9F8F-02B02162554D@nic.cz>   <236fa2a7df884545b6f8c4a1dd3e8d9a@BY2PR05MB079.namprd05.prod.outlook.com>
To: "Jeffrey (Zhaohui) Zhang" 
X-Mailer: Apple Mail (2.1878.2)
X-Virus-Scanned: clamav-milter 0.98.1 at mail
X-Virus-Status: Clean
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/7mPO5jqi0N7aGepL7dkdH1oT1ww
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] static routes in draft-ietf-netmod-routing-cfg-15
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Jun 2014 15:16:54 -0000

On 26 Jun 2014, at 15:50, Jeffrey (Zhaohui) Zhang  =
wrote:

> Lada,
>=20
>> -----Original Message-----
>> From: Ladislav Lhotka [mailto:lhotka@nic.cz]
>> Sent: Thursday, June 26, 2014 5:52 AM
>> To: Jeffrey (Zhaohui) Zhang; Dean Bogdanovic
>> Cc: netmod@ietf.org
>> Subject: RE: static routes in draft-ietf-netmod-routing-cfg-15
>>=20
>> "Jeffrey (Zhaohui) Zhang"  writes:
>>=20
>>> Lada,
>>>=20
>>>> -----Original Message-----
>>>> From: Ladislav Lhotka [mailto:lhotka@nic.cz]
>>>> Sent: Wednesday, June 25, 2014 12:48 PM
>>>> To: Dean Bogdanovic
>>>> Cc: netmod@ietf.org; Jeffrey (Zhaohui) Zhang
>>>> Subject: Re: static routes in draft-ietf-netmod-routing-cfg-15
>>>>=20
>>>>=20
>>>> On 25 Jun 2014, at 15:51, Dean Bogdanovic  =
wrote:
>>>>=20
>>>>> Hi,
>>>>>=20
>>>>> While reading routing-cfg, looking at the static route model
>>>>> augment "/rt:routing/rt:routing-instance/rt:routing-protocols/"
>>>>>        + "rt:routing-protocol/rt:static-routes" {
>>>>>    ...
>>>>>    container ipv4 {
>>>>>      description
>>>>>        "Configuration of a 'static' pseudo-protocol instance
>>>>>         consists of a list of routes.";
>>>>>      list route {
>>>>>        key "id";
>>>>>        ordered-by "user";
>>>>>        description
>>>>>          "A user-ordered list of static routes.";
>>>>>        leaf id {
>>>>>          type uint32 {
>>>>>            range "1..max";
>>>>>          }
>>>>>          description
>>>>>            "Unique numeric identifier of the route.
>>>>>=20
>>>>>             This value is unrelated to system-assigned 'id'
>>>>>             parameters of routes in RIBs.";
>>>>>        }
>>>>>=20
>>>>> got confused that each static route is identified by an "id".
>>>> Originally thought it could be metric, but after reading =
description,
>>>> wasn't sure.
>>>>>=20
>>>>> Lada explained that the id is used in case same prefixes are
>>>> configured, but have different metric. So why not use prefix and
>>>> preference as unique identifier? One could even argue that the base
>> spec
>>>> only needs to use prefix as the key, and if an implementation
>> supports
>>>> multiple static routes for the same prefix they can extend as an
>>>> optional feature.
>>>>=20
>>>> YANG needs to specify key(s) for configuration lists, so we have to
>> do
>>>> it for static routes in ietf-routing, and this key cannot be =
changed
>> or
>>>> augmented from other modules.
>>>>=20
>>>> Under these conditions, I am afraid we don't have any natural =
key(s)
>>>> that would be universally acceptable. All systems use some =
additional
>>>> parameters, be they called preference, metric or administrative
>> distance,
>>>> but the problem is that, depending on the system, they may be
>> specified
>>>> (i) per route, (ii) per destination prefix, or (iii) per protocol
>>>> instance.
>>>=20
>>> What's the difference between "route" ((i) above) and "destination
>> prefix" ((ii) above)?
>>=20
>> Quagga can set distance either for a protocol
>>=20
>>  distance 
>>=20
>> or selectively
>>=20
>>  distance  A.B.C.D/M
>=20
> I was asking the difference between "route" and "destination prefix". =
I guess a "route" means a particular entry (e.g. those with different =
nexthops or in a broader context - from different protcools) for a =
prefix. Is that correct?

Destination prefix is one of the attributes of a route.

>=20
>>=20
>>> (iii) is irrelevant here - we're talking about "static-route", which
>> is a "protocol instance" and does not need to be in the key for the
>> static route entries.
>>=20
>> It is relevant. If we introduce preference as a route attribute in =
ietf-
>> routing (as it is e.g. in JUNOS or BIRD), then implementations that
>> don't have it (use only per-protocol distance) would be out of luck.
>=20
> We are talking about specifying static routes. If an implementation =
does not support multiple static route entries for the same prefix (e.g. =
using different nexthops), then the "preference" or whatever we call it =
would be a fixed value say 0. If the implementation does support that, =
then it must provide a preference for each entry.

It makes little sense to introduce =93preference=94 just for =
discriminating among configured static routes with the same destination =
prefix. Backup routes or multi-path routing can be configured using =
=93next-hop-list=94.

However, this doesn=92t mean that each destination prefix must always be =
unique in the list of static routes. Future modules may introduce new =
static route attributes, e.g. for policy routing it could be =93tos=94, =
and then it would make a very good sense to configure multiple static =
routes with the same destination prefix but different ToS values.

While static routes can be augmented with a new parameter such as =93tos=94=
, such a parameter cannot be added to the list key.

Lada

>=20
> Jeffrey
>=20
>>=20
>> Lada
>>=20
>>>=20
>>>>=20
>>>> For Linux, the key would be the triple (dest. prefix, TOS,
>> preference).
>>>=20
>>> To me, routes with different TOS behavior could go into different =
RIBs;
>> or, just put the TOS in the prefix part. Then you're left with =
(prefix,
>> preference) - exactly what we were proposing as the key.
>>>=20
>>>>=20
>>>> So, while I don't like the "id" key at all, I don't see what else
>> could
>>>> be done. On the other hand, static routes are usually not defined =
in
>>>> excessive quantities, so an extra parameter probably doesn't =
matter.
>>>>=20
>>>> Another important thing to note is that the "id" parameter of =
routes
>> in
>>>> RIBs (state data) is unrelated to the "id" of static routes. It was
>>>> added recently as a part of "harmonization" with I2RS RIB info =
model
>>>> (state lists don't have to have keys).
>>>=20
>>> That's yet another separate discussion that is going on offline now.
>> We'll loop back here when it's ready.
>>>=20
>>> Jeffrey
>>>=20
>>>>=20
>>>> Lada
>>>>=20
>>>>>=20
>>>>> There was an email exchange on this topic offline and we are
>> curious
>>>> what does the WG think about this "id"?
>>>>>=20
>>>>> Dean
>>>>>=20
>>>>>=20
>>>>=20
>>>> --
>>>> Ladislav Lhotka, CZ.NIC Labs
>>>> PGP Key ID: E74E8C0C
>>>>=20
>>>>=20
>>>>=20
>>>=20
>>=20
>> --
>> Ladislav Lhotka, CZ.NIC Labs
>> PGP Key ID: E74E8C0C

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





From nobody Thu Jun 26 08:40:57 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF22F1A04C2 for ; Thu, 26 Jun 2014 08:40:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.602
X-Spam-Level: 
X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3CKFAFsAUQVG for ; Thu, 26 Jun 2014 08:40:50 -0700 (PDT)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0203.outbound.protection.outlook.com [207.46.163.203]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E26EE1B3178 for ; Thu, 26 Jun 2014 07:46:05 -0700 (PDT)
Received: from BY2PR05MB079.namprd05.prod.outlook.com (10.242.38.16) by BLUPR05MB419.namprd05.prod.outlook.com (10.141.27.19) with Microsoft SMTP Server (TLS) id 15.0.954.9; Thu, 26 Jun 2014 14:46:03 +0000
Received: from BY2PR05MB079.namprd05.prod.outlook.com ([169.254.8.170]) by BY2PR05MB079.namprd05.prod.outlook.com ([169.254.8.170]) with mapi id 15.00.0969.007; Thu, 26 Jun 2014 14:46:02 +0000
From: "Jeffrey (Zhaohui) Zhang" 
To: Ladislav Lhotka 
Thread-Topic: static routes in draft-ietf-netmod-routing-cfg-15
Thread-Index: AQHPkHyQ0orIXWpDoUyLtj2fzemmwZuCCWmAgAAjBWCAAPsgAIAAQPUAgAAKrICAAAN8AA==
Date: Thu, 26 Jun 2014 14:46:01 +0000
Message-ID: 
References: <6CCE7829-D078-41B0-8578-300563AD7CB8@juniper.net> <4F17ABF3-F1E4-4EA3-9F8F-02B02162554D@nic.cz>   <236fa2a7df884545b6f8c4a1dd3e8d9a@BY2PR05MB079.namprd05.prod.outlook.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [66.129.241.14]
x-microsoft-antispam: BL:0; ACTION:Default; RISK:Low; SCL:0; SPMLVL:NotSpam; PCL:0; RULEID:
x-forefront-prvs: 02543CD7CD
x-forefront-antispam-report: SFV:NSPM; SFS:(979002)(6009001)(377454003)(51704005)(13464003)(24454002)(189002)(199002)(50986999)(54356999)(101416001)(76176999)(99396002)(106356001)(74316001)(107046002)(106116001)(33646001)(105586002)(76576001)(99286002)(77096002)(77982001)(92566001)(95666004)(19580395003)(74502001)(66066001)(19580405001)(80022001)(21056001)(85852003)(83322001)(20776003)(83072002)(64706001)(74662001)(31966008)(81342001)(4396001)(81542001)(93886003)(76482001)(46102001)(79102001)(86362001)(575784001)(85306003)(87936001)(2656002)(24736002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR05MB419; H:BY2PR05MB079.namprd05.prod.outlook.com; FPR:; MLV:ovrnspm; PTR:InfoNoRecords; MX:1; A:1; LANG:en; 
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/S74-0e8Nr6kkL03m3yLnZsk_joo
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] static routes in draft-ietf-netmod-routing-cfg-15
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Jun 2014 15:40:55 -0000

Lada,

> It makes little sense to introduce "preference" just for discriminating
> among configured static routes with the same destination prefix. Backup
> routes or multi-path routing can be configured using "next-hop-list".

If those all have the same "preference"/"weight"/"priority"/"whatever", sur=
e use next-hop-list. But if you want to prefer nh1 over nh2, then you can e=
ither use different static route entries with "index", or as you said still=
 use next-hop-list but give different priorities to each nexthop in the lis=
t.

Some implementations may prefer one way or another. If I take a step back a=
nd agree to simply use next-hop-list, then to me we can simply use prefix i=
tself to identify the routes. More below.

>=20
> However, this doesn't mean that each destination prefix must always be
> unique in the list of static routes. Future modules may introduce new
> static route attributes, e.g. for policy routing it could be "tos", and
> then it would make a very good sense to configure multiple static routes
> with the same destination prefix but different ToS values.

A better way would be to augment it so TOS becomes part of the prefix.

Jeffrey

>=20
> While static routes can be augmented with a new parameter such as "tos",
> such a parameter cannot be added to the list key.

> -----Original Message-----
> From: Ladislav Lhotka [mailto:lhotka@nic.cz]
> Sent: Thursday, June 26, 2014 10:23 AM
> To: Jeffrey (Zhaohui) Zhang
> Cc: Dean Bogdanovic; netmod@ietf.org
> Subject: Re: static routes in draft-ietf-netmod-routing-cfg-15
>=20
>=20
> On 26 Jun 2014, at 15:50, Jeffrey (Zhaohui) Zhang 
> wrote:
>=20
> > Lada,
> >
> >> -----Original Message-----
> >> From: Ladislav Lhotka [mailto:lhotka@nic.cz]
> >> Sent: Thursday, June 26, 2014 5:52 AM
> >> To: Jeffrey (Zhaohui) Zhang; Dean Bogdanovic
> >> Cc: netmod@ietf.org
> >> Subject: RE: static routes in draft-ietf-netmod-routing-cfg-15
> >>
> >> "Jeffrey (Zhaohui) Zhang"  writes:
> >>
> >>> Lada,
> >>>
> >>>> -----Original Message-----
> >>>> From: Ladislav Lhotka [mailto:lhotka@nic.cz]
> >>>> Sent: Wednesday, June 25, 2014 12:48 PM
> >>>> To: Dean Bogdanovic
> >>>> Cc: netmod@ietf.org; Jeffrey (Zhaohui) Zhang
> >>>> Subject: Re: static routes in draft-ietf-netmod-routing-cfg-15
> >>>>
> >>>>
> >>>> On 25 Jun 2014, at 15:51, Dean Bogdanovic  wrote:
> >>>>
> >>>>> Hi,
> >>>>>
> >>>>> While reading routing-cfg, looking at the static route model
> >>>>> augment "/rt:routing/rt:routing-instance/rt:routing-protocols/"
> >>>>>        + "rt:routing-protocol/rt:static-routes" {
> >>>>>    ...
> >>>>>    container ipv4 {
> >>>>>      description
> >>>>>        "Configuration of a 'static' pseudo-protocol instance
> >>>>>         consists of a list of routes.";
> >>>>>      list route {
> >>>>>        key "id";
> >>>>>        ordered-by "user";
> >>>>>        description
> >>>>>          "A user-ordered list of static routes.";
> >>>>>        leaf id {
> >>>>>          type uint32 {
> >>>>>            range "1..max";
> >>>>>          }
> >>>>>          description
> >>>>>            "Unique numeric identifier of the route.
> >>>>>
> >>>>>             This value is unrelated to system-assigned 'id'
> >>>>>             parameters of routes in RIBs.";
> >>>>>        }
> >>>>>
> >>>>> got confused that each static route is identified by an "id".
> >>>> Originally thought it could be metric, but after reading
> description,
> >>>> wasn't sure.
> >>>>>
> >>>>> Lada explained that the id is used in case same prefixes are
> >>>> configured, but have different metric. So why not use prefix and
> >>>> preference as unique identifier? One could even argue that the base
> >> spec
> >>>> only needs to use prefix as the key, and if an implementation
> >> supports
> >>>> multiple static routes for the same prefix they can extend as an
> >>>> optional feature.
> >>>>
> >>>> YANG needs to specify key(s) for configuration lists, so we have to
> >> do
> >>>> it for static routes in ietf-routing, and this key cannot be
> changed
> >> or
> >>>> augmented from other modules.
> >>>>
> >>>> Under these conditions, I am afraid we don't have any natural key(s)
> >>>> that would be universally acceptable. All systems use some
> additional
> >>>> parameters, be they called preference, metric or administrative
> >> distance,
> >>>> but the problem is that, depending on the system, they may be
> >> specified
> >>>> (i) per route, (ii) per destination prefix, or (iii) per protocol
> >>>> instance.
> >>>
> >>> What's the difference between "route" ((i) above) and "destination
> >> prefix" ((ii) above)?
> >>
> >> Quagga can set distance either for a protocol
> >>
> >>  distance 
> >>
> >> or selectively
> >>
> >>  distance  A.B.C.D/M
> >
> > I was asking the difference between "route" and "destination prefix".
> I guess a "route" means a particular entry (e.g. those with different
> nexthops or in a broader context - from different protcools) for a
> prefix. Is that correct?
>=20
> Destination prefix is one of the attributes of a route.
>=20
> >
> >>
> >>> (iii) is irrelevant here - we're talking about "static-route", which
> >> is a "protocol instance" and does not need to be in the key for the
> >> static route entries.
> >>
> >> It is relevant. If we introduce preference as a route attribute in
> ietf-
> >> routing (as it is e.g. in JUNOS or BIRD), then implementations that
> >> don't have it (use only per-protocol distance) would be out of luck.
> >
> > We are talking about specifying static routes. If an implementation
> does not support multiple static route entries for the same prefix (e.g.
> using different nexthops), then the "preference" or whatever we call it
> would be a fixed value say 0. If the implementation does support that,
> then it must provide a preference for each entry.
>=20
> It makes little sense to introduce "preference" just for discriminating
> among configured static routes with the same destination prefix. Backup
> routes or multi-path routing can be configured using "next-hop-list".
>=20
> However, this doesn't mean that each destination prefix must always be
> unique in the list of static routes. Future modules may introduce new
> static route attributes, e.g. for policy routing it could be "tos", and
> then it would make a very good sense to configure multiple static routes
> with the same destination prefix but different ToS values.
>=20
> While static routes can be augmented with a new parameter such as "tos",
> such a parameter cannot be added to the list key.
>=20
> Lada
>=20
> >
> > Jeffrey
> >
> >>
> >> Lada
> >>
> >>>
> >>>>
> >>>> For Linux, the key would be the triple (dest. prefix, TOS,
> >> preference).
> >>>
> >>> To me, routes with different TOS behavior could go into different
> RIBs;
> >> or, just put the TOS in the prefix part. Then you're left with
> (prefix,
> >> preference) - exactly what we were proposing as the key.
> >>>
> >>>>
> >>>> So, while I don't like the "id" key at all, I don't see what else
> >> could
> >>>> be done. On the other hand, static routes are usually not defined
> in
> >>>> excessive quantities, so an extra parameter probably doesn't matter.
> >>>>
> >>>> Another important thing to note is that the "id" parameter of
> routes
> >> in
> >>>> RIBs (state data) is unrelated to the "id" of static routes. It was
> >>>> added recently as a part of "harmonization" with I2RS RIB info
> model
> >>>> (state lists don't have to have keys).
> >>>
> >>> That's yet another separate discussion that is going on offline now.
> >> We'll loop back here when it's ready.
> >>>
> >>> Jeffrey
> >>>
> >>>>
> >>>> Lada
> >>>>
> >>>>>
> >>>>> There was an email exchange on this topic offline and we are
> >> curious
> >>>> what does the WG think about this "id"?
> >>>>>
> >>>>> Dean
> >>>>>
> >>>>>
> >>>>
> >>>> --
> >>>> Ladislav Lhotka, CZ.NIC Labs
> >>>> PGP Key ID: E74E8C0C
> >>>>
> >>>>
> >>>>
> >>>
> >>
> >> --
> >> Ladislav Lhotka, CZ.NIC Labs
> >> PGP Key ID: E74E8C0C
>=20
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>=20
>=20
>=20


From nobody Thu Jun 26 08:42:30 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 802E61B3106 for ; Thu, 26 Jun 2014 08:42:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.302
X-Spam-Level: 
X-Spam-Status: No, score=-1.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RP_MATCHES_RCVD=-0.651] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T2_hXZccgyVH for ; Thu, 26 Jun 2014 08:42:23 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A55C71A854B for ; Thu, 26 Jun 2014 07:47: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 BFB09140C79; Thu, 26 Jun 2014 16:46:59 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1403794020; bh=5MKlGhGLKxhYqX38eeu87ftfnCOb1xZVj1OuXjhXOck=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=Q1SgviGnZzy8K8s9zS/P9xWLgCUTcIn2oXhap4dpPzjVItXv5rr9mjrNuLf1Fr9ne 1hCsDzrUU8Oas0M1qMfk9ISUvXSdzPXJ8UHe1fF+GZH8v66wFoT0XpjNN3rRVX8yLl c9zGHcc7yUP9SYwCvcLlxBuY0XhaIHwp14oZEYdE=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
From: Ladislav Lhotka 
In-Reply-To: <18032_1403790102_53AC2316_18032_2351_1_9E32478DFA9976438E7A22F69B08FF92024281@OPEXCLILM34.corporate.adroot.infra.ftgroup>
Date: Thu, 26 Jun 2014 16:46:59 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <141CDEEB-D976-40D0-A436-85D6D4DE7CF8@nic.cz>
References: <6CCE7829-D078-41B0-8578-300563AD7CB8@juniper.net>  <18032_1403790102_53AC2316_18032_2351_1_9E32478DFA9976438E7A22F69B08FF92024281@OPEXCLILM34.corporate.adroot.infra.ftgroup>
To: stephane.litkowski@orange.com
X-Mailer: Apple Mail (2.1878.2)
X-Virus-Scanned: clamav-milter 0.98.1 at mail
X-Virus-Status: Clean
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/JB7_M7QUmfU8qQP_OHgUgb9bfJY
Cc: "Jeffrey \(Zhaohui\) Zhang" , "netmod@ietf.org" 
Subject: Re: [netmod] static routes in draft-ietf-netmod-routing-cfg-15
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Jun 2014 15:42:27 -0000

On 26 Jun 2014, at 15:41,  =
 wrote:

> Hi,
>=20
> Some comments inline
>=20
> -----Original Message-----
> From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Ladislav =
Lhotka
> Sent: Thursday, June 26, 2014 14:11
> To: Dean Bogdanovic; netmod@ietf.org
> Cc: Jeffrey (Zhaohui) Zhang
> Subject: Re: [netmod] static routes in =
draft-ietf-netmod-routing-cfg-15
>=20
> Dean Bogdanovic  writes:
>=20
>> Hi,
>>=20
>> While reading routing-cfg, looking at the static route model  augment=20=

>> "/rt:routing/rt:routing-instance/rt:routing-protocols/"
>>          + "rt:routing-protocol/rt:static-routes" {
>>      ...
>>      container ipv4 {
>>        description
>>          "Configuration of a 'static' pseudo-protocol instance
>>           consists of a list of routes.";
>>        list route {
>>          key "id";
>>          ordered-by "user";
>>          description
>>            "A user-ordered list of static routes.";
>>          leaf id {
>>            type uint32 {
>>              range "1..max";
>>            }
>>            description
>>              "Unique numeric identifier of the route.
>>=20
>>               This value is unrelated to system-assigned 'id'
>>               parameters of routes in RIBs.";
>>          }
>>=20
>> got confused that each static route is identified by an "id". =
Originally thought it could be metric, but after reading description, =
wasn't sure.=20
>>=20
>> Lada explained that the id is used in case same prefixes are =
configured, but have different metric. So why not use prefix and =
preference as unique identifier? One could even argue that the base spec =
only needs to use prefix as the key, and if an implementation supports =
multiple static routes for the same prefix they can extend as an =
optional feature.
>=20
> Back to Dean's proposal. What I think we could do is this:
>=20
> 1. Add "preference" leaf to the configuration and state data of =
"routing-protocol".
>=20
> [SLI] Yes but some routing protocol are using multiple sets of =
preference (external vs internal routes for example), why not letting =
preference configuration, state for the protocol to the protocol itself =
?
> For ISIS model, I defined preference and external-preference leafs.

Yes, that was the idea, and in fact other modules are also expected to =
add other attributes to static routes via augmentation, e.g. for policy =
routing. The whole point of this discussion is whether we can find a =
more natural key for the list of static routes.

>=20
> 2. Define a new feature, "route-prerefence" and a new route attribute, =
"preference", dependent on that feature.
> [SLI]
> Setting of preference for static routes is definitively a need for =
configuration
>=20
> For the operational state of RIB, adding preference information to the =
route is also useful.
> Regarding the operational state of RIB, what kind of RIB model do we =
expect ?
> do we want to display all routes in RIB (from all sources), or only =
used ones (lowest preference) ? If we authorize implementors to push all =
available routes , may be there is a need for a new leaf
> in route container to flag best routes.

The RIBs in the data model contain all routes, not only the active ones. =
How these RIBs are used is system-dependent.

Lada=20

>=20
>=20
>=20
> Stephane
>=20
>=20
>=20
>>=20
>> There was an email exchange on this topic offline and we are curious =
what does the WG think about this "id"?
>>=20
>> Dean
>>=20
>>=20
>=20
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>=20
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>=20
> =
__________________________________________________________________________=
_______________________________________________
>=20
> Ce message et ses pieces jointes peuvent contenir des informations =
confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez =
recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les =
messages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, =
deforme ou falsifie. Merci.
>=20
> This message and its attachments may contain confidential or =
privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and =
delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have =
been modified, changed or falsified.
> Thank you.

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





From nobody Thu Jun 26 08:56:49 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97AC11B31C5 for ; Thu, 26 Jun 2014 08:56:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.302
X-Spam-Level: 
X-Spam-Status: No, score=-1.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RP_MATCHES_RCVD=-0.651] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D4H14edxbGDU for ; Thu, 26 Jun 2014 08:56:43 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F62A1B2B96 for ; Thu, 26 Jun 2014 07:57:59 -0700 (PDT)
Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id A0D9713F807; Thu, 26 Jun 2014 16:57:57 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1403794677; bh=tcvdVfaRmCq97GlBzIKbtSd2cD8zJL5XST61KER1iPg=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=PBzO8+sNRwW+30IL4p0/2hnQY5/cZBoaXaF3KfSW0SgFmqtv/ZxA+q2aftSsjZCs2 CAYD2ujHKXoycPEU9sKS2Q+Gax/0Xg0GHMuCDlb60vj7oy3wl0w1nbRSo779i/6WA0 80yGwyp7lf7lRRYBZPluAf/mjQ5H9wU0HiP4KnWA=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
From: Ladislav Lhotka 
In-Reply-To: 
Date: Thu, 26 Jun 2014 16:57:57 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <109A8A1D-29C4-4F4C-80FF-DBCD5FB6999D@nic.cz>
References: <6CCE7829-D078-41B0-8578-300563AD7CB8@juniper.net> <4F17ABF3-F1E4-4EA3-9F8F-02B02162554D@nic.cz>   <236fa2a7df884545b6f8c4a1dd3e8d9a@BY2PR05MB079.namprd05.prod.outlook.com>  
To: "Jeffrey (Zhaohui) Zhang" 
X-Mailer: Apple Mail (2.1878.2)
X-Virus-Scanned: clamav-milter 0.98.1 at mail
X-Virus-Status: Clean
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/uxW1m6jbCekDwwxmUR8wcJBBLcQ
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] static routes in draft-ietf-netmod-routing-cfg-15
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Jun 2014 15:56:45 -0000

Jeffrey, Dean,

we should move this long discussion towards some resolution. It might be =
helpful if you propose concrete changes to the current module(s).

Thanks, Lada
=20
On 26 Jun 2014, at 16:46, Jeffrey (Zhaohui) Zhang  =
wrote:

> Lada,
>=20
>> It makes little sense to introduce "preference" just for =
discriminating
>> among configured static routes with the same destination prefix. =
Backup
>> routes or multi-path routing can be configured using "next-hop-list".
>=20
> If those all have the same =
"preference"/"weight"/"priority"/"whatever", sure use next-hop-list. But =
if you want to prefer nh1 over nh2, then you can either use different =
static route entries with "index", or as you said still use =
next-hop-list but give different priorities to each nexthop in the list.
>=20
> Some implementations may prefer one way or another. If I take a step =
back and agree to simply use next-hop-list, then to me we can simply use =
prefix itself to identify the routes. More below.
>=20
>>=20
>> However, this doesn't mean that each destination prefix must always =
be
>> unique in the list of static routes. Future modules may introduce new
>> static route attributes, e.g. for policy routing it could be "tos", =
and
>> then it would make a very good sense to configure multiple static =
routes
>> with the same destination prefix but different ToS values.
>=20
> A better way would be to augment it so TOS becomes part of the prefix.
>=20
> Jeffrey
>=20
>>=20
>> While static routes can be augmented with a new parameter such as =
"tos",
>> such a parameter cannot be added to the list key.
>=20
>> -----Original Message-----
>> From: Ladislav Lhotka [mailto:lhotka@nic.cz]
>> Sent: Thursday, June 26, 2014 10:23 AM
>> To: Jeffrey (Zhaohui) Zhang
>> Cc: Dean Bogdanovic; netmod@ietf.org
>> Subject: Re: static routes in draft-ietf-netmod-routing-cfg-15
>>=20
>>=20
>> On 26 Jun 2014, at 15:50, Jeffrey (Zhaohui) Zhang =

>> wrote:
>>=20
>>> Lada,
>>>=20
>>>> -----Original Message-----
>>>> From: Ladislav Lhotka [mailto:lhotka@nic.cz]
>>>> Sent: Thursday, June 26, 2014 5:52 AM
>>>> To: Jeffrey (Zhaohui) Zhang; Dean Bogdanovic
>>>> Cc: netmod@ietf.org
>>>> Subject: RE: static routes in draft-ietf-netmod-routing-cfg-15
>>>>=20
>>>> "Jeffrey (Zhaohui) Zhang"  writes:
>>>>=20
>>>>> Lada,
>>>>>=20
>>>>>> -----Original Message-----
>>>>>> From: Ladislav Lhotka [mailto:lhotka@nic.cz]
>>>>>> Sent: Wednesday, June 25, 2014 12:48 PM
>>>>>> To: Dean Bogdanovic
>>>>>> Cc: netmod@ietf.org; Jeffrey (Zhaohui) Zhang
>>>>>> Subject: Re: static routes in draft-ietf-netmod-routing-cfg-15
>>>>>>=20
>>>>>>=20
>>>>>> On 25 Jun 2014, at 15:51, Dean Bogdanovic  =
wrote:
>>>>>>=20
>>>>>>> Hi,
>>>>>>>=20
>>>>>>> While reading routing-cfg, looking at the static route model
>>>>>>> augment "/rt:routing/rt:routing-instance/rt:routing-protocols/"
>>>>>>>       + "rt:routing-protocol/rt:static-routes" {
>>>>>>>   ...
>>>>>>>   container ipv4 {
>>>>>>>     description
>>>>>>>       "Configuration of a 'static' pseudo-protocol instance
>>>>>>>        consists of a list of routes.";
>>>>>>>     list route {
>>>>>>>       key "id";
>>>>>>>       ordered-by "user";
>>>>>>>       description
>>>>>>>         "A user-ordered list of static routes.";
>>>>>>>       leaf id {
>>>>>>>         type uint32 {
>>>>>>>           range "1..max";
>>>>>>>         }
>>>>>>>         description
>>>>>>>           "Unique numeric identifier of the route.
>>>>>>>=20
>>>>>>>            This value is unrelated to system-assigned 'id'
>>>>>>>            parameters of routes in RIBs.";
>>>>>>>       }
>>>>>>>=20
>>>>>>> got confused that each static route is identified by an "id".
>>>>>> Originally thought it could be metric, but after reading
>> description,
>>>>>> wasn't sure.
>>>>>>>=20
>>>>>>> Lada explained that the id is used in case same prefixes are
>>>>>> configured, but have different metric. So why not use prefix and
>>>>>> preference as unique identifier? One could even argue that the =
base
>>>> spec
>>>>>> only needs to use prefix as the key, and if an implementation
>>>> supports
>>>>>> multiple static routes for the same prefix they can extend as an
>>>>>> optional feature.
>>>>>>=20
>>>>>> YANG needs to specify key(s) for configuration lists, so we have =
to
>>>> do
>>>>>> it for static routes in ietf-routing, and this key cannot be
>> changed
>>>> or
>>>>>> augmented from other modules.
>>>>>>=20
>>>>>> Under these conditions, I am afraid we don't have any natural =
key(s)
>>>>>> that would be universally acceptable. All systems use some
>> additional
>>>>>> parameters, be they called preference, metric or administrative
>>>> distance,
>>>>>> but the problem is that, depending on the system, they may be
>>>> specified
>>>>>> (i) per route, (ii) per destination prefix, or (iii) per protocol
>>>>>> instance.
>>>>>=20
>>>>> What's the difference between "route" ((i) above) and "destination
>>>> prefix" ((ii) above)?
>>>>=20
>>>> Quagga can set distance either for a protocol
>>>>=20
>>>> distance 
>>>>=20
>>>> or selectively
>>>>=20
>>>> distance  A.B.C.D/M
>>>=20
>>> I was asking the difference between "route" and "destination =
prefix".
>> I guess a "route" means a particular entry (e.g. those with different
>> nexthops or in a broader context - from different protcools) for a
>> prefix. Is that correct?
>>=20
>> Destination prefix is one of the attributes of a route.
>>=20
>>>=20
>>>>=20
>>>>> (iii) is irrelevant here - we're talking about "static-route", =
which
>>>> is a "protocol instance" and does not need to be in the key for the
>>>> static route entries.
>>>>=20
>>>> It is relevant. If we introduce preference as a route attribute in
>> ietf-
>>>> routing (as it is e.g. in JUNOS or BIRD), then implementations that
>>>> don't have it (use only per-protocol distance) would be out of =
luck.
>>>=20
>>> We are talking about specifying static routes. If an implementation
>> does not support multiple static route entries for the same prefix =
(e.g.
>> using different nexthops), then the "preference" or whatever we call =
it
>> would be a fixed value say 0. If the implementation does support =
that,
>> then it must provide a preference for each entry.
>>=20
>> It makes little sense to introduce "preference" just for =
discriminating
>> among configured static routes with the same destination prefix. =
Backup
>> routes or multi-path routing can be configured using "next-hop-list".
>>=20
>> However, this doesn't mean that each destination prefix must always =
be
>> unique in the list of static routes. Future modules may introduce new
>> static route attributes, e.g. for policy routing it could be "tos", =
and
>> then it would make a very good sense to configure multiple static =
routes
>> with the same destination prefix but different ToS values.
>>=20
>> While static routes can be augmented with a new parameter such as =
"tos",
>> such a parameter cannot be added to the list key.
>>=20
>> Lada
>>=20
>>>=20
>>> Jeffrey
>>>=20
>>>>=20
>>>> Lada
>>>>=20
>>>>>=20
>>>>>>=20
>>>>>> For Linux, the key would be the triple (dest. prefix, TOS,
>>>> preference).
>>>>>=20
>>>>> To me, routes with different TOS behavior could go into different
>> RIBs;
>>>> or, just put the TOS in the prefix part. Then you're left with
>> (prefix,
>>>> preference) - exactly what we were proposing as the key.
>>>>>=20
>>>>>>=20
>>>>>> So, while I don't like the "id" key at all, I don't see what else
>>>> could
>>>>>> be done. On the other hand, static routes are usually not defined
>> in
>>>>>> excessive quantities, so an extra parameter probably doesn't =
matter.
>>>>>>=20
>>>>>> Another important thing to note is that the "id" parameter of
>> routes
>>>> in
>>>>>> RIBs (state data) is unrelated to the "id" of static routes. It =
was
>>>>>> added recently as a part of "harmonization" with I2RS RIB info
>> model
>>>>>> (state lists don't have to have keys).
>>>>>=20
>>>>> That's yet another separate discussion that is going on offline =
now.
>>>> We'll loop back here when it's ready.
>>>>>=20
>>>>> Jeffrey
>>>>>=20
>>>>>>=20
>>>>>> Lada
>>>>>>=20
>>>>>>>=20
>>>>>>> There was an email exchange on this topic offline and we are
>>>> curious
>>>>>> what does the WG think about this "id"?
>>>>>>>=20
>>>>>>> Dean
>>>>>>>=20
>>>>>>>=20
>>>>>>=20
>>>>>> --
>>>>>> Ladislav Lhotka, CZ.NIC Labs
>>>>>> PGP Key ID: E74E8C0C
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>=20
>>>>=20
>>>> --
>>>> Ladislav Lhotka, CZ.NIC Labs
>>>> PGP Key ID: E74E8C0C
>>=20
>> --
>> Ladislav Lhotka, CZ.NIC Labs
>> PGP Key ID: E74E8C0C
>>=20
>>=20
>>=20
>=20

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





From nobody Thu Jun 26 08:58:56 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BFDE1B2B98 for ; Thu, 26 Jun 2014 08:58:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.602
X-Spam-Level: 
X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dr1alNd4ImhX for ; Thu, 26 Jun 2014 08:58:51 -0700 (PDT)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0212.outbound.protection.outlook.com [207.46.163.212]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80F771B2C48 for ; Thu, 26 Jun 2014 08:01:19 -0700 (PDT)
Received: from BY2PR05MB079.namprd05.prod.outlook.com (10.242.38.16) by BN1PR05MB421.namprd05.prod.outlook.com (10.141.58.139) with Microsoft SMTP Server (TLS) id 15.0.954.9; Thu, 26 Jun 2014 15:01:10 +0000
Received: from BY2PR05MB079.namprd05.prod.outlook.com ([169.254.8.170]) by BY2PR05MB079.namprd05.prod.outlook.com ([169.254.8.170]) with mapi id 15.00.0969.007; Thu, 26 Jun 2014 15:01:09 +0000
From: "Jeffrey (Zhaohui) Zhang" 
To: Ladislav Lhotka 
Thread-Topic: static routes in draft-ietf-netmod-routing-cfg-15
Thread-Index: AQHPkHyQ0orIXWpDoUyLtj2fzemmwZuCCWmAgAAjBWCAAPsgAIAAQPUAgAAKrICAAAN8AIAABmOAgAAApyA=
Date: Thu, 26 Jun 2014 15:01:07 +0000
Message-ID: <8e9299cd951a42b7a8be67e55e87cccb@BY2PR05MB079.namprd05.prod.outlook.com>
References: <6CCE7829-D078-41B0-8578-300563AD7CB8@juniper.net> <4F17ABF3-F1E4-4EA3-9F8F-02B02162554D@nic.cz>   <236fa2a7df884545b6f8c4a1dd3e8d9a@BY2PR05MB079.namprd05.prod.outlook.com>   <109A8A1D-29C4-4F4C-80FF-DBCD5FB6999D@nic.cz>
In-Reply-To: <109A8A1D-29C4-4F4C-80FF-DBCD5FB6999D@nic.cz>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [66.129.241.14]
x-microsoft-antispam: BL:0; ACTION:Default; RISK:Low; SCL:0; SPMLVL:NotSpam; PCL:0; RULEID:
x-forefront-prvs: 02543CD7CD
x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(13464003)(24454002)(377454003)(51704005)(199002)(189002)(164054003)(20776003)(64706001)(79102001)(76482001)(76576001)(80022001)(77982001)(66066001)(575784001)(74316001)(99396002)(54356999)(101416001)(76176999)(86362001)(50986999)(19580395003)(561944003)(33646001)(83322001)(19580405001)(46102001)(92566001)(81542001)(81342001)(74502001)(85306003)(74662001)(85852003)(83072002)(4396001)(77096002)(31966008)(93886003)(95666004)(87936001)(106116001)(107046002)(21056001)(99286002)(105586002)(106356001)(2656002)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BN1PR05MB421; H:BY2PR05MB079.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; 
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/7u1fxhuUeTKYddn-WcZOgFj_oXg
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] static routes in draft-ietf-netmod-routing-cfg-15
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Jun 2014 15:58:55 -0000

Lada,

My proposal is to remove ID and just use prefix.
For future extensions like TOS, just augment to include TOS in the prefix.

Jeffrey

> -----Original Message-----
> From: Ladislav Lhotka [mailto:lhotka@nic.cz]
> Sent: Thursday, June 26, 2014 10:58 AM
> To: Jeffrey (Zhaohui) Zhang
> Cc: Dean Bogdanovic; netmod@ietf.org
> Subject: Re: static routes in draft-ietf-netmod-routing-cfg-15
>=20
> Jeffrey, Dean,
>=20
> we should move this long discussion towards some resolution. It might be
> helpful if you propose concrete changes to the current module(s).
>=20
> Thanks, Lada
>=20
> On 26 Jun 2014, at 16:46, Jeffrey (Zhaohui) Zhang 
> wrote:
>=20
> > Lada,
> >
> >> It makes little sense to introduce "preference" just for
> discriminating
> >> among configured static routes with the same destination prefix.
> Backup
> >> routes or multi-path routing can be configured using "next-hop-list".
> >
> > If those all have the same "preference"/"weight"/"priority"/"whatever",
> sure use next-hop-list. But if you want to prefer nh1 over nh2, then you
> can either use different static route entries with "index", or as you
> said still use next-hop-list but give different priorities to each
> nexthop in the list.
> >
> > Some implementations may prefer one way or another. If I take a step
> back and agree to simply use next-hop-list, then to me we can simply use
> prefix itself to identify the routes. More below.
> >
> >>
> >> However, this doesn't mean that each destination prefix must always
> be
> >> unique in the list of static routes. Future modules may introduce new
> >> static route attributes, e.g. for policy routing it could be "tos",
> and
> >> then it would make a very good sense to configure multiple static
> routes
> >> with the same destination prefix but different ToS values.
> >
> > A better way would be to augment it so TOS becomes part of the prefix.
> >
> > Jeffrey
> >
> >>
> >> While static routes can be augmented with a new parameter such as
> "tos",
> >> such a parameter cannot be added to the list key.
> >
> >> -----Original Message-----
> >> From: Ladislav Lhotka [mailto:lhotka@nic.cz]
> >> Sent: Thursday, June 26, 2014 10:23 AM
> >> To: Jeffrey (Zhaohui) Zhang
> >> Cc: Dean Bogdanovic; netmod@ietf.org
> >> Subject: Re: static routes in draft-ietf-netmod-routing-cfg-15
> >>
> >>
> >> On 26 Jun 2014, at 15:50, Jeffrey (Zhaohui) Zhang 
> >> wrote:
> >>
> >>> Lada,
> >>>
> >>>> -----Original Message-----
> >>>> From: Ladislav Lhotka [mailto:lhotka@nic.cz]
> >>>> Sent: Thursday, June 26, 2014 5:52 AM
> >>>> To: Jeffrey (Zhaohui) Zhang; Dean Bogdanovic
> >>>> Cc: netmod@ietf.org
> >>>> Subject: RE: static routes in draft-ietf-netmod-routing-cfg-15
> >>>>
> >>>> "Jeffrey (Zhaohui) Zhang"  writes:
> >>>>
> >>>>> Lada,
> >>>>>
> >>>>>> -----Original Message-----
> >>>>>> From: Ladislav Lhotka [mailto:lhotka@nic.cz]
> >>>>>> Sent: Wednesday, June 25, 2014 12:48 PM
> >>>>>> To: Dean Bogdanovic
> >>>>>> Cc: netmod@ietf.org; Jeffrey (Zhaohui) Zhang
> >>>>>> Subject: Re: static routes in draft-ietf-netmod-routing-cfg-15
> >>>>>>
> >>>>>>
> >>>>>> On 25 Jun 2014, at 15:51, Dean Bogdanovic 
> wrote:
> >>>>>>
> >>>>>>> Hi,
> >>>>>>>
> >>>>>>> While reading routing-cfg, looking at the static route model
> >>>>>>> augment "/rt:routing/rt:routing-instance/rt:routing-protocols/"
> >>>>>>>       + "rt:routing-protocol/rt:static-routes" {
> >>>>>>>   ...
> >>>>>>>   container ipv4 {
> >>>>>>>     description
> >>>>>>>       "Configuration of a 'static' pseudo-protocol instance
> >>>>>>>        consists of a list of routes.";
> >>>>>>>     list route {
> >>>>>>>       key "id";
> >>>>>>>       ordered-by "user";
> >>>>>>>       description
> >>>>>>>         "A user-ordered list of static routes.";
> >>>>>>>       leaf id {
> >>>>>>>         type uint32 {
> >>>>>>>           range "1..max";
> >>>>>>>         }
> >>>>>>>         description
> >>>>>>>           "Unique numeric identifier of the route.
> >>>>>>>
> >>>>>>>            This value is unrelated to system-assigned 'id'
> >>>>>>>            parameters of routes in RIBs.";
> >>>>>>>       }
> >>>>>>>
> >>>>>>> got confused that each static route is identified by an "id".
> >>>>>> Originally thought it could be metric, but after reading
> >> description,
> >>>>>> wasn't sure.
> >>>>>>>
> >>>>>>> Lada explained that the id is used in case same prefixes are
> >>>>>> configured, but have different metric. So why not use prefix and
> >>>>>> preference as unique identifier? One could even argue that the
> base
> >>>> spec
> >>>>>> only needs to use prefix as the key, and if an implementation
> >>>> supports
> >>>>>> multiple static routes for the same prefix they can extend as an
> >>>>>> optional feature.
> >>>>>>
> >>>>>> YANG needs to specify key(s) for configuration lists, so we have
> to
> >>>> do
> >>>>>> it for static routes in ietf-routing, and this key cannot be
> >> changed
> >>>> or
> >>>>>> augmented from other modules.
> >>>>>>
> >>>>>> Under these conditions, I am afraid we don't have any natural
> key(s)
> >>>>>> that would be universally acceptable. All systems use some
> >> additional
> >>>>>> parameters, be they called preference, metric or administrative
> >>>> distance,
> >>>>>> but the problem is that, depending on the system, they may be
> >>>> specified
> >>>>>> (i) per route, (ii) per destination prefix, or (iii) per protocol
> >>>>>> instance.
> >>>>>
> >>>>> What's the difference between "route" ((i) above) and "destination
> >>>> prefix" ((ii) above)?
> >>>>
> >>>> Quagga can set distance either for a protocol
> >>>>
> >>>> distance 
> >>>>
> >>>> or selectively
> >>>>
> >>>> distance  A.B.C.D/M
> >>>
> >>> I was asking the difference between "route" and "destination prefix".
> >> I guess a "route" means a particular entry (e.g. those with different
> >> nexthops or in a broader context - from different protcools) for a
> >> prefix. Is that correct?
> >>
> >> Destination prefix is one of the attributes of a route.
> >>
> >>>
> >>>>
> >>>>> (iii) is irrelevant here - we're talking about "static-route",
> which
> >>>> is a "protocol instance" and does not need to be in the key for the
> >>>> static route entries.
> >>>>
> >>>> It is relevant. If we introduce preference as a route attribute in
> >> ietf-
> >>>> routing (as it is e.g. in JUNOS or BIRD), then implementations that
> >>>> don't have it (use only per-protocol distance) would be out of luck.
> >>>
> >>> We are talking about specifying static routes. If an implementation
> >> does not support multiple static route entries for the same prefix
> (e.g.
> >> using different nexthops), then the "preference" or whatever we call
> it
> >> would be a fixed value say 0. If the implementation does support that,
> >> then it must provide a preference for each entry.
> >>
> >> It makes little sense to introduce "preference" just for
> discriminating
> >> among configured static routes with the same destination prefix.
> Backup
> >> routes or multi-path routing can be configured using "next-hop-list".
> >>
> >> However, this doesn't mean that each destination prefix must always
> be
> >> unique in the list of static routes. Future modules may introduce new
> >> static route attributes, e.g. for policy routing it could be "tos",
> and
> >> then it would make a very good sense to configure multiple static
> routes
> >> with the same destination prefix but different ToS values.
> >>
> >> While static routes can be augmented with a new parameter such as
> "tos",
> >> such a parameter cannot be added to the list key.
> >>
> >> Lada
> >>
> >>>
> >>> Jeffrey
> >>>
> >>>>
> >>>> Lada
> >>>>
> >>>>>
> >>>>>>
> >>>>>> For Linux, the key would be the triple (dest. prefix, TOS,
> >>>> preference).
> >>>>>
> >>>>> To me, routes with different TOS behavior could go into different
> >> RIBs;
> >>>> or, just put the TOS in the prefix part. Then you're left with
> >> (prefix,
> >>>> preference) - exactly what we were proposing as the key.
> >>>>>
> >>>>>>
> >>>>>> So, while I don't like the "id" key at all, I don't see what else
> >>>> could
> >>>>>> be done. On the other hand, static routes are usually not defined
> >> in
> >>>>>> excessive quantities, so an extra parameter probably doesn't
> matter.
> >>>>>>
> >>>>>> Another important thing to note is that the "id" parameter of
> >> routes
> >>>> in
> >>>>>> RIBs (state data) is unrelated to the "id" of static routes. It
> was
> >>>>>> added recently as a part of "harmonization" with I2RS RIB info
> >> model
> >>>>>> (state lists don't have to have keys).
> >>>>>
> >>>>> That's yet another separate discussion that is going on offline
> now.
> >>>> We'll loop back here when it's ready.
> >>>>>
> >>>>> Jeffrey
> >>>>>
> >>>>>>
> >>>>>> Lada
> >>>>>>
> >>>>>>>
> >>>>>>> There was an email exchange on this topic offline and we are
> >>>> curious
> >>>>>> what does the WG think about this "id"?
> >>>>>>>
> >>>>>>> Dean
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>> --
> >>>>>> Ladislav Lhotka, CZ.NIC Labs
> >>>>>> PGP Key ID: E74E8C0C
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>> --
> >>>> Ladislav Lhotka, CZ.NIC Labs
> >>>> PGP Key ID: E74E8C0C
> >>
> >> --
> >> Ladislav Lhotka, CZ.NIC Labs
> >> PGP Key ID: E74E8C0C
> >>
> >>
> >>
> >
>=20
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>=20
>=20
>=20


From nobody Thu Jun 26 11:57:21 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 495721B2CC1 for ; Thu, 26 Jun 2014 11:57:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -12.852
X-Spam-Level: 
X-Spam-Status: No, score=-12.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MANGLED_TOOL=2.3, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X-jr0X4TzhyG for ; Thu, 26 Jun 2014 11:57:18 -0700 (PDT)
Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DE771B2D42 for ; Thu, 26 Jun 2014 11:54:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1844; q=dns/txt; s=iport; t=1403808892; x=1405018492; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=Wtz0L9giat4Ooweoxhej9iyJUF94I+JXuliJDrJbcIw=; b=AIoVo/0hls0j1zbsIE3mRB+OYyjf1KxEslAG7cXvJKKSEFBsnRQUt38/ XqotvgR25sA1ygPXzqcGbff+7TgyEH7235qobYF3v1iQeVhGnc3xaQ4TQ OamWXZutnf/3m/ekWiL/BcGvjT8wFguO2rNZpM7cGOu3TKVmlLax997F+ w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AnoMAKNrrFOtJV2Z/2dsb2JhbABagw1SUweqFAwBAQEBAQEFAW2YfwGBDRZ1hAMBAgR3FAEIeBsBBgMCBBMJiDkIBZVIrGYXhWSJI4RDBZpZgUaSL4NCbIFE
X-IronPort-AV: E=Sophos;i="5.01,554,1400025600"; d="scan'208";a="56255521"
Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-7.cisco.com with ESMTP; 26 Jun 2014 18:54:52 +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 s5QIspoV014327 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 26 Jun 2014 18:54:51 GMT
Received: from xmb-aln-x07.cisco.com ([169.254.2.4]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0123.003; Thu, 26 Jun 2014 13:54:51 -0500
From: "Dana Blair (dblair)" 
To: "netmod@ietf.org" 
Thread-Topic: New Version Notification for draft-bogdanovic-netmod-acl-model-01.txt
Thread-Index: AQHPkWBDQELkwxkwnEy2FEpwoi+4qJuDzroA
Date: Thu, 26 Jun 2014 18:54:50 +0000
Message-ID: 
In-Reply-To: <20140626164959.26790.5771.idtracker@ietfa.amsl.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.135.16.26]
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <56AACFF51A37034885BDE494F63DF359@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/5WU2OiZ09Cz7DCmb13iTXdj4pOg
Subject: [netmod] FW: New Version Notification for draft-bogdanovic-netmod-acl-model-01.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Jun 2014 18:57:20 -0000

FYI and comments =8A

Here is an initial draft proposal for a YANG model for an Access Control
List.


I need to clarify Cisco's position on this proposal for an Access Control
List yang model since
there was an expired draft, draft-huang-netmod-acl-03.txt, which had Cisco
authorship.

Cisco's position is to support this new draft,
draft-bogdanovic-netmod-acl-model-01.txt,
and not support the expired draft, draft-huang-netmod-acl-03.txt.

Changes from version 00 to 01 of draft-bogdanovic-netmod-acl-model.
1.  Complete the list of authors
2.  Add grouping timerange
3.  Fix the XML example
4.  Remove some terms from "Definitions and Acronyms" which were not used.

thanks,
Dana


On 6/26/14 12:49 PM, "internet-drafts@ietf.org" 
wrote:

>
>A new version of I-D, draft-bogdanovic-netmod-acl-model-01.txt
>has been successfully submitted by Dean Bogdanovic and posted to the
>IETF repository.
>
>Name:		draft-bogdanovic-netmod-acl-model
>Revision:	01
>Title:		ACL YANG model
>Document date:	2014-06-26
>Group:		Individual Submission
>Pages:		17
>URL:           =20
>http://www.ietf.org/internet-drafts/draft-bogdanovic-netmod-acl-model-01.t
>xt
>Status:        =20
>https://datatracker.ietf.org/doc/draft-bogdanovic-netmod-acl-model/
>Htmlized:      =20
>http://tools.ietf.org/html/draft-bogdanovic-netmod-acl-model-01
>Diff:          =20
>http://www.ietf.org/rfcdiff?url2=3Ddraft-bogdanovic-netmod-acl-model-01
>
>Abstract:
>   This document describes information and data model of Access Control
>   List (ACL) basic building blocks.
>
>                 =20
>       =20
>
>
>Please note that it may take a couple of minutes from the time of
>submission
>until the htmlized version and diff are available at tools.ietf.org.
>
>The IETF Secretariat
>


From nobody Thu Jun 26 17:07:10 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE7931B28B2 for ; Thu, 26 Jun 2014 17:07:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.152
X-Spam-Level: 
X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lzZIwRf3kNM8 for ; Thu, 26 Jun 2014 17:07:05 -0700 (PDT)
Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1ACC1B2B37 for ; Thu, 26 Jun 2014 17:07:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1161; q=dns/txt; s=iport; t=1403827625; x=1405037225; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=dQBlKSWa3JWsbXdk8gMDs+Y/Tn7K0huu7RTBMnIhRb0=; b=LKEqGb7yXuY3LH6u1NMuAOqLzXA7QZ2Qag2rhfKpB15SeR+3vs29n6dI +AbKmy0GESNJ0yIvXDLbG0gCP7j1ntx+vElA174CXRJC7FQeVc3BPhUYK Rc1Lr4OnDAmyV95JhXUzbedemCFWv06kWApR2lL86tOEPSuXEXFx8x2DA Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhgGAG+1rFOtJV2U/2dsb2JhbABagmkkUlqqIAwBAQEBAQEFAW2YfwGBChZ1hAMBAQEEOj0SAgEINhAyGwEGAwIEEwmIOQEMwlcXhWSJI4RDBZpZgUaSL4NCbIFE
X-IronPort-AV: E=Sophos;i="5.01,556,1400025600"; d="scan'208";a="56325139"
Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-2.cisco.com with ESMTP; 27 Jun 2014 00:06:52 +0000
Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s5R06p5K012370 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 27 Jun 2014 00:06:51 GMT
Received: from xmb-aln-x13.cisco.com ([fe80::5404:b599:9f57:834b]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0123.003; Thu, 26 Jun 2014 19:06:51 -0500
From: "Clyde Wildes (cwildes)" 
To: "netmod@ietf.org" 
Thread-Topic: New Version Notification for draft-wildes-netmod-syslog-model-00.txt
Thread-Index: AQHPkZMp5tIX3Csi/kmACQV2dQR/PZuD8rAA
Date: Fri, 27 Jun 2014 00:06:50 +0000
Message-ID: 
References: <20140626230541.26022.78913.idtracker@ietfa.amsl.com>
In-Reply-To: <20140626230541.26022.78913.idtracker@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.27.7.188]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <31A2AF7FCD929B40909B0AE529072420@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/KU6TwsYfn2CrbHEOO7Jcf6MBAz8
Subject: [netmod] FW: New Version Notification for draft-wildes-netmod-syslog-model-00.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 27 Jun 2014 00:07:08 -0000

FYI and comments...

Here is an initial draft proposal for a YANG model for Syslog.

Thanks,

Clyde

On 6/26/14, 4:05 PM, "internet-drafts@ietf.org" 
wrote:

>
>A new version of I-D, draft-wildes-netmod-syslog-model-00.txt
>has been successfully submitted by Kiran Koushik Agrahara and posted to
>the
>IETF repository.
>
>Name:		draft-wildes-netmod-syslog-model
>Revision:	00
>Title:		SYSLOG YANG model
>Document date:	2014-06-26
>Group:		Individual Submission
>Pages:		19
>URL:           =20
>http://www.ietf.org/internet-drafts/draft-wildes-netmod-syslog-model-00.tx
>t
>Status:        =20
>https://datatracker.ietf.org/doc/draft-wildes-netmod-syslog-model/
>Htmlized:      =20
>http://tools.ietf.org/html/draft-wildes-netmod-syslog-model-00
>
>
>Abstract:
>   This document describes a data model for Syslog
>   protocol which is used to convey event notification messages.
>
>                 =20
>       =20
>
>
>Please note that it may take a couple of minutes from the time of
>submission
>until the htmlized version and diff are available at tools.ietf.org.
>
>The IETF Secretariat


From nobody Thu Jun 26 19:08:32 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A2211B30DA for ; Thu, 26 Jun 2014 19:08:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.151
X-Spam-Level: 
X-Spam-Status: No, score=-15.151 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n-hCzvtTQsFS for ; Thu, 26 Jun 2014 19:08:28 -0700 (PDT)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5030E1B3074 for ; Thu, 26 Jun 2014 19:08:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3147; q=dns/txt; s=iport; t=1403834908; x=1405044508; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=D5/jr5tGeNuT6xBNrgSfrXuoYy5SBF75SchbUqI0F2Y=; b=XXmNPyEH+nM1pa6x7gEkFUpYZSOD6iM+rod/OmYnoW8lufcM16q+7cgA M8v7L0R4i5RS6wsYFz8oyKZ0nSO9zzvt2y0xMc2oPh7x7pmikDBwkFsx8 5ujfhT1A+tzozAFMNbfVP7SJc75Gvj2BcNCC7mYmH60JdRt4xgs12bdX0 s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AlEGAJjRrFOtJV2P/2dsb2JhbABbgkZHUlqqJQwBAQEBAQEFAW2PaokVAYEKFnWECncUAQx0JQIEiFUNlgSsVxeFZIkjhEMFmlmBRpIvg0KCMA
X-IronPort-AV: E=Sophos;i="5.01,557,1400025600";  d="scan'208,217";a="336009481"
Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-5.cisco.com with ESMTP; 27 Jun 2014 02:08:28 +0000
Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id s5R28RnM014250 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 27 Jun 2014 02:08:27 GMT
Received: from xmb-aln-x03.cisco.com ([169.254.6.12]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0123.003; Thu, 26 Jun 2014 21:08:27 -0500
From: "Lisa Huang (yihuan)" 
To: "netmod@ietf.org" 
Thread-Topic: draft-huang-netmod-acl status notification
Thread-Index: AQHPkZYHAG2zLC1GMkaToTDdHEitb5uEFKiA
Date: Fri, 27 Jun 2014 02:08:26 +0000
Message-ID: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.2.3.120616
x-originating-ip: [10.21.73.186]
Content-Type: multipart/alternative; boundary="_000_CFD2200128EBByihuanciscocom_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/gGFsgBV-y9efGufgBFiRPE9bdAg
Subject: [netmod] draft-huang-netmod-acl status notification
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 27 Jun 2014 02:08:30 -0000

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

Hi,

draft-huang-netmod-acl , the YANG Data Model for Stateless Packet Filter Co=
nfiguration (http://tools.ietf.org/html/draft-huang-netmod-acl-03) recently=
 expired and we will no longer update the draft. Another draft draft-bogdan=
ovic-netmod-acl-model was submitted for an ACL YANG model in its place. Ple=
ase let us know if you have questions or comments.

Thanks,

Lisa

--_000_CFD2200128EBByihuanciscocom_
Content-Type: text/html; charset="us-ascii"
Content-ID: <6836C856A112DB43B0C44672F7B98200@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable







Hi,












draf=
t-huang-netmod-acl , the YANG Data Model
 for Stateless Packet Filter Configuration (http://tools.ietf.org/html/draft-huang-netmod-acl-03) recent=
ly expired and we will
 no longer update the draft. Another =
draft draft-bogdanovic-netmod-acl-model was submitted for an ACL YANG =
model in its place. Please let us know if you have questio=
ns or comments.







Thanks,







Lisa









--_000_CFD2200128EBByihuanciscocom_--


From nobody Thu Jun 26 19:13:40 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 969E31B2EC1 for ; Thu, 26 Jun 2014 19:13:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -12.852
X-Spam-Level: 
X-Spam-Status: No, score=-12.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MANGLED_TOOL=2.3, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 49-SvFEphoWn for ; Thu, 26 Jun 2014 19:13:34 -0700 (PDT)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7039F1B2EBE for ; Thu, 26 Jun 2014 19:13:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2514; q=dns/txt; s=iport; t=1403835214; x=1405044814; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=WwO6pgDYQZ/eNL/gxN5ojEJlZq8z7Syr1Bf4LjC/sMo=; b=F5R294viJvaGrV6fmCqOBZLZJq+Kvb3iW9HXFyupoa7SMXK8lVGf4z2b U/I8MdB85NkJkYqW0WaHm50rHukTao+AHvjVuGCP6uxZ15fSbZJHZSly8 TDcJRhoLSPMxZiw04iBJwCrU6YjXP3ZmxBFTw0OY+GEHOrevmtZ31k2fp Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AnMMAAHTrFOtJA2L/2dsb2JhbABbgw1SUweqMQEBAQEBAQUBbZE/hm1TAYEKFnWEAwEBAQQBAQFrCRQBCG0LHAkCBAESCYg5CAXCWheFZIkjhEMFmlmBRpIvggCBQoIw
X-IronPort-AV: E=Sophos;i="5.01,557,1400025600"; d="scan'208";a="332913026"
Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-9.cisco.com with ESMTP; 27 Jun 2014 02:13:09 +0000
Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s5R2D9is018649 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 27 Jun 2014 02:13:09 GMT
Received: from xmb-aln-x03.cisco.com ([169.254.6.12]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.03.0123.003; Thu, 26 Jun 2014 21:13:09 -0500
From: "Lisa Huang (yihuan)" 
To: "Dana Blair (dblair)" , "netmod@ietf.org" 
Thread-Topic: [netmod] FW: New Version Notification for draft-bogdanovic-netmod-acl-model-01.txt
Thread-Index: AQHPkWBDVZCYvlixREGFDymh1fRr6ZuEEUgAgAAFG4A=
Date: Fri, 27 Jun 2014 02:13:08 +0000
Message-ID: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.2.3.120616
x-originating-ip: [10.21.73.186]
Content-Type: text/plain; charset="iso-8859-2"
Content-ID: <2BAB73E8C834624FAD588E1602FE9D76@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/gT5s-51DURjOwYrcsnyLzD3lXUc
Subject: Re: [netmod] FW: New Version Notification for draft-bogdanovic-netmod-acl-model-01.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 27 Jun 2014 02:13:37 -0000

The document contains a base ACL model that could be flexibly extended or
adapted by different vendors. It is with cross-company support. We will be
presenting this work at the netmod WG meeting.

We wish to acknowledge the helpful contributions, comments, and
suggestions from Alex Clem and Andy Bierman on ACL model, who also
co-authored draft-huang-netmod-acl.

Thanks,

Lisa

On 6/26/14 11:54 AM, "Dana Blair (dblair)"  wrote:

>FYI and comments =A9
>
>Here is an initial draft proposal for a YANG model for an Access Control
>List.
>
>
>I need to clarify Cisco's position on this proposal for an Access Control
>List yang model since
>there was an expired draft, draft-huang-netmod-acl-03.txt, which had Cisco
>authorship.
>
>Cisco's position is to support this new draft,
>draft-bogdanovic-netmod-acl-model-01.txt,
>and not support the expired draft, draft-huang-netmod-acl-03.txt.
>
>Changes from version 00 to 01 of draft-bogdanovic-netmod-acl-model.
>1.  Complete the list of authors
>2.  Add grouping timerange
>3.  Fix the XML example
>4.  Remove some terms from "Definitions and Acronyms" which were not used.
>
>thanks,
>Dana
>
>
>On 6/26/14 12:49 PM, "internet-drafts@ietf.org" 
>wrote:
>
>>
>>A new version of I-D, draft-bogdanovic-netmod-acl-model-01.txt
>>has been successfully submitted by Dean Bogdanovic and posted to the
>>IETF repository.
>>
>>Name:		draft-bogdanovic-netmod-acl-model
>>Revision:	01
>>Title:		ACL YANG model
>>Document date:	2014-06-26
>>Group:		Individual Submission
>>Pages:		17
>>URL:           =20
>>http://www.ietf.org/internet-drafts/draft-bogdanovic-netmod-acl-model-01.
>>t
>>xt
>>Status:        =20
>>https://datatracker.ietf.org/doc/draft-bogdanovic-netmod-acl-model/
>>Htmlized:      =20
>>http://tools.ietf.org/html/draft-bogdanovic-netmod-acl-model-01
>>Diff:          =20
>>http://www.ietf.org/rfcdiff?url2=3Ddraft-bogdanovic-netmod-acl-model-01
>>
>>Abstract:
>>   This document describes information and data model of Access Control
>>   List (ACL) basic building blocks.
>>
>>                =20
>>       =20
>>
>>
>>Please note that it may take a couple of minutes from the time of
>>submission
>>until the htmlized version and diff are available at tools.ietf.org.
>>
>>The IETF Secretariat
>>
>
>_______________________________________________
>netmod mailing list
>netmod@ietf.org
>https://www.ietf.org/mailman/listinfo/netmod


From nobody Fri Jun 27 00:00:27 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53A4B1B2AE7 for ; Fri, 27 Jun 2014 00:00:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.201
X-Spam-Level: 
X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RiILarIuACUz for ; Fri, 27 Jun 2014 00:00:20 -0700 (PDT)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75ECD1B2ACB for ; Fri, 27 Jun 2014 00:00:20 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id B9B2813A5; Fri, 27 Jun 2014 09:00:18 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id mP4N3ztSFzB1; Fri, 27 Jun 2014 09:00:13 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Fri, 27 Jun 2014 09:00:18 +0200 (CEST)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0C8E020043; Fri, 27 Jun 2014 09:00:18 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id Ck_IRbKR9cTn; Fri, 27 Jun 2014 09:00:17 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 96DC220044; Fri, 27 Jun 2014 09:00:16 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 835942D9A9EC; Fri, 27 Jun 2014 09:00:13 +0200 (CEST)
Date: Fri, 27 Jun 2014 09:00:13 +0200
From: Juergen Schoenwaelder 
To: "Jeffrey (Zhaohui) Zhang" 
Message-ID: <20140627070013.GA26128@elstar.local>
Mail-Followup-To: "Jeffrey (Zhaohui) Zhang" , Ladislav Lhotka , "netmod@ietf.org" 
References: <6CCE7829-D078-41B0-8578-300563AD7CB8@juniper.net> <4F17ABF3-F1E4-4EA3-9F8F-02B02162554D@nic.cz>   <236fa2a7df884545b6f8c4a1dd3e8d9a@BY2PR05MB079.namprd05.prod.outlook.com>   <109A8A1D-29C4-4F4C-80FF-DBCD5FB6999D@nic.cz> <8e9299cd951a42b7a8be67e55e87cccb@BY2PR05MB079.namprd05.prod.outlook.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <8e9299cd951a42b7a8be67e55e87cccb@BY2PR05MB079.namprd05.prod.outlook.com>
User-Agent: Mutt/1.4.2.3i
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/XABzAuEwZ_lxF9F_ely4R8ZB7_8
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] static routes in draft-ietf-netmod-routing-cfg-15
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 27 Jun 2014 07:00:25 -0000

On Thu, Jun 26, 2014 at 03:01:07PM +0000, Jeffrey (Zhaohui) Zhang wrote:
> Lada,
> 
> My proposal is to remove ID and just use prefix.
> For future extensions like TOS, just augment to include TOS in the prefix.
> 

I do not understand how that would work / look like. Can you sketch
such a solution?

/js

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


From kkoushik@Brocade.com  Thu Jun 26 10:08:53 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A7821ABB90 for ; Thu, 26 Jun 2014 10:08:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jETVHB2_u011 for ; Thu, 26 Jun 2014 10:08:51 -0700 (PDT)
Received: from mx0a-000f0801.pphosted.com (mx0a-000f0801.pphosted.com [IPv6:2620:100:9001:7a::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B8AE1B2B2C for ; Thu, 26 Jun 2014 10:04:12 -0700 (PDT)
Received: from pps.filterd (m0048193 [127.0.0.1]) by mx0a-000f0801.pphosted.com (8.14.5/8.14.5) with SMTP id s5QH0ifD014137 for ; Thu, 26 Jun 2014 10:04:11 -0700
Received: from hq1wp-exchub01.corp.brocade.com ([144.49.131.13]) by mx0a-000f0801.pphosted.com with ESMTP id 1mqg74ry6t-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Thu, 26 Jun 2014 10:04:11 -0700
Received: from BRMWP-EXCHUB02.corp.brocade.com (172.16.187.99) by HQ1WP-EXCHUB01.corp.brocade.com (10.70.36.101) with Microsoft SMTP Server (TLS) id 14.3.123.3; Thu, 26 Jun 2014 10:04:10 -0700
Received: from brm-excashub-2.corp.brocade.com (172.16.187.74) by BRMWP-EXCHUB02.corp.brocade.com (172.16.187.99) with Microsoft SMTP Server (TLS) id 14.3.123.3; Thu, 26 Jun 2014 11:04:07 -0600
Received: from brm-exch-3.corp.brocade.com ([169.254.1.137]) by brm-excashub-2.corp.brocade.com ([172.16.187.74]) with mapi; Thu, 26 Jun 2014 11:03:34 -0600
From: Kiran Agrahara Sreenivasa 
To: "netmod@ietf.org" 
Date: Thu, 26 Jun 2014 11:03:34 -0600
Thread-Topic: Need two 10 min slots at IETF toronto
Thread-Index: Ac+RYFy2Vqm+HVHxSTeSv1QUsgbDzA==
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_C051D5C82AA58D49B08200C1A16C643106E80A27CBBRMEXCH3corpb_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52, 1.0.14,  0.0.0000 definitions=2014-06-26_06:2014-06-26,2014-06-26,1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1406260175
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/1L69g5Qlc6G1X_jljpWtUhYzJTk
X-Mailman-Approved-At: Fri, 27 Jun 2014 00:37:00 -0700
Cc: Tom Nadeau 
Subject: [netmod] Need two 10 min slots at IETF toronto
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Jun 2014 17:59:11 -0000

--_000_C051D5C82AA58D49B08200C1A16C643106E80A27CBBRMEXCH3corpb_
Content-Type: text/plain; charset="us-ascii"

Hi
We'd like to request two 10 min slots at IETF Toronto Netmod WG meeting.


1)      Present YANG model for Access control Lists - Dana Blair, Dean Bogdanovic, Kiran Agrahara, Lisa Huang

2)      Present YANG model for SYSLOG - Clyde Wildes, Kiran Agrahara

Thanks
Kiran


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


Hi
We’d like to request two 10 min slots at IETF T=
oronto Netmod WG meeting.
 
1)      Present YANG model for Access control Lists – Dana =
Blair, Dean Bogdanovic, Kiran Agrahara, Lisa Huang
2)      Present YANG model for SYSLOG – Clyde Wildes, Kiran Agrahara<=
/o:p>
 
Tha=
nks
Kiran
 
=

--_000_C051D5C82AA58D49B08200C1A16C643106E80A27CBBRMEXCH3corpb_--


From nobody Fri Jun 27 00:42:37 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79A021B3173 for ; Fri, 27 Jun 2014 00:42:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.201
X-Spam-Level: 
X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nE7XmftD8zhm for ; Fri, 27 Jun 2014 00:42:31 -0700 (PDT)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 496EB1A02E3 for ; Fri, 27 Jun 2014 00:42:30 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id EC91E321; Fri, 27 Jun 2014 09:42:28 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id xSyxzHAwWgWw; Fri, 27 Jun 2014 09:42:23 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Fri, 27 Jun 2014 09:42:28 +0200 (CEST)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1BE0320043; Fri, 27 Jun 2014 09:42:28 +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 xOq6hP2IrdWB; Fri, 27 Jun 2014 09:42:27 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1EFCF20040; Fri, 27 Jun 2014 09:42:26 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 3F8072D9AC1D; Fri, 27 Jun 2014 09:42:27 +0200 (CEST)
Date: Fri, 27 Jun 2014 09:42:27 +0200
From: Juergen Schoenwaelder 
To: Kiran Agrahara Sreenivasa 
Message-ID: <20140627074227.GB26370@elstar.local>
Mail-Followup-To: Kiran Agrahara Sreenivasa , "netmod@ietf.org" , Tom Nadeau 
References: 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.4.2.3i
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/gNBOUVcbvaUB5DMfJtpD2eQMwdM
Cc: Tom Nadeau , "netmod@ietf.org" 
Subject: Re: [netmod] Need two 10 min slots at IETF toronto
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 27 Jun 2014 07:42:35 -0000

Hi,

it is in general good to see some discussion on the mailing list and
it helps to have a concrete list of issues people want to discuss
during the meeting.

/js

On Thu, Jun 26, 2014 at 11:03:34AM -0600, Kiran Agrahara Sreenivasa wrote:
> Hi
> We'd like to request two 10 min slots at IETF Toronto Netmod WG meeting.
> 
> 
> 1)      Present YANG model for Access control Lists - Dana Blair, Dean Bogdanovic, Kiran Agrahara, Lisa Huang
> 
> 2)      Present YANG model for SYSLOG - Clyde Wildes, Kiran Agrahara
> 
> Thanks
> Kiran
> 

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


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


From nobody Fri Jun 27 03:04:58 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70CA81B2F29 for ; Fri, 27 Jun 2014 03:04:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t2q514pmeWcD for ; Fri, 27 Jun 2014 03:04:52 -0700 (PDT)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4F611B2F28 for ; Fri, 27 Jun 2014 03:04:51 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 98B13540726; Fri, 27 Jun 2014 12:04:49 +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 zmkLverKzpsa; Fri, 27 Jun 2014 12:04:43 +0200 (CEST)
Received: from localhost (unknown [172.29.2.201]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 08D4A540687; Fri, 27 Jun 2014 12:04:43 +0200 (CEST)
From: Ladislav Lhotka 
To: "Jeffrey \(Zhaohui\) Zhang" 
In-Reply-To: <8e9299cd951a42b7a8be67e55e87cccb@BY2PR05MB079.namprd05.prod.outlook.com>
References: <6CCE7829-D078-41B0-8578-300563AD7CB8@juniper.net> <4F17ABF3-F1E4-4EA3-9F8F-02B02162554D@nic.cz>   <236fa2a7df884545b6f8c4a1dd3e8d9a@BY2PR05MB079.namprd05.prod.outlook.com>   <109A8A1D-29C4-4F4C-80FF-DBCD5FB6999D@nic.cz> <8e9299cd951a42b7a8be67e55e87cccb@BY2PR05MB079.namprd05.prod.outlook.com>
User-Agent: Notmuch/0.18 (http://notmuchmail.org) Emacs/24.3.50.2 (x86_64-apple-darwin13.0.0)
Date: Fri, 27 Jun 2014 12:04:44 +0200
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/72RBXXUfwmi8hywCMOub-Qb2L-0
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] static routes in draft-ietf-netmod-routing-cfg-15
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 27 Jun 2014 10:04:55 -0000

"Jeffrey (Zhaohui) Zhang"  writes:

> Lada,
>
> My proposal is to remove ID and just use prefix.
> For future extensions like TOS, just augment to include TOS in the prefix.

No way. ToS was just an example, other modules may add other parameters such as "preference" or "source-address". We can't expect the destination prefix to be unique.

One thing that *might* be possible is to have the following key in static routes:

  key "destination-prefix id"

It would be especially useful if optional keys are introduced in YANG 1.1 (see issue Y09). The "id" would then be used as an auxiliary distinguisher for routes that have the same destination-prefix, otherwise it could have the default value.

Lada  

>
> Jeffrey
>
>> -----Original Message-----
>> From: Ladislav Lhotka [mailto:lhotka@nic.cz]
>> Sent: Thursday, June 26, 2014 10:58 AM
>> To: Jeffrey (Zhaohui) Zhang
>> Cc: Dean Bogdanovic; netmod@ietf.org
>> Subject: Re: static routes in draft-ietf-netmod-routing-cfg-15
>> 
>> Jeffrey, Dean,
>> 
>> we should move this long discussion towards some resolution. It might be
>> helpful if you propose concrete changes to the current module(s).
>> 
>> Thanks, Lada
>> 
>> On 26 Jun 2014, at 16:46, Jeffrey (Zhaohui) Zhang 
>> wrote:
>> 
>> > Lada,
>> >
>> >> It makes little sense to introduce "preference" just for
>> discriminating
>> >> among configured static routes with the same destination prefix.
>> Backup
>> >> routes or multi-path routing can be configured using "next-hop-list".
>> >
>> > If those all have the same "preference"/"weight"/"priority"/"whatever",
>> sure use next-hop-list. But if you want to prefer nh1 over nh2, then you
>> can either use different static route entries with "index", or as you
>> said still use next-hop-list but give different priorities to each
>> nexthop in the list.
>> >
>> > Some implementations may prefer one way or another. If I take a step
>> back and agree to simply use next-hop-list, then to me we can simply use
>> prefix itself to identify the routes. More below.
>> >
>> >>
>> >> However, this doesn't mean that each destination prefix must always
>> be
>> >> unique in the list of static routes. Future modules may introduce new
>> >> static route attributes, e.g. for policy routing it could be "tos",
>> and
>> >> then it would make a very good sense to configure multiple static
>> routes
>> >> with the same destination prefix but different ToS values.
>> >
>> > A better way would be to augment it so TOS becomes part of the prefix.
>> >
>> > Jeffrey
>> >
>> >>
>> >> While static routes can be augmented with a new parameter such as
>> "tos",
>> >> such a parameter cannot be added to the list key.
>> >
>> >> -----Original Message-----
>> >> From: Ladislav Lhotka [mailto:lhotka@nic.cz]
>> >> Sent: Thursday, June 26, 2014 10:23 AM
>> >> To: Jeffrey (Zhaohui) Zhang
>> >> Cc: Dean Bogdanovic; netmod@ietf.org
>> >> Subject: Re: static routes in draft-ietf-netmod-routing-cfg-15
>> >>
>> >>
>> >> On 26 Jun 2014, at 15:50, Jeffrey (Zhaohui) Zhang 
>> >> wrote:
>> >>
>> >>> Lada,
>> >>>
>> >>>> -----Original Message-----
>> >>>> From: Ladislav Lhotka [mailto:lhotka@nic.cz]
>> >>>> Sent: Thursday, June 26, 2014 5:52 AM
>> >>>> To: Jeffrey (Zhaohui) Zhang; Dean Bogdanovic
>> >>>> Cc: netmod@ietf.org
>> >>>> Subject: RE: static routes in draft-ietf-netmod-routing-cfg-15
>> >>>>
>> >>>> "Jeffrey (Zhaohui) Zhang"  writes:
>> >>>>
>> >>>>> Lada,
>> >>>>>
>> >>>>>> -----Original Message-----
>> >>>>>> From: Ladislav Lhotka [mailto:lhotka@nic.cz]
>> >>>>>> Sent: Wednesday, June 25, 2014 12:48 PM
>> >>>>>> To: Dean Bogdanovic
>> >>>>>> Cc: netmod@ietf.org; Jeffrey (Zhaohui) Zhang
>> >>>>>> Subject: Re: static routes in draft-ietf-netmod-routing-cfg-15
>> >>>>>>
>> >>>>>>
>> >>>>>> On 25 Jun 2014, at 15:51, Dean Bogdanovic 
>> wrote:
>> >>>>>>
>> >>>>>>> Hi,
>> >>>>>>>
>> >>>>>>> While reading routing-cfg, looking at the static route model
>> >>>>>>> augment "/rt:routing/rt:routing-instance/rt:routing-protocols/"
>> >>>>>>>       + "rt:routing-protocol/rt:static-routes" {
>> >>>>>>>   ...
>> >>>>>>>   container ipv4 {
>> >>>>>>>     description
>> >>>>>>>       "Configuration of a 'static' pseudo-protocol instance
>> >>>>>>>        consists of a list of routes.";
>> >>>>>>>     list route {
>> >>>>>>>       key "id";
>> >>>>>>>       ordered-by "user";
>> >>>>>>>       description
>> >>>>>>>         "A user-ordered list of static routes.";
>> >>>>>>>       leaf id {
>> >>>>>>>         type uint32 {
>> >>>>>>>           range "1..max";
>> >>>>>>>         }
>> >>>>>>>         description
>> >>>>>>>           "Unique numeric identifier of the route.
>> >>>>>>>
>> >>>>>>>            This value is unrelated to system-assigned 'id'
>> >>>>>>>            parameters of routes in RIBs.";
>> >>>>>>>       }
>> >>>>>>>
>> >>>>>>> got confused that each static route is identified by an "id".
>> >>>>>> Originally thought it could be metric, but after reading
>> >> description,
>> >>>>>> wasn't sure.
>> >>>>>>>
>> >>>>>>> Lada explained that the id is used in case same prefixes are
>> >>>>>> configured, but have different metric. So why not use prefix and
>> >>>>>> preference as unique identifier? One could even argue that the
>> base
>> >>>> spec
>> >>>>>> only needs to use prefix as the key, and if an implementation
>> >>>> supports
>> >>>>>> multiple static routes for the same prefix they can extend as an
>> >>>>>> optional feature.
>> >>>>>>
>> >>>>>> YANG needs to specify key(s) for configuration lists, so we have
>> to
>> >>>> do
>> >>>>>> it for static routes in ietf-routing, and this key cannot be
>> >> changed
>> >>>> or
>> >>>>>> augmented from other modules.
>> >>>>>>
>> >>>>>> Under these conditions, I am afraid we don't have any natural
>> key(s)
>> >>>>>> that would be universally acceptable. All systems use some
>> >> additional
>> >>>>>> parameters, be they called preference, metric or administrative
>> >>>> distance,
>> >>>>>> but the problem is that, depending on the system, they may be
>> >>>> specified
>> >>>>>> (i) per route, (ii) per destination prefix, or (iii) per protocol
>> >>>>>> instance.
>> >>>>>
>> >>>>> What's the difference between "route" ((i) above) and "destination
>> >>>> prefix" ((ii) above)?
>> >>>>
>> >>>> Quagga can set distance either for a protocol
>> >>>>
>> >>>> distance 
>> >>>>
>> >>>> or selectively
>> >>>>
>> >>>> distance  A.B.C.D/M
>> >>>
>> >>> I was asking the difference between "route" and "destination prefix".
>> >> I guess a "route" means a particular entry (e.g. those with different
>> >> nexthops or in a broader context - from different protcools) for a
>> >> prefix. Is that correct?
>> >>
>> >> Destination prefix is one of the attributes of a route.
>> >>
>> >>>
>> >>>>
>> >>>>> (iii) is irrelevant here - we're talking about "static-route",
>> which
>> >>>> is a "protocol instance" and does not need to be in the key for the
>> >>>> static route entries.
>> >>>>
>> >>>> It is relevant. If we introduce preference as a route attribute in
>> >> ietf-
>> >>>> routing (as it is e.g. in JUNOS or BIRD), then implementations that
>> >>>> don't have it (use only per-protocol distance) would be out of luck.
>> >>>
>> >>> We are talking about specifying static routes. If an implementation
>> >> does not support multiple static route entries for the same prefix
>> (e.g.
>> >> using different nexthops), then the "preference" or whatever we call
>> it
>> >> would be a fixed value say 0. If the implementation does support that,
>> >> then it must provide a preference for each entry.
>> >>
>> >> It makes little sense to introduce "preference" just for
>> discriminating
>> >> among configured static routes with the same destination prefix.
>> Backup
>> >> routes or multi-path routing can be configured using "next-hop-list".
>> >>
>> >> However, this doesn't mean that each destination prefix must always
>> be
>> >> unique in the list of static routes. Future modules may introduce new
>> >> static route attributes, e.g. for policy routing it could be "tos",
>> and
>> >> then it would make a very good sense to configure multiple static
>> routes
>> >> with the same destination prefix but different ToS values.
>> >>
>> >> While static routes can be augmented with a new parameter such as
>> "tos",
>> >> such a parameter cannot be added to the list key.
>> >>
>> >> Lada
>> >>
>> >>>
>> >>> Jeffrey
>> >>>
>> >>>>
>> >>>> Lada
>> >>>>
>> >>>>>
>> >>>>>>
>> >>>>>> For Linux, the key would be the triple (dest. prefix, TOS,
>> >>>> preference).
>> >>>>>
>> >>>>> To me, routes with different TOS behavior could go into different
>> >> RIBs;
>> >>>> or, just put the TOS in the prefix part. Then you're left with
>> >> (prefix,
>> >>>> preference) - exactly what we were proposing as the key.
>> >>>>>
>> >>>>>>
>> >>>>>> So, while I don't like the "id" key at all, I don't see what else
>> >>>> could
>> >>>>>> be done. On the other hand, static routes are usually not defined
>> >> in
>> >>>>>> excessive quantities, so an extra parameter probably doesn't
>> matter.
>> >>>>>>
>> >>>>>> Another important thing to note is that the "id" parameter of
>> >> routes
>> >>>> in
>> >>>>>> RIBs (state data) is unrelated to the "id" of static routes. It
>> was
>> >>>>>> added recently as a part of "harmonization" with I2RS RIB info
>> >> model
>> >>>>>> (state lists don't have to have keys).
>> >>>>>
>> >>>>> That's yet another separate discussion that is going on offline
>> now.
>> >>>> We'll loop back here when it's ready.
>> >>>>>
>> >>>>> Jeffrey
>> >>>>>
>> >>>>>>
>> >>>>>> Lada
>> >>>>>>
>> >>>>>>>
>> >>>>>>> There was an email exchange on this topic offline and we are
>> >>>> curious
>> >>>>>> what does the WG think about this "id"?
>> >>>>>>>
>> >>>>>>> Dean
>> >>>>>>>
>> >>>>>>>
>> >>>>>>
>> >>>>>> --
>> >>>>>> Ladislav Lhotka, CZ.NIC Labs
>> >>>>>> PGP Key ID: E74E8C0C
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>
>> >>>>
>> >>>> --
>> >>>> Ladislav Lhotka, CZ.NIC Labs
>> >>>> PGP Key ID: E74E8C0C
>> >>
>> >> --
>> >> Ladislav Lhotka, CZ.NIC Labs
>> >> PGP Key ID: E74E8C0C
>> >>
>> >>
>> >>
>> >
>> 
>> --
>> Ladislav Lhotka, CZ.NIC Labs
>> PGP Key ID: E74E8C0C
>> 
>> 
>> 
>

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


From nobody Fri Jun 27 04:46:41 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C7091B317D for ; Fri, 27 Jun 2014 04:46:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.602
X-Spam-Level: 
X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vmfnnZ3NDWs5 for ; Fri, 27 Jun 2014 04:46:35 -0700 (PDT)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0238.outbound.protection.outlook.com [207.46.163.238]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE9221B2B12 for ; Fri, 27 Jun 2014 04:46:34 -0700 (PDT)
Received: from BY2PR05MB079.namprd05.prod.outlook.com (10.242.38.16) by CO1PR05MB425.namprd05.prod.outlook.com (10.141.74.11) with Microsoft SMTP Server (TLS) id 15.0.959.24; Fri, 27 Jun 2014 11:46:32 +0000
Received: from BY2PR05MB079.namprd05.prod.outlook.com ([169.254.8.170]) by BY2PR05MB079.namprd05.prod.outlook.com ([169.254.8.170]) with mapi id 15.00.0969.007; Fri, 27 Jun 2014 11:46:31 +0000
From: "Jeffrey (Zhaohui) Zhang" 
To: Ladislav Lhotka 
Thread-Topic: static routes in draft-ietf-netmod-routing-cfg-15
Thread-Index: AQHPkHyQ0orIXWpDoUyLtj2fzemmwZuCCWmAgAAjBWCAAPsgAIAAQPUAgAAKrICAAAN8AIAABmOAgAAApyCAAT/BAIAAF+NQ
Date: Fri, 27 Jun 2014 11:46:30 +0000
Message-ID: 
References: <6CCE7829-D078-41B0-8578-300563AD7CB8@juniper.net> <4F17ABF3-F1E4-4EA3-9F8F-02B02162554D@nic.cz>   <236fa2a7df884545b6f8c4a1dd3e8d9a@BY2PR05MB079.namprd05.prod.outlook.com>   <109A8A1D-29C4-4F4C-80FF-DBCD5FB6999D@nic.cz> <8e9299cd951a42b7a8be67e55e87cccb@BY2PR05MB079.namprd05.prod.outlook.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [66.129.241.12]
x-microsoft-antispam: BCL:0;PCL:0;RULEID:
x-forefront-prvs: 0255DF69B9
x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(377454003)(51704005)(164054003)(199002)(189002)(13464003)(24454002)(19580405001)(83322001)(81542001)(19580395003)(83072002)(74502001)(54356999)(46102001)(50986999)(2656002)(76482001)(87936001)(80022001)(76176999)(76576001)(79102001)(85852003)(74662001)(92566001)(77982001)(101416001)(93886003)(561944003)(33646001)(21056001)(74316001)(4396001)(99286002)(20776003)(64706001)(81342001)(575784001)(86362001)(66066001)(85306003)(31966008)(107046002)(99396002)(95666004)(106116001)(77096002)(105586002)(106356001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR05MB425; H:BY2PR05MB079.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; 
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/kcEucMdOaYtMIx63O9cE9uz5S-Y
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] static routes in draft-ietf-netmod-routing-cfg-15
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 27 Jun 2014 11:46:39 -0000

Lada,

> -----Original Message-----
> From: Ladislav Lhotka [mailto:lhotka@nic.cz]
> Sent: Friday, June 27, 2014 6:05 AM
> To: Jeffrey (Zhaohui) Zhang
> Cc: Dean Bogdanovic; netmod@ietf.org
> Subject: RE: static routes in draft-ietf-netmod-routing-cfg-15
>=20
> "Jeffrey (Zhaohui) Zhang"  writes:
>=20
> > Lada,
> >
> > My proposal is to remove ID and just use prefix.
> > For future extensions like TOS, just augment to include TOS in the pref=
ix.
>=20
> No way. ToS was just an example, other modules may add other parameters
> such as "preference" or "source-address". We can't expect the
> destination prefix to be unique.

Things like "TOS", "source-address" could be considered as part of the pref=
ix. In the base spec, we simply say the key is prefix. For a particular imp=
lementation that needs more than the plain old 32-bit or 128-bit v4/v6 addr=
ess, they can augment that to include addition parameters in the prefix.

For things like "preferences", in an earlier email you were saying that you=
 don't need multiple entries - you just need to have a nexthop list, so I w=
as taking a step back and follow your argument.

For even more other things, please see below.

>=20
> One thing that *might* be possible is to have the following key in
> static routes:
>=20
>   key "destination-prefix id"

That's exactly what I was proposing earlier (to consider preference/metric =
factors) but then I took a step back to follow your argument that for prefe=
rence/metric king of things, using a nexthop list would work.

Now if there are even more complicated situations where it is not feasible =
to augment the prefix, yes we could use an "id" that is only relevant in th=
e context of a particular prefix; however again that id (not the raw parame=
ters behind the id) could be considered as part of the prefix. Therefore, f=
or the base spec, using prefix itself works well and is preferred. An imple=
mentation may be able to simply use the base model, or may have to define t=
heir own extensions.

>=20
> It would be especially useful if optional keys are introduced in YANG
> 1.1 (see issue Y09). The "id" would then be used as an auxiliary
> distinguisher for routes that have the same destination-prefix,
> otherwise it could have the default value.

That's another option, but I still prefer the base spec just uses the prefi=
x.

Jeffrey

>=20
> Lada
>=20
> >
> > Jeffrey
> >
> >> -----Original Message-----
> >> From: Ladislav Lhotka [mailto:lhotka@nic.cz]
> >> Sent: Thursday, June 26, 2014 10:58 AM
> >> To: Jeffrey (Zhaohui) Zhang
> >> Cc: Dean Bogdanovic; netmod@ietf.org
> >> Subject: Re: static routes in draft-ietf-netmod-routing-cfg-15
> >>
> >> Jeffrey, Dean,
> >>
> >> we should move this long discussion towards some resolution. It might
> be
> >> helpful if you propose concrete changes to the current module(s).
> >>
> >> Thanks, Lada
> >>
> >> On 26 Jun 2014, at 16:46, Jeffrey (Zhaohui) Zhang 
> >> wrote:
> >>
> >> > Lada,
> >> >
> >> >> It makes little sense to introduce "preference" just for
> >> discriminating
> >> >> among configured static routes with the same destination prefix.
> >> Backup
> >> >> routes or multi-path routing can be configured using "next-hop-
> list".
> >> >
> >> > If those all have the same
> "preference"/"weight"/"priority"/"whatever",
> >> sure use next-hop-list. But if you want to prefer nh1 over nh2, then
> you
> >> can either use different static route entries with "index", or as you
> >> said still use next-hop-list but give different priorities to each
> >> nexthop in the list.
> >> >
> >> > Some implementations may prefer one way or another. If I take a
> step
> >> back and agree to simply use next-hop-list, then to me we can simply
> use
> >> prefix itself to identify the routes. More below.
> >> >
> >> >>
> >> >> However, this doesn't mean that each destination prefix must
> always
> >> be
> >> >> unique in the list of static routes. Future modules may introduce
> new
> >> >> static route attributes, e.g. for policy routing it could be "tos",
> >> and
> >> >> then it would make a very good sense to configure multiple static
> >> routes
> >> >> with the same destination prefix but different ToS values.
> >> >
> >> > A better way would be to augment it so TOS becomes part of the
> prefix.
> >> >
> >> > Jeffrey
> >> >
> >> >>
> >> >> While static routes can be augmented with a new parameter such as
> >> "tos",
> >> >> such a parameter cannot be added to the list key.
> >> >
> >> >> -----Original Message-----
> >> >> From: Ladislav Lhotka [mailto:lhotka@nic.cz]
> >> >> Sent: Thursday, June 26, 2014 10:23 AM
> >> >> To: Jeffrey (Zhaohui) Zhang
> >> >> Cc: Dean Bogdanovic; netmod@ietf.org
> >> >> Subject: Re: static routes in draft-ietf-netmod-routing-cfg-15
> >> >>
> >> >>
> >> >> On 26 Jun 2014, at 15:50, Jeffrey (Zhaohui) Zhang
> 
> >> >> wrote:
> >> >>
> >> >>> Lada,
> >> >>>
> >> >>>> -----Original Message-----
> >> >>>> From: Ladislav Lhotka [mailto:lhotka@nic.cz]
> >> >>>> Sent: Thursday, June 26, 2014 5:52 AM
> >> >>>> To: Jeffrey (Zhaohui) Zhang; Dean Bogdanovic
> >> >>>> Cc: netmod@ietf.org
> >> >>>> Subject: RE: static routes in draft-ietf-netmod-routing-cfg-15
> >> >>>>
> >> >>>> "Jeffrey (Zhaohui) Zhang"  writes:
> >> >>>>
> >> >>>>> Lada,
> >> >>>>>
> >> >>>>>> -----Original Message-----
> >> >>>>>> From: Ladislav Lhotka [mailto:lhotka@nic.cz]
> >> >>>>>> Sent: Wednesday, June 25, 2014 12:48 PM
> >> >>>>>> To: Dean Bogdanovic
> >> >>>>>> Cc: netmod@ietf.org; Jeffrey (Zhaohui) Zhang
> >> >>>>>> Subject: Re: static routes in draft-ietf-netmod-routing-cfg-15
> >> >>>>>>
> >> >>>>>>
> >> >>>>>> On 25 Jun 2014, at 15:51, Dean Bogdanovic 
> >> wrote:
> >> >>>>>>
> >> >>>>>>> Hi,
> >> >>>>>>>
> >> >>>>>>> While reading routing-cfg, looking at the static route model
> >> >>>>>>> augment "/rt:routing/rt:routing-instance/rt:routing-
> protocols/"
> >> >>>>>>>       + "rt:routing-protocol/rt:static-routes" {
> >> >>>>>>>   ...
> >> >>>>>>>   container ipv4 {
> >> >>>>>>>     description
> >> >>>>>>>       "Configuration of a 'static' pseudo-protocol instance
> >> >>>>>>>        consists of a list of routes.";
> >> >>>>>>>     list route {
> >> >>>>>>>       key "id";
> >> >>>>>>>       ordered-by "user";
> >> >>>>>>>       description
> >> >>>>>>>         "A user-ordered list of static routes.";
> >> >>>>>>>       leaf id {
> >> >>>>>>>         type uint32 {
> >> >>>>>>>           range "1..max";
> >> >>>>>>>         }
> >> >>>>>>>         description
> >> >>>>>>>           "Unique numeric identifier of the route.
> >> >>>>>>>
> >> >>>>>>>            This value is unrelated to system-assigned 'id'
> >> >>>>>>>            parameters of routes in RIBs.";
> >> >>>>>>>       }
> >> >>>>>>>
> >> >>>>>>> got confused that each static route is identified by an "id".
> >> >>>>>> Originally thought it could be metric, but after reading
> >> >> description,
> >> >>>>>> wasn't sure.
> >> >>>>>>>
> >> >>>>>>> Lada explained that the id is used in case same prefixes are
> >> >>>>>> configured, but have different metric. So why not use prefix
> and
> >> >>>>>> preference as unique identifier? One could even argue that the
> >> base
> >> >>>> spec
> >> >>>>>> only needs to use prefix as the key, and if an implementation
> >> >>>> supports
> >> >>>>>> multiple static routes for the same prefix they can extend as
> an
> >> >>>>>> optional feature.
> >> >>>>>>
> >> >>>>>> YANG needs to specify key(s) for configuration lists, so we
> have
> >> to
> >> >>>> do
> >> >>>>>> it for static routes in ietf-routing, and this key cannot be
> >> >> changed
> >> >>>> or
> >> >>>>>> augmented from other modules.
> >> >>>>>>
> >> >>>>>> Under these conditions, I am afraid we don't have any natural
> >> key(s)
> >> >>>>>> that would be universally acceptable. All systems use some
> >> >> additional
> >> >>>>>> parameters, be they called preference, metric or
> administrative
> >> >>>> distance,
> >> >>>>>> but the problem is that, depending on the system, they may be
> >> >>>> specified
> >> >>>>>> (i) per route, (ii) per destination prefix, or (iii) per
> protocol
> >> >>>>>> instance.
> >> >>>>>
> >> >>>>> What's the difference between "route" ((i) above) and
> "destination
> >> >>>> prefix" ((ii) above)?
> >> >>>>
> >> >>>> Quagga can set distance either for a protocol
> >> >>>>
> >> >>>> distance 
> >> >>>>
> >> >>>> or selectively
> >> >>>>
> >> >>>> distance  A.B.C.D/M
> >> >>>
> >> >>> I was asking the difference between "route" and "destination
> prefix".
> >> >> I guess a "route" means a particular entry (e.g. those with
> different
> >> >> nexthops or in a broader context - from different protcools) for a
> >> >> prefix. Is that correct?
> >> >>
> >> >> Destination prefix is one of the attributes of a route.
> >> >>
> >> >>>
> >> >>>>
> >> >>>>> (iii) is irrelevant here - we're talking about "static-route",
> >> which
> >> >>>> is a "protocol instance" and does not need to be in the key for
> the
> >> >>>> static route entries.
> >> >>>>
> >> >>>> It is relevant. If we introduce preference as a route attribute
> in
> >> >> ietf-
> >> >>>> routing (as it is e.g. in JUNOS or BIRD), then implementations
> that
> >> >>>> don't have it (use only per-protocol distance) would be out of
> luck.
> >> >>>
> >> >>> We are talking about specifying static routes. If an
> implementation
> >> >> does not support multiple static route entries for the same prefix
> >> (e.g.
> >> >> using different nexthops), then the "preference" or whatever we
> call
> >> it
> >> >> would be a fixed value say 0. If the implementation does support
> that,
> >> >> then it must provide a preference for each entry.
> >> >>
> >> >> It makes little sense to introduce "preference" just for
> >> discriminating
> >> >> among configured static routes with the same destination prefix.
> >> Backup
> >> >> routes or multi-path routing can be configured using "next-hop-
> list".
> >> >>
> >> >> However, this doesn't mean that each destination prefix must
> always
> >> be
> >> >> unique in the list of static routes. Future modules may introduce
> new
> >> >> static route attributes, e.g. for policy routing it could be "tos",
> >> and
> >> >> then it would make a very good sense to configure multiple static
> >> routes
> >> >> with the same destination prefix but different ToS values.
> >> >>
> >> >> While static routes can be augmented with a new parameter such as
> >> "tos",
> >> >> such a parameter cannot be added to the list key.
> >> >>
> >> >> Lada
> >> >>
> >> >>>
> >> >>> Jeffrey
> >> >>>
> >> >>>>
> >> >>>> Lada
> >> >>>>
> >> >>>>>
> >> >>>>>>
> >> >>>>>> For Linux, the key would be the triple (dest. prefix, TOS,
> >> >>>> preference).
> >> >>>>>
> >> >>>>> To me, routes with different TOS behavior could go into
> different
> >> >> RIBs;
> >> >>>> or, just put the TOS in the prefix part. Then you're left with
> >> >> (prefix,
> >> >>>> preference) - exactly what we were proposing as the key.
> >> >>>>>
> >> >>>>>>
> >> >>>>>> So, while I don't like the "id" key at all, I don't see what
> else
> >> >>>> could
> >> >>>>>> be done. On the other hand, static routes are usually not
> defined
> >> >> in
> >> >>>>>> excessive quantities, so an extra parameter probably doesn't
> >> matter.
> >> >>>>>>
> >> >>>>>> Another important thing to note is that the "id" parameter of
> >> >> routes
> >> >>>> in
> >> >>>>>> RIBs (state data) is unrelated to the "id" of static routes.
> It
> >> was
> >> >>>>>> added recently as a part of "harmonization" with I2RS RIB info
> >> >> model
> >> >>>>>> (state lists don't have to have keys).
> >> >>>>>
> >> >>>>> That's yet another separate discussion that is going on offline
> >> now.
> >> >>>> We'll loop back here when it's ready.
> >> >>>>>
> >> >>>>> Jeffrey
> >> >>>>>
> >> >>>>>>
> >> >>>>>> Lada
> >> >>>>>>
> >> >>>>>>>
> >> >>>>>>> There was an email exchange on this topic offline and we are
> >> >>>> curious
> >> >>>>>> what does the WG think about this "id"?
> >> >>>>>>>
> >> >>>>>>> Dean
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>
> >> >>>>>> --
> >> >>>>>> Ladislav Lhotka, CZ.NIC Labs
> >> >>>>>> PGP Key ID: E74E8C0C
> >> >>>>>>
> >> >>>>>>
> >> >>>>>>
> >> >>>>>
> >> >>>>
> >> >>>> --
> >> >>>> Ladislav Lhotka, CZ.NIC Labs
> >> >>>> PGP Key ID: E74E8C0C
> >> >>
> >> >> --
> >> >> Ladislav Lhotka, CZ.NIC Labs
> >> >> PGP Key ID: E74E8C0C
> >> >>
> >> >>
> >> >>
> >> >
> >>
> >> --
> >> Ladislav Lhotka, CZ.NIC Labs
> >> PGP Key ID: E74E8C0C
> >>
> >>
> >>
> >
>=20
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C


From nobody Fri Jun 27 04:49:19 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D013A1B317D for ; Fri, 27 Jun 2014 04:49:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lmpoddOBUuS1 for ; Fri, 27 Jun 2014 04:49:12 -0700 (PDT)
Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB9611B2B12 for ; Fri, 27 Jun 2014 04:49:11 -0700 (PDT)
Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id E6EA722C7D8; Fri, 27 Jun 2014 13:49:09 +0200 (CEST)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.56]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 8014327C06A; Fri, 27 Jun 2014 13:49:09 +0200 (CEST)
Received: from OPEXCLILM34.corporate.adroot.infra.ftgroup ([169.254.4.110]) by OPEXCLILH04.corporate.adroot.infra.ftgroup ([10.114.31.56]) with mapi id 14.03.0181.006; Fri, 27 Jun 2014 13:49:09 +0200
From: 
To: Ladislav Lhotka , "Jeffrey (Zhaohui) Zhang" 
Thread-Topic: [netmod] static routes in draft-ietf-netmod-routing-cfg-15
Thread-Index: AQHPkVjZ5/h1zRC+fE+1O8i784fEa5uEmjcAgAA6CQA=
Date: Fri, 27 Jun 2014 11:49:09 +0000
Message-ID: <16002_1403869749_53AD5A35_16002_507_1_9E32478DFA9976438E7A22F69B08FF92034FBC@OPEXCLILM34.corporate.adroot.infra.ftgroup>
References: <6CCE7829-D078-41B0-8578-300563AD7CB8@juniper.net> <4F17ABF3-F1E4-4EA3-9F8F-02B02162554D@nic.cz>   <236fa2a7df884545b6f8c4a1dd3e8d9a@BY2PR05MB079.namprd05.prod.outlook.com>   <109A8A1D-29C4-4F4C-80FF-DBCD5FB6999D@nic.cz> <8e9299cd951a42b7a8be67e55e87cccb@BY2PR05MB079.namprd05.prod.outlook.com> 
In-Reply-To: 
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.168.234.3]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.6.25.100319
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/kMQ5xDIbpSTs7GnLNcADXkHhnLc
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] static routes in draft-ietf-netmod-routing-cfg-15
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 27 Jun 2014 11:49:17 -0000

Hi,

I'm wondering if the current model for RIB is the right one. Maybe there wa=
s already discussions on this in the past, so sorry to come back to it , if=
 it's the case ...

Currently the model is to have list of routes. Each route containing nextho=
p and prefix information.
So if I have the following routes :
10.0.0.0/8 ISIS preference 20, metric 100
10.0.0.0/8 OSPF preference 15, metric 500

I would have two route entries in routes with a single nexthop in it for ea=
ch.

If I have :
10.0.0.0/8 Static nexthop 1
10.0.0.0/8 Static nexthop 2

I would have a single route entry with a nexthop-list.

This is not really displaying how RIBs are working today. Moreover it tends=
 to mix how FIB works and how RIB works,  generally we have for RIB :
A single prefix entry followed by a list of paths : some are primary, some =
are protecting (LFA or MRT ...), some are only hidden path (less preferred =
protocol preference). When multipath is enabled, all primaries are used for=
 Loadbalancing.

Why not using this model , so with the example, I would have a single route=
 entry with next-hop-list as next-hop-options. Nexthop-list would have one =
primary nexthop, and one backup nexthop. Moreover I'm not sure about what "=
backup" means, especially if you have a FRR nexthop, would it be "backup" ?=
 I think a new enum may be required for next-hop-classifiers to differentia=
te "hidden routes" (less preferred) from protecting routes (LFA ...), both =
are sort of backup routes ...

Using this system the key of routes can be the destination prefix.
Next-hop-content need then more to be a path-list.
To index path-list, all attributes may require to be taken into account.

Thoughts ?



-----Original Message-----
From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Ladislav Lhotka
Sent: Friday, June 27, 2014 12:05
To: Jeffrey (Zhaohui) Zhang
Cc: netmod@ietf.org
Subject: Re: [netmod] static routes in draft-ietf-netmod-routing-cfg-15

"Jeffrey (Zhaohui) Zhang"  writes:

> Lada,
>
> My proposal is to remove ID and just use prefix.
> For future extensions like TOS, just augment to include TOS in the prefix.

No way. ToS was just an example, other modules may add other parameters suc=
h as "preference" or "source-address". We can't expect the destination pref=
ix to be unique.

One thing that *might* be possible is to have the following key in static r=
outes:

  key "destination-prefix id"

It would be especially useful if optional keys are introduced in YANG 1.1 (=
see issue Y09). The "id" would then be used as an auxiliary distinguisher f=
or routes that have the same destination-prefix, otherwise it could have th=
e default value.

Lada=20=20

>
> Jeffrey
>
>> -----Original Message-----
>> From: Ladislav Lhotka [mailto:lhotka@nic.cz]
>> Sent: Thursday, June 26, 2014 10:58 AM
>> To: Jeffrey (Zhaohui) Zhang
>> Cc: Dean Bogdanovic; netmod@ietf.org
>> Subject: Re: static routes in draft-ietf-netmod-routing-cfg-15
>>=20
>> Jeffrey, Dean,
>>=20
>> we should move this long discussion towards some resolution. It might=20
>> be helpful if you propose concrete changes to the current module(s).
>>=20
>> Thanks, Lada
>>=20
>> On 26 Jun 2014, at 16:46, Jeffrey (Zhaohui) Zhang=20
>> 
>> wrote:
>>=20
>> > Lada,
>> >
>> >> It makes little sense to introduce "preference" just for
>> discriminating
>> >> among configured static routes with the same destination prefix.
>> Backup
>> >> routes or multi-path routing can be configured using "next-hop-list".
>> >
>> > If those all have the same=20
>> > "preference"/"weight"/"priority"/"whatever",
>> sure use next-hop-list. But if you want to prefer nh1 over nh2, then=20
>> you can either use different static route entries with "index", or as=20
>> you said still use next-hop-list but give different priorities to=20
>> each nexthop in the list.
>> >
>> > Some implementations may prefer one way or another. If I take a=20
>> > step
>> back and agree to simply use next-hop-list, then to me we can simply=20
>> use prefix itself to identify the routes. More below.
>> >
>> >>
>> >> However, this doesn't mean that each destination prefix must=20
>> >> always
>> be
>> >> unique in the list of static routes. Future modules may introduce=20
>> >> new static route attributes, e.g. for policy routing it could be=20
>> >> "tos",
>> and
>> >> then it would make a very good sense to configure multiple static
>> routes
>> >> with the same destination prefix but different ToS values.
>> >
>> > A better way would be to augment it so TOS becomes part of the prefix.
>> >
>> > Jeffrey
>> >
>> >>
>> >> While static routes can be augmented with a new parameter such as
>> "tos",
>> >> such a parameter cannot be added to the list key.
>> >
>> >> -----Original Message-----
>> >> From: Ladislav Lhotka [mailto:lhotka@nic.cz]
>> >> Sent: Thursday, June 26, 2014 10:23 AM
>> >> To: Jeffrey (Zhaohui) Zhang
>> >> Cc: Dean Bogdanovic; netmod@ietf.org
>> >> Subject: Re: static routes in draft-ietf-netmod-routing-cfg-15
>> >>
>> >>
>> >> On 26 Jun 2014, at 15:50, Jeffrey (Zhaohui) Zhang=20
>> >> 
>> >> wrote:
>> >>
>> >>> Lada,
>> >>>
>> >>>> -----Original Message-----
>> >>>> From: Ladislav Lhotka [mailto:lhotka@nic.cz]
>> >>>> Sent: Thursday, June 26, 2014 5:52 AM
>> >>>> To: Jeffrey (Zhaohui) Zhang; Dean Bogdanovic
>> >>>> Cc: netmod@ietf.org
>> >>>> Subject: RE: static routes in draft-ietf-netmod-routing-cfg-15
>> >>>>
>> >>>> "Jeffrey (Zhaohui) Zhang"  writes:
>> >>>>
>> >>>>> Lada,
>> >>>>>
>> >>>>>> -----Original Message-----
>> >>>>>> From: Ladislav Lhotka [mailto:lhotka@nic.cz]
>> >>>>>> Sent: Wednesday, June 25, 2014 12:48 PM
>> >>>>>> To: Dean Bogdanovic
>> >>>>>> Cc: netmod@ietf.org; Jeffrey (Zhaohui) Zhang
>> >>>>>> Subject: Re: static routes in draft-ietf-netmod-routing-cfg-15
>> >>>>>>
>> >>>>>>
>> >>>>>> On 25 Jun 2014, at 15:51, Dean Bogdanovic 
>> wrote:
>> >>>>>>
>> >>>>>>> Hi,
>> >>>>>>>
>> >>>>>>> While reading routing-cfg, looking at the static route model=20
>> >>>>>>> augment "/rt:routing/rt:routing-instance/rt:routing-protocols/"
>> >>>>>>>       + "rt:routing-protocol/rt:static-routes" {
>> >>>>>>>   ...
>> >>>>>>>   container ipv4 {
>> >>>>>>>     description
>> >>>>>>>       "Configuration of a 'static' pseudo-protocol instance
>> >>>>>>>        consists of a list of routes.";
>> >>>>>>>     list route {
>> >>>>>>>       key "id";
>> >>>>>>>       ordered-by "user";
>> >>>>>>>       description
>> >>>>>>>         "A user-ordered list of static routes.";
>> >>>>>>>       leaf id {
>> >>>>>>>         type uint32 {
>> >>>>>>>           range "1..max";
>> >>>>>>>         }
>> >>>>>>>         description
>> >>>>>>>           "Unique numeric identifier of the route.
>> >>>>>>>
>> >>>>>>>            This value is unrelated to system-assigned 'id'
>> >>>>>>>            parameters of routes in RIBs.";
>> >>>>>>>       }
>> >>>>>>>
>> >>>>>>> got confused that each static route is identified by an "id".
>> >>>>>> Originally thought it could be metric, but after reading
>> >> description,
>> >>>>>> wasn't sure.
>> >>>>>>>
>> >>>>>>> Lada explained that the id is used in case same prefixes are
>> >>>>>> configured, but have different metric. So why not use prefix=20
>> >>>>>> and preference as unique identifier? One could even argue that=20
>> >>>>>> the
>> base
>> >>>> spec
>> >>>>>> only needs to use prefix as the key, and if an implementation
>> >>>> supports
>> >>>>>> multiple static routes for the same prefix they can extend as=20
>> >>>>>> an optional feature.
>> >>>>>>
>> >>>>>> YANG needs to specify key(s) for configuration lists, so we=20
>> >>>>>> have
>> to
>> >>>> do
>> >>>>>> it for static routes in ietf-routing, and this key cannot be
>> >> changed
>> >>>> or
>> >>>>>> augmented from other modules.
>> >>>>>>
>> >>>>>> Under these conditions, I am afraid we don't have any natural
>> key(s)
>> >>>>>> that would be universally acceptable. All systems use some
>> >> additional
>> >>>>>> parameters, be they called preference, metric or=20
>> >>>>>> administrative
>> >>>> distance,
>> >>>>>> but the problem is that, depending on the system, they may be
>> >>>> specified
>> >>>>>> (i) per route, (ii) per destination prefix, or (iii) per=20
>> >>>>>> protocol instance.
>> >>>>>
>> >>>>> What's the difference between "route" ((i) above) and=20
>> >>>>> "destination
>> >>>> prefix" ((ii) above)?
>> >>>>
>> >>>> Quagga can set distance either for a protocol
>> >>>>
>> >>>> distance 
>> >>>>
>> >>>> or selectively
>> >>>>
>> >>>> distance  A.B.C.D/M
>> >>>
>> >>> I was asking the difference between "route" and "destination prefix".
>> >> I guess a "route" means a particular entry (e.g. those with=20
>> >> different nexthops or in a broader context - from different=20
>> >> protcools) for a prefix. Is that correct?
>> >>
>> >> Destination prefix is one of the attributes of a route.
>> >>
>> >>>
>> >>>>
>> >>>>> (iii) is irrelevant here - we're talking about "static-route",
>> which
>> >>>> is a "protocol instance" and does not need to be in the key for=20
>> >>>> the static route entries.
>> >>>>
>> >>>> It is relevant. If we introduce preference as a route attribute=20
>> >>>> in
>> >> ietf-
>> >>>> routing (as it is e.g. in JUNOS or BIRD), then implementations=20
>> >>>> that don't have it (use only per-protocol distance) would be out of=
 luck.
>> >>>
>> >>> We are talking about specifying static routes. If an=20
>> >>> implementation
>> >> does not support multiple static route entries for the same prefix
>> (e.g.
>> >> using different nexthops), then the "preference" or whatever we=20
>> >> call
>> it
>> >> would be a fixed value say 0. If the implementation does support=20
>> >> that, then it must provide a preference for each entry.
>> >>
>> >> It makes little sense to introduce "preference" just for
>> discriminating
>> >> among configured static routes with the same destination prefix.
>> Backup
>> >> routes or multi-path routing can be configured using "next-hop-list".
>> >>
>> >> However, this doesn't mean that each destination prefix must=20
>> >> always
>> be
>> >> unique in the list of static routes. Future modules may introduce=20
>> >> new static route attributes, e.g. for policy routing it could be=20
>> >> "tos",
>> and
>> >> then it would make a very good sense to configure multiple static
>> routes
>> >> with the same destination prefix but different ToS values.
>> >>
>> >> While static routes can be augmented with a new parameter such as
>> "tos",
>> >> such a parameter cannot be added to the list key.
>> >>
>> >> Lada
>> >>
>> >>>
>> >>> Jeffrey
>> >>>
>> >>>>
>> >>>> Lada
>> >>>>
>> >>>>>
>> >>>>>>
>> >>>>>> For Linux, the key would be the triple (dest. prefix, TOS,
>> >>>> preference).
>> >>>>>
>> >>>>> To me, routes with different TOS behavior could go into=20
>> >>>>> different
>> >> RIBs;
>> >>>> or, just put the TOS in the prefix part. Then you're left with
>> >> (prefix,
>> >>>> preference) - exactly what we were proposing as the key.
>> >>>>>
>> >>>>>>
>> >>>>>> So, while I don't like the "id" key at all, I don't see what=20
>> >>>>>> else
>> >>>> could
>> >>>>>> be done. On the other hand, static routes are usually not=20
>> >>>>>> defined
>> >> in
>> >>>>>> excessive quantities, so an extra parameter probably doesn't
>> matter.
>> >>>>>>
>> >>>>>> Another important thing to note is that the "id" parameter of
>> >> routes
>> >>>> in
>> >>>>>> RIBs (state data) is unrelated to the "id" of static routes.=20
>> >>>>>> It
>> was
>> >>>>>> added recently as a part of "harmonization" with I2RS RIB info
>> >> model
>> >>>>>> (state lists don't have to have keys).
>> >>>>>
>> >>>>> That's yet another separate discussion that is going on offline
>> now.
>> >>>> We'll loop back here when it's ready.
>> >>>>>
>> >>>>> Jeffrey
>> >>>>>
>> >>>>>>
>> >>>>>> Lada
>> >>>>>>
>> >>>>>>>
>> >>>>>>> There was an email exchange on this topic offline and we are
>> >>>> curious
>> >>>>>> what does the WG think about this "id"?
>> >>>>>>>
>> >>>>>>> Dean
>> >>>>>>>
>> >>>>>>>
>> >>>>>>
>> >>>>>> --
>> >>>>>> Ladislav Lhotka, CZ.NIC Labs
>> >>>>>> PGP Key ID: E74E8C0C
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>
>> >>>>
>> >>>> --
>> >>>> Ladislav Lhotka, CZ.NIC Labs
>> >>>> PGP Key ID: E74E8C0C
>> >>
>> >> --
>> >> Ladislav Lhotka, CZ.NIC Labs
>> >> PGP Key ID: E74E8C0C
>> >>
>> >>
>> >>
>> >
>>=20
>> --
>> Ladislav Lhotka, CZ.NIC Labs
>> PGP Key ID: E74E8C0C
>>=20
>>=20
>>=20
>

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

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

___________________________________________________________________________=
______________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.


From nobody Fri Jun 27 05:50:46 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D4F51B3180 for ; Fri, 27 Jun 2014 05:50:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.302
X-Spam-Level: 
X-Spam-Status: No, score=-1.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RP_MATCHES_RCVD=-0.651] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PXdwTPXOzNuI for ; Fri, 27 Jun 2014 05:50:41 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 610E61B2F4D for ; Fri, 27 Jun 2014 05:50:41 -0700 (PDT)
Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id AA04313F853; Fri, 27 Jun 2014 14:50:38 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1403873438; bh=qU+QqGopJ1bHXxinmk8EaBecZg5vq+DUULAm5JWS+zs=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=aUv5NFYfUtBqmQL2+vtGC+zfBEMMFWcqOiU5FVLEm/VBXu3e5HFdY85z8wZZR6swX SH9OWjt41dTBhJcITRfjDFgYo815ogiFDMfKJV8FQC4TS1KA4R8GAAvegdgWHJQ3uV PdicdLkTsPDo0AEjqR7xczu1BxBVRm9zZyNRgI1I=
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
From: Ladislav Lhotka 
In-Reply-To: <16002_1403869749_53AD5A35_16002_507_1_9E32478DFA9976438E7A22F69B08FF92034FBC@OPEXCLILM34.corporate.adroot.infra.ftgroup>
Date: Fri, 27 Jun 2014 14:50:39 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <999D12A8-C4D9-4D68-9D16-BB01728A6579@nic.cz>
References: <6CCE7829-D078-41B0-8578-300563AD7CB8@juniper.net> <4F17ABF3-F1E4-4EA3-9F8F-02B02162554D@nic.cz>   <236fa2a7df884545b6f8c4a1dd3e8d9a@BY2PR05MB079.namprd05.prod.outlook.com>   <109A8A1D-29C4-4F4C-80FF-DBCD5FB6999D@nic.cz> <8e9299cd951a42b7a8be67e55e87cccb@BY2PR05MB079.namprd05.prod.outlook.com>  <16002_1403869749_53AD5A35_16002_507_1_9E32478DFA9976438E7A22F69B08FF92034FBC@OPEXCLILM34.corporate.adroot.infra.ftgroup>
To: stephane.litkowski@orange.com
X-Mailer: Apple Mail (2.1878.2)
X-Virus-Scanned: clamav-milter 0.98.1 at mail
X-Virus-Status: Clean
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/pYFMppSnyP_MS7jwaOSVXz91zso
Cc: "Jeffrey \(Zhaohui\) Zhang" , "netmod@ietf.org" 
Subject: Re: [netmod] static routes in draft-ietf-netmod-routing-cfg-15
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 27 Jun 2014 12:50:44 -0000

On 27 Jun 2014, at 13:49,  =
 wrote:

> Hi,
>=20
> I'm wondering if the current model for RIB is the right one. Maybe =
there was already discussions on this in the past, so sorry to come back =
to it , if it's the case ...
>=20
> Currently the model is to have list of routes. Each route containing =
nexthop and prefix information.
> So if I have the following routes :
> 10.0.0.0/8 ISIS preference 20, metric 100
> 10.0.0.0/8 OSPF preference 15, metric 500
>=20
> I would have two route entries in routes with a single nexthop in it =
for each.
>=20
> If I have :
> 10.0.0.0/8 Static nexthop 1
> 10.0.0.0/8 Static nexthop 2
>=20
> I would have a single route entry with a nexthop-list.

A system supporting the =93multipath-routes=94 feature can use =
=93next-hop-list=94 in its routes.

On the other hand, I assume that two routes with the same destination =
prefix obtained from different protocols will remain separate because =
they may be passed to a route filter and treated differently by it.


>=20
> This is not really displaying how RIBs are working today. Moreover it =
tends to mix how FIB works and how RIB works,  generally we have for RIB =
:

FIB (=3D table containing active routes) is not part of this data model =
because we also need to support systems such as Linux that uses route =
cache.


> A single prefix entry followed by a list of paths : some are primary, =
some are protecting (LFA or MRT ...), some are only hidden path (less =
preferred protocol preference). When multipath is enabled, all primaries =
are used for Loadbalancing.
>=20
> Why not using this model , so with the example, I would have a single =
route entry with next-hop-list as next-hop-options. Nexthop-list would =
have one primary nexthop, and one backup nexthop. Moreover I'm not=20

Because nobody proposed it so far.

> sure about what "backup" means, especially if you have a FRR nexthop, =
would it be "backup" ? I think a new enum may be required for =
next-hop-classifiers to differentiate "hidden routes" (less preferred) =
from protecting routes (LFA ...), both are sort of backup routes ...
>=20
> Using this system the key of routes can be the destination prefix.
> Next-hop-content need then more to be a path-list.
> To index path-list, all attributes may require to be taken into =
account.

For lists in state data keys are optional.

Lada=20

>=20
> Thoughts ?
>=20
>=20
>=20
> -----Original Message-----
> From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Ladislav =
Lhotka
> Sent: Friday, June 27, 2014 12:05
> To: Jeffrey (Zhaohui) Zhang
> Cc: netmod@ietf.org
> Subject: Re: [netmod] static routes in =
draft-ietf-netmod-routing-cfg-15
>=20
> "Jeffrey (Zhaohui) Zhang"  writes:
>=20
>> Lada,
>>=20
>> My proposal is to remove ID and just use prefix.
>> For future extensions like TOS, just augment to include TOS in the =
prefix.
>=20
> No way. ToS was just an example, other modules may add other =
parameters such as "preference" or "source-address". We can't expect the =
destination prefix to be unique.
>=20
> One thing that *might* be possible is to have the following key in =
static routes:
>=20
>  key "destination-prefix id"
>=20
> It would be especially useful if optional keys are introduced in YANG =
1.1 (see issue Y09). The "id" would then be used as an auxiliary =
distinguisher for routes that have the same destination-prefix, =
otherwise it could have the default value.
>=20
> Lada =20
>=20
>>=20
>> Jeffrey
>>=20
>>> -----Original Message-----
>>> From: Ladislav Lhotka [mailto:lhotka@nic.cz]
>>> Sent: Thursday, June 26, 2014 10:58 AM
>>> To: Jeffrey (Zhaohui) Zhang
>>> Cc: Dean Bogdanovic; netmod@ietf.org
>>> Subject: Re: static routes in draft-ietf-netmod-routing-cfg-15
>>>=20
>>> Jeffrey, Dean,
>>>=20
>>> we should move this long discussion towards some resolution. It =
might=20
>>> be helpful if you propose concrete changes to the current module(s).
>>>=20
>>> Thanks, Lada
>>>=20
>>> On 26 Jun 2014, at 16:46, Jeffrey (Zhaohui) Zhang=20
>>> 
>>> wrote:
>>>=20
>>>> Lada,
>>>>=20
>>>>> It makes little sense to introduce "preference" just for
>>> discriminating
>>>>> among configured static routes with the same destination prefix.
>>> Backup
>>>>> routes or multi-path routing can be configured using =
"next-hop-list".
>>>>=20
>>>> If those all have the same=20
>>>> "preference"/"weight"/"priority"/"whatever",
>>> sure use next-hop-list. But if you want to prefer nh1 over nh2, then=20=

>>> you can either use different static route entries with "index", or =
as=20
>>> you said still use next-hop-list but give different priorities to=20
>>> each nexthop in the list.
>>>>=20
>>>> Some implementations may prefer one way or another. If I take a=20
>>>> step
>>> back and agree to simply use next-hop-list, then to me we can simply=20=

>>> use prefix itself to identify the routes. More below.
>>>>=20
>>>>>=20
>>>>> However, this doesn't mean that each destination prefix must=20
>>>>> always
>>> be
>>>>> unique in the list of static routes. Future modules may introduce=20=

>>>>> new static route attributes, e.g. for policy routing it could be=20=

>>>>> "tos",
>>> and
>>>>> then it would make a very good sense to configure multiple static
>>> routes
>>>>> with the same destination prefix but different ToS values.
>>>>=20
>>>> A better way would be to augment it so TOS becomes part of the =
prefix.
>>>>=20
>>>> Jeffrey
>>>>=20
>>>>>=20
>>>>> While static routes can be augmented with a new parameter such as
>>> "tos",
>>>>> such a parameter cannot be added to the list key.
>>>>=20
>>>>> -----Original Message-----
>>>>> From: Ladislav Lhotka [mailto:lhotka@nic.cz]
>>>>> Sent: Thursday, June 26, 2014 10:23 AM
>>>>> To: Jeffrey (Zhaohui) Zhang
>>>>> Cc: Dean Bogdanovic; netmod@ietf.org
>>>>> Subject: Re: static routes in draft-ietf-netmod-routing-cfg-15
>>>>>=20
>>>>>=20
>>>>> On 26 Jun 2014, at 15:50, Jeffrey (Zhaohui) Zhang=20
>>>>> 
>>>>> wrote:
>>>>>=20
>>>>>> Lada,
>>>>>>=20
>>>>>>> -----Original Message-----
>>>>>>> From: Ladislav Lhotka [mailto:lhotka@nic.cz]
>>>>>>> Sent: Thursday, June 26, 2014 5:52 AM
>>>>>>> To: Jeffrey (Zhaohui) Zhang; Dean Bogdanovic
>>>>>>> Cc: netmod@ietf.org
>>>>>>> Subject: RE: static routes in draft-ietf-netmod-routing-cfg-15
>>>>>>>=20
>>>>>>> "Jeffrey (Zhaohui) Zhang"  writes:
>>>>>>>=20
>>>>>>>> Lada,
>>>>>>>>=20
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: Ladislav Lhotka [mailto:lhotka@nic.cz]
>>>>>>>>> Sent: Wednesday, June 25, 2014 12:48 PM
>>>>>>>>> To: Dean Bogdanovic
>>>>>>>>> Cc: netmod@ietf.org; Jeffrey (Zhaohui) Zhang
>>>>>>>>> Subject: Re: static routes in draft-ietf-netmod-routing-cfg-15
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>> On 25 Jun 2014, at 15:51, Dean Bogdanovic 
>>> wrote:
>>>>>>>>>=20
>>>>>>>>>> Hi,
>>>>>>>>>>=20
>>>>>>>>>> While reading routing-cfg, looking at the static route model=20=

>>>>>>>>>> augment =
"/rt:routing/rt:routing-instance/rt:routing-protocols/"
>>>>>>>>>>      + "rt:routing-protocol/rt:static-routes" {
>>>>>>>>>>  ...
>>>>>>>>>>  container ipv4 {
>>>>>>>>>>    description
>>>>>>>>>>      "Configuration of a 'static' pseudo-protocol instance
>>>>>>>>>>       consists of a list of routes.";
>>>>>>>>>>    list route {
>>>>>>>>>>      key "id";
>>>>>>>>>>      ordered-by "user";
>>>>>>>>>>      description
>>>>>>>>>>        "A user-ordered list of static routes.";
>>>>>>>>>>      leaf id {
>>>>>>>>>>        type uint32 {
>>>>>>>>>>          range "1..max";
>>>>>>>>>>        }
>>>>>>>>>>        description
>>>>>>>>>>          "Unique numeric identifier of the route.
>>>>>>>>>>=20
>>>>>>>>>>           This value is unrelated to system-assigned 'id'
>>>>>>>>>>           parameters of routes in RIBs.";
>>>>>>>>>>      }
>>>>>>>>>>=20
>>>>>>>>>> got confused that each static route is identified by an "id".
>>>>>>>>> Originally thought it could be metric, but after reading
>>>>> description,
>>>>>>>>> wasn't sure.
>>>>>>>>>>=20
>>>>>>>>>> Lada explained that the id is used in case same prefixes are
>>>>>>>>> configured, but have different metric. So why not use prefix=20=

>>>>>>>>> and preference as unique identifier? One could even argue that=20=

>>>>>>>>> the
>>> base
>>>>>>> spec
>>>>>>>>> only needs to use prefix as the key, and if an implementation
>>>>>>> supports
>>>>>>>>> multiple static routes for the same prefix they can extend as=20=

>>>>>>>>> an optional feature.
>>>>>>>>>=20
>>>>>>>>> YANG needs to specify key(s) for configuration lists, so we=20
>>>>>>>>> have
>>> to
>>>>>>> do
>>>>>>>>> it for static routes in ietf-routing, and this key cannot be
>>>>> changed
>>>>>>> or
>>>>>>>>> augmented from other modules.
>>>>>>>>>=20
>>>>>>>>> Under these conditions, I am afraid we don't have any natural
>>> key(s)
>>>>>>>>> that would be universally acceptable. All systems use some
>>>>> additional
>>>>>>>>> parameters, be they called preference, metric or=20
>>>>>>>>> administrative
>>>>>>> distance,
>>>>>>>>> but the problem is that, depending on the system, they may be
>>>>>>> specified
>>>>>>>>> (i) per route, (ii) per destination prefix, or (iii) per=20
>>>>>>>>> protocol instance.
>>>>>>>>=20
>>>>>>>> What's the difference between "route" ((i) above) and=20
>>>>>>>> "destination
>>>>>>> prefix" ((ii) above)?
>>>>>>>=20
>>>>>>> Quagga can set distance either for a protocol
>>>>>>>=20
>>>>>>> distance 
>>>>>>>=20
>>>>>>> or selectively
>>>>>>>=20
>>>>>>> distance  A.B.C.D/M
>>>>>>=20
>>>>>> I was asking the difference between "route" and "destination =
prefix".
>>>>> I guess a "route" means a particular entry (e.g. those with=20
>>>>> different nexthops or in a broader context - from different=20
>>>>> protcools) for a prefix. Is that correct?
>>>>>=20
>>>>> Destination prefix is one of the attributes of a route.
>>>>>=20
>>>>>>=20
>>>>>>>=20
>>>>>>>> (iii) is irrelevant here - we're talking about "static-route",
>>> which
>>>>>>> is a "protocol instance" and does not need to be in the key for=20=

>>>>>>> the static route entries.
>>>>>>>=20
>>>>>>> It is relevant. If we introduce preference as a route attribute=20=

>>>>>>> in
>>>>> ietf-
>>>>>>> routing (as it is e.g. in JUNOS or BIRD), then implementations=20=

>>>>>>> that don't have it (use only per-protocol distance) would be out =
of luck.
>>>>>>=20
>>>>>> We are talking about specifying static routes. If an=20
>>>>>> implementation
>>>>> does not support multiple static route entries for the same prefix
>>> (e.g.
>>>>> using different nexthops), then the "preference" or whatever we=20
>>>>> call
>>> it
>>>>> would be a fixed value say 0. If the implementation does support=20=

>>>>> that, then it must provide a preference for each entry.
>>>>>=20
>>>>> It makes little sense to introduce "preference" just for
>>> discriminating
>>>>> among configured static routes with the same destination prefix.
>>> Backup
>>>>> routes or multi-path routing can be configured using =
"next-hop-list".
>>>>>=20
>>>>> However, this doesn't mean that each destination prefix must=20
>>>>> always
>>> be
>>>>> unique in the list of static routes. Future modules may introduce=20=

>>>>> new static route attributes, e.g. for policy routing it could be=20=

>>>>> "tos",
>>> and
>>>>> then it would make a very good sense to configure multiple static
>>> routes
>>>>> with the same destination prefix but different ToS values.
>>>>>=20
>>>>> While static routes can be augmented with a new parameter such as
>>> "tos",
>>>>> such a parameter cannot be added to the list key.
>>>>>=20
>>>>> Lada
>>>>>=20
>>>>>>=20
>>>>>> Jeffrey
>>>>>>=20
>>>>>>>=20
>>>>>>> Lada
>>>>>>>=20
>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>> For Linux, the key would be the triple (dest. prefix, TOS,
>>>>>>> preference).
>>>>>>>>=20
>>>>>>>> To me, routes with different TOS behavior could go into=20
>>>>>>>> different
>>>>> RIBs;
>>>>>>> or, just put the TOS in the prefix part. Then you're left with
>>>>> (prefix,
>>>>>>> preference) - exactly what we were proposing as the key.
>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>> So, while I don't like the "id" key at all, I don't see what=20=

>>>>>>>>> else
>>>>>>> could
>>>>>>>>> be done. On the other hand, static routes are usually not=20
>>>>>>>>> defined
>>>>> in
>>>>>>>>> excessive quantities, so an extra parameter probably doesn't
>>> matter.
>>>>>>>>>=20
>>>>>>>>> Another important thing to note is that the "id" parameter of
>>>>> routes
>>>>>>> in
>>>>>>>>> RIBs (state data) is unrelated to the "id" of static routes.=20=

>>>>>>>>> It
>>> was
>>>>>>>>> added recently as a part of "harmonization" with I2RS RIB info
>>>>> model
>>>>>>>>> (state lists don't have to have keys).
>>>>>>>>=20
>>>>>>>> That's yet another separate discussion that is going on offline
>>> now.
>>>>>>> We'll loop back here when it's ready.
>>>>>>>>=20
>>>>>>>> Jeffrey
>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>> Lada
>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>> There was an email exchange on this topic offline and we are
>>>>>>> curious
>>>>>>>>> what does the WG think about this "id"?
>>>>>>>>>>=20
>>>>>>>>>> Dean
>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>> --
>>>>>>>>> Ladislav Lhotka, CZ.NIC Labs
>>>>>>>>> PGP Key ID: E74E8C0C
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>=20
>>>>>>>=20
>>>>>>> --
>>>>>>> Ladislav Lhotka, CZ.NIC Labs
>>>>>>> PGP Key ID: E74E8C0C
>>>>>=20
>>>>> --
>>>>> Ladislav Lhotka, CZ.NIC Labs
>>>>> PGP Key ID: E74E8C0C
>>>>>=20
>>>>>=20
>>>>>=20
>>>>=20
>>>=20
>>> --
>>> Ladislav Lhotka, CZ.NIC Labs
>>> PGP Key ID: E74E8C0C
>>>=20
>>>=20
>>>=20
>>=20
>=20
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>=20
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>=20
> =
__________________________________________________________________________=
_______________________________________________
>=20
> Ce message et ses pieces jointes peuvent contenir des informations =
confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez =
recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les =
messages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, =
deforme ou falsifie. Merci.
>=20
> This message and its attachments may contain confidential or =
privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and =
delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have =
been modified, changed or falsified.
> Thank you.
>=20

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





From nobody Fri Jun 27 06:22:07 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 333C81B319F for ; Fri, 27 Jun 2014 06:22:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4LS9Jj9XGqVn for ; Fri, 27 Jun 2014 06:22:02 -0700 (PDT)
Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 623AC1B319B for ; Fri, 27 Jun 2014 06:22:01 -0700 (PDT)
Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda14.si.francetelecom.fr (ESMTP service) with ESMTP id A929F2AC39F; Fri, 27 Jun 2014 15:21:59 +0200 (CEST)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.30]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id 90CA9384079; Fri, 27 Jun 2014 15:21:59 +0200 (CEST)
Received: from OPEXCLILM34.corporate.adroot.infra.ftgroup ([169.254.4.110]) by OPEXCLILH02.corporate.adroot.infra.ftgroup ([10.114.31.30]) with mapi id 14.03.0181.006; Fri, 27 Jun 2014 15:21:59 +0200
From: 
To: Ladislav Lhotka 
Thread-Topic: [netmod] static routes in draft-ietf-netmod-routing-cfg-15
Thread-Index: AQHPkVjZ5/h1zRC+fE+1O8i784fEa5uEmjcAgAA6CQD///RSgIAAJQEw
Date: Fri, 27 Jun 2014 13:21:58 +0000
Message-ID: <22741_1403875319_53AD6FF7_22741_879_4_9E32478DFA9976438E7A22F69B08FF920370DE@OPEXCLILM34.corporate.adroot.infra.ftgroup>
References: <6CCE7829-D078-41B0-8578-300563AD7CB8@juniper.net> <4F17ABF3-F1E4-4EA3-9F8F-02B02162554D@nic.cz>   <236fa2a7df884545b6f8c4a1dd3e8d9a@BY2PR05MB079.namprd05.prod.outlook.com>   <109A8A1D-29C4-4F4C-80FF-DBCD5FB6999D@nic.cz> <8e9299cd951a42b7a8be67e55e87cccb@BY2PR05MB079.namprd05.prod.outlook.com>  <16002_1403869749_53AD5A35_16002_507_1_9E32478DFA9976438E7A22F69B08FF92034FBC@OPEXCLILM34.corporate.adroot.infra.ftgroup> <999D12A8-C4D9-4D68-9D16-BB01728A6579@nic.cz>
In-Reply-To: <999D12A8-C4D9-4D68-9D16-BB01728A6579@nic.cz>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.168.234.3]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.6.25.220919
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/Zh7PZdq2fpS9X3fVjo89ghI2HuE
Cc: "Jeffrey \(Zhaohui\) Zhang" , "netmod@ietf.org" 
Subject: Re: [netmod] static routes in draft-ietf-netmod-routing-cfg-15
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 27 Jun 2014 13:22:06 -0000

> A system supporting the "multipath-routes" feature can use "next-hop-list=
" in its routes.

>On the other hand, I assume that two routes with the same destination pref=
ix obtained from different protocols will remain >separate because they may=
 be passed to a route filter and treated differently by it.

[SLI] Regarding route filters, I have one concern regarding the approach fo=
r multiple routes for the same prefix in route list.


Consider that you have a RIP learned route 10/8 at RtrX
RtrX has a "default RIP route-filter" to export RIP routes from connected R=
IB to RIP neighbors.

So it's expected that 10/8 learned RIB route is advertised to neighbors.

Now, I had a static route to 10/8 on RtrX with highest preference than RIP =
protocol.

The 10/8 is expected to not be exported anymore because only best routes ca=
n be exported from RIB and best route is not a RIP one.

That's why I found the model confusing to have different route entries for =
a specific destination. The notion of best path per destination is quite cr=
itical to be present in the model and we need to be able to retrieve all pa=
ths for a specific destination prefix.
The other way to do it, would be to add "active"/"best" leaf in the route l=
ist.


Best Regards,

Stephane

-----Original Message-----
From: Ladislav Lhotka [mailto:lhotka@nic.cz]=20
Sent: Friday, June 27, 2014 14:51
To: LITKOWSKI Stephane SCE/IBNF
Cc: Jeffrey (Zhaohui) Zhang; netmod@ietf.org
Subject: Re: [netmod] static routes in draft-ietf-netmod-routing-cfg-15


On 27 Jun 2014, at 13:49,   wrote:

> Hi,
>=20
> I'm wondering if the current model for RIB is the right one. Maybe there =
was already discussions on this in the past, so sorry to come back to it , =
if it's the case ...
>=20
> Currently the model is to have list of routes. Each route containing next=
hop and prefix information.
> So if I have the following routes :
> 10.0.0.0/8 ISIS preference 20, metric 100
> 10.0.0.0/8 OSPF preference 15, metric 500
>=20
> I would have two route entries in routes with a single nexthop in it for =
each.
>=20
> If I have :
> 10.0.0.0/8 Static nexthop 1
> 10.0.0.0/8 Static nexthop 2
>=20
> I would have a single route entry with a nexthop-list.

A system supporting the "multipath-routes" feature can use "next-hop-list" =
in its routes.

On the other hand, I assume that two routes with the same destination prefi=
x obtained from different protocols will remain separate because they may b=
e passed to a route filter and treated differently by it.


>=20
> This is not really displaying how RIBs are working today. Moreover it ten=
ds to mix how FIB works and how RIB works,  generally we have for RIB :

FIB (=3D table containing active routes) is not part of this data model bec=
ause we also need to support systems such as Linux that uses route cache.


> A single prefix entry followed by a list of paths : some are primary, som=
e are protecting (LFA or MRT ...), some are only hidden path (less preferre=
d protocol preference). When multipath is enabled, all primaries are used f=
or Loadbalancing.
>=20
> Why not using this model , so with the example, I would have a single=20
> route entry with next-hop-list as next-hop-options. Nexthop-list would=20
> have one primary nexthop, and one backup nexthop. Moreover I'm not

Because nobody proposed it so far.

> sure about what "backup" means, especially if you have a FRR nexthop, wou=
ld it be "backup" ? I think a new enum may be required for next-hop-classif=
iers to differentiate "hidden routes" (less preferred) from protecting rout=
es (LFA ...), both are sort of backup routes ...
>=20
> Using this system the key of routes can be the destination prefix.
> Next-hop-content need then more to be a path-list.
> To index path-list, all attributes may require to be taken into account.

For lists in state data keys are optional.

Lada=20

>=20
> Thoughts ?
>=20
>=20
>=20
> -----Original Message-----
> From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Ladislav=20
> Lhotka
> Sent: Friday, June 27, 2014 12:05
> To: Jeffrey (Zhaohui) Zhang
> Cc: netmod@ietf.org
> Subject: Re: [netmod] static routes in=20
> draft-ietf-netmod-routing-cfg-15
>=20
> "Jeffrey (Zhaohui) Zhang"  writes:
>=20
>> Lada,
>>=20
>> My proposal is to remove ID and just use prefix.
>> For future extensions like TOS, just augment to include TOS in the prefi=
x.
>=20
> No way. ToS was just an example, other modules may add other parameters s=
uch as "preference" or "source-address". We can't expect the destination pr=
efix to be unique.
>=20
> One thing that *might* be possible is to have the following key in static=
 routes:
>=20
>  key "destination-prefix id"
>=20
> It would be especially useful if optional keys are introduced in YANG 1.1=
 (see issue Y09). The "id" would then be used as an auxiliary distinguisher=
 for routes that have the same destination-prefix, otherwise it could have =
the default value.
>=20
> Lada
>=20
>>=20
>> Jeffrey
>>=20
>>> -----Original Message-----
>>> From: Ladislav Lhotka [mailto:lhotka@nic.cz]
>>> Sent: Thursday, June 26, 2014 10:58 AM
>>> To: Jeffrey (Zhaohui) Zhang
>>> Cc: Dean Bogdanovic; netmod@ietf.org
>>> Subject: Re: static routes in draft-ietf-netmod-routing-cfg-15
>>>=20
>>> Jeffrey, Dean,
>>>=20
>>> we should move this long discussion towards some resolution. It=20
>>> might be helpful if you propose concrete changes to the current module(=
s).
>>>=20
>>> Thanks, Lada
>>>=20
>>> On 26 Jun 2014, at 16:46, Jeffrey (Zhaohui) Zhang=20
>>> 
>>> wrote:
>>>=20
>>>> Lada,
>>>>=20
>>>>> It makes little sense to introduce "preference" just for
>>> discriminating
>>>>> among configured static routes with the same destination prefix.
>>> Backup
>>>>> routes or multi-path routing can be configured using "next-hop-list".
>>>>=20
>>>> If those all have the same
>>>> "preference"/"weight"/"priority"/"whatever",
>>> sure use next-hop-list. But if you want to prefer nh1 over nh2, then=20
>>> you can either use different static route entries with "index", or=20
>>> as you said still use next-hop-list but give different priorities to=20
>>> each nexthop in the list.
>>>>=20
>>>> Some implementations may prefer one way or another. If I take a=20
>>>> step
>>> back and agree to simply use next-hop-list, then to me we can simply=20
>>> use prefix itself to identify the routes. More below.
>>>>=20
>>>>>=20
>>>>> However, this doesn't mean that each destination prefix must=20
>>>>> always
>>> be
>>>>> unique in the list of static routes. Future modules may introduce=20
>>>>> new static route attributes, e.g. for policy routing it could be=20
>>>>> "tos",
>>> and
>>>>> then it would make a very good sense to configure multiple static
>>> routes
>>>>> with the same destination prefix but different ToS values.
>>>>=20
>>>> A better way would be to augment it so TOS becomes part of the prefix.
>>>>=20
>>>> Jeffrey
>>>>=20
>>>>>=20
>>>>> While static routes can be augmented with a new parameter such as
>>> "tos",
>>>>> such a parameter cannot be added to the list key.
>>>>=20
>>>>> -----Original Message-----
>>>>> From: Ladislav Lhotka [mailto:lhotka@nic.cz]
>>>>> Sent: Thursday, June 26, 2014 10:23 AM
>>>>> To: Jeffrey (Zhaohui) Zhang
>>>>> Cc: Dean Bogdanovic; netmod@ietf.org
>>>>> Subject: Re: static routes in draft-ietf-netmod-routing-cfg-15
>>>>>=20
>>>>>=20
>>>>> On 26 Jun 2014, at 15:50, Jeffrey (Zhaohui) Zhang=20
>>>>> 
>>>>> wrote:
>>>>>=20
>>>>>> Lada,
>>>>>>=20
>>>>>>> -----Original Message-----
>>>>>>> From: Ladislav Lhotka [mailto:lhotka@nic.cz]
>>>>>>> Sent: Thursday, June 26, 2014 5:52 AM
>>>>>>> To: Jeffrey (Zhaohui) Zhang; Dean Bogdanovic
>>>>>>> Cc: netmod@ietf.org
>>>>>>> Subject: RE: static routes in draft-ietf-netmod-routing-cfg-15
>>>>>>>=20
>>>>>>> "Jeffrey (Zhaohui) Zhang"  writes:
>>>>>>>=20
>>>>>>>> Lada,
>>>>>>>>=20
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: Ladislav Lhotka [mailto:lhotka@nic.cz]
>>>>>>>>> Sent: Wednesday, June 25, 2014 12:48 PM
>>>>>>>>> To: Dean Bogdanovic
>>>>>>>>> Cc: netmod@ietf.org; Jeffrey (Zhaohui) Zhang
>>>>>>>>> Subject: Re: static routes in draft-ietf-netmod-routing-cfg-15
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>> On 25 Jun 2014, at 15:51, Dean Bogdanovic 
>>> wrote:
>>>>>>>>>=20
>>>>>>>>>> Hi,
>>>>>>>>>>=20
>>>>>>>>>> While reading routing-cfg, looking at the static route model=20
>>>>>>>>>> augment "/rt:routing/rt:routing-instance/rt:routing-protocols/"
>>>>>>>>>>      + "rt:routing-protocol/rt:static-routes" {  ...
>>>>>>>>>>  container ipv4 {
>>>>>>>>>>    description
>>>>>>>>>>      "Configuration of a 'static' pseudo-protocol instance
>>>>>>>>>>       consists of a list of routes.";
>>>>>>>>>>    list route {
>>>>>>>>>>      key "id";
>>>>>>>>>>      ordered-by "user";
>>>>>>>>>>      description
>>>>>>>>>>        "A user-ordered list of static routes.";
>>>>>>>>>>      leaf id {
>>>>>>>>>>        type uint32 {
>>>>>>>>>>          range "1..max";
>>>>>>>>>>        }
>>>>>>>>>>        description
>>>>>>>>>>          "Unique numeric identifier of the route.
>>>>>>>>>>=20
>>>>>>>>>>           This value is unrelated to system-assigned 'id'
>>>>>>>>>>           parameters of routes in RIBs.";
>>>>>>>>>>      }
>>>>>>>>>>=20
>>>>>>>>>> got confused that each static route is identified by an "id".
>>>>>>>>> Originally thought it could be metric, but after reading
>>>>> description,
>>>>>>>>> wasn't sure.
>>>>>>>>>>=20
>>>>>>>>>> Lada explained that the id is used in case same prefixes are
>>>>>>>>> configured, but have different metric. So why not use prefix=20
>>>>>>>>> and preference as unique identifier? One could even argue that=20
>>>>>>>>> the
>>> base
>>>>>>> spec
>>>>>>>>> only needs to use prefix as the key, and if an implementation
>>>>>>> supports
>>>>>>>>> multiple static routes for the same prefix they can extend as=20
>>>>>>>>> an optional feature.
>>>>>>>>>=20
>>>>>>>>> YANG needs to specify key(s) for configuration lists, so we=20
>>>>>>>>> have
>>> to
>>>>>>> do
>>>>>>>>> it for static routes in ietf-routing, and this key cannot be
>>>>> changed
>>>>>>> or
>>>>>>>>> augmented from other modules.
>>>>>>>>>=20
>>>>>>>>> Under these conditions, I am afraid we don't have any natural
>>> key(s)
>>>>>>>>> that would be universally acceptable. All systems use some
>>>>> additional
>>>>>>>>> parameters, be they called preference, metric or=20
>>>>>>>>> administrative
>>>>>>> distance,
>>>>>>>>> but the problem is that, depending on the system, they may be
>>>>>>> specified
>>>>>>>>> (i) per route, (ii) per destination prefix, or (iii) per=20
>>>>>>>>> protocol instance.
>>>>>>>>=20
>>>>>>>> What's the difference between "route" ((i) above) and=20
>>>>>>>> "destination
>>>>>>> prefix" ((ii) above)?
>>>>>>>=20
>>>>>>> Quagga can set distance either for a protocol
>>>>>>>=20
>>>>>>> distance 
>>>>>>>=20
>>>>>>> or selectively
>>>>>>>=20
>>>>>>> distance  A.B.C.D/M
>>>>>>=20
>>>>>> I was asking the difference between "route" and "destination prefix".
>>>>> I guess a "route" means a particular entry (e.g. those with=20
>>>>> different nexthops or in a broader context - from different
>>>>> protcools) for a prefix. Is that correct?
>>>>>=20
>>>>> Destination prefix is one of the attributes of a route.
>>>>>=20
>>>>>>=20
>>>>>>>=20
>>>>>>>> (iii) is irrelevant here - we're talking about "static-route",
>>> which
>>>>>>> is a "protocol instance" and does not need to be in the key for=20
>>>>>>> the static route entries.
>>>>>>>=20
>>>>>>> It is relevant. If we introduce preference as a route attribute=20
>>>>>>> in
>>>>> ietf-
>>>>>>> routing (as it is e.g. in JUNOS or BIRD), then implementations=20
>>>>>>> that don't have it (use only per-protocol distance) would be out of=
 luck.
>>>>>>=20
>>>>>> We are talking about specifying static routes. If an=20
>>>>>> implementation
>>>>> does not support multiple static route entries for the same prefix
>>> (e.g.
>>>>> using different nexthops), then the "preference" or whatever we=20
>>>>> call
>>> it
>>>>> would be a fixed value say 0. If the implementation does support=20
>>>>> that, then it must provide a preference for each entry.
>>>>>=20
>>>>> It makes little sense to introduce "preference" just for
>>> discriminating
>>>>> among configured static routes with the same destination prefix.
>>> Backup
>>>>> routes or multi-path routing can be configured using "next-hop-list".
>>>>>=20
>>>>> However, this doesn't mean that each destination prefix must=20
>>>>> always
>>> be
>>>>> unique in the list of static routes. Future modules may introduce=20
>>>>> new static route attributes, e.g. for policy routing it could be=20
>>>>> "tos",
>>> and
>>>>> then it would make a very good sense to configure multiple static
>>> routes
>>>>> with the same destination prefix but different ToS values.
>>>>>=20
>>>>> While static routes can be augmented with a new parameter such as
>>> "tos",
>>>>> such a parameter cannot be added to the list key.
>>>>>=20
>>>>> Lada
>>>>>=20
>>>>>>=20
>>>>>> Jeffrey
>>>>>>=20
>>>>>>>=20
>>>>>>> Lada
>>>>>>>=20
>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>> For Linux, the key would be the triple (dest. prefix, TOS,
>>>>>>> preference).
>>>>>>>>=20
>>>>>>>> To me, routes with different TOS behavior could go into=20
>>>>>>>> different
>>>>> RIBs;
>>>>>>> or, just put the TOS in the prefix part. Then you're left with
>>>>> (prefix,
>>>>>>> preference) - exactly what we were proposing as the key.
>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>> So, while I don't like the "id" key at all, I don't see what=20
>>>>>>>>> else
>>>>>>> could
>>>>>>>>> be done. On the other hand, static routes are usually not=20
>>>>>>>>> defined
>>>>> in
>>>>>>>>> excessive quantities, so an extra parameter probably doesn't
>>> matter.
>>>>>>>>>=20
>>>>>>>>> Another important thing to note is that the "id" parameter of
>>>>> routes
>>>>>>> in
>>>>>>>>> RIBs (state data) is unrelated to the "id" of static routes.=20
>>>>>>>>> It
>>> was
>>>>>>>>> added recently as a part of "harmonization" with I2RS RIB info
>>>>> model
>>>>>>>>> (state lists don't have to have keys).
>>>>>>>>=20
>>>>>>>> That's yet another separate discussion that is going on offline
>>> now.
>>>>>>> We'll loop back here when it's ready.
>>>>>>>>=20
>>>>>>>> Jeffrey
>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>> Lada
>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>> There was an email exchange on this topic offline and we are
>>>>>>> curious
>>>>>>>>> what does the WG think about this "id"?
>>>>>>>>>>=20
>>>>>>>>>> Dean
>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>> --
>>>>>>>>> Ladislav Lhotka, CZ.NIC Labs
>>>>>>>>> PGP Key ID: E74E8C0C
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>=20
>>>>>>>=20
>>>>>>> --
>>>>>>> Ladislav Lhotka, CZ.NIC Labs
>>>>>>> PGP Key ID: E74E8C0C
>>>>>=20
>>>>> --
>>>>> Ladislav Lhotka, CZ.NIC Labs
>>>>> PGP Key ID: E74E8C0C
>>>>>=20
>>>>>=20
>>>>>=20
>>>>=20
>>>=20
>>> --
>>> Ladislav Lhotka, CZ.NIC Labs
>>> PGP Key ID: E74E8C0C
>>>=20
>>>=20
>>>=20
>>=20
>=20
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>=20
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>=20
> ______________________________________________________________________
> ___________________________________________________
>=20
> Ce message et ses pieces jointes peuvent contenir des informations=20
> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20
> exploites ou copies sans autorisation. Si vous avez recu ce message=20
> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que =
les pieces jointes. Les messages electroniques etant susceptibles d'alterat=
ion, Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.
>=20
> This message and its attachments may contain confidential or=20
> privileged information that may be protected by law; they should not be d=
istributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and de=
lete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have bee=
n modified, changed or falsified.
> Thank you.
>=20

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





___________________________________________________________________________=
______________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.


From nobody Fri Jun 27 07:10:45 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1C261B2C29 for ; Fri, 27 Jun 2014 07:10:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.302
X-Spam-Level: 
X-Spam-Status: No, score=-1.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RP_MATCHES_RCVD=-0.651] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fZ17FHgxfiyG for ; Fri, 27 Jun 2014 07:10:37 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BEC61B2FB8 for ; Fri, 27 Jun 2014 07:10:35 -0700 (PDT)
Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 51EDE13F6C1; Fri, 27 Jun 2014 16:10:33 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1403878233; bh=lJZRu9BBD5HlG+tMbBnUB1Si8i32ErrvMaZfCv5Abiw=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=pkPfsyr71ZMXvK+muQsnlbkQF1e0t6r8GuF/46AIMjEZUSaQpWeqTO+LRe8Rp4BMl MFakjEAXZRqRKqRpCFyX0BPvB/bmaMuwF7P2AW5amAmujDs6NuuQTDYtXKzUB4U3XC iIJzPaAV5RJS9TuW7oggeWaSK35ynsyxvt+EEmzA=
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
From: Ladislav Lhotka 
In-Reply-To: <22741_1403875319_53AD6FF7_22741_879_4_9E32478DFA9976438E7A22F69B08FF920370DE@OPEXCLILM34.corporate.adroot.infra.ftgroup>
Date: Fri, 27 Jun 2014 16:10:33 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <85661580-5EE0-4D2E-BFF1-063506811858@nic.cz>
References: <6CCE7829-D078-41B0-8578-300563AD7CB8@juniper.net> <4F17ABF3-F1E4-4EA3-9F8F-02B02162554D@nic.cz>   <236fa2a7df884545b6f8c4a1dd3e8d9a@BY2PR05MB079.namprd05.prod.outlook.com>   <109A8A1D-29C4-4F4C-80FF-DBCD5FB6999D@nic.cz> <8e9299cd951a42b7a8be67e55e87cccb@BY2PR05MB079.namprd05.prod.outlook.com>  <16002_1403869749_53AD5A35_16002_507_1_9E32478DFA9976438E7A22F69B08FF92034FBC@OPEXCLILM34.corporate.adroot.infra.ftgroup> <999D12A8-C4D9-4D68-9D16-BB01728A6579@nic.cz> <22741_1403875319_53AD6FF7_22741_879_4_9E32478DFA9976438E7A22F69B08FF920370DE@OPEXCLILM34.corporate.adroot.infra.ftgroup>
To: stephane.litkowski@orange.com
X-Mailer: Apple Mail (2.1878.2)
X-Virus-Scanned: clamav-milter 0.98.1 at mail
X-Virus-Status: Clean
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/yCG3Kkl7RIA_hpeXjtnKFCa9juU
Cc: "Jeffrey \(Zhaohui\) Zhang" , "netmod@ietf.org" 
Subject: Re: [netmod] static routes in draft-ietf-netmod-routing-cfg-15
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 27 Jun 2014 14:10:40 -0000

On 27 Jun 2014, at 15:21,  =
 wrote:

>> A system supporting the "multipath-routes" feature can use =
"next-hop-list" in its routes.
>=20
>> On the other hand, I assume that two routes with the same destination =
prefix obtained from different protocols will remain >separate because =
they may be passed to a route filter and treated differently by it.
>=20
> [SLI] Regarding route filters, I have one concern regarding the =
approach for multiple routes for the same prefix in route list.
>=20
>=20
> Consider that you have a RIP learned route 10/8 at RtrX
> RtrX has a "default RIP route-filter" to export RIP routes from =
connected RIB to RIP neighbors.
>=20
> So it's expected that 10/8 learned RIB route is advertised to =
neighbors.
>=20
> Now, I had a static route to 10/8 on RtrX with highest preference than =
RIP protocol.
>=20
> The 10/8 is expected to not be exported anymore because only best =
routes can be exported from RIB and best route is not a RIP one.
>=20
> That's why I found the model confusing to have different route entries =
for a specific destination. The notion of best path per destination is =
quite critical to be present in the model and we need to be able to =
retrieve all paths for a specific destination prefix.
> The other way to do it, would be to add "active"/"best" leaf in the =
route list.

If I understand you correctly, you=92d prefer to have a RIB as a list =
keyed with destination prefixes and each entry containing a list of =
routes for that prefix with the active route being tagged.

Lada

>=20
>=20
> Best Regards,
>=20
> Stephane
>=20
> -----Original Message-----
> From: Ladislav Lhotka [mailto:lhotka@nic.cz]=20
> Sent: Friday, June 27, 2014 14:51
> To: LITKOWSKI Stephane SCE/IBNF
> Cc: Jeffrey (Zhaohui) Zhang; netmod@ietf.org
> Subject: Re: [netmod] static routes in =
draft-ietf-netmod-routing-cfg-15
>=20
>=20
> On 27 Jun 2014, at 13:49,  =
 wrote:
>=20
>> Hi,
>>=20
>> I'm wondering if the current model for RIB is the right one. Maybe =
there was already discussions on this in the past, so sorry to come back =
to it , if it's the case ...
>>=20
>> Currently the model is to have list of routes. Each route containing =
nexthop and prefix information.
>> So if I have the following routes :
>> 10.0.0.0/8 ISIS preference 20, metric 100
>> 10.0.0.0/8 OSPF preference 15, metric 500
>>=20
>> I would have two route entries in routes with a single nexthop in it =
for each.
>>=20
>> If I have :
>> 10.0.0.0/8 Static nexthop 1
>> 10.0.0.0/8 Static nexthop 2
>>=20
>> I would have a single route entry with a nexthop-list.
>=20
> A system supporting the "multipath-routes" feature can use =
"next-hop-list" in its routes.
>=20
> On the other hand, I assume that two routes with the same destination =
prefix obtained from different protocols will remain separate because =
they may be passed to a route filter and treated differently by it.
>=20
>=20
>>=20
>> This is not really displaying how RIBs are working today. Moreover it =
tends to mix how FIB works and how RIB works,  generally we have for RIB =
:
>=20
> FIB (=3D table containing active routes) is not part of this data =
model because we also need to support systems such as Linux that uses =
route cache.
>=20
>=20
>> A single prefix entry followed by a list of paths : some are primary, =
some are protecting (LFA or MRT ...), some are only hidden path (less =
preferred protocol preference). When multipath is enabled, all primaries =
are used for Loadbalancing.
>>=20
>> Why not using this model , so with the example, I would have a single=20=

>> route entry with next-hop-list as next-hop-options. Nexthop-list =
would=20
>> have one primary nexthop, and one backup nexthop. Moreover I'm not
>=20
> Because nobody proposed it so far.
>=20
>> sure about what "backup" means, especially if you have a FRR nexthop, =
would it be "backup" ? I think a new enum may be required for =
next-hop-classifiers to differentiate "hidden routes" (less preferred) =
from protecting routes (LFA ...), both are sort of backup routes ...
>>=20
>> Using this system the key of routes can be the destination prefix.
>> Next-hop-content need then more to be a path-list.
>> To index path-list, all attributes may require to be taken into =
account.
>=20
> For lists in state data keys are optional.
>=20
> Lada=20
>=20
>>=20
>> Thoughts ?
>>=20
>>=20
>>=20
>> -----Original Message-----
>> From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Ladislav=20=

>> Lhotka
>> Sent: Friday, June 27, 2014 12:05
>> To: Jeffrey (Zhaohui) Zhang
>> Cc: netmod@ietf.org
>> Subject: Re: [netmod] static routes in=20
>> draft-ietf-netmod-routing-cfg-15
>>=20
>> "Jeffrey (Zhaohui) Zhang"  writes:
>>=20
>>> Lada,
>>>=20
>>> My proposal is to remove ID and just use prefix.
>>> For future extensions like TOS, just augment to include TOS in the =
prefix.
>>=20
>> No way. ToS was just an example, other modules may add other =
parameters such as "preference" or "source-address". We can't expect the =
destination prefix to be unique.
>>=20
>> One thing that *might* be possible is to have the following key in =
static routes:
>>=20
>> key "destination-prefix id"
>>=20
>> It would be especially useful if optional keys are introduced in YANG =
1.1 (see issue Y09). The "id" would then be used as an auxiliary =
distinguisher for routes that have the same destination-prefix, =
otherwise it could have the default value.
>>=20
>> Lada
>>=20
>>>=20
>>> Jeffrey
>>>=20
>>>> -----Original Message-----
>>>> From: Ladislav Lhotka [mailto:lhotka@nic.cz]
>>>> Sent: Thursday, June 26, 2014 10:58 AM
>>>> To: Jeffrey (Zhaohui) Zhang
>>>> Cc: Dean Bogdanovic; netmod@ietf.org
>>>> Subject: Re: static routes in draft-ietf-netmod-routing-cfg-15
>>>>=20
>>>> Jeffrey, Dean,
>>>>=20
>>>> we should move this long discussion towards some resolution. It=20
>>>> might be helpful if you propose concrete changes to the current =
module(s).
>>>>=20
>>>> Thanks, Lada
>>>>=20
>>>> On 26 Jun 2014, at 16:46, Jeffrey (Zhaohui) Zhang=20
>>>> 
>>>> wrote:
>>>>=20
>>>>> Lada,
>>>>>=20
>>>>>> It makes little sense to introduce "preference" just for
>>>> discriminating
>>>>>> among configured static routes with the same destination prefix.
>>>> Backup
>>>>>> routes or multi-path routing can be configured using =
"next-hop-list".
>>>>>=20
>>>>> If those all have the same
>>>>> "preference"/"weight"/"priority"/"whatever",
>>>> sure use next-hop-list. But if you want to prefer nh1 over nh2, =
then=20
>>>> you can either use different static route entries with "index", or=20=

>>>> as you said still use next-hop-list but give different priorities =
to=20
>>>> each nexthop in the list.
>>>>>=20
>>>>> Some implementations may prefer one way or another. If I take a=20
>>>>> step
>>>> back and agree to simply use next-hop-list, then to me we can =
simply=20
>>>> use prefix itself to identify the routes. More below.
>>>>>=20
>>>>>>=20
>>>>>> However, this doesn't mean that each destination prefix must=20
>>>>>> always
>>>> be
>>>>>> unique in the list of static routes. Future modules may introduce=20=

>>>>>> new static route attributes, e.g. for policy routing it could be=20=

>>>>>> "tos",
>>>> and
>>>>>> then it would make a very good sense to configure multiple static
>>>> routes
>>>>>> with the same destination prefix but different ToS values.
>>>>>=20
>>>>> A better way would be to augment it so TOS becomes part of the =
prefix.
>>>>>=20
>>>>> Jeffrey
>>>>>=20
>>>>>>=20
>>>>>> While static routes can be augmented with a new parameter such as
>>>> "tos",
>>>>>> such a parameter cannot be added to the list key.
>>>>>=20
>>>>>> -----Original Message-----
>>>>>> From: Ladislav Lhotka [mailto:lhotka@nic.cz]
>>>>>> Sent: Thursday, June 26, 2014 10:23 AM
>>>>>> To: Jeffrey (Zhaohui) Zhang
>>>>>> Cc: Dean Bogdanovic; netmod@ietf.org
>>>>>> Subject: Re: static routes in draft-ietf-netmod-routing-cfg-15
>>>>>>=20
>>>>>>=20
>>>>>> On 26 Jun 2014, at 15:50, Jeffrey (Zhaohui) Zhang=20
>>>>>> 
>>>>>> wrote:
>>>>>>=20
>>>>>>> Lada,
>>>>>>>=20
>>>>>>>> -----Original Message-----
>>>>>>>> From: Ladislav Lhotka [mailto:lhotka@nic.cz]
>>>>>>>> Sent: Thursday, June 26, 2014 5:52 AM
>>>>>>>> To: Jeffrey (Zhaohui) Zhang; Dean Bogdanovic
>>>>>>>> Cc: netmod@ietf.org
>>>>>>>> Subject: RE: static routes in draft-ietf-netmod-routing-cfg-15
>>>>>>>>=20
>>>>>>>> "Jeffrey (Zhaohui) Zhang"  writes:
>>>>>>>>=20
>>>>>>>>> Lada,
>>>>>>>>>=20
>>>>>>>>>> -----Original Message-----
>>>>>>>>>> From: Ladislav Lhotka [mailto:lhotka@nic.cz]
>>>>>>>>>> Sent: Wednesday, June 25, 2014 12:48 PM
>>>>>>>>>> To: Dean Bogdanovic
>>>>>>>>>> Cc: netmod@ietf.org; Jeffrey (Zhaohui) Zhang
>>>>>>>>>> Subject: Re: static routes in =
draft-ietf-netmod-routing-cfg-15
>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>> On 25 Jun 2014, at 15:51, Dean Bogdanovic 
>>>> wrote:
>>>>>>>>>>=20
>>>>>>>>>>> Hi,
>>>>>>>>>>>=20
>>>>>>>>>>> While reading routing-cfg, looking at the static route model=20=

>>>>>>>>>>> augment =
"/rt:routing/rt:routing-instance/rt:routing-protocols/"
>>>>>>>>>>>     + "rt:routing-protocol/rt:static-routes" {  ...
>>>>>>>>>>> container ipv4 {
>>>>>>>>>>>   description
>>>>>>>>>>>     "Configuration of a 'static' pseudo-protocol instance
>>>>>>>>>>>      consists of a list of routes.";
>>>>>>>>>>>   list route {
>>>>>>>>>>>     key "id";
>>>>>>>>>>>     ordered-by "user";
>>>>>>>>>>>     description
>>>>>>>>>>>       "A user-ordered list of static routes.";
>>>>>>>>>>>     leaf id {
>>>>>>>>>>>       type uint32 {
>>>>>>>>>>>         range "1..max";
>>>>>>>>>>>       }
>>>>>>>>>>>       description
>>>>>>>>>>>         "Unique numeric identifier of the route.
>>>>>>>>>>>=20
>>>>>>>>>>>          This value is unrelated to system-assigned 'id'
>>>>>>>>>>>          parameters of routes in RIBs.";
>>>>>>>>>>>     }
>>>>>>>>>>>=20
>>>>>>>>>>> got confused that each static route is identified by an =
"id".
>>>>>>>>>> Originally thought it could be metric, but after reading
>>>>>> description,
>>>>>>>>>> wasn't sure.
>>>>>>>>>>>=20
>>>>>>>>>>> Lada explained that the id is used in case same prefixes are
>>>>>>>>>> configured, but have different metric. So why not use prefix=20=

>>>>>>>>>> and preference as unique identifier? One could even argue =
that=20
>>>>>>>>>> the
>>>> base
>>>>>>>> spec
>>>>>>>>>> only needs to use prefix as the key, and if an implementation
>>>>>>>> supports
>>>>>>>>>> multiple static routes for the same prefix they can extend as=20=

>>>>>>>>>> an optional feature.
>>>>>>>>>>=20
>>>>>>>>>> YANG needs to specify key(s) for configuration lists, so we=20=

>>>>>>>>>> have
>>>> to
>>>>>>>> do
>>>>>>>>>> it for static routes in ietf-routing, and this key cannot be
>>>>>> changed
>>>>>>>> or
>>>>>>>>>> augmented from other modules.
>>>>>>>>>>=20
>>>>>>>>>> Under these conditions, I am afraid we don't have any natural
>>>> key(s)
>>>>>>>>>> that would be universally acceptable. All systems use some
>>>>>> additional
>>>>>>>>>> parameters, be they called preference, metric or=20
>>>>>>>>>> administrative
>>>>>>>> distance,
>>>>>>>>>> but the problem is that, depending on the system, they may be
>>>>>>>> specified
>>>>>>>>>> (i) per route, (ii) per destination prefix, or (iii) per=20
>>>>>>>>>> protocol instance.
>>>>>>>>>=20
>>>>>>>>> What's the difference between "route" ((i) above) and=20
>>>>>>>>> "destination
>>>>>>>> prefix" ((ii) above)?
>>>>>>>>=20
>>>>>>>> Quagga can set distance either for a protocol
>>>>>>>>=20
>>>>>>>> distance 
>>>>>>>>=20
>>>>>>>> or selectively
>>>>>>>>=20
>>>>>>>> distance  A.B.C.D/M
>>>>>>>=20
>>>>>>> I was asking the difference between "route" and "destination =
prefix".
>>>>>> I guess a "route" means a particular entry (e.g. those with=20
>>>>>> different nexthops or in a broader context - from different
>>>>>> protcools) for a prefix. Is that correct?
>>>>>>=20
>>>>>> Destination prefix is one of the attributes of a route.
>>>>>>=20
>>>>>>>=20
>>>>>>>>=20
>>>>>>>>> (iii) is irrelevant here - we're talking about "static-route",
>>>> which
>>>>>>>> is a "protocol instance" and does not need to be in the key for=20=

>>>>>>>> the static route entries.
>>>>>>>>=20
>>>>>>>> It is relevant. If we introduce preference as a route attribute=20=

>>>>>>>> in
>>>>>> ietf-
>>>>>>>> routing (as it is e.g. in JUNOS or BIRD), then implementations=20=

>>>>>>>> that don't have it (use only per-protocol distance) would be =
out of luck.
>>>>>>>=20
>>>>>>> We are talking about specifying static routes. If an=20
>>>>>>> implementation
>>>>>> does not support multiple static route entries for the same =
prefix
>>>> (e.g.
>>>>>> using different nexthops), then the "preference" or whatever we=20=

>>>>>> call
>>>> it
>>>>>> would be a fixed value say 0. If the implementation does support=20=

>>>>>> that, then it must provide a preference for each entry.
>>>>>>=20
>>>>>> It makes little sense to introduce "preference" just for
>>>> discriminating
>>>>>> among configured static routes with the same destination prefix.
>>>> Backup
>>>>>> routes or multi-path routing can be configured using =
"next-hop-list".
>>>>>>=20
>>>>>> However, this doesn't mean that each destination prefix must=20
>>>>>> always
>>>> be
>>>>>> unique in the list of static routes. Future modules may introduce=20=

>>>>>> new static route attributes, e.g. for policy routing it could be=20=

>>>>>> "tos",
>>>> and
>>>>>> then it would make a very good sense to configure multiple static
>>>> routes
>>>>>> with the same destination prefix but different ToS values.
>>>>>>=20
>>>>>> While static routes can be augmented with a new parameter such as
>>>> "tos",
>>>>>> such a parameter cannot be added to the list key.
>>>>>>=20
>>>>>> Lada
>>>>>>=20
>>>>>>>=20
>>>>>>> Jeffrey
>>>>>>>=20
>>>>>>>>=20
>>>>>>>> Lada
>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>> For Linux, the key would be the triple (dest. prefix, TOS,
>>>>>>>> preference).
>>>>>>>>>=20
>>>>>>>>> To me, routes with different TOS behavior could go into=20
>>>>>>>>> different
>>>>>> RIBs;
>>>>>>>> or, just put the TOS in the prefix part. Then you're left with
>>>>>> (prefix,
>>>>>>>> preference) - exactly what we were proposing as the key.
>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>> So, while I don't like the "id" key at all, I don't see what=20=

>>>>>>>>>> else
>>>>>>>> could
>>>>>>>>>> be done. On the other hand, static routes are usually not=20
>>>>>>>>>> defined
>>>>>> in
>>>>>>>>>> excessive quantities, so an extra parameter probably doesn't
>>>> matter.
>>>>>>>>>>=20
>>>>>>>>>> Another important thing to note is that the "id" parameter of
>>>>>> routes
>>>>>>>> in
>>>>>>>>>> RIBs (state data) is unrelated to the "id" of static routes.=20=

>>>>>>>>>> It
>>>> was
>>>>>>>>>> added recently as a part of "harmonization" with I2RS RIB =
info
>>>>>> model
>>>>>>>>>> (state lists don't have to have keys).
>>>>>>>>>=20
>>>>>>>>> That's yet another separate discussion that is going on =
offline
>>>> now.
>>>>>>>> We'll loop back here when it's ready.
>>>>>>>>>=20
>>>>>>>>> Jeffrey
>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>> Lada
>>>>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>>>>>> There was an email exchange on this topic offline and we are
>>>>>>>> curious
>>>>>>>>>> what does the WG think about this "id"?
>>>>>>>>>>>=20
>>>>>>>>>>> Dean
>>>>>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>> --
>>>>>>>>>> Ladislav Lhotka, CZ.NIC Labs
>>>>>>>>>> PGP Key ID: E74E8C0C
>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>=20
>>>>>>>> --
>>>>>>>> Ladislav Lhotka, CZ.NIC Labs
>>>>>>>> PGP Key ID: E74E8C0C
>>>>>>=20
>>>>>> --
>>>>>> Ladislav Lhotka, CZ.NIC Labs
>>>>>> PGP Key ID: E74E8C0C
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>=20
>>>>=20
>>>> --
>>>> Ladislav Lhotka, CZ.NIC Labs
>>>> PGP Key ID: E74E8C0C
>>>>=20
>>>>=20
>>>>=20
>>>=20
>>=20
>> --
>> Ladislav Lhotka, CZ.NIC Labs
>> PGP Key ID: E74E8C0C
>>=20
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>>=20
>> =
______________________________________________________________________
>> ___________________________________________________
>>=20
>> Ce message et ses pieces jointes peuvent contenir des informations=20
>> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20=

>> exploites ou copies sans autorisation. Si vous avez recu ce message=20=

>> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi =
que les pieces jointes. Les messages electroniques etant susceptibles =
d'alteration, Orange decline toute responsabilite si ce message a ete =
altere, deforme ou falsifie. Merci.
>>=20
>> This message and its attachments may contain confidential or=20
>> privileged information that may be protected by law; they should not =
be distributed, used or copied without authorisation.
>> If you have received this email in error, please notify the sender =
and delete this message and its attachments.
>> As emails may be altered, Orange is not liable for messages that have =
been modified, changed or falsified.
>> Thank you.
>>=20
>=20
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>=20
>=20
>=20
>=20
>=20
> =
__________________________________________________________________________=
_______________________________________________
>=20
> Ce message et ses pieces jointes peuvent contenir des informations =
confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez =
recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les =
messages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, =
deforme ou falsifie. Merci.
>=20
> This message and its attachments may contain confidential or =
privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and =
delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have =
been modified, changed or falsified.
> Thank you.
>=20

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





From nobody Fri Jun 27 08:00:07 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A03CD1B2B5F for ; Fri, 27 Jun 2014 08:00:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AaLk3tRs_OSk for ; Fri, 27 Jun 2014 08:00:01 -0700 (PDT)
Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82C851B3207 for ; Fri, 27 Jun 2014 07:59:46 -0700 (PDT)
Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 207563B4390; Fri, 27 Jun 2014 16:59:45 +0200 (CEST)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.5]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id F1637238055; Fri, 27 Jun 2014 16:59:44 +0200 (CEST)
Received: from OPEXCLILM34.corporate.adroot.infra.ftgroup ([169.254.4.110]) by OPEXCLILH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0181.006; Fri, 27 Jun 2014 16:59:44 +0200
From: 
To: Ladislav Lhotka 
Thread-Topic: [netmod] static routes in draft-ietf-netmod-routing-cfg-15
Thread-Index: AQHPkVjZ5/h1zRC+fE+1O8i784fEa5uEmjcAgAA6CQD///RSgIAAJQEw///xUoCAACs1gA==
Date: Fri, 27 Jun 2014 14:59:44 +0000
Message-ID: <15159_1403881185_53AD86E1_15159_4507_1_9E32478DFA9976438E7A22F69B08FF92039219@OPEXCLILM34.corporate.adroot.infra.ftgroup>
References: <6CCE7829-D078-41B0-8578-300563AD7CB8@juniper.net> <4F17ABF3-F1E4-4EA3-9F8F-02B02162554D@nic.cz>   <236fa2a7df884545b6f8c4a1dd3e8d9a@BY2PR05MB079.namprd05.prod.outlook.com>   <109A8A1D-29C4-4F4C-80FF-DBCD5FB6999D@nic.cz> <8e9299cd951a42b7a8be67e55e87cccb@BY2PR05MB079.namprd05.prod.outlook.com>  <16002_1403869749_53AD5A35_16002_507_1_9E32478DFA9976438E7A22F69B08FF92034FBC@OPEXCLILM34.corporate.adroot.infra.ftgroup> <999D12A8-C4D9-4D68-9D16-BB01728A6579@nic.cz> <22741_1403875319_53AD6FF7_22741_879_4_9E32478DFA9976438E7A22F69B08FF920370DE@OPEXCLILM34.corporate.adroot.infra.ftgroup> <85661580-5EE0-4D2E-BFF1-063506811858@nic.cz>
In-Reply-To: <85661580-5EE0-4D2E-BFF1-063506811858@nic.cz>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.168.234.1]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.6.27.103319
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/dAi6BD76KBPUba5VJoG25mBBBwg
Cc: "Jeffrey \(Zhaohui\) Zhang" , "netmod@ietf.org" 
Subject: Re: [netmod] static routes in draft-ietf-netmod-routing-cfg-15
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 27 Jun 2014 15:00:05 -0000

> If I understand you correctly, you'd prefer to have a RIB as a list keyed=
 with destination prefixes and each entry containing a list of routes for t=
hat prefix with the active route being tagged.

[SLI] The major point is to be able to identify the easily the "route-type"=
 : best, non best.



-----Original Message-----
From: Ladislav Lhotka [mailto:lhotka@nic.cz]=20
Sent: Friday, June 27, 2014 16:11
To: LITKOWSKI Stephane SCE/IBNF
Cc: Jeffrey (Zhaohui) Zhang; netmod@ietf.org
Subject: Re: [netmod] static routes in draft-ietf-netmod-routing-cfg-15


On 27 Jun 2014, at 15:21,   wrote:

>> A system supporting the "multipath-routes" feature can use "next-hop-lis=
t" in its routes.
>=20
>> On the other hand, I assume that two routes with the same destination pr=
efix obtained from different protocols will remain >separate because they m=
ay be passed to a route filter and treated differently by it.
>=20
> [SLI] Regarding route filters, I have one concern regarding the approach =
for multiple routes for the same prefix in route list.
>=20
>=20
> Consider that you have a RIP learned route 10/8 at RtrX RtrX has a=20
> "default RIP route-filter" to export RIP routes from connected RIB to RIP=
 neighbors.
>=20
> So it's expected that 10/8 learned RIB route is advertised to neighbors.
>=20
> Now, I had a static route to 10/8 on RtrX with highest preference than RI=
P protocol.
>=20
> The 10/8 is expected to not be exported anymore because only best routes =
can be exported from RIB and best route is not a RIP one.
>=20
> That's why I found the model confusing to have different route entries fo=
r a specific destination. The notion of best path per destination is quite =
critical to be present in the model and we need to be able to retrieve all =
paths for a specific destination prefix.
> The other way to do it, would be to add "active"/"best" leaf in the route=
 list.

If I understand you correctly, you'd prefer to have a RIB as a list keyed w=
ith destination prefixes and each entry containing a list of routes for tha=
t prefix with the active route being tagged.

Lada

>=20
>=20
> Best Regards,
>=20
> Stephane
>=20
> -----Original Message-----
> From: Ladislav Lhotka [mailto:lhotka@nic.cz]
> Sent: Friday, June 27, 2014 14:51
> To: LITKOWSKI Stephane SCE/IBNF
> Cc: Jeffrey (Zhaohui) Zhang; netmod@ietf.org
> Subject: Re: [netmod] static routes in=20
> draft-ietf-netmod-routing-cfg-15
>=20
>=20
> On 27 Jun 2014, at 13:49,   wrote:
>=20
>> Hi,
>>=20
>> I'm wondering if the current model for RIB is the right one. Maybe there=
 was already discussions on this in the past, so sorry to come back to it ,=
 if it's the case ...
>>=20
>> Currently the model is to have list of routes. Each route containing nex=
thop and prefix information.
>> So if I have the following routes :
>> 10.0.0.0/8 ISIS preference 20, metric 100
>> 10.0.0.0/8 OSPF preference 15, metric 500
>>=20
>> I would have two route entries in routes with a single nexthop in it for=
 each.
>>=20
>> If I have :
>> 10.0.0.0/8 Static nexthop 1
>> 10.0.0.0/8 Static nexthop 2
>>=20
>> I would have a single route entry with a nexthop-list.
>=20
> A system supporting the "multipath-routes" feature can use "next-hop-list=
" in its routes.
>=20
> On the other hand, I assume that two routes with the same destination pre=
fix obtained from different protocols will remain separate because they may=
 be passed to a route filter and treated differently by it.
>=20
>=20
>>=20
>> This is not really displaying how RIBs are working today. Moreover it te=
nds to mix how FIB works and how RIB works,  generally we have for RIB :
>=20
> FIB (=3D table containing active routes) is not part of this data model b=
ecause we also need to support systems such as Linux that uses route cache.
>=20
>=20
>> A single prefix entry followed by a list of paths : some are primary, so=
me are protecting (LFA or MRT ...), some are only hidden path (less preferr=
ed protocol preference). When multipath is enabled, all primaries are used =
for Loadbalancing.
>>=20
>> Why not using this model , so with the example, I would have a single=20
>> route entry with next-hop-list as next-hop-options. Nexthop-list=20
>> would have one primary nexthop, and one backup nexthop. Moreover I'm=20
>> not
>=20
> Because nobody proposed it so far.
>=20
>> sure about what "backup" means, especially if you have a FRR nexthop, wo=
uld it be "backup" ? I think a new enum may be required for next-hop-classi=
fiers to differentiate "hidden routes" (less preferred) from protecting rou=
tes (LFA ...), both are sort of backup routes ...
>>=20
>> Using this system the key of routes can be the destination prefix.
>> Next-hop-content need then more to be a path-list.
>> To index path-list, all attributes may require to be taken into account.
>=20
> For lists in state data keys are optional.
>=20
> Lada
>=20
>>=20
>> Thoughts ?
>>=20
>>=20
>>=20
>> -----Original Message-----
>> From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Ladislav=20
>> Lhotka
>> Sent: Friday, June 27, 2014 12:05
>> To: Jeffrey (Zhaohui) Zhang
>> Cc: netmod@ietf.org
>> Subject: Re: [netmod] static routes in
>> draft-ietf-netmod-routing-cfg-15
>>=20
>> "Jeffrey (Zhaohui) Zhang"  writes:
>>=20
>>> Lada,
>>>=20
>>> My proposal is to remove ID and just use prefix.
>>> For future extensions like TOS, just augment to include TOS in the pref=
ix.
>>=20
>> No way. ToS was just an example, other modules may add other parameters =
such as "preference" or "source-address". We can't expect the destination p=
refix to be unique.
>>=20
>> One thing that *might* be possible is to have the following key in stati=
c routes:
>>=20
>> key "destination-prefix id"
>>=20
>> It would be especially useful if optional keys are introduced in YANG 1.=
1 (see issue Y09). The "id" would then be used as an auxiliary distinguishe=
r for routes that have the same destination-prefix, otherwise it could have=
 the default value.
>>=20
>> Lada
>>=20
>>>=20
>>> Jeffrey
>>>=20
>>>> -----Original Message-----
>>>> From: Ladislav Lhotka [mailto:lhotka@nic.cz]
>>>> Sent: Thursday, June 26, 2014 10:58 AM
>>>> To: Jeffrey (Zhaohui) Zhang
>>>> Cc: Dean Bogdanovic; netmod@ietf.org
>>>> Subject: Re: static routes in draft-ietf-netmod-routing-cfg-15
>>>>=20
>>>> Jeffrey, Dean,
>>>>=20
>>>> we should move this long discussion towards some resolution. It=20
>>>> might be helpful if you propose concrete changes to the current module=
(s).
>>>>=20
>>>> Thanks, Lada
>>>>=20
>>>> On 26 Jun 2014, at 16:46, Jeffrey (Zhaohui) Zhang=20
>>>> 
>>>> wrote:
>>>>=20
>>>>> Lada,
>>>>>=20
>>>>>> It makes little sense to introduce "preference" just for
>>>> discriminating
>>>>>> among configured static routes with the same destination prefix.
>>>> Backup
>>>>>> routes or multi-path routing can be configured using "next-hop-list".
>>>>>=20
>>>>> If those all have the same
>>>>> "preference"/"weight"/"priority"/"whatever",
>>>> sure use next-hop-list. But if you want to prefer nh1 over nh2,=20
>>>> then you can either use different static route entries with=20
>>>> "index", or as you said still use next-hop-list but give different=20
>>>> priorities to each nexthop in the list.
>>>>>=20
>>>>> Some implementations may prefer one way or another. If I take a=20
>>>>> step
>>>> back and agree to simply use next-hop-list, then to me we can=20
>>>> simply use prefix itself to identify the routes. More below.
>>>>>=20
>>>>>>=20
>>>>>> However, this doesn't mean that each destination prefix must=20
>>>>>> always
>>>> be
>>>>>> unique in the list of static routes. Future modules may introduce=20
>>>>>> new static route attributes, e.g. for policy routing it could be=20
>>>>>> "tos",
>>>> and
>>>>>> then it would make a very good sense to configure multiple static
>>>> routes
>>>>>> with the same destination prefix but different ToS values.
>>>>>=20
>>>>> A better way would be to augment it so TOS becomes part of the prefix.
>>>>>=20
>>>>> Jeffrey
>>>>>=20
>>>>>>=20
>>>>>> While static routes can be augmented with a new parameter such as
>>>> "tos",
>>>>>> such a parameter cannot be added to the list key.
>>>>>=20
>>>>>> -----Original Message-----
>>>>>> From: Ladislav Lhotka [mailto:lhotka@nic.cz]
>>>>>> Sent: Thursday, June 26, 2014 10:23 AM
>>>>>> To: Jeffrey (Zhaohui) Zhang
>>>>>> Cc: Dean Bogdanovic; netmod@ietf.org
>>>>>> Subject: Re: static routes in draft-ietf-netmod-routing-cfg-15
>>>>>>=20
>>>>>>=20
>>>>>> On 26 Jun 2014, at 15:50, Jeffrey (Zhaohui) Zhang=20
>>>>>> 
>>>>>> wrote:
>>>>>>=20
>>>>>>> Lada,
>>>>>>>=20
>>>>>>>> -----Original Message-----
>>>>>>>> From: Ladislav Lhotka [mailto:lhotka@nic.cz]
>>>>>>>> Sent: Thursday, June 26, 2014 5:52 AM
>>>>>>>> To: Jeffrey (Zhaohui) Zhang; Dean Bogdanovic
>>>>>>>> Cc: netmod@ietf.org
>>>>>>>> Subject: RE: static routes in draft-ietf-netmod-routing-cfg-15
>>>>>>>>=20
>>>>>>>> "Jeffrey (Zhaohui) Zhang"  writes:
>>>>>>>>=20
>>>>>>>>> Lada,
>>>>>>>>>=20
>>>>>>>>>> -----Original Message-----
>>>>>>>>>> From: Ladislav Lhotka [mailto:lhotka@nic.cz]
>>>>>>>>>> Sent: Wednesday, June 25, 2014 12:48 PM
>>>>>>>>>> To: Dean Bogdanovic
>>>>>>>>>> Cc: netmod@ietf.org; Jeffrey (Zhaohui) Zhang
>>>>>>>>>> Subject: Re: static routes in=20
>>>>>>>>>> draft-ietf-netmod-routing-cfg-15
>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>> On 25 Jun 2014, at 15:51, Dean Bogdanovic 
>>>> wrote:
>>>>>>>>>>=20
>>>>>>>>>>> Hi,
>>>>>>>>>>>=20
>>>>>>>>>>> While reading routing-cfg, looking at the static route model=20
>>>>>>>>>>> augment "/rt:routing/rt:routing-instance/rt:routing-protocols/"
>>>>>>>>>>>     + "rt:routing-protocol/rt:static-routes" {  ...
>>>>>>>>>>> container ipv4 {
>>>>>>>>>>>   description
>>>>>>>>>>>     "Configuration of a 'static' pseudo-protocol instance
>>>>>>>>>>>      consists of a list of routes.";
>>>>>>>>>>>   list route {
>>>>>>>>>>>     key "id";
>>>>>>>>>>>     ordered-by "user";
>>>>>>>>>>>     description
>>>>>>>>>>>       "A user-ordered list of static routes.";
>>>>>>>>>>>     leaf id {
>>>>>>>>>>>       type uint32 {
>>>>>>>>>>>         range "1..max";
>>>>>>>>>>>       }
>>>>>>>>>>>       description
>>>>>>>>>>>         "Unique numeric identifier of the route.
>>>>>>>>>>>=20
>>>>>>>>>>>          This value is unrelated to system-assigned 'id'
>>>>>>>>>>>          parameters of routes in RIBs.";
>>>>>>>>>>>     }
>>>>>>>>>>>=20
>>>>>>>>>>> got confused that each static route is identified by an "id".
>>>>>>>>>> Originally thought it could be metric, but after reading
>>>>>> description,
>>>>>>>>>> wasn't sure.
>>>>>>>>>>>=20
>>>>>>>>>>> Lada explained that the id is used in case same prefixes are
>>>>>>>>>> configured, but have different metric. So why not use prefix=20
>>>>>>>>>> and preference as unique identifier? One could even argue=20
>>>>>>>>>> that the
>>>> base
>>>>>>>> spec
>>>>>>>>>> only needs to use prefix as the key, and if an implementation
>>>>>>>> supports
>>>>>>>>>> multiple static routes for the same prefix they can extend as=20
>>>>>>>>>> an optional feature.
>>>>>>>>>>=20
>>>>>>>>>> YANG needs to specify key(s) for configuration lists, so we=20
>>>>>>>>>> have
>>>> to
>>>>>>>> do
>>>>>>>>>> it for static routes in ietf-routing, and this key cannot be
>>>>>> changed
>>>>>>>> or
>>>>>>>>>> augmented from other modules.
>>>>>>>>>>=20
>>>>>>>>>> Under these conditions, I am afraid we don't have any natural
>>>> key(s)
>>>>>>>>>> that would be universally acceptable. All systems use some
>>>>>> additional
>>>>>>>>>> parameters, be they called preference, metric or=20
>>>>>>>>>> administrative
>>>>>>>> distance,
>>>>>>>>>> but the problem is that, depending on the system, they may be
>>>>>>>> specified
>>>>>>>>>> (i) per route, (ii) per destination prefix, or (iii) per=20
>>>>>>>>>> protocol instance.
>>>>>>>>>=20
>>>>>>>>> What's the difference between "route" ((i) above) and=20
>>>>>>>>> "destination
>>>>>>>> prefix" ((ii) above)?
>>>>>>>>=20
>>>>>>>> Quagga can set distance either for a protocol
>>>>>>>>=20
>>>>>>>> distance 
>>>>>>>>=20
>>>>>>>> or selectively
>>>>>>>>=20
>>>>>>>> distance  A.B.C.D/M
>>>>>>>=20
>>>>>>> I was asking the difference between "route" and "destination prefix=
".
>>>>>> I guess a "route" means a particular entry (e.g. those with=20
>>>>>> different nexthops or in a broader context - from different
>>>>>> protcools) for a prefix. Is that correct?
>>>>>>=20
>>>>>> Destination prefix is one of the attributes of a route.
>>>>>>=20
>>>>>>>=20
>>>>>>>>=20
>>>>>>>>> (iii) is irrelevant here - we're talking about "static-route",
>>>> which
>>>>>>>> is a "protocol instance" and does not need to be in the key for=20
>>>>>>>> the static route entries.
>>>>>>>>=20
>>>>>>>> It is relevant. If we introduce preference as a route attribute=20
>>>>>>>> in
>>>>>> ietf-
>>>>>>>> routing (as it is e.g. in JUNOS or BIRD), then implementations=20
>>>>>>>> that don't have it (use only per-protocol distance) would be out o=
f luck.
>>>>>>>=20
>>>>>>> We are talking about specifying static routes. If an=20
>>>>>>> implementation
>>>>>> does not support multiple static route entries for the same=20
>>>>>> prefix
>>>> (e.g.
>>>>>> using different nexthops), then the "preference" or whatever we=20
>>>>>> call
>>>> it
>>>>>> would be a fixed value say 0. If the implementation does support=20
>>>>>> that, then it must provide a preference for each entry.
>>>>>>=20
>>>>>> It makes little sense to introduce "preference" just for
>>>> discriminating
>>>>>> among configured static routes with the same destination prefix.
>>>> Backup
>>>>>> routes or multi-path routing can be configured using "next-hop-list".
>>>>>>=20
>>>>>> However, this doesn't mean that each destination prefix must=20
>>>>>> always
>>>> be
>>>>>> unique in the list of static routes. Future modules may introduce=20
>>>>>> new static route attributes, e.g. for policy routing it could be=20
>>>>>> "tos",
>>>> and
>>>>>> then it would make a very good sense to configure multiple static
>>>> routes
>>>>>> with the same destination prefix but different ToS values.
>>>>>>=20
>>>>>> While static routes can be augmented with a new parameter such as
>>>> "tos",
>>>>>> such a parameter cannot be added to the list key.
>>>>>>=20
>>>>>> Lada
>>>>>>=20
>>>>>>>=20
>>>>>>> Jeffrey
>>>>>>>=20
>>>>>>>>=20
>>>>>>>> Lada
>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>> For Linux, the key would be the triple (dest. prefix, TOS,
>>>>>>>> preference).
>>>>>>>>>=20
>>>>>>>>> To me, routes with different TOS behavior could go into=20
>>>>>>>>> different
>>>>>> RIBs;
>>>>>>>> or, just put the TOS in the prefix part. Then you're left with
>>>>>> (prefix,
>>>>>>>> preference) - exactly what we were proposing as the key.
>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>> So, while I don't like the "id" key at all, I don't see what=20
>>>>>>>>>> else
>>>>>>>> could
>>>>>>>>>> be done. On the other hand, static routes are usually not=20
>>>>>>>>>> defined
>>>>>> in
>>>>>>>>>> excessive quantities, so an extra parameter probably doesn't
>>>> matter.
>>>>>>>>>>=20
>>>>>>>>>> Another important thing to note is that the "id" parameter of
>>>>>> routes
>>>>>>>> in
>>>>>>>>>> RIBs (state data) is unrelated to the "id" of static routes.=20
>>>>>>>>>> It
>>>> was
>>>>>>>>>> added recently as a part of "harmonization" with I2RS RIB=20
>>>>>>>>>> info
>>>>>> model
>>>>>>>>>> (state lists don't have to have keys).
>>>>>>>>>=20
>>>>>>>>> That's yet another separate discussion that is going on=20
>>>>>>>>> offline
>>>> now.
>>>>>>>> We'll loop back here when it's ready.
>>>>>>>>>=20
>>>>>>>>> Jeffrey
>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>> Lada
>>>>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>>>>>> There was an email exchange on this topic offline and we are
>>>>>>>> curious
>>>>>>>>>> what does the WG think about this "id"?
>>>>>>>>>>>=20
>>>>>>>>>>> Dean
>>>>>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>> --
>>>>>>>>>> Ladislav Lhotka, CZ.NIC Labs
>>>>>>>>>> PGP Key ID: E74E8C0C
>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>=20
>>>>>>>> --
>>>>>>>> Ladislav Lhotka, CZ.NIC Labs
>>>>>>>> PGP Key ID: E74E8C0C
>>>>>>=20
>>>>>> --
>>>>>> Ladislav Lhotka, CZ.NIC Labs
>>>>>> PGP Key ID: E74E8C0C
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>=20
>>>>=20
>>>> --
>>>> Ladislav Lhotka, CZ.NIC Labs
>>>> PGP Key ID: E74E8C0C
>>>>=20
>>>>=20
>>>>=20
>>>=20
>>=20
>> --
>> Ladislav Lhotka, CZ.NIC Labs
>> PGP Key ID: E74E8C0C
>>=20
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>>=20
>> _____________________________________________________________________
>> _ ___________________________________________________
>>=20
>> Ce message et ses pieces jointes peuvent contenir des informations=20
>> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20
>> exploites ou copies sans autorisation. Si vous avez recu ce message=20
>> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que=
 les pieces jointes. Les messages electroniques etant susceptibles d'altera=
tion, Orange decline toute responsabilite si ce message a ete altere, defor=
me ou falsifie. Merci.
>>=20
>> This message and its attachments may contain confidential or=20
>> privileged information that may be protected by law; they should not be =
distributed, used or copied without authorisation.
>> If you have received this email in error, please notify the sender and d=
elete this message and its attachments.
>> As emails may be altered, Orange is not liable for messages that have be=
en modified, changed or falsified.
>> Thank you.
>>=20
>=20
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>=20
>=20
>=20
>=20
>=20
> ______________________________________________________________________
> ___________________________________________________
>=20
> Ce message et ses pieces jointes peuvent contenir des informations=20
> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20
> exploites ou copies sans autorisation. Si vous avez recu ce message=20
> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que =
les pieces jointes. Les messages electroniques etant susceptibles d'alterat=
ion, Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.
>=20
> This message and its attachments may contain confidential or=20
> privileged information that may be protected by law; they should not be d=
istributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and de=
lete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have bee=
n modified, changed or falsified.
> Thank you.
>=20

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





___________________________________________________________________________=
______________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.


From nobody Fri Jun 27 08:13:53 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84B6B1B3241 for ; Fri, 27 Jun 2014 08:13:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.602
X-Spam-Level: 
X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GnY0waRodtZK for ; Fri, 27 Jun 2014 08:13:35 -0700 (PDT)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0207.outbound.protection.outlook.com [207.46.163.207]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6AE631B323E for ; Fri, 27 Jun 2014 08:13:29 -0700 (PDT)
Received: from BN1PR05MB424.namprd05.prod.outlook.com (10.141.58.148) by BN1PR05MB074.namprd05.prod.outlook.com (10.255.199.12) with Microsoft SMTP Server (TLS) id 15.0.954.9; Fri, 27 Jun 2014 15:13:19 +0000
Received: from BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.172]) by BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.172]) with mapi id 15.00.0954.000; Fri, 27 Jun 2014 15:13:19 +0000
From: Dean Bogdanovic 
To: "stephane.litkowski@orange.com" 
Thread-Topic: [netmod] static routes in draft-ietf-netmod-routing-cfg-15
Thread-Index: AQHPkHyQ0orIXWpDoUyLtj2fzemmwZuCCWmAgAAjBWCAAPsgAIAAQPUAgAAKrICAAAN8AIAABmOAgAAApyCAAT/BAIAAHS2AgAARL4CAAAjAAIAADZOAgAANvQCAAAPKgA==
Date: Fri, 27 Jun 2014 15:13:18 +0000
Message-ID: <84CF3F71-9CAD-4C96-977F-80945C4DE29E@juniper.net>
References: <6CCE7829-D078-41B0-8578-300563AD7CB8@juniper.net> <4F17ABF3-F1E4-4EA3-9F8F-02B02162554D@nic.cz>   <236fa2a7df884545b6f8c4a1dd3e8d9a@BY2PR05MB079.namprd05.prod.outlook.com>   <109A8A1D-29C4-4F4C-80FF-DBCD5FB6999D@nic.cz> <8e9299cd951a42b7a8be67e55e87cccb@BY2PR05MB079.namprd05.prod.outlook.com>  <16002_1403869749_53AD5A35_16002_507_1_9E32478DFA9976438E7A22F69B08FF92034FBC@OPEXCLILM34.corporate.adroot.infra.ftgroup> <999D12A8-C4D9-4D68-9D16-BB01728A6579@nic.cz> <22741_1403875319_53AD6FF7_22741_879_4_9E32478DFA9976438E7A22F69B08FF920370DE@OPEXCLILM34.corporate.adroot.infra.ftgroup> <85661580-5EE0-4D2E-BFF1-063506811858@nic.cz> <15159_1403881185_53AD86E1_15159_4507_1_9E32478DFA9976438E7A22F69B08FF92039219@OPEXCLILM34.corporate.adroot.infra.ftgroup>
In-Reply-To: <15159_1403881185_53AD86E1_15159_4507_1_9E32478DFA9976438E7A22F69B08FF92039219@OPEXCLILM34.corporate.adroot.infra.ftgroup>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-mailer: Apple Mail (2.1510)
x-originating-ip: [66.129.241.10]
x-microsoft-antispam: BL:0; ACTION:Default; RISK:Low; SCL:0; SPMLVL:NotSpam; PCL:0; RULEID:
x-forefront-prvs: 0255DF69B9
x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(51704005)(377454003)(24454002)(199002)(164054003)(13464003)(189002)(105586002)(50986999)(80022001)(92726001)(88136002)(76176999)(95666004)(81342001)(99286002)(106356001)(104166001)(74662001)(50226001)(106116001)(101416001)(107046002)(74502001)(31966008)(2351001)(21056001)(4396001)(2656002)(77156001)(87936001)(20776003)(64706001)(79102001)(36756003)(89996001)(81542001)(83072002)(87286001)(85852003)(15975445006)(66066001)(561944003)(57306001)(77982001)(19580405001)(76482001)(46102001)(83322001)(93916002)(575784001)(86362001)(33656002)(19580395003)(93886003)(99396002)(83716003)(85306003)(82746002)(92566001)(62966002)(77096002)(104396001)(579004); DIR:OUT; SFP:; SCL:1; SRVR:BN1PR05MB074; H:BN1PR05MB424.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:3; LANG:en; 
Content-Type: text/plain; charset="us-ascii"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/UgqM_X-0YW9lY-7WdU3b08mHi5Q
Cc: "Jeffrey \(Zhaohui\) Zhang" , "netmod@ietf.org" 
Subject: Re: [netmod] static routes in draft-ietf-netmod-routing-cfg-15
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 27 Jun 2014 15:13:42 -0000

On Jun 27, 2014, at 10:59 AM, stephane.litkowski@orange.com wrote:

>> If I understand you correctly, you'd prefer to have a RIB as a list keye=
d with destination prefixes and each entry containing a list of routes for =
that prefix with the active route being tagged.
>=20
> [SLI] The major point is to be able to identify the easily the "route-typ=
e" : best, non best.

no, that is not a good idea. You can have protection and load balance prefe=
rence. If you just use route-type best, then how will you do load balancing=
 between different routes? You should be able to add weight to each route a=
nd based on that weight do load balancing between them.

>=20
>=20
>=20
> -----Original Message-----
> From: Ladislav Lhotka [mailto:lhotka@nic.cz]=20
> Sent: Friday, June 27, 2014 16:11
> To: LITKOWSKI Stephane SCE/IBNF
> Cc: Jeffrey (Zhaohui) Zhang; netmod@ietf.org
> Subject: Re: [netmod] static routes in draft-ietf-netmod-routing-cfg-15
>=20
>=20
> On 27 Jun 2014, at 15:21,   wrote:
>=20
>>> A system supporting the "multipath-routes" feature can use "next-hop-li=
st" in its routes.
>>=20
>>> On the other hand, I assume that two routes with the same destination p=
refix obtained from different protocols will remain >separate because they =
may be passed to a route filter and treated differently by it.
>>=20
>> [SLI] Regarding route filters, I have one concern regarding the approach=
 for multiple routes for the same prefix in route list.
>>=20
>>=20
>> Consider that you have a RIP learned route 10/8 at RtrX RtrX has a=20
>> "default RIP route-filter" to export RIP routes from connected RIB to RI=
P neighbors.
>>=20
>> So it's expected that 10/8 learned RIB route is advertised to neighbors.
>>=20
>> Now, I had a static route to 10/8 on RtrX with highest preference than R=
IP protocol.
>>=20
>> The 10/8 is expected to not be exported anymore because only best routes=
 can be exported from RIB and best route is not a RIP one.
>>=20
>> That's why I found the model confusing to have different route entries f=
or a specific destination. The notion of best path per destination is quite=
 critical to be present in the model and we need to be able to retrieve all=
 paths for a specific destination prefix.
>> The other way to do it, would be to add "active"/"best" leaf in the rout=
e list.
>=20
> If I understand you correctly, you'd prefer to have a RIB as a list keyed=
 with destination prefixes and each entry containing a list of routes for t=
hat prefix with the active route being tagged.
>=20
> Lada
>=20
>>=20
>>=20
>> Best Regards,
>>=20
>> Stephane
>>=20
>> -----Original Message-----
>> From: Ladislav Lhotka [mailto:lhotka@nic.cz]
>> Sent: Friday, June 27, 2014 14:51
>> To: LITKOWSKI Stephane SCE/IBNF
>> Cc: Jeffrey (Zhaohui) Zhang; netmod@ietf.org
>> Subject: Re: [netmod] static routes in=20
>> draft-ietf-netmod-routing-cfg-15
>>=20
>>=20
>> On 27 Jun 2014, at 13:49,   wrote:
>>=20
>>> Hi,
>>>=20
>>> I'm wondering if the current model for RIB is the right one. Maybe ther=
e was already discussions on this in the past, so sorry to come back to it =
, if it's the case ...
>>>=20
>>> Currently the model is to have list of routes. Each route containing ne=
xthop and prefix information.
>>> So if I have the following routes :
>>> 10.0.0.0/8 ISIS preference 20, metric 100
>>> 10.0.0.0/8 OSPF preference 15, metric 500
>>>=20
>>> I would have two route entries in routes with a single nexthop in it fo=
r each.
>>>=20
>>> If I have :
>>> 10.0.0.0/8 Static nexthop 1
>>> 10.0.0.0/8 Static nexthop 2
>>>=20
>>> I would have a single route entry with a nexthop-list.
>>=20
>> A system supporting the "multipath-routes" feature can use "next-hop-lis=
t" in its routes.
>>=20
>> On the other hand, I assume that two routes with the same destination pr=
efix obtained from different protocols will remain separate because they ma=
y be passed to a route filter and treated differently by it.
>>=20
>>=20
>>>=20
>>> This is not really displaying how RIBs are working today. Moreover it t=
ends to mix how FIB works and how RIB works,  generally we have for RIB :
>>=20
>> FIB (=3D table containing active routes) is not part of this data model =
because we also need to support systems such as Linux that uses route cache=
.
>>=20
>>=20
>>> A single prefix entry followed by a list of paths : some are primary, s=
ome are protecting (LFA or MRT ...), some are only hidden path (less prefer=
red protocol preference). When multipath is enabled, all primaries are used=
 for Loadbalancing.
>>>=20
>>> Why not using this model , so with the example, I would have a single=20
>>> route entry with next-hop-list as next-hop-options. Nexthop-list=20
>>> would have one primary nexthop, and one backup nexthop. Moreover I'm=20
>>> not
>>=20
>> Because nobody proposed it so far.
>>=20
>>> sure about what "backup" means, especially if you have a FRR nexthop, w=
ould it be "backup" ? I think a new enum may be required for next-hop-class=
ifiers to differentiate "hidden routes" (less preferred) from protecting ro=
utes (LFA ...), both are sort of backup routes ...
>>>=20
>>> Using this system the key of routes can be the destination prefix.
>>> Next-hop-content need then more to be a path-list.
>>> To index path-list, all attributes may require to be taken into account=
.
>>=20
>> For lists in state data keys are optional.
>>=20
>> Lada
>>=20
>>>=20
>>> Thoughts ?
>>>=20
>>>=20
>>>=20
>>> -----Original Message-----
>>> From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Ladislav=20
>>> Lhotka
>>> Sent: Friday, June 27, 2014 12:05
>>> To: Jeffrey (Zhaohui) Zhang
>>> Cc: netmod@ietf.org
>>> Subject: Re: [netmod] static routes in
>>> draft-ietf-netmod-routing-cfg-15
>>>=20
>>> "Jeffrey (Zhaohui) Zhang"  writes:
>>>=20
>>>> Lada,
>>>>=20
>>>> My proposal is to remove ID and just use prefix.
>>>> For future extensions like TOS, just augment to include TOS in the pre=
fix.
>>>=20
>>> No way. ToS was just an example, other modules may add other parameters=
 such as "preference" or "source-address". We can't expect the destination =
prefix to be unique.
>>>=20
>>> One thing that *might* be possible is to have the following key in stat=
ic routes:
>>>=20
>>> key "destination-prefix id"
>>>=20
>>> It would be especially useful if optional keys are introduced in YANG 1=
.1 (see issue Y09). The "id" would then be used as an auxiliary distinguish=
er for routes that have the same destination-prefix, otherwise it could hav=
e the default value.
>>>=20
>>> Lada
>>>=20
>>>>=20
>>>> Jeffrey
>>>>=20
>>>>> -----Original Message-----
>>>>> From: Ladislav Lhotka [mailto:lhotka@nic.cz]
>>>>> Sent: Thursday, June 26, 2014 10:58 AM
>>>>> To: Jeffrey (Zhaohui) Zhang
>>>>> Cc: Dean Bogdanovic; netmod@ietf.org
>>>>> Subject: Re: static routes in draft-ietf-netmod-routing-cfg-15
>>>>>=20
>>>>> Jeffrey, Dean,
>>>>>=20
>>>>> we should move this long discussion towards some resolution. It=20
>>>>> might be helpful if you propose concrete changes to the current modul=
e(s).
>>>>>=20
>>>>> Thanks, Lada
>>>>>=20
>>>>> On 26 Jun 2014, at 16:46, Jeffrey (Zhaohui) Zhang=20
>>>>> 
>>>>> wrote:
>>>>>=20
>>>>>> Lada,
>>>>>>=20
>>>>>>> It makes little sense to introduce "preference" just for
>>>>> discriminating
>>>>>>> among configured static routes with the same destination prefix.
>>>>> Backup
>>>>>>> routes or multi-path routing can be configured using "next-hop-list=
".
>>>>>>=20
>>>>>> If those all have the same
>>>>>> "preference"/"weight"/"priority"/"whatever",
>>>>> sure use next-hop-list. But if you want to prefer nh1 over nh2,=20
>>>>> then you can either use different static route entries with=20
>>>>> "index", or as you said still use next-hop-list but give different=20
>>>>> priorities to each nexthop in the list.
>>>>>>=20
>>>>>> Some implementations may prefer one way or another. If I take a=20
>>>>>> step
>>>>> back and agree to simply use next-hop-list, then to me we can=20
>>>>> simply use prefix itself to identify the routes. More below.
>>>>>>=20
>>>>>>>=20
>>>>>>> However, this doesn't mean that each destination prefix must=20
>>>>>>> always
>>>>> be
>>>>>>> unique in the list of static routes. Future modules may introduce=20
>>>>>>> new static route attributes, e.g. for policy routing it could be=20
>>>>>>> "tos",
>>>>> and
>>>>>>> then it would make a very good sense to configure multiple static
>>>>> routes
>>>>>>> with the same destination prefix but different ToS values.
>>>>>>=20
>>>>>> A better way would be to augment it so TOS becomes part of the prefi=
x.
>>>>>>=20
>>>>>> Jeffrey
>>>>>>=20
>>>>>>>=20
>>>>>>> While static routes can be augmented with a new parameter such as
>>>>> "tos",
>>>>>>> such a parameter cannot be added to the list key.
>>>>>>=20
>>>>>>> -----Original Message-----
>>>>>>> From: Ladislav Lhotka [mailto:lhotka@nic.cz]
>>>>>>> Sent: Thursday, June 26, 2014 10:23 AM
>>>>>>> To: Jeffrey (Zhaohui) Zhang
>>>>>>> Cc: Dean Bogdanovic; netmod@ietf.org
>>>>>>> Subject: Re: static routes in draft-ietf-netmod-routing-cfg-15
>>>>>>>=20
>>>>>>>=20
>>>>>>> On 26 Jun 2014, at 15:50, Jeffrey (Zhaohui) Zhang=20
>>>>>>> 
>>>>>>> wrote:
>>>>>>>=20
>>>>>>>> Lada,
>>>>>>>>=20
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: Ladislav Lhotka [mailto:lhotka@nic.cz]
>>>>>>>>> Sent: Thursday, June 26, 2014 5:52 AM
>>>>>>>>> To: Jeffrey (Zhaohui) Zhang; Dean Bogdanovic
>>>>>>>>> Cc: netmod@ietf.org
>>>>>>>>> Subject: RE: static routes in draft-ietf-netmod-routing-cfg-15
>>>>>>>>>=20
>>>>>>>>> "Jeffrey (Zhaohui) Zhang"  writes:
>>>>>>>>>=20
>>>>>>>>>> Lada,
>>>>>>>>>>=20
>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>> From: Ladislav Lhotka [mailto:lhotka@nic.cz]
>>>>>>>>>>> Sent: Wednesday, June 25, 2014 12:48 PM
>>>>>>>>>>> To: Dean Bogdanovic
>>>>>>>>>>> Cc: netmod@ietf.org; Jeffrey (Zhaohui) Zhang
>>>>>>>>>>> Subject: Re: static routes in=20
>>>>>>>>>>> draft-ietf-netmod-routing-cfg-15
>>>>>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>>>>>> On 25 Jun 2014, at 15:51, Dean Bogdanovic 
>>>>> wrote:
>>>>>>>>>>>=20
>>>>>>>>>>>> Hi,
>>>>>>>>>>>>=20
>>>>>>>>>>>> While reading routing-cfg, looking at the static route model=20
>>>>>>>>>>>> augment "/rt:routing/rt:routing-instance/rt:routing-protocols/=
"
>>>>>>>>>>>>    + "rt:routing-protocol/rt:static-routes" {  ...
>>>>>>>>>>>> container ipv4 {
>>>>>>>>>>>>  description
>>>>>>>>>>>>    "Configuration of a 'static' pseudo-protocol instance
>>>>>>>>>>>>     consists of a list of routes.";
>>>>>>>>>>>>  list route {
>>>>>>>>>>>>    key "id";
>>>>>>>>>>>>    ordered-by "user";
>>>>>>>>>>>>    description
>>>>>>>>>>>>      "A user-ordered list of static routes.";
>>>>>>>>>>>>    leaf id {
>>>>>>>>>>>>      type uint32 {
>>>>>>>>>>>>        range "1..max";
>>>>>>>>>>>>      }
>>>>>>>>>>>>      description
>>>>>>>>>>>>        "Unique numeric identifier of the route.
>>>>>>>>>>>>=20
>>>>>>>>>>>>         This value is unrelated to system-assigned 'id'
>>>>>>>>>>>>         parameters of routes in RIBs.";
>>>>>>>>>>>>    }
>>>>>>>>>>>>=20
>>>>>>>>>>>> got confused that each static route is identified by an "id".
>>>>>>>>>>> Originally thought it could be metric, but after reading
>>>>>>> description,
>>>>>>>>>>> wasn't sure.
>>>>>>>>>>>>=20
>>>>>>>>>>>> Lada explained that the id is used in case same prefixes are
>>>>>>>>>>> configured, but have different metric. So why not use prefix=20
>>>>>>>>>>> and preference as unique identifier? One could even argue=20
>>>>>>>>>>> that the
>>>>> base
>>>>>>>>> spec
>>>>>>>>>>> only needs to use prefix as the key, and if an implementation
>>>>>>>>> supports
>>>>>>>>>>> multiple static routes for the same prefix they can extend as=20
>>>>>>>>>>> an optional feature.
>>>>>>>>>>>=20
>>>>>>>>>>> YANG needs to specify key(s) for configuration lists, so we=20
>>>>>>>>>>> have
>>>>> to
>>>>>>>>> do
>>>>>>>>>>> it for static routes in ietf-routing, and this key cannot be
>>>>>>> changed
>>>>>>>>> or
>>>>>>>>>>> augmented from other modules.
>>>>>>>>>>>=20
>>>>>>>>>>> Under these conditions, I am afraid we don't have any natural
>>>>> key(s)
>>>>>>>>>>> that would be universally acceptable. All systems use some
>>>>>>> additional
>>>>>>>>>>> parameters, be they called preference, metric or=20
>>>>>>>>>>> administrative
>>>>>>>>> distance,
>>>>>>>>>>> but the problem is that, depending on the system, they may be
>>>>>>>>> specified
>>>>>>>>>>> (i) per route, (ii) per destination prefix, or (iii) per=20
>>>>>>>>>>> protocol instance.
>>>>>>>>>>=20
>>>>>>>>>> What's the difference between "route" ((i) above) and=20
>>>>>>>>>> "destination
>>>>>>>>> prefix" ((ii) above)?
>>>>>>>>>=20
>>>>>>>>> Quagga can set distance either for a protocol
>>>>>>>>>=20
>>>>>>>>> distance 
>>>>>>>>>=20
>>>>>>>>> or selectively
>>>>>>>>>=20
>>>>>>>>> distance  A.B.C.D/M
>>>>>>>>=20
>>>>>>>> I was asking the difference between "route" and "destination prefi=
x".
>>>>>>> I guess a "route" means a particular entry (e.g. those with=20
>>>>>>> different nexthops or in a broader context - from different
>>>>>>> protcools) for a prefix. Is that correct?
>>>>>>>=20
>>>>>>> Destination prefix is one of the attributes of a route.
>>>>>>>=20
>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>>> (iii) is irrelevant here - we're talking about "static-route",
>>>>> which
>>>>>>>>> is a "protocol instance" and does not need to be in the key for=20
>>>>>>>>> the static route entries.
>>>>>>>>>=20
>>>>>>>>> It is relevant. If we introduce preference as a route attribute=20
>>>>>>>>> in
>>>>>>> ietf-
>>>>>>>>> routing (as it is e.g. in JUNOS or BIRD), then implementations=20
>>>>>>>>> that don't have it (use only per-protocol distance) would be out =
of luck.
>>>>>>>>=20
>>>>>>>> We are talking about specifying static routes. If an=20
>>>>>>>> implementation
>>>>>>> does not support multiple static route entries for the same=20
>>>>>>> prefix
>>>>> (e.g.
>>>>>>> using different nexthops), then the "preference" or whatever we=20
>>>>>>> call
>>>>> it
>>>>>>> would be a fixed value say 0. If the implementation does support=20
>>>>>>> that, then it must provide a preference for each entry.
>>>>>>>=20
>>>>>>> It makes little sense to introduce "preference" just for
>>>>> discriminating
>>>>>>> among configured static routes with the same destination prefix.
>>>>> Backup
>>>>>>> routes or multi-path routing can be configured using "next-hop-list=
".
>>>>>>>=20
>>>>>>> However, this doesn't mean that each destination prefix must=20
>>>>>>> always
>>>>> be
>>>>>>> unique in the list of static routes. Future modules may introduce=20
>>>>>>> new static route attributes, e.g. for policy routing it could be=20
>>>>>>> "tos",
>>>>> and
>>>>>>> then it would make a very good sense to configure multiple static
>>>>> routes
>>>>>>> with the same destination prefix but different ToS values.
>>>>>>>=20
>>>>>>> While static routes can be augmented with a new parameter such as
>>>>> "tos",
>>>>>>> such a parameter cannot be added to the list key.
>>>>>>>=20
>>>>>>> Lada
>>>>>>>=20
>>>>>>>>=20
>>>>>>>> Jeffrey
>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>> Lada
>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>>>>>> For Linux, the key would be the triple (dest. prefix, TOS,
>>>>>>>>> preference).
>>>>>>>>>>=20
>>>>>>>>>> To me, routes with different TOS behavior could go into=20
>>>>>>>>>> different
>>>>>>> RIBs;
>>>>>>>>> or, just put the TOS in the prefix part. Then you're left with
>>>>>>> (prefix,
>>>>>>>>> preference) - exactly what we were proposing as the key.
>>>>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>>>>>> So, while I don't like the "id" key at all, I don't see what=20
>>>>>>>>>>> else
>>>>>>>>> could
>>>>>>>>>>> be done. On the other hand, static routes are usually not=20
>>>>>>>>>>> defined
>>>>>>> in
>>>>>>>>>>> excessive quantities, so an extra parameter probably doesn't
>>>>> matter.
>>>>>>>>>>>=20
>>>>>>>>>>> Another important thing to note is that the "id" parameter of
>>>>>>> routes
>>>>>>>>> in
>>>>>>>>>>> RIBs (state data) is unrelated to the "id" of static routes.=20
>>>>>>>>>>> It
>>>>> was
>>>>>>>>>>> added recently as a part of "harmonization" with I2RS RIB=20
>>>>>>>>>>> info
>>>>>>> model
>>>>>>>>>>> (state lists don't have to have keys).
>>>>>>>>>>=20
>>>>>>>>>> That's yet another separate discussion that is going on=20
>>>>>>>>>> offline
>>>>> now.
>>>>>>>>> We'll loop back here when it's ready.
>>>>>>>>>>=20
>>>>>>>>>> Jeffrey
>>>>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>>>>>> Lada
>>>>>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>>>>>>> There was an email exchange on this topic offline and we are
>>>>>>>>> curious
>>>>>>>>>>> what does the WG think about this "id"?
>>>>>>>>>>>>=20
>>>>>>>>>>>> Dean
>>>>>>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>>>>>> --
>>>>>>>>>>> Ladislav Lhotka, CZ.NIC Labs
>>>>>>>>>>> PGP Key ID: E74E8C0C
>>>>>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>> --
>>>>>>>>> Ladislav Lhotka, CZ.NIC Labs
>>>>>>>>> PGP Key ID: E74E8C0C
>>>>>>>=20
>>>>>>> --
>>>>>>> Ladislav Lhotka, CZ.NIC Labs
>>>>>>> PGP Key ID: E74E8C0C
>>>>>>>=20
>>>>>>>=20
>>>>>>>=20
>>>>>>=20
>>>>>=20
>>>>> --
>>>>> Ladislav Lhotka, CZ.NIC Labs
>>>>> PGP Key ID: E74E8C0C
>>>>>=20
>>>>>=20
>>>>>=20
>>>>=20
>>>=20
>>> --
>>> Ladislav Lhotka, CZ.NIC Labs
>>> PGP Key ID: E74E8C0C
>>>=20
>>> _______________________________________________
>>> netmod mailing list
>>> netmod@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netmod
>>>=20
>>> _____________________________________________________________________
>>> _ ___________________________________________________
>>>=20
>>> Ce message et ses pieces jointes peuvent contenir des informations=20
>>> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20
>>> exploites ou copies sans autorisation. Si vous avez recu ce message=20
>>> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi qu=
e les pieces jointes. Les messages electroniques etant susceptibles d'alter=
ation, Orange decline toute responsabilite si ce message a ete altere, defo=
rme ou falsifie. Merci.
>>>=20
>>> This message and its attachments may contain confidential or=20
>>> privileged information that may be protected by law; they should not be=
 distributed, used or copied without authorisation.
>>> If you have received this email in error, please notify the sender and =
delete this message and its attachments.
>>> As emails may be altered, Orange is not liable for messages that have b=
een modified, changed or falsified.
>>> Thank you.
>>>=20
>>=20
>> --
>> Ladislav Lhotka, CZ.NIC Labs
>> PGP Key ID: E74E8C0C
>>=20
>>=20
>>=20
>>=20
>>=20
>> ______________________________________________________________________
>> ___________________________________________________
>>=20
>> Ce message et ses pieces jointes peuvent contenir des informations=20
>> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20
>> exploites ou copies sans autorisation. Si vous avez recu ce message=20
>> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que=
 les pieces jointes. Les messages electroniques etant susceptibles d'altera=
tion, Orange decline toute responsabilite si ce message a ete altere, defor=
me ou falsifie. Merci.
>>=20
>> This message and its attachments may contain confidential or=20
>> privileged information that may be protected by law; they should not be =
distributed, used or copied without authorisation.
>> If you have received this email in error, please notify the sender and d=
elete this message and its attachments.
>> As emails may be altered, Orange is not liable for messages that have be=
en modified, changed or falsified.
>> Thank you.
>>=20
>=20
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>=20
>=20
>=20
>=20
>=20
> _________________________________________________________________________=
________________________________________________
>=20
> Ce message et ses pieces jointes peuvent contenir des informations confid=
entielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re=
cu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages =
electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme o=
u falsifie. Merci.
>=20
> This message and its attachments may contain confidential or privileged i=
nformation that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and de=
lete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have bee=
n modified, changed or falsified.
> Thank you.
>=20
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


From nobody Fri Jun 27 08:22:55 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAB5C1B2D2A for ; Fri, 27 Jun 2014 08:22:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.092
X-Spam-Level: 
X-Spam-Status: No, score=-1.092 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RP_MATCHES_RCVD=-0.651, T_DKIM_INVALID=0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sY8UhSavytYQ for ; Fri, 27 Jun 2014 08:22:46 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A3801A0658 for ; Fri, 27 Jun 2014 08:22:46 -0700 (PDT)
Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id D0F8713F9E7; Fri, 27 Jun 2014 17:22:43 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1403882564; bh=91duwF03QyrGIq7xkeZUuDe1Nfys1EVJHU33A2wH4KY=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=hQd1cPBZYwNwvWDQmd8kaFWDEoZ7szYK0UVbwF9QmMhy4S6C4fiufE8IIL7l4hSDD AGZGtE6UWqEjDYpyHIDv5N5K9GXi81fWlxpYCHkxdGk9uvr0u9DiGFznmuKf3HL390 /O01r6hEDxBbhiTjkjcGdYroiAu2UsgXPN7VIHw0=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
From: Ladislav Lhotka 
In-Reply-To: <84CF3F71-9CAD-4C96-977F-80945C4DE29E@juniper.net>
Date: Fri, 27 Jun 2014 17:22:44 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <6CCE7829-D078-41B0-8578-300563AD7CB8@juniper.net> <4F17ABF3-F1E4-4EA3-9F8F-02B02162554D@nic.cz>   <236fa2a7df884545b6f8c4a1dd3e8d9a@BY2PR05MB079.namprd05.prod.outlook.com>   <109A8A1D-29C4-4F4C-80FF-DBCD5FB6999D@nic.cz> <8e9299cd951a42b7a8be67e55e87cccb@BY2PR05MB079.namprd05.prod.outlook.com>  <16002_1403869749_53AD5A35_16002_507_1_9E32478DFA9976438E7A22F69B08FF92034FBC@OPEXCLILM34.corporate.adroot.infra.ftgroup> <999D12A8-C4D9-4D68-9D16-BB01728A6579@nic.cz> <22741_1403875319_53AD6FF7_22741_879_4_9E32478DFA9976438E7A22F69B08FF920370DE@OPEXCLILM34.corporate.adroot.infra.ftgroup> <85661580-5EE0-4D2E-BFF1-063506811858@nic.cz> <15159_1403881185_53AD86E1_15159_4507_1_9E32478DFA9976438E7A22F69B08FF92039219@OPEXCLILM34.corporate.adroot.i nfra.ftgroup> <84CF3F71-9CAD-4C96-977F-80945C4DE29E@juniper.net>
To: Dean Bogdanovic 
X-Mailer: Apple Mail (2.1878.2)
X-Virus-Scanned: clamav-milter 0.98.1 at mail
X-Virus-Status: Clean
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/dn6NnDtZJJ7YV3bD3G3NACm_-7k
Cc: "Jeffrey \(Zhaohui\) Zhang" , "netmod@ietf.org" 
Subject: Re: [netmod] static routes in draft-ietf-netmod-routing-cfg-15
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 27 Jun 2014 15:22:50 -0000

On 27 Jun 2014, at 17:13, Dean Bogdanovic  wrote:

>=20
> On Jun 27, 2014, at 10:59 AM, stephane.litkowski@orange.com wrote:
>=20
>>> If I understand you correctly, you'd prefer to have a RIB as a list =
keyed with destination prefixes and each entry containing a list of =
routes for that prefix with the active route being tagged.
>>=20
>> [SLI] The major point is to be able to identify the easily the =
"route-type" : best, non best.
>=20
> no, that is not a good idea. You can have protection and load balance =
preference. If you just use route-type best, then how will you do load =
balancing between different routes? You should be able to add weight to =
each route and based on that weight do load balancing between them.

This is I guess what the next-hop-list is intended for?

Lada

>=20
>>=20
>>=20
>>=20
>> -----Original Message-----
>> From: Ladislav Lhotka [mailto:lhotka@nic.cz]=20
>> Sent: Friday, June 27, 2014 16:11
>> To: LITKOWSKI Stephane SCE/IBNF
>> Cc: Jeffrey (Zhaohui) Zhang; netmod@ietf.org
>> Subject: Re: [netmod] static routes in =
draft-ietf-netmod-routing-cfg-15
>>=20
>>=20
>> On 27 Jun 2014, at 15:21,  =
 wrote:
>>=20
>>>> A system supporting the "multipath-routes" feature can use =
"next-hop-list" in its routes.
>>>=20
>>>> On the other hand, I assume that two routes with the same =
destination prefix obtained from different protocols will remain =
>separate because they may be passed to a route filter and treated =
differently by it.
>>>=20
>>> [SLI] Regarding route filters, I have one concern regarding the =
approach for multiple routes for the same prefix in route list.
>>>=20
>>>=20
>>> Consider that you have a RIP learned route 10/8 at RtrX RtrX has a=20=

>>> "default RIP route-filter" to export RIP routes from connected RIB =
to RIP neighbors.
>>>=20
>>> So it's expected that 10/8 learned RIB route is advertised to =
neighbors.
>>>=20
>>> Now, I had a static route to 10/8 on RtrX with highest preference =
than RIP protocol.
>>>=20
>>> The 10/8 is expected to not be exported anymore because only best =
routes can be exported from RIB and best route is not a RIP one.
>>>=20
>>> That's why I found the model confusing to have different route =
entries for a specific destination. The notion of best path per =
destination is quite critical to be present in the model and we need to =
be able to retrieve all paths for a specific destination prefix.
>>> The other way to do it, would be to add "active"/"best" leaf in the =
route list.
>>=20
>> If I understand you correctly, you'd prefer to have a RIB as a list =
keyed with destination prefixes and each entry containing a list of =
routes for that prefix with the active route being tagged.
>>=20
>> Lada
>>=20
>>>=20
>>>=20
>>> Best Regards,
>>>=20
>>> Stephane
>>>=20
>>> -----Original Message-----
>>> From: Ladislav Lhotka [mailto:lhotka@nic.cz]
>>> Sent: Friday, June 27, 2014 14:51
>>> To: LITKOWSKI Stephane SCE/IBNF
>>> Cc: Jeffrey (Zhaohui) Zhang; netmod@ietf.org
>>> Subject: Re: [netmod] static routes in=20
>>> draft-ietf-netmod-routing-cfg-15
>>>=20
>>>=20
>>> On 27 Jun 2014, at 13:49,  =
 wrote:
>>>=20
>>>> Hi,
>>>>=20
>>>> I'm wondering if the current model for RIB is the right one. Maybe =
there was already discussions on this in the past, so sorry to come back =
to it , if it's the case ...
>>>>=20
>>>> Currently the model is to have list of routes. Each route =
containing nexthop and prefix information.
>>>> So if I have the following routes :
>>>> 10.0.0.0/8 ISIS preference 20, metric 100
>>>> 10.0.0.0/8 OSPF preference 15, metric 500
>>>>=20
>>>> I would have two route entries in routes with a single nexthop in =
it for each.
>>>>=20
>>>> If I have :
>>>> 10.0.0.0/8 Static nexthop 1
>>>> 10.0.0.0/8 Static nexthop 2
>>>>=20
>>>> I would have a single route entry with a nexthop-list.
>>>=20
>>> A system supporting the "multipath-routes" feature can use =
"next-hop-list" in its routes.
>>>=20
>>> On the other hand, I assume that two routes with the same =
destination prefix obtained from different protocols will remain =
separate because they may be passed to a route filter and treated =
differently by it.
>>>=20
>>>=20
>>>>=20
>>>> This is not really displaying how RIBs are working today. Moreover =
it tends to mix how FIB works and how RIB works,  generally we have for =
RIB :
>>>=20
>>> FIB (=3D table containing active routes) is not part of this data =
model because we also need to support systems such as Linux that uses =
route cache.
>>>=20
>>>=20
>>>> A single prefix entry followed by a list of paths : some are =
primary, some are protecting (LFA or MRT ...), some are only hidden path =
(less preferred protocol preference). When multipath is enabled, all =
primaries are used for Loadbalancing.
>>>>=20
>>>> Why not using this model , so with the example, I would have a =
single=20
>>>> route entry with next-hop-list as next-hop-options. Nexthop-list=20
>>>> would have one primary nexthop, and one backup nexthop. Moreover =
I'm=20
>>>> not
>>>=20
>>> Because nobody proposed it so far.
>>>=20
>>>> sure about what "backup" means, especially if you have a FRR =
nexthop, would it be "backup" ? I think a new enum may be required for =
next-hop-classifiers to differentiate "hidden routes" (less preferred) =
from protecting routes (LFA ...), both are sort of backup routes ...
>>>>=20
>>>> Using this system the key of routes can be the destination prefix.
>>>> Next-hop-content need then more to be a path-list.
>>>> To index path-list, all attributes may require to be taken into =
account.
>>>=20
>>> For lists in state data keys are optional.
>>>=20
>>> Lada
>>>=20
>>>>=20
>>>> Thoughts ?
>>>>=20
>>>>=20
>>>>=20
>>>> -----Original Message-----
>>>> From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Ladislav=20=

>>>> Lhotka
>>>> Sent: Friday, June 27, 2014 12:05
>>>> To: Jeffrey (Zhaohui) Zhang
>>>> Cc: netmod@ietf.org
>>>> Subject: Re: [netmod] static routes in
>>>> draft-ietf-netmod-routing-cfg-15
>>>>=20
>>>> "Jeffrey (Zhaohui) Zhang"  writes:
>>>>=20
>>>>> Lada,
>>>>>=20
>>>>> My proposal is to remove ID and just use prefix.
>>>>> For future extensions like TOS, just augment to include TOS in the =
prefix.
>>>>=20
>>>> No way. ToS was just an example, other modules may add other =
parameters such as "preference" or "source-address". We can't expect the =
destination prefix to be unique.
>>>>=20
>>>> One thing that *might* be possible is to have the following key in =
static routes:
>>>>=20
>>>> key "destination-prefix id"
>>>>=20
>>>> It would be especially useful if optional keys are introduced in =
YANG 1.1 (see issue Y09). The "id" would then be used as an auxiliary =
distinguisher for routes that have the same destination-prefix, =
otherwise it could have the default value.
>>>>=20
>>>> Lada
>>>>=20
>>>>>=20
>>>>> Jeffrey
>>>>>=20
>>>>>> -----Original Message-----
>>>>>> From: Ladislav Lhotka [mailto:lhotka@nic.cz]
>>>>>> Sent: Thursday, June 26, 2014 10:58 AM
>>>>>> To: Jeffrey (Zhaohui) Zhang
>>>>>> Cc: Dean Bogdanovic; netmod@ietf.org
>>>>>> Subject: Re: static routes in draft-ietf-netmod-routing-cfg-15
>>>>>>=20
>>>>>> Jeffrey, Dean,
>>>>>>=20
>>>>>> we should move this long discussion towards some resolution. It=20=

>>>>>> might be helpful if you propose concrete changes to the current =
module(s).
>>>>>>=20
>>>>>> Thanks, Lada
>>>>>>=20
>>>>>> On 26 Jun 2014, at 16:46, Jeffrey (Zhaohui) Zhang=20
>>>>>> 
>>>>>> wrote:
>>>>>>=20
>>>>>>> Lada,
>>>>>>>=20
>>>>>>>> It makes little sense to introduce "preference" just for
>>>>>> discriminating
>>>>>>>> among configured static routes with the same destination =
prefix.
>>>>>> Backup
>>>>>>>> routes or multi-path routing can be configured using =
"next-hop-list".
>>>>>>>=20
>>>>>>> If those all have the same
>>>>>>> "preference"/"weight"/"priority"/"whatever",
>>>>>> sure use next-hop-list. But if you want to prefer nh1 over nh2,=20=

>>>>>> then you can either use different static route entries with=20
>>>>>> "index", or as you said still use next-hop-list but give =
different=20
>>>>>> priorities to each nexthop in the list.
>>>>>>>=20
>>>>>>> Some implementations may prefer one way or another. If I take a=20=

>>>>>>> step
>>>>>> back and agree to simply use next-hop-list, then to me we can=20
>>>>>> simply use prefix itself to identify the routes. More below.
>>>>>>>=20
>>>>>>>>=20
>>>>>>>> However, this doesn't mean that each destination prefix must=20
>>>>>>>> always
>>>>>> be
>>>>>>>> unique in the list of static routes. Future modules may =
introduce=20
>>>>>>>> new static route attributes, e.g. for policy routing it could =
be=20
>>>>>>>> "tos",
>>>>>> and
>>>>>>>> then it would make a very good sense to configure multiple =
static
>>>>>> routes
>>>>>>>> with the same destination prefix but different ToS values.
>>>>>>>=20
>>>>>>> A better way would be to augment it so TOS becomes part of the =
prefix.
>>>>>>>=20
>>>>>>> Jeffrey
>>>>>>>=20
>>>>>>>>=20
>>>>>>>> While static routes can be augmented with a new parameter such =
as
>>>>>> "tos",
>>>>>>>> such a parameter cannot be added to the list key.
>>>>>>>=20
>>>>>>>> -----Original Message-----
>>>>>>>> From: Ladislav Lhotka [mailto:lhotka@nic.cz]
>>>>>>>> Sent: Thursday, June 26, 2014 10:23 AM
>>>>>>>> To: Jeffrey (Zhaohui) Zhang
>>>>>>>> Cc: Dean Bogdanovic; netmod@ietf.org
>>>>>>>> Subject: Re: static routes in draft-ietf-netmod-routing-cfg-15
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>> On 26 Jun 2014, at 15:50, Jeffrey (Zhaohui) Zhang=20
>>>>>>>> 
>>>>>>>> wrote:
>>>>>>>>=20
>>>>>>>>> Lada,
>>>>>>>>>=20
>>>>>>>>>> -----Original Message-----
>>>>>>>>>> From: Ladislav Lhotka [mailto:lhotka@nic.cz]
>>>>>>>>>> Sent: Thursday, June 26, 2014 5:52 AM
>>>>>>>>>> To: Jeffrey (Zhaohui) Zhang; Dean Bogdanovic
>>>>>>>>>> Cc: netmod@ietf.org
>>>>>>>>>> Subject: RE: static routes in =
draft-ietf-netmod-routing-cfg-15
>>>>>>>>>>=20
>>>>>>>>>> "Jeffrey (Zhaohui) Zhang"  writes:
>>>>>>>>>>=20
>>>>>>>>>>> Lada,
>>>>>>>>>>>=20
>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>> From: Ladislav Lhotka [mailto:lhotka@nic.cz]
>>>>>>>>>>>> Sent: Wednesday, June 25, 2014 12:48 PM
>>>>>>>>>>>> To: Dean Bogdanovic
>>>>>>>>>>>> Cc: netmod@ietf.org; Jeffrey (Zhaohui) Zhang
>>>>>>>>>>>> Subject: Re: static routes in=20
>>>>>>>>>>>> draft-ietf-netmod-routing-cfg-15
>>>>>>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>>>>>>> On 25 Jun 2014, at 15:51, Dean Bogdanovic =

>>>>>> wrote:
>>>>>>>>>>>>=20
>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>=20
>>>>>>>>>>>>> While reading routing-cfg, looking at the static route =
model=20
>>>>>>>>>>>>> augment =
"/rt:routing/rt:routing-instance/rt:routing-protocols/"
>>>>>>>>>>>>>   + "rt:routing-protocol/rt:static-routes" {  ...
>>>>>>>>>>>>> container ipv4 {
>>>>>>>>>>>>> description
>>>>>>>>>>>>>   "Configuration of a 'static' pseudo-protocol instance
>>>>>>>>>>>>>    consists of a list of routes.";
>>>>>>>>>>>>> list route {
>>>>>>>>>>>>>   key "id";
>>>>>>>>>>>>>   ordered-by "user";
>>>>>>>>>>>>>   description
>>>>>>>>>>>>>     "A user-ordered list of static routes.";
>>>>>>>>>>>>>   leaf id {
>>>>>>>>>>>>>     type uint32 {
>>>>>>>>>>>>>       range "1..max";
>>>>>>>>>>>>>     }
>>>>>>>>>>>>>     description
>>>>>>>>>>>>>       "Unique numeric identifier of the route.
>>>>>>>>>>>>>=20
>>>>>>>>>>>>>        This value is unrelated to system-assigned 'id'
>>>>>>>>>>>>>        parameters of routes in RIBs.";
>>>>>>>>>>>>>   }
>>>>>>>>>>>>>=20
>>>>>>>>>>>>> got confused that each static route is identified by an =
"id".
>>>>>>>>>>>> Originally thought it could be metric, but after reading
>>>>>>>> description,
>>>>>>>>>>>> wasn't sure.
>>>>>>>>>>>>>=20
>>>>>>>>>>>>> Lada explained that the id is used in case same prefixes =
are
>>>>>>>>>>>> configured, but have different metric. So why not use =
prefix=20
>>>>>>>>>>>> and preference as unique identifier? One could even argue=20=

>>>>>>>>>>>> that the
>>>>>> base
>>>>>>>>>> spec
>>>>>>>>>>>> only needs to use prefix as the key, and if an =
implementation
>>>>>>>>>> supports
>>>>>>>>>>>> multiple static routes for the same prefix they can extend =
as=20
>>>>>>>>>>>> an optional feature.
>>>>>>>>>>>>=20
>>>>>>>>>>>> YANG needs to specify key(s) for configuration lists, so we=20=

>>>>>>>>>>>> have
>>>>>> to
>>>>>>>>>> do
>>>>>>>>>>>> it for static routes in ietf-routing, and this key cannot =
be
>>>>>>>> changed
>>>>>>>>>> or
>>>>>>>>>>>> augmented from other modules.
>>>>>>>>>>>>=20
>>>>>>>>>>>> Under these conditions, I am afraid we don't have any =
natural
>>>>>> key(s)
>>>>>>>>>>>> that would be universally acceptable. All systems use some
>>>>>>>> additional
>>>>>>>>>>>> parameters, be they called preference, metric or=20
>>>>>>>>>>>> administrative
>>>>>>>>>> distance,
>>>>>>>>>>>> but the problem is that, depending on the system, they may =
be
>>>>>>>>>> specified
>>>>>>>>>>>> (i) per route, (ii) per destination prefix, or (iii) per=20
>>>>>>>>>>>> protocol instance.
>>>>>>>>>>>=20
>>>>>>>>>>> What's the difference between "route" ((i) above) and=20
>>>>>>>>>>> "destination
>>>>>>>>>> prefix" ((ii) above)?
>>>>>>>>>>=20
>>>>>>>>>> Quagga can set distance either for a protocol
>>>>>>>>>>=20
>>>>>>>>>> distance 
>>>>>>>>>>=20
>>>>>>>>>> or selectively
>>>>>>>>>>=20
>>>>>>>>>> distance  A.B.C.D/M
>>>>>>>>>=20
>>>>>>>>> I was asking the difference between "route" and "destination =
prefix".
>>>>>>>> I guess a "route" means a particular entry (e.g. those with=20
>>>>>>>> different nexthops or in a broader context - from different
>>>>>>>> protcools) for a prefix. Is that correct?
>>>>>>>>=20
>>>>>>>> Destination prefix is one of the attributes of a route.
>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>>> (iii) is irrelevant here - we're talking about =
"static-route",
>>>>>> which
>>>>>>>>>> is a "protocol instance" and does not need to be in the key =
for=20
>>>>>>>>>> the static route entries.
>>>>>>>>>>=20
>>>>>>>>>> It is relevant. If we introduce preference as a route =
attribute=20
>>>>>>>>>> in
>>>>>>>> ietf-
>>>>>>>>>> routing (as it is e.g. in JUNOS or BIRD), then =
implementations=20
>>>>>>>>>> that don't have it (use only per-protocol distance) would be =
out of luck.
>>>>>>>>>=20
>>>>>>>>> We are talking about specifying static routes. If an=20
>>>>>>>>> implementation
>>>>>>>> does not support multiple static route entries for the same=20
>>>>>>>> prefix
>>>>>> (e.g.
>>>>>>>> using different nexthops), then the "preference" or whatever we=20=

>>>>>>>> call
>>>>>> it
>>>>>>>> would be a fixed value say 0. If the implementation does =
support=20
>>>>>>>> that, then it must provide a preference for each entry.
>>>>>>>>=20
>>>>>>>> It makes little sense to introduce "preference" just for
>>>>>> discriminating
>>>>>>>> among configured static routes with the same destination =
prefix.
>>>>>> Backup
>>>>>>>> routes or multi-path routing can be configured using =
"next-hop-list".
>>>>>>>>=20
>>>>>>>> However, this doesn't mean that each destination prefix must=20
>>>>>>>> always
>>>>>> be
>>>>>>>> unique in the list of static routes. Future modules may =
introduce=20
>>>>>>>> new static route attributes, e.g. for policy routing it could =
be=20
>>>>>>>> "tos",
>>>>>> and
>>>>>>>> then it would make a very good sense to configure multiple =
static
>>>>>> routes
>>>>>>>> with the same destination prefix but different ToS values.
>>>>>>>>=20
>>>>>>>> While static routes can be augmented with a new parameter such =
as
>>>>>> "tos",
>>>>>>>> such a parameter cannot be added to the list key.
>>>>>>>>=20
>>>>>>>> Lada
>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>> Jeffrey
>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>> Lada
>>>>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>>>>>>> For Linux, the key would be the triple (dest. prefix, TOS,
>>>>>>>>>> preference).
>>>>>>>>>>>=20
>>>>>>>>>>> To me, routes with different TOS behavior could go into=20
>>>>>>>>>>> different
>>>>>>>> RIBs;
>>>>>>>>>> or, just put the TOS in the prefix part. Then you're left =
with
>>>>>>>> (prefix,
>>>>>>>>>> preference) - exactly what we were proposing as the key.
>>>>>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>>>>>>> So, while I don't like the "id" key at all, I don't see =
what=20
>>>>>>>>>>>> else
>>>>>>>>>> could
>>>>>>>>>>>> be done. On the other hand, static routes are usually not=20=

>>>>>>>>>>>> defined
>>>>>>>> in
>>>>>>>>>>>> excessive quantities, so an extra parameter probably =
doesn't
>>>>>> matter.
>>>>>>>>>>>>=20
>>>>>>>>>>>> Another important thing to note is that the "id" parameter =
of
>>>>>>>> routes
>>>>>>>>>> in
>>>>>>>>>>>> RIBs (state data) is unrelated to the "id" of static =
routes.=20
>>>>>>>>>>>> It
>>>>>> was
>>>>>>>>>>>> added recently as a part of "harmonization" with I2RS RIB=20=

>>>>>>>>>>>> info
>>>>>>>> model
>>>>>>>>>>>> (state lists don't have to have keys).
>>>>>>>>>>>=20
>>>>>>>>>>> That's yet another separate discussion that is going on=20
>>>>>>>>>>> offline
>>>>>> now.
>>>>>>>>>> We'll loop back here when it's ready.
>>>>>>>>>>>=20
>>>>>>>>>>> Jeffrey
>>>>>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>>>>>>> Lada
>>>>>>>>>>>>=20
>>>>>>>>>>>>>=20
>>>>>>>>>>>>> There was an email exchange on this topic offline and we =
are
>>>>>>>>>> curious
>>>>>>>>>>>> what does the WG think about this "id"?
>>>>>>>>>>>>>=20
>>>>>>>>>>>>> Dean
>>>>>>>>>>>>>=20
>>>>>>>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>>>>>>> --
>>>>>>>>>>>> Ladislav Lhotka, CZ.NIC Labs
>>>>>>>>>>>> PGP Key ID: E74E8C0C
>>>>>>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>> --
>>>>>>>>>> Ladislav Lhotka, CZ.NIC Labs
>>>>>>>>>> PGP Key ID: E74E8C0C
>>>>>>>>=20
>>>>>>>> --
>>>>>>>> Ladislav Lhotka, CZ.NIC Labs
>>>>>>>> PGP Key ID: E74E8C0C
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>=20
>>>>>>=20
>>>>>> --
>>>>>> Ladislav Lhotka, CZ.NIC Labs
>>>>>> PGP Key ID: E74E8C0C
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>=20
>>>>=20
>>>> --
>>>> Ladislav Lhotka, CZ.NIC Labs
>>>> PGP Key ID: E74E8C0C
>>>>=20
>>>> _______________________________________________
>>>> netmod mailing list
>>>> netmod@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/netmod
>>>>=20
>>>> =
_____________________________________________________________________
>>>> _ ___________________________________________________
>>>>=20
>>>> Ce message et ses pieces jointes peuvent contenir des informations=20=

>>>> confidentielles ou privilegiees et ne doivent donc pas etre =
diffuses,=20
>>>> exploites ou copies sans autorisation. Si vous avez recu ce message=20=

>>>> par erreur, veuillez le signaler a l'expediteur et le detruire =
ainsi que les pieces jointes. Les messages electroniques etant =
susceptibles d'alteration, Orange decline toute responsabilite si ce =
message a ete altere, deforme ou falsifie. Merci.
>>>>=20
>>>> This message and its attachments may contain confidential or=20
>>>> privileged information that may be protected by law; they should =
not be distributed, used or copied without authorisation.
>>>> If you have received this email in error, please notify the sender =
and delete this message and its attachments.
>>>> As emails may be altered, Orange is not liable for messages that =
have been modified, changed or falsified.
>>>> Thank you.
>>>>=20
>>>=20
>>> --
>>> Ladislav Lhotka, CZ.NIC Labs
>>> PGP Key ID: E74E8C0C
>>>=20
>>>=20
>>>=20
>>>=20
>>>=20
>>> =
______________________________________________________________________
>>> ___________________________________________________
>>>=20
>>> Ce message et ses pieces jointes peuvent contenir des informations=20=

>>> confidentielles ou privilegiees et ne doivent donc pas etre =
diffuses,=20
>>> exploites ou copies sans autorisation. Si vous avez recu ce message=20=

>>> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi =
que les pieces jointes. Les messages electroniques etant susceptibles =
d'alteration, Orange decline toute responsabilite si ce message a ete =
altere, deforme ou falsifie. Merci.
>>>=20
>>> This message and its attachments may contain confidential or=20
>>> privileged information that may be protected by law; they should not =
be distributed, used or copied without authorisation.
>>> If you have received this email in error, please notify the sender =
and delete this message and its attachments.
>>> As emails may be altered, Orange is not liable for messages that =
have been modified, changed or falsified.
>>> Thank you.
>>>=20
>>=20
>> --
>> Ladislav Lhotka, CZ.NIC Labs
>> PGP Key ID: E74E8C0C
>>=20
>>=20
>>=20
>>=20
>>=20
>> =
__________________________________________________________________________=
_______________________________________________
>>=20
>> Ce message et ses pieces jointes peuvent contenir des informations =
confidentielles ou privilegiees et ne doivent donc
>> pas etre diffuses, exploites ou copies sans autorisation. Si vous =
avez recu ce message par erreur, veuillez le signaler
>> a l'expediteur et le detruire ainsi que les pieces jointes. Les =
messages electroniques etant susceptibles d'alteration,
>> Orange decline toute responsabilite si ce message a ete altere, =
deforme ou falsifie. Merci.
>>=20
>> This message and its attachments may contain confidential or =
privileged information that may be protected by law;
>> they should not be distributed, used or copied without authorisation.
>> If you have received this email in error, please notify the sender =
and delete this message and its attachments.
>> As emails may be altered, Orange is not liable for messages that have =
been modified, changed or falsified.
>> Thank you.
>>=20
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod

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





From nobody Fri Jun 27 09:43:02 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B5BB1B29FF for ; Fri, 27 Jun 2014 09:42:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gz-6Ai87rgd4 for ; Fri, 27 Jun 2014 09:42:55 -0700 (PDT)
Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70E671B2960 for ; Fri, 27 Jun 2014 09:42:54 -0700 (PDT)
Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda14.si.francetelecom.fr (ESMTP service) with ESMTP id 9C7D32ACA91; Fri, 27 Jun 2014 18:42:52 +0200 (CEST)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.5]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id 715BC158052; Fri, 27 Jun 2014 18:42:52 +0200 (CEST)
Received: from OPEXCLILM34.corporate.adroot.infra.ftgroup ([169.254.4.110]) by OPEXCLILH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0181.006; Fri, 27 Jun 2014 18:42:52 +0200
From: 
To: Dean Bogdanovic 
Thread-Topic: [netmod] static routes in draft-ietf-netmod-routing-cfg-15
Thread-Index: AQHPkVjZ5/h1zRC+fE+1O8i784fEa5uEmjcAgAA6CQD///RSgIAAJQEw///xUoCAACs1gP//5lMAAAc/XXA=
Date: Fri, 27 Jun 2014 16:42:51 +0000
Message-ID: <23435_1403887372_53AD9F0C_23435_19136_1_9E32478DFA9976438E7A22F69B08FF92039ABA@OPEXCLILM34.corporate.adroot.infra.ftgroup>
References: <6CCE7829-D078-41B0-8578-300563AD7CB8@juniper.net> <4F17ABF3-F1E4-4EA3-9F8F-02B02162554D@nic.cz>   <236fa2a7df884545b6f8c4a1dd3e8d9a@BY2PR05MB079.namprd05.prod.outlook.com>   <109A8A1D-29C4-4F4C-80FF-DBCD5FB6999D@nic.cz> <8e9299cd951a42b7a8be67e55e87cccb@BY2PR05MB079.namprd05.prod.outlook.com>  <16002_1403869749_53AD5A35_16002_507_1_9E32478DFA9976438E7A22F69B08FF92034FBC@OPEXCLILM34.corporate.adroot.infra.ftgroup> <999D12A8-C4D9-4D68-9D16-BB01728A6579@nic.cz> <22741_1403875319_53AD6FF7_22741_879_4_9E32478DFA9976438E7A22F69B08FF920370DE@OPEXCLILM34.corporate.adroot.infra.ftgroup> <85661580-5EE0-4D2E-BFF1-063506811858@nic.cz> <15159_1403881185_53AD86E1_15159_4507_1_9E32478DFA9976438E7A22F69B08FF92039219@OPEXCLILM34.corporate.adroot.infra.ftgroup> <84CF3F71-9CAD-4C96-977F-80945C4DE29E@juniper.net>
In-Reply-To: <84CF3F71-9CAD-4C96-977F-80945C4DE29E@juniper.net>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.168.234.1]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.6.27.121217
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/AqdFZlhLtvGsFuYuQtQFB91S9jc
Cc: "Jeffrey \(Zhaohui\) Zhang" , "netmod@ietf.org" 
Subject: Re: [netmod] static routes in draft-ietf-netmod-routing-cfg-15
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 27 Jun 2014 16:42:59 -0000

Weight is something else ...
And you need "best" flag as well as weight setting.
Maybe best is not a good name ... and active is better. When doing ECMP or =
UECMP, both are active with same weight (ECMP) or different weight (UECMP)


-----Original Message-----
From: Dean Bogdanovic [mailto:deanb@juniper.net]=20
Sent: Friday, June 27, 2014 17:13
To: LITKOWSKI Stephane SCE/IBNF
Cc: Ladislav Lhotka; Jeffrey (Zhaohui) Zhang; netmod@ietf.org
Subject: Re: [netmod] static routes in draft-ietf-netmod-routing-cfg-15


On Jun 27, 2014, at 10:59 AM, stephane.litkowski@orange.com wrote:

>> If I understand you correctly, you'd prefer to have a RIB as a list keye=
d with destination prefixes and each entry containing a list of routes for =
that prefix with the active route being tagged.
>=20
> [SLI] The major point is to be able to identify the easily the "route-typ=
e" : best, non best.

no, that is not a good idea. You can have protection and load balance prefe=
rence. If you just use route-type best, then how will you do load balancing=
 between different routes? You should be able to add weight to each route a=
nd based on that weight do load balancing between them.

>=20
>=20
>=20
> -----Original Message-----
> From: Ladislav Lhotka [mailto:lhotka@nic.cz]
> Sent: Friday, June 27, 2014 16:11
> To: LITKOWSKI Stephane SCE/IBNF
> Cc: Jeffrey (Zhaohui) Zhang; netmod@ietf.org
> Subject: Re: [netmod] static routes in=20
> draft-ietf-netmod-routing-cfg-15
>=20
>=20
> On 27 Jun 2014, at 15:21,   wrote:
>=20
>>> A system supporting the "multipath-routes" feature can use "next-hop-li=
st" in its routes.
>>=20
>>> On the other hand, I assume that two routes with the same destination p=
refix obtained from different protocols will remain >separate because they =
may be passed to a route filter and treated differently by it.
>>=20
>> [SLI] Regarding route filters, I have one concern regarding the approach=
 for multiple routes for the same prefix in route list.
>>=20
>>=20
>> Consider that you have a RIP learned route 10/8 at RtrX RtrX has a=20
>> "default RIP route-filter" to export RIP routes from connected RIB to RI=
P neighbors.
>>=20
>> So it's expected that 10/8 learned RIB route is advertised to neighbors.
>>=20
>> Now, I had a static route to 10/8 on RtrX with highest preference than R=
IP protocol.
>>=20
>> The 10/8 is expected to not be exported anymore because only best routes=
 can be exported from RIB and best route is not a RIP one.
>>=20
>> That's why I found the model confusing to have different route entries f=
or a specific destination. The notion of best path per destination is quite=
 critical to be present in the model and we need to be able to retrieve all=
 paths for a specific destination prefix.
>> The other way to do it, would be to add "active"/"best" leaf in the rout=
e list.
>=20
> If I understand you correctly, you'd prefer to have a RIB as a list keyed=
 with destination prefixes and each entry containing a list of routes for t=
hat prefix with the active route being tagged.
>=20
> Lada
>=20
>>=20
>>=20
>> Best Regards,
>>=20
>> Stephane
>>=20
>> -----Original Message-----
>> From: Ladislav Lhotka [mailto:lhotka@nic.cz]
>> Sent: Friday, June 27, 2014 14:51
>> To: LITKOWSKI Stephane SCE/IBNF
>> Cc: Jeffrey (Zhaohui) Zhang; netmod@ietf.org
>> Subject: Re: [netmod] static routes in
>> draft-ietf-netmod-routing-cfg-15
>>=20
>>=20
>> On 27 Jun 2014, at 13:49,   wrote:
>>=20
>>> Hi,
>>>=20
>>> I'm wondering if the current model for RIB is the right one. Maybe ther=
e was already discussions on this in the past, so sorry to come back to it =
, if it's the case ...
>>>=20
>>> Currently the model is to have list of routes. Each route containing ne=
xthop and prefix information.
>>> So if I have the following routes :
>>> 10.0.0.0/8 ISIS preference 20, metric 100
>>> 10.0.0.0/8 OSPF preference 15, metric 500
>>>=20
>>> I would have two route entries in routes with a single nexthop in it fo=
r each.
>>>=20
>>> If I have :
>>> 10.0.0.0/8 Static nexthop 1
>>> 10.0.0.0/8 Static nexthop 2
>>>=20
>>> I would have a single route entry with a nexthop-list.
>>=20
>> A system supporting the "multipath-routes" feature can use "next-hop-lis=
t" in its routes.
>>=20
>> On the other hand, I assume that two routes with the same destination pr=
efix obtained from different protocols will remain separate because they ma=
y be passed to a route filter and treated differently by it.
>>=20
>>=20
>>>=20
>>> This is not really displaying how RIBs are working today. Moreover it t=
ends to mix how FIB works and how RIB works,  generally we have for RIB :
>>=20
>> FIB (=3D table containing active routes) is not part of this data model =
because we also need to support systems such as Linux that uses route cache.
>>=20
>>=20
>>> A single prefix entry followed by a list of paths : some are primary, s=
ome are protecting (LFA or MRT ...), some are only hidden path (less prefer=
red protocol preference). When multipath is enabled, all primaries are used=
 for Loadbalancing.
>>>=20
>>> Why not using this model , so with the example, I would have a=20
>>> single route entry with next-hop-list as next-hop-options.=20
>>> Nexthop-list would have one primary nexthop, and one backup nexthop.=20
>>> Moreover I'm not
>>=20
>> Because nobody proposed it so far.
>>=20
>>> sure about what "backup" means, especially if you have a FRR nexthop, w=
ould it be "backup" ? I think a new enum may be required for next-hop-class=
ifiers to differentiate "hidden routes" (less preferred) from protecting ro=
utes (LFA ...), both are sort of backup routes ...
>>>=20
>>> Using this system the key of routes can be the destination prefix.
>>> Next-hop-content need then more to be a path-list.
>>> To index path-list, all attributes may require to be taken into account.
>>=20
>> For lists in state data keys are optional.
>>=20
>> Lada
>>=20
>>>=20
>>> Thoughts ?
>>>=20
>>>=20
>>>=20
>>> -----Original Message-----
>>> From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Ladislav=20
>>> Lhotka
>>> Sent: Friday, June 27, 2014 12:05
>>> To: Jeffrey (Zhaohui) Zhang
>>> Cc: netmod@ietf.org
>>> Subject: Re: [netmod] static routes in
>>> draft-ietf-netmod-routing-cfg-15
>>>=20
>>> "Jeffrey (Zhaohui) Zhang"  writes:
>>>=20
>>>> Lada,
>>>>=20
>>>> My proposal is to remove ID and just use prefix.
>>>> For future extensions like TOS, just augment to include TOS in the pre=
fix.
>>>=20
>>> No way. ToS was just an example, other modules may add other parameters=
 such as "preference" or "source-address". We can't expect the destination =
prefix to be unique.
>>>=20
>>> One thing that *might* be possible is to have the following key in stat=
ic routes:
>>>=20
>>> key "destination-prefix id"
>>>=20
>>> It would be especially useful if optional keys are introduced in YANG 1=
.1 (see issue Y09). The "id" would then be used as an auxiliary distinguish=
er for routes that have the same destination-prefix, otherwise it could hav=
e the default value.
>>>=20
>>> Lada
>>>=20
>>>>=20
>>>> Jeffrey
>>>>=20
>>>>> -----Original Message-----
>>>>> From: Ladislav Lhotka [mailto:lhotka@nic.cz]
>>>>> Sent: Thursday, June 26, 2014 10:58 AM
>>>>> To: Jeffrey (Zhaohui) Zhang
>>>>> Cc: Dean Bogdanovic; netmod@ietf.org
>>>>> Subject: Re: static routes in draft-ietf-netmod-routing-cfg-15
>>>>>=20
>>>>> Jeffrey, Dean,
>>>>>=20
>>>>> we should move this long discussion towards some resolution. It=20
>>>>> might be helpful if you propose concrete changes to the current modul=
e(s).
>>>>>=20
>>>>> Thanks, Lada
>>>>>=20
>>>>> On 26 Jun 2014, at 16:46, Jeffrey (Zhaohui) Zhang=20
>>>>> 
>>>>> wrote:
>>>>>=20
>>>>>> Lada,
>>>>>>=20
>>>>>>> It makes little sense to introduce "preference" just for
>>>>> discriminating
>>>>>>> among configured static routes with the same destination prefix.
>>>>> Backup
>>>>>>> routes or multi-path routing can be configured using "next-hop-list=
".
>>>>>>=20
>>>>>> If those all have the same
>>>>>> "preference"/"weight"/"priority"/"whatever",
>>>>> sure use next-hop-list. But if you want to prefer nh1 over nh2,=20
>>>>> then you can either use different static route entries with=20
>>>>> "index", or as you said still use next-hop-list but give different=20
>>>>> priorities to each nexthop in the list.
>>>>>>=20
>>>>>> Some implementations may prefer one way or another. If I take a=20
>>>>>> step
>>>>> back and agree to simply use next-hop-list, then to me we can=20
>>>>> simply use prefix itself to identify the routes. More below.
>>>>>>=20
>>>>>>>=20
>>>>>>> However, this doesn't mean that each destination prefix must=20
>>>>>>> always
>>>>> be
>>>>>>> unique in the list of static routes. Future modules may=20
>>>>>>> introduce new static route attributes, e.g. for policy routing=20
>>>>>>> it could be "tos",
>>>>> and
>>>>>>> then it would make a very good sense to configure multiple=20
>>>>>>> static
>>>>> routes
>>>>>>> with the same destination prefix but different ToS values.
>>>>>>=20
>>>>>> A better way would be to augment it so TOS becomes part of the prefi=
x.
>>>>>>=20
>>>>>> Jeffrey
>>>>>>=20
>>>>>>>=20
>>>>>>> While static routes can be augmented with a new parameter such=20
>>>>>>> as
>>>>> "tos",
>>>>>>> such a parameter cannot be added to the list key.
>>>>>>=20
>>>>>>> -----Original Message-----
>>>>>>> From: Ladislav Lhotka [mailto:lhotka@nic.cz]
>>>>>>> Sent: Thursday, June 26, 2014 10:23 AM
>>>>>>> To: Jeffrey (Zhaohui) Zhang
>>>>>>> Cc: Dean Bogdanovic; netmod@ietf.org
>>>>>>> Subject: Re: static routes in draft-ietf-netmod-routing-cfg-15
>>>>>>>=20
>>>>>>>=20
>>>>>>> On 26 Jun 2014, at 15:50, Jeffrey (Zhaohui) Zhang=20
>>>>>>> 
>>>>>>> wrote:
>>>>>>>=20
>>>>>>>> Lada,
>>>>>>>>=20
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: Ladislav Lhotka [mailto:lhotka@nic.cz]
>>>>>>>>> Sent: Thursday, June 26, 2014 5:52 AM
>>>>>>>>> To: Jeffrey (Zhaohui) Zhang; Dean Bogdanovic
>>>>>>>>> Cc: netmod@ietf.org
>>>>>>>>> Subject: RE: static routes in draft-ietf-netmod-routing-cfg-15
>>>>>>>>>=20
>>>>>>>>> "Jeffrey (Zhaohui) Zhang"  writes:
>>>>>>>>>=20
>>>>>>>>>> Lada,
>>>>>>>>>>=20
>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>> From: Ladislav Lhotka [mailto:lhotka@nic.cz]
>>>>>>>>>>> Sent: Wednesday, June 25, 2014 12:48 PM
>>>>>>>>>>> To: Dean Bogdanovic
>>>>>>>>>>> Cc: netmod@ietf.org; Jeffrey (Zhaohui) Zhang
>>>>>>>>>>> Subject: Re: static routes in
>>>>>>>>>>> draft-ietf-netmod-routing-cfg-15
>>>>>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>>>>>> On 25 Jun 2014, at 15:51, Dean Bogdanovic=20
>>>>>>>>>>> 
>>>>> wrote:
>>>>>>>>>>>=20
>>>>>>>>>>>> Hi,
>>>>>>>>>>>>=20
>>>>>>>>>>>> While reading routing-cfg, looking at the static route=20
>>>>>>>>>>>> model augment "/rt:routing/rt:routing-instance/rt:routing-prot=
ocols/"
>>>>>>>>>>>>    + "rt:routing-protocol/rt:static-routes" {  ...
>>>>>>>>>>>> container ipv4 {
>>>>>>>>>>>>  description
>>>>>>>>>>>>    "Configuration of a 'static' pseudo-protocol instance
>>>>>>>>>>>>     consists of a list of routes.";  list route {
>>>>>>>>>>>>    key "id";
>>>>>>>>>>>>    ordered-by "user";
>>>>>>>>>>>>    description
>>>>>>>>>>>>      "A user-ordered list of static routes.";
>>>>>>>>>>>>    leaf id {
>>>>>>>>>>>>      type uint32 {
>>>>>>>>>>>>        range "1..max";
>>>>>>>>>>>>      }
>>>>>>>>>>>>      description
>>>>>>>>>>>>        "Unique numeric identifier of the route.
>>>>>>>>>>>>=20
>>>>>>>>>>>>         This value is unrelated to system-assigned 'id'
>>>>>>>>>>>>         parameters of routes in RIBs.";
>>>>>>>>>>>>    }
>>>>>>>>>>>>=20
>>>>>>>>>>>> got confused that each static route is identified by an "id".
>>>>>>>>>>> Originally thought it could be metric, but after reading
>>>>>>> description,
>>>>>>>>>>> wasn't sure.
>>>>>>>>>>>>=20
>>>>>>>>>>>> Lada explained that the id is used in case same prefixes=20
>>>>>>>>>>>> are
>>>>>>>>>>> configured, but have different metric. So why not use prefix=20
>>>>>>>>>>> and preference as unique identifier? One could even argue=20
>>>>>>>>>>> that the
>>>>> base
>>>>>>>>> spec
>>>>>>>>>>> only needs to use prefix as the key, and if an=20
>>>>>>>>>>> implementation
>>>>>>>>> supports
>>>>>>>>>>> multiple static routes for the same prefix they can extend=20
>>>>>>>>>>> as an optional feature.
>>>>>>>>>>>=20
>>>>>>>>>>> YANG needs to specify key(s) for configuration lists, so we=20
>>>>>>>>>>> have
>>>>> to
>>>>>>>>> do
>>>>>>>>>>> it for static routes in ietf-routing, and this key cannot be
>>>>>>> changed
>>>>>>>>> or
>>>>>>>>>>> augmented from other modules.
>>>>>>>>>>>=20
>>>>>>>>>>> Under these conditions, I am afraid we don't have any=20
>>>>>>>>>>> natural
>>>>> key(s)
>>>>>>>>>>> that would be universally acceptable. All systems use some
>>>>>>> additional
>>>>>>>>>>> parameters, be they called preference, metric or=20
>>>>>>>>>>> administrative
>>>>>>>>> distance,
>>>>>>>>>>> but the problem is that, depending on the system, they may=20
>>>>>>>>>>> be
>>>>>>>>> specified
>>>>>>>>>>> (i) per route, (ii) per destination prefix, or (iii) per=20
>>>>>>>>>>> protocol instance.
>>>>>>>>>>=20
>>>>>>>>>> What's the difference between "route" ((i) above) and=20
>>>>>>>>>> "destination
>>>>>>>>> prefix" ((ii) above)?
>>>>>>>>>=20
>>>>>>>>> Quagga can set distance either for a protocol
>>>>>>>>>=20
>>>>>>>>> distance 
>>>>>>>>>=20
>>>>>>>>> or selectively
>>>>>>>>>=20
>>>>>>>>> distance  A.B.C.D/M
>>>>>>>>=20
>>>>>>>> I was asking the difference between "route" and "destination prefi=
x".
>>>>>>> I guess a "route" means a particular entry (e.g. those with=20
>>>>>>> different nexthops or in a broader context - from different
>>>>>>> protcools) for a prefix. Is that correct?
>>>>>>>=20
>>>>>>> Destination prefix is one of the attributes of a route.
>>>>>>>=20
>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>>> (iii) is irrelevant here - we're talking about=20
>>>>>>>>>> "static-route",
>>>>> which
>>>>>>>>> is a "protocol instance" and does not need to be in the key=20
>>>>>>>>> for the static route entries.
>>>>>>>>>=20
>>>>>>>>> It is relevant. If we introduce preference as a route=20
>>>>>>>>> attribute in
>>>>>>> ietf-
>>>>>>>>> routing (as it is e.g. in JUNOS or BIRD), then implementations=20
>>>>>>>>> that don't have it (use only per-protocol distance) would be out =
of luck.
>>>>>>>>=20
>>>>>>>> We are talking about specifying static routes. If an=20
>>>>>>>> implementation
>>>>>>> does not support multiple static route entries for the same=20
>>>>>>> prefix
>>>>> (e.g.
>>>>>>> using different nexthops), then the "preference" or whatever we=20
>>>>>>> call
>>>>> it
>>>>>>> would be a fixed value say 0. If the implementation does support=20
>>>>>>> that, then it must provide a preference for each entry.
>>>>>>>=20
>>>>>>> It makes little sense to introduce "preference" just for
>>>>> discriminating
>>>>>>> among configured static routes with the same destination prefix.
>>>>> Backup
>>>>>>> routes or multi-path routing can be configured using "next-hop-list=
".
>>>>>>>=20
>>>>>>> However, this doesn't mean that each destination prefix must=20
>>>>>>> always
>>>>> be
>>>>>>> unique in the list of static routes. Future modules may=20
>>>>>>> introduce new static route attributes, e.g. for policy routing=20
>>>>>>> it could be "tos",
>>>>> and
>>>>>>> then it would make a very good sense to configure multiple=20
>>>>>>> static
>>>>> routes
>>>>>>> with the same destination prefix but different ToS values.
>>>>>>>=20
>>>>>>> While static routes can be augmented with a new parameter such=20
>>>>>>> as
>>>>> "tos",
>>>>>>> such a parameter cannot be added to the list key.
>>>>>>>=20
>>>>>>> Lada
>>>>>>>=20
>>>>>>>>=20
>>>>>>>> Jeffrey
>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>> Lada
>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>>>>>> For Linux, the key would be the triple (dest. prefix, TOS,
>>>>>>>>> preference).
>>>>>>>>>>=20
>>>>>>>>>> To me, routes with different TOS behavior could go into=20
>>>>>>>>>> different
>>>>>>> RIBs;
>>>>>>>>> or, just put the TOS in the prefix part. Then you're left with
>>>>>>> (prefix,
>>>>>>>>> preference) - exactly what we were proposing as the key.
>>>>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>>>>>> So, while I don't like the "id" key at all, I don't see what=20
>>>>>>>>>>> else
>>>>>>>>> could
>>>>>>>>>>> be done. On the other hand, static routes are usually not=20
>>>>>>>>>>> defined
>>>>>>> in
>>>>>>>>>>> excessive quantities, so an extra parameter probably doesn't
>>>>> matter.
>>>>>>>>>>>=20
>>>>>>>>>>> Another important thing to note is that the "id" parameter=20
>>>>>>>>>>> of
>>>>>>> routes
>>>>>>>>> in
>>>>>>>>>>> RIBs (state data) is unrelated to the "id" of static routes.=20
>>>>>>>>>>> It
>>>>> was
>>>>>>>>>>> added recently as a part of "harmonization" with I2RS RIB=20
>>>>>>>>>>> info
>>>>>>> model
>>>>>>>>>>> (state lists don't have to have keys).
>>>>>>>>>>=20
>>>>>>>>>> That's yet another separate discussion that is going on=20
>>>>>>>>>> offline
>>>>> now.
>>>>>>>>> We'll loop back here when it's ready.
>>>>>>>>>>=20
>>>>>>>>>> Jeffrey
>>>>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>>>>>> Lada
>>>>>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>>>>>>> There was an email exchange on this topic offline and we=20
>>>>>>>>>>>> are
>>>>>>>>> curious
>>>>>>>>>>> what does the WG think about this "id"?
>>>>>>>>>>>>=20
>>>>>>>>>>>> Dean
>>>>>>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>>>>>> --
>>>>>>>>>>> Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C
>>>>>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>> --
>>>>>>>>> Ladislav Lhotka, CZ.NIC Labs
>>>>>>>>> PGP Key ID: E74E8C0C
>>>>>>>=20
>>>>>>> --
>>>>>>> Ladislav Lhotka, CZ.NIC Labs
>>>>>>> PGP Key ID: E74E8C0C
>>>>>>>=20
>>>>>>>=20
>>>>>>>=20
>>>>>>=20
>>>>>=20
>>>>> --
>>>>> Ladislav Lhotka, CZ.NIC Labs
>>>>> PGP Key ID: E74E8C0C
>>>>>=20
>>>>>=20
>>>>>=20
>>>>=20
>>>=20
>>> --
>>> Ladislav Lhotka, CZ.NIC Labs
>>> PGP Key ID: E74E8C0C
>>>=20
>>> _______________________________________________
>>> netmod mailing list
>>> netmod@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netmod
>>>=20
>>> ____________________________________________________________________
>>> _ _ ___________________________________________________
>>>=20
>>> Ce message et ses pieces jointes peuvent contenir des informations=20
>>> confidentielles ou privilegiees et ne doivent donc pas etre=20
>>> diffuses, exploites ou copies sans autorisation. Si vous avez recu=20
>>> ce message par erreur, veuillez le signaler a l'expediteur et le detrui=
re ainsi que les pieces jointes. Les messages electroniques etant susceptib=
les d'alteration, Orange decline toute responsabilite si ce message a ete a=
ltere, deforme ou falsifie. Merci.
>>>=20
>>> This message and its attachments may contain confidential or=20
>>> privileged information that may be protected by law; they should not be=
 distributed, used or copied without authorisation.
>>> If you have received this email in error, please notify the sender and =
delete this message and its attachments.
>>> As emails may be altered, Orange is not liable for messages that have b=
een modified, changed or falsified.
>>> Thank you.
>>>=20
>>=20
>> --
>> Ladislav Lhotka, CZ.NIC Labs
>> PGP Key ID: E74E8C0C
>>=20
>>=20
>>=20
>>=20
>>=20
>> _____________________________________________________________________
>> _ ___________________________________________________
>>=20
>> Ce message et ses pieces jointes peuvent contenir des informations=20
>> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20
>> exploites ou copies sans autorisation. Si vous avez recu ce message=20
>> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que=
 les pieces jointes. Les messages electroniques etant susceptibles d'altera=
tion, Orange decline toute responsabilite si ce message a ete altere, defor=
me ou falsifie. Merci.
>>=20
>> This message and its attachments may contain confidential or=20
>> privileged information that may be protected by law; they should not be =
distributed, used or copied without authorisation.
>> If you have received this email in error, please notify the sender and d=
elete this message and its attachments.
>> As emails may be altered, Orange is not liable for messages that have be=
en modified, changed or falsified.
>> Thank you.
>>=20
>=20
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>=20
>=20
>=20
>=20
>=20
> ______________________________________________________________________
> ___________________________________________________
>=20
> Ce message et ses pieces jointes peuvent contenir des informations=20
> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20
> exploites ou copies sans autorisation. Si vous avez recu ce message=20
> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que =
les pieces jointes. Les messages electroniques etant susceptibles d'alterat=
ion, Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.
>=20
> This message and its attachments may contain confidential or=20
> privileged information that may be protected by law; they should not be d=
istributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and de=
lete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have bee=
n modified, changed or falsified.
> Thank you.
>=20
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


___________________________________________________________________________=
______________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.


From nobody Fri Jun 27 10:03:30 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4173B1B2964 for ; Fri, 27 Jun 2014 10:03:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aaS_CKObUP2C for ; Fri, 27 Jun 2014 10:03:23 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0140.outbound.protection.outlook.com [207.46.163.140]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 249B31B28E3 for ; Fri, 27 Jun 2014 10:03:23 -0700 (PDT)
Received: from BN1PR05MB424.namprd05.prod.outlook.com (10.141.58.148) by BN1PR05MB075.namprd05.prod.outlook.com (10.255.199.21) with Microsoft SMTP Server (TLS) id 15.0.954.9; Fri, 27 Jun 2014 17:03:19 +0000
Received: from BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.172]) by BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.172]) with mapi id 15.00.0954.000; Fri, 27 Jun 2014 17:03:19 +0000
From: Dean Bogdanovic 
To: "stephane.litkowski@orange.com" 
Thread-Topic: [netmod] static routes in draft-ietf-netmod-routing-cfg-15
Thread-Index: AQHPkHyQ0orIXWpDoUyLtj2fzemmwZuCCWmAgAAjBWCAAPsgAIAAQPUAgAAKrICAAAN8AIAABmOAgAAApyCAAT/BAIAAHS2AgAARL4CAAAjAAIAADZOAgAANvQCAAAPKgIAAGQaAgAAFtwA=
Date: Fri, 27 Jun 2014 17:03:19 +0000
Message-ID: <0354536A-3CFA-4638-8F47-DFF43CF803D9@juniper.net>
References: <6CCE7829-D078-41B0-8578-300563AD7CB8@juniper.net> <4F17ABF3-F1E4-4EA3-9F8F-02B02162554D@nic.cz>   <236fa2a7df884545b6f8c4a1dd3e8d9a@BY2PR05MB079.namprd05.prod.outlook.com>   <109A8A1D-29C4-4F4C-80FF-DBCD5FB6999D@nic.cz> <8e9299cd951a42b7a8be67e55e87cccb@BY2PR05MB079.namprd05.prod.outlook.com>  <16002_1403869749_53AD5A35_16002_507_1_9E32478DFA9976438E7A22F69B08FF92034FBC@OPEXCLILM34.corporate.adroot.infra.ftgroup> <999D12A8-C4D9-4D68-9D16-BB01728A6579@nic.cz> <22741_1403875319_53AD6FF7_22741_879_4_9E32478DFA9976438E7A22F69B08FF920370DE@OPEXCLILM34.corporate.adroot.infra.ftgroup> <85661580-5EE0-4D2E-BFF1-063506811858@nic.cz> <15159_1403881185_53AD86E1_15159_4507_1_9E32478DFA9976438E7A22F69B08FF92039219@OPEXCLILM34.corporate.adroot.infra.ftgroup> <84CF3F71-9CAD-4C96-977F-80945C4DE29E@juniper.net> <23435_1403887372_53AD9F0C_23435_19136_1_9E32478DFA9976438E7A22F69B08FF92039ABA@OPEXCLILM34.corporate.adroot.infra.ftgroup>
In-Reply-To: <23435_1403887372_53AD9F0C_23435_19136_1_9E32478DFA9976438E7A22F69B08FF92039ABA@OPEXCLILM34.corporate.adroot.infra.ftgroup>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-mailer: Apple Mail (2.1510)
x-originating-ip: [66.129.241.10]
x-microsoft-antispam: BL:0; ACTION:Default; RISK:Low; SCL:0; SPMLVL:NotSpam; PCL:0; RULEID:
x-forefront-prvs: 0255DF69B9
x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(164054003)(24454002)(377454003)(199002)(189002)(13464003)(51704005)(93886003)(2351001)(575784001)(95666004)(561944003)(93916002)(104166001)(21056001)(107046002)(106356001)(106116001)(86362001)(99396002)(85306003)(77096002)(31966008)(74662001)(101416001)(92726001)(82746002)(92566001)(74502001)(50986999)(76176999)(89996001)(80022001)(83716003)(4396001)(50226001)(57306001)(77982001)(36756003)(85852003)(77156001)(87936001)(83072002)(2656002)(87286001)(88136002)(83322001)(19580395003)(19580405001)(76482001)(81342001)(99286002)(15975445006)(33656002)(62966002)(46102001)(64706001)(66066001)(105586002)(20776003)(81542001)(79102001)(104396001)(579004); DIR:OUT; SFP:; SCL:1; SRVR:BN1PR05MB075; H:BN1PR05MB424.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; 
Content-Type: text/plain; charset="us-ascii"
Content-ID: <976D30C495B29B4DA62E23AB8F2B7465@namprd05.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/7B-fb4fmChC6TMsZQ2RmxaSVkaA
Cc: "Jeffrey \(Zhaohui\) Zhang" , "netmod@ietf.org" 
Subject: Re: [netmod] static routes in draft-ietf-netmod-routing-cfg-15
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 27 Jun 2014 17:03:28 -0000

Stephane,

active is better attribute.

Dean

On Jun 27, 2014, at 12:42 PM, stephane.litkowski@orange.com wrote:

> Weight is something else ...
> And you need "best" flag as well as weight setting.
> Maybe best is not a good name ... and active is better. When doing ECMP o=
r UECMP, both are active with same weight (ECMP) or different weight (UECMP=
)
>=20
>=20
> -----Original Message-----
> From: Dean Bogdanovic [mailto:deanb@juniper.net]=20
> Sent: Friday, June 27, 2014 17:13
> To: LITKOWSKI Stephane SCE/IBNF
> Cc: Ladislav Lhotka; Jeffrey (Zhaohui) Zhang; netmod@ietf.org
> Subject: Re: [netmod] static routes in draft-ietf-netmod-routing-cfg-15
>=20
>=20
> On Jun 27, 2014, at 10:59 AM, stephane.litkowski@orange.com wrote:
>=20
>>> If I understand you correctly, you'd prefer to have a RIB as a list key=
ed with destination prefixes and each entry containing a list of routes for=
 that prefix with the active route being tagged.
>>=20
>> [SLI] The major point is to be able to identify the easily the "route-ty=
pe" : best, non best.
>=20
> no, that is not a good idea. You can have protection and load balance pre=
ference. If you just use route-type best, then how will you do load balanci=
ng between different routes? You should be able to add weight to each route=
 and based on that weight do load balancing between them.
>=20
>>=20
>>=20
>>=20
>> -----Original Message-----
>> From: Ladislav Lhotka [mailto:lhotka@nic.cz]
>> Sent: Friday, June 27, 2014 16:11
>> To: LITKOWSKI Stephane SCE/IBNF
>> Cc: Jeffrey (Zhaohui) Zhang; netmod@ietf.org
>> Subject: Re: [netmod] static routes in=20
>> draft-ietf-netmod-routing-cfg-15
>>=20
>>=20
>> On 27 Jun 2014, at 15:21,   wrote:
>>=20
>>>> A system supporting the "multipath-routes" feature can use "next-hop-l=
ist" in its routes.
>>>=20
>>>> On the other hand, I assume that two routes with the same destination =
prefix obtained from different protocols will remain >separate because they=
 may be passed to a route filter and treated differently by it.
>>>=20
>>> [SLI] Regarding route filters, I have one concern regarding the approac=
h for multiple routes for the same prefix in route list.
>>>=20
>>>=20
>>> Consider that you have a RIP learned route 10/8 at RtrX RtrX has a=20
>>> "default RIP route-filter" to export RIP routes from connected RIB to R=
IP neighbors.
>>>=20
>>> So it's expected that 10/8 learned RIB route is advertised to neighbors=
.
>>>=20
>>> Now, I had a static route to 10/8 on RtrX with highest preference than =
RIP protocol.
>>>=20
>>> The 10/8 is expected to not be exported anymore because only best route=
s can be exported from RIB and best route is not a RIP one.
>>>=20
>>> That's why I found the model confusing to have different route entries =
for a specific destination. The notion of best path per destination is quit=
e critical to be present in the model and we need to be able to retrieve al=
l paths for a specific destination prefix.
>>> The other way to do it, would be to add "active"/"best" leaf in the rou=
te list.
>>=20
>> If I understand you correctly, you'd prefer to have a RIB as a list keye=
d with destination prefixes and each entry containing a list of routes for =
that prefix with the active route being tagged.
>>=20
>> Lada
>>=20
>>>=20
>>>=20
>>> Best Regards,
>>>=20
>>> Stephane
>>>=20
>>> -----Original Message-----
>>> From: Ladislav Lhotka [mailto:lhotka@nic.cz]
>>> Sent: Friday, June 27, 2014 14:51
>>> To: LITKOWSKI Stephane SCE/IBNF
>>> Cc: Jeffrey (Zhaohui) Zhang; netmod@ietf.org
>>> Subject: Re: [netmod] static routes in
>>> draft-ietf-netmod-routing-cfg-15
>>>=20
>>>=20
>>> On 27 Jun 2014, at 13:49,   wrote:
>>>=20
>>>> Hi,
>>>>=20
>>>> I'm wondering if the current model for RIB is the right one. Maybe the=
re was already discussions on this in the past, so sorry to come back to it=
 , if it's the case ...
>>>>=20
>>>> Currently the model is to have list of routes. Each route containing n=
exthop and prefix information.
>>>> So if I have the following routes :
>>>> 10.0.0.0/8 ISIS preference 20, metric 100
>>>> 10.0.0.0/8 OSPF preference 15, metric 500
>>>>=20
>>>> I would have two route entries in routes with a single nexthop in it f=
or each.
>>>>=20
>>>> If I have :
>>>> 10.0.0.0/8 Static nexthop 1
>>>> 10.0.0.0/8 Static nexthop 2
>>>>=20
>>>> I would have a single route entry with a nexthop-list.
>>>=20
>>> A system supporting the "multipath-routes" feature can use "next-hop-li=
st" in its routes.
>>>=20
>>> On the other hand, I assume that two routes with the same destination p=
refix obtained from different protocols will remain separate because they m=
ay be passed to a route filter and treated differently by it.
>>>=20
>>>=20
>>>>=20
>>>> This is not really displaying how RIBs are working today. Moreover it =
tends to mix how FIB works and how RIB works,  generally we have for RIB :
>>>=20
>>> FIB (=3D table containing active routes) is not part of this data model=
 because we also need to support systems such as Linux that uses route cach=
e.
>>>=20
>>>=20
>>>> A single prefix entry followed by a list of paths : some are primary, =
some are protecting (LFA or MRT ...), some are only hidden path (less prefe=
rred protocol preference). When multipath is enabled, all primaries are use=
d for Loadbalancing.
>>>>=20
>>>> Why not using this model , so with the example, I would have a=20
>>>> single route entry with next-hop-list as next-hop-options.=20
>>>> Nexthop-list would have one primary nexthop, and one backup nexthop.=20
>>>> Moreover I'm not
>>>=20
>>> Because nobody proposed it so far.
>>>=20
>>>> sure about what "backup" means, especially if you have a FRR nexthop, =
would it be "backup" ? I think a new enum may be required for next-hop-clas=
sifiers to differentiate "hidden routes" (less preferred) from protecting r=
outes (LFA ...), both are sort of backup routes ...
>>>>=20
>>>> Using this system the key of routes can be the destination prefix.
>>>> Next-hop-content need then more to be a path-list.
>>>> To index path-list, all attributes may require to be taken into accoun=
t.
>>>=20
>>> For lists in state data keys are optional.
>>>=20
>>> Lada
>>>=20
>>>>=20
>>>> Thoughts ?
>>>>=20
>>>>=20
>>>>=20
>>>> -----Original Message-----
>>>> From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Ladislav=20
>>>> Lhotka
>>>> Sent: Friday, June 27, 2014 12:05
>>>> To: Jeffrey (Zhaohui) Zhang
>>>> Cc: netmod@ietf.org
>>>> Subject: Re: [netmod] static routes in
>>>> draft-ietf-netmod-routing-cfg-15
>>>>=20
>>>> "Jeffrey (Zhaohui) Zhang"  writes:
>>>>=20
>>>>> Lada,
>>>>>=20
>>>>> My proposal is to remove ID and just use prefix.
>>>>> For future extensions like TOS, just augment to include TOS in the pr=
efix.
>>>>=20
>>>> No way. ToS was just an example, other modules may add other parameter=
s such as "preference" or "source-address". We can't expect the destination=
 prefix to be unique.
>>>>=20
>>>> One thing that *might* be possible is to have the following key in sta=
tic routes:
>>>>=20
>>>> key "destination-prefix id"
>>>>=20
>>>> It would be especially useful if optional keys are introduced in YANG =
1.1 (see issue Y09). The "id" would then be used as an auxiliary distinguis=
her for routes that have the same destination-prefix, otherwise it could ha=
ve the default value.
>>>>=20
>>>> Lada
>>>>=20
>>>>>=20
>>>>> Jeffrey
>>>>>=20
>>>>>> -----Original Message-----
>>>>>> From: Ladislav Lhotka [mailto:lhotka@nic.cz]
>>>>>> Sent: Thursday, June 26, 2014 10:58 AM
>>>>>> To: Jeffrey (Zhaohui) Zhang
>>>>>> Cc: Dean Bogdanovic; netmod@ietf.org
>>>>>> Subject: Re: static routes in draft-ietf-netmod-routing-cfg-15
>>>>>>=20
>>>>>> Jeffrey, Dean,
>>>>>>=20
>>>>>> we should move this long discussion towards some resolution. It=20
>>>>>> might be helpful if you propose concrete changes to the current modu=
le(s).
>>>>>>=20
>>>>>> Thanks, Lada
>>>>>>=20
>>>>>> On 26 Jun 2014, at 16:46, Jeffrey (Zhaohui) Zhang=20
>>>>>> 
>>>>>> wrote:
>>>>>>=20
>>>>>>> Lada,
>>>>>>>=20
>>>>>>>> It makes little sense to introduce "preference" just for
>>>>>> discriminating
>>>>>>>> among configured static routes with the same destination prefix.
>>>>>> Backup
>>>>>>>> routes or multi-path routing can be configured using "next-hop-lis=
t".
>>>>>>>=20
>>>>>>> If those all have the same
>>>>>>> "preference"/"weight"/"priority"/"whatever",
>>>>>> sure use next-hop-list. But if you want to prefer nh1 over nh2,=20
>>>>>> then you can either use different static route entries with=20
>>>>>> "index", or as you said still use next-hop-list but give different=20
>>>>>> priorities to each nexthop in the list.
>>>>>>>=20
>>>>>>> Some implementations may prefer one way or another. If I take a=20
>>>>>>> step
>>>>>> back and agree to simply use next-hop-list, then to me we can=20
>>>>>> simply use prefix itself to identify the routes. More below.
>>>>>>>=20
>>>>>>>>=20
>>>>>>>> However, this doesn't mean that each destination prefix must=20
>>>>>>>> always
>>>>>> be
>>>>>>>> unique in the list of static routes. Future modules may=20
>>>>>>>> introduce new static route attributes, e.g. for policy routing=20
>>>>>>>> it could be "tos",
>>>>>> and
>>>>>>>> then it would make a very good sense to configure multiple=20
>>>>>>>> static
>>>>>> routes
>>>>>>>> with the same destination prefix but different ToS values.
>>>>>>>=20
>>>>>>> A better way would be to augment it so TOS becomes part of the pref=
ix.
>>>>>>>=20
>>>>>>> Jeffrey
>>>>>>>=20
>>>>>>>>=20
>>>>>>>> While static routes can be augmented with a new parameter such=20
>>>>>>>> as
>>>>>> "tos",
>>>>>>>> such a parameter cannot be added to the list key.
>>>>>>>=20
>>>>>>>> -----Original Message-----
>>>>>>>> From: Ladislav Lhotka [mailto:lhotka@nic.cz]
>>>>>>>> Sent: Thursday, June 26, 2014 10:23 AM
>>>>>>>> To: Jeffrey (Zhaohui) Zhang
>>>>>>>> Cc: Dean Bogdanovic; netmod@ietf.org
>>>>>>>> Subject: Re: static routes in draft-ietf-netmod-routing-cfg-15
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>> On 26 Jun 2014, at 15:50, Jeffrey (Zhaohui) Zhang=20
>>>>>>>> 
>>>>>>>> wrote:
>>>>>>>>=20
>>>>>>>>> Lada,
>>>>>>>>>=20
>>>>>>>>>> -----Original Message-----
>>>>>>>>>> From: Ladislav Lhotka [mailto:lhotka@nic.cz]
>>>>>>>>>> Sent: Thursday, June 26, 2014 5:52 AM
>>>>>>>>>> To: Jeffrey (Zhaohui) Zhang; Dean Bogdanovic
>>>>>>>>>> Cc: netmod@ietf.org
>>>>>>>>>> Subject: RE: static routes in draft-ietf-netmod-routing-cfg-15
>>>>>>>>>>=20
>>>>>>>>>> "Jeffrey (Zhaohui) Zhang"  writes:
>>>>>>>>>>=20
>>>>>>>>>>> Lada,
>>>>>>>>>>>=20
>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>> From: Ladislav Lhotka [mailto:lhotka@nic.cz]
>>>>>>>>>>>> Sent: Wednesday, June 25, 2014 12:48 PM
>>>>>>>>>>>> To: Dean Bogdanovic
>>>>>>>>>>>> Cc: netmod@ietf.org; Jeffrey (Zhaohui) Zhang
>>>>>>>>>>>> Subject: Re: static routes in
>>>>>>>>>>>> draft-ietf-netmod-routing-cfg-15
>>>>>>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>>>>>>> On 25 Jun 2014, at 15:51, Dean Bogdanovic=20
>>>>>>>>>>>> 
>>>>>> wrote:
>>>>>>>>>>>>=20
>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>=20
>>>>>>>>>>>>> While reading routing-cfg, looking at the static route=20
>>>>>>>>>>>>> model augment "/rt:routing/rt:routing-instance/rt:routing-pro=
tocols/"
>>>>>>>>>>>>>   + "rt:routing-protocol/rt:static-routes" {  ...
>>>>>>>>>>>>> container ipv4 {
>>>>>>>>>>>>> description
>>>>>>>>>>>>>   "Configuration of a 'static' pseudo-protocol instance
>>>>>>>>>>>>>    consists of a list of routes.";  list route {
>>>>>>>>>>>>>   key "id";
>>>>>>>>>>>>>   ordered-by "user";
>>>>>>>>>>>>>   description
>>>>>>>>>>>>>     "A user-ordered list of static routes.";
>>>>>>>>>>>>>   leaf id {
>>>>>>>>>>>>>     type uint32 {
>>>>>>>>>>>>>       range "1..max";
>>>>>>>>>>>>>     }
>>>>>>>>>>>>>     description
>>>>>>>>>>>>>       "Unique numeric identifier of the route.
>>>>>>>>>>>>>=20
>>>>>>>>>>>>>        This value is unrelated to system-assigned 'id'
>>>>>>>>>>>>>        parameters of routes in RIBs.";
>>>>>>>>>>>>>   }
>>>>>>>>>>>>>=20
>>>>>>>>>>>>> got confused that each static route is identified by an "id".
>>>>>>>>>>>> Originally thought it could be metric, but after reading
>>>>>>>> description,
>>>>>>>>>>>> wasn't sure.
>>>>>>>>>>>>>=20
>>>>>>>>>>>>> Lada explained that the id is used in case same prefixes=20
>>>>>>>>>>>>> are
>>>>>>>>>>>> configured, but have different metric. So why not use prefix=20
>>>>>>>>>>>> and preference as unique identifier? One could even argue=20
>>>>>>>>>>>> that the
>>>>>> base
>>>>>>>>>> spec
>>>>>>>>>>>> only needs to use prefix as the key, and if an=20
>>>>>>>>>>>> implementation
>>>>>>>>>> supports
>>>>>>>>>>>> multiple static routes for the same prefix they can extend=20
>>>>>>>>>>>> as an optional feature.
>>>>>>>>>>>>=20
>>>>>>>>>>>> YANG needs to specify key(s) for configuration lists, so we=20
>>>>>>>>>>>> have
>>>>>> to
>>>>>>>>>> do
>>>>>>>>>>>> it for static routes in ietf-routing, and this key cannot be
>>>>>>>> changed
>>>>>>>>>> or
>>>>>>>>>>>> augmented from other modules.
>>>>>>>>>>>>=20
>>>>>>>>>>>> Under these conditions, I am afraid we don't have any=20
>>>>>>>>>>>> natural
>>>>>> key(s)
>>>>>>>>>>>> that would be universally acceptable. All systems use some
>>>>>>>> additional
>>>>>>>>>>>> parameters, be they called preference, metric or=20
>>>>>>>>>>>> administrative
>>>>>>>>>> distance,
>>>>>>>>>>>> but the problem is that, depending on the system, they may=20
>>>>>>>>>>>> be
>>>>>>>>>> specified
>>>>>>>>>>>> (i) per route, (ii) per destination prefix, or (iii) per=20
>>>>>>>>>>>> protocol instance.
>>>>>>>>>>>=20
>>>>>>>>>>> What's the difference between "route" ((i) above) and=20
>>>>>>>>>>> "destination
>>>>>>>>>> prefix" ((ii) above)?
>>>>>>>>>>=20
>>>>>>>>>> Quagga can set distance either for a protocol
>>>>>>>>>>=20
>>>>>>>>>> distance 
>>>>>>>>>>=20
>>>>>>>>>> or selectively
>>>>>>>>>>=20
>>>>>>>>>> distance  A.B.C.D/M
>>>>>>>>>=20
>>>>>>>>> I was asking the difference between "route" and "destination pref=
ix".
>>>>>>>> I guess a "route" means a particular entry (e.g. those with=20
>>>>>>>> different nexthops or in a broader context - from different
>>>>>>>> protcools) for a prefix. Is that correct?
>>>>>>>>=20
>>>>>>>> Destination prefix is one of the attributes of a route.
>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>>> (iii) is irrelevant here - we're talking about=20
>>>>>>>>>>> "static-route",
>>>>>> which
>>>>>>>>>> is a "protocol instance" and does not need to be in the key=20
>>>>>>>>>> for the static route entries.
>>>>>>>>>>=20
>>>>>>>>>> It is relevant. If we introduce preference as a route=20
>>>>>>>>>> attribute in
>>>>>>>> ietf-
>>>>>>>>>> routing (as it is e.g. in JUNOS or BIRD), then implementations=20
>>>>>>>>>> that don't have it (use only per-protocol distance) would be out=
 of luck.
>>>>>>>>>=20
>>>>>>>>> We are talking about specifying static routes. If an=20
>>>>>>>>> implementation
>>>>>>>> does not support multiple static route entries for the same=20
>>>>>>>> prefix
>>>>>> (e.g.
>>>>>>>> using different nexthops), then the "preference" or whatever we=20
>>>>>>>> call
>>>>>> it
>>>>>>>> would be a fixed value say 0. If the implementation does support=20
>>>>>>>> that, then it must provide a preference for each entry.
>>>>>>>>=20
>>>>>>>> It makes little sense to introduce "preference" just for
>>>>>> discriminating
>>>>>>>> among configured static routes with the same destination prefix.
>>>>>> Backup
>>>>>>>> routes or multi-path routing can be configured using "next-hop-lis=
t".
>>>>>>>>=20
>>>>>>>> However, this doesn't mean that each destination prefix must=20
>>>>>>>> always
>>>>>> be
>>>>>>>> unique in the list of static routes. Future modules may=20
>>>>>>>> introduce new static route attributes, e.g. for policy routing=20
>>>>>>>> it could be "tos",
>>>>>> and
>>>>>>>> then it would make a very good sense to configure multiple=20
>>>>>>>> static
>>>>>> routes
>>>>>>>> with the same destination prefix but different ToS values.
>>>>>>>>=20
>>>>>>>> While static routes can be augmented with a new parameter such=20
>>>>>>>> as
>>>>>> "tos",
>>>>>>>> such a parameter cannot be added to the list key.
>>>>>>>>=20
>>>>>>>> Lada
>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>> Jeffrey
>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>> Lada
>>>>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>>>>>>> For Linux, the key would be the triple (dest. prefix, TOS,
>>>>>>>>>> preference).
>>>>>>>>>>>=20
>>>>>>>>>>> To me, routes with different TOS behavior could go into=20
>>>>>>>>>>> different
>>>>>>>> RIBs;
>>>>>>>>>> or, just put the TOS in the prefix part. Then you're left with
>>>>>>>> (prefix,
>>>>>>>>>> preference) - exactly what we were proposing as the key.
>>>>>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>>>>>>> So, while I don't like the "id" key at all, I don't see what=20
>>>>>>>>>>>> else
>>>>>>>>>> could
>>>>>>>>>>>> be done. On the other hand, static routes are usually not=20
>>>>>>>>>>>> defined
>>>>>>>> in
>>>>>>>>>>>> excessive quantities, so an extra parameter probably doesn't
>>>>>> matter.
>>>>>>>>>>>>=20
>>>>>>>>>>>> Another important thing to note is that the "id" parameter=20
>>>>>>>>>>>> of
>>>>>>>> routes
>>>>>>>>>> in
>>>>>>>>>>>> RIBs (state data) is unrelated to the "id" of static routes.=20
>>>>>>>>>>>> It
>>>>>> was
>>>>>>>>>>>> added recently as a part of "harmonization" with I2RS RIB=20
>>>>>>>>>>>> info
>>>>>>>> model
>>>>>>>>>>>> (state lists don't have to have keys).
>>>>>>>>>>>=20
>>>>>>>>>>> That's yet another separate discussion that is going on=20
>>>>>>>>>>> offline
>>>>>> now.
>>>>>>>>>> We'll loop back here when it's ready.
>>>>>>>>>>>=20
>>>>>>>>>>> Jeffrey
>>>>>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>>>>>>> Lada
>>>>>>>>>>>>=20
>>>>>>>>>>>>>=20
>>>>>>>>>>>>> There was an email exchange on this topic offline and we=20
>>>>>>>>>>>>> are
>>>>>>>>>> curious
>>>>>>>>>>>> what does the WG think about this "id"?
>>>>>>>>>>>>>=20
>>>>>>>>>>>>> Dean
>>>>>>>>>>>>>=20
>>>>>>>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>>>>>>> --
>>>>>>>>>>>> Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C
>>>>>>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>> --
>>>>>>>>>> Ladislav Lhotka, CZ.NIC Labs
>>>>>>>>>> PGP Key ID: E74E8C0C
>>>>>>>>=20
>>>>>>>> --
>>>>>>>> Ladislav Lhotka, CZ.NIC Labs
>>>>>>>> PGP Key ID: E74E8C0C
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>=20
>>>>>>=20
>>>>>> --
>>>>>> Ladislav Lhotka, CZ.NIC Labs
>>>>>> PGP Key ID: E74E8C0C
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>=20
>>>>=20
>>>> --
>>>> Ladislav Lhotka, CZ.NIC Labs
>>>> PGP Key ID: E74E8C0C
>>>>=20
>>>> _______________________________________________
>>>> netmod mailing list
>>>> netmod@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/netmod
>>>>=20
>>>> ____________________________________________________________________
>>>> _ _ ___________________________________________________
>>>>=20
>>>> Ce message et ses pieces jointes peuvent contenir des informations=20
>>>> confidentielles ou privilegiees et ne doivent donc pas etre=20
>>>> diffuses, exploites ou copies sans autorisation. Si vous avez recu=20
>>>> ce message par erreur, veuillez le signaler a l'expediteur et le detru=
ire ainsi que les pieces jointes. Les messages electroniques etant suscepti=
bles d'alteration, Orange decline toute responsabilite si ce message a ete =
altere, deforme ou falsifie. Merci.
>>>>=20
>>>> This message and its attachments may contain confidential or=20
>>>> privileged information that may be protected by law; they should not b=
e distributed, used or copied without authorisation.
>>>> If you have received this email in error, please notify the sender and=
 delete this message and its attachments.
>>>> As emails may be altered, Orange is not liable for messages that have =
been modified, changed or falsified.
>>>> Thank you.
>>>>=20
>>>=20
>>> --
>>> Ladislav Lhotka, CZ.NIC Labs
>>> PGP Key ID: E74E8C0C
>>>=20
>>>=20
>>>=20
>>>=20
>>>=20
>>> _____________________________________________________________________
>>> _ ___________________________________________________
>>>=20
>>> Ce message et ses pieces jointes peuvent contenir des informations=20
>>> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20
>>> exploites ou copies sans autorisation. Si vous avez recu ce message=20
>>> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi qu=
e les pieces jointes. Les messages electroniques etant susceptibles d'alter=
ation, Orange decline toute responsabilite si ce message a ete altere, defo=
rme ou falsifie. Merci.
>>>=20
>>> This message and its attachments may contain confidential or=20
>>> privileged information that may be protected by law; they should not be=
 distributed, used or copied without authorisation.
>>> If you have received this email in error, please notify the sender and =
delete this message and its attachments.
>>> As emails may be altered, Orange is not liable for messages that have b=
een modified, changed or falsified.
>>> Thank you.
>>>=20
>>=20
>> --
>> Ladislav Lhotka, CZ.NIC Labs
>> PGP Key ID: E74E8C0C
>>=20
>>=20
>>=20
>>=20
>>=20
>> ______________________________________________________________________
>> ___________________________________________________
>>=20
>> Ce message et ses pieces jointes peuvent contenir des informations=20
>> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20
>> exploites ou copies sans autorisation. Si vous avez recu ce message=20
>> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que=
 les pieces jointes. Les messages electroniques etant susceptibles d'altera=
tion, Orange decline toute responsabilite si ce message a ete altere, defor=
me ou falsifie. Merci.
>>=20
>> This message and its attachments may contain confidential or=20
>> privileged information that may be protected by law; they should not be =
distributed, used or copied without authorisation.
>> If you have received this email in error, please notify the sender and d=
elete this message and its attachments.
>> As emails may be altered, Orange is not liable for messages that have be=
en modified, changed or falsified.
>> Thank you.
>>=20
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>=20
>=20
> _________________________________________________________________________=
________________________________________________
>=20
> Ce message et ses pieces jointes peuvent contenir des informations confid=
entielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re=
cu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages =
electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme o=
u falsifie. Merci.
>=20
> This message and its attachments may contain confidential or privileged i=
nformation that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and de=
lete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have bee=
n modified, changed or falsified.
> Thank you.
>=20


From nobody Fri Jun 27 12:07:11 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B2C31B29D5 for ; Fri, 27 Jun 2014 12:07:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.201
X-Spam-Level: 
X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3GyxcGfNSjYq for ; Fri, 27 Jun 2014 12:07:06 -0700 (PDT)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFD671B29FC for ; Fri, 27 Jun 2014 12:07:06 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id E39D114B2 for ; Fri, 27 Jun 2014 21:07:04 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 1CyGIvbALHN3 for ; Fri, 27 Jun 2014 21:06:56 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Fri, 27 Jun 2014 21:07:04 +0200 (CEST)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4F01F20054 for ; Fri, 27 Jun 2014 21:07:04 +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 4TXra4vOuyRn; Fri, 27 Jun 2014 21:07: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 3D20A20053; Fri, 27 Jun 2014 21:07:03 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 74AA12D9C4EF; Fri, 27 Jun 2014 21:07:01 +0200 (CEST)
Date: Fri, 27 Jun 2014 21:07:01 +0200
From: Juergen Schoenwaelder 
To: netmod@ietf.org
Message-ID: <20140627190700.GA28109@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.4.2.3i
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/njqZu0-w_n7KEu11y-Vc7kPC1jI
Subject: [netmod] yang 1.1 issues status update
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 27 Jun 2014 19:07:09 -0000

Hi,

as recorded in the minutes of the 2014-06-04 virtual interim minutes,
the following proposals were made for issues that are currently still
in the NEW state:

Y09 introduce optional keys -> OPEN
Y19 we need a better unique -> DEAD
Y21 statement to define new XPath functions in a module -> DEAD
Y22 support constraints on unions -> DEAD
Y26 allow mandatory nodes in augment -> OPEN
Y27 allow mandatory nodes in an updated module -> OPEN
Y33 add 'attribute' statement -> DEAD
Y36 associate a notification with a data node -> DEAD
Y37 allow notifications to be derived from other notifications -> DEAD
Y39 define the terms system/user-controlled instances -> DEAD
Y50 additional extension grammar validation -> DEAD
Y54 remove the advertisement of conformance information in hello message -> OPEN

The reasoning can be found in the minutes. If anyone disagrees with
the proposal coming out of the virtual interim meeting, speak up by
July 4th the latest.

/js

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


From nobody Sat Jun 28 14:02:08 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FC211A008A; Sat, 28 Jun 2014 14:02:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eD_vanaOz5Qp; Sat, 28 Jun 2014 14:02:02 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0144.outbound.protection.outlook.com [207.46.163.144]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4AFB11A0085; Sat, 28 Jun 2014 14:02:02 -0700 (PDT)
Received: from BN1PR05MB424.namprd05.prod.outlook.com (10.141.58.148) by BN1PR05MB423.namprd05.prod.outlook.com (10.141.58.146) with Microsoft SMTP Server (TLS) id 15.0.974.11; Sat, 28 Jun 2014 21:02:00 +0000
Received: from BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.110]) by BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.110]) with mapi id 15.00.0974.002; Sat, 28 Jun 2014 21:02:00 +0000
From: Dean Bogdanovic 
To: Brian E Carpenter 
Thread-Topic: I-D Action: draft-bogdanovic-nmrg-mobile-backhaul-use-case-00.txt
Thread-Index: AQHPko5VW0YUev070EW1SY6IIGMP5ZuHA0qA
Date: Sat, 28 Jun 2014 21:01:59 +0000
Message-ID: <7F667A3C-978A-4732-BFD6-CA32DC58A120@juniper.net>
References: <20140623165625.20901.29157.idtracker@ietfa.amsl.com> <53AE4C89.8000803@gmail.com>
In-Reply-To: <53AE4C89.8000803@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-mailer: Apple Mail (2.1510)
x-originating-ip: [66.129.241.12]
x-microsoft-antispam: BCL:0;PCL:0;RULEID:
x-forefront-prvs: 0256C18696
x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(24454002)(199002)(189002)(51704005)(377454003)(85852003)(79102001)(83072002)(92566001)(82746002)(19580395003)(19580405001)(57306001)(2656002)(81542001)(88136002)(104166001)(89996001)(92726001)(77982001)(87936001)(81342001)(77156001)(76176999)(74662001)(31966008)(83716003)(50226001)(4396001)(50986999)(36756003)(99396002)(46102001)(83322001)(66066001)(33656002)(74502001)(93916002)(87286001)(76482001)(86362001)(64706001)(80022001)(62966002)(101416001)(85306003)(99286002)(95666004)(77096002)(20776003)(105586002)(106116001)(106356001)(21056001)(107046002)(104396001); DIR:OUT; SFP:; SCL:1; SRVR:BN1PR05MB423; H:BN1PR05MB424.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; 
Content-Type: text/plain; charset="us-ascii"
Content-ID: <3ECC319471078E41B86534BC12922C18@namprd05.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/8xxbN_RQ-k4VNMY5_GuNTu1uS50
Cc: "netmod@ietf.org" , "anima@ietf.org" 
Subject: Re: [netmod] I-D Action: draft-bogdanovic-nmrg-mobile-backhaul-use-case-00.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 28 Jun 2014 21:02:04 -0000

Brian,

I'm aware of that issue, but today router is not aware of microwave managem=
ent network. Where locally connected devices have some ideas how to figure =
out, for remote devices have no idea how to get stats without SNMP. And man=
agement networks are usually out of band.=20
I'm interested to hear how remote microwave devices could send counters inf=
ormation using existing tools today, this is one part that I plan to look m=
ore into it

Dean

On Jun 28, 2014, at 1:03 AM, Brian E Carpenter  wrote:

> (Sorry, retry with correct address)
>=20
> Hi,
>=20
> Thanks for this use case. I have one immediate comment.
> In the section on "4.2.  Information needed from policy intent"
> you have listed the addresses of various units and ethernet ports.
> I would expect that in an AN solution, all that would be discovered
> automatically, and might even not be known centrally. In any case
> I don't really see it as policy information.
>=20
> Regards
>   Brian Carpenter
>=20


From nobody Sun Jun 29 09:20:47 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E6A11A0095; Sun, 29 Jun 2014 09:20:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -12.701
X-Spam-Level: 
X-Spam-Status: No, score=-12.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FO3nCZlTPvJw; Sun, 29 Jun 2014 09:20:31 -0700 (PDT)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DC901A00D3; Sun, 29 Jun 2014 09:20:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18015; q=dns/txt; s=iport; t=1404058832; x=1405268432; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=rprHflacPwG+j+k/FMzM2WJk1rZ+HaBa7VzyFKlnAws=; b=fwNPlQdVki1DaWJatpAltUFQYdiu+DbjY4eLySgD2x31pndTUBFpublc 3R4Ib/PgjMhojPK3n+yqx47u8c96R6uOxJNnfVh/wasWiFnxS+S1wT91Q Djx3x48ptGo5pub0bYBVYCzywOmzgH2c1lHw03cjFiYepRNtdwBqzbr+m E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ah0LAMk7sFOtJV2Q/2dsb2JhbABZgkZHUlqCbqgaAQEBAQEBBQFugiqOCIkVARlvFnWEAwEBAQQtQQsQAgEGAg4DBAEBCx0FAgIwFAkIAQEEAQ0FCIg6DY0OnCEInEkXhWSIchYbBgGCczqBFgWcJJI3g0KCMA
X-IronPort-AV: E=Sophos;i="5.01,571,1400025600";  d="scan'208,217";a="336300708"
Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-1.cisco.com with ESMTP; 29 Jun 2014 16:20:30 +0000
Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id s5TGKTFd026251 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 29 Jun 2014 16:20:29 GMT
Received: from xmb-rcd-x08.cisco.com ([169.254.8.36]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.03.0123.003; Sun, 29 Jun 2014 11:20:29 -0500
From: "Tissa Senevirathne (tsenevir)" 
To: Qin Wu , "time@ietf.org" 
Thread-Topic: YANG models for OAM
Thread-Index: Ac+E3qlMyPi638vnRGmjYh75Wx+edAATLCxAA6JRP1A=
Date: Sun, 29 Jun 2014 16:20:29 +0000
Message-ID: 
References:  
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.21.120.135]
Content-Type: multipart/alternative; boundary="_000_FBEA3E19AA24F847BA3AE74E2FE193562EEC1E8Bxmbrcdx08ciscoc_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/mEGafKAU-UTP3NzNC5lysaMcEA4
Cc: "l2vpn@ietf.org" , "opsawg@ietf.org" , "nvo3@ietf.org" , "netmod@ietf.org" , "trill@ietf.org" 
Subject: Re: [netmod] YANG models for OAM
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 29 Jun 2014 16:20:35 -0000

--_000_FBEA3E19AA24F847BA3AE74E2FE193562EEC1E8Bxmbrcdx08ciscoc_
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64

SGkgUWluDQoNClRoZXJlIGFyZSBzZXZlcmFsIHdheSB0aGlzIGlzIGFwcGxpY2FibGUgdG8gU0ZD
DQoNCg0KMS4gICAgICBTRkMgaXMgdW5kZXJsYXllciBpbmRlcGVuZGVudCAsIHdoaWNoIG1lYW5z
IGl0IGNhbiBoYXZlIGFsbCBzb3J0cyBvZiBlbmNhcCB0eXBlcyB1bmRlcm5lYXRoLCB0aGUgbW9k
ZWwgcHJlc2VudGVkIGluIHRpc3NhLW5ldG1vZC1vYW0sIGFkZHJlc3MgZXhhY3RseSB0aGF0IGlz
c3VlLiBJbnN0ZWFkIG9mIHJlLWludmVudGluZyBhbmQgcmUtaW1wbGVtZW50aW5nIHZhcmlvdXMg
ZGlmZmVyZW50IE9BTSB0aGUgZHJhZnQgcHJvcG9zZSB0byBpbnRlZ3JhdGUgdGhlbSBhdCB0aGUg
bWFuYWdlbWVudCBsYXllci4NCg0KMi4gICAgICBJbiB0aGlzIGRyYWZ0IHdlIGRlZmluZSBhIGZs
b3ctZW50cm9weSBhcyBhbiBvcGFxdWUgZWxlbWVudCB0aGF0IGVhY2ggb2YgdGhlIHRlY2hub2xv
Z3kgdHlwZSBjYW4gc3BlY2lmeSBhbmQgaW5jbHVkZS4gSWYgd2UgbG9vayBhdCBkcmFmdC1xdWlu
bi1zZmMtbnNoLTAyLnR4dCwgaXQgZGVmaW5lIGEgYmxvY2sgdGhhdCBzcGVjaWZpZXMgU0ZDLiBT
RkMgdmVyc2lvbiBvZiBZQU5HICBjYW4gc3BlY2lmeSB0aGlzIGFzIHBhcnQgb2YgaXRzIGZsb3cg
ZW50cm9weS4gVGhlIGJlYXV0eSBpcyB0aGF0IGl0IGlzIGFsbCB1cCB0byB0aGUgdGVjaG5vbG9n
eSB0byBzcGVjaWZ5IHRoYXQgKHNpemUgYW5kIHNoYXBlIGlzIHRlY2hub2xvZ3kgZGVwZW5kZW50
KSBhbmQgYmFzZSBtb2RlbCBpcyBzdGlsbCBpbnRhY3QuDQoNCldpdGggdGhlIGFib3ZlIGluIG1p
bmQgLCBjYW4geW91IHBsZWFzZSByZXZpZXcgZHJhZnQtdGlzc2EtbmV0bW9kLW9hbSBhbmQgc2Vl
IGl0IGlzIGZsZXhpYmxlIGFuZCBleHRlbnNpYmxlIGVub3VnaCB0byBmb3IgdGhlIHB1cnBvc2Uu
IElmIHRoaW5ncyBhcmUgbWlzc2luZyB3ZSBjYW4gYWRkIGFuZCBleHRlbmQuDQoNCkkgaGF2ZSBy
ZXF1ZXN0ZWQgbmV0bW9kIFdHIGNoYWlycyBmb3IgYSBwcmVzZW50YXRpb24gc2xvdCBmb3IgZnVy
dGhlciBkaXNjdXNzaW9uIG9mIHRoZSBkcmFmdC4NCg0KRnJvbTogUWluIFd1IFttYWlsdG86Ymls
bC53dUBodWF3ZWkuY29tXQ0KU2VudDogVHVlc2RheSwgSnVuZSAxMCwgMjAxNCA5OjIyIFBNDQpU
bzogVGlzc2EgU2VuZXZpcmF0aG5lICh0c2VuZXZpcik7IHRpbWVAaWV0Zi5vcmcNCkNjOiBuZXRt
b2RAaWV0Zi5vcmc7IG52bzNAaWV0Zi5vcmc7IHRyaWxsQGlldGYub3JnOyBsMnZwbkBpZXRmLm9y
Zzsgb3BzYXdnQGlldGYub3JnDQpTdWJqZWN0OiBSRTogWUFORyBtb2RlbHMgZm9yIE9BTQ0KDQpI
aSwgVGlzc2E6DQpUaGFua3MgZm9yIGluaXRpYXRpbmcgZGlzY3Vzc2lvbiBvbiB0aGlzIHRvcGlj
Lg0KVW5pZmllZCBPQU0gZm9yIG11bHRpLUxheWVyIG5ldHdvcmsgaXMgYSBnb29kIGlkZWEgdG8g
bWUuDQpkcmFmdC13dy1vcHNhd2ctbXVsdGktbGF5ZXItb2FtLTAwIHdlIHByb3Bvc2VkIGluIG9w
c2F3ZyBsYWlkIG91dCB0aGUgYW4gaW5pdGlhbCBkZXNjcmlwdGlvbiBvZiB0aGUgcHJvYmxlbS4N
ClRoZSBxdWVzdGlvbiB0byBkcmFmdC10aXNzYS1uZXRtb2Qtb2FtIGlzDQpJIGFtIHdvbmRlcmlu
ZyBob3cgdGhpcyBnZW5lcmljIFlhbmcgTW9kZWwgY2FuIGJlIGFwcGxpZWQgdG8gU0ZDIGVudmly
b25tZW50Pw0KSG93IGRvIHlvdSBzdXBwb3J0IHRoZSBjYXNlIHdoZXJlIHR3byBlbmRwb2ludHMg
c3VwcG9ydCBkaWZmZXJlbnQgbGF5ZXIgT0FNIG9yIGRvZXNuoa90IHN1cHBvcnQgYW55IE9BTSBh
dCB0aGF0IGxheWVyLg0KDQpCVFc6IEkgaGF2ZSBjY6GvZWQgdGltZSBtYWlsaW5nIGxpc3Qgc2lu
Y2UgSSBiZWxpZXZlIHRoaXMgbWFpbGluZyBsaXN0IGlzIHB1cnBvc2VkIHRvIGxvb2sgZm9yIGdl
bmVyaWMgYW5kIGludGVncmF0ZWQgT0FNIGNvdmVyaW5nIHZhcmlvdXMgaGV0ZXJvZ2VuZW91cyBu
ZXR3b3JraW5nIHRlY2hub2xvZ2llcy4NClJlZ2FyZHMhDQotUWluDQq3orz+yMs6IG5ldG1vZCBb
bWFpbHRvOm5ldG1vZC1ib3VuY2VzQGlldGYub3JnXSC0+rHtIFRpc3NhIFNlbmV2aXJhdGhuZSAo
dHNlbmV2aXIpDQq3osvNyrG85DogMjAxNMTqNtTCMTHI1SAzOjAzDQrK1bz+yMs6IG5ldG1vZEBp
ZXRmLm9yZzxtYWlsdG86bmV0bW9kQGlldGYub3JnPjsgbnZvM0BpZXRmLm9yZzxtYWlsdG86bnZv
M0BpZXRmLm9yZz47IHRyaWxsQGlldGYub3JnPG1haWx0bzp0cmlsbEBpZXRmLm9yZz47IGwydnBu
QGlldGYub3JnPG1haWx0bzpsMnZwbkBpZXRmLm9yZz47IG9wc2F3Z0BpZXRmLm9yZzxtYWlsdG86
b3BzYXdnQGlldGYub3JnPg0K1vfM4jogW25ldG1vZF0gWUFORyBtb2RlbHMgZm9yIE9BTQ0KDQpB
bGwNCg0KV2UgaGF2ZSBwdWJsaXNoZWQgWUFORyBtb2RlbCBmb3IgT0FNLiAjMSBkcmFmdCBiZWxv
dyBwbGFjZSB0aGUgZ2VuZXJpYyBmcmFtZXdvcmsgZm9yIE9BTSwgdGhhdCBjYW4gYmUgYXVnbWVu
dGVkIGZvciBkaWZmZXJlbnQgdGVjaG5vbG9naWVzLiAjMiBhbmQgIzMgYXJlIGFwcGxpY2F0aW9u
IG9mIHRoZSBjb25jZXB0IHRvIE5WTzMgYW5kIFRSSUxMLA0KDQoNCjEuICAgICAgaHR0cDovL2Rh
dGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC10aXNzYS1uZXRtb2Qtb2FtLw0KDQoyLiAgICAg
IGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtdGlzc2EtbnZvMy15YW5nLW9h
bS8NCg0KMy4gICAgICBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXRpc3Nh
LXRyaWxsLXlhbmctb2FtLw0KDQpQbGVhc2UgcmV2aWV3IGFuZCBzaGFyZSB5b3VyIGNvbW1lbnRz
DQoNClRoYW5rcw0KVGlzc2ENCg0KDQo=

--_000_FBEA3E19AA24F847BA3AE74E2FE193562EEC1E8Bxmbrcdx08ciscoc_
Content-Type: text/html; charset="gb2312"
Content-Transfer-Encoding: quoted-printable











Hi Qin


 


There are several way =
this is applicable to SFC


 


1.&n=
bsp;    
SFC is underla=
yer independent , which means it can have all sorts of encap types undernea=
th, the model presented in tissa-netmod-oam, address exactly that issue. In=
stead of re-inventing and re-implementing
 various different OAM the draft propose to integrate them at the managemen=
t layer.


2.&n=
bsp;    
In this draft =
we define a flow-entropy as an opaque element that each of the technology t=
ype can specify and include. If we look at draft-quinn-sfc-nsh-02.txt, it d=
efine a block that specifies SFC.
 SFC version of YANG  can specify this as part of its flow entropy. Th=
e beauty is that it is all up to the technology to specify that (size and s=
hape is technology dependent) and base model is still intact.


 


With the above in mind=
 , can you please review draft-tissa-netmod-oam and see it is flexible and =
extensible enough to for the purpose. If things are missing we can add and =
extend.


 


I have requested netmo=
d WG chairs for a presentation slot for further discussion of the draft. &n=
bsp;


 






From: Qin Wu [=
mailto:bill.wu@huawei.com]


Sent: Tuesday, June 10, 2014 9:22 PM

To: Tissa Senevirathne (tsenevir); time@ietf.org

Cc: netmod@ietf.org; nvo3@ietf.org; trill@ietf.org; l2vpn@ietf.org; =
opsawg@ietf.org

Subject: RE: YANG models for OAM






 


Hi, T=
issa:


Thank=
s for initiating discussion on this topic.


Unifi=
ed OAM for multi-Layer network is a good idea to me.


draft=
-ww-opsawg-multi-layer-oam-00 we proposed in opsawg laid out the an initial=
 description of the problem.


The q=
uestion to
draft-tissa-netmod-oam is


I am =
wondering how this generic Yang Model can be applied to SFC environment?


How d=
o you support the case where two endpoints support different layer OAM or d=
oesn=A1=AFt support any OAM at that layer.


=
 


BTW: =
I have cc=A1=AFed time mailing list since I believe this mailing list is pu=
rposed to look for generic and integrated OAM covering various heterogeneou=
s networking technologies.


Regar=
ds!


-Qin<=
o:p>






=B7=A2=BC=FE=C8=CB: netmod [mailto:=
netmod-bounces@ietf.org]
=B4=FA=B1=ED Tissa Senevirathne (tsenevi=
r)

=B7=A2=CB=CD=CA=B1=BC=E4: 2014=C4=EA6=D4=C211=C8=D5 3:03

=CA=D5=BC=FE=C8=CB: netmod@ietf.org;
nvo3@ietf.org; 
trill@ietf.org; l2vpn@ietf.org; <=
a href=3D"mailto:opsawg@ietf.org">
opsawg@ietf.org

=D6=F7=CC=E2: [netmod] YANG models for O=
AM






 


All


 


We have published YANG model for OAM. #1 draft below=
 place the generic framework for OAM, that can be augmented for different t=
echnologies. #2 and #3 are application of the concept to NVO3 and TRILL,


 


1.     
http://datatracker.ietf.org/doc/draft-tissa-netmod-oam/


2.     
http://datatracker.ietf.org/doc/draft-tissa-nvo3-yang-o=
am/


3.     
http://datatracker.ietf.org/doc/draft-tissa-trill-yang=
-oam/


 


Please review and share your comments


 


Thanks


Tissa


 


 






--_000_FBEA3E19AA24F847BA3AE74E2FE193562EEC1E8Bxmbrcdx08ciscoc_--