From mbj@tail-f.com Mon Apr 1 12:13:55 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C0FD21E80A6 for ; Mon, 1 Apr 2013 12:13:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.187 X-Spam-Level: X-Spam-Status: No, score=-0.187 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zQmr2TGPnCqq for ; Mon, 1 Apr 2013 12:13:53 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id B7F6D21E8063 for ; Mon, 1 Apr 2013 12:13:53 -0700 (PDT) Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id AEFAB1200D5E; Mon, 1 Apr 2013 21:13:51 +0200 (CEST) Date: Mon, 01 Apr 2013 21:13:51 +0200 (CEST) Message-Id: <20130401.211351.525131372.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: References: <11D8A662-9EC4-4488-8345-CC01A9176A3C@nic.cz> <5155B2A8.8050104@mg-soft.com> X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] include X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 19:13:55 -0000 Ladislav Lhotka wrote: > Hi, > > for the time being, an easy fix seems to be to require that all submodules be > explicitly included from the main module. This may even qualify as an erratum. +1 /martin From andy@yumaworks.com Mon Apr 1 18:40:14 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 399341F0D07 for ; Mon, 1 Apr 2013 18:40:14 -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=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vXBmktgB9lzV for ; Mon, 1 Apr 2013 18:40:13 -0700 (PDT) Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id B0C2F1F0C74 for ; Mon, 1 Apr 2013 18:40:13 -0700 (PDT) Received: by mail-ie0-f172.google.com with SMTP id c10so3001585ieb.3 for ; Mon, 01 Apr 2013 18:40:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=QovmZ/0aXE2XSMSHpkFyBSXizXePPb6qJqSw1uYjCn8=; b=aZDzg87FZ4Ia0wlGZN1S85G6+R6NZy6HiMoz/dUmK6rUc3X8JWg32cRKzUapQZeVOJ YRom8UdIjEul9GW9oRq1so3tuWpFd2rru0gXkJMWMrSOGfLdz4ZwDe6g8abakFu4YM3Z sYitBGZYeneM1Nv2Gnz37rB6IgpsB2Ie+uuk/tP3Y/sma41i7UdZ0R1DlluTA0hDXXYF ZTx9sl1Qc1wOhwtLTf9aM2YXjlliDiOGJVD8Bq6zFJjqvNFWbeSCFA/fPxFn7JzzwwiZ ez7peYSu6XwrdziKvs2lYjGBKiIpCKh2wl4vejErhIoh+67PCWUhCpWzp5d7BmVWcZrU tIjw== MIME-Version: 1.0 X-Received: by 10.50.78.202 with SMTP id d10mr4378397igx.69.1364866813141; Mon, 01 Apr 2013 18:40:13 -0700 (PDT) Received: by 10.231.34.68 with HTTP; Mon, 1 Apr 2013 18:40:12 -0700 (PDT) In-Reply-To: <20130401.211351.525131372.mbj@tail-f.com> References: <11D8A662-9EC4-4488-8345-CC01A9176A3C@nic.cz> <5155B2A8.8050104@mg-soft.com> <20130401.211351.525131372.mbj@tail-f.com> Date: Mon, 1 Apr 2013 18:40:12 -0700 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQlrkPVVTHgyXScMGJY6soxY96HVko30Y/wrquxPvv6Oaf0B99RSA7Y0q2i7085HpErr501H Cc: netmod@ietf.org Subject: Re: [netmod] include X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 01:40:14 -0000 On Mon, Apr 1, 2013 at 12:13 PM, Martin Bjorklund wrote: > Ladislav Lhotka wrote: >> Hi, >> >> for the time being, an easy fix seems to be to require that all submodules be >> explicitly included from the main module. This may even qualify as an erratum. > > +1 > > Section 6.2.1 already requires that identifiers with a specific namespace MUST be unique, so no new text is needed at all. 6.2.1. Identifiers and Their Namespaces Each identifier is valid in a namespace that depends on the type of the YANG item being defined. All identifiers defined in a namespace MUST be unique. o All module and submodule names share the same global module identifier namespace. o All extension names defined in a module and its submodules share the same extension identifier namespace. o All feature names defined in a module and its submodules share the same feature identifier namespace. o All identity names defined in a module and its submodules share the same identity identifier namespace. o All derived type names defined within a parent node or at the top level of the module or its submodules share the same type identifier namespace. This namespace is scoped to all descendant nodes of the parent node or module. This means that any descendent node may use that typedef, and it MUST NOT define a typedef with the same name. o All grouping names defined within a parent node or at the top level of the module or its submodules share the same grouping identifier namespace. This namespace is scoped to all descendant nodes of the parent node or module. This means that any descendent node may use that grouping, and it MUST NOT define a grouping with the same name. o All leafs, leaf-lists, lists, containers, choices, rpcs, notifications, and anyxmls defined (directly or through a uses statement) within a parent node or at the top level of the module or its submodules share the same identifier namespace. This namespace is scoped to the parent node or module, unless the parent node is a case node. In that case, the namespace is scoped to the closest ancestor node that is not a case or choice node. o All cases within a choice share the same case identifier namespace. This namespace is scoped to the parent choice node. > /martin Andy From lhotka@nic.cz Tue Apr 2 02:50:08 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9609821F982B for ; Tue, 2 Apr 2013 02:50:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.095 X-Spam-Level: X-Spam-Status: No, score=-1.095 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_EQ_CZ=0.904, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F8PVB22ZGIy2 for ; Tue, 2 Apr 2013 02:50:08 -0700 (PDT) Received: from trail.lhotka.name (nat-5.bravonet.cz [77.48.224.5]) by ietfa.amsl.com (Postfix) with ESMTP id C4ABF21F9821 for ; Tue, 2 Apr 2013 02:50:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 257D3540223 for ; Tue, 2 Apr 2013 11:50:02 +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 U8dT6xbU4Nkd for ; Tue, 2 Apr 2013 11:49: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 3B15D540101 for ; Tue, 2 Apr 2013 11:49:42 +0200 (CEST) From: Ladislav Lhotka To: netmod@ietf.org In-Reply-To: References: <20130222.161941.453515630.mbj@tail-f.com> <04E80624-7F7E-4265-BB89-C06F104B62E3@nic.cz> <20130222.172257.357766029.mbj@tail-f.com> <11D8A662-9EC4-4488-8345-CC01A9176A3C@nic.cz> <5155B2A8.8050104@mg-soft.com> <8A6EFB59-3B3D-45A9-B2E1-5CC7000716AD@nic.cz> User-Agent: Notmuch/0.15.2+56~gf55b35b (http://notmuchmail.org) Emacs/23.3.50.1 (i386-apple-darwin9.8.0) Mail-Followup-To: netmod@ietf.org Date: Tue, 02 Apr 2013 11:49:41 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [netmod] include X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 09:50:08 -0000 Andy Bierman writes: > > The fact is, you cannot rely the information in the YANG modules to > determine the set of files that were used to construct the schema tree > in use by the server. > > 1) module namspaces are assumed to be globally unique, not module names. > Import "foo" does not reliably identify anything. The URI > for the YANG module is needed to map namespace to module-name. I think the message that module names should be kept unique is quite clear. After all, even the uniqueness of URIs is not enforced and works only as long as people follow the rules. > > 2) Since submodules are not advertised as YANG module capabilities, > the cannot be used to map sub-module names to the > namespace-stmt value. Yes, that's why it is important for the client to be able to find a complete list of submodules in the main module. > > 3) Since import-by-revision and include-by-revision are optional to use, > the import or include statements cannot be used to reliably determine > which revision of the specified module or submodule to use. This is a problem of identifying a version of a data model, but it is IMO orthogonal to the present subject, which is how to determine the components of a single version. > The URI can usually be used to resolve import, but > nothing except the 'schema' list contains this information for submodules. > (Making them mandatory to use would illuminate how fragile they are.) A YANG data model is supposed to be a contract between the server and client, so it is up to the client to make an autonomous decision whether the stuff received from the server is valid. Lada > >> Lada >> > > Andy > >> >>> >>> The include-stmt just says how to resolve prefixes within the module >>> that is being parsed. The import-stmt says how to resolve prefixes >>> from other modules. >>> >>> >>>> Lada >>>> >>> >>> Andy >>> >>> >>>>> >>>>> 7.1.6. The include Statement >>>>> >>>>> [para 1]..... Modules are only allowed to >>>>> include submodules that belong to that module, as defined by the >>>>> "belongs-to" statement (see Section 7.2.2). >>>>> >>>>> 7.2.2. The belongs-to Statement >>>>> >>>>> The "belongs-to" statement specifies the module to which the >>>>> submodule belongs. The argument is an identifier that is the name of >>>>> the module. >>>>> >>>>> There is only one XML namespace for the entire module. >>>>> QNames within that namespace must be unique. >>>>> There is no namespace per submodule in YANG. >>>>> >>>>>> Lada >>>>>> >>>>> >>>>> Andy >>>> >>>> -- >>>> 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 andy@yumaworks.com Tue Apr 2 10:11:47 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 336C521F8717 for ; Tue, 2 Apr 2013 10:11:47 -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=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a3ifuz2Dgr+a for ; Tue, 2 Apr 2013 10:11:46 -0700 (PDT) Received: from mail-ia0-x22d.google.com (mail-ia0-x22d.google.com [IPv6:2607:f8b0:4001:c02::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 341AE21F8BBD for ; Tue, 2 Apr 2013 10:11:41 -0700 (PDT) Received: by mail-ia0-f173.google.com with SMTP id h37so503682iak.4 for ; Tue, 02 Apr 2013 10:11:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type:x-gm-message-state; bh=v5qXo1VypYEIXALIpEwhBKyKjkpnHdQuPpzCZMZJrOM=; b=kzog5TwG2WK+b686v5mCA3vDwUVHZ4XT1u8T2d50aNh79VbuBnijdXCBH+W3VM2AVg Uu2CS6K02dciA1W1emsy5Us8Br0DRxcEeqcDxbCr+XqE4q65sPg7y6fPxISIXTG/WQtw VGsjHzFFZpc2zy7u6ZfABB6dReLOYwTN4HAGUyV1zKte7Ym8upJy0eXH6KfNxvNO6iKC mfU6O/HtMfclwj1eIYqvfL3S+TNFcxb9OMaoWlvZBCINZ/NiszRfk5FAx7xNJk9vX0rA XbBtHVVu7h53kTOdxemf/P9L+OzTgXZXwlRuXu01oCw8nm3Pt/TVmYd/tpbuP7NN+fgk kdvQ== MIME-Version: 1.0 X-Received: by 10.42.64.135 with SMTP id g7mr6699435ici.37.1364922701337; Tue, 02 Apr 2013 10:11:41 -0700 (PDT) Received: by 10.231.34.68 with HTTP; Tue, 2 Apr 2013 10:11:41 -0700 (PDT) In-Reply-To: References: <20130222.161941.453515630.mbj@tail-f.com> <04E80624-7F7E-4265-BB89-C06F104B62E3@nic.cz> <20130222.172257.357766029.mbj@tail-f.com> <11D8A662-9EC4-4488-8345-CC01A9176A3C@nic.cz> <5155B2A8.8050104@mg-soft.com> <8A6EFB59-3B3D-45A9-B2E1-5CC7000716AD@nic.cz> Date: Tue, 2 Apr 2013 10:11:41 -0700 Message-ID: From: Andy Bierman To: netmod@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQlMQbYl0NFNYyQ//tDrGil/dxcj8n0BJ9X1T9jUqi7Pt37W95nE85/lHJeGiKSmsQYpr7xY Subject: Re: [netmod] include X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 17:11:47 -0000 On Tue, Apr 2, 2013 at 2:49 AM, Ladislav Lhotka wrote: > Andy Bierman writes: > >> >> The fact is, you cannot rely the information in the YANG modules to >> determine the set of files that were used to construct the schema tree >> in use by the server. >> >> 1) module namspaces are assumed to be globally unique, not module names. >> Import "foo" does not reliably identify anything. The URI >> for the YANG module is needed to map namespace to module-name. > > I think the message that module names should be kept unique is quite clear. After all, even the uniqueness of URIs is not enforced and works only as long as people follow the rules. > It is quite clear from sec 7.1 that private module names are not reliable. 7.1 (para 2 & 3) Names of modules published in RFC streams [RFC4844] MUST be assigned by IANA, see Section 14. Private module names are assigned by the organization owning the module without a central registry. It is RECOMMENDED to choose module names that will have a low probability of colliding with standard or other enterprise modules and submodules, e.g., by using the enterprise or organization name as a prefix for the module name. >> >> 2) Since submodules are not advertised as YANG module capabilities, >> the cannot be used to map sub-module names to the >> namespace-stmt value. > > Yes, that's why it is important for the client to be able to find a complete list of submodules in the main module. This is a minor implementation detail. The client can usually figure out the submodules to use by following the include-chain. I don't agree that submodules have their own namespace. The include-stmt is used to make a subset of all module symbols available to that suibmodule. IMO this is rather pointless and just adds extra complexity (like we are discussing right now). The "belongs-to" statement has the module prefix as a sub-statement. Any symbol from the module being compiled must use that prefix. Note that the include-stmt does not have a prefix sub-statement. The symbol resolution logic for the current design is not broken. Each parent module or submodule MUST pull in all definitions from its own included submodules to compile statements. So saying that these symbols are not visible is incorrect. All the submodules for the module are accounted for in the dependency tree. It is just an implementation detail how the compiler determines that the requirements of sec 6.2.1 are met. The human writing the YANG module does not need to add anything to the main module. Listing all the submodules in the main module defeats the whole purpose of nesting submodules in the first place. > Lada Andy From lhotka@nic.cz Tue Apr 2 10:21:53 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23C7621F8CA5 for ; Tue, 2 Apr 2013 10:21:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.547 X-Spam-Level: X-Spam-Status: No, score=-1.547 tagged_above=-999 required=5 tests=[AWL=0.452, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p1DegyhG3-Jb for ; Tue, 2 Apr 2013 10:21:52 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id C779021F8C85 for ; Tue, 2 Apr 2013 10:21:51 -0700 (PDT) Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 8892513FE09 for ; Tue, 2 Apr 2013 19:21:50 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1364923310; bh=Haahr8n9tbUZvCnsCYVahmwERYvNdafj81btK+ZNdqE=; h=From:Content-Type:Content-Transfer-Encoding:Subject:Date: References:To:Message-Id:Mime-Version; b=R/WxsYXh65God0tnefuRJHon5QaXhpbw9+cPAAa/2gIBhtAQfhG7X0ZxUZ2fcb5ua a30wGg/3xjxcCztRh952F9TYVyo80vBIb8YeYF/RQ3FX0DtprvIfr3xEGUpiXQiZ+Z pvY3rJSiqs7gl+oLLKDqTYdJLw177tQ0yWAMf224= From: Ladislav Lhotka Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 2 Apr 2013 19:21:49 +0200 References: <20130402171911.7591.53906.idtracker@ietfa.amsl.com> To: netmod@ietf.org Message-Id: Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) X-Mailer: Apple Mail (2.1503) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Subject: [netmod] Fwd: New Version Notification for draft-lhotka-netmod-yang-json-01.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 17:21:53 -0000 Hi, this revision corrects several mistakes and adds an example for union = type. Lada Begin forwarded message: > From: internet-drafts@ietf.org > Subject: New Version Notification for = draft-lhotka-netmod-yang-json-01.txt > Date: April 2, 2013 7:19:11 PM GMT+02:00 > To: lhotka@nic.cz >=20 >=20 > A new version of I-D, draft-lhotka-netmod-yang-json-01.txt > has been successfully submitted by Ladislav Lhotka and posted to the > IETF repository. >=20 > Filename: draft-lhotka-netmod-yang-json > Revision: 01 > Title: Modeling JSON Text with YANG > Creation date: 2013-04-02 > Group: Individual Submission > Number of pages: 14 > URL: = http://www.ietf.org/internet-drafts/draft-lhotka-netmod-yang-json-01.txt > Status: = http://datatracker.ietf.org/doc/draft-lhotka-netmod-yang-json > Htmlized: = http://tools.ietf.org/html/draft-lhotka-netmod-yang-json-01 > Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-lhotka-netmod-yang-json-01 >=20 > Abstract: > This document defines rules for mapping data models expressed in = YANG > to configuration and operational state data encoded as JSON text. = It > does so by specifying a procedure for translating the subset of = YANG- > compatible XML documents to JSON text, and vice versa. >=20 >=20 >=20 >=20 > The IETF Secretariat >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From lhotka@nic.cz Tue Apr 2 11:47:30 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 884B821F8D90 for ; Tue, 2 Apr 2013 11:47:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.773 X-Spam-Level: X-Spam-Status: No, score=-1.773 tagged_above=-999 required=5 tests=[AWL=0.226, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sUiX9oQ3Oiqr for ; Tue, 2 Apr 2013 11:47:29 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 665EF21F8D09 for ; Tue, 2 Apr 2013 11:47:22 -0700 (PDT) Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 1829F13FBD3; Tue, 2 Apr 2013 20:47:22 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1364928442; bh=DkRlOAPklH1GtuUVsnuFG1YN3c/HnQsxecD1mMXg6Xw=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=j0ZGcdJo26ls6NQUQ3cI5h77ArGX1rt0ijhPSqT5dh0+PIFZMlrKpwnejEgZMJMN/ 9f9KfROguurPeGagYq1MJ90aQKYKnqM/2p8GLqdWcvbJYczJ7KZ3Xtt71AlaXEOeqL vggDA2bogyQEsp1Zb+iks7ii3nN0gAFbCQ2wHEUU= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Ladislav Lhotka In-Reply-To: Date: Tue, 2 Apr 2013 20:47:20 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130222.161941.453515630.mbj@tail-f.com> <04E80624-7F7E-4265-BB89-C06F104B62E3@nic.cz> <20130222.172257.357766029.mbj@tail-f.com> <11D8A662-9EC4-4488-8345-CC01A9176A3C@nic.cz> <5155B2A8.8050104@mg-soft.com> <8A6EFB59-3B3D-45A9-B2E1-5CC7000716AD@nic.cz> To: Andy Bierman X-Mailer: Apple Mail (2.1503) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] include X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 18:47:31 -0000 On Apr 2, 2013, at 7:11 PM, Andy Bierman wrote: > On Tue, Apr 2, 2013 at 2:49 AM, Ladislav Lhotka wrote: >> Andy Bierman writes: >>=20 >>>=20 >>> The fact is, you cannot rely the information in the YANG modules to >>> determine the set of files that were used to construct the schema = tree >>> in use by the server. >>>=20 >>> 1) module namspaces are assumed to be globally unique, not module = names. >>> Import "foo" does not reliably identify anything. The = URI >>> for the YANG module is needed to map namespace to module-name. >>=20 >> I think the message that module names should be kept unique is quite = clear. After all, even the uniqueness of URIs is not enforced and works = only as long as people follow the rules. >>=20 >=20 >=20 > It is quite clear from sec 7.1 that private module names are not = reliable. >=20 > 7.1 (para 2 & 3) >=20 > Names of modules published in RFC streams [RFC4844] MUST be assigned > by IANA, see Section 14. >=20 > Private module names are assigned by the organization owning the > module without a central registry. It is RECOMMENDED to choose > module names that will have a low probability of colliding with > standard or other enterprise modules and submodules, e.g., by using > the enterprise or organization name as a prefix for the module name. >=20 >=20 >>>=20 >>> 2) Since submodules are not advertised as YANG module capabilities, >>> the cannot be used to map sub-module names to the >>> namespace-stmt value. >>=20 >> Yes, that's why it is important for the client to be able to find a = complete list of submodules in the main module. >=20 > This is a minor implementation detail. > The client can usually figure out the submodules to use > by following the include-chain. There is no support for this include chain in 6020.=20 >=20 > I don't agree that submodules have their own namespace. I don't think I have ever said this. >=20 > The include-stmt is used to make a subset of all module symbols > available to that suibmodule. IMO this is rather pointless and > just adds extra complexity (like we are discussing right now). I agree with this part, but sec. 7.1.6 also has this text: When a module includes a submodule, it incorporates the contents of the submodule into the node hierarchy of the module. This means it is the include statement that pulls a submodule tree into = the module hierarchy. IMO a sensible solution would be to require the main module to include = all submodules, and have belongs-to in submodules in order to declare = the prefix. That is, no includes in submodules, submodules could = automatically refer to top-level definitions in the main module and all = other submodules. I suspect we may be in a violent agreement. :-) Lada=20 >=20 > The "belongs-to" statement has the module prefix as > a sub-statement. Any symbol from the module being > compiled must use that prefix. Note that the include-stmt > does not have a prefix sub-statement. >=20 > The symbol resolution logic for the current design is not broken. > Each parent module or submodule MUST pull in all definitions > from its own included submodules to compile statements. > So saying that these symbols are not visible is incorrect. > All the submodules for the module are accounted for in the > dependency tree. >=20 > It is just an implementation detail how the compiler determines > that the requirements of sec 6.2.1 are met. The human writing > the YANG module does not need to add anything to the main > module. Listing all the submodules in the main module > defeats the whole purpose of nesting submodules in > the first place. >=20 >> Lada >=20 > Andy > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From andy@yumaworks.com Tue Apr 2 12:13:32 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCD4F21F87CB for ; Tue, 2 Apr 2013 12:13:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_23=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FfDui5eyWUDM for ; Tue, 2 Apr 2013 12:13:32 -0700 (PDT) Received: from mail-ia0-x234.google.com (mail-ia0-x234.google.com [IPv6:2607:f8b0:4001:c02::234]) by ietfa.amsl.com (Postfix) with ESMTP id 0BBF621F87C3 for ; Tue, 2 Apr 2013 12:13:31 -0700 (PDT) Received: by mail-ia0-f180.google.com with SMTP id f27so592161iae.39 for ; Tue, 02 Apr 2013 12:13:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=JmVe8zt6/ycLFhTITaRJMh7nGnytbC9rbixF/x8+Pjs=; b=pb2MUZJMh95UcihaJqS780wbXR90SJe0Fy/IrtON4KZk8CUsEdsZ+/1vi7pVjGYRV6 KFsLPYkmmLGckRbSWA+lLRMUGryA+CbEaD1MsoC+6z+3UvDN94T8pAp+87EaekUZVI/r /0w0TvmmP0Kz3EymukEm5LVFyamhW4XyMmORwQLXLjDucuiYy/dXjM8q+nfK+HKlM63q YkuqglONfsKRAa1aBDNXHT3FdddE6pyMX2qixXxnSyhUazKv+Q8QZGE2KkyDMxi/Pug0 Z6j7URTMwzN0ZG8w6gTezPRuaW57Y5SuM80EGX0COLzcsCl9+EuyF+54u7alOygTO8Qu WYMA== MIME-Version: 1.0 X-Received: by 10.50.7.69 with SMTP id h5mr5920577iga.69.1364930011364; Tue, 02 Apr 2013 12:13:31 -0700 (PDT) Received: by 10.231.34.68 with HTTP; Tue, 2 Apr 2013 12:13:31 -0700 (PDT) In-Reply-To: References: <20130222.161941.453515630.mbj@tail-f.com> <04E80624-7F7E-4265-BB89-C06F104B62E3@nic.cz> <20130222.172257.357766029.mbj@tail-f.com> <11D8A662-9EC4-4488-8345-CC01A9176A3C@nic.cz> <5155B2A8.8050104@mg-soft.com> <8A6EFB59-3B3D-45A9-B2E1-5CC7000716AD@nic.cz> Date: Tue, 2 Apr 2013 12:13:31 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQl5Si2WoBl1OErBOKYhWPOagzobD4r0dGQcncEXJ5I1h9HGHXJDnOQUDm6wV5X+2IzcnKkJ Cc: netmod@ietf.org Subject: Re: [netmod] include X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 19:13:32 -0000 On Tue, Apr 2, 2013 at 11:47 AM, Ladislav Lhotka wrote: > > On Apr 2, 2013, at 7:11 PM, Andy Bierman wrote: > >> On Tue, Apr 2, 2013 at 2:49 AM, Ladislav Lhotka wrote: >>> Andy Bierman writes: >>> >>>> >>>> The fact is, you cannot rely the information in the YANG modules to >>>> determine the set of files that were used to construct the schema tree >>>> in use by the server. >>>> >>>> 1) module namspaces are assumed to be globally unique, not module nam= es. >>>> Import "foo" does not reliably identify anything. The = URI >>>> for the YANG module is needed to map namespace to module-name. >>> >>> I think the message that module names should be kept unique is quite cl= ear. After all, even the uniqueness of URIs is not enforced and works only = as long as people follow the rules. >>> >> >> >> It is quite clear from sec 7.1 that private module names are not reliabl= e. >> >> 7.1 (para 2 & 3) >> >> Names of modules published in RFC streams [RFC4844] MUST be assigned >> by IANA, see Section 14. >> >> Private module names are assigned by the organization owning the >> module without a central registry. It is RECOMMENDED to choose >> module names that will have a low probability of colliding with >> standard or other enterprise modules and submodules, e.g., by using >> the enterprise or organization name as a prefix for the module name. >> >> >>>> >>>> 2) Since submodules are not advertised as YANG module capabilities, >>>> the cannot be used to map sub-module names to the >>>> namespace-stmt value. >>> >>> Yes, that's why it is important for the client to be able to find a com= plete list of submodules in the main module. >> >> This is a minor implementation detail. >> The client can usually figure out the submodules to use >> by following the include-chain. > > There is no support for this include chain in 6020. > The include chain is the conceptual dependency tree specified by the include-stmts in the main module and each submodule included by the main module or a submodule. There has never been any support in YANG for module search paths or other implementation-specific details which would impact the YANG compiler's ability to process an include-stmt. >> >> I don't agree that submodules have their own namespace. > > I don't think I have ever said this. I thought this came up in the discussion of private submodules. > >> >> The include-stmt is used to make a subset of all module symbols >> available to that suibmodule. IMO this is rather pointless and >> just adds extra complexity (like we are discussing right now). > > I agree with this part, but sec. 7.1.6 also has this text: > > When a module includes a submodule, it incorporates the contents of > the submodule into the node hierarchy of the module. IMO this means that all symbols included into the submodule via include-stmts or import-stmts are available to the compiler for resolving symbols. Consider a simple nested example: submod2 --> submod1 --> main submod1 includes all of submod2 into its context, and main includes all of submod1+submod2 into its context. If this did not happen then groupings would not compile correctly. I can use a grouping from submod1 in main. That grouping can use a typedef from submod2. That typedef is used in the main module even though the typedef name is not referenced directly in the main module. Having extra include-stmts in the main module for symbols that are not referenced in the main module is just busy work for the YANG designer. The compiler does not need any extra includes to resolve a symbol. Andy > > This means it is the include statement that pulls a submodule tree into t= he module hierarchy. > > IMO a sensible solution would be to require the main module to include al= l submodules, and have belongs-to in submodules in order to declare the pre= fix. That is, no includes in submodules, submodules could automatically ref= er to top-level definitions in the main module and all other submodules. > > I suspect we may be in a violent agreement. :-) > > Lada > >> >> The "belongs-to" statement has the module prefix as >> a sub-statement. Any symbol from the module being >> compiled must use that prefix. Note that the include-stmt >> does not have a prefix sub-statement. >> >> The symbol resolution logic for the current design is not broken. >> Each parent module or submodule MUST pull in all definitions >> from its own included submodules to compile statements. >> So saying that these symbols are not visible is incorrect. >> All the submodules for the module are accounted for in the >> dependency tree. >> >> It is just an implementation detail how the compiler determines >> that the requirements of sec 6.2.1 are met. The human writing >> the YANG module does not need to add anything to the main >> module. Listing all the submodules in the main module >> defeats the whole purpose of nesting submodules in >> the first place. >> >>> 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 phil@juniper.net Tue Apr 2 12:34:37 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60DFF21F8E9E for ; Tue, 2 Apr 2013 12:34:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MZ1ofrpYrsXU for ; Tue, 2 Apr 2013 12:34:37 -0700 (PDT) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by ietfa.amsl.com (Postfix) with ESMTP id E3FBC21F8B35 for ; Tue, 2 Apr 2013 12:34:32 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKUVsyyGV6ZN2IQQKWNl4qZmOZ+Cl1r49p@postini.com; Tue, 02 Apr 2013 12:34:35 PDT Received: from merlot.juniper.net (172.17.27.10) by P-EMHUB02-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 2 Apr 2013 12:30:59 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id r32JVra95843; Tue, 2 Apr 2013 12:31:59 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.4/8.14.3) with ESMTP id r32JTpHn060530; Tue, 2 Apr 2013 15:30:07 -0400 (EDT) (envelope-from phil@idle.juniper.net) Message-ID: <201304021930.r32JTpHn060530@idle.juniper.net> To: Ladislav Lhotka In-Reply-To: Date: Tue, 2 Apr 2013 15:29:51 -0400 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] Fwd: New Version Notification for draft-lhotka-netmod-yang-json-01.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 19:34:37 -0000 Ladislav Lhotka writes: >this revision corrects several mistakes and adds an example for union type. Looks good. Three questions: Have you considered including an encoding for the attributes that YANG defines (insert/before/after/operation/etc.)? I don't see them mentioned in the draft at all. HAve you considered including a means of expressing namespace mappings? It's not clear if you are putting this mapping entirely outside of the draft, but it seems like a facility worth having. Can you add an example where one YANG modules augments another? I can't tell from your text what would happen. Actually, I can find nothing on augmentation in the draft. Thanks, Phil From lhotka@nic.cz Tue Apr 2 12:37:57 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 337D621F8EA9 for ; Tue, 2 Apr 2013 12:37:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.848 X-Spam-Level: X-Spam-Status: No, score=-1.848 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8pCn7sOd8KRM for ; Tue, 2 Apr 2013 12:37:56 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 1D12E21F8B35 for ; Tue, 2 Apr 2013 12:37:56 -0700 (PDT) Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id C5AD913FBD3; Tue, 2 Apr 2013 21:37:54 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1364931475; bh=QQYckjzAFZzaFpzRMiBI01+pgdgt4bkpZ8ymDNz8sQM=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=j9Jb9D5M0OC0F8bNImj7qc0qKOu0ZL7sbol7pzsZN898UUeA5hqRtl+IZV5d12/V7 gTh0z00mGAH5ASAtV92/Z6n10GWXN7iWLKh1hsTYghnFPTz6RTX6wrKVjIbEeG+FKe o51BAM9HHEIqA8H+jH0Ogr3YKlknrsQhgQsYSA8U= Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Ladislav Lhotka In-Reply-To: Date: Tue, 2 Apr 2013 21:37:54 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <9E101062-16E0-48A1-82CF-385D97FE1707@nic.cz> References: <20130222.161941.453515630.mbj@tail-f.com> <04E80624-7F7E-4265-BB89-C06F104B62E3@nic.cz> <20130222.172257.357766029.mbj@tail-f.com> <11D8A662-9EC4-4488-8345-CC01A9176A3C@nic.cz> <5155B2A8.8050104@mg-soft.com> <8A6EFB59-3B3D-45A9-B2E1-5CC7000716AD@nic.cz> To: Andy Bierman X-Mailer: Apple Mail (2.1503) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] include X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 19:37:57 -0000 On Apr 2, 2013, at 9:13 PM, Andy Bierman wrote: > On Tue, Apr 2, 2013 at 11:47 AM, Ladislav Lhotka = wrote: >>=20 >> On Apr 2, 2013, at 7:11 PM, Andy Bierman wrote: >>=20 >>> On Tue, Apr 2, 2013 at 2:49 AM, Ladislav Lhotka = wrote: >>>> Andy Bierman writes: >>>>=20 >>>>>=20 >>>>> The fact is, you cannot rely the information in the YANG modules = to >>>>> determine the set of files that were used to construct the schema = tree >>>>> in use by the server. >>>>>=20 >>>>> 1) module namspaces are assumed to be globally unique, not module = names. >>>>> Import "foo" does not reliably identify anything. The = URI >>>>> for the YANG module is needed to map namespace to module-name. >>>>=20 >>>> I think the message that module names should be kept unique is = quite clear. After all, even the uniqueness of URIs is not enforced and = works only as long as people follow the rules. >>>>=20 >>>=20 >>>=20 >>> It is quite clear from sec 7.1 that private module names are not = reliable. >>>=20 >>> 7.1 (para 2 & 3) >>>=20 >>> Names of modules published in RFC streams [RFC4844] MUST be = assigned >>> by IANA, see Section 14. >>>=20 >>> Private module names are assigned by the organization owning the >>> module without a central registry. It is RECOMMENDED to choose >>> module names that will have a low probability of colliding with >>> standard or other enterprise modules and submodules, e.g., by using >>> the enterprise or organization name as a prefix for the module = name. >>>=20 >>>=20 >>>>>=20 >>>>> 2) Since submodules are not advertised as YANG module = capabilities, >>>>> the cannot be used to map sub-module names to the >>>>> namespace-stmt value. >>>>=20 >>>> Yes, that's why it is important for the client to be able to find a = complete list of submodules in the main module. >>>=20 >>> This is a minor implementation detail. >>> The client can usually figure out the submodules to use >>> by following the include-chain. >>=20 >> There is no support for this include chain in 6020. >>=20 >=20 > The include chain is the conceptual dependency tree specified > by the include-stmts in the main module and each submodule > included by the main module or a submodule. >=20 > There has never been any support in YANG for > module search paths or other implementation-specific details > which would impact the YANG compiler's ability to > process an include-stmt. >=20 >=20 >>>=20 >>> I don't agree that submodules have their own namespace. >>=20 >> I don't think I have ever said this. >=20 > I thought this came up in the discussion of private submodules. >=20 >=20 >>=20 >>>=20 >>> The include-stmt is used to make a subset of all module symbols >>> available to that suibmodule. IMO this is rather pointless and >>> just adds extra complexity (like we are discussing right now). >>=20 >> I agree with this part, but sec. 7.1.6 also has this text: >>=20 >> When a module includes a submodule, it incorporates the contents of >> the submodule into the node hierarchy of the module. >=20 > IMO this means that all symbols included into the submodule > via include-stmts or import-stmts are available to the compiler > for resolving symbols. My understanding is this is only true for includes in submodules, see = the next sentence in 7.1.6: When a submodule includes another submodule, the target submodule's definitions are made available to the current submodule. The difference seems clear: - include in the main module incorporates submodule contents into the = node hierarchy, - include in a submodule makes definitions available. >=20 > Consider a simple nested example: >=20 > submod2 --> submod1 --> main >=20 > submod1 includes all of submod2 into its context, and > main includes all of submod1+submod2 into its context. >=20 > If this did not happen then groupings would not compile > correctly. I can use a grouping from submod1 in main. > That grouping can use a typedef from submod2. > That typedef is used in the main module even though > the typedef name is not referenced directly in the main module. >=20 > Having extra include-stmts in the main module for symbols > that are not referenced in the main module is just busy work > for the YANG designer. The compiler does not need > any extra includes to resolve a symbol. In my view, an include statement in the main module is equivalent to = having the submodule contents directly in the main module. Lada =20 >=20 >=20 > Andy >=20 >=20 >=20 >>=20 >> This means it is the include statement that pulls a submodule tree = into the module hierarchy. >>=20 >> IMO a sensible solution would be to require the main module to = include all submodules, and have belongs-to in submodules in order to = declare the prefix. That is, no includes in submodules, submodules could = automatically refer to top-level definitions in the main module and all = other submodules. >>=20 >> I suspect we may be in a violent agreement. :-) >>=20 >> Lada >>=20 >>>=20 >>> The "belongs-to" statement has the module prefix as >>> a sub-statement. Any symbol from the module being >>> compiled must use that prefix. Note that the include-stmt >>> does not have a prefix sub-statement. >>>=20 >>> The symbol resolution logic for the current design is not broken. >>> Each parent module or submodule MUST pull in all definitions >>> from its own included submodules to compile statements. >>> So saying that these symbols are not visible is incorrect. >>> All the submodules for the module are accounted for in the >>> dependency tree. >>>=20 >>> It is just an implementation detail how the compiler determines >>> that the requirements of sec 6.2.1 are met. The human writing >>> the YANG module does not need to add anything to the main >>> module. Listing all the submodules in the main module >>> defeats the whole purpose of nesting submodules in >>> the first place. >>>=20 >>>> Lada >>>=20 >>> Andy >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >>=20 >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C >>=20 >>=20 >>=20 >>=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From lhotka@nic.cz Tue Apr 2 13:19:56 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09DC321F8D35 for ; Tue, 2 Apr 2013 13:19:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.886 X-Spam-Level: X-Spam-Status: No, score=-1.886 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x2ciKFhTk90n for ; Tue, 2 Apr 2013 13:19:55 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 1548E21F8D28 for ; Tue, 2 Apr 2013 13:19:54 -0700 (PDT) Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 06AE913FBD3; Tue, 2 Apr 2013 22:19:54 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1364933994; bh=X/BYabmX8oslzW+qRs7YblTQpXWN61KDt728M0GGCb8=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=yN7GIeQG5tk8Vc2l/FQgP4TFN1ONkc90fENC1Jb+JKhpw+LD2eLUNHdpKhFoXHiS1 DHGlt16F56x+KW3nAnFX70HGdwcczNJmCR7ybNe988ek/QqbgAIiOkbSua3qOb5avi C7LuG/wXy8Ltk2e9eRWgXoomIo0nvahXJLZdOjwY= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Ladislav Lhotka In-Reply-To: <201304021930.r32JTpHn060530@idle.juniper.net> Date: Tue, 2 Apr 2013 22:19:54 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201304021930.r32JTpHn060530@idle.juniper.net> To: Phil Shafer X-Mailer: Apple Mail (2.1503) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] Fwd: New Version Notification for draft-lhotka-netmod-yang-json-01.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 20:19:56 -0000 On Apr 2, 2013, at 9:29 PM, Phil Shafer wrote: > Ladislav Lhotka writes: >> this revision corrects several mistakes and adds an example for union = type. >=20 > Looks good. Three questions: >=20 > Have you considered including an encoding for the attributes=20 > that YANG defines (insert/before/after/operation/etc.)? I > don't see them mentioned in the draft at all. I decided to stay away from attributes, for two reasons: 1. I don't know how to encode the binding between such an attribute and = the data node (especially leaf) to which it belongs, because in JSON = they would have to be siblings, and there might be other sibling leaves. 2. APIs that are based on HTTP methods, as well as e.g. JSON Patch, = don't really need these attributes. >=20 > HAve you considered including a means of expressing namespace > mappings? It's not clear if you are putting this mapping entirely > outside of the draft, but it seems like a facility worth having. I think section 3.1 defines this mapping and the encoding of an explicit = namespace id: : >=20 > Can you add an example where one YANG modules augments another? > I can't tell from your text what would happen. Actually, I can > find nothing on augmentation in the draft. The mapping is between instance documents, so augments are not special, = except that they may lead to local name collisions where explicit namespace ids are = required. But if the local name is unambiguous, the : prefix is = not required, even for augmented nodes. Lada >=20 > Thanks, > Phil -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From mbj@tail-f.com Tue Apr 2 14:01:52 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FD4B21F8A7E for ; Tue, 2 Apr 2013 14:01:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.117 X-Spam-Level: X-Spam-Status: No, score=-1.117 tagged_above=-999 required=5 tests=[AWL=0.929, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XCsqTiPZ3gws for ; Tue, 2 Apr 2013 14:01:51 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 2CC8E21F8A68 for ; Tue, 2 Apr 2013 14:01:50 -0700 (PDT) Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 77C521200D5E; Tue, 2 Apr 2013 23:01:49 +0200 (CEST) Date: Tue, 02 Apr 2013 23:01:49 +0200 (CEST) Message-Id: <20130402.230149.92811084.mbj@tail-f.com> To: bclaise@cisco.com From: Martin Bjorklund In-Reply-To: <5150CF8E.8090006@cisco.com> References: <5150CF8E.8090006@cisco.com> X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] AD review of draft-ietf-netmod-interfaces-cfg-09 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 21:01:52 -0000 Hi, Benoit Claise wrote: > Dear all, > > Disclaimer: > - If any of those points have been discussed on the mailing list, don't > - hesitate to let me know. > - I probably should have mentioned some of these documents during the last > - call. Sorry. After a year in the new position, I'm still playing catch up > - mode. > > _CLARIFYING QUE__STION__S_ > > - Section 3.1 The interface List > > The data model for interfaces presented in this document uses a flat > list of interfaces. Each interface in the list is identified by its > name. Furthermore, each interface has a mandatory "type" leaf, and a > "location" leaf. The combination of "type" and "location" is unique > within the interface list. > > First time I read this, I thought the location was mandatory. > However, it's not: > > +--rw interfaces > +--rw interface [name] > +--rw name string > +--rw description? string > +--rw type ianaift:iana-if-type > +--rw location? string > > Proposal: > OLD: > > Furthermore, each interface has a mandatory "type" leaf, and a > "location" leaf. > > NEW: > Furthermore, each interface has a mandatory "type" leaf, and an optional > "location" leaf. Ok, will fix. > When I understood that the location is optional, I have some difficulties to > understand the following sentence > "The combination of "type" and "location" is unique within the interface list." > when the location is an optional field. > > - How does the mechanism above apply to subinterfaces? example: Interface > Ethernet 0.1? > > I believe it deserves some explanation. Now, it's true that the RFC 2863 > doesn't mention the notion of subinterface, and I believe that the notion of > sub-layer (in RFC 2863) and interface layering (in > draft-ietf-netmod-interfaces-cfg) notions don't apply to subinterfaces? I would > be happy to stand corrected. It all depends what you put in your definition of a subinterface. This document does not mention subinterfaces at all. It just talks about how interfaces are layered. > For example, how should I understand the following sentence, if we speak about > an subinterface > > The "location" leaf is a string. It is optional in the data model, > but if the type represents a physical interface, it is mandatory. > > Does the subinterface really _represent _a physical interface? If you have your subinterface represent a vlan, it would not. In this case, the subinterface would be layered on top of another (physical maybe) interface. > The "if-index" leaf contains the value of the corresponding ifEntry's ifIndex. > > Shouldn't we stress this sentence with a MUST? Ok, fixed. > Let's face it, we still have many MIB modules for monitoring. We can use > NETCONF/YANG for interface management, but we need the link to the ifIndex, to > access the corresponding entries in the existing MIB modules Agreed. This is why this leaf is there :) > - One of the real pain point of RFC 2863 is the ifIndex non persistence. > > "Its value ranges between 1 and the value of ifNumber. The > value for each interface must remain constant at least from > one re-initialization of the entity's network management > system to the next re-initialization." > > > Can we assume that the leaf name will remain constant after a > "re-initialization of the entity's network management system", and that only > the leaf if-index could change. Yes! With NETCONF/YANG, the config is persistently stored (which config depends on the capabilities). > Or we can't assume anything, and the NMS must rediscover everything. So same > pain point as SNMP? > Or should the NMS compare the config (which contains the ifName/leaf-name), and > if they're unchanged after a reboot, the NMS just have query leaf if-index for > the mapping to the MIB module? > Could/should we say a few words about this in the draft? I guess we could say that the if-index value may change, but in general I am not too fond of redundant specifications in new documents... I don't want to spell out all the semantics of ifIndex. Maybe something like this: Note that the ifIndex value for a particular interface may change if the entity's network management system is re-initialized. But I am not sure if this is what you meant? > _EDITORIAL:_ > > - Section 2 > > o It is recognized that existing implementations will have to map > the interface data model defined in this memo to their proprietary > native data model. The new data model should be simple to > facilitate such mappings. > > What does new refer to? The YANG module in this document, or the extensions, > referred by the text seen in the introduction > > It is expected that interface type specific > data models augment the generic interfaces data model defined in this > document. > > I guess the YANG module in this document. So removing "new" would solve the > confusion. Ok, will fix. > - You might to stress in the section 4 that the non HC counters are not > - modeled. > > | in-octets | ifHCInOctets | > | in-unicast-pkts | ifHCInUcastPkts | > | in-broadcast-pkts | ifHCInBroadcastPkts | > | in-multicast-pkts | ifHCInMulticastPkts | > > Btw, could this be a problem for sensors? 64 vs 32 bit counters were discussed in the thread starting at http://www.ietf.org/mail-archive/web/netmod/current/msg06943.html. > leaf last-change { > type yang:date-and-time; > config false; > description > "The time the interface entered its current operational > state. If the current state was entered prior to the > last re-initialization of the local network management > subsystem, then this node is not present."; > reference > "RFC 2863 : The Interfaces > Group MIB - ifLastChange"; > } > > From the date-and-time definition in RFC 6021, do I understand correctly that > the date-and-time are absolute time (and not the equivalent of the sysUpTime, > as mentioned in ifLastChange). > What if the device doesn't have any absolute time, but simply the sysUpTime? > Same question for leaf discontinuity-time I think this was also discussed in the thread above. It was suggested that even smaller devices (that still implement NETCONF and these data models) have support for absolute times these days. > - I discovered the following feature in the YANG module > > feature arbitrary-names { > description > "This feature indicates that the server allows interfaces to > be named arbitrarily."; > } > > The only information I can find is > > If the device allows arbitrarily named interfaces, the > feature 'arbitrary-names' is advertised. > This leaf MAY be mapped to ifName by an implementation. > Such an implementation MAY restrict the allowed values for > this leaf so that it matches the restrictions of ifName. > > As an implementor, I don't have much idea what is meant by this > 'arbitrary-names' feature. Some explanatory text outside of the YANG module > would be welcome. > Note: it's only when I read the appendix E that I finally got the information I > was after. Not sure why this is in the appendix... Up to you. > At least, I would make it clear in which of the E.X examples, the "feature > arbitrary-names" is advertised. I guess, from the title, E2 and E5 Ok, done. /martin From andy@yumaworks.com Fri Apr 5 09:03:03 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2ACE21F9836 for ; Fri, 5 Apr 2013 09:03:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.578 X-Spam-Level: X-Spam-Status: No, score=-1.578 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_23=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wrGrBF-z4FxE for ; Fri, 5 Apr 2013 09:03:03 -0700 (PDT) Received: from mail-ie0-x22e.google.com (mail-ie0-x22e.google.com [IPv6:2607:f8b0:4001:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id D2FB621F9833 for ; Fri, 5 Apr 2013 09:03:02 -0700 (PDT) Received: by mail-ie0-f174.google.com with SMTP id aq17so4530350iec.33 for ; Fri, 05 Apr 2013 09:02:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=PCHqGM71VV+bYjrdpcx2i9FCHpvHyPm3KNRR2Fk3Kro=; b=ohe8mMmEEYbBY1mgp7nwyMsceDVjmnSXKuRAU1W/W7ewfoTnUL5Q+QmK5kxu4jsfmg HY5g8tSJL4VURiUJuSvuQffYSTnwBW/ZFPzdrN/COpVARO2MuaWdNBMTYw/HwzMt0LgS bLukDbY+M+Ff6Wl5fw2LKb7xCbJqHCyTXD7sSs4VhIy7JaMV83y9EHaENdkNwvd1GYe8 AF5IKIaUMNtaMY5LJIZej/1sO4a72UpndFkHG5FJwX3is+TLylZW1uhj20kOCaOx3XT8 l0ie9VYi1aMnbLKwUE3EQ1krtDUxY9QUbOptqiOS2FvYP/bhZhPzLH3Xu8MmJHI9cwL8 hR9A== MIME-Version: 1.0 X-Received: by 10.50.187.225 with SMTP id fv1mr2044331igc.74.1365177778497; Fri, 05 Apr 2013 09:02:58 -0700 (PDT) Received: by 10.231.71.198 with HTTP; Fri, 5 Apr 2013 09:02:58 -0700 (PDT) In-Reply-To: References: <20130402171911.7591.53906.idtracker@ietfa.amsl.com> Date: Fri, 5 Apr 2013 09:02:58 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQkxhsxCUiMwWVToBT+T6prvQf83KVLLpVLHuqPwR2neY9IXb0RcG7Mza+p0uTSASqLlOIsb Cc: netmod@ietf.org Subject: Re: [netmod] Fwd: New Version Notification for draft-lhotka-netmod-yang-json-01.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Apr 2013 16:03:04 -0000 Hi, I have implemented the JSON-00 draft for YANG-API, and have some issues that should be addressed. 3.1, para 4: The namespace identifier MUST be used for local names that are ambiguous, i.e., whenever the data model permits a sibling node with the same local name. Otherwise, the namespace identifier is OPTIONAL. The term "the data model" is unclear. The module name needs to be used within a protocol only if the server advertises YANG modules that have duplicate sibling local-names. 3.1, para 5: When mapping namespaces from JSON text to XML, the resulting XML document may use default namespace declarations (via the "xmlns" attribute), prefix-based namespace declarations (via attributes beginning with "xmlns:"), or any combination thereof, following the rules stated in [XMLNS]. If prefixed names are used, their prefix SHOULD be the one defined by the "prefix" statement in the YANG module where each data node is defined. This draft has no business re-defining XML 1.0, which says how to encode extended-names. This paragraph should be removed. 3.2 Mapping XML Elements to JSON Objects para 1, bullets 1 - 4: o An XML element that is modeled as YANG leaf is translated to a name/value pair and the JSON datatype of the value is derived from the YANG datatype of the leaf (see Section 3.3 for the datatype mapping rules). o An XML element that is modeled as YANG container is translated to a JSON object. o A sequence of one or more sibling XML elements with the same qualified name that is modeled as YANG leaf-list is translated to a name/array pair, and the array elements are primitive values whose type depends on the datatype of the leaf-list (see Section 3.3). o A sequence of one or more sibling XML elements with the same qualified name that is modeled as YANG list is translated to a name/array pair, and the array elements are JSON objects. All 4 bullets mix XML encoding with the YANG construct they represent. This does not really work if a node-set is returned by the protocol: GET http://localhost/yang-api/datastore/interfaces/interface?select=name returns: { "data": { "name": [ "eth0", "lo" ] } } Even though 'name' is a leaf, since the client requested all the interface names (eth0 and lo), they are returned as a leaf-list. if "select=counters" were used then an array of JSON objects would be returned (1 per 'counters' container). Bullet 3 & 4: I do not agree that arrays MUST be used if only one leaf-list or list entry is present. The translator MAY use an array but not MUST or SHOULD. The main reason for using JSON is to get more efficient encoding than XML. Sec. 3.5 IANA Considerations It would really help out my code if this encoding was registered with IANA (MIME type? application/json-yang?) That way a protocol could identify the encoding types it supports somehow, and auto-negotiate the one(s) to use. These are the only implementation issues I had (so far). Andy On Tue, Apr 2, 2013 at 10:21 AM, Ladislav Lhotka wrote: > Hi, > > this revision corrects several mistakes and adds an example for union type. > > Lada > > Begin forwarded message: > >> From: internet-drafts@ietf.org >> Subject: New Version Notification for draft-lhotka-netmod-yang-json-01.txt >> Date: April 2, 2013 7:19:11 PM GMT+02:00 >> To: lhotka@nic.cz >> >> >> A new version of I-D, draft-lhotka-netmod-yang-json-01.txt >> has been successfully submitted by Ladislav Lhotka and posted to the >> IETF repository. >> >> Filename: draft-lhotka-netmod-yang-json >> Revision: 01 >> Title: Modeling JSON Text with YANG >> Creation date: 2013-04-02 >> Group: Individual Submission >> Number of pages: 14 >> URL: http://www.ietf.org/internet-drafts/draft-lhotka-netmod-yang-json-01.txt >> Status: http://datatracker.ietf.org/doc/draft-lhotka-netmod-yang-json >> Htmlized: http://tools.ietf.org/html/draft-lhotka-netmod-yang-json-01 >> Diff: http://www.ietf.org/rfcdiff?url2=draft-lhotka-netmod-yang-json-01 >> >> Abstract: >> This document defines rules for mapping data models expressed in YANG >> to configuration and operational state data encoded as JSON text. It >> does so by specifying a procedure for translating the subset of YANG- >> compatible XML documents to JSON text, and vice versa. >> >> >> >> >> The IETF Secretariat >> > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From lhotka@nic.cz Fri Apr 5 10:10:13 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44E6121F97EB for ; Fri, 5 Apr 2013 10:10:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.457 X-Spam-Level: X-Spam-Status: No, score=-1.457 tagged_above=-999 required=5 tests=[AWL=-0.362, BAYES_00=-2.599, HOST_EQ_CZ=0.904, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GDHSF2WbaS-R for ; Fri, 5 Apr 2013 10:10:12 -0700 (PDT) Received: from trail.lhotka.name (nat-5.bravonet.cz [77.48.224.5]) by ietfa.amsl.com (Postfix) with ESMTP id 273E721F97C5 for ; Fri, 5 Apr 2013 10:10:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id DC20C540165 for ; Fri, 5 Apr 2013 19:10:00 +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 GYgQFhrOVLlk for ; Fri, 5 Apr 2013 19:09:51 +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 83E5754014A for ; Fri, 5 Apr 2013 19:09:46 +0200 (CEST) From: Ladislav Lhotka To: netmod@ietf.org In-Reply-To: References: <20130402171911.7591.53906.idtracker@ietfa.amsl.com> User-Agent: Notmuch/0.15.2+56~gf55b35b (http://notmuchmail.org) Emacs/23.3.50.1 (i386-apple-darwin9.8.0) Mail-Followup-To: netmod@ietf.org Date: Fri, 05 Apr 2013 19:09:45 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [netmod] Fwd: New Version Notification for draft-lhotka-netmod-yang-json-01.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Apr 2013 17:10:13 -0000 Andy Bierman writes: > Hi, > > I have implemented the JSON-00 draft for YANG-API, and have Thanks, I also have a few comments regarding YANG-API, I just have to write them down and send. > some issues that should be addressed. > > 3.1, para 4: > > The namespace identifier MUST be used for local names that are > ambiguous, i.e., whenever the data model permits a sibling node with > the same local name. Otherwise, the namespace identifier is > OPTIONAL. > > The term "the data model" is unclear. > The module name needs to be used within a protocol > only if the server advertises YANG modules that have > duplicate sibling local-names. Yes, that's essentially what "data model" means, but I didn't want to limit the mapping to the specific NETCONF context. What one has to know is the complete set of modules, features that are considered active etc. On the other hand, it is true that the hello message provides a very compact way for encoding all this info, so that's why pyangs accepts a hello message as the data model specification. So maybe a definition of "data model" along these lines would be appropriate in the terminology section. > > 3.1, para 5: > > When mapping namespaces from JSON text to XML, the resulting XML > document may use default namespace declarations (via the "xmlns" > attribute), prefix-based namespace declarations (via attributes > beginning with "xmlns:"), or any combination thereof, following the > rules stated in [XMLNS]. If prefixed names are used, their prefix > SHOULD be the one defined by the "prefix" statement in the YANG > module where each data node is defined. > > This draft has no business re-defining XML 1.0, > which says how to encode extended-names. > This paragraph should be removed. This was supposed to mean: An implementation is free to use the default namespace (i.e., no prefix), but *if* it uses a non-default namespace for any part of the data tree, the prefix SHOULD be the one from the YANG module. > > 3.2 Mapping XML Elements to JSON Objects > > para 1, bullets 1 - 4: > > o An XML element that is modeled as YANG leaf is translated to a > name/value pair and the JSON datatype of the value is derived from > the YANG datatype of the leaf (see Section 3.3 for the datatype > mapping rules). > > o An XML element that is modeled as YANG container is translated to > a JSON object. > > o A sequence of one or more sibling XML elements with the same > qualified name that is modeled as YANG leaf-list is translated to > a name/array pair, and the array elements are primitive values > whose type depends on the datatype of the leaf-list (see > Section 3.3). > > o A sequence of one or more sibling XML elements with the same > qualified name that is modeled as YANG list is translated to a > name/array pair, and the array elements are JSON objects. > > All 4 bullets mix XML encoding with the YANG construct they I don't think so. We are mapping instance documents, but the way how individidual elements are mapped depends on the data model. > represent. This does not really work if a node-set is returned > by the protocol: > > GET http://localhost/yang-api/datastore/interfaces/interface?select=name > > returns: > > { > "data": { > "name": [ > "eth0", > "lo" > ] > } > } > > Even though 'name' is a leaf, since the client requested all > the interface names (eth0 and lo), they are returned as a > leaf-list. if "select=counters" were used then an array > of JSON objects would be returned (1 per 'counters' container). But this cherry-picking breaks the data model schema, so it is outside of this document's scope. > > Bullet 3 & 4: > I do not agree that arrays MUST be used if only one > leaf-list or list entry is present. The translator MAY > use an array but not MUST or SHOULD. > The main reason for using JSON > is to get more efficient encoding than XML. I disagree, I think it is actually quite useful to be able to encode even single-entry lists as arrays. Consider JSON Pointer. If we have container foo { leaf-list bar { type uint8; } } then it is IMO easier to handle if "/foo/bar" always returns an array, and "/foo/bar/0" never results in an error, which would be the case if it was used on { "foo": { "bar": 1 }} And you can predict the behaviour just from the data model, without peeking at the instance document. > > Sec. 3.5 IANA Considerations > > It would really help out my code if this encoding was > registered with IANA (MIME type? application/json-yang?) I know there have been flamewars about "media type explosion", but I see no dilemma here because in fact the contents can be *any* JSON text. I don't think the mere fact that there is some data model behind it warrants a new media type. > > That way a protocol could identify the encoding types it > supports somehow, and auto-negotiate the one(s) to use. But there is no special encoding, is it? Lada > > > These are the only implementation issues I had (so far). > > > Andy > > > On Tue, Apr 2, 2013 at 10:21 AM, Ladislav Lhotka wrote: >> Hi, >> >> this revision corrects several mistakes and adds an example for union type. >> >> Lada >> >> Begin forwarded message: >> >>> From: internet-drafts@ietf.org >>> Subject: New Version Notification for draft-lhotka-netmod-yang-json-01.txt >>> Date: April 2, 2013 7:19:11 PM GMT+02:00 >>> To: lhotka@nic.cz >>> >>> >>> A new version of I-D, draft-lhotka-netmod-yang-json-01.txt >>> has been successfully submitted by Ladislav Lhotka and posted to the >>> IETF repository. >>> >>> Filename: draft-lhotka-netmod-yang-json >>> Revision: 01 >>> Title: Modeling JSON Text with YANG >>> Creation date: 2013-04-02 >>> Group: Individual Submission >>> Number of pages: 14 >>> URL: http://www.ietf.org/internet-drafts/draft-lhotka-netmod-yang-json-01.txt >>> Status: http://datatracker.ietf.org/doc/draft-lhotka-netmod-yang-json >>> Htmlized: http://tools.ietf.org/html/draft-lhotka-netmod-yang-json-01 >>> Diff: http://www.ietf.org/rfcdiff?url2=draft-lhotka-netmod-yang-json-01 >>> >>> Abstract: >>> This document defines rules for mapping data models expressed in YANG >>> to configuration and operational state data encoded as JSON text. It >>> does so by specifying a procedure for translating the subset of YANG- >>> compatible XML documents to JSON text, and vice versa. >>> >>> >>> >>> >>> The IETF Secretariat >>> >> >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C >> >> >> >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From andy@yumaworks.com Fri Apr 5 10:26:31 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D6BC21F9845 for ; Fri, 5 Apr 2013 10:26:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.528 X-Spam-Level: X-Spam-Status: No, score=-1.528 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_23=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mIAvkUDZYTz7 for ; Fri, 5 Apr 2013 10:26:30 -0700 (PDT) Received: from mail-ia0-x22f.google.com (mail-ia0-x22f.google.com [IPv6:2607:f8b0:4001:c02::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 3AD5521F983F for ; Fri, 5 Apr 2013 10:26:30 -0700 (PDT) Received: by mail-ia0-f175.google.com with SMTP id e16so3324874iaa.6 for ; Fri, 05 Apr 2013 10:26:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type:content-transfer-encoding :x-gm-message-state; bh=mTRsjyz/jsD2XY7aq5lAjdiV+3IU7ht5OL13zMVazP0=; b=Zv9bvqMcbXQf0agXC4w20xsHjXGw2ct1gAs4xRI+D3ctbRkmr4ePybfR/BGSGNDENi /xFzcNww230hCBlwLBGYRJHTGNR1PBSOk30g69qED2Qssf9wHhYZuS7y9JL7tBdmvJto RC80xnxzdGLWJMJbzGUNBZn6xNku6/opGs88gNxO3ShPZGUtBFmiXm+n2XwLJwV1lDYX 7jcpuEeyQYwBmc3+3j2Cv2MQq99xWDxU1QmzafwrK/l9a6y4i6QT8KWIGUi/jXo0rkyh tjNUNWXeUeTjfgnY37Uwh9xbU2GiCXz552LRpYVTMY38WOOAYgqizGWU/EQrLVCQKyKr oyHw== MIME-Version: 1.0 X-Received: by 10.50.53.180 with SMTP id c20mr62248igp.15.1365182789575; Fri, 05 Apr 2013 10:26:29 -0700 (PDT) Received: by 10.231.71.198 with HTTP; Fri, 5 Apr 2013 10:26:29 -0700 (PDT) In-Reply-To: References: <20130402171911.7591.53906.idtracker@ietfa.amsl.com> Date: Fri, 5 Apr 2013 10:26:29 -0700 Message-ID: From: Andy Bierman To: netmod@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQm4dN8x4Vo40cokiyRTnRJMKcbzqRC1QWdnnJGG09TEBU4kFehK5J0V/qy0EMPUrLu6uFKL Subject: Re: [netmod] Fwd: New Version Notification for draft-lhotka-netmod-yang-json-01.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Apr 2013 17:26:31 -0000 On Fri, Apr 5, 2013 at 10:09 AM, Ladislav Lhotka wrote: > Andy Bierman writes: > >> Hi, >> >> I have implemented the JSON-00 draft for YANG-API, and have > > Thanks, I also have a few comments regarding YANG-API, I just have to wri= te them down and send. > >> some issues that should be addressed. >> >> 3.1, para 4: >> >> The namespace identifier MUST be used for local names that are >> ambiguous, i.e., whenever the data model permits a sibling node with >> the same local name. Otherwise, the namespace identifier is >> OPTIONAL. >> >> The term "the data model" is unclear. >> The module name needs to be used within a protocol >> only if the server advertises YANG modules that have >> duplicate sibling local-names. > > Yes, that's essentially what "data model" means, but I didn't want to lim= it the mapping to the specific NETCONF context. What one has to know is the= complete set of modules, features that are considered active etc. On the o= ther hand, it is true that the hello message provides a very compact way fo= r encoding all this info, so that's why pyangs accepts a hello message as t= he data model specification. > > So maybe a definition of "data model" along these lines would be appropri= ate in the terminology section. > >> >> 3.1, para 5: >> >> When mapping namespaces from JSON text to XML, the resulting XML >> document may use default namespace declarations (via the "xmlns" >> attribute), prefix-based namespace declarations (via attributes >> beginning with "xmlns:"), or any combination thereof, following the >> rules stated in [XMLNS]. If prefixed names are used, their prefix >> SHOULD be the one defined by the "prefix" statement in the YANG >> module where each data node is defined. >> >> This draft has no business re-defining XML 1.0, >> which says how to encode extended-names. >> This paragraph should be removed. > > This was supposed to mean: An implementation is free to use the default n= amespace (i.e., no prefix), but *if* it uses a non-default namespace for an= y part of the data tree, the prefix SHOULD be the one from the YANG module. > What difference does it make what prefix is used? It makes none at all to XML, since an 'xmlns' attribute MUST be present for whatever prefix is used. This is a CLR that has no purpose in XML. >> >> 3.2 Mapping XML Elements to JSON Objects >> >> para 1, bullets 1 - 4: >> >> o An XML element that is modeled as YANG leaf is translated to a >> name/value pair and the JSON datatype of the value is derived from >> the YANG datatype of the leaf (see Section 3.3 for the datatype >> mapping rules). >> >> o An XML element that is modeled as YANG container is translated to >> a JSON object. >> >> o A sequence of one or more sibling XML elements with the same >> qualified name that is modeled as YANG leaf-list is translated to >> a name/array pair, and the array elements are primitive values >> whose type depends on the datatype of the leaf-list (see >> Section 3.3). >> >> o A sequence of one or more sibling XML elements with the same >> qualified name that is modeled as YANG list is translated to a >> name/array pair, and the array elements are JSON objects. >> >> All 4 bullets mix XML encoding with the YANG construct they > > I don't think so. We are mapping instance documents, but the way how indi= vididual elements are mapped depends on the data model. > >> represent. This does not really work if a node-set is returned >> by the protocol: >> >> GET http://localhost/yang-api/datastore/interfaces/interface?select=3Dna= me >> >> returns: >> >> { >> "data": { >> "name": [ >> "eth0", >> "lo" >> ] >> } >> } >> >> Even though 'name' is a leaf, since the client requested all >> the interface names (eth0 and lo), they are returned as a >> leaf-list. if "select=3Dcounters" were used then an array >> of JSON objects would be returned (1 per 'counters' container). > > But this cherry-picking breaks the data model schema, so it is outside of= this document's scope. > The 'data' node is 'anyxml'. The bullets above should account for XML elements which represent YANG anyxml. >> >> Bullet 3 & 4: >> I do not agree that arrays MUST be used if only one >> leaf-list or list entry is present. The translator MAY >> use an array but not MUST or SHOULD. >> The main reason for using JSON >> is to get more efficient encoding than XML. > > I disagree, I think it is actually quite useful to be able to encode even= single-entry lists as arrays. Consider JSON Pointer. If we have > > container foo { > leaf-list bar { > type uint8; > } > } > > then it is IMO easier to handle if "/foo/bar" always returns an array, an= d "/foo/bar/0" never results in an error, which would be the case if it was= used on > > { "foo": { "bar": 1 }} > I don't see any added value -- the parser has to accept any of the valid formats so the code will not prefer 1 form over another. It will just parse what is there. > And you can predict the behaviour just from the data model, without peeki= ng at the instance document. > >> >> Sec. 3.5 IANA Considerations >> >> It would really help out my code if this encoding was >> registered with IANA (MIME type? application/json-yang?) > > I know there have been flamewars about "media type explosion", but I see = no dilemma here because in fact the contents can be *any* JSON text. I don'= t think the mere fact that there is some data model behind it warrants a ne= w media type. > Obviously I can make up my own URIs, but doesn't this count as a media type? It could be application/json I suppose. >> >> That way a protocol could identify the encoding types it >> supports somehow, and auto-negotiate the one(s) to use. > > But there is no special encoding, is it? > The module names and identityrefs, etc. have extra semantics encoded into the value part. > Lada > Andy >> >> >> These are the only implementation issues I had (so far). >> >> >> Andy >> >> >> On Tue, Apr 2, 2013 at 10:21 AM, Ladislav Lhotka wrote: >>> Hi, >>> >>> this revision corrects several mistakes and adds an example for union t= ype. >>> >>> Lada >>> >>> Begin forwarded message: >>> >>>> From: internet-drafts@ietf.org >>>> Subject: New Version Notification for draft-lhotka-netmod-yang-json-01= .txt >>>> Date: April 2, 2013 7:19:11 PM GMT+02:00 >>>> To: lhotka@nic.cz >>>> >>>> >>>> A new version of I-D, draft-lhotka-netmod-yang-json-01.txt >>>> has been successfully submitted by Ladislav Lhotka and posted to the >>>> IETF repository. >>>> >>>> Filename: draft-lhotka-netmod-yang-json >>>> Revision: 01 >>>> Title: Modeling JSON Text with YANG >>>> Creation date: 2013-04-02 >>>> Group: Individual Submission >>>> Number of pages: 14 >>>> URL: http://www.ietf.org/internet-drafts/draft-lhotka-netm= od-yang-json-01.txt >>>> Status: http://datatracker.ietf.org/doc/draft-lhotka-netmod-y= ang-json >>>> Htmlized: http://tools.ietf.org/html/draft-lhotka-netmod-yang-j= son-01 >>>> Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-lhotka-netmo= d-yang-json-01 >>>> >>>> Abstract: >>>> This document defines rules for mapping data models expressed in YAN= G >>>> to configuration and operational state data encoded as JSON text. I= t >>>> does so by specifying a procedure for translating the subset of YANG= - >>>> compatible XML documents to JSON text, and vice versa. >>>> >>>> >>>> >>>> >>>> The IETF Secretariat >>>> >>> >>> -- >>> Ladislav Lhotka, CZ.NIC Labs >>> PGP Key ID: E74E8C0C >>> >>> >>> >>> >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From lhotka@nic.cz Fri Apr 5 11:22:05 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 888F921F9897 for ; Fri, 5 Apr 2013 11:22:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.848 X-Spam-Level: X-Spam-Status: No, score=-1.848 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i120s091M1Wr for ; Fri, 5 Apr 2013 11:22:04 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 226B621F9899 for ; Fri, 5 Apr 2013 11:22: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 487C913F8B5; Fri, 5 Apr 2013 20:22:03 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1365186123; bh=doxjmQYwkjjLtLRTuOW+wAgxlVYSDgoTkQnNdZDGwR8=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=ZLY9Y1mR6rC0Y0jOY3UQtdVk9141qPibHd+RM9THKewYbJu04gC2NzbrRXxbI20KZ n6geXPIXnwF9rZ8SVW/v12F305OGJ4podHuOb50aj8ozudKiK/3AWvyeOjHpljTzro S/bX/+Zs6EDVTHrLCSbyDsq4ARrhJh9brYGpx+Sc= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Ladislav Lhotka In-Reply-To: Date: Fri, 5 Apr 2013 20:21:58 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130402171911.7591.53906.idtracker@ietfa.amsl.com> To: Andy Bierman X-Mailer: Apple Mail (2.1503) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] Fwd: New Version Notification for draft-lhotka-netmod-yang-json-01.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Apr 2013 18:22:05 -0000 On Apr 5, 2013, at 7:26 PM, Andy Bierman wrote: ... >>>=20 >>> 3.1, para 5: >>>=20 >>> When mapping namespaces from JSON text to XML, the resulting XML >>> document may use default namespace declarations (via the "xmlns" >>> attribute), prefix-based namespace declarations (via attributes >>> beginning with "xmlns:"), or any combination thereof, following = the >>> rules stated in [XMLNS]. If prefixed names are used, their prefix >>> SHOULD be the one defined by the "prefix" statement in the YANG >>> module where each data node is defined. >>>=20 >>> This draft has no business re-defining XML 1.0, >>> which says how to encode extended-names. >>> This paragraph should be removed. >>=20 >> This was supposed to mean: An implementation is free to use the = default namespace (i.e., no prefix), but *if* it uses a non-default = namespace for any part of the data tree, the prefix SHOULD be the one = from the YANG module. >>=20 >=20 > What difference does it make what prefix is used? > It makes none at all to XML, since an 'xmlns' attribute > MUST be present for whatever prefix is used. > This is a CLR that has no purpose in XML. In fact, I agree with you, but the same rule is in RFC 6020, sec. 7.1.4, = second paragraph. I just followed the suit. >=20 >=20 >>>=20 >>> 3.2 Mapping XML Elements to JSON Objects >>>=20 >>> para 1, bullets 1 - 4: >>>=20 >>> o An XML element that is modeled as YANG leaf is translated to a >>> name/value pair and the JSON datatype of the value is derived = from >>> the YANG datatype of the leaf (see Section 3.3 for the datatype >>> mapping rules). >>>=20 >>> o An XML element that is modeled as YANG container is translated = to >>> a JSON object. >>>=20 >>> o A sequence of one or more sibling XML elements with the same >>> qualified name that is modeled as YANG leaf-list is translated = to >>> a name/array pair, and the array elements are primitive values >>> whose type depends on the datatype of the leaf-list (see >>> Section 3.3). >>>=20 >>> o A sequence of one or more sibling XML elements with the same >>> qualified name that is modeled as YANG list is translated to a >>> name/array pair, and the array elements are JSON objects. >>>=20 >>> All 4 bullets mix XML encoding with the YANG construct they >>=20 >> I don't think so. We are mapping instance documents, but the way how = individidual elements are mapped depends on the data model. >>=20 >>> represent. This does not really work if a node-set is returned >>> by the protocol: >>>=20 >>> GET = http://localhost/yang-api/datastore/interfaces/interface?select=3Dname >>>=20 >>> returns: >>>=20 >>> { >>> "data": { >>> "name": [ >>> "eth0", >>> "lo" >>> ] >>> } >>> } >>>=20 >>> Even though 'name' is a leaf, since the client requested all >>> the interface names (eth0 and lo), they are returned as a >>> leaf-list. if "select=3Dcounters" were used then an array >>> of JSON objects would be returned (1 per 'counters' container). >>=20 >> But this cherry-picking breaks the data model schema, so it is = outside of this document's scope. >>=20 >=20 > The 'data' node is 'anyxml'. Right, but this anyxml has nothing to do with the ietf-interfaces = module. > The bullets above should account for XML elements > which represent YANG anyxml. >=20 >=20 >>>=20 >>> Bullet 3 & 4: >>> I do not agree that arrays MUST be used if only one >>> leaf-list or list entry is present. The translator MAY >>> use an array but not MUST or SHOULD. >>> The main reason for using JSON >>> is to get more efficient encoding than XML. >>=20 >> I disagree, I think it is actually quite useful to be able to encode = even single-entry lists as arrays. Consider JSON Pointer. If we have >>=20 >> container foo { >> leaf-list bar { >> type uint8; >> } >> } >>=20 >> then it is IMO easier to handle if "/foo/bar" always returns an = array, and "/foo/bar/0" never results in an error, which would be the = case if it was used on >>=20 >> { "foo": { "bar": 1 }} >>=20 >=20 > I don't see any added value -- the parser has to accept any > of the valid formats so the code will not prefer 1 form over another. > It will just parse what is there. For example, if I want append a new entry (say 3) at the end, I can = always use this JSON Patch operation: { "op": "add", "path": "/foo/bar/-", "value": 3 } It works fine for both {"foo": {"bar": [1, 2]}} and {"foo": {"bar": = [1]}}, but fails for {"foo": {"bar": 1}}. >=20 >> And you can predict the behaviour just from the data model, without = peeking at the instance document. >>=20 >>>=20 >>> Sec. 3.5 IANA Considerations >>>=20 >>> It would really help out my code if this encoding was >>> registered with IANA (MIME type? application/json-yang?) >>=20 >> I know there have been flamewars about "media type explosion", but I = see no dilemma here because in fact the contents can be *any* JSON text. = I don't think the mere fact that there is some data model behind it = warrants a new media type. >>=20 >=20 > Obviously I can make up my own URIs, but doesn't > this count as a media type? It could be application/json > I suppose. Or perhaps something specific for the concrete data model. Maybe we can = ask application experts. Lada >=20 >=20 >>>=20 >>> That way a protocol could identify the encoding types it >>> supports somehow, and auto-negotiate the one(s) to use. >>=20 >> But there is no special encoding, is it? >>=20 >=20 > The module names and identityrefs, etc. have extra semantics > encoded into the value part. >=20 >=20 >> Lada >>=20 >=20 > Andy >=20 >>>=20 >>>=20 >>> These are the only implementation issues I had (so far). >>>=20 >>>=20 >>> Andy >>>=20 >>>=20 >>> On Tue, Apr 2, 2013 at 10:21 AM, Ladislav Lhotka = wrote: >>>> Hi, >>>>=20 >>>> this revision corrects several mistakes and adds an example for = union type. >>>>=20 >>>> Lada >>>>=20 >>>> Begin forwarded message: >>>>=20 >>>>> From: internet-drafts@ietf.org >>>>> Subject: New Version Notification for = draft-lhotka-netmod-yang-json-01.txt >>>>> Date: April 2, 2013 7:19:11 PM GMT+02:00 >>>>> To: lhotka@nic.cz >>>>>=20 >>>>>=20 >>>>> A new version of I-D, draft-lhotka-netmod-yang-json-01.txt >>>>> has been successfully submitted by Ladislav Lhotka and posted to = the >>>>> IETF repository. >>>>>=20 >>>>> Filename: draft-lhotka-netmod-yang-json >>>>> Revision: 01 >>>>> Title: Modeling JSON Text with YANG >>>>> Creation date: 2013-04-02 >>>>> Group: Individual Submission >>>>> Number of pages: 14 >>>>> URL: = http://www.ietf.org/internet-drafts/draft-lhotka-netmod-yang-json-01.txt >>>>> Status: = http://datatracker.ietf.org/doc/draft-lhotka-netmod-yang-json >>>>> Htmlized: = http://tools.ietf.org/html/draft-lhotka-netmod-yang-json-01 >>>>> Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-lhotka-netmod-yang-json-01 >>>>>=20 >>>>> Abstract: >>>>> This document defines rules for mapping data models expressed in = YANG >>>>> to configuration and operational state data encoded as JSON text. = It >>>>> does so by specifying a procedure for translating the subset of = YANG- >>>>> compatible XML documents to JSON text, and vice versa. >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> The IETF Secretariat >>>>>=20 >>>>=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 >> _______________________________________________ >> 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 phil@juniper.net Sat Apr 6 10:57:17 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 941E121F8A66 for ; Sat, 6 Apr 2013 10:57:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ArGGOiXWivV for ; Sat, 6 Apr 2013 10:57:17 -0700 (PDT) Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by ietfa.amsl.com (Postfix) with ESMTP id E083921F8A52 for ; Sat, 6 Apr 2013 10:57:13 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP ID DSNKUWBh+f9mzngK8qX5rapqBBatNhBjWI9R@postini.com; Sat, 06 Apr 2013 10:57:16 PDT Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB01-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.3.213.0; Sat, 6 Apr 2013 10:57:08 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id r36Hv7312062; Sat, 6 Apr 2013 10:57:07 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.4/8.14.3) with ESMTP id r36HuLRm087531; Sat, 6 Apr 2013 13:56:36 -0400 (EDT) (envelope-from phil@idle.juniper.net) Message-ID: <201304061756.r36HuLRm087531@idle.juniper.net> To: Ladislav Lhotka In-Reply-To: Date: Sat, 6 Apr 2013 13:56:21 -0400 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] Fwd: New Version Notification for draft-lhotka-netmod-yang-json-01.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Apr 2013 17:57:17 -0000 Ladislav Lhotka writes: >1. I don't know how to encode the binding between such an attribute and the data node (e >specially leaf) to which it belongs, because in JSON they would have to be siblings, and > there might be other sibling leaves. XML data has three dimensions, values, attributes, and namespaces. If you have to encode using JSON, you'll need something like: { "top": { "_attributes": { "elt1": { "attr1": "av1", } "elt2": { "attr2": "av2", "more2": "mv2", } }, "elt1": "25", "elt2": "popcorn", } } for the XML: 25 popcorn Noisy as all get out, but.... >I think section 3.1 defines this mapping and the encoding of an explicit namespace id: >: Ah, I missed that you are talking about an actual module name here. It wasn't clear that you are talking about the name of the YANG module. Once I know what you mean, it's clear, but adding something more explicit might help the next reader. I'm also worried about this part: The namespace identifier MUST be used for local names that are ambiguous, i.e., whenever the data model permits a sibling node with the same local name. Otherwise, the namespace identifier is OPTIONAL. This is both confusing (since you're talking about "namespace identifier"s instead of module names, but it's also painful for both parties to not know if the other side is sending the module name or not. My code can't refer to 'top.elt1' or 'top["elt2"]' since they could be top["phil:elt1"] or top["phil:elt2"]. Ambiguity is also an interesting point, since deciding what's ambiguous means knowing the full set of modules running on the device. If you add the "lada" module, then top.elt1 has to be top["phil:elt1"] if "lada" augments with elt1. >> Can you add an example where one YANG modules augments another? >> I can't tell from your text what would happen. Actually, I can >> find nothing on augmentation in the draft. >The mapping is between instance documents, so augments are not special, except that they >may lead to local name collisions where explicit namespace ids are required. But if the >local name is unambiguous, the : prefix is not required, even for augmented node >s. I still suggest an example since this is not an easy topic and is only covered lightly in the text. Thanks, Phil From andy@yumaworks.com Sat Apr 6 11:28:43 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED6C421F85C9 for ; Sat, 6 Apr 2013 11:28:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.798 X-Spam-Level: X-Spam-Status: No, score=-1.798 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UKcaAbfYAGoH for ; Sat, 6 Apr 2013 11:28:43 -0700 (PDT) Received: from mail-ia0-x233.google.com (mail-ia0-x233.google.com [IPv6:2607:f8b0:4001:c02::233]) by ietfa.amsl.com (Postfix) with ESMTP id 525CC21F8522 for ; Sat, 6 Apr 2013 11:28:43 -0700 (PDT) Received: by mail-ia0-f179.google.com with SMTP id x24so4033001iak.24 for ; Sat, 06 Apr 2013 11:28:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=NFiZnHqAXZQDwdbbebuVAGLQDIHZ8OJ9W7kZFe6K5bg=; b=gemgSfStaH6BVW1cHWJE8i7/Zj+rSQG3J4NDACJ5jUFfFHoN/0kcX9RicRvFtFtRXr rn6k1NyupVcCY6f+OY57X6cTU3eA1DTK5uW2fiq7Y/lKwVBbIrfJ0N8Cj71yOKTBL1Nl ZXkyRO27RzXqW9aUsUQQ4dKFLDwgCP+vgkmZ4r6Io7j5CZ+sE8V3jlRalkrUC10L8m+z M5mXiQtDYrWNWOgmx2REqwt3rsQnQPFNNYWfPEt3jp9BbT8SHIEVxS6AYXteucDImL1p kDdqIOBXrjgMguz6M2NFob1Kn+Byl59PupEqXyZ/VVQyAgH3n46DE9rRy8KwzqEKo/6/ J9jg== MIME-Version: 1.0 X-Received: by 10.50.140.5 with SMTP id rc5mr2616335igb.78.1365272922921; Sat, 06 Apr 2013 11:28:42 -0700 (PDT) Received: by 10.231.71.198 with HTTP; Sat, 6 Apr 2013 11:28:42 -0700 (PDT) In-Reply-To: <201304061756.r36HuLRm087531@idle.juniper.net> References: <201304061756.r36HuLRm087531@idle.juniper.net> Date: Sat, 6 Apr 2013 11:28:42 -0700 Message-ID: From: Andy Bierman To: Phil Shafer Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQm36hHzbfYkE06ZdfIaw3Qst1OiYGIyeILBhcbOnHZYf+bZAWWQNXnJoI7/LSwPkru8RZ1L Cc: netmod@ietf.org Subject: Re: [netmod] Fwd: New Version Notification for draft-lhotka-netmod-yang-json-01.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Apr 2013 18:28:44 -0000 On Sat, Apr 6, 2013 at 10:56 AM, Phil Shafer wrote: > Ladislav Lhotka writes: >>1. I don't know how to encode the binding between such an attribute and the data node (e >>specially leaf) to which it belongs, because in JSON they would have to be siblings, and >> there might be other sibling leaves. > > XML data has three dimensions, values, attributes, and namespaces. If > you have to encode using JSON, you'll need something like: > > > { > "top": { > "_attributes": { > "elt1": { > "attr1": "av1", > } > "elt2": { > "attr2": "av2", > "more2": "mv2", > } > }, > "elt1": "25", > "elt2": "popcorn", > } > } > Qualified attributes could be encoded like node names. I prefer to keep the attributes with the parent nodes to make parsing, streaming, and access control easier. There could be a convention that "@attributes" and "@value" must be used together: { "config" : { "newleaf": { "@attributes": { "ietf-netconf:operation" : "create" }, "@value" : 42 } } This works for any YANG data node (replace 42 with appropriate conversion according to draft). I think @attributes is a JSON convention already, and it is an illegal YANG identifier, so no name collisions are possible. > for the XML: > > > 25 > popcorn > > > Noisy as all get out, but.... > >>I think section 3.1 defines this mapping and the encoding of an explicit namespace id: >>: > > Ah, I missed that you are talking about an actual module name here. > It wasn't clear that you are talking about the name of the YANG module. > Once I know what you mean, it's clear, but adding something more explicit > might help the next reader. > I agree -- it is up to the protocol that uses this encoding to provide a mapping from module-name to a more specific description of the relevant YANG module file(s). > I'm also worried about this part: > > The namespace identifier MUST be used for local names that are > ambiguous, i.e., whenever the data model permits a sibling node with > the same local name. Otherwise, the namespace identifier is > OPTIONAL. > > This is both confusing (since you're talking about "namespace identifier"s > instead of module names, but it's also painful for both parties to > not know if the other side is sending the module name or not. My > code can't refer to 'top.elt1' or 'top["elt2"]' since they could be > top["phil:elt1"] or top["phil:elt2"]. > > Ambiguity is also an interesting point, since deciding what's ambiguous > means knowing the full set of modules running on the device. If you > add the "lada" module, then top.elt1 has to be top["phil:elt1"] if > "lada" augments with elt1. > >>> Can you add an example where one YANG modules augments another? >>> I can't tell from your text what would happen. Actually, I can >>> find nothing on augmentation in the draft. >>The mapping is between instance documents, so augments are not special, except that they >>may lead to local name collisions where explicit namespace ids are required. But if the >>local name is unambiguous, the : prefix is not required, even for augmented node >>s. This draft needs to assume a "static" YANG module, meaning all the augment-stmts are already applied. If the set of modules on the server has duplicate local-names due to augment or just 2 top-level nodes from different modules, then the "long-form" of the name has to be used. > > I still suggest an example since this is not an easy topic and is > only covered lightly in the text. agree -- encoding examples for all YANG node types and data types are needed. > > Thanks, > Phil Andy From lhotka@nic.cz Sun Apr 7 03:51:47 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C85E921F8CEC for ; Sun, 7 Apr 2013 03:51:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.418 X-Spam-Level: X-Spam-Status: No, score=-1.418 tagged_above=-999 required=5 tests=[AWL=-0.323, BAYES_00=-2.599, HOST_EQ_CZ=0.904, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XdbLONO+wwb3 for ; Sun, 7 Apr 2013 03:51:47 -0700 (PDT) Received: from trail.lhotka.name (nat-5.bravonet.cz [77.48.224.5]) by ietfa.amsl.com (Postfix) with ESMTP id 999CF21F8E6C for ; Sun, 7 Apr 2013 03:51:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 10B1554028A for ; Sun, 7 Apr 2013 12:51: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 Oa4lhMQIeg2t for ; Sun, 7 Apr 2013 12:51: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 DDA435401BA for ; Sun, 7 Apr 2013 12:51:27 +0200 (CEST) From: Ladislav Lhotka To: netmod@ietf.org In-Reply-To: <201304061756.r36HuLRm087531@idle.juniper.net> References: <201304061756.r36HuLRm087531@idle.juniper.net> User-Agent: Notmuch/0.15.2+56~gf55b35b (http://notmuchmail.org) Emacs/23.3.50.1 (i386-apple-darwin9.8.0) Mail-Followup-To: netmod@ietf.org Date: Sun, 07 Apr 2013 12:51:27 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [netmod] Fwd: New Version Notification for draft-lhotka-netmod-yang-json-01.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Apr 2013 10:51:47 -0000 Phil Shafer writes: > Ladislav Lhotka writes: >>1. I don't know how to encode the binding between such an attribute and the data node (e >>specially leaf) to which it belongs, because in JSON they would have to be siblings, and >> there might be other sibling leaves. > > XML data has three dimensions, values, attributes, and namespaces. If > you have to encode using JSON, you'll need something like: > > > { > "top": { > "_attributes": { > "elt1": { > "attr1": "av1", > } > "elt2": { > "attr2": "av2", > "more2": "mv2", > } > }, > "elt1": "25", > "elt2": "popcorn", > } > } > Hmm, this is really ugly and I think it sort of defeats the purpose of using JSON in the first place, i.e. simple encoding. IMO, it would be better to keep the attributes completely separate, for example [ { "path": "/top/elt1", "attributes": { "attr1": "av1" } }, { "path": "/top/elt2", "attributes": { "attr2": "av2", "more2": "mv2" } } ] Another approach could be to turn things around: "@disabled": { "elt1": 25, "elt2": "popcorn" } The advantage of this approach is that it works for leaf-list entries as well: "foo": [1, 2, {"@disabled": 3}, 4] But all that being said, the draft is about mapping documents that follow the schema of a YANG data model, and YANG cannot model XML attributes, so they are out of scope. > for the XML: > > > 25 > popcorn > > > Noisy as all get out, but.... > >>I think section 3.1 defines this mapping and the encoding of an explicit namespace id: >>: > > Ah, I missed that you are talking about an actual module name here. > It wasn't clear that you are talking about the name of the YANG module. > Once I know what you mean, it's clear, but adding something more explicit > might help the next reader. I agree that the text can be improved and one or two examples would be useful. > > I'm also worried about this part: > > The namespace identifier MUST be used for local names that are > ambiguous, i.e., whenever the data model permits a sibling node with > the same local name. Otherwise, the namespace identifier is > OPTIONAL. > > This is both confusing (since you're talking about "namespace identifier"s > instead of module names, but it's also painful for both parties to Module name is the namespace identifier. > not know if the other side is sending the module name or not. My > code can't refer to 'top.elt1' or 'top["elt2"]' since they could be > top["phil:elt1"] or top["phil:elt2"]. We have gone through several iterations here, and I think the present solution is best (it was Andy's suggestion). The motivation was to get rid of namespaces where possible. It's true that this simple access to object members is not possible but a simple function would do. The alternative would be to have module names everywhere. > > Ambiguity is also an interesting point, since deciding what's ambiguous > means knowing the full set of modules running on the device. If you > add the "lada" module, then top.elt1 has to be top["phil:elt1"] if > "lada" augments with elt1. Yes, it is a basic assumption that all modules and features etc are known beforehand. > >>> Can you add an example where one YANG modules augments another? >>> I can't tell from your text what would happen. Actually, I can >>> find nothing on augmentation in the draft. >>The mapping is between instance documents, so augments are not special, except that they >>may lead to local name collisions where explicit namespace ids are required. But if the >>local name is unambiguous, the : prefix is not required, even for augmented node >>s. > > I still suggest an example since this is not an easy topic and is > only covered lightly in the text. OK, agreed. Lada > > Thanks, > Phil -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From lhotka@nic.cz Sun Apr 7 04:14:34 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EEB721F85F5 for ; Sun, 7 Apr 2013 04:14:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[AWL=-0.282, BAYES_00=-2.599, HOST_EQ_CZ=0.904, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1rKY7SW9uJgH for ; Sun, 7 Apr 2013 04:14:34 -0700 (PDT) Received: from trail.lhotka.name (nat-5.bravonet.cz [77.48.224.5]) by ietfa.amsl.com (Postfix) with ESMTP id D23E221F85E8 for ; Sun, 7 Apr 2013 04:14:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id B10A254028A for ; Sun, 7 Apr 2013 13:14:32 +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 VOxmxA4OYhI7 for ; Sun, 7 Apr 2013 13:14:25 +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 9F7EC5401BA for ; Sun, 7 Apr 2013 13:14:25 +0200 (CEST) From: Ladislav Lhotka To: netmod@ietf.org In-Reply-To: References: <201304061756.r36HuLRm087531@idle.juniper.net> User-Agent: Notmuch/0.15.2+56~gf55b35b (http://notmuchmail.org) Emacs/23.3.50.1 (i386-apple-darwin9.8.0) Mail-Followup-To: netmod@ietf.org Date: Sun, 07 Apr 2013 13:14:25 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [netmod] Fwd: New Version Notification for draft-lhotka-netmod-yang-json-01.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Apr 2013 11:14:34 -0000 Andy Bierman writes: > > > Qualified attributes could be encoded like node names. > I prefer to keep the attributes with the parent nodes to make > parsing, streaming, and access control easier. > > There could be a convention that "@attributes" and "@value" must > be used together: > > > { "config" : { > "newleaf": { > "@attributes": { > "ietf-netconf:operation" : "create" > }, > "@value" : 42 > } > } > > This works for any YANG data node (replace 42 with > appropriate conversion according to draft). > I think @attributes is a JSON convention already, > and it is an illegal YANG identifier, so no name > collisions are possible. > Perhaps the problem is that YANG-API is just a front end to NETCONF API. NETCONF operations were designed for XML and don't work that well for JSON. IMO, using JSON Patch (it is now a fresh RFC 6902) would be simpler and better: [ { "op": "add", "path": "/config/newleaf", "value": 42 } ] Lada -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From andy@yumaworks.com Sun Apr 7 07:11:39 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8AEF21F8EA6 for ; Sun, 7 Apr 2013 07:11:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.828 X-Spam-Level: X-Spam-Status: No, score=-1.828 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PFvkdiY43mKq for ; Sun, 7 Apr 2013 07:11:37 -0700 (PDT) Received: from mail-ia0-x233.google.com (mail-ia0-x233.google.com [IPv6:2607:f8b0:4001:c02::233]) by ietfa.amsl.com (Postfix) with ESMTP id 2296421F8EA5 for ; Sun, 7 Apr 2013 07:11:34 -0700 (PDT) Received: by mail-ia0-f179.google.com with SMTP id x24so4396873iak.24 for ; Sun, 07 Apr 2013 07:11:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type:x-gm-message-state; bh=2LQ2B4Fyq2zQcidEjzHN568hGJrlJHbhBq+WfZkh6F4=; b=NLDoHdNrxQGcTvxBO0JiNnrwP8m2i1Y3JlDbQ8pl5TK8KfzGBQy68eNVX4Cud8HoIj mQA25aPrpwtEgTayfnuYQ+Jt98WnzBGQpaDTe3zLsJJ+mCLY3MILd3o74IphF3oWzDHF MGwtKFwmb+g0SsU52HDyVdUlZxgAlrPPRWRdeKequau3rTz86f2oBF9ErgGlcUAb//X/ 6tJZ6xcOW6HspVURme+FjFRfWTMkRaqv+joKj/X4AekMlg4htdAE8l4cvnEQDJFeEvsM oOCBSlxHaZ42EWBM1aJdtxTJMGWozKni8uf0NNMuvVllzrkhLKy4jvUBWj619RjEI4Sb pSCg== MIME-Version: 1.0 X-Received: by 10.50.136.138 with SMTP id qa10mr4226528igb.74.1365343894301; Sun, 07 Apr 2013 07:11:34 -0700 (PDT) Received: by 10.231.71.198 with HTTP; Sun, 7 Apr 2013 07:11:34 -0700 (PDT) In-Reply-To: References: <201304061756.r36HuLRm087531@idle.juniper.net> Date: Sun, 7 Apr 2013 07:11:34 -0700 Message-ID: From: Andy Bierman To: netmod@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnN4SvG/ZyV/auWJbYa00KIWXuAfUw0fVOQUifcePUofIOblkn/hSUZnt1opU9Dmw84M8fg Subject: Re: [netmod] Fwd: New Version Notification for draft-lhotka-netmod-yang-json-01.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Apr 2013 14:11:39 -0000 On Sun, Apr 7, 2013 at 4:14 AM, Ladislav Lhotka wrote: > Andy Bierman writes: > >> >> >> Qualified attributes could be encoded like node names. >> I prefer to keep the attributes with the parent nodes to make >> parsing, streaming, and access control easier. >> >> There could be a convention that "@attributes" and "@value" must >> be used together: >> >> >> { "config" : { >> "newleaf": { >> "@attributes": { >> "ietf-netconf:operation" : "create" >> }, >> "@value" : 42 >> } >> } >> >> This works for any YANG data node (replace 42 with >> appropriate conversion according to draft). >> I think @attributes is a JSON convention already, >> and it is an illegal YANG identifier, so no name >> collisions are possible. >> > > Perhaps the problem is that YANG-API is just a front end to NETCONF API. NETCONF operations were designed for XML and don't work that well for JSON. > YANG-API does not use attributes. If I want to use an alternate encoding for NETCONF, then attributes need to be supported. I've seen several examples of how this is being done and it doesn't look too complicated. > IMO, using JSON Patch (it is now a fresh RFC 6902) would be simpler and better: > > [ > { "op": "add", "path": "/config/newleaf", "value": 42 } > ] > This actually has a different edit model than . The PATCH operation is atomic, and each individual patch object within the request is sequential. They expect the input for step 3 to be the output of step 2. Rather than validating N separate edits against candidate or running. JSON Patch validates edit N+1 against result N. Of course if any operation in the list fails (including 'test'), then everything has to get backed out, even on the running config (rollback-on-error is the only error-option). I don't know if this edit model is compatible with the NETCONF datastores. If the only thing going on were simple patches to a document, then it would be easy. But a NETCONF datastore is the tip of the iceberg -- the underlying system takes those edits and changes network behavior. It could be impossible to to know if result N will be valid until an attempt to commit that change is made. This has always been the flaw with pretending the datastore is just an XML instance document. > Lada > Andy From lhotka@nic.cz Sun Apr 7 08:19:35 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 352D921F8DD6 for ; Sun, 7 Apr 2013 08:19:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.798 X-Spam-Level: X-Spam-Status: No, score=-1.798 tagged_above=-999 required=5 tests=[AWL=0.201, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yI2nOIpNNZPD for ; Sun, 7 Apr 2013 08:19:34 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 3CB9C21F8D90 for ; Sun, 7 Apr 2013 08:19:34 -0700 (PDT) Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 6A21E13F662; Sun, 7 Apr 2013 17:19:33 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1365347973; bh=9+l0+Va05DfsWgf7kIoM76Varmuyy0OlKONCF9Qp7eE=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=feau98e6tYlF5eQxqg9blSoFRUfg89YNo1b3fiMrZ1joubCfU6bm192J4ClFvvdmk QeJzKkgehxZ6WBslHZ6xp0HExG9OfHLAt0y9nbTq7McT7YXUfMr64M6cJZtphecXWn GBSgoXkHVfSi6UvLb4hw9tYXMEHrLInuhff4Ryy0= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Ladislav Lhotka In-Reply-To: Date: Sun, 7 Apr 2013 17:19:31 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <6CBAC5E7-DD1F-4C6C-8290-9091132C87AD@nic.cz> References: <201304061756.r36HuLRm087531@idle.juniper.net> To: Andy Bierman X-Mailer: Apple Mail (2.1503) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] Fwd: New Version Notification for draft-lhotka-netmod-yang-json-01.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Apr 2013 15:19:35 -0000 On Apr 7, 2013, at 4:11 PM, Andy Bierman wrote: > On Sun, Apr 7, 2013 at 4:14 AM, Ladislav Lhotka wrote: >> Andy Bierman writes: >>=20 >>>=20 >>>=20 >>> Qualified attributes could be encoded like node names. >>> I prefer to keep the attributes with the parent nodes to make >>> parsing, streaming, and access control easier. >>>=20 >>> There could be a convention that "@attributes" and "@value" must >>> be used together: >>>=20 >>>=20 >>> { "config" : { >>> "newleaf": { >>> "@attributes": { >>> "ietf-netconf:operation" : "create" >>> }, >>> "@value" : 42 >>> } >>> } >>>=20 >>> This works for any YANG data node (replace 42 with >>> appropriate conversion according to draft). >>> I think @attributes is a JSON convention already, >>> and it is an illegal YANG identifier, so no name >>> collisions are possible. >>>=20 >>=20 >> Perhaps the problem is that YANG-API is just a front end to NETCONF = API. NETCONF operations were designed for XML and don't work that well = for JSON. >>=20 >=20 > YANG-API does not use attributes. > If I want to use an alternate encoding for NETCONF, then > attributes need to be supported. I've seen several examples > of how this is being done and it doesn't look too complicated. >=20 >=20 >> IMO, using JSON Patch (it is now a fresh RFC 6902) would be simpler = and better: >>=20 >> [ >> { "op": "add", "path": "/config/newleaf", "value": 42 } >> ] >>=20 >=20 > This actually has a different edit model than . > The PATCH operation is atomic, and each individual patch > object within the request is sequential. They expect the > input for step 3 to be the output of step 2. >=20 > Rather than validating N separate edits against candidate or running. > JSON Patch validates edit N+1 against result N. > Of course if any operation in the list fails (including 'test'), > then everything has to get backed out, even on the running > config (rollback-on-error is the only error-option). >=20 > I don't know if this edit model is compatible with the NETCONF > datastores. If the only thing going on were simple patches > to a document, then it would be easy. But a NETCONF > datastore is the tip of the iceberg -- the underlying system > takes those edits and changes network behavior. > It could be impossible to to know if result N will be valid > until an attempt to commit that change is made. > This has always been the flaw with pretending the datastore > is just an XML instance document. Validation always has some scope and limits. A configuration that is = perfectly OK from the point of view of an individual router can still = break the network.=20 But I think that RFC 5789 (HTTP PATCH) addresses all kinds of errors, = even run-time.=20 Lada -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From andy@yumaworks.com Sun Apr 7 09:15:31 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44DD121F8CD8 for ; Sun, 7 Apr 2013 09:15:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.849 X-Spam-Level: X-Spam-Status: No, score=-1.849 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aDcbu4Eqyrqw for ; Sun, 7 Apr 2013 09:15:30 -0700 (PDT) Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 9D7B521F8C3C for ; Sun, 7 Apr 2013 09:15:30 -0700 (PDT) Received: by mail-ie0-f172.google.com with SMTP id c10so6037080ieb.3 for ; Sun, 07 Apr 2013 09:15:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=jmv0Dc1CvuZe+78N2R4w3XeUFkbB7vSdUCPax9G8ZF8=; b=YyyvQrUgkdrfKSxfgXVKZC55tWDQxaUEzK4Pe4Ho4KgAg6RlMcFeRxwzHkhpohHBNE EOeo5OUI3YuI9W/w/L/nVVcsX8HV6P3u4n93UrIL9oXUJIEXL5p4nlgg3+nuBtwAm3Ui gxVxpp/jASFZiwEsm5Jch1cVl0udQ2fyoi57vS9REKMIRhxF39zJin9ZCa4WER9K9k9F SSBsZjNx4tVW/UyzfcGNDcZYgO2xtuLPWsvItdEJH7ZSkXXHHorq9vdMAJpkUH1vARPf O1oyf3bhX3atuSpQSpPTM2sJUwGODi+8Syn8EniIJ5w0uLo6YagjD0TpcAJHzZ8CThXh Ij8w== MIME-Version: 1.0 X-Received: by 10.50.187.225 with SMTP id fv1mr4656025igc.74.1365351322100; Sun, 07 Apr 2013 09:15:22 -0700 (PDT) Received: by 10.231.71.198 with HTTP; Sun, 7 Apr 2013 09:15:21 -0700 (PDT) In-Reply-To: <6CBAC5E7-DD1F-4C6C-8290-9091132C87AD@nic.cz> References: <201304061756.r36HuLRm087531@idle.juniper.net> <6CBAC5E7-DD1F-4C6C-8290-9091132C87AD@nic.cz> Date: Sun, 7 Apr 2013 09:15:21 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnVGtT4d1TW4fjcrFj4ReInOhBBqgt6Fo4nr0icGFFMO+Yk9FXCQoWJTehGkgfj0Uh80CBE Cc: netmod@ietf.org Subject: Re: [netmod] Fwd: New Version Notification for draft-lhotka-netmod-yang-json-01.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Apr 2013 16:15:31 -0000 On Sun, Apr 7, 2013 at 8:19 AM, Ladislav Lhotka wrote: > > On Apr 7, 2013, at 4:11 PM, Andy Bierman wrote: > >> On Sun, Apr 7, 2013 at 4:14 AM, Ladislav Lhotka wrote: >>> Andy Bierman writes: >>> >>>> >>>> >>>> Qualified attributes could be encoded like node names. >>>> I prefer to keep the attributes with the parent nodes to make >>>> parsing, streaming, and access control easier. >>>> >>>> There could be a convention that "@attributes" and "@value" must >>>> be used together: >>>> >>>> >>>> { "config" : { >>>> "newleaf": { >>>> "@attributes": { >>>> "ietf-netconf:operation" : "create" >>>> }, >>>> "@value" : 42 >>>> } >>>> } >>>> >>>> This works for any YANG data node (replace 42 with >>>> appropriate conversion according to draft). >>>> I think @attributes is a JSON convention already, >>>> and it is an illegal YANG identifier, so no name >>>> collisions are possible. >>>> >>> >>> Perhaps the problem is that YANG-API is just a front end to NETCONF API. NETCONF operations were designed for XML and don't work that well for JSON. >>> >> >> YANG-API does not use attributes. >> If I want to use an alternate encoding for NETCONF, then >> attributes need to be supported. I've seen several examples >> of how this is being done and it doesn't look too complicated. >> >> >>> IMO, using JSON Patch (it is now a fresh RFC 6902) would be simpler and better: >>> >>> [ >>> { "op": "add", "path": "/config/newleaf", "value": 42 } >>> ] >>> >> >> This actually has a different edit model than . >> The PATCH operation is atomic, and each individual patch >> object within the request is sequential. They expect the >> input for step 3 to be the output of step 2. >> >> Rather than validating N separate edits against candidate or running. >> JSON Patch validates edit N+1 against result N. >> Of course if any operation in the list fails (including 'test'), >> then everything has to get backed out, even on the running >> config (rollback-on-error is the only error-option). > >> >> I don't know if this edit model is compatible with the NETCONF >> datastores. If the only thing going on were simple patches >> to a document, then it would be easy. But a NETCONF >> datastore is the tip of the iceberg -- the underlying system >> takes those edits and changes network behavior. >> It could be impossible to to know if result N will be valid >> until an attempt to commit that change is made. >> This has always been the flaw with pretending the datastore >> is just an XML instance document. > > Validation always has some scope and limits. A configuration that is perfectly OK from the point of view of an individual router can still break the network. > This has nothing to do with the problem. > But I think that RFC 5789 (HTTP PATCH) addresses all kinds of errors, even run-time. > I think the NETCONF model works better for configuration management. There is a huge difference between JSON Patch and NETCONF: * NETCONF applies N edits within 1 request in no specified order to the target datastore, and all validation is against the target * JSON Patch applies N edits within 1 request in sequential order. The first edit is validated against the target which produces a temporary result datastore R(n). Each edit(n+1) is validated against datastore R(n). I suppose only server developers understand the impact of this change, but IMO the NETCONF edit model is much better for CM use-cases and much easier to implement. I am interested in maintaining compatibility with NETCONF servers with any new protocol or message encoding. > Lada > Andy From j.schoenwaelder@jacobs-university.de Sun Apr 7 10:19:14 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09FAB21F8585 for ; Sun, 7 Apr 2013 10:19:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.249 X-Spam-Level: X-Spam-Status: No, score=-103.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YAFVLOICccpd for ; Sun, 7 Apr 2013 10:19:13 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 04B7021F8536 for ; Sun, 7 Apr 2013 10:19:12 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4C1B420C12; Sun, 7 Apr 2013 19:19:11 +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 IGNggIcWcK5G; Sun, 7 Apr 2013 19:19: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 C1E2A20BE5; Sun, 7 Apr 2013 19:19:10 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 05977257924C; Sun, 7 Apr 2013 19:19:17 +0200 (CEST) Date: Sun, 7 Apr 2013 19:19:17 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20130407171917.GA12792@elstar.local> Mail-Followup-To: Andy Bierman , Ladislav Lhotka , netmod@ietf.org References: <201304061756.r36HuLRm087531@idle.juniper.net> <6CBAC5E7-DD1F-4C6C-8290-9091132C87AD@nic.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] Fwd: New Version Notification for draft-lhotka-netmod-yang-json-01.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Apr 2013 17:19:14 -0000 On Sun, Apr 07, 2013 at 09:15:21AM -0700, Andy Bierman wrote: > I think the NETCONF model works better for configuration management. > There is a huge difference between JSON Patch and NETCONF: > * NETCONF applies N edits within 1 request in no specified > order to the target datastore, and all validation is against the target > * JSON Patch applies N edits within 1 request in sequential order. > The first edit is validated against the target which produces a temporary > result datastore R(n). Each edit(n+1) is validated against datastore R(n). > Andy, can you point us to where this is specified for JSON patch? Do they really have the same notion of 'validation' that NETCONF has? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From andy@yumaworks.com Sun Apr 7 11:54:42 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF4E021F8501 for ; Sun, 7 Apr 2013 11:54:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.866 X-Spam-Level: X-Spam-Status: No, score=-1.866 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id udKnXsKrTEEz for ; Sun, 7 Apr 2013 11:54:42 -0700 (PDT) Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 4FA4821F84E7 for ; Sun, 7 Apr 2013 11:54:42 -0700 (PDT) Received: by mail-ie0-f172.google.com with SMTP id c10so6117442ieb.3 for ; Sun, 07 Apr 2013 11:54:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type:x-gm-message-state; bh=1ZVFcKkNfiJKGn9FSd2Zs8oKZrsuo5+zNzR6ELCLKSw=; b=UcskOjEPR7sLW7hjZYlw/WWk8KfvRFc+29bYgGnLYoXrV0U93szcDQ8HqXVWcIWS/G s/fxc/ocbEsN7SXXtOPXSGOorM4ZCxqOXKeZh1xwR1nY8UQsu6bregCmnEORlw7ZB0Sc juXhXeNzCyXZEIAEIFuXklO8e/6vZwOspZLqZdx9wexJvu4eKexOjpiF0vPpd3DHnLL8 1P4AtC9unIZG1fakLxn7D9GoFmSfkBcgueEqCttZn/9fI0fqM9RzDWrorGoOqok5k+0Y yoaj7a5dFA1EeJ9QfG/+Z3S7ANnjRfd0qTENaoJt18itqRa2eVS6XsKCJiyB9/xv4zLj 4D8Q== MIME-Version: 1.0 X-Received: by 10.50.136.138 with SMTP id qa10mr4775333igb.74.1365360881814; Sun, 07 Apr 2013 11:54:41 -0700 (PDT) Received: by 10.231.71.198 with HTTP; Sun, 7 Apr 2013 11:54:41 -0700 (PDT) In-Reply-To: <20130407171917.GA12792@elstar.local> References: <201304061756.r36HuLRm087531@idle.juniper.net> <6CBAC5E7-DD1F-4C6C-8290-9091132C87AD@nic.cz> <20130407171917.GA12792@elstar.local> Date: Sun, 7 Apr 2013 11:54:41 -0700 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , Andy Bierman , Ladislav Lhotka , netmod@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnNM9sIDlJPpv5DmstLpMuw1trIHoR7bLo0jMZF2Q9yVOwnBzJPz95yLqkDpLdAKL5vBKZm Subject: Re: [netmod] Fwd: New Version Notification for draft-lhotka-netmod-yang-json-01.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Apr 2013 18:54:42 -0000 On Sun, Apr 7, 2013 at 10:19 AM, Juergen Schoenwaelder wrote: > On Sun, Apr 07, 2013 at 09:15:21AM -0700, Andy Bierman wrote: > >> I think the NETCONF model works better for configuration management. >> There is a huge difference between JSON Patch and NETCONF: >> * NETCONF applies N edits within 1 request in no specified >> order to the target datastore, and all validation is against the target >> * JSON Patch applies N edits within 1 request in sequential order. >> The first edit is validated against the target which produces a temporary >> result datastore R(n). Each edit(n+1) is validated against datastore R(n). >> > > Andy, can you point us to where this is specified for JSON patch? Do > they really have the same notion of 'validation' that NETCONF has? They have a notion that the operations are performed sequentially and value tests can be done against intermediate steps (RFC 6902, sec. 3). Even if just the final result is validated wrt/ datastore checks, the field validation and the individual "test" operations within the patch may need to be done on intermediate results. The server should be the one that figures out the order and normalization of edits. I prefer the current NETCONF edit model and see no reason to change it. I'm just looking for more efficient message encoding formats than XML, not a server re-design. > > /js Andy From j.schoenwaelder@jacobs-university.de Sun Apr 7 13:04:10 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A1D021F84A9 for ; Sun, 7 Apr 2013 13:04:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.249 X-Spam-Level: X-Spam-Status: No, score=-103.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8EqM9ygCMbDt for ; Sun, 7 Apr 2013 13:04:09 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 35EEF21F84A1 for ; Sun, 7 Apr 2013 13:04:08 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 655E520C18; Sun, 7 Apr 2013 22:04:07 +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 UABhpBc8M_SC; Sun, 7 Apr 2013 22:04: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 D276F20C1A; Sun, 7 Apr 2013 22:04:06 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 96DC6257952D; Sun, 7 Apr 2013 22:04:14 +0200 (CEST) Date: Sun, 7 Apr 2013 22:04:14 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20130407200414.GA13081@elstar.local> Mail-Followup-To: Andy Bierman , Ladislav Lhotka , netmod@ietf.org References: <201304061756.r36HuLRm087531@idle.juniper.net> <6CBAC5E7-DD1F-4C6C-8290-9091132C87AD@nic.cz> <20130407171917.GA12792@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] Fwd: New Version Notification for draft-lhotka-netmod-yang-json-01.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Apr 2013 20:04:10 -0000 On Sun, Apr 07, 2013 at 11:54:41AM -0700, Andy Bierman wrote: > > > > Andy, can you point us to where this is specified for JSON patch? Do > > they really have the same notion of 'validation' that NETCONF has? > > They have a notion that the operations are performed sequentially > and value tests can be done against intermediate steps (RFC 6902, sec. 3). > Even if just the final result is validated wrt/ datastore checks, the field > validation and the individual "test" operations within the patch may > need to be done on intermediate results. > > The server should be the one that figures out the order and > normalization of edits. I prefer the current NETCONF edit > model and see no reason to change it. I'm just looking for more > efficient message encoding formats than XML, not a server re-design. Do we actually have evidence that applications out there make use of the NETCONF edit model? There is complexity associated with the ability to send an arbitrarily complex edit-config to a device. If this is heavily used, fine. If not (e.g., since application writers are too lazy to generate complex edit-configs or they simply only operate on a small subset of the data model anyway), then one can ask whether maintaining this complexity for a REST API is a good match. Note, this is a question. I do not know the answer. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From mbj@tail-f.com Sun Apr 7 14:18:55 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD4BC21F856E for ; Sun, 7 Apr 2013 14:18:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.281 X-Spam-Level: X-Spam-Status: No, score=-1.281 tagged_above=-999 required=5 tests=[AWL=0.165, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_34=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CGrGbr9M7tqT for ; Sun, 7 Apr 2013 14:18:55 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 4E2EA21F8556 for ; Sun, 7 Apr 2013 14:18:55 -0700 (PDT) Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 88ED21200D67; Sun, 7 Apr 2013 23:18:53 +0200 (CEST) Date: Sun, 07 Apr 2013 23:18:53 +0200 (CEST) Message-Id: <20130407.231853.374864263.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20130407200414.GA13081@elstar.local> References: <20130407171917.GA12792@elstar.local> <20130407200414.GA13081@elstar.local> X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] Fwd: New Version Notification for draft-lhotka-netmod-yang-json-01.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Apr 2013 21:18:56 -0000 Juergen Schoenwaelder wrote: > On Sun, Apr 07, 2013 at 11:54:41AM -0700, Andy Bierman wrote: > > > > > > Andy, can you point us to where this is specified for JSON patch? Do > > > they really have the same notion of 'validation' that NETCONF has? > > > > They have a notion that the operations are performed sequentially > > and value tests can be done against intermediate steps (RFC 6902, sec. 3). > > Even if just the final result is validated wrt/ datastore checks, the field > > validation and the individual "test" operations within the patch may > > need to be done on intermediate results. > > > > The server should be the one that figures out the order and > > normalization of edits. I prefer the current NETCONF edit > > model and see no reason to change it. I'm just looking for more > > efficient message encoding formats than XML, not a server re-design. > > Do we actually have evidence that applications out there make use of > the NETCONF edit model? There is complexity associated with the > ability to send an arbitrarily complex edit-config to a device. We make heavy use of it! The complexity shows up when we have to deal with devices that do *not* support this model. Given an arbitrary changeset, figuring out which CLI commands / SNMP SETs / REST PUT,POST,PATCH you have to send, and most importantly, in which order to send them is terribly tricky in the general case. /martin From mbj@tail-f.com Sun Apr 7 14:20:33 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0264521F8F39 for ; Sun, 7 Apr 2013 14:20:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.636 X-Spam-Level: X-Spam-Status: No, score=-1.636 tagged_above=-999 required=5 tests=[AWL=0.410, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fJMt9Vf92nmA for ; Sun, 7 Apr 2013 14:20:31 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id A768F21F8F33 for ; Sun, 7 Apr 2013 14:20:31 -0700 (PDT) Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id CF3A91200D67; Sun, 7 Apr 2013 23:20:30 +0200 (CEST) Date: Sun, 07 Apr 2013 23:20:29 +0200 (CEST) Message-Id: <20130407.232029.361611394.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: <20130407171917.GA12792@elstar.local> X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] Fwd: New Version Notification for draft-lhotka-netmod-yang-json-01.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Apr 2013 21:20:33 -0000 Andy Bierman wrote: > On Sun, Apr 7, 2013 at 10:19 AM, Juergen Schoenwaelder > wrote: > > On Sun, Apr 07, 2013 at 09:15:21AM -0700, Andy Bierman wrote: > > > >> I think the NETCONF model works better for configuration management. > >> There is a huge difference between JSON Patch and NETCONF: > >> * NETCONF applies N edits within 1 request in no specified > >> order to the target datastore, and all validation is against the target > >> * JSON Patch applies N edits within 1 request in sequential order. > >> The first edit is validated against the target which produces a > >> temporary > >> result datastore R(n). Each edit(n+1) is validated against datastore > >> R(n). > >> > > > > Andy, can you point us to where this is specified for JSON patch? Do > > they really have the same notion of 'validation' that NETCONF has? > > They have a notion that the operations are performed sequentially > and value tests can be done against intermediate steps (RFC 6902, sec. 3). > Even if just the final result is validated wrt/ datastore checks, the field > validation and the individual "test" operations within the patch may > need to be done on intermediate results. I do not understand this. Why can't we say that the final result is validated and applied to the datastore? What is the problem with field validation and "test"? > The server should be the one that figures out the order and > normalization of edits. I prefer the current NETCONF edit > model and see no reason to change it. I'm just looking for more > efficient message encoding formats than XML, not a server re-design. +1 /martin From j.schoenwaelder@jacobs-university.de Sun Apr 7 15:17:05 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A5E321F8F8A for ; Sun, 7 Apr 2013 15:17:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.949 X-Spam-Level: X-Spam-Status: No, score=-102.949 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GceNcWOyfFvw for ; Sun, 7 Apr 2013 15:17:04 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 838C221F8F11 for ; Sun, 7 Apr 2013 15:17:04 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id BB43220C1A; Mon, 8 Apr 2013 00:17:03 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 0O5mEM-tiW-K; Mon, 8 Apr 2013 00:17: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 2DA9D20C18; Mon, 8 Apr 2013 00:17:03 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id C14E725798AD; Mon, 8 Apr 2013 00:17:10 +0200 (CEST) Date: Mon, 8 Apr 2013 00:17:10 +0200 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20130407221710.GA13387@elstar.local> Mail-Followup-To: Martin Bjorklund , andy@yumaworks.com, netmod@ietf.org References: <20130407171917.GA12792@elstar.local> <20130407200414.GA13081@elstar.local> <20130407.231853.374864263.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130407.231853.374864263.mbj@tail-f.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] Fwd: New Version Notification for draft-lhotka-netmod-yang-json-01.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Apr 2013 22:17:05 -0000 On Sun, Apr 07, 2013 at 11:18:53PM +0200, Martin Bjorklund wrote: > Juergen Schoenwaelder wrote: > > On Sun, Apr 07, 2013 at 11:54:41AM -0700, Andy Bierman wrote: > > > > > > > > Andy, can you point us to where this is specified for JSON patch? Do > > > > they really have the same notion of 'validation' that NETCONF has? > > > > > > They have a notion that the operations are performed sequentially > > > and value tests can be done against intermediate steps (RFC 6902, sec. 3). > > > Even if just the final result is validated wrt/ datastore checks, the field > > > validation and the individual "test" operations within the patch may > > > need to be done on intermediate results. > > > > > > The server should be the one that figures out the order and > > > normalization of edits. I prefer the current NETCONF edit > > > model and see no reason to change it. I'm just looking for more > > > efficient message encoding formats than XML, not a server re-design. > > > > Do we actually have evidence that applications out there make use of > > the NETCONF edit model? There is complexity associated with the > > ability to send an arbitrarily complex edit-config to a device. > > We make heavy use of it! The complexity shows up when we have to deal > with devices that do *not* support this model. Given an arbitrary > changeset, figuring out which CLI commands / SNMP SETs / REST > PUT,POST,PATCH you have to send, and most importantly, in which > order to send them is terribly tricky in the general case. But this is likely not what this discussion is about. I want to understand why a NETCONF edit-config with embedded "add this", "merge this", "delete this" and then you validate the result is fundamentally better than a JSON patch that you send and then validate the result. I heard Andy saying that an edit-config can be processed in any order the server likes and that is a big win. However, applying a JSON patch yields another JSON document that can be validated and then the delta applied to the system in any order as well, no? We may have to distinguish between (a) the transformation of the serialized representation and (b) the application of the change to the 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 mbj@tail-f.com Sun Apr 7 15:23:53 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3E0321F89E2 for ; Sun, 7 Apr 2013 15:23:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.439 X-Spam-Level: X-Spam-Status: No, score=-1.439 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_34=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ISYN5Y+omxK6 for ; Sun, 7 Apr 2013 15:23:53 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 363D621F86BB for ; Sun, 7 Apr 2013 15:23:53 -0700 (PDT) Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 64B6C1200D65; Mon, 8 Apr 2013 00:23:51 +0200 (CEST) Date: Mon, 08 Apr 2013 00:23:50 +0200 (CEST) Message-Id: <20130408.002350.297731160.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20130407221710.GA13387@elstar.local> References: <20130407200414.GA13081@elstar.local> <20130407.231853.374864263.mbj@tail-f.com> <20130407221710.GA13387@elstar.local> X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] Fwd: New Version Notification for draft-lhotka-netmod-yang-json-01.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Apr 2013 22:23:54 -0000 Juergen Schoenwaelder wrote: > On Sun, Apr 07, 2013 at 11:18:53PM +0200, Martin Bjorklund wrote: > > Juergen Schoenwaelder wrote: > > > On Sun, Apr 07, 2013 at 11:54:41AM -0700, Andy Bierman wrote: > > > > > > > > > > Andy, can you point us to where this is specified for JSON patch? Do > > > > > they really have the same notion of 'validation' that NETCONF has? > > > > > > > > They have a notion that the operations are performed sequentially > > > > and value tests can be done against intermediate steps (RFC 6902, > > > > sec. 3). > > > > Even if just the final result is validated wrt/ datastore checks, the > > > > field > > > > validation and the individual "test" operations within the patch may > > > > need to be done on intermediate results. > > > > > > > > The server should be the one that figures out the order and > > > > normalization of edits. I prefer the current NETCONF edit > > > > model and see no reason to change it. I'm just looking for more > > > > efficient message encoding formats than XML, not a server re-design. > > > > > > Do we actually have evidence that applications out there make use of > > > the NETCONF edit model? There is complexity associated with the > > > ability to send an arbitrarily complex edit-config to a device. > > > > We make heavy use of it! The complexity shows up when we have to deal > > with devices that do *not* support this model. Given an arbitrary > > changeset, figuring out which CLI commands / SNMP SETs / REST > > PUT,POST,PATCH you have to send, and most importantly, in which > > order to send them is terribly tricky in the general case. > > But this is likely not what this discussion is about. Ok, then I got confused by your question. I guess I don't understand what your question refers to then; specifically, what does this mean: There is complexity associated with the ability to send an arbitrarily complex edit-config to a device. > I want to > understand why a NETCONF edit-config with embedded "add this", "merge > this", "delete this" and then you validate the result is fundamentally > better than a JSON patch that you send and then validate the result. > > I heard Andy saying that an edit-config can be processed in any order > the server likes and that is a big win. However, applying a JSON patch > yields another JSON document that can be validated and then the delta > applied to the system in any order as well, no? Yes, that is also my understanding. I think Andy needs to clarify his concerns. /martin From andy@yumaworks.com Sun Apr 7 15:24:30 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C4EC21F8DE4 for ; Sun, 7 Apr 2013 15:24:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.878 X-Spam-Level: X-Spam-Status: No, score=-1.878 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8CWS6iLns5wn for ; Sun, 7 Apr 2013 15:24:29 -0700 (PDT) Received: from mail-ie0-x233.google.com (mail-ie0-x233.google.com [IPv6:2607:f8b0:4001:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id B25B721F8F08 for ; Sun, 7 Apr 2013 15:24:29 -0700 (PDT) Received: by mail-ie0-f179.google.com with SMTP id k11so6121842iea.38 for ; Sun, 07 Apr 2013 15:24:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=Fl0VMDSPgY7Tcw3BpZ0nBvt8opGI8dajP+udciOxd8E=; b=ko0B1DyPeQwrmVy9fhodKYSjL+g+KMzrtrStUQKn20ULeKiqckYjBurI8Dq/ZNxe/Z yX0D8666JPvYSL39KnY8Q1s2+7i2OONM9gmqtE7GqbEwakpl1uLAQqrqtRxncgr/SwDN oj2rOczUkmZB/LA9+dWEP612qYLxIUYFz0mtP2jQ7KZQHO+p5kidEcPAn7qaCxMmqDp1 VIb2tcZzp6P58t2ia+DkjQ02IS5Z3InXiDCa1AARZBO378qmFsgCk91xn/lv4I8CzXKA KRvnd6u4yRhnHZX9jRmzFliBu5Q1RBO+EFzsDL/E0LBA0jc0lnWvaCH6fjbm3WPQQgXk 8vew== MIME-Version: 1.0 X-Received: by 10.50.152.169 with SMTP id uz9mr5407597igb.15.1365373468957; Sun, 07 Apr 2013 15:24:28 -0700 (PDT) Received: by 10.231.71.198 with HTTP; Sun, 7 Apr 2013 15:24:28 -0700 (PDT) In-Reply-To: <20130407.232029.361611394.mbj@tail-f.com> References: <20130407171917.GA12792@elstar.local> <20130407.232029.361611394.mbj@tail-f.com> Date: Sun, 7 Apr 2013 15:24:28 -0700 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQkAxfUNOH7+sUIWQ+ePFzWRvl606UPlgO2REGWRCWnequd04gWncc98rPZVaFuLREW5/Gl5 Cc: netmod@ietf.org Subject: Re: [netmod] Fwd: New Version Notification for draft-lhotka-netmod-yang-json-01.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Apr 2013 22:24:30 -0000 On Sun, Apr 7, 2013 at 2:20 PM, Martin Bjorklund wrote: > Andy Bierman wrote: >> On Sun, Apr 7, 2013 at 10:19 AM, Juergen Schoenwaelder >> wrote: >> > On Sun, Apr 07, 2013 at 09:15:21AM -0700, Andy Bierman wrote: >> > >> >> I think the NETCONF model works better for configuration management. >> >> There is a huge difference between JSON Patch and NETCONF: >> >> * NETCONF applies N edits within 1 request in no specified >> >> order to the target datastore, and all validation is against the target >> >> * JSON Patch applies N edits within 1 request in sequential order. >> >> The first edit is validated against the target which produces a >> >> temporary >> >> result datastore R(n). Each edit(n+1) is validated against datastore >> >> R(n). >> >> >> > >> > Andy, can you point us to where this is specified for JSON patch? Do >> > they really have the same notion of 'validation' that NETCONF has? >> >> They have a notion that the operations are performed sequentially >> and value tests can be done against intermediate steps (RFC 6902, sec. 3). >> Even if just the final result is validated wrt/ datastore checks, the field >> validation and the individual "test" operations within the patch may >> need to be done on intermediate results. > > I do not understand this. Why can't we say that the final result is > validated and applied to the datastore? What is the problem with > field validation and "test"? The "test" operation is an equals-test on the previous result in the sequence. It is not a test on the end-result. The JSON Patch edit list can be a random sequence of edits, add then delete, then add the same entry, set the value to 10, test for 10, set the value to 20, test for 20, etc. I guess if the server looked at the edit as being only the final result of the atomic PATCH operation and recorded edits according to the diffs it finds and applies the edits to the system any way it wants, then this would be OK. The server does not have to preserve intermediate edits in the sys-config-change notifications. E.g., a 2 edit patch like "add /top/a; remove /top/a" can result in a NO-OP on the server. > >> The server should be the one that figures out the order and >> normalization of edits. I prefer the current NETCONF edit >> model and see no reason to change it. I'm just looking for more >> efficient message encoding formats than XML, not a server re-design. > > +1 > > > /martin Andy From j.schoenwaelder@jacobs-university.de Mon Apr 8 01:14:46 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF1CD21F9330 for ; Mon, 8 Apr 2013 01:14:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.149 X-Spam-Level: X-Spam-Status: No, score=-103.149 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KoAybXKZ-V0l for ; Mon, 8 Apr 2013 01:14:45 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id C3C8921F9322 for ; Mon, 8 Apr 2013 01:14:43 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0BF5B20C26; Mon, 8 Apr 2013 10:14:39 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 5CDXYxnFu_Jk; Mon, 8 Apr 2013 10:14:38 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 71FD620C24; Mon, 8 Apr 2013 10:14:38 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 6204C257A4F5; Mon, 8 Apr 2013 10:14:46 +0200 (CEST) Date: Mon, 8 Apr 2013 10:14:46 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20130408081445.GB14225@elstar.local> Mail-Followup-To: Andy Bierman , Martin Bjorklund , lhotka@nic.cz, netmod@ietf.org References: <20130407171917.GA12792@elstar.local> <20130407.232029.361611394.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] Fwd: New Version Notification for draft-lhotka-netmod-yang-json-01.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2013 08:14:47 -0000 On Sun, Apr 07, 2013 at 03:24:28PM -0700, Andy Bierman wrote: > > I guess if the server looked at the edit as being only > the final result of the atomic PATCH operation and > recorded edits according to the diffs it finds and applies the edits > to the system any way it wants, then this would be OK. > Yes, this is how I tried to look at things. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From lhotka@nic.cz Mon Apr 8 02:23:44 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 906AB21F85BF for ; Mon, 8 Apr 2013 02:23:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.095 X-Spam-Level: X-Spam-Status: No, score=-1.095 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_EQ_CZ=0.904, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pvKSv-eordPI for ; Mon, 8 Apr 2013 02:23:44 -0700 (PDT) Received: from trail.lhotka.name (nat-5.bravonet.cz [77.48.224.5]) by ietfa.amsl.com (Postfix) with ESMTP id ECECA21F8536 for ; Mon, 8 Apr 2013 02:23:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 29E2654025F for ; Mon, 8 Apr 2013 11:23:37 +0200 (CEST) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4fGE9TaI3kFO for ; Mon, 8 Apr 2013 11:23:30 +0200 (CEST) Received: from localhost (unknown [217.31.207.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 9CD13540189 for ; Mon, 8 Apr 2013 11:23:25 +0200 (CEST) From: Ladislav Lhotka To: netmod@ietf.org In-Reply-To: References: <201304061756.r36HuLRm087531@idle.juniper.net> <6CBAC5E7-DD1F-4C6C-8290-9091132C87AD@nic.cz> User-Agent: Notmuch/0.15.2+56~gf55b35b (http://notmuchmail.org) Emacs/23.3.50.1 (i386-apple-darwin9.8.0) Mail-Followup-To: netmod@ietf.org Date: Mon, 08 Apr 2013 11:23:24 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [netmod] Fwd: New Version Notification for draft-lhotka-netmod-yang-json-01.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2013 09:23:44 -0000 Andy Bierman writes: >>> I don't know if this edit model is compatible with the NETCONF >>> datastores. If the only thing going on were simple patches >>> to a document, then it would be easy. But a NETCONF >>> datastore is the tip of the iceberg -- the underlying system >>> takes those edits and changes network behavior. >>> It could be impossible to to know if result N will be valid >>> until an attempt to commit that change is made. >>> This has always been the flaw with pretending the datastore >>> is just an XML instance document. >> >> Validation always has some scope and limits. A configuration that is perfectly OK from the point of view of an individual router can still break the network. >> > > This has nothing to do with the problem. I think it does have, in the sense that it is up to the server to accept or reject a request, be it for a stupid typo or very tricky run-time error. > >> But I think that RFC 5789 (HTTP PATCH) addresses all kinds of errors, even run-time. >> > > I think the NETCONF model works better for configuration management. > There is a huge difference between JSON Patch and NETCONF: > * NETCONF applies N edits within 1 request in no specified > order to the target datastore, and all validation is against the target > * JSON Patch applies N edits within 1 request in sequential order. > The first edit is validated against the target which produces a temporary > result datastore R(n). Each edit(n+1) is validated against datastore R(n). This is not necessarily true. HTTP PATCH requires the patch request to be atomic, so that it is either applied or rejected in its entirety, and a partially patched resource must not be served to anybody else. I don't see anything that prevents the server to perform just a single validation on the final patched contents. Of course, other errors may occur in the middle of JSON Patch processing (including failed "test" operation). Lada > > I suppose only server developers understand the impact of this change, > but IMO the NETCONF edit model is much better for CM use-cases > and much easier to implement. > > I am interested in maintaining compatibility with NETCONF servers > with any new protocol or message encoding. > >> Lada >> > > Andy -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From lhotka@nic.cz Mon Apr 8 02:25:56 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A419921F934D for ; Mon, 8 Apr 2013 02:25:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.795 X-Spam-Level: X-Spam-Status: No, score=-0.795 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HOST_EQ_CZ=0.904, J_CHICKENPOX_23=0.6, J_CHICKENPOX_34=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lREiVHPlNtbG for ; Mon, 8 Apr 2013 02:25:55 -0700 (PDT) Received: from trail.lhotka.name (nat-5.bravonet.cz [77.48.224.5]) by ietfa.amsl.com (Postfix) with ESMTP id DA94421F871C for ; Mon, 8 Apr 2013 02:25:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 1A25E54025F for ; Mon, 8 Apr 2013 11:25:54 +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 n0sVRhYX4dm4 for ; Mon, 8 Apr 2013 11:25:47 +0200 (CEST) Received: from localhost (unknown [217.31.207.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 470C6540189 for ; Mon, 8 Apr 2013 11:25:47 +0200 (CEST) From: Ladislav Lhotka To: netmod@ietf.org In-Reply-To: <20130407.231853.374864263.mbj@tail-f.com> References: <20130407171917.GA12792@elstar.local> <20130407200414.GA13081@elstar.local> <20130407.231853.374864263.mbj@tail-f.com> User-Agent: Notmuch/0.15.2+56~gf55b35b (http://notmuchmail.org) Emacs/23.3.50.1 (i386-apple-darwin9.8.0) Mail-Followup-To: netmod@ietf.org Date: Mon, 08 Apr 2013 11:25:46 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [netmod] Fwd: New Version Notification for draft-lhotka-netmod-yang-json-01.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2013 09:25:56 -0000 Martin Bjorklund writes: > Juergen Schoenwaelder wrote: >> On Sun, Apr 07, 2013 at 11:54:41AM -0700, Andy Bierman wrote: >> > > >> > > Andy, can you point us to where this is specified for JSON patch? Do >> > > they really have the same notion of 'validation' that NETCONF has? >> > >> > They have a notion that the operations are performed sequentially >> > and value tests can be done against intermediate steps (RFC 6902, sec. 3). >> > Even if just the final result is validated wrt/ datastore checks, the field >> > validation and the individual "test" operations within the patch may >> > need to be done on intermediate results. >> > >> > The server should be the one that figures out the order and >> > normalization of edits. I prefer the current NETCONF edit >> > model and see no reason to change it. I'm just looking for more >> > efficient message encoding formats than XML, not a server re-design. >> >> Do we actually have evidence that applications out there make use of >> the NETCONF edit model? There is complexity associated with the >> ability to send an arbitrarily complex edit-config to a device. > > We make heavy use of it! The complexity shows up when we have to deal > with devices that do *not* support this model. Given an arbitrary > changeset, figuring out which CLI commands / SNMP SETs / REST > PUT,POST,PATCH you have to send, and most importantly, in which > order to send them is terribly tricky in the general case. But isn't it because there is no standardized API? 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 bclaise@cisco.com Mon Apr 8 07:12:01 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BCB121F94C3; Mon, 8 Apr 2013 07:12:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.979 X-Spam-Level: X-Spam-Status: No, score=-9.979 tagged_above=-999 required=5 tests=[AWL=0.319, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WdY+b8RggFRe; Mon, 8 Apr 2013 07:12:00 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id D6C0E21F935A; Mon, 8 Apr 2013 07:11:50 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r38E1nGt024009; Mon, 8 Apr 2013 16:01:49 +0200 (CEST) Received: from [10.60.67.87] (ams-bclaise-8916.cisco.com [10.60.67.87]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r38E1XsT016387; Mon, 8 Apr 2013 16:01:44 +0200 (CEST) Message-ID: <5162CD72.9050201@cisco.com> Date: Mon, 08 Apr 2013 16:00:18 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: NETMOD Working Group , NETCONF References: <5162CBD4.9080708@cisco.com> In-Reply-To: <5162CBD4.9080708@cisco.com> X-Forwarded-Message-Id: <5162CBD4.9080708@cisco.com> Content-Type: multipart/mixed; boundary="------------030606000503050304000603" Subject: [netmod] =?iso-8859-1?q?Fwd=3A_=5Bi2rs=5D_I2RS_OPS_technical_advi?= =?iso-8859-1?q?sor=3A_J=FCrgen_Sch=F6nw=E4lder?= X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2013 14:12:01 -0000 This is a multi-part message in MIME format. --------------030606000503050304000603 Content-Type: multipart/alternative; boundary="------------050305080708050008050002" --------------050305080708050008050002 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit FYI. Regards, Benoit -------- Original Message -------- Subject: [i2rs] I2RS OPS technical advisor: Jürgen Schönwälder Date: Mon, 08 Apr 2013 15:53:24 +0200 From: Benoit Claise To: rtg-ads@tools.ietf.org CC: ops-ads@tools.ietf.org , Juergen Schoenwaelder , i2rs-chairs@ietf.org, i2rs@ietf.org Dear all, I would like to announce Jürgen Schönwälder as the I2RS OPS technical advisor. Jürgen is very knowledgeable in OPS in general, in NETCONF/YANG and SNMP/MIB, and in data modeling in general. Exactly like he did in the recent LMAP BoF, he will be able to help with the pros and cons of the different OPS protocols ... Also, let me stress an important aspect behind Jürgen's selection as OPS technical advisor: he's not biased. Even if he is one of the netmod chairs, his job doesn't depend on the success of a particular solution. Bottom line: I'm sure Jürgen will do an excellent job. He will be monitoring the I2RS progress, but don't hesitate to involve him in the OPS-related discussions. The agreement with Jürgen is that he will not be doing this job /ad vitam æternam/. That makes sense: once the I2RS use cases and requirements are done, and that the protocol and data model are selected, the OPS technical advisor job should be done. The I2RS charter page has been updated. Regards, Benoit (OPS AD° --------------050305080708050008050002 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit FYI.

Regards, Benoit


-------- Original Message --------
Subject: [i2rs] I2RS OPS technical advisor: Jürgen Schönwälder
Date: Mon, 08 Apr 2013 15:53:24 +0200
From: Benoit Claise <bclaise@cisco.com>
To: rtg-ads@tools.ietf.org <rtg-ads@tools.ietf.org>
CC: ops-ads@tools.ietf.org <ops-ads@tools.ietf.org>, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>, i2rs-chairs@ietf.org, i2rs@ietf.org


Dear all,

I would like to announce Jürgen Schönwälder as the I2RS OPS technical advisor.

Jürgen is very knowledgeable in OPS in general, in NETCONF/YANG and SNMP/MIB, and in data modeling in general.
Exactly like he did in the recent LMAP BoF, he will be able to help with the pros and cons of the different OPS protocols ... Also, let me stress an important aspect behind Jürgen's selection as OPS technical advisor: he's not biased. Even if he is one of the netmod chairs, his job doesn't depend on the success of a particular solution.
Bottom line: I'm sure Jürgen will do an excellent job. He will be monitoring the I2RS progress, but don't hesitate to involve him in the OPS-related discussions.

The agreement with Jürgen is that he will not be doing this job ad vitam æternam. 
That makes sense: once the I2RS use cases and requirements are done, and that the protocol and data model are selected, the OPS technical advisor job should be done.

The I2RS charter page has been updated.

Regards, Benoit (OPS AD°


--------------050305080708050008050002-- --------------030606000503050304000603 Content-Type: text/plain; charset=windows-1252; name="Attached Message Part" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Attached Message Part" _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs --------------030606000503050304000603-- From bclaise@cisco.com Mon Apr 8 09:50:10 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02B9121F9298 for ; Mon, 8 Apr 2013 09:50:10 -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=[AWL=0.446, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bODa8iUjgGc6 for ; Mon, 8 Apr 2013 09:50:08 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 1B99121F84E3 for ; Mon, 8 Apr 2013 09:50:06 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r38Go390010356; Mon, 8 Apr 2013 18:50:03 +0200 (CEST) Received: from [10.60.67.87] (ams-bclaise-8916.cisco.com [10.60.67.87]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r38Gnb5v015214; Mon, 8 Apr 2013 18:49:52 +0200 (CEST) Message-ID: <5162F4D6.6020009@cisco.com> Date: Mon, 08 Apr 2013 18:48:22 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Martin Bjorklund References: <5150CF8E.8090006@cisco.com> <20130402.230149.92811084.mbj@tail-f.com> In-Reply-To: <20130402.230149.92811084.mbj@tail-f.com> Content-Type: multipart/alternative; boundary="------------020000080900060107040406" Cc: netmod@ietf.org Subject: Re: [netmod] AD review of draft-ietf-netmod-interfaces-cfg-09 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2013 16:50:10 -0000 This is a multi-part message in MIME format. --------------020000080900060107040406 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Martin, > Hi, > > Benoit Claise wrote: >> Dear all, >> >> Disclaimer: >> - If any of those points have been discussed on the mailing list, don't >> - hesitate to let me know. >> - I probably should have mentioned some of these documents during the last >> - call. Sorry. After a year in the new position, I'm still playing catch up >> - mode. >> >> _CLARIFYING QUE__STION__S_ >> >> - Section 3.1 The interface List >> >> The data model for interfaces presented in this document uses a flat >> list of interfaces. Each interface in the list is identified by its >> name. Furthermore, each interface has a mandatory "type" leaf, and a >> "location" leaf. The combination of "type" and "location" is unique >> within the interface list. >> >> First time I read this, I thought the location was mandatory. >> However, it's not: >> >> +--rw interfaces >> +--rw interface [name] >> +--rw name string >> +--rw description? string >> +--rw type ianaift:iana-if-type >> +--rw location? string >> >> Proposal: >> OLD: >> >> Furthermore, each interface has a mandatory "type" leaf, and a >> "location" leaf. >> >> NEW: >> Furthermore, each interface has a mandatory "type" leaf, and an optional >> "location" leaf. > Ok, will fix. > >> When I understood that the location is optional, I have some difficulties to >> understand the following sentence >> "The combination of "type" and "location" is unique within the interface list." >> when the location is an optional field. >> >> - How does the mechanism above apply to subinterfaces? example: Interface >> Ethernet 0.1? >> >> I believe it deserves some explanation. Now, it's true that the RFC 2863 >> doesn't mention the notion of subinterface, and I believe that the notion of >> sub-layer (in RFC 2863) and interface layering (in >> draft-ietf-netmod-interfaces-cfg) notions don't apply to subinterfaces? I would >> be happy to stand corrected. > It all depends what you put in your definition of a subinterface. > This document does not mention subinterfaces at all. It just talks > about how interfaces are layered. Having at least one example on how this module is supposed to work with sub-interfaces is required IMHO, specifically because of the location related sentences: The combination of "type" and "location" is unique within the interface list. ... The "location" leaf is a string. It is optional in the data model, but if the type represents a physical interface, it is mandatory. See below. > >> For example, how should I understand the following sentence, if we speak about >> an subinterface >> >> The "location" leaf is a string. It is optional in the data model, >> but if the type represents a physical interface, it is mandatory. >> >> Does the subinterface really _represent _a physical interface? > If you have your subinterface represent a vlan, it would not. In this > case, the subinterface would be layered on top of another (physical > maybe) interface. So should subinterface location be the location of the physical interface? No, it can't because of The combination of "type" and "location" is unique within the interface list You see, I'm slightly confused. > >> - One of the real pain point of RFC 2863 is the ifIndex non persistence. >> >> "Its value ranges between 1 and the value of ifNumber. The >> value for each interface must remain constant at least from >> one re-initialization of the entity's network management >> system to the next re-initialization." >> >> >> Can we assume that the leaf name will remain constant after a >> "re-initialization of the entity's network management system", and that only >> the leaf if-index could change. > Yes! With NETCONF/YANG, the config is persistently stored (which > config depends on the capabilities). Actually, which RFC mentions that the config data is persistent? > >> Or we can't assume anything, and the NMS must rediscover everything. So same >> pain point as SNMP? >> Or should the NMS compare the config (which contains the ifName/leaf-name), and >> if they're unchanged after a reboot, the NMS just have query leaf if-index for >> the mapping to the MIB module? >> Could/should we say a few words about this in the draft? > I guess we could say that the if-index value may change, but in > general I am not too fond of redundant specifications in new > documents... I don't want to spell out all the semantics of ifIndex. > Maybe something like this: > > Note that the ifIndex value for a particular interface may change > if the entity's network management system is re-initialized. > > But I am not sure if this is what you meant? Not really. The interface "key" in SNMP is the ifIndex: the ifTable is rediscovered each time the device reboots. The interface "key" in YANG is the interface name. How do I know, from the NETFCONF client point of view, if the interface name is persistent? > >> _EDITORIAL:_ >> >> - You might to stress in the section 4 that the non HC counters are not >> - modeled. >> >> | in-octets | ifHCInOctets | >> | in-unicast-pkts | ifHCInUcastPkts | >> | in-broadcast-pkts | ifHCInBroadcastPkts | >> | in-multicast-pkts | ifHCInMulticastPkts | >> >> Btw, could this be a problem for sensors? > 64 vs 32 bit counters were discussed in the thread starting at > http://www.ietf.org/mail-archive/web/netmod/current/msg06943.html. Ok, if this is what the WG consensus... > > >> leaf last-change { >> type yang:date-and-time; >> config false; >> description >> "The time the interface entered its current operational >> state. If the current state was entered prior to the >> last re-initialization of the local network management >> subsystem, then this node is not present."; >> reference >> "RFC 2863 : The Interfaces >> Group MIB - ifLastChange"; >> } >> >> From the date-and-time definition in RFC 6021, do I understand correctly that >> the date-and-time are absolute time (and not the equivalent of the sysUpTime, >> as mentioned in ifLastChange). >> What if the device doesn't have any absolute time, but simply the sysUpTime? >> Same question for leaf discontinuity-time > I think this was also discussed in the thread above. It was suggested > that even smaller devices (that still implement NETCONF and these data > models) have support for absolute times these days. Ok. Regards, Benoit --------------020000080900060107040406 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Hi Martin,

Hi,

Benoit Claise <bclaise@cisco.com> wrote:

Dear all,

Disclaimer:
- If any of those points have been discussed on the mailing list, don't
- hesitate to let me know.
- I probably should have mentioned some of these documents during the last
- call. Sorry. After a year in the new position, I'm still playing catch up
- mode.

_CLARIFYING QUE__STION__S_

- Section 3.1 The interface List

   The data model for interfaces presented in this document uses a flat
   list of interfaces.  Each interface in the list is identified by its
   name.  Furthermore, each interface has a mandatory "type" leaf, and a
   "location" leaf.  The combination of "type" and "location" is unique
   within the interface list.

First time I read this, I thought the location was mandatory.
However, it's not:

      +--rw interfaces
         +--rw interface [name]
            +--rw name                        string
            +--rw description?                string
            +--rw type                        ianaift:iana-if-type
            +--rw location?                   string

Proposal:
OLD:
	
   Furthermore, each interface has a mandatory "type" leaf, and a
   "location" leaf.

NEW:
   Furthermore, each interface has a mandatory "type" leaf, and an optional
   "location" leaf.

Ok, will fix.


When I understood that the location is optional, I have some difficulties to
understand the following sentence
"The combination of "type" and "location" is unique within the interface list."
when the location is an optional field.

- How does the mechanism above apply to subinterfaces? example: Interface
  Ethernet 0.1?

I believe it deserves some explanation. Now, it's true that the RFC 2863
doesn't mention the notion of subinterface, and I believe that the notion of
sub-layer (in RFC 2863) and interface layering (in
draft-ietf-netmod-interfaces-cfg) notions don't apply to subinterfaces? I would
be happy to stand corrected.

It all depends what you put in your definition of a subinterface.
This document does not mention subinterfaces at all.  It just talks
about how interfaces are layered.
Having at least one example on how this module is supposed to work with sub-interfaces is required IMHO, specifically because of the location related sentences: 
The combination of "type" and "location" is unique within the interface list.

...

The "location" leaf is a string.  It is optional in the data model,
but if the type represents a physical interface, it is mandatory.
See below.

    

    

    

      



      

        
For example, how should I understand the following sentence, if we speak about
an subinterface

   The "location" leaf is a string.  It is optional in the data model,
   but if the type represents a physical interface, it is mandatory.

Does the subinterface really _represent _a physical interface?


      

      
If you have your subinterface represent a vlan, it would not.  In this
case, the subinterface would be layered on top of another (physical
maybe) interface.

    

    So should subinterface location be the location of the physical
    interface?

    No, it can't because of   

    

      
The combination of "type" and "location" is unique within the interface list

    

    You see, I'm slightly confused.

    


      

        
- One of the real pain point of RFC 2863 is the ifIndex non persistence.

      "Its value ranges between 1 and the value of ifNumber.  The
      value for each interface must remain constant at least from
      one re-initialization of the entity's network management
      system to the next re-initialization."


Can we assume that the leaf name will remain constant after a
"re-initialization of the entity's network management system", and that only
the leaf if-index could change.


      

      
Yes!  With NETCONF/YANG, the config is persistently stored (which
config depends on the capabilities).

    

    Actually, which RFC mentions that the config data is persistent?

    

      



      

        
Or we can't assume anything, and the NMS must rediscover everything. So same
pain point as SNMP?
Or should the NMS compare the config (which contains the ifName/leaf-name), and
if they're unchanged after a reboot, the NMS just have query leaf if-index for
the mapping to the MIB module?
Could/should we say a few words about this in the draft?


      

      
I guess we could say that the if-index value may change, but in
general I am not too fond of redundant specifications in new
documents... I don't want to spell out all the semantics of ifIndex.
Maybe something like this:

  Note that the ifIndex value for a particular interface may change
  if the entity's network management system is re-initialized.

But I am not sure if this is what you meant?

    

    Not really.

    The interface "key" in SNMP is the ifIndex: the ifTable is
    rediscovered each time the device reboots.

    The interface "key" in YANG is the interface name. How do I know,
    from the NETFCONF client point of view, if the interface name is
    persistent? 

    

      



      

        
_EDITORIAL:_

- You might to stress in the section 4 that the non HC counters are not
- modeled.

       | in-octets                        | ifHCInOctets           |
       | in-unicast-pkts                  | ifHCInUcastPkts        |
       | in-broadcast-pkts                | ifHCInBroadcastPkts    |
       | in-multicast-pkts                | ifHCInMulticastPkts    |

Btw, could this be a problem for sensors?


      

      
64 vs 32 bit counters were discussed in the thread starting at
http://www.ietf.org/mail-archive/web/netmod/current/msg06943.html.

    

    Ok, if this is what the WG consensus...

    

      




      

        
       leaf last-change {
           type yang:date-and-time;
           config false;
           description
             "The time the interface entered its current operational
              state.  If the current state was entered prior to the
              last re-initialization of the local network management
              subsystem, then this node is not present.";
           reference
             "RFC 2863 <http://tools.ietf.org/html/rfc2863>: The Interfaces
             Group MIB - ifLastChange";
         }

>From the date-and-time definition in RFC 6021, do I understand correctly that
the date-and-time are absolute time (and not the equivalent of the sysUpTime,
as mentioned in ifLastChange).
What if the device doesn't have any absolute time, but simply the sysUpTime?
Same question for leaf discontinuity-time


      

      
I think this was also discussed in the thread above.  It was suggested
that even smaller devices (that still implement NETCONF and these data
models) have support for absolute times these days.

    

    Ok.

    

    Regards, Benoit

  


--------------020000080900060107040406--

From j.schoenwaelder@jacobs-university.de  Mon Apr  8 11:34:17 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCC9D21F871C for ; Mon,  8 Apr 2013 11:34:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.174
X-Spam-Level: 
X-Spam-Status: No, score=-103.174 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LolfxEswMOkO for ; Mon,  8 Apr 2013 11:34:16 -0700 (PDT)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 600CC21F8681 for ; Mon,  8 Apr 2013 11:34:16 -0700 (PDT)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id B250220BFB; Mon,  8 Apr 2013 20:34:14 +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 rrbcnLXb-qy8; Mon,  8 Apr 2013 20:34:14 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3571420BF9; Mon,  8 Apr 2013 20:34:14 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 59C51257EC4C; Mon,  8 Apr 2013 20:34:22 +0200 (CEST)
Date: Mon, 8 Apr 2013 20:34:21 +0200
From: Juergen Schoenwaelder 
To: Benoit Claise 
Message-ID: <20130408183421.GA16360@elstar.local>
Mail-Followup-To: Benoit Claise , Martin Bjorklund , NETMOD Working Group 
References: <514C8C6F.60704@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <514C8C6F.60704@cisco.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: NETMOD Working Group 
Subject: Re: [netmod] AD review of draft-ietf-netmod-iana-if-type-04
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 08 Apr 2013 18:34:17 -0000

On Fri, Mar 22, 2013 at 05:53:03PM +0100, Benoit Claise wrote:
> Hi Martin, netmod participants,
> 
> - IANAifType-MIB http://www.iana.org/assignments/smi-numbers/smi-numbers.xml
> There is a new value 273, which should be added to the draft, at
> first glance.
> Note: this entry 273 is called "Reserved". This is a weird name,
> because there is RFC6825 next to it.
> Am I correct that, if a second entry is called "Reserved", the enum
> would break?

This issue has been further discussed between Benoit, Dan Romascanu
(the expert for the ifType registry), the NETMOD chairs and IANA.  We
arrived at the conclusion that reserved ifType numbers should show up
in both the YANG module and the SNMP module. (Technically, IANA
maintains a primary registry and two serializations, one in SMIv2
format and one in YANG format.) In order to ensure that we have unique
'labels' for the allocated numbers, IANA is expected to use 'labels'
of the form reserverXYZ where XYZ is replaced by the allocated number.
In other words, the entry for 273 would be something like this:

         enum "reserved272" {
           value 272;
           description
             "Reserved by IANA";
         }

Please speak up now if you believe this is not a workable solution.
Martin, if there are no objections raised within a few days, please
produce a new I-D which includes this allocation and perhaps 1-2
sentences that help IANA understand that reserved ifTypes should be
treated as described above. (Perhaps you can draft the edits and send
them to the list for review before posting a new I-D.)

/js

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

From mbj@tail-f.com  Mon Apr  8 12:33:08 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 861A921F93E8 for ; Mon,  8 Apr 2013 12:33:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.74
X-Spam-Level: 
X-Spam-Status: No, score=-1.74 tagged_above=-999 required=5 tests=[AWL=0.306,  BAYES_00=-2.599, HELO_MISMATCH_COM=0.553]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T-9bQLY7L4vW for ; Mon,  8 Apr 2013 12:33:03 -0700 (PDT)
Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 16D2D21F9125 for ; Mon,  8 Apr 2013 12:33:03 -0700 (PDT)
Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id A16C81200AE5; Mon,  8 Apr 2013 21:33:00 +0200 (CEST)
Date: Mon, 08 Apr 2013 21:33:00 +0200 (CEST)
Message-Id: <20130408.213300.287705284.mbj@tail-f.com>
To: j.schoenwaelder@jacobs-university.de
From: Martin Bjorklund 
In-Reply-To: <20130408183421.GA16360@elstar.local>
References: <514C8C6F.60704@cisco.com> <20130408183421.GA16360@elstar.local>
X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Cc: netmod@ietf.org
Subject: Re: [netmod] AD review of draft-ietf-netmod-iana-if-type-04
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 08 Apr 2013 19:33:08 -0000

Juergen Schoenwaelder  wrote:
> On Fri, Mar 22, 2013 at 05:53:03PM +0100, Benoit Claise wrote:
> > Hi Martin, netmod participants,
> > 
> > - IANAifType-MIB http://www.iana.org/assignments/smi-numbers/smi-numbers.xml
> > There is a new value 273, which should be added to the draft, at
> > first glance.
> > Note: this entry 273 is called "Reserved". This is a weird name,
> > because there is RFC6825 next to it.
> > Am I correct that, if a second entry is called "Reserved", the enum
> > would break?
> 
> This issue has been further discussed between Benoit, Dan Romascanu
> (the expert for the ifType registry), the NETMOD chairs and IANA.  We
> arrived at the conclusion that reserved ifType numbers should show up
> in both the YANG module and the SNMP module. (Technically, IANA
> maintains a primary registry and two serializations, one in SMIv2
> format and one in YANG format.) In order to ensure that we have unique
> 'labels' for the allocated numbers, IANA is expected to use 'labels'
> of the form reserverXYZ where XYZ is replaced by the allocated number.
> In other words, the entry for 273 would be something like this:
> 
>          enum "reserved272" {
>            value 272;
>            description
>              "Reserved by IANA";
>          }
> 
> Please speak up now if you believe this is not a workable solution.

At first glance, this seems weird.  The point of reserving a value in
a registry is to make sure the value (or label) is not used by anyone
else.  But since it is reserved it would not be used.  So when it
actually shows up like this with a dummy label it looks quite
confusing.

>From a technical YANG point of view, this is problematic, since you
are not allowed to modify the enum label, one published (see section
10 of RFC 6020).


/martin

From j.schoenwaelder@jacobs-university.de  Mon Apr  8 12:45:00 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F4C021F93C4 for ; Mon,  8 Apr 2013 12:45:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.189
X-Spam-Level: 
X-Spam-Status: No, score=-103.189 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hfh6zN0IVYuN for ; Mon,  8 Apr 2013 12:44:59 -0700 (PDT)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id D0BBB21F905A for ; Mon,  8 Apr 2013 12:44:58 -0700 (PDT)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 115DA20BED; Mon,  8 Apr 2013 21:44:58 +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 hdY5yKSyDXOo; Mon,  8 Apr 2013 21:44: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 5D12620BEC; Mon,  8 Apr 2013 21:44:57 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 39A15257F05F; Mon,  8 Apr 2013 21:45:04 +0200 (CEST)
Date: Mon, 8 Apr 2013 21:45:03 +0200
From: Juergen Schoenwaelder 
To: Martin Bjorklund 
Message-ID: <20130408194503.GA16659@elstar.local>
Mail-Followup-To: Martin Bjorklund , bclaise@cisco.com, netmod@ietf.org
References: <514C8C6F.60704@cisco.com> <20130408183421.GA16360@elstar.local> <20130408.213300.287705284.mbj@tail-f.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20130408.213300.287705284.mbj@tail-f.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: netmod@ietf.org
Subject: Re: [netmod] AD review of draft-ietf-netmod-iana-if-type-04
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 08 Apr 2013 19:45:00 -0000

On Mon, Apr 08, 2013 at 09:33:00PM +0200, Martin Bjorklund wrote:
> Juergen Schoenwaelder  wrote:
> > On Fri, Mar 22, 2013 at 05:53:03PM +0100, Benoit Claise wrote:
> > > Hi Martin, netmod participants,
> > > 
> > > - IANAifType-MIB http://www.iana.org/assignments/smi-numbers/smi-numbers.xml
> > > There is a new value 273, which should be added to the draft, at
> > > first glance.
> > > Note: this entry 273 is called "Reserved". This is a weird name,
> > > because there is RFC6825 next to it.
> > > Am I correct that, if a second entry is called "Reserved", the enum
> > > would break?
> > 
> > This issue has been further discussed between Benoit, Dan Romascanu
> > (the expert for the ifType registry), the NETMOD chairs and IANA.  We
> > arrived at the conclusion that reserved ifType numbers should show up
> > in both the YANG module and the SNMP module. (Technically, IANA
> > maintains a primary registry and two serializations, one in SMIv2
> > format and one in YANG format.) In order to ensure that we have unique
> > 'labels' for the allocated numbers, IANA is expected to use 'labels'
> > of the form reserverXYZ where XYZ is replaced by the allocated number.
> > In other words, the entry for 273 would be something like this:
> > 
> >          enum "reserved272" {
> >            value 272;
> >            description
> >              "Reserved by IANA";
> >          }
> > 
> > Please speak up now if you believe this is not a workable solution.
> 
> At first glance, this seems weird.  The point of reserving a value in
> a registry is to make sure the value (or label) is not used by anyone
> else.  But since it is reserved it would not be used.  So when it
> actually shows up like this with a dummy label it looks quite
> confusing.
> 
> From a technical YANG point of view, this is problematic, since you
> are not allowed to modify the enum label, one published (see section
> 10 of RFC 6020).

Oops, we apparently missed that part of YANG update rules which is
different from the SMIv2 update rules. So what would you propose?
Have reserved values marked only in the registry but not show up in
the SMIv2 / YANG serializations? I think someone involved in the
discussion was arguing against this solution. I need to check.

/js

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

From mbj@tail-f.com  Mon Apr  8 13:16:24 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86E9021F8E06 for ; Mon,  8 Apr 2013 13:16:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.791
X-Spam-Level: 
X-Spam-Status: No, score=-1.791 tagged_above=-999 required=5 tests=[AWL=0.255,  BAYES_00=-2.599, HELO_MISMATCH_COM=0.553]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KqbycYDqKaGw for ; Mon,  8 Apr 2013 13:16:23 -0700 (PDT)
Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 8FD3521F8DB2 for ; Mon,  8 Apr 2013 13:16:21 -0700 (PDT)
Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id A22141200D46; Mon,  8 Apr 2013 22:16:20 +0200 (CEST)
Date: Mon, 08 Apr 2013 22:16:20 +0200 (CEST)
Message-Id: <20130408.221620.378835500.mbj@tail-f.com>
To: j.schoenwaelder@jacobs-university.de
From: Martin Bjorklund 
In-Reply-To: <20130408194503.GA16659@elstar.local>
References: <20130408183421.GA16360@elstar.local> <20130408.213300.287705284.mbj@tail-f.com> <20130408194503.GA16659@elstar.local>
X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Cc: netmod@ietf.org
Subject: Re: [netmod] AD review of draft-ietf-netmod-iana-if-type-04
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 08 Apr 2013 20:16:24 -0000

Juergen Schoenwaelder  wrote:
> On Mon, Apr 08, 2013 at 09:33:00PM +0200, Martin Bjorklund wrote:
> > Juergen Schoenwaelder  wrote:
> > > On Fri, Mar 22, 2013 at 05:53:03PM +0100, Benoit Claise wrote:
> > > > Hi Martin, netmod participants,
> > > > 
> > > > - IANAifType-MIB
> > > > - http://www.iana.org/assignments/smi-numbers/smi-numbers.xml
> > > > There is a new value 273, which should be added to the draft, at
> > > > first glance.
> > > > Note: this entry 273 is called "Reserved". This is a weird name,
> > > > because there is RFC6825 next to it.
> > > > Am I correct that, if a second entry is called "Reserved", the enum
> > > > would break?
> > > 
> > > This issue has been further discussed between Benoit, Dan Romascanu
> > > (the expert for the ifType registry), the NETMOD chairs and IANA.  We
> > > arrived at the conclusion that reserved ifType numbers should show up
> > > in both the YANG module and the SNMP module. (Technically, IANA
> > > maintains a primary registry and two serializations, one in SMIv2
> > > format and one in YANG format.) In order to ensure that we have unique
> > > 'labels' for the allocated numbers, IANA is expected to use 'labels'
> > > of the form reserverXYZ where XYZ is replaced by the allocated number.
> > > In other words, the entry for 273 would be something like this:
> > > 
> > >          enum "reserved272" {
> > >            value 272;
> > >            description
> > >              "Reserved by IANA";
> > >          }
> > > 
> > > Please speak up now if you believe this is not a workable solution.
> > 
> > At first glance, this seems weird.  The point of reserving a value in
> > a registry is to make sure the value (or label) is not used by anyone
> > else.  But since it is reserved it would not be used.  So when it
> > actually shows up like this with a dummy label it looks quite
> > confusing.
> > 
> > From a technical YANG point of view, this is problematic, since you
> > are not allowed to modify the enum label, one published (see section
> > 10 of RFC 6020).
> 
> Oops, we apparently missed that part of YANG update rules which is
> different from the SMIv2 update rules. So what would you propose?
> Have reserved values marked only in the registry but not show up in
> the SMIv2 / YANG serializations?

Yes.


/martin

From mbj@tail-f.com  Mon Apr  8 14:38:14 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79D4721F8EAE for ; Mon,  8 Apr 2013 14:38:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.828
X-Spam-Level: 
X-Spam-Status: No, score=-1.828 tagged_above=-999 required=5 tests=[AWL=0.218,  BAYES_00=-2.599, HELO_MISMATCH_COM=0.553]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mpW2Y6bpgDDk for ; Mon,  8 Apr 2013 14:38:13 -0700 (PDT)
Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 832CE21F8EAA for ; Mon,  8 Apr 2013 14:38:13 -0700 (PDT)
Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 278A01200A35; Mon,  8 Apr 2013 23:38:11 +0200 (CEST)
Date: Mon, 08 Apr 2013 23:38:10 +0200 (CEST)
Message-Id: <20130408.233810.311649160.mbj@tail-f.com>
To: bclaise@cisco.com
From: Martin Bjorklund 
In-Reply-To: <5162F4D6.6020009@cisco.com>
References: <5150CF8E.8090006@cisco.com> <20130402.230149.92811084.mbj@tail-f.com> <5162F4D6.6020009@cisco.com>
X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Cc: netmod@ietf.org
Subject: Re: [netmod] AD review of draft-ietf-netmod-interfaces-cfg-09
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 08 Apr 2013 21:38:14 -0000

Benoit Claise  wrote:
> Hi Martin,
> 
> > Hi,
> >
> > Benoit Claise  wrote:
> >> Dear all,
> >>
> >> Disclaimer:
> >> - If any of those points have been discussed on the mailing list, don't
> >> - hesitate to let me know.
> >> - I probably should have mentioned some of these documents during the last
> >> - call. Sorry. After a year in the new position, I'm still playing catch up
> >> - mode.
> >>
> >> _CLARIFYING QUE__STION__S_
> >>
> >> - Section 3.1 The interface List
> >>
> >>     The data model for interfaces presented in this document uses a flat
> >>     list of interfaces.  Each interface in the list is identified by its
> >>     name.  Furthermore, each interface has a mandatory "type" leaf, and a
> >>     "location" leaf.  The combination of "type" and "location" is unique
> >>     within the interface list.
> >>
> >> First time I read this, I thought the location was mandatory.
> >> However, it's not:
> >>
> >>        +--rw interfaces
> >>           +--rw interface [name]
> >>              +--rw name                        string
> >>              +--rw description?                string
> >>              +--rw type                        ianaift:iana-if-type
> >>              +--rw location?                   string
> >>
> >> Proposal:
> >> OLD:
> >> 	
> >>     Furthermore, each interface has a mandatory "type" leaf, and a
> >>     "location" leaf.
> >>
> >> NEW:
> >>     Furthermore, each interface has a mandatory "type" leaf, and an optional
> >>     "location" leaf.
> > Ok, will fix.
> >
> >> When I understood that the location is optional, I have some difficulties to
> >> understand the following sentence
> >> "The combination of "type" and "location" is unique within the interface
> >> list."
> >> when the location is an optional field.
> >>
> >> - How does the mechanism above apply to subinterfaces? example: Interface
> >>    Ethernet 0.1?
> >>
> >> I believe it deserves some explanation. Now, it's true that the RFC 2863
> >> doesn't mention the notion of subinterface, and I believe that the notion of
> >> sub-layer (in RFC 2863) and interface layering (in
> >> draft-ietf-netmod-interfaces-cfg) notions don't apply to subinterfaces? I
> >> would
> >> be happy to stand corrected.
> > It all depends what you put in your definition of a subinterface.
> > This document does not mention subinterfaces at all.  It just talks
> > about how interfaces are layered.
> Having at least one example on how this module is supposed to work with
> sub-interfaces is required IMHO, specifically because of the location related
> sentences:
> 
>    The combination of "type" and "location" is unique within the interface
>    list.
> 
>    ...
> 
>    The "location" leaf is a string.  It is optional in the data model,
>    but if the type represents a physical interface, it is mandatory.
> 
> See below.
> 
> >
> >> For example, how should I understand the following sentence, if we speak
> >> about
> >> an subinterface
> >>
> >>     The "location" leaf is a string.  It is optional in the data model,
> >>     but if the type represents a physical interface, it is mandatory.
> >>
> >> Does the subinterface really _represent _a physical interface?
> > If you have your subinterface represent a vlan, it would not.  In this
> > case, the subinterface would be layered on top of another (physical
> > maybe) interface.
> So should subinterface location be the location of the physical interface?
> No, it can't because of
> 
>    The combination of "type" and "location" is unique within the interface list
> 
> You see, I'm slightly confused.

No, you are right - the location would probably not be set for the
type of subinterface you have in mind.  There are examples of vlan
interfaces in the document.  You may call this a subinterface.  I
don't think there is any defintion of the term subinterface, but I may
be wrong.  So I don't really know what additional info you are looking
for.

> >> - One of the real pain point of RFC 2863 is the ifIndex non persistence.
> >>
> >>        "Its value ranges between 1 and the value of ifNumber.  The
> >>        value for each interface must remain constant at least from
> >>        one re-initialization of the entity's network management
> >>        system to the next re-initialization."
> >>
> >>
> >> Can we assume that the leaf name will remain constant after a
> >> "re-initialization of the entity's network management system", and that only
> >> the leaf if-index could change.
> > Yes!  With NETCONF/YANG, the config is persistently stored (which
> > config depends on the capabilities).
> Actually, which RFC mentions that the config data is persistent?

6241 - but only implicitly.  For example:

   o  startup configuration datastore: The configuration datastore
      holding the configuration loaded by the device when it boots.

> >> Or we can't assume anything, and the NMS must rediscover everything. So same
> >> pain point as SNMP?
> >> Or should the NMS compare the config (which contains the ifName/leaf-name),
> >> and
> >> if they're unchanged after a reboot, the NMS just have query leaf if-index
> >> for
> >> the mapping to the MIB module?
> >> Could/should we say a few words about this in the draft?
> > I guess we could say that the if-index value may change, but in
> > general I am not too fond of redundant specifications in new
> > documents... I don't want to spell out all the semantics of ifIndex.
> > Maybe something like this:
> >
> >    Note that the ifIndex value for a particular interface may change
> >    if the entity's network management system is re-initialized.
> >
> > But I am not sure if this is what you meant?
> Not really.
> The interface "key" in SNMP is the ifIndex: the ifTable is rediscovered each
> time the device reboots.
> The interface "key" in YANG is the interface name. How do I know, from the
> NETFCONF client point of view, if the interface name is persistent?

This is not different from any other configuration node - if a value
has been successfully written to a persistent datastore (startup or
running if startup is not supported), the value is there after a
reboot (unless it has been changed by some other client).  This should
be clear in 6241, but maybe it isn't...



/martin

From andy@yumaworks.com  Mon Apr  8 19:30:03 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FB1B21F8E62 for ; Mon,  8 Apr 2013 19:30:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.888
X-Spam-Level: 
X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[AWL=0.090,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aWwNwUMT3xrJ for ; Mon,  8 Apr 2013 19:30:02 -0700 (PDT)
Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id A391821F8D4E for ; Mon,  8 Apr 2013 19:30:02 -0700 (PDT)
Received: by mail-ie0-f172.google.com with SMTP id c10so7991553ieb.31 for ; Mon, 08 Apr 2013 19:30:02 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type:x-gm-message-state; bh=D8S8JZsKYLtPgSHJKNf3B4HRnSHoot9qJN1Hl1CnHx4=; b=pb1b8YwXmV1WU218vy+R3dEG5+iGMaGxHbsA0X4ZNb1qoS1yKyT+iGUemMbFrdeLxk 1ybFh+rYDTIdYXUPoO3x7/oTi0s1UE9w+dmWVfj71l8ZO4yl2kh/7PTnaOkh+wXw9Znf TFDE+IYIqUolHT1z057SgySj2E5/yjBcOmjSQlK6YyhjFRO3DaXF74Uf51TVfhVymTwU 4qeWIkI69SzibFDyKd1nX/jCIO7v/ErMzc4IAB0tQF+hHrvuXljpKESg+99JIXxlTaxq gRy7CDCs9m6QGTXFb/iNgKTfyQPyNOe1qNCCVway/4+nnH8MnOs7jyZcH8JFTe5nW9x1 0RMw==
MIME-Version: 1.0
X-Received: by 10.50.45.166 with SMTP id o6mr9404383igm.78.1365474602207; Mon, 08 Apr 2013 19:30:02 -0700 (PDT)
Received: by 10.231.11.2 with HTTP; Mon, 8 Apr 2013 19:30:02 -0700 (PDT)
In-Reply-To: <20130409022627.16888.35291.idtracker@ietfa.amsl.com>
References: <20130409022627.16888.35291.idtracker@ietfa.amsl.com>
Date: Mon, 8 Apr 2013 19:30:02 -0700
Message-ID: 
From: Andy Bierman 
To: netmod@ietf.org
Content-Type: text/plain; charset=ISO-8859-1
X-Gm-Message-State: ALoCoQkQdQAe4a25qnG2OUvN46jWApqlLGI80BMRhrqOEsDrLpkFCCvp2u++MCxLo285Qbe+nHfb
Subject: [netmod] Fwd: I-D Action: draft-bierman-netconf-get2-03.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 09 Apr 2013 02:30:03 -0000

FYI,

I updated the  draft.
References and definitions related to operational state have
been removed since that work is very TBD and new operations
and/or datastores may be needed


Andy



---------- Forwarded message ----------
From:  
Date: Mon, Apr 8, 2013 at 7:26 PM
Subject: I-D Action: draft-bierman-netconf-get2-03.txt
To: i-d-announce@ietf.org



A New Internet-Draft is available from the on-line Internet-Drafts directories.


        Title           : The NETCONF  Operation
        Author(s)       : Andy Bierman
        Filename        : draft-bierman-netconf-get2-03.txt
        Pages           : 28
        Date            : 2013-04-08

Abstract:
   This document describes NETCONF protocol enhancements to improve data
   retrieval capabilities.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-bierman-netconf-get2

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-bierman-netconf-get2-03

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-bierman-netconf-get2-03


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 andy@yumaworks.com  Mon Apr  8 19:31:10 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94AD821F8EE6 for ; Mon,  8 Apr 2013 19:31:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.903
X-Spam-Level: 
X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[AWL=0.075,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K32zSuLiM6xt for ; Mon,  8 Apr 2013 19:31:10 -0700 (PDT)
Received: from mail-ie0-x230.google.com (mail-ie0-x230.google.com [IPv6:2607:f8b0:4001:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id 1F12221F8EDE for ; Mon,  8 Apr 2013 19:31:10 -0700 (PDT)
Received: by mail-ie0-f176.google.com with SMTP id x14so7741705ief.7 for ; Mon, 08 Apr 2013 19:31:09 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=Tbr40o+FQTi6u2Fg8qdcfO3CTYQj1iTQb8BdFlb52dM=; b=UA4FRWKlnRTVESwe+mzWtDEonQYEkNWML318QLpCZJEbzBnvp70b74lZQb48vHNV8Y OZRuxKJZu5Ak5Jv4crh6JHl04NBNoHcz0dsC6DNm58I0A0wzVvSzxAzZ6NFPbVjR5QoN i9LgRU0ub04eiv1WJaeieCP5LF5WDgwpIqG1f51t8Lpkny3mcZ4k/RguorWwpq1zrzkr aZ2Ch+TLUiIA7MLfG0ZX8vRdn2gHCm7Rn3TP4Xdaj7zRB/P3QyGQp+qDquRo6culVgVg f/CGP5azoUQKHL43ziRsTRR8K7CGsJatfKX4dgDzQcuvEuvS9GJ4I5r5X2rBEYOJJF9j MRSw==
MIME-Version: 1.0
X-Received: by 10.50.136.138 with SMTP id qa10mr9082319igb.74.1365474669677; Mon, 08 Apr 2013 19:31:09 -0700 (PDT)
Received: by 10.231.11.2 with HTTP; Mon, 8 Apr 2013 19:31:09 -0700 (PDT)
In-Reply-To: 
References: <20130409022627.16888.35291.idtracker@ietfa.amsl.com> 
Date: Mon, 8 Apr 2013 19:31:09 -0700
Message-ID: 
From: Andy Bierman 
To: netmod@ietf.org
Content-Type: text/plain; charset=ISO-8859-1
X-Gm-Message-State: ALoCoQnQTfQji6xJz5zp2p8RpSqvs4AInEvZPC25EBEw5t1Uc8lkbhk5JD1ffgA7MqI7PHuwdnD5
Cc: Netconf 
Subject: Re: [netmod] I-D Action: draft-bierman-netconf-get2-03.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 09 Apr 2013 02:31:10 -0000

oops -- sorry NETMOD, meant to send to NETCONF WG...

On Mon, Apr 8, 2013 at 7:30 PM, Andy Bierman  wrote:
> FYI,
>
> I updated the  draft.
> References and definitions related to operational state have
> been removed since that work is very TBD and new operations
> and/or datastores may be needed
>
>
> Andy
>
>
>
> ---------- Forwarded message ----------
> From:  
> Date: Mon, Apr 8, 2013 at 7:26 PM
> Subject: I-D Action: draft-bierman-netconf-get2-03.txt
> To: i-d-announce@ietf.org
>
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>
>
>         Title           : The NETCONF  Operation
>         Author(s)       : Andy Bierman
>         Filename        : draft-bierman-netconf-get2-03.txt
>         Pages           : 28
>         Date            : 2013-04-08
>
> Abstract:
>    This document describes NETCONF protocol enhancements to improve data
>    retrieval capabilities.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-bierman-netconf-get2
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-bierman-netconf-get2-03
>
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=draft-bierman-netconf-get2-03
>
>
> 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 lhotka@nic.cz  Tue Apr  9 01:19:30 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91AF221F8733 for ; Tue,  9 Apr 2013 01:19:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.818
X-Spam-Level: 
X-Spam-Status: No, score=-1.818 tagged_above=-999 required=5 tests=[AWL=0.181,  BAYES_00=-2.599, J_CHICKENPOX_23=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fv5MazVtpkCq for ; Tue,  9 Apr 2013 01:19:29 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 2863E21F859C for ; Tue,  9 Apr 2013 01:19:28 -0700 (PDT)
Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 81CBE1405A5; Tue,  9 Apr 2013 10:19:27 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1365495567; bh=jPYudZRzi42Y3H3fzKqxtSvwMOqIWD/iJU7Gnp4juho=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=HQWr2INDhJGThR4cp/WloXILmNVBCGd11VdhmP2UmQECM1q6BQ3PUsvbl9VkeqBl1 XYqjenyprdph2PK1iPtk6AePeAGvb84Xf8OZVHKm7zZE8wZyBA4QSCEi9RbRLYPF9P QAGt04ECh0MZXO+T2ls4GTkD+zsYNBOH5hbQ2EmI=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
From: Ladislav Lhotka 
In-Reply-To: <20130408.221620.378835500.mbj@tail-f.com>
Date: Tue, 9 Apr 2013 10:19:28 +0200
Content-Transfer-Encoding: 7bit
Message-Id: <61216620-344B-48B9-9D08-9D7146230EED@nic.cz>
References: <20130408183421.GA16360@elstar.local> <20130408.213300.287705284.mbj@tail-f.com> <20130408194503.GA16659@elstar.local> <20130408.221620.378835500.mbj@tail-f.com>
To: Martin Bjorklund 
X-Mailer: Apple Mail (2.1503)
X-Virus-Scanned: clamav-milter 0.96.5 at mail
X-Virus-Status: Clean
Cc: netmod@ietf.org
Subject: Re: [netmod] AD review of draft-ietf-netmod-iana-if-type-04
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 09 Apr 2013 08:19:30 -0000

On Apr 8, 2013, at 10:16 PM, Martin Bjorklund  wrote:

> Juergen Schoenwaelder  wrote:
>> On Mon, Apr 08, 2013 at 09:33:00PM +0200, Martin Bjorklund wrote:
>>> Juergen Schoenwaelder  wrote:
>>>> On Fri, Mar 22, 2013 at 05:53:03PM +0100, Benoit Claise wrote:
>>>>> Hi Martin, netmod participants,
>>>>> 
>>>>> - IANAifType-MIB
>>>>> - http://www.iana.org/assignments/smi-numbers/smi-numbers.xml
>>>>> There is a new value 273, which should be added to the draft, at
>>>>> first glance.
>>>>> Note: this entry 273 is called "Reserved". This is a weird name,
>>>>> because there is RFC6825 next to it.
>>>>> Am I correct that, if a second entry is called "Reserved", the enum
>>>>> would break?
>>>> 
>>>> This issue has been further discussed between Benoit, Dan Romascanu
>>>> (the expert for the ifType registry), the NETMOD chairs and IANA.  We
>>>> arrived at the conclusion that reserved ifType numbers should show up
>>>> in both the YANG module and the SNMP module. (Technically, IANA
>>>> maintains a primary registry and two serializations, one in SMIv2
>>>> format and one in YANG format.) In order to ensure that we have unique
>>>> 'labels' for the allocated numbers, IANA is expected to use 'labels'
>>>> of the form reserverXYZ where XYZ is replaced by the allocated number.
>>>> In other words, the entry for 273 would be something like this:
>>>> 
>>>>         enum "reserved272" {
>>>>           value 272;
>>>>           description
>>>>             "Reserved by IANA";
>>>>         }
>>>> 
>>>> Please speak up now if you believe this is not a workable solution.
>>> 
>>> At first glance, this seems weird.  The point of reserving a value in
>>> a registry is to make sure the value (or label) is not used by anyone
>>> else.  But since it is reserved it would not be used.  So when it
>>> actually shows up like this with a dummy label it looks quite
>>> confusing.
>>> 
>>> From a technical YANG point of view, this is problematic, since you
>>> are not allowed to modify the enum label, one published (see section
>>> 10 of RFC 6020).
>> 
>> Oops, we apparently missed that part of YANG update rules which is
>> different from the SMIv2 update rules. So what would you propose?
>> Have reserved values marked only in the registry but not show up in
>> the SMIv2 / YANG serializations?
> 
> Yes.

+1

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 dromasca@avaya.com  Tue Apr  9 04:54:46 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8350A21F8D92 for ; Tue,  9 Apr 2013 04:54:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.016
X-Spam-Level: 
X-Spam-Status: No, score=-103.016 tagged_above=-999 required=5 tests=[AWL=-0.417, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uzdmcy4qD8yi for ; Tue,  9 Apr 2013 04:54:45 -0700 (PDT)
Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id 8D4B621F8D8E for ; Tue,  9 Apr 2013 04:54:45 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgMFALh+MVGHCzI1/2dsb2JhbABBA4Jmv16BABZzgh8BAQEBAgESKDQLBQcCAgIBCA0BAgEEAQEBChQJBxsXFAkIAgQOBQgBGYdrBgELpByMa49YBI1IEIEQIQULAgUGC4JOYQOXYYR7ilKBUoE2gXI1
X-IronPort-AV: E=Sophos;i="4.84,766,1355115600";  d="scan'208";a="6195192"
Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 09 Apr 2013 07:54:44 -0400
Received: from unknown (HELO AZ-FFEXHC02.global.avaya.com) ([135.64.58.12]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 09 Apr 2013 07:52:07 -0400
Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC02.global.avaya.com ([135.64.58.12]) with mapi id 14.02.0328.009; Tue, 9 Apr 2013 07:54:43 -0400
From: "Romascanu, Dan (Dan)" 
To: Juergen Schoenwaelder 
Thread-Topic: [IANA #668518] Fwd: Re: [netmod] AD review of draft-ietf-netmod-iana-if-type-04
Thread-Index: AQHONQWugJxzExrM+kmHh70Pgm9dN5jNxODA
Date: Tue, 9 Apr 2013 11:54:42 +0000
Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA0C4E7A@AZ-FFEXMB04.global.avaya.com>
References:  <514CDCD3.7030902@cisco.com> <20130324091737.GA19451@elstar.local>  <9904FB1B0159DA42B0B887B7FA8119CA0C210F@AZ-FFEXMB04.global.avaya.com>  <20130404182535.GA4511@elstar.local>  <9904FB1B0159DA42B0B887B7FA8119CA0C274A@AZ-FFEXMB04.global.avaya.com>  <20130409093616.GA22729@elstar.jacobs.jacobs-university.de>
In-Reply-To: <20130409093616.GA22729@elstar.jacobs.jacobs-university.de>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.64.58.45]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] [IANA #668518] Fwd: Re: AD review of draft-ietf-netmod-iana-if-type-04
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 09 Apr 2013 11:54:46 -0000

Hi Juergen,

I am moving the thread to the WG mail list, as you requested.=20

The argument in the previous thread were:=20

> At first glance, this seems weird.  The point of reserving a value in
> a registry is to make sure the value (or label) is not used by anyone
> else.  But since it is reserved it would not be used.  So when it
> actually shows up like this with a dummy label it looks quite
> confusing.
>=20

I fail to understand how a clarification that the value us reserved by IANA=
 can be confusing. Actually all this thread shows that many folks (with the=
 few exceptions of old-timers who designed MIB modules ages ago) are not aw=
are about the parallelism between the ifTime and transmission enumerations,=
 and the need to reserve the corresponding value if only one of them is def=
ined. The lack of documentation seems to be the confusing element here. Wha=
t am I missing?=20

> From a technical YANG point of view, this is problematic, since you
> are not allowed to modify the enum label, one published (see section
> 10 of RFC 6020).

I do not understand about what modification we are talking. We discuss futu=
re entries in the enumeration, not about modifying published ones.=20


Regards,

Dan




> -----Original Message-----
> From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-
> university.de]
> Sent: Tuesday, April 09, 2013 12:36 PM
> To: Romascanu, Dan (Dan)
> Cc: bclaise@cisco.com; netmod-chairs@tools.ietf.org
> Subject: Re: [IANA #668518] Fwd: Re: [netmod] AD review of draft-ietf-
> netmod-iana-if-type-04
>=20
> On Fri, Apr 05, 2013 at 07:22:06AM +0000, Romascanu, Dan (Dan) via RT
> wrote:
> >
> > So there are a few questions here:
> >
> > - should they show up in the MIB / YANG modules? I believe that yes,
> > they should, it provides clarity and avoids mistakes
>=20
> Dan,
>=20
> it seems at least Martin and Lada prefer that reserved values do not
> show up in the MIB module / YANG module but are only maintained in the
> IANA registry and I think they do have a point. See this email and
> followups:
>=20
> http://www.ietf.org/mail-archive/web/netmod/current/msg07925.html
>=20
> Can you please defend your suggestion that reserved values should be in
> the MIB / YANG modules on the mailing list or declare that you rethought
> things?
>=20
> I like to continue the discussion on the WG mailing list since this
> avoids duplication.
>=20
> /js
>=20
> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
> Fax:   +49 421 200 3103         

From j.schoenwaelder@jacobs-university.de  Tue Apr  9 04:59:48 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 255F721F9022 for ; Tue,  9 Apr 2013 04:59:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.899
X-Spam-Level: 
X-Spam-Status: No, score=-102.899 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wQw+phJIBY-r for ; Tue,  9 Apr 2013 04:59:47 -0700 (PDT)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 70FF221F8F10 for ; Tue,  9 Apr 2013 04:59:47 -0700 (PDT)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 400C520A6D; Tue,  9 Apr 2013 13:59:46 +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 CfIucrN439hp; Tue,  9 Apr 2013 13:59:46 +0200 (CEST)
Received: from elstar.jacobs.jacobs-university.de (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C04A520A01; Tue,  9 Apr 2013 13:59:45 +0200 (CEST)
Received: by elstar.jacobs.jacobs-university.de (Postfix, from userid 501) id 05E2B258B518; Tue,  9 Apr 2013 13:59:53 +0200 (CEST)
Date: Tue, 9 Apr 2013 13:59:53 +0200
From: Juergen Schoenwaelder 
To: "Romascanu, Dan (Dan)" 
Message-ID: <20130409115953.GA23326@elstar.jacobs.jacobs-university.de>
Mail-Followup-To: "Romascanu, Dan (Dan)" , "bclaise@cisco.com" , "netmod@ietf.org" 
References: <20130324091737.GA19451@elstar.local>  <9904FB1B0159DA42B0B887B7FA8119CA0C210F@AZ-FFEXMB04.global.avaya.com>  <20130404182535.GA4511@elstar.local>  <9904FB1B0159DA42B0B887B7FA8119CA0C274A@AZ-FFEXMB04.global.avaya.com>  <20130409093616.GA22729@elstar.jacobs.jacobs-university.de> <9904FB1B0159DA42B0B887B7FA8119CA0C4E7A@AZ-FFEXMB04.global.avaya.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA0C4E7A@AZ-FFEXMB04.global.avaya.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] [IANA #668518] Fwd: Re: AD review of draft-ietf-netmod-iana-if-type-04
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 09 Apr 2013 11:59:48 -0000

On Tue, Apr 09, 2013 at 11:54:42AM +0000, Romascanu, Dan (Dan) wrote:
> 
> > From a technical YANG point of view, this is problematic, since you
> > are not allowed to modify the enum label, one published (see section
> > 10 of RFC 6020).
> 
> I do not understand about what modification we are talking. We discuss future entries in the enumeration, not about modifying published ones. 
> 

If it is reserved, it might be used in the future, no? In that case,
you want to modify the 'label' but that would break YANG rules,as
Martin pointed out.

/js

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

From dromasca@avaya.com  Tue Apr  9 05:02:44 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DEB421F9157 for ; Tue,  9 Apr 2013 05:02:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.201
X-Spam-Level: 
X-Spam-Status: No, score=-103.201 tagged_above=-999 required=5 tests=[AWL=-0.202, BAYES_00=-2.599, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UVbL417huzIk for ; Tue,  9 Apr 2013 05:02:43 -0700 (PDT)
Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id 78F2221F9156 for ; Tue,  9 Apr 2013 05:02:43 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgIFAFupNVGHCzI1/2dsb2JhbABEgma/boEEFnOCHwEBAQEDEig/DAQCAQgNAQIBBAEBAQoUCQcyFAkIAgQOBQgah3EBoVWMa5A1jlsmCwcGgllhA5dohHyKVIFSgTaCJw
X-IronPort-AV: E=Sophos;i="4.84,786,1355115600";  d="scan'208";a="4749628"
Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 09 Apr 2013 08:02:41 -0400
Received: from unknown (HELO AZ-FFEXHC02.global.avaya.com) ([135.64.58.12]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 09 Apr 2013 08:00:04 -0400
Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC02.global.avaya.com ([135.64.58.12]) with mapi id 14.02.0328.009; Tue, 9 Apr 2013 08:02:39 -0400
From: "Romascanu, Dan (Dan)" 
To: Juergen Schoenwaelder 
Thread-Topic: [IANA #668518] Fwd: Re: [netmod] AD review of draft-ietf-netmod-iana-if-type-04
Thread-Index: AQHONQWugJxzExrM+kmHh70Pgm9dN5jNxODAgABHoID//71ckA==
Date: Tue, 9 Apr 2013 12:02:39 +0000
Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA0C4EA4@AZ-FFEXMB04.global.avaya.com>
References: <20130324091737.GA19451@elstar.local>  <9904FB1B0159DA42B0B887B7FA8119CA0C210F@AZ-FFEXMB04.global.avaya.com>  <20130404182535.GA4511@elstar.local>  <9904FB1B0159DA42B0B887B7FA8119CA0C274A@AZ-FFEXMB04.global.avaya.com>  <20130409093616.GA22729@elstar.jacobs.jacobs-university.de> <9904FB1B0159DA42B0B887B7FA8119CA0C4E7A@AZ-FFEXMB04.global.avaya.com> <20130409115953.GA23326@elstar.jacobs.jacobs-university.de>
In-Reply-To: <20130409115953.GA23326@elstar.jacobs.jacobs-university.de>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.64.58.45]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] [IANA #668518] Fwd: Re: AD review of draft-ietf-netmod-iana-if-type-04
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 09 Apr 2013 12:02:44 -0000

> -----Original Message-----
> From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-
> university.de]
> Sent: Tuesday, April 09, 2013 3:00 PM
> To: Romascanu, Dan (Dan)
> Cc: bclaise@cisco.com; netmod@ietf.org
> Subject: Re: [IANA #668518] Fwd: Re: [netmod] AD review of draft-ietf-
> netmod-iana-if-type-04
>=20
> On Tue, Apr 09, 2013 at 11:54:42AM +0000, Romascanu, Dan (Dan) wrote:
> >
> > > From a technical YANG point of view, this is problematic, since you
> > > are not allowed to modify the enum label, one published (see section
> > > 10 of RFC 6020).
> >
> > I do not understand about what modification we are talking. We discuss
> future entries in the enumeration, not about modifying published ones.
> >
>=20
> If it is reserved, it might be used in the future, no? In that case, you
> want to modify the 'label' but that would break YANG rules,as Martin
> pointed out.
>=20
> /js
>=20

[[DR]] I believe that what we mean is that it is NOT to be used in the futu=
re. Modifying the label would break SMI as well.=20

Dan


From bclaise@cisco.com  Tue Apr  9 05:39:03 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C0AB21F8437 for ; Tue,  9 Apr 2013 05:39:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.97
X-Spam-Level: 
X-Spam-Status: No, score=-9.97 tagged_above=-999 required=5 tests=[AWL=0.029,  BAYES_00=-2.599, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hYJdaMoUck+d for ; Tue,  9 Apr 2013 05:39:02 -0700 (PDT)
Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 61B7221F8510 for ; Tue,  9 Apr 2013 05:38:52 -0700 (PDT)
X-TACSUNS: Virus Scanned
Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r39CcnlB006544; Tue, 9 Apr 2013 14:38:49 +0200 (CEST)
Received: from [10.60.67.87] (ams-bclaise-8916.cisco.com [10.60.67.87]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r39CcD8J019451; Tue, 9 Apr 2013 14:38:29 +0200 (CEST)
Message-ID: <51640B68.5070504@cisco.com>
Date: Tue, 09 Apr 2013 14:36:56 +0200
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4
MIME-Version: 1.0
To: "Romascanu, Dan (Dan)" 
References: <20130324091737.GA19451@elstar.local>  <9904FB1B0159DA42B0B887B7FA8119CA0C210F@AZ-FFEXMB04.global.avaya.com>  <20130404182535.GA4511@elstar.local>  <9904FB1B0159DA42B0B887B7FA8119CA0C274A@AZ-FFEXMB04.global.avaya.com>  <20130409093616.GA22729@elstar.jacobs.jacobs-university.de> <9904FB1B0159DA42B0B887B7FA8119CA0C4E7A@AZ-FFEXMB04.global.avaya.com> <20130409115953.GA23326@elstar.jacobs.jacobs-university.de> <9904FB1B0159DA42B0B887B7FA8119CA0C4EA4@AZ-FFEXMB04.global.avaya.com>
In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA0C4EA4@AZ-FFEXMB04.global.avaya.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] [IANA #668518] Fwd: Re: AD review of draft-ietf-netmod-iana-if-type-04
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 09 Apr 2013 12:39:03 -0000

Dear all,
>
>
>
>> -----Original Message-----
>> From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-
>> university.de]
>> Sent: Tuesday, April 09, 2013 3:00 PM
>> To: Romascanu, Dan (Dan)
>> Cc: bclaise@cisco.com; netmod@ietf.org
>> Subject: Re: [IANA #668518] Fwd: Re: [netmod] AD review of draft-ietf-
>> netmod-iana-if-type-04
>>
>> On Tue, Apr 09, 2013 at 11:54:42AM +0000, Romascanu, Dan (Dan) wrote:
>>>>  From a technical YANG point of view, this is problematic, since you
>>>> are not allowed to modify the enum label, one published (see section
>>>> 10 of RFC 6020).
>>> I do not understand about what modification we are talking. We discuss
>> future entries in the enumeration, not about modifying published ones.
>> If it is reserved, it might be used in the future, no? In that case, you
>> want to modify the 'label' but that would break YANG rules,as Martin
>> pointed out.
>>
>> /js
>>
> [[DR]] I believe that what we mean is that it is NOT to be used in the future. Modifying the label would break SMI as well.
That's one of the sources of my confusion.
Reserved: is there a difference between reserved for a specific RFC and 
reserved because it will be assigned in the future?

http://www.iana.org/assignments/smi-numbers/smi-numbers.xml#smi-numbers-5 has 
only one Reserved, and there is a RFC next to it
However, in 
http://www.iana.org/assignments/smi-numbers/smi-numbers.xml#smi-numbers-7, 
I see multiple entries. For example: 50-55    Reserved    Reserved

Bottom line: the IANA considerations must explain what to do with the 
"Reserved" values, for both interface type and SAFI
And if there are two different of "Reserved" meaning, the IANA 
considerations section must explain the different treatments, if different.

Note also that there is a similar issue with "unassigned" in 
http://www.iana.org/assignments/safi-namespace/safi-namespace.xml . I 
guess that we don't want to register them

Regards, Benoit
>
> Dan
>
>
>


From dromasca@avaya.com  Tue Apr  9 05:57:37 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F128C21F904B for ; Tue,  9 Apr 2013 05:57:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.194
X-Spam-Level: 
X-Spam-Status: No, score=-103.194 tagged_above=-999 required=5 tests=[AWL=-0.195, BAYES_00=-2.599, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UIUjS3ZPIjE5 for ; Tue,  9 Apr 2013 05:57:34 -0700 (PDT)
Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id 9FACC21F8F33 for ; Tue,  9 Apr 2013 05:57:34 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgIFAHpXMFHGmAcF/2dsb2JhbABEgma/Tn8Wc4IfAQEBAQMSKD8MBAIBCA0BAgEEAQEBChQJBzIUCQgCBA4FCAEZh3EBC6RWjGuPWI5jJgsHBoJZYQOXX4R7ilGBUoE2gic
X-IronPort-AV: E=Sophos;i="4.84,760,1355115600";  d="scan'208";a="6194064"
Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 09 Apr 2013 08:57:33 -0400
Received: from unknown (HELO AZ-FFEXHC04.global.avaya.com) ([135.64.58.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 09 Apr 2013 08:54:49 -0400
Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC04.global.avaya.com ([135.64.58.14]) with mapi id 14.02.0328.009; Tue, 9 Apr 2013 08:57:32 -0400
From: "Romascanu, Dan (Dan)" 
To: Benoit Claise 
Thread-Topic: [IANA #668518] Fwd: Re: [netmod] AD review of draft-ietf-netmod-iana-if-type-04
Thread-Index: AQHONQWugJxzExrM+kmHh70Pgm9dN5jNxODAgABHoID//71ckIAATP4A///CKcA=
Date: Tue, 9 Apr 2013 12:57:32 +0000
Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA0C4FF7@AZ-FFEXMB04.global.avaya.com>
References: <20130324091737.GA19451@elstar.local>  <9904FB1B0159DA42B0B887B7FA8119CA0C210F@AZ-FFEXMB04.global.avaya.com>  <20130404182535.GA4511@elstar.local>  <9904FB1B0159DA42B0B887B7FA8119CA0C274A@AZ-FFEXMB04.global.avaya.com>  <20130409093616.GA22729@elstar.jacobs.jacobs-university.de> <9904FB1B0159DA42B0B887B7FA8119CA0C4E7A@AZ-FFEXMB04.global.avaya.com> <20130409115953.GA23326@elstar.jacobs.jacobs-university.de> <9904FB1B0159DA42B0B887B7FA8119CA0C4EA4@AZ-FFEXMB04.global.avaya.com> <51640B68.5070504@cisco.com>
In-Reply-To: <51640B68.5070504@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.64.58.45]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] [IANA #668518] Fwd: Re: AD review of draft-ietf-netmod-iana-if-type-04
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 09 Apr 2013 12:57:37 -0000

> -----Original Message-----
> From: Benoit Claise [mailto:bclaise@cisco.com]
> Sent: Tuesday, April 09, 2013 3:37 PM
> To: Romascanu, Dan (Dan)
> Cc: Juergen Schoenwaelder; netmod@ietf.org
> Subject: Re: [IANA #668518] Fwd: Re: [netmod] AD review of draft-ietf-
> netmod-iana-if-type-04
>=20
> Dear all,
> >
> >
> >
> >> -----Original Message-----
> >> From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-
> >> university.de]
> >> Sent: Tuesday, April 09, 2013 3:00 PM
> >> To: Romascanu, Dan (Dan)
> >> Cc: bclaise@cisco.com; netmod@ietf.org
> >> Subject: Re: [IANA #668518] Fwd: Re: [netmod] AD review of
> >> draft-ietf-
> >> netmod-iana-if-type-04
> >>
> >> On Tue, Apr 09, 2013 at 11:54:42AM +0000, Romascanu, Dan (Dan) wrote:
> >>>>  From a technical YANG point of view, this is problematic, since
> >>>> you are not allowed to modify the enum label, one published (see
> >>>> section
> >>>> 10 of RFC 6020).
> >>> I do not understand about what modification we are talking. We
> >>> discuss
> >> future entries in the enumeration, not about modifying published
> ones.
> >> If it is reserved, it might be used in the future, no? In that case,
> >> you want to modify the 'label' but that would break YANG rules,as
> >> Martin pointed out.
> >>
> >> /js
> >>
> > [[DR]] I believe that what we mean is that it is NOT to be used in the
> future. Modifying the label would break SMI as well.
> That's one of the sources of my confusion.
> Reserved: is there a difference between reserved for a specific RFC and
> reserved because it will be assigned in the future?
>=20
> http://www.iana.org/assignments/smi-numbers/smi-numbers.xml#smi-numbers-
> 5 has only one Reserved, and there is a RFC next to it However, in
> http://www.iana.org/assignments/smi-numbers/smi-numbers.xml#smi-numbers-
> 7,
> I see multiple entries. For example: 50-55    Reserved    Reserved
>=20
> Bottom line: the IANA considerations must explain what to do with the
> "Reserved" values, for both interface type and SAFI And if there are two
> different of "Reserved" meaning, the IANA considerations section must
> explain the different treatments, if different.
>=20
> Note also that there is a similar issue with "unassigned" in
> http://www.iana.org/assignments/safi-namespace/safi-namespace.xml . I
> guess that we don't want to register them
>=20
> Regards, Benoit
> >
> > Dan

[[DR]] I thought that ' reserved because it will be assigned in the future =
' =3D 'unassigned'.=20


Dan


From j.schoenwaelder@jacobs-university.de  Tue Apr  9 06:02:12 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B49F621F904B for ; Tue,  9 Apr 2013 06:02:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.163
X-Spam-Level: 
X-Spam-Status: No, score=-103.163 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1JImSGyMB9Qg for ; Tue,  9 Apr 2013 06:02:12 -0700 (PDT)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 084B521F9034 for ; Tue,  9 Apr 2013 06:02:12 -0700 (PDT)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 46FF620BE6; Tue,  9 Apr 2013 15:02:11 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id LQ6obp_mjx50; Tue,  9 Apr 2013 15:02:11 +0200 (CEST)
Received: from elstar.jacobs.jacobs-university.de (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A88B720BE2; Tue,  9 Apr 2013 15:02:10 +0200 (CEST)
Received: by elstar.jacobs.jacobs-university.de (Postfix, from userid 501) id 490A2258BB36; Tue,  9 Apr 2013 15:02:19 +0200 (CEST)
Date: Tue, 9 Apr 2013 15:02:19 +0200
From: Juergen Schoenwaelder 
To: "Romascanu, Dan (Dan)" 
Message-ID: <20130409130219.GC23525@elstar.jacobs.jacobs-university.de>
Mail-Followup-To: "Romascanu, Dan (Dan)" , "bclaise@cisco.com" , "netmod@ietf.org" 
References: <9904FB1B0159DA42B0B887B7FA8119CA0C210F@AZ-FFEXMB04.global.avaya.com>  <20130404182535.GA4511@elstar.local>  <9904FB1B0159DA42B0B887B7FA8119CA0C274A@AZ-FFEXMB04.global.avaya.com>  <20130409093616.GA22729@elstar.jacobs.jacobs-university.de> <9904FB1B0159DA42B0B887B7FA8119CA0C4E7A@AZ-FFEXMB04.global.avaya.com> <20130409115953.GA23326@elstar.jacobs.jacobs-university.de> <9904FB1B0159DA42B0B887B7FA8119CA0C4EA4@AZ-FFEXMB04.global.avaya.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA0C4EA4@AZ-FFEXMB04.global.avaya.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] [IANA #668518] Fwd: Re: AD review of draft-ietf-netmod-iana-if-type-04
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 09 Apr 2013 13:02:12 -0000

On Tue, Apr 09, 2013 at 12:02:39PM +0000, Romascanu, Dan (Dan) wrote:
> 
> 
> [[DR]] I believe that what we mean is that it is NOT to be used in the future. Modifying the label would break SMI as well. 
> 

This is incorrect, quoting RFC 2579 section 5:

(1)  A SYNTAX clause containing an enumerated INTEGER may have new
     enumerations added or existing labels changed.

I am not saying this is a good idea but the SMI allows 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 j.schoenwaelder@jacobs-university.de  Tue Apr  9 06:06:47 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEC6921F9184 for ; Tue,  9 Apr 2013 06:06:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.174
X-Spam-Level: 
X-Spam-Status: No, score=-103.174 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tK1fZKa52PJb for ; Tue,  9 Apr 2013 06:06:47 -0700 (PDT)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 2391321F915A for ; Tue,  9 Apr 2013 06:06:47 -0700 (PDT)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8044720BD4; Tue,  9 Apr 2013 15:06:46 +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 AdYqLmW-sC2u; Tue,  9 Apr 2013 15:06:46 +0200 (CEST)
Received: from elstar.jacobs.jacobs-university.de (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1CF3E20A01; Tue,  9 Apr 2013 15:06:46 +0200 (CEST)
Received: by elstar.jacobs.jacobs-university.de (Postfix, from userid 501) id AAF31258BBF6; Tue,  9 Apr 2013 15:06:54 +0200 (CEST)
Date: Tue, 9 Apr 2013 15:06:54 +0200
From: Juergen Schoenwaelder 
To: Benoit Claise 
Message-ID: <20130409130654.GD23525@elstar.jacobs.jacobs-university.de>
Mail-Followup-To: Benoit Claise , "Romascanu, Dan (Dan)" , "netmod@ietf.org" 
References:  <20130404182535.GA4511@elstar.local>  <9904FB1B0159DA42B0B887B7FA8119CA0C274A@AZ-FFEXMB04.global.avaya.com>  <20130409093616.GA22729@elstar.jacobs.jacobs-university.de> <9904FB1B0159DA42B0B887B7FA8119CA0C4E7A@AZ-FFEXMB04.global.avaya.com> <20130409115953.GA23326@elstar.jacobs.jacobs-university.de> <9904FB1B0159DA42B0B887B7FA8119CA0C4EA4@AZ-FFEXMB04.global.avaya.com> <51640B68.5070504@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <51640B68.5070504@cisco.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] [IANA #668518] Fwd: Re: AD review of draft-ietf-netmod-iana-if-type-04
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 09 Apr 2013 13:06:48 -0000

On Tue, Apr 09, 2013 at 02:36:56PM +0200, Benoit Claise wrote:

> That's one of the sources of my confusion.
> Reserved: is there a difference between reserved for a specific RFC
> and reserved because it will be assigned in the future?
> 
> http://www.iana.org/assignments/smi-numbers/smi-numbers.xml#smi-numbers-5
> has only one Reserved, and there is a RFC next to it
> However, in http://www.iana.org/assignments/smi-numbers/smi-numbers.xml#smi-numbers-7,
> I see multiple entries. For example: 50-55    Reserved    Reserved
> 
> Bottom line: the IANA considerations must explain what to do with
> the "Reserved" values, for both interface type and SAFI
> And if there are two different of "Reserved" meaning, the IANA
> considerations section must explain the different treatments, if
> different.

Lets not confuse registries. The 50-55 Reserved Reserved line belongs
to the transmission OID allocations, not ifTypes (if only implicitely)
and hence this is not relevant for the document we are discussing
here.

/js

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

From bclaise@cisco.com  Tue Apr  9 06:07:05 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A67A621F91A0 for ; Tue,  9 Apr 2013 06:07:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.971
X-Spam-Level: 
X-Spam-Status: No, score=-9.971 tagged_above=-999 required=5 tests=[AWL=0.028,  BAYES_00=-2.599, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z1grQj7PPFQP for ; Tue,  9 Apr 2013 06:07:03 -0700 (PDT)
Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 5CA5621F919D for ; Tue,  9 Apr 2013 06:07:03 -0700 (PDT)
X-TACSUNS: Virus Scanned
Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r39D6xP0010435; Tue, 9 Apr 2013 15:06:59 +0200 (CEST)
Received: from [10.60.67.87] (ams-bclaise-8916.cisco.com [10.60.67.87]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r39D69AE027868; Tue, 9 Apr 2013 15:06:24 +0200 (CEST)
Message-ID: <516411F4.1070200@cisco.com>
Date: Tue, 09 Apr 2013 15:04:52 +0200
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4
MIME-Version: 1.0
To: "Romascanu, Dan (Dan)" 
References: <20130324091737.GA19451@elstar.local>  <9904FB1B0159DA42B0B887B7FA8119CA0C210F@AZ-FFEXMB04.global.avaya.com>  <20130404182535.GA4511@elstar.local>  <9904FB1B0159DA42B0B887B7FA8119CA0C274A@AZ-FFEXMB04.global.avaya.com>  <20130409093616.GA22729@elstar.jacobs.jacobs-university.de> <9904FB1B0159DA42B0B887B7FA8119CA0C4E7A@AZ-FFEXMB04.global.avaya.com> <20130409115953.GA23326@elstar.jacobs.jacobs-university.de> <9904FB1B0159DA42B0B887B7FA8119CA0C4EA4@AZ-FFEXMB04.global.avaya.com> <51640B68.5070504@cisco.com> <9904FB1B0159DA42B0B887B7FA8119CA0C4FF7@AZ-FFEXMB04.global.avaya.com>
In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA0C4FF7@AZ-FFEXMB04.global.avaya.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] [IANA #668518] Fwd: Re: AD review of draft-ietf-netmod-iana-if-type-04
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 09 Apr 2013 13:07:05 -0000

On 9/04/2013 14:57, Romascanu, Dan (Dan) wrote:
>
>
>
>> -----Original Message-----
>> From: Benoit Claise [mailto:bclaise@cisco.com]
>> Sent: Tuesday, April 09, 2013 3:37 PM
>> To: Romascanu, Dan (Dan)
>> Cc: Juergen Schoenwaelder; netmod@ietf.org
>> Subject: Re: [IANA #668518] Fwd: Re: [netmod] AD review of draft-ietf-
>> netmod-iana-if-type-04
>>
>> Dear all,
>>>
>>>
>>>> -----Original Message-----
>>>> From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-
>>>> university.de]
>>>> Sent: Tuesday, April 09, 2013 3:00 PM
>>>> To: Romascanu, Dan (Dan)
>>>> Cc: bclaise@cisco.com; netmod@ietf.org
>>>> Subject: Re: [IANA #668518] Fwd: Re: [netmod] AD review of
>>>> draft-ietf-
>>>> netmod-iana-if-type-04
>>>>
>>>> On Tue, Apr 09, 2013 at 11:54:42AM +0000, Romascanu, Dan (Dan) wrote:
>>>>>>   From a technical YANG point of view, this is problematic, since
>>>>>> you are not allowed to modify the enum label, one published (see
>>>>>> section
>>>>>> 10 of RFC 6020).
>>>>> I do not understand about what modification we are talking. We
>>>>> discuss
>>>> future entries in the enumeration, not about modifying published
>> ones.
>>>> If it is reserved, it might be used in the future, no? In that case,
>>>> you want to modify the 'label' but that would break YANG rules,as
>>>> Martin pointed out.
>>>>
>>>> /js
>>>>
>>> [[DR]] I believe that what we mean is that it is NOT to be used in the
>> future. Modifying the label would break SMI as well.
>> That's one of the sources of my confusion.
>> Reserved: is there a difference between reserved for a specific RFC and
>> reserved because it will be assigned in the future?
>>
>> http://www.iana.org/assignments/smi-numbers/smi-numbers.xml#smi-numbers-
>> 5 has only one Reserved, and there is a RFC next to it However, in
>> http://www.iana.org/assignments/smi-numbers/smi-numbers.xml#smi-numbers-
>> 7,
>> I see multiple entries. For example: 50-55    Reserved    Reserved
>>
>> Bottom line: the IANA considerations must explain what to do with the
>> "Reserved" values, for both interface type and SAFI And if there are two
>> different of "Reserved" meaning, the IANA considerations section must
>> explain the different treatments, if different.
>>
>> Note also that there is a similar issue with "unassigned" in
>> http://www.iana.org/assignments/safi-namespace/safi-namespace.xml . I
>> guess that we don't want to register them
>>
>> Regards, Benoit
>>> Dan
> [[DR]] I thought that ' reserved because it will be assigned in the future ' = 'unassigned'.
I thought so, until I saw 
http://www.iana.org/assignments/smi-numbers/smi-numbers.xml#smi-numbers-7
see 50-55, 57-80, 83-93, etc...

B.
>
>
> Dan
>
>
>


From dromasca@avaya.com  Tue Apr  9 06:11:03 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB7AC21F9030 for ; Tue,  9 Apr 2013 06:11:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.487
X-Spam-Level: 
X-Spam-Status: No, score=-103.487 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c1A1w0z9htKF for ; Tue,  9 Apr 2013 06:11:03 -0700 (PDT)
Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id C8EE621F89BA for ; Tue,  9 Apr 2013 06:11:01 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgIFAFupNVGHCzI1/2dsb2JhbABEgma/boEEFnOCHwEBAQEDEig/DAQCAQgNAQIBBAEBAQoUCQcyFAkIAgQOBQgah3EBoVWMa5A1jlsmCwcGgllhA5dohHyKVIFSgTaCJw
X-IronPort-AV: E=Sophos;i="4.84,786,1355115600";  d="scan'208";a="4761073"
Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 09 Apr 2013 09:10:59 -0400
Received: from unknown (HELO AZ-FFEXHC04.global.avaya.com) ([135.64.58.14]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 09 Apr 2013 09:08:22 -0400
Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC04.global.avaya.com ([135.64.58.14]) with mapi id 14.02.0328.009; Tue, 9 Apr 2013 09:10:57 -0400
From: "Romascanu, Dan (Dan)" 
To: Juergen Schoenwaelder 
Thread-Topic: [IANA #668518] Fwd: Re: [netmod] AD review of draft-ietf-netmod-iana-if-type-04
Thread-Index: AQHONQWugJxzExrM+kmHh70Pgm9dN5jNxODAgABHoID//71ckIAAVBWA//+/HyA=
Date: Tue, 9 Apr 2013 13:10:57 +0000
Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA0C5073@AZ-FFEXMB04.global.avaya.com>
References: <9904FB1B0159DA42B0B887B7FA8119CA0C210F@AZ-FFEXMB04.global.avaya.com>  <20130404182535.GA4511@elstar.local>  <9904FB1B0159DA42B0B887B7FA8119CA0C274A@AZ-FFEXMB04.global.avaya.com>  <20130409093616.GA22729@elstar.jacobs.jacobs-university.de> <9904FB1B0159DA42B0B887B7FA8119CA0C4E7A@AZ-FFEXMB04.global.avaya.com> <20130409115953.GA23326@elstar.jacobs.jacobs-university.de> <9904FB1B0159DA42B0B887B7FA8119CA0C4EA4@AZ-FFEXMB04.global.avaya.com> <20130409130219.GC23525@elstar.jacobs.jacobs-university.de>
In-Reply-To: <20130409130219.GC23525@elstar.jacobs.jacobs-university.de>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.64.58.45]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] [IANA #668518] Fwd: Re: AD review of draft-ietf-netmod-iana-if-type-04
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 09 Apr 2013 13:11:03 -0000

> -----Original Message-----
> From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-
> university.de]
> Sent: Tuesday, April 09, 2013 4:02 PM
> To: Romascanu, Dan (Dan)
> Cc: bclaise@cisco.com; netmod@ietf.org
> Subject: Re: [IANA #668518] Fwd: Re: [netmod] AD review of draft-ietf-
> netmod-iana-if-type-04
>=20
> On Tue, Apr 09, 2013 at 12:02:39PM +0000, Romascanu, Dan (Dan) wrote:
> >
> >
> > [[DR]] I believe that what we mean is that it is NOT to be used in the
> future. Modifying the label would break SMI as well.
> >
>=20
> This is incorrect, quoting RFC 2579 section 5:
>=20
> (1)  A SYNTAX clause containing an enumerated INTEGER may have new
>      enumerations added or existing labels changed.
>=20
> I am not saying this is a good idea but the SMI allows this.
>=20
> /js
>=20

[[DR]] I stand corrected. It does not seem a good idea, indeed.

Dan


From mbj@tail-f.com  Tue Apr  9 06:18:46 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36F8721F928B for ; Tue,  9 Apr 2013 06:18:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.046
X-Spam-Level: 
X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v1xUyyaBU0lI for ; Tue,  9 Apr 2013 06:18:45 -0700 (PDT)
Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id A3BAB21F926E for ; Tue,  9 Apr 2013 06:18:45 -0700 (PDT)
Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 33B8D1200A35; Tue,  9 Apr 2013 15:18:44 +0200 (CEST)
Date: Tue, 09 Apr 2013 15:18:44 +0200 (CEST)
Message-Id: <20130409.151844.1909906276780430974.mbj@tail-f.com>
To: dromasca@avaya.com
From: Martin Bjorklund 
In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA0C4E7A@AZ-FFEXMB04.global.avaya.com>
References:  <20130409093616.GA22729@elstar.jacobs.jacobs-university.de> <9904FB1B0159DA42B0B887B7FA8119CA0C4E7A@AZ-FFEXMB04.global.avaya.com>
X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Cc: netmod@ietf.org
Subject: Re: [netmod] [IANA #668518] Fwd: Re: AD review of draft-ietf-netmod-iana-if-type-04
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 09 Apr 2013 13:18:46 -0000

"Romascanu, Dan (Dan)"  wrote:
> Hi Juergen,
> 
> I am moving the thread to the WG mail list, as you requested. 
> 
> The argument in the previous thread were: 
> 
> > At first glance, this seems weird.  The point of reserving a value in
> > a registry is to make sure the value (or label) is not used by anyone
> > else.  But since it is reserved it would not be used.  So when it
> > actually shows up like this with a dummy label it looks quite
> > confusing.
> > 
> 
> I fail to understand how a clarification that the value us reserved by
> IANA can be confusing. Actually all this thread shows that many folks
> (with the few exceptions of old-timers who designed MIB modules ages
> ago) are not aware about the parallelism between the ifTime and
> transmission enumerations, and the need to reserve the corresponding
> value if only one of them is defined. The lack of documentation seems
> to be the confusing element here. What am I missing?

The confusing part is that a real value is defined in the data model,
but the intent is (?) that the value is reserved so that it is not
used by anyone else.  And for this purpose, marking it as reserved in
the registry seems perfectly fine.

> > From a technical YANG point of view, this is problematic, since you
> > are not allowed to modify the enum label, one published (see section
> > 10 of RFC 6020).
> 
> I do not understand about what modification we are talking. We discuss
> future entries in the enumeration, not about modifying published ones.

I see that Juergen replied to this.


/martin

From dromasca@avaya.com  Tue Apr  9 06:22:45 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25BC221F91B8 for ; Tue,  9 Apr 2013 06:22:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.491
X-Spam-Level: 
X-Spam-Status: No, score=-103.491 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oi+WJ+wZi2Em for ; Tue,  9 Apr 2013 06:22:44 -0700 (PDT)
Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id 651F321F9184 for ; Tue,  9 Apr 2013 06:22:43 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgEFAHpXMFHGmAcF/2dsb2JhbABEgma/Tn8Wc4IfAQEBAQMSKD8MBAIBCA0BBw0UCQcyFBECBA4FCBqHcQGkYYxrj1iOYyYLB4JfYQOcWopRgVKBNoIn
X-IronPort-AV: E=Sophos;i="4.84,760,1355115600";  d="scan'208";a="6199112"
Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 09 Apr 2013 09:22:42 -0400
Received: from unknown (HELO AZ-FFEXHC04.global.avaya.com) ([135.64.58.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 09 Apr 2013 09:19:57 -0400
Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC04.global.avaya.com ([135.64.58.14]) with mapi id 14.02.0328.009; Tue, 9 Apr 2013 09:22:41 -0400
From: "Romascanu, Dan (Dan)" 
To: Martin Bjorklund 
Thread-Topic: [netmod] [IANA #668518] Fwd: Re: AD review of draft-ietf-netmod-iana-if-type-04
Thread-Index: AQHONSTGUSO1ewbf6EmP+Un5c5GCGJjN37AA
Date: Tue, 9 Apr 2013 13:22:41 +0000
Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA0C516F@AZ-FFEXMB04.global.avaya.com>
References:  <20130409093616.GA22729@elstar.jacobs.jacobs-university.de> <9904FB1B0159DA42B0B887B7FA8119CA0C4E7A@AZ-FFEXMB04.global.avaya.com> <20130409.151844.1909906276780430974.mbj@tail-f.com>
In-Reply-To: <20130409.151844.1909906276780430974.mbj@tail-f.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.64.58.45]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] [IANA #668518] Fwd: Re: AD review of draft-ietf-netmod-iana-if-type-04
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 09 Apr 2013 13:22:45 -0000

> -----Original Message-----
> From: Martin Bjorklund [mailto:mbj@tail-f.com]
>=20
> The confusing part is that a real value is defined in the data model,
> but the intent is (?) that the value is reserved so that it is not used
> by anyone else.  And for this purpose, marking it as reserved in the
> registry seems perfectly fine.
>=20
[[DR]] What do you mean by 'a real value is defined in the data model'? The=
 'real value' is for the transmission entry, but not all transmission entri=
es map onto corresponding ifType values. The data model needs to distinguis=
h between the two.=20

Regards,

Dan


From mbj@tail-f.com  Tue Apr  9 06:28:28 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB4BB21F91A0 for ; Tue,  9 Apr 2013 06:28:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.046
X-Spam-Level: 
X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cf6yGmEGDuol for ; Tue,  9 Apr 2013 06:28:28 -0700 (PDT)
Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 3F41C21F8FD6 for ; Tue,  9 Apr 2013 06:28:28 -0700 (PDT)
Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 8E5571200A35; Tue,  9 Apr 2013 15:28:27 +0200 (CEST)
Date: Tue, 09 Apr 2013 15:28:27 +0200 (CEST)
Message-Id: <20130409.152827.1381963496459277072.mbj@tail-f.com>
To: dromasca@avaya.com
From: Martin Bjorklund 
In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA0C516F@AZ-FFEXMB04.global.avaya.com>
References: <9904FB1B0159DA42B0B887B7FA8119CA0C4E7A@AZ-FFEXMB04.global.avaya.com> <20130409.151844.1909906276780430974.mbj@tail-f.com> <9904FB1B0159DA42B0B887B7FA8119CA0C516F@AZ-FFEXMB04.global.avaya.com>
X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Cc: netmod@ietf.org
Subject: Re: [netmod] [IANA #668518] Fwd: Re: AD review of draft-ietf-netmod-iana-if-type-04
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 09 Apr 2013 13:28:28 -0000

"Romascanu, Dan (Dan)"  wrote:
> 
> 
> 
> 
> > -----Original Message-----
> > From: Martin Bjorklund [mailto:mbj@tail-f.com]
> > 
> > The confusing part is that a real value is defined in the data model,
> > but the intent is (?) that the value is reserved so that it is not
> > used
> > by anyone else.  And for this purpose, marking it as reserved in the
> > registry seems perfectly fine.
> > 
> [[DR]] What do you mean by 'a real value is defined in the data
> model'? The 'real value' is for the transmission entry, but not all
> transmission entries map onto corresponding ifType values.

Juergen suggested this YANG:

         enum "reserved273" {
           value 273;
           description
             "Reserved by IANA";
         }


This is a real value in the typedef.  The transmission value *is* thus
mapped onto a corresponding if-type value.


/martin


From dromasca@avaya.com  Tue Apr  9 06:31:19 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CC5F21F930C for ; Tue,  9 Apr 2013 06:31:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.494
X-Spam-Level: 
X-Spam-Status: No, score=-103.494 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iJHctE+Ylgu9 for ; Tue,  9 Apr 2013 06:31:18 -0700 (PDT)
Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id 4B67B21F8FD6 for ; Tue,  9 Apr 2013 06:31:18 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgIFAFupNVGHCzI1/2dsb2JhbABEgma/boEEFnOCHwEBAQEDEig/DAQCAQgNAQIBBAEBAQoUCQcyFAkIAgQOBQgah3EBoVWMa5A1jlsmCwcGgllhA5xkilSBUoE2gic
X-IronPort-AV: E=Sophos;i="4.84,786,1355115600";  d="scan'208";a="4764377"
Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 09 Apr 2013 09:31:16 -0400
Received: from unknown (HELO AZ-FFEXHC03.global.avaya.com) ([135.64.58.13]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 09 Apr 2013 09:28:39 -0400
Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC03.global.avaya.com ([135.64.58.13]) with mapi id 14.02.0328.009; Tue, 9 Apr 2013 09:31:14 -0400
From: "Romascanu, Dan (Dan)" 
To: Martin Bjorklund 
Thread-Topic: [netmod] [IANA #668518] Fwd: Re: AD review of draft-ietf-netmod-iana-if-type-04
Thread-Index: AQHONSTGUSO1ewbf6EmP+Un5c5GCGJjN37AAgABFUID//71HQA==
Date: Tue, 9 Apr 2013 13:31:14 +0000
Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA0C51F2@AZ-FFEXMB04.global.avaya.com>
References: <9904FB1B0159DA42B0B887B7FA8119CA0C4E7A@AZ-FFEXMB04.global.avaya.com> <20130409.151844.1909906276780430974.mbj@tail-f.com> <9904FB1B0159DA42B0B887B7FA8119CA0C516F@AZ-FFEXMB04.global.avaya.com> <20130409.152827.1381963496459277072.mbj@tail-f.com>
In-Reply-To: <20130409.152827.1381963496459277072.mbj@tail-f.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.64.58.45]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] [IANA #668518] Fwd: Re: AD review of draft-ietf-netmod-iana-if-type-04
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 09 Apr 2013 13:31:19 -0000

> -----Original Message-----
> From: Martin Bjorklund [mailto:mbj@tail-f.com]
> Sent: Tuesday, April 09, 2013 4:28 PM
> To: Romascanu, Dan (Dan)
> Cc: j.schoenwaelder@jacobs-university.de; netmod@ietf.org
> Subject: Re: [netmod] [IANA #668518] Fwd: Re: AD review of draft-ietf-
> netmod-iana-if-type-04
>=20
> "Romascanu, Dan (Dan)"  wrote:
> >
> >
> >
> >
> > > -----Original Message-----
> > > From: Martin Bjorklund [mailto:mbj@tail-f.com]
> > >
> > > The confusing part is that a real value is defined in the data
> > > model, but the intent is (?) that the value is reserved so that it
> > > is not used by anyone else.  And for this purpose, marking it as
> > > reserved in the registry seems perfectly fine.
> > >
> > [[DR]] What do you mean by 'a real value is defined in the data
> > model'? The 'real value' is for the transmission entry, but not all
> > transmission entries map onto corresponding ifType values.
>=20
> Juergen suggested this YANG:
>=20
>          enum "reserved273" {
>            value 273;
>            description
>              "Reserved by IANA";
>          }
>=20
>=20
> This is a real value in the typedef.  The transmission value *is* thus
> mapped onto a corresponding if-type value.
>=20
>=20
> /martin

[[DR]] So? We have a label. This label cannot be changed according to RFC 6=
020. Rge 'description' clause explains who made the reservation. Where is t=
he confusion?=20

Dan


From mbj@tail-f.com  Tue Apr  9 06:42:20 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 559D421F8E7C for ; Tue,  9 Apr 2013 06:42:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.046
X-Spam-Level: 
X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b-thIl8wgxUv for ; Tue,  9 Apr 2013 06:42:19 -0700 (PDT)
Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id B015D21F8E7B for ; Tue,  9 Apr 2013 06:42:19 -0700 (PDT)
Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 2F5EF1200A35; Tue,  9 Apr 2013 15:42:16 +0200 (CEST)
Date: Tue, 09 Apr 2013 15:42:16 +0200 (CEST)
Message-Id: <20130409.154216.2204981475552383627.mbj@tail-f.com>
To: dromasca@avaya.com
From: Martin Bjorklund 
In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA0C51F2@AZ-FFEXMB04.global.avaya.com>
References: <9904FB1B0159DA42B0B887B7FA8119CA0C516F@AZ-FFEXMB04.global.avaya.com> <20130409.152827.1381963496459277072.mbj@tail-f.com> <9904FB1B0159DA42B0B887B7FA8119CA0C51F2@AZ-FFEXMB04.global.avaya.com>
X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Cc: netmod@ietf.org
Subject: Re: [netmod] [IANA #668518] Fwd: Re: AD review of draft-ietf-netmod-iana-if-type-04
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 09 Apr 2013 13:42:20 -0000

"Romascanu, Dan (Dan)"  wrote:
> 
> 
> 
> 
> > -----Original Message-----
> > From: Martin Bjorklund [mailto:mbj@tail-f.com]
> > Sent: Tuesday, April 09, 2013 4:28 PM
> > To: Romascanu, Dan (Dan)
> > Cc: j.schoenwaelder@jacobs-university.de; netmod@ietf.org
> > Subject: Re: [netmod] [IANA #668518] Fwd: Re: AD review of draft-ietf-
> > netmod-iana-if-type-04
> > 
> > "Romascanu, Dan (Dan)"  wrote:
> > >
> > >
> > >
> > >
> > > > -----Original Message-----
> > > > From: Martin Bjorklund [mailto:mbj@tail-f.com]
> > > >
> > > > The confusing part is that a real value is defined in the data
> > > > model, but the intent is (?) that the value is reserved so that it
> > > > is not used by anyone else.  And for this purpose, marking it as
> > > > reserved in the registry seems perfectly fine.
> > > >
> > > [[DR]] What do you mean by 'a real value is defined in the data
> > > model'? The 'real value' is for the transmission entry, but not all
> > > transmission entries map onto corresponding ifType values.
> > 
> > Juergen suggested this YANG:
> > 
> >          enum "reserved273" {
> >            value 273;
> >            description
> >              "Reserved by IANA";
> >          }
> > 
> > 
> > This is a real value in the typedef.  The transmission value *is* thus
> > mapped onto a corresponding if-type value.
> > 
> > 
> > /martin
> 
> [[DR]] So? We have a label. This label cannot be changed according to
> RFC 6020. Rge 'description' clause explains who made the
> reservation. Where is the confusion?

It is probably just in the word "reserved".  It seems at least two
people interpreted this to mean "reserved for now, might be used in
the future".

May I ask what we gain by adding this enum to the module?

If we do it, maybe we could do something like this:

  enum not-used-273 {
    value 273;
    description
      "The corresponding transmission value
       is allocated according to the following
       reference.

       This enumeration must not be used by implementations.";
    reference
      "RFC 6825";
  }

(the first part of the description is the same as in the "ifType
definitions" registry.)


/martin


From dromasca@avaya.com  Tue Apr  9 07:04:25 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2638821F86C3 for ; Tue,  9 Apr 2013 07:04:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.997
X-Spam-Level: 
X-Spam-Status: No, score=-102.997 tagged_above=-999 required=5 tests=[AWL=-0.398, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zlYVADHp3l+F for ; Tue,  9 Apr 2013 07:04:24 -0700 (PDT)
Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id 3746E21F8540 for ; Tue,  9 Apr 2013 07:04:18 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgMFALh+MVGHCzI1/2dsb2JhbABEgma/XoEAFnOCHwEBAQEDEigyCgMMBAIBCA0BAgEEAQEBChQJBzIUCQgCBA4FCBqHcQGkJ4xrj1iObCYLBwaCWWEDnFyKUoFSgTaCJw
X-IronPort-AV: E=Sophos;i="4.84,766,1355115600";  d="scan'208";a="6218401"
Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 09 Apr 2013 10:04:17 -0400
Received: from unknown (HELO AZ-FFEXHC04.global.avaya.com) ([135.64.58.14]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 09 Apr 2013 10:01:40 -0400
Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC04.global.avaya.com ([135.64.58.14]) with mapi id 14.02.0328.009; Tue, 9 Apr 2013 10:04:16 -0400
From: "Romascanu, Dan (Dan)" 
To: Martin Bjorklund 
Thread-Topic: [netmod] [IANA #668518] Fwd: Re: AD review of draft-ietf-netmod-iana-if-type-04
Thread-Index: AQHONSTGUSO1ewbf6EmP+Un5c5GCGJjN37AAgABFUID//71HQIAARpUA///C5AA=
Date: Tue, 9 Apr 2013 14:04:15 +0000
Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA0C5246@AZ-FFEXMB04.global.avaya.com>
References: <9904FB1B0159DA42B0B887B7FA8119CA0C516F@AZ-FFEXMB04.global.avaya.com> <20130409.152827.1381963496459277072.mbj@tail-f.com> <9904FB1B0159DA42B0B887B7FA8119CA0C51F2@AZ-FFEXMB04.global.avaya.com> <20130409.154216.2204981475552383627.mbj@tail-f.com>
In-Reply-To: <20130409.154216.2204981475552383627.mbj@tail-f.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.64.58.45]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] [IANA #668518] Fwd: Re: AD review of draft-ietf-netmod-iana-if-type-04
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 09 Apr 2013 14:04:25 -0000

> -----Original Message-----
> From: Martin Bjorklund [mailto:mbj@tail-f.com]
> Sent: Tuesday, April 09, 2013 4:42 PM
> To: Romascanu, Dan (Dan)
> Cc: j.schoenwaelder@jacobs-university.de; netmod@ietf.org
> Subject: Re: [netmod] [IANA #668518] Fwd: Re: AD review of draft-ietf-
> netmod-iana-if-type-04
>=20
> "Romascanu, Dan (Dan)"  wrote:
> >
> >
> >
> >
> > > -----Original Message-----
> > > From: Martin Bjorklund [mailto:mbj@tail-f.com]
> > > Sent: Tuesday, April 09, 2013 4:28 PM
> > > To: Romascanu, Dan (Dan)
> > > Cc: j.schoenwaelder@jacobs-university.de; netmod@ietf.org
> > > Subject: Re: [netmod] [IANA #668518] Fwd: Re: AD review of
> > > draft-ietf-
> > > netmod-iana-if-type-04
> > >
> > > "Romascanu, Dan (Dan)"  wrote:
> > > >
> > > >
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Martin Bjorklund [mailto:mbj@tail-f.com]
> > > > >
> > > > > The confusing part is that a real value is defined in the data
> > > > > model, but the intent is (?) that the value is reserved so that
> > > > > it is not used by anyone else.  And for this purpose, marking it
> > > > > as reserved in the registry seems perfectly fine.
> > > > >
> > > > [[DR]] What do you mean by 'a real value is defined in the data
> > > > model'? The 'real value' is for the transmission entry, but not
> > > > all transmission entries map onto corresponding ifType values.
> > >
> > > Juergen suggested this YANG:
> > >
> > >          enum "reserved273" {
> > >            value 273;
> > >            description
> > >              "Reserved by IANA";
> > >          }
> > >
> > >
> > > This is a real value in the typedef.  The transmission value *is*
> > > thus mapped onto a corresponding if-type value.
> > >
> > >
> > > /martin
> >
> > [[DR]] So? We have a label. This label cannot be changed according to
> > RFC 6020. Rge 'description' clause explains who made the reservation.
> > Where is the confusion?
>=20
> It is probably just in the word "reserved".  It seems at least two
> people interpreted this to mean "reserved for now, might be used in the
> future".
>=20
> May I ask what we gain by adding this enum to the module?
>=20
> If we do it, maybe we could do something like this:
>=20
>   enum not-used-273 {
>     value 273;
>     description
>       "The corresponding transmission value
>        is allocated according to the following
>        reference.
>=20
>        This enumeration must not be used by implementations.";
>     reference
>       "RFC 6825";
>   }
>=20
> (the first part of the description is the same as in the "ifType
> definitions" registry.)
>=20
>=20
> /martin

[[DR]] (this also) wfm

Dan



From j.schoenwaelder@jacobs-university.de  Tue Apr  9 07:46:31 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E97921F93B3 for ; Tue,  9 Apr 2013 07:46:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.65
X-Spam-Level: 
X-Spam-Status: No, score=-100.65 tagged_above=-999 required=5 tests=[HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SB+3b4BEyaeD for ; Tue,  9 Apr 2013 07:46:31 -0700 (PDT)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id CF1C221F93A3 for ; Tue,  9 Apr 2013 07:46:27 -0700 (PDT)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1B8FB20BE1; Tue,  9 Apr 2013 16:46:27 +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 7sYZYgGQDcso; Tue,  9 Apr 2013 16:46:26 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4757220BDB; Tue,  9 Apr 2013 16:46:26 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 0546D258C45E; Tue,  9 Apr 2013 16:46:31 +0200 (CEST)
Date: Tue, 9 Apr 2013 16:46:31 +0200
From: Juergen Schoenwaelder 
To: Martin Bjorklund 
Message-ID: <20130409144631.GA192@elstar.local>
Mail-Followup-To: Martin Bjorklund , dromasca@avaya.com, netmod@ietf.org
References: <9904FB1B0159DA42B0B887B7FA8119CA0C516F@AZ-FFEXMB04.global.avaya.com> <20130409.152827.1381963496459277072.mbj@tail-f.com> <9904FB1B0159DA42B0B887B7FA8119CA0C51F2@AZ-FFEXMB04.global.avaya.com> <20130409.154216.2204981475552383627.mbj@tail-f.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20130409.154216.2204981475552383627.mbj@tail-f.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: netmod@ietf.org
Subject: Re: [netmod] [IANA #668518] Fwd: Re: AD review of draft-ietf-netmod-iana-if-type-04
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 09 Apr 2013 14:46:31 -0000

On Tue, Apr 09, 2013 at 03:42:16PM +0200, Martin Bjorklund wrote:
 
> It is probably just in the word "reserved".  It seems at least two
> people interpreted this to mean "reserved for now, might be used in
> the future".
> 
> May I ask what we gain by adding this enum to the module?
> 
> If we do it, maybe we could do something like this:
> 
>   enum not-used-273 {
>     value 273;
>     description
>       "The corresponding transmission value
>        is allocated according to the following
>        reference.
> 
>        This enumeration must not be used by implementations.";
>     reference
>       "RFC 6825";
>   }
> 
> (the first part of the description is the same as in the "ifType
> definitions" registry.)

Speaking as technical contributor, I fail to see the value of doing
this. not-used-273 is not an assigned ifType and so why bother to have
it in SMIv2/YANG modules? How does this help to manage a network?

I understand that it is important for the registry maintainer to know
that there are values that are reserved for specific future usages or
reserved to never be used, but it is not clear to me why information
about this should to appear in an SMIv2 or YANG module as if these
numbers were actually registered as an ifType. And I am concerned that
some of the not-used-XYZ entries then later may find a usage and we
run into trouble with that.

/js

PS: Note that hyphens are not allowed in SMIv2 labels...

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

From andy@yumaworks.com  Tue Apr  9 07:55:13 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2FBA21F9402 for ; Tue,  9 Apr 2013 07:55:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.621
X-Spam-Level: 
X-Spam-Status: No, score=0.621 tagged_above=-999 required=5 tests=[FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ege7xmHJOziJ for ; Tue,  9 Apr 2013 07:55:11 -0700 (PDT)
Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [IPv6:2607:f8b0:4001:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id 4C86A21F9412 for ; Tue,  9 Apr 2013 07:55:10 -0700 (PDT)
Received: by mail-ie0-f180.google.com with SMTP id a11so8406448iee.25 for ; Tue, 09 Apr 2013 07:55:08 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type:x-gm-message-state; bh=jbzL5G6Mr1WovSLl5HttKwSMa7+69flz0RBX+RenhXE=; b=Yur+zPsO1bXrkMMl7VIvJK/Uyg8bFBHVy5DVWYFMRlgpwmbWq2f9EWwZn1iH02aQQO twXpXRj6MC9vZCTUTk6XKcbX24h+cbFum7SJOBHgS4SzPnc93dKFjHsVxscwF7t4PHjD oe5ppBUL/LibxfkP0RtrwWxzGm8VlfAY9VgQDTR2dkdGrjv/qgWIrg8iYchkHbwqru9H jIblot5kGojVAk+EvS4xEs+48U5EDrrYXrV5RYCTD+CzxiYROjc/6CIPVdG+4tGVmyLG OJxSg7+S9v+rVl52ClNFvMzot0mdv1DGDy33SX73AnHOwfjfXeCjqaMK1hwaClU5WUzr fPWg==
MIME-Version: 1.0
X-Received: by 10.50.53.180 with SMTP id c20mr10628670igp.15.1365519308385; Tue, 09 Apr 2013 07:55:08 -0700 (PDT)
Received: by 10.231.11.2 with HTTP; Tue, 9 Apr 2013 07:55:08 -0700 (PDT)
In-Reply-To: <20130409144631.GA192@elstar.local>
References: <9904FB1B0159DA42B0B887B7FA8119CA0C516F@AZ-FFEXMB04.global.avaya.com> <20130409.152827.1381963496459277072.mbj@tail-f.com> <9904FB1B0159DA42B0B887B7FA8119CA0C51F2@AZ-FFEXMB04.global.avaya.com> <20130409.154216.2204981475552383627.mbj@tail-f.com> <20130409144631.GA192@elstar.local>
Date: Tue, 9 Apr 2013 07:55:08 -0700
Message-ID: 
From: Andy Bierman 
To: Juergen Schoenwaelder , Martin Bjorklund , dromasca@avaya.com, netmod@ietf.org
Content-Type: text/plain; charset=ISO-8859-1
X-Gm-Message-State: ALoCoQlBE7NGDrut6aMevt6Vkp6qOkoh51OjPGS7cnbwBd0H/KQqIGU59mxvI0fE6D5s+APD2uJm
Subject: Re: [netmod] [IANA #668518] Fwd: Re: AD review of draft-ietf-netmod-iana-if-type-04
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 09 Apr 2013 14:55:13 -0000

On Tue, Apr 9, 2013 at 7:46 AM, Juergen Schoenwaelder
 wrote:
> On Tue, Apr 09, 2013 at 03:42:16PM +0200, Martin Bjorklund wrote:
>
>> It is probably just in the word "reserved".  It seems at least two
>> people interpreted this to mean "reserved for now, might be used in
>> the future".
>>
>> May I ask what we gain by adding this enum to the module?
>>
>> If we do it, maybe we could do something like this:
>>
>>   enum not-used-273 {
>>     value 273;
>>     description
>>       "The corresponding transmission value
>>        is allocated according to the following
>>        reference.
>>
>>        This enumeration must not be used by implementations.";
>>     reference
>>       "RFC 6825";
>>   }
>>
>> (the first part of the description is the same as in the "ifType
>> definitions" registry.)
>
> Speaking as technical contributor, I fail to see the value of doing
> this. not-used-273 is not an assigned ifType and so why bother to have
> it in SMIv2/YANG modules? How does this help to manage a network?
>

I agree.
The typedef should only have valid interface types in it.
What's the point of having the list if a developer
has to hard-code specific non-values out of the list?

> I understand that it is important for the registry maintainer to know
> that there are values that are reserved for specific future usages or
> reserved to never be used, but it is not clear to me why information
> about this should to appear in an SMIv2 or YANG module as if these
> numbers were actually registered as an ifType. And I am concerned that
> some of the not-used-XYZ entries then later may find a usage and we
> run into trouble with that.
>
> /js
>
> PS: Note that hyphens are not allowed in SMIv2 labels...
>

Andy

From lhotka@nic.cz  Tue Apr  9 07:58:15 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CEB321F8B49 for ; Tue,  9 Apr 2013 07:58:15 -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=[J_CHICKENPOX_23=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pM1mvSp4DeVF for ; Tue,  9 Apr 2013 07:58:15 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id B7F7021F91CE for ; Tue,  9 Apr 2013 07:58:14 -0700 (PDT)
Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 494961405A5; Tue,  9 Apr 2013 16:58:09 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1365519489; bh=oFNdj52utuhbsdGJpLX4Hy2noAE8zpNgDjYnNjhhb7k=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=dEQ5IPl9dehi1JsCShjUj1KKWcK8JIhsdRV1Xw9Jatsrzn2HK0HVHj5KyTv+xvE7r t5wD/BJw6NwK0u8288U3M8abe3mVvG/ljjSuYZ6T02zGsrCT/K6ymh5OWtVyFX4Lz4 7ZTo08HHjIPaONfvj6rp1p94ZWaeX/rOHfEgvZSw=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
From: Ladislav Lhotka 
In-Reply-To: <20130409144631.GA192@elstar.local>
Date: Tue, 9 Apr 2013 16:58:00 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <203FE3B9-575C-436C-A2BF-DA6719B33464@nic.cz>
References: <9904FB1B0159DA42B0B887B7FA8119CA0C516F@AZ-FFEXMB04.global.avaya.com> <20130409.152827.1381963496459277072.mbj@tail-f.com> <9904FB1B0159DA42B0B887B7FA8119CA0C51F2@AZ-FFEXMB04.global.avaya.com> <20130409.154216.2204981475552383627.mbj@tail-f.com> <20130409144631.GA192@elstar.local>
To: Juergen Schoenwaelder 
X-Mailer: Apple Mail (2.1503)
X-Virus-Scanned: clamav-milter 0.96.5 at mail
X-Virus-Status: Clean
Cc: netmod@ietf.org
Subject: Re: [netmod] [IANA #668518] Fwd: Re: AD review of draft-ietf-netmod-iana-if-type-04
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 09 Apr 2013 14:58:15 -0000

On Apr 9, 2013, at 4:46 PM, Juergen Schoenwaelder =
 wrote:

> On Tue, Apr 09, 2013 at 03:42:16PM +0200, Martin Bjorklund wrote:
>=20
>> It is probably just in the word "reserved".  It seems at least two
>> people interpreted this to mean "reserved for now, might be used in
>> the future".
>>=20
>> May I ask what we gain by adding this enum to the module?
>>=20
>> If we do it, maybe we could do something like this:
>>=20
>>  enum not-used-273 {
>>    value 273;
>>    description
>>      "The corresponding transmission value
>>       is allocated according to the following
>>       reference.
>>=20
>>       This enumeration must not be used by implementations.";
>>    reference
>>      "RFC 6825";
>>  }
>>=20
>> (the first part of the description is the same as in the "ifType
>> definitions" registry.)
>=20
> Speaking as technical contributor, I fail to see the value of doing
> this. not-used-273 is not an assigned ifType and so why bother to have
> it in SMIv2/YANG modules? How does this help to manage a network?
>=20
> I understand that it is important for the registry maintainer to know
> that there are values that are reserved for specific future usages or
> reserved to never be used, but it is not clear to me why information
> about this should to appear in an SMIv2 or YANG module as if these
> numbers were actually registered as an ifType. And I am concerned that
> some of the not-used-XYZ entries then later may find a usage and we
> run into trouble with that.

I agree with Juergen. In fact, if a value is NOT among the enums, it =
cannot be used, and this is how I understand the normal meaning of =
"reserved". The case of RFC 6825 looks somewhat abnormal and I'd suggest =
to use a more descriptive label.

Lada
=20
>=20
> /js
>=20
> PS: Note that hyphens are not allowed in SMIv2 labels...
>=20
> --=20
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
> Fax:   +49 421 200 3103         
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

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





From jouni.nospam@gmail.com  Tue Apr  9 05:32:09 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6568421F8EEB; Tue,  9 Apr 2013 05:32:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yWeTe-c6sxyE; Tue,  9 Apr 2013 05:32:09 -0700 (PDT)
Received: from mail-ea0-x230.google.com (mail-ea0-x230.google.com [IPv6:2a00:1450:4013:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id 8615C21F8F1E; Tue,  9 Apr 2013 05:32:08 -0700 (PDT)
Received: by mail-ea0-f176.google.com with SMTP id h10so2745679eaj.7 for ; Tue, 09 Apr 2013 05:32:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:content-type:content-transfer-encoding:subject:date :message-id:cc:to:mime-version:x-mailer; bh=uDDVf0HHlBnlsGdIU2lTagIwLHH5LvvKf/Ao+8RKHmI=; b=KDy5uzTpUDfrzQ2WemmG2g4NqeyIvr7E807nHCREbQafgYP5of7WNHFvkcRy2JDCs4 En14F48hKWDiSPdEBui2yNa/sSibXyeyG3C9+yc+JR0TVMKHDrtethNakellLVLOtaI0 IU1zwZ+VOAHbMIH6/P2ql7uXu+Dyrd0ixxMomCZY9hlvzroIOzSHMteCnTKMH8APevrp /bUS0lqxK3Zngb1kwZ0+V7Dy71OzJovHxBvMi1O3mYQa4rb2eVJ5Tzr25MA6Jm2Y5ZUH bt9dwJ/rY0g866JXHbSxbCEtm3bv5ZpzZ81qWDV26+Z6e7tRKvLns7xC3zQ0CcH2gozG 8ycg==
X-Received: by 10.14.218.66 with SMTP id j42mr13572784eep.46.1365510726433; Tue, 09 Apr 2013 05:32:06 -0700 (PDT)
Received: from ?IPv6:2001:1bc8:101:f101:39c5:a766:d0ea:341d? ([2001:1bc8:101:f101:39c5:a766:d0ea:341d]) by mx.google.com with ESMTPS id b5sm6017191eew.16.2013.04.09.05.32.04 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 09 Apr 2013 05:32:05 -0700 (PDT)
From: Jouni Korhonen 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Date: Tue, 9 Apr 2013 15:32:03 +0300
Message-Id: <97FEA158-451F-4F48-85B3-5763A6026A8F@gmail.com>
To: netmod@ietf.org
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
X-Mailer: Apple Mail (2.1503)
X-Mailman-Approved-At: Tue, 09 Apr 2013 07:59:14 -0700
Cc: "" 
Subject: [netmod] Comment on draft-ietf-netmod-system-mgmt-05
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 09 Apr 2013 12:32:09 -0000

Folks,

AAA-Doctors track on all documents that specify something that
relates to AAA protocols (RADIUS/Diameter). In that light we
also occasionally provide some early comments before the I-Ds
from other WGs enter IETF LC.

Section 3.4 of draft-ietf-netmod-system-mgmt-05 defines a data
model for the configuration of the RADIUS client. Has the WG
considered additional transports for RADIUS than the original
UDP? RADEXT has defined TCP (RFC6613), TLS (RFC6614) and is
about to complete DTLS (draft-ietf-radext-dtls-04). There are
implementations already out in the field. I would envision 
different transports would have an impact to the data model
(transport type, possible TLS cipher details and credentials,
etc). Or is there a particular reason for not taking alternative
transports into account?

- Jouni (RADEXT co-chair)

From andy@yumaworks.com  Tue Apr  9 08:42:12 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5255921F9764 for ; Tue,  9 Apr 2013 08:42:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.079
X-Spam-Level: 
X-Spam-Status: No, score=-0.079 tagged_above=-999 required=5 tests=[AWL=0.700,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=0.6, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7tKJcwBplHJE for ; Tue,  9 Apr 2013 08:42:11 -0700 (PDT)
Received: from mail-ie0-x235.google.com (mail-ie0-x235.google.com [IPv6:2607:f8b0:4001:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id CC88421F976F for ; Tue,  9 Apr 2013 08:42:11 -0700 (PDT)
Received: by mail-ie0-f181.google.com with SMTP id 17so8466197iea.40 for ; Tue, 09 Apr 2013 08:42:11 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=w4fblGZKLnmrs1yXynHQZ2YEcfU4wRj1bJnF26ENqu4=; b=JsiAw3VgiGQZG9yfLQuIA01jGPPo7/a1kAkPAmJPELgfyXTIARU07Bcp+AI4d8x2h/ 1iEAOV5x+SlpFytUEL7dIOIJL+3RYia6wou0oekfP7zj19uWBeUDNxP2+R4t5OmGuptx j81W9UivLljg9gGPbC//eFznk2szaezNMhZDi6q3PidXbkpHJ7VObmjCP8DunlQd/hrS HWiSjuxTovZPtdI5SI0ve8fza4pRTyVlwIyqqy/1fKW/1MM7J6XjsrcSyzrCquG+jqeQ iD4KH1Eaoeea5C+c4Mm8ia40ArEPXIBFgCnhc8HpLodnjRG5oMofxSfM0f9iQ/O3Rd3Y 8M8g==
MIME-Version: 1.0
X-Received: by 10.42.58.201 with SMTP id j9mr15069025ich.20.1365522131444; Tue, 09 Apr 2013 08:42:11 -0700 (PDT)
Received: by 10.231.11.2 with HTTP; Tue, 9 Apr 2013 08:42:11 -0700 (PDT)
In-Reply-To: <97FEA158-451F-4F48-85B3-5763A6026A8F@gmail.com>
References: <97FEA158-451F-4F48-85B3-5763A6026A8F@gmail.com>
Date: Tue, 9 Apr 2013 08:42:11 -0700
Message-ID: 
From: Andy Bierman 
To: Jouni Korhonen 
Content-Type: text/plain; charset=ISO-8859-1
X-Gm-Message-State: ALoCoQnSi6smBR2rz80g+Y84t91iP900Mu7t+5HeS03hpGz+EVPn27Xs/GGB1gkCWEHadhfZtxsD
Cc: "" , netmod@ietf.org
Subject: Re: [netmod] Comment on draft-ietf-netmod-system-mgmt-05
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 09 Apr 2013 15:42:12 -0000

On Tue, Apr 9, 2013 at 5:32 AM, Jouni Korhonen  wrote:
> Folks,
>
> AAA-Doctors track on all documents that specify something that
> relates to AAA protocols (RADIUS/Diameter). In that light we
> also occasionally provide some early comments before the I-Ds
> from other WGs enter IETF LC.
>
> Section 3.4 of draft-ietf-netmod-system-mgmt-05 defines a data
> model for the configuration of the RADIUS client. Has the WG
> considered additional transports for RADIUS than the original
> UDP? RADEXT has defined TCP (RFC6613), TLS (RFC6614) and is
> about to complete DTLS (draft-ietf-radext-dtls-04). There are
> implementations already out in the field. I would envision
> different transports would have an impact to the data model
> (transport type, possible TLS cipher details and credentials,
> etc). Or is there a particular reason for not taking alternative
> transports into account?
>

thanks for the review.
How would you suggest adding this support?
The radius feature (page 12) references RFC 2865.

If the transport is something the server developer picks,
then perhaps updating the description and reference
statements for this feature is sufficient.

If the transport is something the operator picks,
then it gets more complicated. E.g.,
   - add a config=false leaf or leaf-list identifying the transports
     supported by the server
  - add a config=true leaf to the radius/server list (page 21)
    specifying the transport for the server to use
  - add new identity statements for the standard transports


> - Jouni (RADEXT co-chair)

Andy

From mbj@tail-f.com  Tue Apr  9 12:25:15 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDE7321F989A; Tue,  9 Apr 2013 12:25:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.846
X-Spam-Level: 
X-Spam-Status: No, score=-0.846 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IhZ7fb+pjupH; Tue,  9 Apr 2013 12:25:15 -0700 (PDT)
Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 97BB021F98C2; Tue,  9 Apr 2013 12:25:14 -0700 (PDT)
Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 6372F1200A35; Tue,  9 Apr 2013 21:25:13 +0200 (CEST)
Date: Tue, 09 Apr 2013 21:25:12 +0200 (CEST)
Message-Id: <20130409.212512.301591899.mbj@tail-f.com>
To: andy@yumaworks.com
From: Martin Bjorklund 
In-Reply-To: 
References: <97FEA158-451F-4F48-85B3-5763A6026A8F@gmail.com> 
X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Cc: radext@ietf.org, jouni.nospam@gmail.com, netmod@ietf.org
Subject: Re: [netmod] Comment on draft-ietf-netmod-system-mgmt-05
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 09 Apr 2013 19:25:16 -0000

Andy Bierman  wrote:
> On Tue, Apr 9, 2013 at 5:32 AM, Jouni Korhonen  wrote:
> > Folks,
> >
> > AAA-Doctors track on all documents that specify something that
> > relates to AAA protocols (RADIUS/Diameter). In that light we
> > also occasionally provide some early comments before the I-Ds
> > from other WGs enter IETF LC.
> >
> > Section 3.4 of draft-ietf-netmod-system-mgmt-05 defines a data
> > model for the configuration of the RADIUS client. Has the WG
> > considered additional transports for RADIUS than the original
> > UDP? RADEXT has defined TCP (RFC6613), TLS (RFC6614) and is
> > about to complete DTLS (draft-ietf-radext-dtls-04). There are
> > implementations already out in the field. I would envision
> > different transports would have an impact to the data model
> > (transport type, possible TLS cipher details and credentials,
> > etc). Or is there a particular reason for not taking alternative
> > transports into account?
> >
> 
> thanks for the review.
> How would you suggest adding this support?
> The radius feature (page 12) references RFC 2865.
> 
> If the transport is something the server developer picks,
> then perhaps updating the description and reference
> statements for this feature is sufficient.
> 
> If the transport is something the operator picks,
> then it gets more complicated. E.g.,
>    - add a config=false leaf or leaf-list identifying the transports
>      supported by the server
>   - add a config=true leaf to the radius/server list (page 21)
>     specifying the transport for the server to use
>   - add new identity statements for the standard transports

I think what is needed is more flexibility in the radius server list
(note that we only provide client-side configuration; so in the client
config we list the servers the client can talk to).  Something like
this:

   container radius {
     list server {
       key name;
       ordered-by user;

       leaf name {
         type string;  // arbitrary name
       }
       leaf address {
         type inet:host;
         mandatory true;
       }
       choice transport {
         case udp {
           container udp {
             leaf authentication-port { ... }
             leaf shared-secret { ... }
           }
         case tcp {
           container tcp {
             leaf authentication-port { ... }
             // RFC 6613 section 2.6.7 talks about config parameters
             // maybe include them here?
           }
         }
         case tls {
             leaf port { ... }
             // what else...?
           }
         }
       }
       ...
     }

Note that this is an extensible model; other transports can be added
or augmented into this structure.

One option could be to restructure like this but only actually define
the udp case above, and leave the rest (tcp, tls, dtls) for future
work.


/martin



From phil@juniper.net  Wed Apr 10 16:15:42 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD7A021F8B25 for ; Wed, 10 Apr 2013 16:15:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wlmC4g5OflUx for ; Wed, 10 Apr 2013 16:15:42 -0700 (PDT)
Received: from exprod7og116.obsmtp.com (exprod7og116.obsmtp.com [64.18.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 52C0D21F8AF8 for ; Wed, 10 Apr 2013 16:15:38 -0700 (PDT)
Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob116.postini.com ([64.18.6.12]) with SMTP ID DSNKUWXymO5+14lfiSCX1RoJvDTSWQVm81RR@postini.com; Wed, 10 Apr 2013 16:15:41 PDT
Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB01-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 10 Apr 2013 16:10:32 -0700
Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26])	by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id r3ANAV363235; Wed, 10 Apr 2013 16:10:32 -0700 (PDT)	(envelope-from phil@juniper.net)
Received: from idle.juniper.net (localhost [127.0.0.1])	by idle.juniper.net (8.14.4/8.14.3) with ESMTP id r3AN9Zas015308; Wed, 10 Apr 2013 19:09:55 -0400 (EDT)	(envelope-from phil@idle.juniper.net)
Message-ID: <201304102309.r3AN9Zas015308@idle.juniper.net>
To: Andy Bierman 
In-Reply-To: 
Date: Wed, 10 Apr 2013 19:09:35 -0400
From: Phil Shafer 
MIME-Version: 1.0
Content-Type: text/plain
Cc: netmod@ietf.org
Subject: Re: [netmod] Fwd: New Version Notification for draft-lhotka-netmod-yang-json-01.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 10 Apr 2013 23:15:42 -0000

Andy Bierman writes:
>I prefer to keep the attributes with the parent nodes to make
>parsing, streaming, and access control easier.

It's a tradeoff.  Having attributes with the parent node makes it
easier to get to the attributes at the expense of making it more
painful to get to the real values.

>There could be a convention that "@attributes" and "@value" must
>be used together:
>
>
>   { "config" : {
>      "newleaf": {
>         "@attributes": {
>            "ietf-netconf:operation" : "create"
>         },
>         "@value" : 42
>      }
>  }

This turns the value from config.newleaf to config.newlead["@value"]
(in javascript) which is decidedly less appealing.

>This draft needs to assume a "static" YANG module, meaning
>all the augment-stmts are already applied.  If the set of modules
>on the server has duplicate local-names due to augment or
>just 2 top-level nodes from different modules, then the "long-form"
>of the name has to be used.

But the client won't know if the server needs to use the
"long form" unless it completely groks all the modules that
server implements, which isn't realistic.

Thanks,
 Phil

From phil@juniper.net  Wed Apr 10 16:21:10 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19E6F21F8BA6 for ; Wed, 10 Apr 2013 16:21:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lMEIYaChaJsE for ; Wed, 10 Apr 2013 16:21:09 -0700 (PDT)
Received: from exprod7og125.obsmtp.com (exprod7og125.obsmtp.com [64.18.2.28]) by ietfa.amsl.com (Postfix) with ESMTP id 6F22A21F8B9B for ; Wed, 10 Apr 2013 16:21:07 -0700 (PDT)
Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob125.postini.com ([64.18.6.12]) with SMTP ID DSNKUWXz4tJYySWn0ghy9QLpmGgYBiKtaGbL@postini.com; Wed, 10 Apr 2013 16:21:09 PDT
Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB01-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 10 Apr 2013 16:14:44 -0700
Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26])	by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id r3ANEg365011; Wed, 10 Apr 2013 16:14:43 -0700 (PDT)	(envelope-from phil@juniper.net)
Received: from idle.juniper.net (localhost [127.0.0.1])	by idle.juniper.net (8.14.4/8.14.3) with ESMTP id r3ANDu9t015346; Wed, 10 Apr 2013 19:14:11 -0400 (EDT)	(envelope-from phil@idle.juniper.net)
Message-ID: <201304102314.r3ANDu9t015346@idle.juniper.net>
To: Ladislav Lhotka 
In-Reply-To: 
Date: Wed, 10 Apr 2013 19:13:56 -0400
From: Phil Shafer 
MIME-Version: 1.0
Content-Type: text/plain
Cc: netmod@ietf.org
Subject: Re: [netmod] Fwd: New Version Notification for draft-lhotka-netmod-yang-json-01.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 10 Apr 2013 23:21:10 -0000

Ladislav Lhotka writes:
>But all that being said, the draft is about mapping documents that follow the schema of 
>a YANG data model, and YANG cannot model XML attributes, so they are out of scope.

I don't see how this can work.  YANG defines means of manipulating
the data defined in its data models.  If you can't express that,
you've either dramtically reduced your usefulness or are needing
to redefine all the tools for manipulation.  Both are non-starters
imho.

>Yes, it is a basic assumption that all modules and features etc are known beforehand.

How can this assumption be valid in the "wild", where precious
little is known beforehand?

Thanks,
 Phil

From phil@juniper.net  Wed Apr 10 16:23:09 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56EC321F8C03 for ; Wed, 10 Apr 2013 16:23:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dp7UVBaZXYK2 for ; Wed, 10 Apr 2013 16:23:08 -0700 (PDT)
Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by ietfa.amsl.com (Postfix) with ESMTP id 9379421F8A7E for ; Wed, 10 Apr 2013 16:22:59 -0700 (PDT)
Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP ID DSNKUWX0UyfGK6P1kCveN4FBFZ5tG8nPH8v3@postini.com; Wed, 10 Apr 2013 16:23:03 PDT
Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB01-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 10 Apr 2013 16:17:41 -0700
Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26])	by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id r3ANHe366047; Wed, 10 Apr 2013 16:17:40 -0700 (PDT)	(envelope-from phil@juniper.net)
Received: from idle.juniper.net (localhost [127.0.0.1])	by idle.juniper.net (8.14.4/8.14.3) with ESMTP id r3ANGc9E015380; Wed, 10 Apr 2013 19:16:58 -0400 (EDT)	(envelope-from phil@idle.juniper.net)
Message-ID: <201304102316.r3ANGc9E015380@idle.juniper.net>
To: Martin Bjorklund 
In-Reply-To: <20130407.231853.374864263.mbj@tail-f.com>
Date: Wed, 10 Apr 2013 19:16:38 -0400
From: Phil Shafer 
MIME-Version: 1.0
Content-Type: text/plain
Cc: netmod@ietf.org
Subject: Re: [netmod] Fwd: New Version Notification for draft-lhotka-netmod-yang-json-01.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 10 Apr 2013 23:23:09 -0000

Martin Bjorklund writes:
>> Do we actually have evidence that applications out there make use of
>> the NETCONF edit model?  There is complexity associated with the
>> ability to send an arbitrarily complex edit-config to a device.
>
>We make heavy use of it!  The complexity shows up when we have to deal
>with devices that do *not* support this model.  Given an arbitrary
>changeset, figuring out which CLI commands / SNMP SETs / REST
>PUT,POST,PATCH you have to send, and most importantly, in which
>order to send them is terribly tricky in the general case.

Ditto and amen.

Thanks,
 Phil

From lhotka@nic.cz  Wed Apr 10 23:31:48 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A4D321F8E62 for ; Wed, 10 Apr 2013 23:31:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.248
X-Spam-Level: 
X-Spam-Status: No, score=-0.248 tagged_above=-999 required=5 tests=[AWL=0.847,  BAYES_00=-2.599, HOST_EQ_CZ=0.904, J_CHICKENPOX_23=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gaSpa1DYXVNB for ; Wed, 10 Apr 2013 23:31:47 -0700 (PDT)
Received: from trail.lhotka.name (nat-5.bravonet.cz [77.48.224.5]) by ietfa.amsl.com (Postfix) with ESMTP id A493921F8E5F for ; Wed, 10 Apr 2013 23:31:47 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 2F8615401BA for ; Thu, 11 Apr 2013 08:31:46 +0200 (CEST)
Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yDVEsnOaZPM4 for ; Thu, 11 Apr 2013 08:31: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 E48E554017C for ; Thu, 11 Apr 2013 08:31:38 +0200 (CEST)
From: Ladislav Lhotka 
To: netmod@ietf.org
In-Reply-To: <201304102314.r3ANDu9t015346@idle.juniper.net>
References: <201304102314.r3ANDu9t015346@idle.juniper.net>
User-Agent: Notmuch/0.15.2+56~gf55b35b (http://notmuchmail.org) Emacs/23.3.50.1 (i386-apple-darwin9.8.0)
Mail-Followup-To: netmod@ietf.org
Date: Thu, 11 Apr 2013 08:31:38 +0200
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Subject: Re: [netmod] Fwd: New Version Notification for draft-lhotka-netmod-yang-json-01.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 11 Apr 2013 06:31:48 -0000

Phil Shafer  writes:

> Ladislav Lhotka writes:
>>But all that being said, the draft is about mapping documents that follow the schema of 
>>a YANG data model, and YANG cannot model XML attributes, so they are out of scope.
>
> I don't see how this can work.  YANG defines means of manipulating
> the data defined in its data models.  If you can't express that,

The purpose of this document is to enable encoding of datastore contents (or other YANG-modelled data trees) in JSON and their validation against a YANG data model. As such, it works just fine.

> you've either dramtically reduced your usefulness or are needing
> to redefine all the tools for manipulation.  Both are non-starters
> imho.

Not necessarily, there are other means for specifying edits, such as JSON Patch.
 
>
>>Yes, it is a basic assumption that all modules and features etc are known beforehand.
>
> How can this assumption be valid in the "wild", where precious
> little is known beforehand?

Why? Servers know their data model and send all this info in hello, and REST approaches will presumably make it available through a well-known URI.

Lada

>
> Thanks,
>  Phil

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

From jouni.nospam@gmail.com  Wed Apr 10 23:33:00 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C59321F8D7A; Wed, 10 Apr 2013 23:33:00 -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=[AWL=-0.851, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=0.6, RDNS_NONE=0.1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ykJ5mOqIGFf; Wed, 10 Apr 2013 23:33:00 -0700 (PDT)
Received: from mail-la0-x236.google.com (mail-la0-x236.google.com [IPv6:2a00:1450:4010:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 7AC4821F8D31; Wed, 10 Apr 2013 23:32:59 -0700 (PDT)
Received: by mail-la0-f54.google.com with SMTP id ec20so1155893lab.27 for ; Wed, 10 Apr 2013 23:32:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=J7IUzWWov/0EscTT1ADBwkOtjZldJKjb9G8blSTfBc8=; b=gTBRh37cPSj4VNu6cW+sk62o74vpofcVgDvB0wMRnGoMOH7KDhWIMoqASbDyy2PwKq b3MUTHdi3+fS5igZSHb0QanVrHINa7Is2iK3k4qCuPkYCdq10qeMP5fuZ1iwEGQ8bN4+ 7K4SfemO/RsIchtYeDT+6gLEAPuU0PKU7kPh8yTRw4cdiGoARr0m0tWDfannazO7ArQt 6h9de7xooDL69y9FUrQ7Vde+O8pP2NyuED/GzgFDCAf40mO55QFBpSU8fVXl51VpTP78 p02WVzcEzqwJIo+X/0iLXlPEyJzWmStuAj/F1/BY59/mmY3x1k/WaNc18UO/O7OnANM4 w2Zw==
X-Received: by 10.112.132.134 with SMTP id ou6mr2568065lbb.45.1365661978398; Wed, 10 Apr 2013 23:32:58 -0700 (PDT)
Received: from [192.168.250.235] ([194.100.71.98]) by mx.google.com with ESMTPS id t20sm1202617lbi.5.2013.04.10.23.32.55 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 10 Apr 2013 23:32:56 -0700 (PDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
From: Jouni Korhonen 
In-Reply-To: <20130409.212512.301591899.mbj@tail-f.com>
Date: Thu, 11 Apr 2013 09:32:56 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <8F9CE41F-422C-4143-9261-BAF6F71848E8@gmail.com>
References: <97FEA158-451F-4F48-85B3-5763A6026A8F@gmail.com>  <20130409.212512.301591899.mbj@tail-f.com>
To: Martin Bjorklund 
X-Mailer: Apple Mail (2.1503)
X-Mailman-Approved-At: Wed, 10 Apr 2013 23:58:26 -0700
Cc: radext@ietf.org, jouni.nospam@gmail.com, netmod@ietf.org
Subject: Re: [netmod] Comment on draft-ietf-netmod-system-mgmt-05
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 11 Apr 2013 06:33:00 -0000

Martin,


On Apr 9, 2013, at 10:25 PM, Martin Bjorklund  wrote:

> Andy Bierman  wrote:
>> On Tue, Apr 9, 2013 at 5:32 AM, Jouni Korhonen =
 wrote:
>>> Folks,
>>>=20
>>> AAA-Doctors track on all documents that specify something that
>>> relates to AAA protocols (RADIUS/Diameter). In that light we
>>> also occasionally provide some early comments before the I-Ds
>>> from other WGs enter IETF LC.
>>>=20
>>> Section 3.4 of draft-ietf-netmod-system-mgmt-05 defines a data
>>> model for the configuration of the RADIUS client. Has the WG
>>> considered additional transports for RADIUS than the original
>>> UDP? RADEXT has defined TCP (RFC6613), TLS (RFC6614) and is
>>> about to complete DTLS (draft-ietf-radext-dtls-04). There are
>>> implementations already out in the field. I would envision
>>> different transports would have an impact to the data model
>>> (transport type, possible TLS cipher details and credentials,
>>> etc). Or is there a particular reason for not taking alternative
>>> transports into account?
>>>=20
>>=20
>> thanks for the review.
>> How would you suggest adding this support?
>> The radius feature (page 12) references RFC 2865.
>>=20
>> If the transport is something the server developer picks,
>> then perhaps updating the description and reference
>> statements for this feature is sufficient.
>>=20
>> If the transport is something the operator picks,
>> then it gets more complicated. E.g.,
>>   - add a config=3Dfalse leaf or leaf-list identifying the transports
>>     supported by the server
>>  - add a config=3Dtrue leaf to the radius/server list (page 21)
>>    specifying the transport for the server to use
>>  - add new identity statements for the standard transports
>=20
> I think what is needed is more flexibility in the radius server list
> (note that we only provide client-side configuration; so in the client
> config we list the servers the client can talk to).  Something like
> this:


Something like below would be fine. Of course, it is up to Netmod to
decide what goes in and what does not. We just wanted to point out
that RADIUS has moved on and there are more tools in the box. I
would assume that TLS transport should be interesting for the
management folks.

- Jouni




>=20
>   container radius {
>     list server {
>       key name;
>       ordered-by user;
>=20
>       leaf name {
>         type string;  // arbitrary name
>       }
>       leaf address {
>         type inet:host;
>         mandatory true;
>       }
>       choice transport {
>         case udp {
>           container udp {
>             leaf authentication-port { ... }
>             leaf shared-secret { ... }
>           }
>         case tcp {
>           container tcp {
>             leaf authentication-port { ... }
>             // RFC 6613 section 2.6.7 talks about config parameters
>             // maybe include them here?
>           }
>         }
>         case tls {
>             leaf port { ... }
>             // what else...?
>           }
>         }
>       }
>       ...
>     }
>=20
> Note that this is an extensible model; other transports can be added
> or augmented into this structure.
>=20
> One option could be to restructure like this but only actually define
> the udp case above, and leave the rest (tcp, tls, dtls) for future
> work.
>=20
>=20
> /martin
>=20
>=20


From andy@yumaworks.com  Thu Apr 11 06:40:55 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B7B921F8C1E for ; Thu, 11 Apr 2013 06:40:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.845
X-Spam-Level: 
X-Spam-Status: No, score=-0.845 tagged_above=-999 required=5 tests=[AWL=0.533,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_65=0.6, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CSdk9iTSExCi for ; Thu, 11 Apr 2013 06:40:55 -0700 (PDT)
Received: from mail-ia0-x22e.google.com (mail-ia0-x22e.google.com [IPv6:2607:f8b0:4001:c02::22e]) by ietfa.amsl.com (Postfix) with ESMTP id D9BBE21F8C10 for ; Thu, 11 Apr 2013 06:40:54 -0700 (PDT)
Received: by mail-ia0-f174.google.com with SMTP id r13so1393818iar.19 for ; Thu, 11 Apr 2013 06:40:54 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type:x-gm-message-state; bh=/f2+xfzdL+DyRi+fWmxcwDKliW/M65u6wUJBDW3RUOg=; b=eUovKMB9RRtskFQQvkTaekrXjYUp8qtOuoc8+hOpKM9Xe/gmlmI6Lu7MADltGgDsmS 0IUdwquZfiIPtAgtpUlB2qcE89R1xLZ7fZ/ocWP0cm3DCGVPVr8UnpnLsyLaS0DyShnZ ASVVGr0+ScOWeiT336dcGGKIYQO2fMrW6+8BcXnuWtRZjsEc/Qr9YsTMwlF3IvCc3VTJ 37m6H6/NARyfgU19TeUkxmD7JspohPsMjH8C47M40TMrjDvlPiq/80c9HXk/AnKzuVA1 cCoLBoYrJ4EiUWqpp9pkp/h9vuAjCN5xjZIqTKk0Ak/+8opLw9ui8G6gNopaRyR3UHwd QgwA==
MIME-Version: 1.0
X-Received: by 10.42.151.3 with SMTP id c3mr3915366icw.27.1365687654121; Thu, 11 Apr 2013 06:40:54 -0700 (PDT)
Received: by 10.231.125.202 with HTTP; Thu, 11 Apr 2013 06:40:53 -0700 (PDT)
In-Reply-To: 
References: <201304102314.r3ANDu9t015346@idle.juniper.net> 
Date: Thu, 11 Apr 2013 06:40:53 -0700
Message-ID: 
From: Andy Bierman 
To: netmod@ietf.org
Content-Type: text/plain; charset=ISO-8859-1
X-Gm-Message-State: ALoCoQlF28yjFTMUjj5MWyGPqpmwnUh4h+dp8VBaE2CtDb887n3cFhz3ob2MxD2of8W+QGZLDPBK
Subject: Re: [netmod] Fwd: New Version Notification for draft-lhotka-netmod-yang-json-01.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 11 Apr 2013 13:40:55 -0000

On Wed, Apr 10, 2013 at 11:31 PM, Ladislav Lhotka  wrote:
> Phil Shafer  writes:
>
>> Ladislav Lhotka writes:
>>>But all that being said, the draft is about mapping documents that follow the schema of
>>>a YANG data model, and YANG cannot model XML attributes, so they are out of scope.
>>
>> I don't see how this can work.  YANG defines means of manipulating
>> the data defined in its data models.  If you can't express that,
>
> The purpose of this document is to enable encoding of datastore contents (or other YANG-modelled data trees) in JSON and their validation against a YANG data model. As such, it works just fine.
>
>> you've either dramtically reduced your usefulness or are needing
>> to redefine all the tools for manipulation.  Both are non-starters
>> imho.
>
> Not necessarily, there are other means for specifying edits, such as JSON Patch.

There are also ways to encode attributes, even if we don't
agree on the details yet.

I agree that JSON Patch is better than using attributes
like operation=create or insert=after.

>
>>
>>>Yes, it is a basic assumption that all modules and features etc are known beforehand.
>>
>> How can this assumption be valid in the "wild", where precious
>> little is known beforehand?
>
> Why? Servers know their data model and send all this info in hello, and REST approaches will presumably make it available through a well-known URI.
>

I agree.  There are several companies that have tools which
utilize the hello, get-schema, and /netconf-state info and
build the exact schema tree that the server advertises, starting
from scratch.

That doesn't mean the tool knows the semantics of the knobs,
but 100% of the YANG and CRUD mechanics can be automated.

> Lada
>
>>
>> Thanks,
>>  Phil
>

Andy

From phil@juniper.net  Thu Apr 11 07:33:17 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6C3921F8DD0 for ; Thu, 11 Apr 2013 07:33:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oxfV07ZVo-Dr for ; Thu, 11 Apr 2013 07:33:04 -0700 (PDT)
Received: from exprod7og115.obsmtp.com (exprod7og115.obsmtp.com [64.18.2.217]) by ietfa.amsl.com (Postfix) with ESMTP id 482AD21F85EE for ; Thu, 11 Apr 2013 07:32:33 -0700 (PDT)
Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob115.postini.com ([64.18.6.12]) with SMTP ID DSNKUWbJfxUgiBwOe0vkObCjHDvJf78/Qou2@postini.com; Thu, 11 Apr 2013 07:32:42 PDT
Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB01-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 11 Apr 2013 07:31:21 -0700
Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26])	by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id r3BEVK326778; Thu, 11 Apr 2013 07:31:20 -0700 (PDT)	(envelope-from phil@juniper.net)
Received: from idle.juniper.net (localhost [127.0.0.1])	by idle.juniper.net (8.14.4/8.14.3) with ESMTP id r3BEUYHI020689; Thu, 11 Apr 2013 10:30:49 -0400 (EDT)	(envelope-from phil@idle.juniper.net)
Message-ID: <201304111430.r3BEUYHI020689@idle.juniper.net>
To: Ladislav Lhotka 
In-Reply-To: 
Date: Thu, 11 Apr 2013 10:30:34 -0400
From: Phil Shafer 
MIME-Version: 1.0
Content-Type: text/plain
Cc: netmod@ietf.org
Subject: Re: [netmod] Fwd: New Version Notification for draft-lhotka-netmod-yang-json-01.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 11 Apr 2013 14:33:17 -0000

Ladislav Lhotka writes:
>The purpose of this document is to enable encoding of datastore contents (or other YANG-
>modelled data trees) in JSON and their validation against a YANG data model. As such, it
> works just fine.

Skimming the JSON patch draft; looks like it's missing some vital
functionality.

But in truth, this JSON/REST work is falling into the "netconf 2.0"
trap, where every is being redesigned.  If so, perhaps these issues
don't concern you.

For me, the keys are having a stable usable technology that folks
can implement and deploy.  Anything that implies a redesign is a
step in the wrong direction.

>Why? Servers know their data model and send all this info in hello, and REST approaches 
>will presumably make it available through a well-known URI.

One of the ideas in NETCONF/YANG is that the client doesn't need
to completely understand everything the server implements.  If you
support the FOO model, then my client needs only to grok that model
in order to manipulate your box.  Forcing the client to have complete
understanding would be a step backwards.

Thanks,
 Phil

From phil@juniper.net  Thu Apr 11 07:45:49 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED30D21F8F14 for ; Thu, 11 Apr 2013 07:45:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.299
X-Spam-Level: 
X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aISjvcxN5ikD for ; Thu, 11 Apr 2013 07:45:48 -0700 (PDT)
Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by ietfa.amsl.com (Postfix) with ESMTP id 2BB6421F8EF1 for ; Thu, 11 Apr 2013 07:45:46 -0700 (PDT)
Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP ID DSNKUWbMmARxgrmE3wIzbziRGecGm+k+jDJQ@postini.com; Thu, 11 Apr 2013 07:45:46 PDT
Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB01-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 11 Apr 2013 07:42:59 -0700
Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26])	by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id r3BEgw334246; Thu, 11 Apr 2013 07:42:58 -0700 (PDT)	(envelope-from phil@juniper.net)
Received: from idle.juniper.net (localhost [127.0.0.1])	by idle.juniper.net (8.14.4/8.14.3) with ESMTP id r3BEg7fC020815; Thu, 11 Apr 2013 10:42:28 -0400 (EDT)	(envelope-from phil@idle.juniper.net)
Message-ID: <201304111442.r3BEg7fC020815@idle.juniper.net>
To: Andy Bierman 
In-Reply-To: 
Date: Thu, 11 Apr 2013 10:42:07 -0400
From: Phil Shafer 
MIME-Version: 1.0
Content-Type: text/plain
Cc: netmod@ietf.org
Subject: Re: [netmod] Fwd: New Version Notification for draft-lhotka-netmod-yang-json-01.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 11 Apr 2013 14:45:49 -0000

Andy Bierman writes:
>I agree that JSON Patch is better than using attributes
>like operation=create or insert=after.

I must be missing something.  How does one get insert=after
functionality from JSON patch?  "add" takes only a simple path,
as does "move".

Maybe this is a problem solved by json schema?  Or json pointer?
Or by any of the "redo stuff we had in xml for json" drafts?

I'm still trying to understand what technological improvement is
made when we say '"foo": "none",' instead of 'none'.
I'm just not seeing it.....

Thanks,
 Phil

From lhotka@nic.cz  Thu Apr 11 08:09:47 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D83D21F8FDA for ; Thu, 11 Apr 2013 08:09:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.823
X-Spam-Level: 
X-Spam-Status: No, score=-0.823 tagged_above=-999 required=5 tests=[AWL=0.576,  BAYES_00=-2.599, J_CHICKENPOX_23=0.6, J_CHICKENPOX_65=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YQvhBa-wE4ib for ; Thu, 11 Apr 2013 08:09:46 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 5DCF821F8D90 for ; Thu, 11 Apr 2013 08:09:46 -0700 (PDT)
Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 675AB13FB3F; Thu, 11 Apr 2013 17:09:45 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1365692985; bh=QnBTRebkOYC9EhQXcxUUEhpFLvv7c7Vt8un8EZKbr9Y=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=jEJ0cqXu6Q4EgfZm4SlUoHdySRL3YLqR6MZjDgdeEPsQHJ1sIrUh+WKOCmqiwM4VS CS9Yjtqm1otrv6lyF5qclBStsXh3uGApXEv4X4kpOxTR3FXZs64a9s9e/xbmi5W7OQ dTTcxE5SZRxFt9se6twJ0FahtLRQyT+zTIVLA1aY=
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
From: Ladislav Lhotka 
In-Reply-To: <201304111442.r3BEg7fC020815@idle.juniper.net>
Date: Thu, 11 Apr 2013 17:09:45 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <8C6D5336-2C2D-4DC7-B7D7-2C06E0264DCB@nic.cz>
References: <201304111442.r3BEg7fC020815@idle.juniper.net>
To: Phil Shafer 
X-Mailer: Apple Mail (2.1503)
X-Virus-Scanned: clamav-milter 0.96.5 at mail
X-Virus-Status: Clean
Cc: netmod@ietf.org
Subject: Re: [netmod] Fwd: New Version Notification for draft-lhotka-netmod-yang-json-01.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 11 Apr 2013 15:09:47 -0000

On Apr 11, 2013, at 4:42 PM, Phil Shafer  wrote:

> Andy Bierman writes:
>> I agree that JSON Patch is better than using attributes
>> like operation=3Dcreate or insert=3Dafter.
>=20
> I must be missing something.  How does one get insert=3Dafter
> functionality from JSON patch?  "add" takes only a simple path,
> as does "move".

   o  If the target location specifies an array index, a new value is
      inserted into the array at the specified index.

>=20
> Maybe this is a problem solved by json schema?  Or json pointer?
> Or by any of the "redo stuff we had in xml for json" drafts?
>=20
> I'm still trying to understand what technological improvement is
> made when we say '"foo": "none",' instead of 'none'.
> I'm just not seeing it=85..

Of course, the problem with XML is not in a different serialisation but =
rather in its complexity - mixed content, namespaces etc. Generic tools =
have to support all this.

But nobody says XML is evil, JSON is just an alternative.

Lada

>=20
> Thanks,
> Phil
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

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





From lhotka@nic.cz  Thu Apr 11 08:28:44 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D32621F9058 for ; Thu, 11 Apr 2013 08:28:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.315
X-Spam-Level: 
X-Spam-Status: No, score=-1.315 tagged_above=-999 required=5 tests=[AWL=0.684,  BAYES_00=-2.599, J_CHICKENPOX_23=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kXFmlRE03xGN for ; Thu, 11 Apr 2013 08:28:41 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 23F5621F9036 for ; Thu, 11 Apr 2013 08:28:40 -0700 (PDT)
Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id EFF9D13FB3F; Thu, 11 Apr 2013 17:28:38 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1365694119; bh=ZJbPdMlFRvIm5qDR9a9XW+kwpsBEBSiGim9ml1ovKbM=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=HnZqnSJ3XZhphBeiqkE9zTcN+d4AGk2iPBtrRg+0M52hNMsmyVYQllqqP1kWl7/Fz pDqXZ2AhxQ88sP8Grk+hOmgabqcEpymtgkf1lz8pu9Gyc1nZ0+ZC65zSn7h58wUQed ha/xmk+bAD5Pbh/9FlxoMO+f+ckuculcvWI78m54=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
From: Ladislav Lhotka 
In-Reply-To: <201304111430.r3BEUYHI020689@idle.juniper.net>
Date: Thu, 11 Apr 2013 17:28:38 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <9BED2E1C-51F7-4AD2-863D-CC69276F74C3@nic.cz>
References: <201304111430.r3BEUYHI020689@idle.juniper.net>
To: Phil Shafer 
X-Mailer: Apple Mail (2.1503)
X-Virus-Scanned: clamav-milter 0.96.5 at mail
X-Virus-Status: Clean
Cc: netmod@ietf.org
Subject: Re: [netmod] Fwd: New Version Notification for draft-lhotka-netmod-yang-json-01.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 11 Apr 2013 15:28:44 -0000

On Apr 11, 2013, at 4:30 PM, Phil Shafer  wrote:

> Ladislav Lhotka writes:
>> The purpose of this document is to enable encoding of datastore =
contents (or other YANG-
>> modelled data trees) in JSON and their validation against a YANG data =
model. As such, it
>> works just fine.
>=20
> Skimming the JSON patch draft; looks like it's missing some vital
> functionality.

It's simpler but I think everything what edit-config does should be =
doable, too, perhaps with a few more round-trips. On the other hand, =
JSON Patch clearly separates the locator ("path") from the new contents =
("value"), which is a good thing.

>=20
> But in truth, this JSON/REST work is falling into the "netconf 2.0"
> trap, where every is being redesigned.  If so, perhaps these issues
> don't concern you.
>=20
> For me, the keys are having a stable usable technology that folks
> can implement and deploy.  Anything that implies a redesign is a
> step in the wrong direction.

NETCONF notwithstanding, folks keep designing REST APIs for =
configuration purposes, even in the IETF. I think it would be great if =
YANG could work for them, too.

>=20
>> Why? Servers know their data model and send all this info in hello, =
and REST approaches=20
>> will presumably make it available through a well-known URI.
>=20
> One of the ideas in NETCONF/YANG is that the client doesn't need
> to completely understand everything the server implements.  If you
> support the FOO model, then my client needs only to grok that model
> in order to manipulate your box.  Forcing the client to have complete
> understanding would be a step backwards.

Such a client with an incomplete model can always use the module: prefix =
with all node names, this is allowed. Our goal was to get rid of =
explicit namespace identifiers where possible.

Lada

>=20
> Thanks,
> Phil

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





From andy@yumaworks.com  Thu Apr 11 11:53:20 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3627D21F8DB6 for ; Thu, 11 Apr 2013 11:53:20 -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=[AWL=0.700,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mm0YsB37z1Ji for ; Thu, 11 Apr 2013 11:53:19 -0700 (PDT)
Received: from mail-ia0-x234.google.com (mail-ia0-x234.google.com [IPv6:2607:f8b0:4001:c02::234]) by ietfa.amsl.com (Postfix) with ESMTP id 92B9621F8AE7 for ; Thu, 11 Apr 2013 11:53:19 -0700 (PDT)
Received: by mail-ia0-f180.google.com with SMTP id l29so1684011iag.39 for ; Thu, 11 Apr 2013 11:53:19 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=3E+eEpNSZ2oemBJr7LiZjHfPosozsKT1hurEeBlHRZs=; b=RfdnU6FlJrxObGqStq8K1qNsuZlhKV1U+MaxqFqQZJHyNpBd3HusNJ/kPUDgDabcTI NJ6kgYbMAQRAoWqAw+oWHawBH926my3cQ0yIeSxbP2wc7ibB1GQAp2mF7v9nB6TOyiqi RU73wpjlS2oIXJia9jMIrQ21U7dBucC1m8NHDKy1qxw6tggLCvmF7F6+NwpuYNSaPQXx mhiuxSgi/gcZIVz67z2CLLx575ZOueBXTPwctA/i+t7EXdbWjfClioA7nuTflWiVnsZT yVLgdj1UbhWduqkvzT019wFdNLAsZUiJRD/GVNAn45/dKJdFPCn6r4os7rs0NWLrau55 NP8g==
MIME-Version: 1.0
X-Received: by 10.50.78.202 with SMTP id d10mr17337093igx.69.1365706399065; Thu, 11 Apr 2013 11:53:19 -0700 (PDT)
Received: by 10.231.125.202 with HTTP; Thu, 11 Apr 2013 11:53:18 -0700 (PDT)
In-Reply-To: <9BED2E1C-51F7-4AD2-863D-CC69276F74C3@nic.cz>
References: <201304111430.r3BEUYHI020689@idle.juniper.net> <9BED2E1C-51F7-4AD2-863D-CC69276F74C3@nic.cz>
Date: Thu, 11 Apr 2013 11:53:18 -0700
Message-ID: 
From: Andy Bierman 
To: Ladislav Lhotka 
Content-Type: text/plain; charset=ISO-8859-1
X-Gm-Message-State: ALoCoQmUI1JQc8k9cyf7923UqrnsSsmZgkwUgm5y3C6DwLoTczOq4V9WlvkQAhrvUtToqMmfOCnH
Cc: netmod@ietf.org
Subject: Re: [netmod] Fwd: New Version Notification for draft-lhotka-netmod-yang-json-01.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 11 Apr 2013 18:53:20 -0000

On Thu, Apr 11, 2013 at 8:28 AM, Ladislav Lhotka  wrote:
>
> On Apr 11, 2013, at 4:30 PM, Phil Shafer  wrote:
>
>> Ladislav Lhotka writes:
>>> The purpose of this document is to enable encoding of datastore contents (or other YANG-
>>> modelled data trees) in JSON and their validation against a YANG data model. As such, it
>>> works just fine.
>>
>> Skimming the JSON patch draft; looks like it's missing some vital
>> functionality.
>
> It's simpler but I think everything what edit-config does should be doable, too, perhaps with a few more round-trips. On the other hand, JSON Patch clearly separates the locator ("path") from the new contents ("value"), which is a good thing.
>
>>
>> But in truth, this JSON/REST work is falling into the "netconf 2.0"
>> trap, where every is being redesigned.  If so, perhaps these issues
>> don't concern you.
>>
>> For me, the keys are having a stable usable technology that folks
>> can implement and deploy.  Anything that implies a redesign is a
>> step in the wrong direction.

I am still trying to understand the JSON Pointer RFC,
but I think using array position for edit operations
may be incompatible with system-ordered lists and leaf-lists.

RFC 6020 is not clear whether system ordered means
the server picks some ordering and uses the same ordering
every time, or whether it means there is no document
ordering that the client can depend on.

I think the recent interpretation of JSON Patch implies that
the document ordering has to be stable for the entire PATCH
operation.  That isn't good enough, which is why the If-Match
header is needed.  The entity tag must be changed if document
order of the conceptual datastore or subtree changes.



>
> NETCONF notwithstanding, folks keep designing REST APIs for configuration purposes, even in the IETF. I think it would be great if YANG could work for them, too.
>

I am only interested in using JSON Patch in YANG-API, not NETCONF.


>>
>>> Why? Servers know their data model and send all this info in hello, and REST approaches
>>> will presumably make it available through a well-known URI.
>>
>> One of the ideas in NETCONF/YANG is that the client doesn't need
>> to completely understand everything the server implements.  If you
>> support the FOO model, then my client needs only to grok that model
>> in order to manipulate your box.  Forcing the client to have complete
>> understanding would be a step backwards.
>
> Such a client with an incomplete model can always use the module: prefix with all node names, this is allowed. Our goal was to get rid of explicit namespace identifiers where possible.
>

I don't see how JSON or REST changes anything related to this problem.

> Lada
>
>>
>> Thanks,
>> Phil
>

Andy

From j.schoenwaelder@jacobs-university.de  Thu Apr 11 14:24:25 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D848B21F8FDC for ; Thu, 11 Apr 2013 14:24:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.899
X-Spam-Level: 
X-Spam-Status: No, score=-102.899 tagged_above=-999 required=5 tests=[AWL=0.350, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ECdMtsVE0tk0 for ; Thu, 11 Apr 2013 14:24:25 -0700 (PDT)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 15E7321F8E5C for ; Thu, 11 Apr 2013 14:24:24 -0700 (PDT)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 300B520BD9; Thu, 11 Apr 2013 23:24:20 +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 eFDXjjiVwHsj; Thu, 11 Apr 2013 23:24:19 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id BCECB20BEA; Thu, 11 Apr 2013 23:24:19 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 0FA00259BD17; Thu, 11 Apr 2013 23:24:23 +0200 (CEST)
Date: Thu, 11 Apr 2013 23:24:23 +0200
From: Juergen Schoenwaelder 
To: netmod@ietf.org
Message-ID: <20130411212423.GA13296@elstar.local>
Mail-Followup-To: netmod@ietf.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.21 (2010-09-15)
Subject: [netmod] ietf 86 meeting minutes
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 11 Apr 2013 21:24:26 -0000

Hi,

the minutes of the last IETF meeting have been posted:

http://www.ietf.org/proceedings/86/minutes/minutes-86-netmod

Please review and let me know if any changes are needed.

/js

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

From ietfc@btconnect.com  Fri Apr 12 02:21:34 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F4E921F8D12 for ; Fri, 12 Apr 2013 02:21:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RVj21kD+6R6k for ; Fri, 12 Apr 2013 02:21:28 -0700 (PDT)
Received: from db8outboundpool.messaging.microsoft.com (mail-db8lp0186.outbound.messaging.microsoft.com [213.199.154.186]) by ietfa.amsl.com (Postfix) with ESMTP id 5DC4621F8CE5 for ; Fri, 12 Apr 2013 02:21:25 -0700 (PDT)
Received: from mail109-db8-R.bigfish.com (10.174.8.243) by DB8EHSOBE024.bigfish.com (10.174.4.87) with Microsoft SMTP Server id 14.1.225.23; Fri, 12 Apr 2013 09:21:22 +0000
Received: from mail109-db8 (localhost [127.0.0.1])	by mail109-db8-R.bigfish.com (Postfix) with ESMTP id E051F20314; Fri, 12 Apr 2013 09:21:22 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:157.56.253.85; KIP:(null); UIP:(null); IPV:NLI; H:DB3PRD0710HT001.eurprd07.prod.outlook.com; RD:none; EFVD:NLI
X-SpamScore: -22
X-BigFish: PS-22(zf7Iz98dI9371I542I1432I4015Izz1f42h1fc6h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ahzz1033IL8275bh8275dh8275chz2dh2a8h5a9h668h839h947hd24hf0ah1177h1179h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h1758h17f1h184fh1898h18e1h1946h19b5h19ceh19f0h1ad9h1b0ah304l1155h)
Received: from mail109-db8 (localhost.localdomain [127.0.0.1]) by mail109-db8 (MessageSwitch) id 1365758480720150_2580; Fri, 12 Apr 2013 09:21:20 +0000 (UTC)
Received: from DB8EHSMHS003.bigfish.com (unknown [10.174.8.244])	by mail109-db8.bigfish.com (Postfix) with ESMTP id A35C62C0045; Fri, 12 Apr 2013 09:21:20 +0000 (UTC)
Received: from DB3PRD0710HT001.eurprd07.prod.outlook.com (157.56.253.85) by DB8EHSMHS003.bigfish.com (10.174.4.13) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 12 Apr 2013 09:21:19 +0000
Received: from DB3PRD0511HT002.eurprd05.prod.outlook.com (157.56.254.213) by pod51017.outlook.com (10.255.75.36) with Microsoft SMTP Server (TLS) id 14.16.293.5; Fri, 12 Apr 2013 09:21:17 +0000
Message-ID: <015101ce375e$70845fa0$4001a8c0@gateway.2wire.net>
From: t.petch 
To: Andy Bierman , Ladislav Lhotka 
References: <201304111430.r3BEUYHI020689@idle.juniper.net><9BED2E1C-51F7-4AD2-863D-CC69276F74C3@nic.cz> 
Date: Fri, 12 Apr 2013 10:16:30 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Originating-IP: [157.56.254.213]
X-FOPE-CRA-SourceIpAddress: 157.56.253.85
X-FOPE-CRA-DRYRUN: 1207119;1
X-FOPE-BFA-SENDER: ietfc@btconnect.com
X-FOPE-BFA-RECEIVER: netmod@ietf.org
X-FOPE-BFA-RECEIVER: lhotka@nic.cz
X-FOPE-BFA-RECEIVER: andy@yumaworks.com
X-OriginatorOrg: btconnect.com
Cc: netmod@ietf.org
Subject: Re: [netmod] Fwd: New Version Notification fordraft-lhotka-netmod-yang-json-01.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 12 Apr 2013 09:21:34 -0000

----- Original Message -----
From: "Andy Bierman" 
To: "Ladislav Lhotka" 
Cc: 
Sent: Thursday, April 11, 2013 7:53 PM
> On Thu, Apr 11, 2013 at 8:28 AM, Ladislav Lhotka 
wrote:
> >
> > On Apr 11, 2013, at 4:30 PM, Phil Shafer  wrote:
> >
> >> Ladislav Lhotka writes:
> >>> The purpose of this document is to enable encoding of datastore
contents (or other YANG-
> >>> modelled data trees) in JSON and their validation against a YANG
data model. As such, it
> >>> works just fine.
> >>
> >> Skimming the JSON patch draft; looks like it's missing some vital
> >> functionality.
> >
> > It's simpler but I think everything what edit-config does should be
doable, too, perhaps with a few more round-trips. On the other hand,
JSON Patch clearly separates the locator ("path") from the new contents
("value"), which is a good thing.
> >
> >>
> >> But in truth, this JSON/REST work is falling into the "netconf 2.0"
> >> trap, where every is being redesigned.  If so, perhaps these issues
> >> don't concern you.
> >>
> >> For me, the keys are having a stable usable technology that folks
> >> can implement and deploy.  Anything that implies a redesign is a
> >> step in the wrong direction.
>
> I am still trying to understand the JSON Pointer RFC,
> but I think using array position for edit operations
> may be incompatible with system-ordered lists and leaf-lists.

Andy

I don't know if you ever look at apps-discuss but JSON in its various
aspects has figured substantially there in the past year or two, and
every time it does, it seems to me like a 'topsy' design, lacking a
coherent underpinning, with weak typing and much coercion. Whatever you
do will produce something (as opposed to an error) but you may be
surprised at what that is.

 Recent examples of posts about JSON Pointer  include

'If we were starting from scratch and defining JSON Pointer again I
would argue for distinguishing array indices and object names in the
syntax. For instance, prefix an object name with "/" and an array index
with ":". '

'JSON Pointer does not distinguish between objects and arrays. That is
not
determined until the pointer is applied to an actual object instance...
the
pointer "/1" is valid against {"1":"a"} or ["a","b"] '

'If I understand the issue
correctly, you're basically talking about a client making a blind
partial
update to an arbitrarily structured JSON document whose structure may
have
changed since the last time the client edited it...  In such cases, I
would
argue that you get whatever you end up with.'

This last says to me that you must know precisely what you have to start
with or else you will have no idea what you will end up with, ie lock
the document, read it in its entirety, apply an update, release the
lock - anything else is unpredictable.

Overall I have the impression that there are a lot of flaws yet to be
discovered in the JSON specifications and they are something I hope that
I never have to be involved with.

If you find it hard to understand, perhaps it is because you are asking
questions of it that do not yet have answers:-(

Tom Petch

> RFC 6020 is not clear whether system ordered means
> the server picks some ordering and uses the same ordering
> every time, or whether it means there is no document
> ordering that the client can depend on.
>
> I think the recent interpretation of JSON Patch implies that
> the document ordering has to be stable for the entire PATCH
> operation.  That isn't good enough, which is why the If-Match
> header is needed.  The entity tag must be changed if document
> order of the conceptual datastore or subtree changes.
>
> > NETCONF notwithstanding, folks keep designing REST APIs for
configuration purposes, even in the IETF. I think it would be great if
YANG could work for them, too.
> >
> I am only interested in using JSON Patch in YANG-API, not NETCONF.
> >>
> >>> Why? Servers know their data model and send all this info in
hello, and REST approaches
> >>> will presumably make it available through a well-known URI.
> >>
> >> One of the ideas in NETCONF/YANG is that the client doesn't need
> >> to completely understand everything the server implements.  If you
> >> support the FOO model, then my client needs only to grok that model
> >> in order to manipulate your box.  Forcing the client to have
complete
> >> understanding would be a step backwards.
> >
> > Such a client with an incomplete model can always use the module:
prefix with all node names, this is allowed. Our goal was to get rid of
explicit namespace identifiers where possible.
> >
> I don't see how JSON or REST changes anything related to this problem.
>
> > Lada
> >
> >>
> >> Thanks,
> >> Phil
> >
> Andy



From lhotka@nic.cz  Fri Apr 12 02:45:09 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58DCA21F8AF0 for ; Fri, 12 Apr 2013 02:45:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.034
X-Spam-Level: 
X-Spam-Status: No, score=-1.034 tagged_above=-999 required=5 tests=[AWL=0.061,  BAYES_00=-2.599, HOST_EQ_CZ=0.904, J_CHICKENPOX_23=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bgdogKZovKee for ; Fri, 12 Apr 2013 02:45:08 -0700 (PDT)
Received: from trail.lhotka.name (nat-5.bravonet.cz [77.48.224.5]) by ietfa.amsl.com (Postfix) with ESMTP id 66B9D21F86CD for ; Fri, 12 Apr 2013 02:45:07 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 51661540204 for ; Fri, 12 Apr 2013 11:45:01 +0200 (CEST)
Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t40kOH0MPrEz for ; Fri, 12 Apr 2013 11:44:53 +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 0235354000E for ; Fri, 12 Apr 2013 11:44:47 +0200 (CEST)
From: Ladislav Lhotka 
To: netmod@ietf.org
In-Reply-To: 
References: <201304111430.r3BEUYHI020689@idle.juniper.net> <9BED2E1C-51F7-4AD2-863D-CC69276F74C3@nic.cz> 
User-Agent: Notmuch/0.15.2+56~gf55b35b (http://notmuchmail.org) Emacs/23.3.50.1 (i386-apple-darwin9.8.0)
Mail-Followup-To: netmod@ietf.org
Date: Fri, 12 Apr 2013 11:44:43 +0200
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Subject: Re: [netmod] Fwd: New Version Notification for draft-lhotka-netmod-yang-json-01.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 12 Apr 2013 09:45:09 -0000

Andy Bierman  writes:

> On Thu, Apr 11, 2013 at 8:28 AM, Ladislav Lhotka  wrote:
>>
>> On Apr 11, 2013, at 4:30 PM, Phil Shafer  wrote:
>>
>>> Ladislav Lhotka writes:
>>>> The purpose of this document is to enable encoding of datastore contents (or other YANG-
>>>> modelled data trees) in JSON and their validation against a YANG data model. As such, it
>>>> works just fine.
>>>
>>> Skimming the JSON patch draft; looks like it's missing some vital
>>> functionality.
>>
>> It's simpler but I think everything what edit-config does should be doable, too, perhaps with a few more round-trips. On the other hand, JSON Patch clearly separates the locator ("path") from the new contents ("value"), which is a good thing.
>>
>>>
>>> But in truth, this JSON/REST work is falling into the "netconf 2.0"
>>> trap, where every is being redesigned.  If so, perhaps these issues
>>> don't concern you.
>>>
>>> For me, the keys are having a stable usable technology that folks
>>> can implement and deploy.  Anything that implies a redesign is a
>>> step in the wrong direction.
>
> I am still trying to understand the JSON Pointer RFC,
> but I think using array position for edit operations
> may be incompatible with system-ordered lists and leaf-lists.
>
> RFC 6020 is not clear whether system ordered means
> the server picks some ordering and uses the same ordering
> every time, or whether it means there is no document
> ordering that the client can depend on.

Well, if it is system-ordered, then why bother? New entries can be always appended at the end, right?

>
> I think the recent interpretation of JSON Patch implies that
> the document ordering has to be stable for the entire PATCH
> operation.  That isn't good enough, which is why the If-Match
> header is needed.  The entity tag must be changed if document
> order of the conceptual datastore or subtree changes.
>
>
>
>>
>> NETCONF notwithstanding, folks keep designing REST APIs for configuration purposes, even in the IETF. I think it would be great if YANG could work for them, too.
>>
>
> I am only interested in using JSON Patch in YANG-API, not NETCONF.

Sure.

>
>
>>>
>>>> Why? Servers know their data model and send all this info in hello, and REST approaches
>>>> will presumably make it available through a well-known URI.
>>>
>>> One of the ideas in NETCONF/YANG is that the client doesn't need
>>> to completely understand everything the server implements.  If you
>>> support the FOO model, then my client needs only to grok that model
>>> in order to manipulate your box.  Forcing the client to have complete
>>> understanding would be a step backwards.
>>
>> Such a client with an incomplete model can always use the module: prefix with all node names, this is allowed. Our goal was to get rid of explicit namespace identifiers where possible.
>>
>
> I don't see how JSON or REST changes anything related to this problem.


In XML, the namespace is always expressed, via NS declarations. In JSON, it needn't be the case. If the server advertises modules A and B, and the client only cares about A, then there may be a local name clash that the client is not aware about, caused by an augment in module B.

Lada

>
>> Lada
>>
>>>
>>> Thanks,
>>> Phil
>>
>
> Andy

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

From lhotka@nic.cz  Fri Apr 12 04:05:58 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D26DF21F89D3 for ; Fri, 12 Apr 2013 04:05:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.046
X-Spam-Level: 
X-Spam-Status: No, score=-1.046 tagged_above=-999 required=5 tests=[AWL=0.049,  BAYES_00=-2.599, HOST_EQ_CZ=0.904, J_CHICKENPOX_23=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aHh+bnsCOmrv for ; Fri, 12 Apr 2013 04:05:58 -0700 (PDT)
Received: from trail.lhotka.name (nat-5.bravonet.cz [77.48.224.5]) by ietfa.amsl.com (Postfix) with ESMTP id B5CA421F899E for ; Fri, 12 Apr 2013 04:05:57 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id C7AC0540204 for ; Fri, 12 Apr 2013 13:05:44 +0200 (CEST)
Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l4R1cSMEInTB for ; Fri, 12 Apr 2013 13:05:30 +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 4CBA154017C for ; Fri, 12 Apr 2013 13:05:25 +0200 (CEST)
From: Ladislav Lhotka 
To: netmod@ietf.org
In-Reply-To: <015101ce375e$70845fa0$4001a8c0@gateway.2wire.net>
References: <201304111430.r3BEUYHI020689@idle.juniper.net> <9BED2E1C-51F7-4AD2-863D-CC69276F74C3@nic.cz>  <015101ce375e$70845fa0$4001a8c0@gateway.2wire.net>
User-Agent: Notmuch/0.15.2+56~gf55b35b (http://notmuchmail.org) Emacs/23.3.50.1 (i386-apple-darwin9.8.0)
Mail-Followup-To: netmod@ietf.org
Date: Fri, 12 Apr 2013 13:05:24 +0200
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Subject: Re: [netmod] Fwd: New Version Notification fordraft-lhotka-netmod-yang-json-01.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 12 Apr 2013 11:05:58 -0000

"t.petch"  writes:

>>
>> I am still trying to understand the JSON Pointer RFC,
>> but I think using array position for edit operations
>> may be incompatible with system-ordered lists and leaf-lists.
>
> Andy
>
> I don't know if you ever look at apps-discuss but JSON in its various
> aspects has figured substantially there in the past year or two, and
> every time it does, it seems to me like a 'topsy' design, lacking a
> coherent underpinning, with weak typing and much coercion. Whatever you
> do will produce something (as opposed to an error) but you may be
> surprised at what that is.
>
>  Recent examples of posts about JSON Pointer  include
>
> 'If we were starting from scratch and defining JSON Pointer again I
> would argue for distinguishing array indices and object names in the
> syntax. For instance, prefix an object name with "/" and an array index
> with ":". '

This is not a big issue for us because, luckily, we have a data model, so we are able to discriminate between containers/objects and lists/arrays.

Lada

>
> 'JSON Pointer does not distinguish between objects and arrays. That is
> not
> determined until the pointer is applied to an actual object instance...
> the
> pointer "/1" is valid against {"1":"a"} or ["a","b"] '
>
> 'If I understand the issue
> correctly, you're basically talking about a client making a blind
> partial
> update to an arbitrarily structured JSON document whose structure may
> have
> changed since the last time the client edited it...  In such cases, I
> would
> argue that you get whatever you end up with.'
>
> This last says to me that you must know precisely what you have to start
> with or else you will have no idea what you will end up with, ie lock
> the document, read it in its entirety, apply an update, release the
> lock - anything else is unpredictable.
>
> Overall I have the impression that there are a lot of flaws yet to be
> discovered in the JSON specifications and they are something I hope that
> I never have to be involved with.
>
> If you find it hard to understand, perhaps it is because you are asking
> questions of it that do not yet have answers:-(
>
> Tom Petch
>
>> RFC 6020 is not clear whether system ordered means
>> the server picks some ordering and uses the same ordering
>> every time, or whether it means there is no document
>> ordering that the client can depend on.
>>
>> I think the recent interpretation of JSON Patch implies that
>> the document ordering has to be stable for the entire PATCH
>> operation.  That isn't good enough, which is why the If-Match
>> header is needed.  The entity tag must be changed if document
>> order of the conceptual datastore or subtree changes.
>>
>> > NETCONF notwithstanding, folks keep designing REST APIs for
> configuration purposes, even in the IETF. I think it would be great if
> YANG could work for them, too.
>> >
>> I am only interested in using JSON Patch in YANG-API, not NETCONF.
>> >>
>> >>> Why? Servers know their data model and send all this info in
> hello, and REST approaches
>> >>> will presumably make it available through a well-known URI.
>> >>
>> >> One of the ideas in NETCONF/YANG is that the client doesn't need
>> >> to completely understand everything the server implements.  If you
>> >> support the FOO model, then my client needs only to grok that model
>> >> in order to manipulate your box.  Forcing the client to have
> complete
>> >> understanding would be a step backwards.
>> >
>> > Such a client with an incomplete model can always use the module:
> prefix with all node names, this is allowed. Our goal was to get rid of
> explicit namespace identifiers where possible.
>> >
>> I don't see how JSON or REST changes anything related to this problem.
>>
>> > Lada
>> >
>> >>
>> >> Thanks,
>> >> Phil
>> >
>> Andy
>
>

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

From andy@yumaworks.com  Fri Apr 12 04:54:02 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7725F21F89D3 for ; Fri, 12 Apr 2013 04:54:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.418
X-Spam-Level: 
X-Spam-Status: No, score=-1.418 tagged_above=-999 required=5 tests=[AWL=0.560,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tiwEqF8iyayU for ; Fri, 12 Apr 2013 04:54:02 -0700 (PDT)
Received: from mail-ia0-x234.google.com (mail-ia0-x234.google.com [IPv6:2607:f8b0:4001:c02::234]) by ietfa.amsl.com (Postfix) with ESMTP id CB90621F8976 for ; Fri, 12 Apr 2013 04:54:01 -0700 (PDT)
Received: by mail-ia0-f180.google.com with SMTP id l29so2258794iag.39 for ; Fri, 12 Apr 2013 04:54:01 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type:content-transfer-encoding :x-gm-message-state; bh=AqiUkD0mxP16mjR/OnQSg8xcSHVtHcj71rGGVXhTnE8=; b=Xyzyh4shoTmmyW3o01qm1KJHDb2D1yU314xyEfxxfy8HhtI7POiN/sCpgU/zeZ8MKf ckgdbAhtIPcEl+JIBUw8QH5awWvMpa8jpJCEaasPZxP+1oVchI+t0YQ+jWJjnEhZVGm/ ict08PldRjvoYh8X1cyBWUz6nsHlZd3/BsqCg6Oqbn173NmsdP/6L1e5FFTwQr1v/TVT 4ldgS1n5NuYrQPt/UmzyZ61XYZqPU4OffFzmKLONzk6pC2o7xGQkjh4hp4DRAHMDvMO5 Jfu782z0ZjwwJ7OQfsZSKiIbr8jvK9AY81ZhfFo8MaUZ0nHDM3uZerruzVyNxEZjb17r p9FA==
MIME-Version: 1.0
X-Received: by 10.50.170.36 with SMTP id aj4mr1511841igc.67.1365767641223; Fri, 12 Apr 2013 04:54:01 -0700 (PDT)
Received: by 10.231.125.202 with HTTP; Fri, 12 Apr 2013 04:54:00 -0700 (PDT)
In-Reply-To: 
References: <201304111430.r3BEUYHI020689@idle.juniper.net> <9BED2E1C-51F7-4AD2-863D-CC69276F74C3@nic.cz>  
Date: Fri, 12 Apr 2013 04:54:00 -0700
Message-ID: 
From: Andy Bierman 
To: netmod@ietf.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
X-Gm-Message-State: ALoCoQm6VtnUGVY0ccw5bUUopiK0D5Mrt4+bNKgwsBKyDwW/yfeGYwTQ8q9rNIF/9t0MsxDsdYDE
Subject: Re: [netmod] Fwd: New Version Notification for draft-lhotka-netmod-yang-json-01.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 12 Apr 2013 11:54:02 -0000

On Fri, Apr 12, 2013 at 2:44 AM, Ladislav Lhotka  wrote:
> Andy Bierman  writes:
>
>> On Thu, Apr 11, 2013 at 8:28 AM, Ladislav Lhotka  wrote:
>>>
>>> On Apr 11, 2013, at 4:30 PM, Phil Shafer  wrote:
>>>
>>>> Ladislav Lhotka writes:
>>>>> The purpose of this document is to enable encoding of datastore conte=
nts (or other YANG-
>>>>> modelled data trees) in JSON and their validation against a YANG data=
 model. As such, it
>>>>> works just fine.
>>>>
>>>> Skimming the JSON patch draft; looks like it's missing some vital
>>>> functionality.
>>>
>>> It's simpler but I think everything what edit-config does should be doa=
ble, too, perhaps with a few more round-trips. On the other hand, JSON Patc=
h clearly separates the locator ("path") from the new contents ("value"), w=
hich is a good thing.
>>>
>>>>
>>>> But in truth, this JSON/REST work is falling into the "netconf 2.0"
>>>> trap, where every is being redesigned.  If so, perhaps these issues
>>>> don't concern you.
>>>>
>>>> For me, the keys are having a stable usable technology that folks
>>>> can implement and deploy.  Anything that implies a redesign is a
>>>> step in the wrong direction.
>>
>> I am still trying to understand the JSON Pointer RFC,
>> but I think using array position for edit operations
>> may be incompatible with system-ordered lists and leaf-lists.
>>
>> RFC 6020 is not clear whether system ordered means
>> the server picks some ordering and uses the same ordering
>> every time, or whether it means there is no document
>> ordering that the client can depend on.
>
> Well, if it is system-ordered, then why bother? New entries can be always=
 appended at the end, right?
>

No - YANG insert on a system-ordered list is an error.
Strictly speaking, an array insertion on any system-ordered
object is always an error.

Either the server honors the user request and treats the
data as user-ordered, or the server lies (returns OK)
and inserts the data wherever it wants, or the server
returns an error.


>>
>> I think the recent interpretation of JSON Patch implies that
>> the document ordering has to be stable for the entire PATCH
>> operation.  That isn't good enough, which is why the If-Match
>> header is needed.  The entity tag must be changed if document
>> order of the conceptual datastore or subtree changes.
>>
>>
>>
>>>
>>> NETCONF notwithstanding, folks keep designing REST APIs for configurati=
on purposes, even in the IETF. I think it would be great if YANG could work=
 for them, too.
>>>
>>
>> I am only interested in using JSON Patch in YANG-API, not NETCONF.
>
> Sure.
>
>>
>>
>>>>
>>>>> Why? Servers know their data model and send all this info in hello, a=
nd REST approaches
>>>>> will presumably make it available through a well-known URI.
>>>>
>>>> One of the ideas in NETCONF/YANG is that the client doesn't need
>>>> to completely understand everything the server implements.  If you
>>>> support the FOO model, then my client needs only to grok that model
>>>> in order to manipulate your box.  Forcing the client to have complete
>>>> understanding would be a step backwards.
>>>
>>> Such a client with an incomplete model can always use the module: prefi=
x with all node names, this is allowed. Our goal was to get rid of explicit=
 namespace identifiers where possible.
>>>
>>
>> I don't see how JSON or REST changes anything related to this problem.
>
>
> In XML, the namespace is always expressed, via NS declarations. In JSON, =
it needn't be the case. If the server advertises modules A and B, and the c=
lient only cares about A, then there may be a local name clash that the cli=
ent is not aware about, caused by an augment in module B.

The client will get back a qualified name whether it knows
about the other module or not. If it chooses to ignore all
qualified names that don't match A, then so what?
Garbage in =3D garbage out.

>
> Lada
>

Andy

From andy@yumaworks.com  Fri Apr 12 05:02:45 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93EA221F852A for ; Fri, 12 Apr 2013 05:02:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.211
X-Spam-Level: 
X-Spam-Status: No, score=-1.211 tagged_above=-999 required=5 tests=[AWL=0.167,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_15=0.6, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id af2CQe-r9gmQ for ; Fri, 12 Apr 2013 05:02:45 -0700 (PDT)
Received: from mail-ie0-x22e.google.com (mail-ie0-x22e.google.com [IPv6:2607:f8b0:4001:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id CC24221F859C for ; Fri, 12 Apr 2013 05:02:44 -0700 (PDT)
Received: by mail-ie0-f174.google.com with SMTP id aq17so3182890iec.5 for ; Fri, 12 Apr 2013 05:02:43 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=24gAL6KmRWTmBJvdH6RXU5RF0V39Ba4mLlFeYKiQXQw=; b=LG+KAakZyej0iQwvRD68hwgAsy6Gk0yOcJAbdQbsOpKrg62BLlIf61XAqKt8BJmrcL 9NRzMonmC310uyusK1G3p4SPdIQMBTUJvwqYJ6rZO6K6310HJ2fdavKdkPrZmIEcvcmv 1Iv43e3PiCZx6cTl4dFLE1ex1xCaRiS5jgLCmydo6wEBVJ03rsHguDJ2wPe8W5syZrIv K39NrlNLZ6P9he9h6dvwyHNKblfhd5PUn6LuDZXHpjDzpncGONRit102Et31s67Jp40u LWkTaxHCzEMSit7rTPJWnHjcu41fERsSP7WJh0YzBDACRbUX78ev5F04jiqTIjMsItbc WZ8w==
MIME-Version: 1.0
X-Received: by 10.50.78.202 with SMTP id d10mr1575920igx.69.1365768163314; Fri, 12 Apr 2013 05:02:43 -0700 (PDT)
Received: by 10.231.125.202 with HTTP; Fri, 12 Apr 2013 05:02:43 -0700 (PDT)
In-Reply-To: <015101ce375e$70845fa0$4001a8c0@gateway.2wire.net>
References: <201304111430.r3BEUYHI020689@idle.juniper.net> <9BED2E1C-51F7-4AD2-863D-CC69276F74C3@nic.cz>  <015101ce375e$70845fa0$4001a8c0@gateway.2wire.net>
Date: Fri, 12 Apr 2013 05:02:43 -0700
Message-ID: 
From: Andy Bierman 
To: "t.petch" 
Content-Type: text/plain; charset=ISO-8859-1
X-Gm-Message-State: ALoCoQnnOIDw64jlqbQ933RXo9iiRwTFs+8FyfMRrg2V+nUIpDGbP3xOPIJC4hd/AY6k+pToqWPB
Cc: netmod@ietf.org
Subject: Re: [netmod] Fwd: New Version Notification fordraft-lhotka-netmod-yang-json-01.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 12 Apr 2013 12:02:45 -0000

On Fri, Apr 12, 2013 at 2:16 AM, t.petch  wrote:
> ----- Original Message -----
> From: "Andy Bierman" 
> To: "Ladislav Lhotka" 
> Cc: 
> Sent: Thursday, April 11, 2013 7:53 PM
>> On Thu, Apr 11, 2013 at 8:28 AM, Ladislav Lhotka 
> wrote:
>> >
>> > On Apr 11, 2013, at 4:30 PM, Phil Shafer  wrote:
>> >
>> >> Ladislav Lhotka writes:
>> >>> The purpose of this document is to enable encoding of datastore
> contents (or other YANG-
>> >>> modelled data trees) in JSON and their validation against a YANG
> data model. As such, it
>> >>> works just fine.
>> >>
>> >> Skimming the JSON patch draft; looks like it's missing some vital
>> >> functionality.
>> >
>> > It's simpler but I think everything what edit-config does should be
> doable, too, perhaps with a few more round-trips. On the other hand,
> JSON Patch clearly separates the locator ("path") from the new contents
> ("value"), which is a good thing.
>> >
>> >>
>> >> But in truth, this JSON/REST work is falling into the "netconf 2.0"
>> >> trap, where every is being redesigned.  If so, perhaps these issues
>> >> don't concern you.
>> >>
>> >> For me, the keys are having a stable usable technology that folks
>> >> can implement and deploy.  Anything that implies a redesign is a
>> >> step in the wrong direction.
>>
>> I am still trying to understand the JSON Pointer RFC,
>> but I think using array position for edit operations
>> may be incompatible with system-ordered lists and leaf-lists.
>
> Andy
>
> I don't know if you ever look at apps-discuss but JSON in its various
> aspects has figured substantially there in the past year or two, and
> every time it does, it seems to me like a 'topsy' design, lacking a
> coherent underpinning, with weak typing and much coercion. Whatever you
> do will produce something (as opposed to an error) but you may be
> surprised at what that is.
>

Perhaps they should be using data models instead.
One key feature of Lada's draft is that the underlying
schema drives the CRUD operations, not the
instance document.  A container does not magically
become a list as soon as there are 2 of them.

I think YANG insert + point approach is much better
than JSON Patch because it does not rely
on document position.


>  Recent examples of posts about JSON Pointer  include
>
> 'If we were starting from scratch and defining JSON Pointer again I
> would argue for distinguishing array indices and object names in the
> syntax. For instance, prefix an object name with "/" and an array index
> with ":". '
>
> 'JSON Pointer does not distinguish between objects and arrays. That is
> not
> determined until the pointer is applied to an actual object instance...
> the
> pointer "/1" is valid against {"1":"a"} or ["a","b"] '
>
> 'If I understand the issue
> correctly, you're basically talking about a client making a blind
> partial
> update to an arbitrarily structured JSON document whose structure may
> have
> changed since the last time the client edited it...  In such cases, I
> would
> argue that you get whatever you end up with.'
>
> This last says to me that you must know precisely what you have to start
> with or else you will have no idea what you will end up with, ie lock
> the document, read it in its entirety, apply an update, release the
> lock - anything else is unpredictable.

The server needs to implement entity tags correctly
and the client needs to use IfMatch  correctly.
The server will send a 412 PreCondition Failed error
if the client is not editing the version they think they are editing.


>
> Overall I have the impression that there are a lot of flaws yet to be
> discovered in the JSON specifications and they are something I hope that
> I never have to be involved with.
>
> If you find it hard to understand, perhaps it is because you are asking
> questions of it that do not yet have answers:-(
>
> Tom Petch
>

Andy

>> RFC 6020 is not clear whether system ordered means
>> the server picks some ordering and uses the same ordering
>> every time, or whether it means there is no document
>> ordering that the client can depend on.
>>
>> I think the recent interpretation of JSON Patch implies that
>> the document ordering has to be stable for the entire PATCH
>> operation.  That isn't good enough, which is why the If-Match
>> header is needed.  The entity tag must be changed if document
>> order of the conceptual datastore or subtree changes.
>>
>> > NETCONF notwithstanding, folks keep designing REST APIs for
> configuration purposes, even in the IETF. I think it would be great if
> YANG could work for them, too.
>> >
>> I am only interested in using JSON Patch in YANG-API, not NETCONF.
>> >>
>> >>> Why? Servers know their data model and send all this info in
> hello, and REST approaches
>> >>> will presumably make it available through a well-known URI.
>> >>
>> >> One of the ideas in NETCONF/YANG is that the client doesn't need
>> >> to completely understand everything the server implements.  If you
>> >> support the FOO model, then my client needs only to grok that model
>> >> in order to manipulate your box.  Forcing the client to have
> complete
>> >> understanding would be a step backwards.
>> >
>> > Such a client with an incomplete model can always use the module:
> prefix with all node names, this is allowed. Our goal was to get rid of
> explicit namespace identifiers where possible.
>> >
>> I don't see how JSON or REST changes anything related to this problem.
>>
>> > Lada
>> >
>> >>
>> >> Thanks,
>> >> Phil
>> >
>> Andy
>
>

From lhotka@nic.cz  Fri Apr 12 05:54:29 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 861FE21F86CA for ; Fri, 12 Apr 2013 05:54:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.506
X-Spam-Level: 
X-Spam-Status: No, score=-1.506 tagged_above=-999 required=5 tests=[AWL=0.493,  BAYES_00=-2.599, J_CHICKENPOX_23=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jw7Pzivnx1ZL for ; Fri, 12 Apr 2013 05:54:28 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id AF2D821F8528 for ; Fri, 12 Apr 2013 05:54:26 -0700 (PDT)
Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 14AB813FB3F; Fri, 12 Apr 2013 14:54:25 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1365771265; bh=0kVI7sLdehAXFnilBThP+JGFRAQtb/eF43k0rgIPDRQ=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=OC+PtDQbXnCjW1uBlwLfKilBA3zAXd4o2DAwC15ASUq8FggrXIijycurIUGkbUvt/ I4KIxLPQBRMJNvuom0m4H8asgS3ZPcvX4sLpQOsNJFU83RKJRi8eanlQYnYeD6NUjD lD2zsKthUKN0eMb/9pfNcMQoq8+MyrLmByb8wzYQ=
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
From: Ladislav Lhotka 
In-Reply-To: 
Date: Fri, 12 Apr 2013 14:54:24 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <201304111430.r3BEUYHI020689@idle.juniper.net> <9BED2E1C-51F7-4AD2-863D-CC69276F74C3@nic.cz>   
To: Andy Bierman 
X-Mailer: Apple Mail (2.1503)
X-Virus-Scanned: clamav-milter 0.96.5 at mail
X-Virus-Status: Clean
Cc: netmod@ietf.org
Subject: Re: [netmod] Fwd: New Version Notification for draft-lhotka-netmod-yang-json-01.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 12 Apr 2013 12:54:29 -0000

On Apr 12, 2013, at 1:54 PM, Andy Bierman  wrote:

> On Fri, Apr 12, 2013 at 2:44 AM, Ladislav Lhotka  =
wrote:
>> Andy Bierman  writes:
>>=20
>>> On Thu, Apr 11, 2013 at 8:28 AM, Ladislav Lhotka  =
wrote:
>>>>=20
>>>> On Apr 11, 2013, at 4:30 PM, Phil Shafer  wrote:
>>>>=20
>>>>> Ladislav Lhotka writes:
>>>>>> The purpose of this document is to enable encoding of datastore =
contents (or other YANG-
>>>>>> modelled data trees) in JSON and their validation against a YANG =
data model. As such, it
>>>>>> works just fine.
>>>>>=20
>>>>> Skimming the JSON patch draft; looks like it's missing some vital
>>>>> functionality.
>>>>=20
>>>> It's simpler but I think everything what edit-config does should be =
doable, too, perhaps with a few more round-trips. On the other hand, =
JSON Patch clearly separates the locator ("path") from the new contents =
("value"), which is a good thing.
>>>>=20
>>>>>=20
>>>>> But in truth, this JSON/REST work is falling into the "netconf =
2.0"
>>>>> trap, where every is being redesigned.  If so, perhaps these =
issues
>>>>> don't concern you.
>>>>>=20
>>>>> For me, the keys are having a stable usable technology that folks
>>>>> can implement and deploy.  Anything that implies a redesign is a
>>>>> step in the wrong direction.
>>>=20
>>> I am still trying to understand the JSON Pointer RFC,
>>> but I think using array position for edit operations
>>> may be incompatible with system-ordered lists and leaf-lists.
>>>=20
>>> RFC 6020 is not clear whether system ordered means
>>> the server picks some ordering and uses the same ordering
>>> every time, or whether it means there is no document
>>> ordering that the client can depend on.
>>=20
>> Well, if it is system-ordered, then why bother? New entries can be =
always appended at the end, right?
>>=20
>=20
> No - YANG insert on a system-ordered list is an error.
> Strictly speaking, an array insertion on any system-ordered
> object is always an error.

I cannot find any text in 6020 saying this is an error.

>=20
> Either the server honors the user request and treats the
> data as user-ordered, or the server lies (returns OK)
> and inserts the data wherever it wants, or the server
> returns an error.

We can imagine the server reshuffles the entries of an system-ordered =
list after an insertion, so the actual array index (including '-') is =
irrelevant and the result will be always the same.

=85

>>>>> One of the ideas in NETCONF/YANG is that the client doesn't need
>>>>> to completely understand everything the server implements.  If you
>>>>> support the FOO model, then my client needs only to grok that =
model
>>>>> in order to manipulate your box.  Forcing the client to have =
complete
>>>>> understanding would be a step backwards.
>>>>=20
>>>> Such a client with an incomplete model can always use the module: =
prefix with all node names, this is allowed. Our goal was to get rid of =
explicit namespace identifiers where possible.
>>>>=20
>>>=20
>>> I don't see how JSON or REST changes anything related to this =
problem.
>>=20
>>=20
>> In XML, the namespace is always expressed, via NS declarations. In =
JSON, it needn't be the case. If the server advertises modules A and B, =
and the client only cares about A, then there may be a local name clash =
that the client is not aware about, caused by an augment in module B.
>=20
> The client will get back a qualified name whether it knows
> about the other module or not. If it chooses to ignore all
> qualified names that don't match A, then so what?
> Garbage in =3D garbage out.

Yes, but in the opposite direction, the client can send a name with no =
namespace, and it will be ambiguous for the server.=20

Lada

>=20
>>=20
>> Lada
>>=20
>=20
> Andy
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

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





From lhotka@nic.cz  Fri Apr 12 06:10:32 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E80A21F86D2 for ; Fri, 12 Apr 2013 06:10:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.277
X-Spam-Level: 
X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[AWL=0.122,  BAYES_00=-2.599, J_CHICKENPOX_15=0.6, J_CHICKENPOX_23=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eB8Iif3V7rhT for ; Fri, 12 Apr 2013 06:10:31 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id D129C21F86BB for ; Fri, 12 Apr 2013 06:10:30 -0700 (PDT)
Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 0986C13FB3F; Fri, 12 Apr 2013 15:10:30 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1365772230; bh=lGQgsRrnNqnbM7SdTKrmGMoEXIizDBUvBFFuAFYCdOg=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=ocrusiowBbFyPyMXNF82rljtzXtbS3+t0fHhcVP4R1O5Gcl3yz4jkWoi+DHeEnO3P eVzGnGMchtUPsRYGCSlqDgCZ1a/7GTbeaThpWJ6pjpUYEnzHc57uFNx3PdwCOxZ3Pr DEXzYRoybj7LWsEI6+xcwrBhB6UpTr8S9USKR940=
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
From: Ladislav Lhotka 
In-Reply-To: 
Date: Fri, 12 Apr 2013 15:10:29 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <0E355AEE-FA88-4AF9-AA4A-ED5B69C80826@nic.cz>
References: <201304111430.r3BEUYHI020689@idle.juniper.net> <9BED2E1C-51F7-4AD2-863D-CC69276F74C3@nic.cz>  <015101ce375e$70845fa0$4001a8c0@gateway.2wire.net> 
To: Andy Bierman 
X-Mailer: Apple Mail (2.1503)
X-Virus-Scanned: clamav-milter 0.96.5 at mail
X-Virus-Status: Clean
Cc: netmod@ietf.org
Subject: Re: [netmod] Fwd: New Version Notification fordraft-lhotka-netmod-yang-json-01.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 12 Apr 2013 13:10:32 -0000

On Apr 12, 2013, at 2:02 PM, Andy Bierman  wrote:

> On Fri, Apr 12, 2013 at 2:16 AM, t.petch  wrote:
>> ----- Original Message -----
>> From: "Andy Bierman" 
>> To: "Ladislav Lhotka" 
>> Cc: 
>> Sent: Thursday, April 11, 2013 7:53 PM
>>> On Thu, Apr 11, 2013 at 8:28 AM, Ladislav Lhotka 
>> wrote:
>>>>=20
>>>> On Apr 11, 2013, at 4:30 PM, Phil Shafer  wrote:
>>>>=20
>>>>> Ladislav Lhotka writes:
>>>>>> The purpose of this document is to enable encoding of datastore
>> contents (or other YANG-
>>>>>> modelled data trees) in JSON and their validation against a YANG
>> data model. As such, it
>>>>>> works just fine.
>>>>>=20
>>>>> Skimming the JSON patch draft; looks like it's missing some vital
>>>>> functionality.
>>>>=20
>>>> It's simpler but I think everything what edit-config does should be
>> doable, too, perhaps with a few more round-trips. On the other hand,
>> JSON Patch clearly separates the locator ("path") from the new =
contents
>> ("value"), which is a good thing.
>>>>=20
>>>>>=20
>>>>> But in truth, this JSON/REST work is falling into the "netconf =
2.0"
>>>>> trap, where every is being redesigned.  If so, perhaps these =
issues
>>>>> don't concern you.
>>>>>=20
>>>>> For me, the keys are having a stable usable technology that folks
>>>>> can implement and deploy.  Anything that implies a redesign is a
>>>>> step in the wrong direction.
>>>=20
>>> I am still trying to understand the JSON Pointer RFC,
>>> but I think using array position for edit operations
>>> may be incompatible with system-ordered lists and leaf-lists.
>>=20
>> Andy
>>=20
>> I don't know if you ever look at apps-discuss but JSON in its various
>> aspects has figured substantially there in the past year or two, and
>> every time it does, it seems to me like a 'topsy' design, lacking a
>> coherent underpinning, with weak typing and much coercion. Whatever =
you
>> do will produce something (as opposed to an error) but you may be
>> surprised at what that is.
>>=20
>=20
> Perhaps they should be using data models instead.
> One key feature of Lada's draft is that the underlying
> schema drives the CRUD operations, not the
> instance document.  A container does not magically
> become a list as soon as there are 2 of them.

Exactly, and that's why I also insist on single-entry lists being still =
represented as arrays.
=20
>=20
> I think YANG insert + point approach is much better
> than JSON Patch because it does not rely
> on document position.

Can you give an example?

On the other hand, JSON Patch can easily do things that are forbidden in =
edit-config, such as change a list key. This is because the locator =
("path") is detached from "value".

Lada

>=20
>=20
>> Recent examples of posts about JSON Pointer  include
>>=20
>> 'If we were starting from scratch and defining JSON Pointer again I
>> would argue for distinguishing array indices and object names in the
>> syntax. For instance, prefix an object name with "/" and an array =
index
>> with ":". '
>>=20
>> 'JSON Pointer does not distinguish between objects and arrays. That =
is
>> not
>> determined until the pointer is applied to an actual object =
instance...
>> the
>> pointer "/1" is valid against {"1":"a"} or ["a","b"] '
>>=20
>> 'If I understand the issue
>> correctly, you're basically talking about a client making a blind
>> partial
>> update to an arbitrarily structured JSON document whose structure may
>> have
>> changed since the last time the client edited it...  In such cases, I
>> would
>> argue that you get whatever you end up with.'
>>=20
>> This last says to me that you must know precisely what you have to =
start
>> with or else you will have no idea what you will end up with, ie lock
>> the document, read it in its entirety, apply an update, release the
>> lock - anything else is unpredictable.
>=20
> The server needs to implement entity tags correctly
> and the client needs to use IfMatch  correctly.
> The server will send a 412 PreCondition Failed error
> if the client is not editing the version they think they are editing.
>=20
>=20
>>=20
>> Overall I have the impression that there are a lot of flaws yet to be
>> discovered in the JSON specifications and they are something I hope =
that
>> I never have to be involved with.
>>=20
>> If you find it hard to understand, perhaps it is because you are =
asking
>> questions of it that do not yet have answers:-(
>>=20
>> Tom Petch
>>=20
>=20
> Andy
>=20
>>> RFC 6020 is not clear whether system ordered means
>>> the server picks some ordering and uses the same ordering
>>> every time, or whether it means there is no document
>>> ordering that the client can depend on.
>>>=20
>>> I think the recent interpretation of JSON Patch implies that
>>> the document ordering has to be stable for the entire PATCH
>>> operation.  That isn't good enough, which is why the If-Match
>>> header is needed.  The entity tag must be changed if document
>>> order of the conceptual datastore or subtree changes.
>>>=20
>>>> NETCONF notwithstanding, folks keep designing REST APIs for
>> configuration purposes, even in the IETF. I think it would be great =
if
>> YANG could work for them, too.
>>>>=20
>>> I am only interested in using JSON Patch in YANG-API, not NETCONF.
>>>>>=20
>>>>>> Why? Servers know their data model and send all this info in
>> hello, and REST approaches
>>>>>> will presumably make it available through a well-known URI.
>>>>>=20
>>>>> One of the ideas in NETCONF/YANG is that the client doesn't need
>>>>> to completely understand everything the server implements.  If you
>>>>> support the FOO model, then my client needs only to grok that =
model
>>>>> in order to manipulate your box.  Forcing the client to have
>> complete
>>>>> understanding would be a step backwards.
>>>>=20
>>>> Such a client with an incomplete model can always use the module:
>> prefix with all node names, this is allowed. Our goal was to get rid =
of
>> explicit namespace identifiers where possible.
>>>>=20
>>> I don't see how JSON or REST changes anything related to this =
problem.
>>>=20
>>>> Lada
>>>>=20
>>>>>=20
>>>>> Thanks,
>>>>> Phil
>>>>=20
>>> Andy
>>=20
>>=20

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





From andy@yumaworks.com  Fri Apr 12 06:29:21 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 475E721F8AA6 for ; Fri, 12 Apr 2013 06:29:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.535
X-Spam-Level: 
X-Spam-Status: No, score=-1.535 tagged_above=-999 required=5 tests=[AWL=0.443,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P3OGl7zjAxnR for ; Fri, 12 Apr 2013 06:29:20 -0700 (PDT)
Received: from mail-ie0-x233.google.com (mail-ie0-x233.google.com [IPv6:2607:f8b0:4001:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id 80AA121F8A85 for ; Fri, 12 Apr 2013 06:29:20 -0700 (PDT)
Received: by mail-ie0-f179.google.com with SMTP id qd14so585357ieb.10 for ; Fri, 12 Apr 2013 06:29:20 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=gY2TPm/kCTn1PTISHGhM58K8t2ZvaCobzlbYaWG4L5k=; b=pl0GWGvDkIpoen63/Ukeluf+673u7BKih6gF5/dQbtnBQ5MwgSmWRDIcvWCiTY33Jw nepHy8BLK7yE/rjMjYSDqYQxA3AElIjomQFSB+EvyIXN/rQwTxF7GcDPtiPUKJcIwjNQ +7jFKLfFM2dtaye+bezLWA7oTW8hiwHuCdpTgkZsdrFpY6Q2eFqDYRUQZ4ujBjdUIiFE 2K0WctIvAuGkp/oUbb4+L/xhVagDC0JiPnm8WFQu7oiAzs5mjnlhl4JxNIlTA6hVEwJ0 fk6AJqkcRKBraMr3JmO2y7O6xNK4pT0SSOnN0CBVQkmW/EBOWYFdvxz+DdJse1zJjU+8 hhCA==
MIME-Version: 1.0
X-Received: by 10.50.170.36 with SMTP id aj4mr1725942igc.67.1365773358623; Fri, 12 Apr 2013 06:29:18 -0700 (PDT)
Received: by 10.231.125.202 with HTTP; Fri, 12 Apr 2013 06:29:18 -0700 (PDT)
In-Reply-To: 
References: <201304111430.r3BEUYHI020689@idle.juniper.net> <9BED2E1C-51F7-4AD2-863D-CC69276F74C3@nic.cz>    
Date: Fri, 12 Apr 2013 06:29:18 -0700
Message-ID: 
From: Andy Bierman 
To: Ladislav Lhotka 
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
X-Gm-Message-State: ALoCoQmhHzFzM2DCsfAtyQBaSr4Z+lLD0KrW8ShJy/tXeSTHI9SXwLr5poKG4mxmKuJ5/oLmvexC
Cc: netmod@ietf.org
Subject: Re: [netmod] Fwd: New Version Notification for draft-lhotka-netmod-yang-json-01.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 12 Apr 2013 13:29:21 -0000

On Fri, Apr 12, 2013 at 5:54 AM, Ladislav Lhotka  wrote:
>
> On Apr 12, 2013, at 1:54 PM, Andy Bierman  wrote:
>
>> On Fri, Apr 12, 2013 at 2:44 AM, Ladislav Lhotka  wrote:
>>> Andy Bierman  writes:
>>>
>>>> On Thu, Apr 11, 2013 at 8:28 AM, Ladislav Lhotka  wrote=
:
>>>>>
>>>>> On Apr 11, 2013, at 4:30 PM, Phil Shafer  wrote:
>>>>>
>>>>>> Ladislav Lhotka writes:
>>>>>>> The purpose of this document is to enable encoding of datastore con=
tents (or other YANG-
>>>>>>> modelled data trees) in JSON and their validation against a YANG da=
ta model. As such, it
>>>>>>> works just fine.
>>>>>>
>>>>>> Skimming the JSON patch draft; looks like it's missing some vital
>>>>>> functionality.
>>>>>
>>>>> It's simpler but I think everything what edit-config does should be d=
oable, too, perhaps with a few more round-trips. On the other hand, JSON Pa=
tch clearly separates the locator ("path") from the new contents ("value"),=
 which is a good thing.
>>>>>
>>>>>>
>>>>>> But in truth, this JSON/REST work is falling into the "netconf 2.0"
>>>>>> trap, where every is being redesigned.  If so, perhaps these issues
>>>>>> don't concern you.
>>>>>>
>>>>>> For me, the keys are having a stable usable technology that folks
>>>>>> can implement and deploy.  Anything that implies a redesign is a
>>>>>> step in the wrong direction.
>>>>
>>>> I am still trying to understand the JSON Pointer RFC,
>>>> but I think using array position for edit operations
>>>> may be incompatible with system-ordered lists and leaf-lists.
>>>>
>>>> RFC 6020 is not clear whether system ordered means
>>>> the server picks some ordering and uses the same ordering
>>>> every time, or whether it means there is no document
>>>> ordering that the client can depend on.
>>>
>>> Well, if it is system-ordered, then why bother? New entries can be alwa=
ys appended at the end, right?
>>>
>>
>> No - YANG insert on a system-ordered list is an error.
>> Strictly speaking, an array insertion on any system-ordered
>> object is always an error.
>
> I cannot find any text in 6020 saying this is an error.
>

I cannot find any text that says the insert attribute
refers to something other than a user-ordered list.
All the text related to the insert operation specifically
mentions "user-ordered lists".

IMO this was the intent of the WG.

7.7.1, para 4:

   YANG provides a rich set of facilities within NETCONF's 
   operation that allows the order of list entries in user-ordered lists
   to be controlled.  List entries may be inserted or rearranged,
   positioned as the first or last entry in the list, or positioned
   before or after another specific entry.

7.7.7, para 2

   In an "ordered-by user" leaf-list, the attributes "insert" and
   "value" in the YANG XML namespace (Section 5.3.1) can be used to
   control where in the leaf-list the entry is inserted.  These can be
   used during "create" operations to insert a new leaf-list entry, or
   during "merge" or "replace" operations to insert a new leaf-list
   entry or move an existing one.

7.8.6, para 2


   In an "ordered-by user" list, the attributes "insert" and "key" in
   the YANG XML namespace (Section 5.3.1) can be used to control where
   in the list the entry is inserted.  These can be used during "create"
   operations to insert a new list entry, or during "merge" or "replace"
   operations to insert a new list entry or move an existing one.



>>
>> Either the server honors the user request and treats the
>> data as user-ordered, or the server lies (returns OK)
>> and inserts the data wherever it wants, or the server
>> returns an error.
>
> We can imagine the server reshuffles the entries of an system-ordered lis=
t after an insertion, so the actual array index (including '-') is irreleva=
nt and the result will be always the same.
>

I thinkt it as an error.
Otherwise the server is forced to treat an unordered list
as ordered for the duration of the PATCH operation.
Each edit in the patch list is applying or testing
the document based on the expected document order.

The YANG schema needs to drive the validation.
These rules are specified by the YANG designer,
not the client sending a JSON Patch.

It is usually extremely expensive for the server to treat
all its managed data as a static instance document.
JSON Patch is designed to work on documents not datastores.
Although it could be forced to work on a datastore,
the implementation and runtime resource cost would be significant.


> =85
>
>>>>>> One of the ideas in NETCONF/YANG is that the client doesn't need
>>>>>> to completely understand everything the server implements.  If you
>>>>>> support the FOO model, then my client needs only to grok that model
>>>>>> in order to manipulate your box.  Forcing the client to have complet=
e
>>>>>> understanding would be a step backwards.
>>>>>
>>>>> Such a client with an incomplete model can always use the module: pre=
fix with all node names, this is allowed. Our goal was to get rid of explic=
it namespace identifiers where possible.
>>>>>
>>>>
>>>> I don't see how JSON or REST changes anything related to this problem.
>>>
>>>
>>> In XML, the namespace is always expressed, via NS declarations. In JSON=
, it needn't be the case. If the server advertises modules A and B, and the=
 client only cares about A, then there may be a local name clash that the c=
lient is not aware about, caused by an augment in module B.
>>
>> The client will get back a qualified name whether it knows
>> about the other module or not. If it chooses to ignore all
>> qualified names that don't match A, then so what?
>> Garbage in =3D garbage out.
>
> Yes, but in the opposite direction, the client can send a name with no na=
mespace, and it will be ambiguous for the server.
>

So the server will send an error and the client
will be forced to retry using namespaces.

> Lada
>

Andy

From mbj@tail-f.com  Fri Apr 12 06:35:15 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2349F21F8B13 for ; Fri, 12 Apr 2013 06:35:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.046
X-Spam-Level: 
X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UDAsS0FQ5zxu for ; Fri, 12 Apr 2013 06:35:14 -0700 (PDT)
Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 96CA021F8A91 for ; Fri, 12 Apr 2013 06:35:14 -0700 (PDT)
Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id C9FEB1200D5E; Fri, 12 Apr 2013 15:35:12 +0200 (CEST)
Date: Fri, 12 Apr 2013 15:35:12 +0200 (CEST)
Message-Id: <20130412.153512.576594641611482364.mbj@tail-f.com>
To: andy@yumaworks.com
From: Martin Bjorklund 
In-Reply-To: 
References:   
X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Cc: netmod@ietf.org
Subject: Re: [netmod] Fwd: New Version Notification for draft-lhotka-netmod-yang-json-01.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 12 Apr 2013 13:35:15 -0000

Andy Bierman  wrote:
> > I cannot find any text in 6020 saying this is an error.
> >
> 
> I cannot find any text that says the insert attribute
> refers to something other than a user-ordered list.
> All the text related to the insert operation specifically
> mentions "user-ordered lists".
> 
> IMO this was the intent of the WG.

Yes, and I think the text is clear.

[...]

> 7.7.7, para 2
> 
>    In an "ordered-by user" leaf-list, the attributes "insert" and
>    "value" in the YANG XML namespace (Section 5.3.1) can be used to
>    control where in the leaf-list the entry is inserted.

Here is it clear that the attributes can be used for ordered-by user
leaf-list.  We do not everything that it _cannot_ be used for,
e.g. container, notification, rpc, input, ...


/martin

From andy@yumaworks.com  Fri Apr 12 06:37:53 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 931EE21F84F9 for ; Fri, 12 Apr 2013 06:37:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.591
X-Spam-Level: 
X-Spam-Status: No, score=-1.591 tagged_above=-999 required=5 tests=[AWL=0.387,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iuCD+NknX7yW for ; Fri, 12 Apr 2013 06:37:48 -0700 (PDT)
Received: from mail-ie0-x231.google.com (mail-ie0-x231.google.com [IPv6:2607:f8b0:4001:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id B466A21F84E7 for ; Fri, 12 Apr 2013 06:37:48 -0700 (PDT)
Received: by mail-ie0-f177.google.com with SMTP id 9so3019187iec.22 for ; Fri, 12 Apr 2013 06:37:48 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=2WmCuJDe7pAfTHO2JwGKG0iV0y7WkrZoSWgDMjca7bs=; b=JGkHEFnEceLl04pk2/pLq9GSTWwBzKEFTrpx2nC5GW7ZPV0VO/oouvMM1wvJdRRO3t gyfAPbasdY3OYfMus3p6Qz1Qs1GeiWOXcTI4+nKthbvgSYEe1Fu6sC4UPaTtZHTXZo9Z NEVq3dbMe/n+wgzHGHkGHloRUZ0vUREARyZhDDZP5xIW2/UrdEPQbOEpw0zIjGDtk08B RahcOFAG/5HpzrKgHVY8vHHL3orL10NR1pp9hbwlviz/MX1+UFa+4Vm1+/9gV5JLYiyJ 2EmG9NIq77ehAypICqfBcgjgRMRMIAip7dDf0F2CimmM1VD8FnJr8U/fLz8FwLOF2Slz Hb3g==
MIME-Version: 1.0
X-Received: by 10.43.59.139 with SMTP id wo11mr3919704icb.0.1365773868242; Fri, 12 Apr 2013 06:37:48 -0700 (PDT)
Received: by 10.231.125.202 with HTTP; Fri, 12 Apr 2013 06:37:47 -0700 (PDT)
In-Reply-To: <0E355AEE-FA88-4AF9-AA4A-ED5B69C80826@nic.cz>
References: <201304111430.r3BEUYHI020689@idle.juniper.net> <9BED2E1C-51F7-4AD2-863D-CC69276F74C3@nic.cz>  <015101ce375e$70845fa0$4001a8c0@gateway.2wire.net>  <0E355AEE-FA88-4AF9-AA4A-ED5B69C80826@nic.cz>
Date: Fri, 12 Apr 2013 06:37:47 -0700
Message-ID: 
From: Andy Bierman 
To: Ladislav Lhotka 
Content-Type: text/plain; charset=ISO-8859-1
X-Gm-Message-State: ALoCoQk3t1TCsNTGT9xdax8CsyfQCHNazX6aJtOmUg83OK19u1vBfJVVFA76ko3mssJctG5jQy/G
Cc: netmod@ietf.org
Subject: Re: [netmod] Fwd: New Version Notification fordraft-lhotka-netmod-yang-json-01.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 12 Apr 2013 13:37:53 -0000

...
>> I think YANG insert + point approach is much better
>> than JSON Patch because it does not rely
>> on document position.
>
> Can you give an example?
>

NETCONF (or YANG-API) does not allow
the client to make a new Nth list entry.
You have to identify the insertion point by name.
No 2 servers are expected to use the same
system ordering.  It is not even clear if a server
must maintain the same system order from
1 message to the next, let alone across a reboot.

Insertion by document order is full of problems
and writing reusable client code based on it is a fool's errand.

> On the other hand, JSON Patch can easily do things that are forbidden in edit-config, such as change a list key. This is because the locator ("path") is detached from "value".
>

This is a conceptual "remove" followed immediately
by an "add" operation.  I think YANG insert is
overloaded and a separate "move" attribute would be better.



> Lada

Andy

From lhotka@nic.cz  Fri Apr 12 07:11:20 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECECF21F89DB for ; Fri, 12 Apr 2013 07:11:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.592
X-Spam-Level: 
X-Spam-Status: No, score=-1.592 tagged_above=-999 required=5 tests=[AWL=0.407,  BAYES_00=-2.599, J_CHICKENPOX_23=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5F15vqCLOpdk for ; Fri, 12 Apr 2013 07:11:13 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id C425D21F8A91 for ; Fri, 12 Apr 2013 07:11:12 -0700 (PDT)
Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 7318E13FB3F; Fri, 12 Apr 2013 16:11:11 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1365775871; bh=n2c7r8olAMerkzIvCSijfTCBFA8opk0wBCg09dmLc6M=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=t8vprcAJd4MYy81mPCYMjVPY7QHakhoPgxF0Ti5zL9eGWC35kJv1L9HrWJKryvuBF 1DS1BIA8lnBXJf4RWodKMxJ8THVtrotk5+Za+DXxxC5KeLoN13EjDkYeA+eOjUoo3E QOuIeTrpvWG/mAPQulLqgf94lRtWBFX4d23Uiiio=
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
From: Ladislav Lhotka 
In-Reply-To: <20130412.153512.576594641611482364.mbj@tail-f.com>
Date: Fri, 12 Apr 2013 16:11:11 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:    <20130412.153512.576594641611482364.mbj@tail-f.com>
To: Martin Bjorklund 
X-Mailer: Apple Mail (2.1503)
X-Virus-Scanned: clamav-milter 0.96.5 at mail
X-Virus-Status: Clean
Cc: netmod@ietf.org
Subject: Re: [netmod] Fwd: New Version Notification for draft-lhotka-netmod-yang-json-01.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 12 Apr 2013 14:11:21 -0000

On Apr 12, 2013, at 3:35 PM, Martin Bjorklund  wrote:

> Andy Bierman  wrote:
>>> I cannot find any text in 6020 saying this is an error.
>>>=20
>>=20
>> I cannot find any text that says the insert attribute
>> refers to something other than a user-ordered list.
>> All the text related to the insert operation specifically
>> mentions "user-ordered lists".
>>=20
>> IMO this was the intent of the WG.
>=20
> Yes, and I think the text is clear.
>=20
> [...]
>=20
>> 7.7.7, para 2
>>=20
>>   In an "ordered-by user" leaf-list, the attributes "insert" and
>>   "value" in the YANG XML namespace (Section 5.3.1) can be used to
>>   control where in the leaf-list the entry is inserted.
>=20
> Here is it clear that the attributes can be used for ordered-by user
> leaf-list.  We do not everything that it _cannot_ be used for,
> e.g. container, notification, rpc, input, =85

Actually, sec. 8.3.1 does say something:

   o  If the attributes "before" and "after" appears in any element that
      is not a list whose "ordered-by" property is "user", the server
      MUST reply with an "unknown-attribute" error-tag in the rpc-error.

This seems incorrect, it should be 'If the attribute "yang:insert" whose =
value is either "before" or "after" appears =85'. But even then, it says =
nothing about "first" and "last".

So maybe what was really intended was 'If the attributes "yang:insert" =
or "yang:value" appear =85'?

Lada


>=20
>=20
> /martin

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





From andy@yumaworks.com  Fri Apr 12 07:31:18 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 814A621F8A3F for ; Fri, 12 Apr 2013 07:31:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.634
X-Spam-Level: 
X-Spam-Status: No, score=-1.634 tagged_above=-999 required=5 tests=[AWL=0.344,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id loRE7dailwJV for ; Fri, 12 Apr 2013 07:31:18 -0700 (PDT)
Received: from mail-ia0-x234.google.com (mail-ia0-x234.google.com [IPv6:2607:f8b0:4001:c02::234]) by ietfa.amsl.com (Postfix) with ESMTP id 091D821F89DE for ; Fri, 12 Apr 2013 07:31:17 -0700 (PDT)
Received: by mail-ia0-f180.google.com with SMTP id l29so2412300iag.25 for ; Fri, 12 Apr 2013 07:31:17 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=Q15QTUqX1KbyuCK6hKhICMSFIIAEPeXT1lNk5K6MtoM=; b=pDpi6qDp7lNzNtwm5xHyL1Dw6z6YPrGfKDUWR30Y+03U14qXbN2thJKxQ0pH/yWKdT M44NoFvJSqEuj+2db6I6yk8OOJtNrws2GpvH/WJGR3j3TzrPxucQ4DaK3o0ig5UZEIOz 4WB+7bR8UjLauzD4maOox9dOVpJOifMpfJK03XNeG/IS/I8hTXLwFELrVsgmfmJLqijA TUQNHiIdxszTAG926bCaB9LaRY18RJjnJoptf3LsBWdNIl0wCyjOPnPdA4YWLRRVHk86 yKyrn5rb6tAziFMC4bC46XmnwFdkn3/wxIJn8uH6HI/PfgCQaooz8Mudl+DXXVPZKJIV gpOA==
MIME-Version: 1.0
X-Received: by 10.50.7.69 with SMTP id h5mr1872427iga.69.1365777077320; Fri, 12 Apr 2013 07:31:17 -0700 (PDT)
Received: by 10.231.125.202 with HTTP; Fri, 12 Apr 2013 07:31:17 -0700 (PDT)
In-Reply-To: 
References:    <20130412.153512.576594641611482364.mbj@tail-f.com> 
Date: Fri, 12 Apr 2013 07:31:17 -0700
Message-ID: 
From: Andy Bierman 
To: Ladislav Lhotka 
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
X-Gm-Message-State: ALoCoQkarnUKg4EAOCCdIdg1+IjP048Fb8Bf3fOBJBuIeGl+DbVuI1QtV4zeTCFWlmn5DVq2ocBu
Cc: netmod@ietf.org
Subject: Re: [netmod] Fwd: New Version Notification for draft-lhotka-netmod-yang-json-01.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 12 Apr 2013 14:31:18 -0000

On Fri, Apr 12, 2013 at 7:11 AM, Ladislav Lhotka  wrote:
>
> On Apr 12, 2013, at 3:35 PM, Martin Bjorklund  wrote:
>
>> Andy Bierman  wrote:
>>>> I cannot find any text in 6020 saying this is an error.
>>>>
>>>
>>> I cannot find any text that says the insert attribute
>>> refers to something other than a user-ordered list.
>>> All the text related to the insert operation specifically
>>> mentions "user-ordered lists".
>>>
>>> IMO this was the intent of the WG.
>>
>> Yes, and I think the text is clear.
>>
>> [...]
>>
>>> 7.7.7, para 2
>>>
>>>   In an "ordered-by user" leaf-list, the attributes "insert" and
>>>   "value" in the YANG XML namespace (Section 5.3.1) can be used to
>>>   control where in the leaf-list the entry is inserted.
>>
>> Here is it clear that the attributes can be used for ordered-by user
>> leaf-list.  We do not everything that it _cannot_ be used for,
>> e.g. container, notification, rpc, input, =85
>
> Actually, sec. 8.3.1 does say something:
>
>    o  If the attributes "before" and "after" appears in any element that
>       is not a list whose "ordered-by" property is "user", the server
>       MUST reply with an "unknown-attribute" error-tag in the rpc-error.
>
> This seems incorrect, it should be 'If the attribute "yang:insert" whose =
value is either "before" or "after" appears =85'. But even then, it says no=
thing about "first" and "last".
>
> So maybe what was really intended was 'If the attributes "yang:insert" or=
 "yang:value" appear =85'?
>

No, Martin is correct. Only "ordered-by user" nodes can use
the "insert" attribute.

> Lada
>
>
>>
>>
>> /martin
>

Andy

From lhotka@nic.cz  Fri Apr 12 07:33:10 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DB9F21F86E8 for ; Fri, 12 Apr 2013 07:33:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.637
X-Spam-Level: 
X-Spam-Status: No, score=-1.637 tagged_above=-999 required=5 tests=[AWL=0.362,  BAYES_00=-2.599, J_CHICKENPOX_23=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dq3FnSHratHg for ; Fri, 12 Apr 2013 07:33:09 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 62B1621F89DB for ; Fri, 12 Apr 2013 07:33: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 9F4E6140503; Fri, 12 Apr 2013 16:33:08 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1365777188; bh=4yNaVv7+ga3oLHy4dgYGx0ZYuOXNoBmZJdElCNpITbA=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=eNamO6ABuxY6YMqEysa/bpyHBSredDIRcmOWM/JgaWLDeNoBYpwGp2YHRsqNMhpFW apLQZ3NR2XHRMC8Nn4aw0aH+VQEdx70C/vTvS7hAOAzBwRG2DNN7UHyuT+nXWxKmUB 62IxeV74gRgifHM9g96na1UvXV+MrHfDt0v38e2w=
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
From: Ladislav Lhotka 
In-Reply-To: 
Date: Fri, 12 Apr 2013 16:33:08 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <00FE7AA8-05A9-47F4-A77D-FF49680890EB@nic.cz>
References: <201304111430.r3BEUYHI020689@idle.juniper.net> <9BED2E1C-51F7-4AD2-863D-CC69276F74C3@nic.cz>  <015101ce375e$70845fa0$4001a8c0@gateway.2wire.net>  <0E355AEE-FA88-4AF9-AA4A-ED5B69C80826@nic.cz> 
To: Andy Bierman 
X-Mailer: Apple Mail (2.1503)
X-Virus-Scanned: clamav-milter 0.96.5 at mail
X-Virus-Status: Clean
Cc: netmod@ietf.org
Subject: Re: [netmod] Fwd: New Version Notification fordraft-lhotka-netmod-yang-json-01.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 12 Apr 2013 14:33:10 -0000

On Apr 12, 2013, at 3:37 PM, Andy Bierman  wrote:

> ...
>>> I think YANG insert + point approach is much better
>>> than JSON Patch because it does not rely
>>> on document position.
>>=20
>> Can you give an example?
>>=20
>=20
> NETCONF (or YANG-API) does not allow
> the client to make a new Nth list entry.
> You have to identify the insertion point by name.
> No 2 servers are expected to use the same
> system ordering.  It is not even clear if a server
> must maintain the same system order from
> 1 message to the next, let alone across a reboot.

Mikrotik/RouterOS has an interesting solution to this: The output of =
"print" command presents list entries in a certain order (and assigns =
numbers to them), and this numbering is guaranteed for that CLI session =
till the next "print". I guess something like this would be necessary =
here, too.

Another option is to use more powerful query expressions instead of JSON =
Pointer, e.g. like those in MongoDB.

Lada

>=20
> Insertion by document order is full of problems
> and writing reusable client code based on it is a fool's errand.
>=20
>> On the other hand, JSON Patch can easily do things that are forbidden =
in edit-config, such as change a list key. This is because the locator =
("path") is detached from "value".
>>=20
>=20
> This is a conceptual "remove" followed immediately
> by an "add" operation.  I think YANG insert is
> overloaded and a separate "move" attribute would be better.
>=20
>=20
>=20
>> Lada
>=20
> Andy

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





From balazs.lengyel@ericsson.com  Fri Apr 12 07:34:18 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DF9321F86E8 for ; Fri, 12 Apr 2013 07:34:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.249
X-Spam-Level: 
X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id swk1SP9NfYzf for ; Fri, 12 Apr 2013 07:34:17 -0700 (PDT)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id E2A3A21F8A3F for ; Fri, 12 Apr 2013 07:34:16 -0700 (PDT)
X-AuditID: c1b4fb25-b7f366d000004d10-61-51681b67cab7
Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 59.05.19728.76B18615; Fri, 12 Apr 2013 16:34:16 +0200 (CEST)
Received: from [159.107.197.157] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.279.1; Fri, 12 Apr 2013 16:34:15 +0200
Message-ID: <51681B66.8080308@ericsson.com>
Date: Fri, 12 Apr 2013 16:34:14 +0200
From: Balazs Lengyel 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4
MIME-Version: 1.0
To: netmod@ietf.org
References: 
In-Reply-To: 
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrPJMWRmVeSWpSXmKPExsUyM+JvrW6GdEagwaHHTBbzLzayOjB6LFny kymAMYrLJiU1J7MstUjfLoEr49OyjcwFZ9gqZm9dwdbA+Jmli5GTQ0LAROLGj02MELaYxIV7 69m6GLk4hAROMUqc/PiOBcJZyyix4dxONpAqXgFtib4fb8FsFgFViUlzt4HZbAJGElP7z4NN FRWIkti74TIzRL2gxMmZT8DiIgLCEhOb37GC2MIC6hJPFraCbRYSCJB4fvkEWA2nQKDEw6XP wOLMArYSF+ZcZ4Gw5SW2v53DDFGvIfHwwl/WCYwCs5CsmIWkZRaSlgWMzKsY2XMTM3PSy402 MQID7eCW36o7GO+cEznEKM3BoiTOG+56IUBIID2xJDU7NbUgtSi+qDQntfgQIxMHp1QDY0HB nIw3T44wSWxdeUH52MPJO9tjelMNZ6SdOxNd+48xa9Vj3nV/H/4sDPSere3bsPrZn//FK68o 9hzs0Dw3Xffxzlmt26yW71n89+qn/9FCijF3im5YbFsVvMtKYuWDQGahDwIVPJWnMjlfJk4K Ov3p/sqnjnerWJ5F/1TriDr374zjhIAa+SNKLMUZiYZazEXFiQAIhEBPAgIAAA==
Subject: [netmod] Modeling recursive containment
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 12 Apr 2013 14:34:18 -0000

Hello,
How is it possible to model recursive containment in YANG?
- I want a list representing some managed object e.g. a directory in a 
file system, that can contain a directory in the file system, that can 
contain a directory in a file system ...
- I have a HW module (which can be a slot, a subrack a card, a chassis, 
etc.) which can contain a HW module, ...

What is the best way to do this?
- Using references does not seem to be the best solution. Many tools 
follow containment easily while following references is much more limited.
- Grouping explicitly forbids this kind of construct.

regards Balazs

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
System Manager
ECN: 831 7320                        Tel: +36-1-437-7320
Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.com


From mbj@tail-f.com  Fri Apr 12 07:35:00 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5039921F8A91 for ; Fri, 12 Apr 2013 07:35:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.046
X-Spam-Level: 
X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V6i9UPrXbU98 for ; Fri, 12 Apr 2013 07:34:59 -0700 (PDT)
Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id BE88B21F8A8A for ; Fri, 12 Apr 2013 07:34:59 -0700 (PDT)
Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id E20711200174; Fri, 12 Apr 2013 16:34:58 +0200 (CEST)
Date: Fri, 12 Apr 2013 16:34:58 +0200 (CEST)
Message-Id: <20130412.163458.84468133765899225.mbj@tail-f.com>
To: lhotka@nic.cz
From: Martin Bjorklund 
In-Reply-To: 
References:  <20130412.153512.576594641611482364.mbj@tail-f.com> 
X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=iso-2022-jp
Content-Transfer-Encoding: 7bit
Cc: netmod@ietf.org
Subject: Re: [netmod] Fwd: New Version Notification for draft-lhotka-netmod-yang-json-01.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 12 Apr 2013 14:35:00 -0000

Ladislav Lhotka  wrote:
> 
> On Apr 12, 2013, at 3:35 PM, Martin Bjorklund  wrote:
> 
> > Andy Bierman  wrote:
> >>> I cannot find any text in 6020 saying this is an error.
> >>> 
> >> 
> >> I cannot find any text that says the insert attribute
> >> refers to something other than a user-ordered list.
> >> All the text related to the insert operation specifically
> >> mentions "user-ordered lists".
> >> 
> >> IMO this was the intent of the WG.
> > 
> > Yes, and I think the text is clear.
> > 
> > [...]
> > 
> >> 7.7.7, para 2
> >> 
> >>   In an "ordered-by user" leaf-list, the attributes "insert" and
> >>   "value" in the YANG XML namespace (Section 5.3.1) can be used to
> >>   control where in the leaf-list the entry is inserted.
> > 
> > Here is it clear that the attributes can be used for ordered-by user
> > leaf-list.  We do not everything that it _cannot_ be used for,
> > e.g. container, notification, rpc, input, $B!D(B
> 
> Actually, sec. 8.3.1 does say something:
> 
>    o  If the attributes "before" and "after" appears in any element that
>       is not a list whose "ordered-by" property is "user", the server
>       MUST reply with an "unknown-attribute" error-tag in the rpc-error.
> 
> This seems incorrect, it should be 'If the attribute "yang:insert"
> whose value is either "before" or "after" appears $B!D(B'.

You are right, this text is not correct.  There is no "before"
attribute.  I will check the text.


/martin

From andy@yumaworks.com  Fri Apr 12 07:38:34 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A527721F884A for ; Fri, 12 Apr 2013 07:38:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.668
X-Spam-Level: 
X-Spam-Status: No, score=-1.668 tagged_above=-999 required=5 tests=[AWL=0.310,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dVSfh9QIaHN3 for ; Fri, 12 Apr 2013 07:38:34 -0700 (PDT)
Received: from mail-ia0-x234.google.com (mail-ia0-x234.google.com [IPv6:2607:f8b0:4001:c02::234]) by ietfa.amsl.com (Postfix) with ESMTP id 1929C21F8917 for ; Fri, 12 Apr 2013 07:38:34 -0700 (PDT)
Received: by mail-ia0-f180.google.com with SMTP id l29so2489351iag.11 for ; Fri, 12 Apr 2013 07:38:33 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=1A3UdyOjeOMlymiJ1xBKZ0NAdds/GaBtYStuBcc0eyw=; b=QE6c/WoFpOYCyRXxGRZKLbFx5UNRh/36mFyXcj+dVO+ae/vFVM6UWJqUhYULRpxETW HWsWb/JlDSplHi82/xWAU1U+g11BJ0xQkgOa415d9GH9SHvLbmFCcBCLUWkxb2ttXLmL H65hvmkuo9puHfm1A844o1YeWmSn2BbR4m0fiXlyul4cV/NTAWyWXqrl4EVpEpW1RxXw QBQENfFq8brE/vG7S2hZIJC0vD3zCMxDThcNVIoi3Ve66Mozrqmkvr3a3kvlETowj+yL IuCycapWVxxc2mOjSo+oE/bs9u7/iLQ/q3ZZZMm8h39KmEQpE3eqtnim5uq+pthMOdQ+ A3Wg==
MIME-Version: 1.0
X-Received: by 10.50.236.100 with SMTP id ut4mr1821257igc.86.1365777513588; Fri, 12 Apr 2013 07:38:33 -0700 (PDT)
Received: by 10.231.125.202 with HTTP; Fri, 12 Apr 2013 07:38:33 -0700 (PDT)
In-Reply-To: <20130409.212512.301591899.mbj@tail-f.com>
References: <97FEA158-451F-4F48-85B3-5763A6026A8F@gmail.com>  <20130409.212512.301591899.mbj@tail-f.com>
Date: Fri, 12 Apr 2013 07:38:33 -0700
Message-ID: 
From: Andy Bierman 
To: Martin Bjorklund 
Content-Type: text/plain; charset=ISO-8859-1
X-Gm-Message-State: ALoCoQkis1T6/aH8yO8O0dg3hye4hmLc4O+gueqjadFVSZiY8at5u4fwaiBIC5Vw5MskQfOAxFyo
Cc: radext@ietf.org, jouni.nospam@gmail.com, netmod@ietf.org
Subject: Re: [netmod] Comment on draft-ietf-netmod-system-mgmt-05
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 12 Apr 2013 14:38:34 -0000

....
>    container radius {
>      list server {
>        key name;
>        ordered-by user;
>
>        leaf name {
>          type string;  // arbitrary name
>        }
>        leaf address {
>          type inet:host;
>          mandatory true;
>        }
>        choice transport {
>          case udp {
>            container udp {
>              leaf authentication-port { ... }
>              leaf shared-secret { ... }
>            }
>          case tcp {
              if-feature radius-over-tcp;
>            container tcp {
>              leaf authentication-port { ... }
>              // RFC 6613 section 2.6.7 talks about config parameters
>              // maybe include them here?
>            }
>          }
>          case tls {
                if-feature radius-over-tls;
>              leaf port { ... }
>              // what else...?
>            }
>          }
>        }
>        ...
>      }
>
> Note that this is an extensible model; other transports can be added
> or augmented into this structure.
>

Re: features:
Doesn't the NETCONF server decide what transports it
can use, not the client?  So new cases need to be optional.

> One option could be to restructure like this but only actually define
> the udp case above, and leave the rest (tcp, tls, dtls) for future
> work.
>

Or just define the leafs you have here and leave
the rest for future work.

>
> /martin
>
>

Andy

From lhotka@nic.cz  Fri Apr 12 07:39:56 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3CF621F8B35 for ; Fri, 12 Apr 2013 07:39:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.673
X-Spam-Level: 
X-Spam-Status: No, score=-1.673 tagged_above=-999 required=5 tests=[AWL=0.326,  BAYES_00=-2.599, J_CHICKENPOX_23=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sGRN-rXDqvWO for ; Fri, 12 Apr 2013 07:39:56 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 272C621F8A3F for ; Fri, 12 Apr 2013 07:39:56 -0700 (PDT)
Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 6F3C013FB3F; Fri, 12 Apr 2013 16:39:55 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1365777595; bh=VC9lNNQPx0f5hdqaZbptz2rNdliSfPxrF3H+Zt8S1M8=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=fywU3ShmEevO2OVa9aXapwAmaGf0a/1ypB1THKbkWpwPjeYXiWacvB83PjYJBPDxy LO2cYry/gPTW0pMnub8AiXnZlmv8qWNBVKjhWfMIF2Dty0YU1elwCYfYBaO0J5ySch gSOzzyYmJ5VfAMnqqIZ+RfpZ/uCbYI4qvo706Eys=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
From: Ladislav Lhotka 
In-Reply-To: <51681B66.8080308@ericsson.com>
Date: Fri, 12 Apr 2013 16:39:55 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:  <51681B66.8080308@ericsson.com>
To: Balazs Lengyel 
X-Mailer: Apple Mail (2.1503)
X-Virus-Scanned: clamav-milter 0.96.5 at mail
X-Virus-Status: Clean
Cc: netmod@ietf.org
Subject: Re: [netmod] Modeling recursive containment
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 12 Apr 2013 14:39:57 -0000

Hi Balazs,

On Apr 12, 2013, at 4:34 PM, Balazs Lengyel =
 wrote:

> Hello,
> How is it possible to model recursive containment in YANG?
> - I want a list representing some managed object e.g. a directory in a =
file system, that can contain a directory in the file system, that can =
contain a directory in a file system ...
> - I have a HW module (which can be a slot, a subrack a card, a =
chassis, etc.) which can contain a HW module, ...
>=20
> What is the best way to do this?
> - Using references does not seem to be the best solution. Many tools =
follow containment easily while following references is much more =
limited.
> - Grouping explicitly forbids this kind of construct.

Recursive schemas are not allowed in YANG, and I believe it was a design =
feature.

Lada

>=20
> regards Balazs
>=20
> --=20
> Balazs Lengyel                       Ericsson Hungary Ltd.
> System Manager
> ECN: 831 7320                        Tel: +36-1-437-7320
> Mobile: +36-70-330-7909              email: =
Balazs.Lengyel@ericsson.com
>=20
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

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





From andy@yumaworks.com  Fri Apr 12 08:03:30 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AACA321F8B2B for ; Fri, 12 Apr 2013 08:03:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.696
X-Spam-Level: 
X-Spam-Status: No, score=-1.696 tagged_above=-999 required=5 tests=[AWL=0.282,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7oPHleGQR2Au for ; Fri, 12 Apr 2013 08:03:30 -0700 (PDT)
Received: from mail-ia0-x235.google.com (mail-ia0-x235.google.com [IPv6:2607:f8b0:4001:c02::235]) by ietfa.amsl.com (Postfix) with ESMTP id 2D86F21F89DE for ; Fri, 12 Apr 2013 08:03:30 -0700 (PDT)
Received: by mail-ia0-f181.google.com with SMTP id y25so1537606iay.12 for ; Fri, 12 Apr 2013 08:03:29 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=lYWGj2ArFnXkS3eJmY05kYuL1NVQCXVnf/GKJ6wnvMY=; b=VfKl9+J3OwxdqpqElj0KFkPjYeS03dmzLjWH8OS5g97jSFtnNkI0Dj3QoLtX06SZuW 7SgVKCzST58SjhDrlal8GuzmAIq1V7K21RYbk2xmBrXLWTpVLLzcgLQ4M2j05TBWKWFS fmHcFdeEnfNslIGqiZQYrkA3St4prsqVMNi8/gndHcNOXwmsrcgvK9liQ05EoIn6y+uQ HnVSfXO3ROOEzuWgAHwLD7RusDxdvHTAyuILZjjYlhOVgPGz1H24Yqtg/Lb0lGG+Es1P +RhjBk8GBwfvNfN3ZI6GwRXP1gk1huFNYbLCSFNbhJBZqirBqrjPgtTP/NgZNYCl7a35 LfNg==
MIME-Version: 1.0
X-Received: by 10.50.6.34 with SMTP id x2mr1833887igx.86.1365779009695; Fri, 12 Apr 2013 08:03:29 -0700 (PDT)
Received: by 10.231.125.202 with HTTP; Fri, 12 Apr 2013 08:03:29 -0700 (PDT)
In-Reply-To: <00FE7AA8-05A9-47F4-A77D-FF49680890EB@nic.cz>
References: <201304111430.r3BEUYHI020689@idle.juniper.net> <9BED2E1C-51F7-4AD2-863D-CC69276F74C3@nic.cz>  <015101ce375e$70845fa0$4001a8c0@gateway.2wire.net>  <0E355AEE-FA88-4AF9-AA4A-ED5B69C80826@nic.cz>  <00FE7AA8-05A9-47F4-A77D-FF49680890EB@nic.cz>
Date: Fri, 12 Apr 2013 08:03:29 -0700
Message-ID: 
From: Andy Bierman 
To: Ladislav Lhotka 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
X-Gm-Message-State: ALoCoQlpyrVbJr1jkIUC808hcEb/8/nSDx0fnAozAmgFC44JahhEonpFLh6aRNFJjK5dgMiQmlo6
Cc: netmod@ietf.org
Subject: Re: [netmod] Fwd: New Version Notification fordraft-lhotka-netmod-yang-json-01.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 12 Apr 2013 15:03:30 -0000

On Fri, Apr 12, 2013 at 7:33 AM, Ladislav Lhotka  wrote:
>
> On Apr 12, 2013, at 3:37 PM, Andy Bierman  wrote:
>
>> ...
>>>> I think YANG insert + point approach is much better
>>>> than JSON Patch because it does not rely
>>>> on document position.
>>>
>>> Can you give an example?


Here is a better example why using document order is
a really bad idea when managing networks.

What if the JSON Patch edit on an array is a route injection
into config or operational state on a large router?
The "data nodes" are not represented in YANG trees
within the router.  They are probably not even all in
1 internal data structure, but spread out in various ways.

Asking the router to freeze document order and process
edit or retrieval requests for the Nth route entry is a non-starter.
(e.g, N=3D42003).  The router needs data such as prefix/length
to know where in the system to find the internal table.
There is no document order maintained in the router for this list.
This is an alien and irrelevant concept within the router.


>>>
>>
>> NETCONF (or YANG-API) does not allow
>> the client to make a new Nth list entry.
>> You have to identify the insertion point by name.
>> No 2 servers are expected to use the same
>> system ordering.  It is not even clear if a server
>> must maintain the same system order from
>> 1 message to the next, let alone across a reboot.
>
> Mikrotik/RouterOS has an interesting solution to this: The output of "pri=
nt" command presents list entries in a certain order (and assigns numbers t=
o them), and this numbering is guaranteed for that CLI session till the nex=
t "print". I guess something like this would be necessary here, too.
>
> Another option is to use more powerful query expressions instead of JSON =
Pointer, e.g. like those in MongoDB.
>

I want to leverage existing NETCONF code, so I am
not inclined to reinvent NETCONF datastore editing
just to use JSON message encoding. IMO the message
encoding needs to be completely detached from the
model (classic MVC stuff).  In fact, there is no reason
the server could not support extensible message formats
and let vendors or operators install plugins that support
whatever latest-and-greatest encoding they want to use.


> Lada
>

Andy

From balazs.lengyel@ericsson.com  Fri Apr 12 09:12:15 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5443221F8EC9 for ; Fri, 12 Apr 2013 09:12:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.249
X-Spam-Level: 
X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OQURgLWBwadZ for ; Fri, 12 Apr 2013 09:12:14 -0700 (PDT)
Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 8154921F8EC7 for ; Fri, 12 Apr 2013 09:12:12 -0700 (PDT)
X-AuditID: c1b4fb2d-b7f316d0000028db-e5-5168325bf28a
Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 6A.AD.10459.B5238615; Fri, 12 Apr 2013 18:12:11 +0200 (CEST)
Received: from [159.107.197.157] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.279.1; Fri, 12 Apr 2013 18:12:11 +0200
Message-ID: <5168325A.8060802@ericsson.com>
Date: Fri, 12 Apr 2013 18:12:10 +0200
From: Balazs Lengyel 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4
MIME-Version: 1.0
To: Ladislav Lhotka 
References:  <51681B66.8080308@ericsson.com> 
In-Reply-To: 
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpjluLIzCtJLcpLzFFi42KZGfG3VjfaKCPQoOmItcWFVXPZLOZfbGR1 YPJYsuQnk8emy3cYA5iiuGxSUnMyy1KL9O0SuDJaNv9gLWjnqGi4eYyxgXErWxcjJ4eEgInE rNkTGCFsMYkL99YDxbk4hAROMUrsaN/OAuGsZZQ48GwSM0gVr4C2RMOEdjCbRUBVYuv7KWCT 2ASMJKb2n2cBsUUFoiT2brgMVS8ocXLmE7C4iICyxMUJP8FsZgFhid2Hn7GC2MJAV+zYuBFq 8zxGiQWbV4IN5RSwkpj3fSVUg63EhTnXoWx5ie1v54AtEBLQkHh44S/rBEbBWUj2zULSMgtJ ywJG5lWM7LmJmTnp5YabGIFheXDLb90djKfOiRxilOZgURLnDXO9ECAkkJ5YkpqdmlqQWhRf VJqTWnyIkYmDU6qBMeD75nOskbXSB7d9/bg5xYVTroLhBachk3190Mup78vtIuyFXz/MvXnC vTRk+tXSTU1l82a6/NK9dP6thPbaObEClum5LYmzp0esLHBVnz3hyNoObwO9TTOeh1TViRl8 fbyt0TbGdp3tbpF3k2Jtmy8uZ8qs8LH0arzqqMY+a09ryrH497vXKrEUZyQaajEXFScCABQn xVIZAgAA
Cc: netmod@ietf.org
Subject: Re: [netmod] Modeling recursive containment
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 12 Apr 2013 16:12:15 -0000

On 2013-04-12 16:39, Ladislav Lhotka wrote:
> Hi Balazs,
>
> On Apr 12, 2013, at 4:34 PM, Balazs Lengyel  wrote:
>
>> Hello,
>> How is it possible to model recursive containment in YANG?
>> - I want a list representing some managed object e.g. a directory in a file system, that can contain a directory in the file system, that can contain a directory in a file system ...
>> - I have a HW module (which can be a slot, a subrack a card, a chassis, etc.) which can contain a HW module, ...
>>
>> What is the best way to do this?
>> - Using references does not seem to be the best solution. Many tools follow containment easily while following references is much more limited.
>> - Grouping explicitly forbids this kind of construct.
> Recursive schemas are not allowed in YANG, and I believe it was a design feature.
>
> Lada
>
Sadly the real world does not seem to agree with this design decision, 
which I hated originally as well.
So is there anything better then anyXml?
Balazs

From lhotka@nic.cz  Fri Apr 12 10:01:18 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7A9D21F8D7A for ; Fri, 12 Apr 2013 10:01:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.703
X-Spam-Level: 
X-Spam-Status: No, score=-1.703 tagged_above=-999 required=5 tests=[AWL=0.296,  BAYES_00=-2.599, J_CHICKENPOX_23=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VBgBYIW+EhfF for ; Fri, 12 Apr 2013 10:01:18 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 2912321F87E0 for ; Fri, 12 Apr 2013 10:01:17 -0700 (PDT)
Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id B8F06140427; Fri, 12 Apr 2013 19:01:16 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1365786076; bh=ooYferu3M8dbE4BH+xqvv/AD8e2Xj0dCoQ75ynuRxhc=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=u6gA/bCsj4PUs1gIVQUD8RGgQF5z6ZLR2jZVNUMjfKPJi9S1J+Pse8yfZTy2qPEyg 4OBzV/JKibZbvBiFXJCjE+aEIVWwEexpH0enwkaQZ2Ylr2RklItFauw6Nu8g82AEAA O8hQzcw1cPEPugMsknIzLRGvwVMKV6vh7uOZwZyc=
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
From: Ladislav Lhotka 
In-Reply-To: <5168325A.8060802@ericsson.com>
Date: Fri, 12 Apr 2013 19:01:16 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <7573C6D8-AF3D-459E-A07E-7DB3A494A278@nic.cz>
References:  <51681B66.8080308@ericsson.com>  <5168325A.8060802@ericsson.com>
To: Balazs Lengyel 
X-Mailer: Apple Mail (2.1503)
X-Virus-Scanned: clamav-milter 0.96.5 at mail
X-Virus-Status: Clean
Cc: netmod@ietf.org
Subject: Re: [netmod] Modeling recursive containment
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 12 Apr 2013 17:01:19 -0000

On Apr 12, 2013, at 6:12 PM, Balazs Lengyel =
 wrote:

>=20
> On 2013-04-12 16:39, Ladislav Lhotka wrote:
>> Hi Balazs,
>>=20
>> On Apr 12, 2013, at 4:34 PM, Balazs Lengyel =
 wrote:
>>=20
>>> Hello,
>>> How is it possible to model recursive containment in YANG?
>>> - I want a list representing some managed object e.g. a directory in =
a file system, that can contain a directory in the file system, that can =
contain a directory in a file system ...
>>> - I have a HW module (which can be a slot, a subrack a card, a =
chassis, etc.) which can contain a HW module, ...
>>>=20
>>> What is the best way to do this?
>>> - Using references does not seem to be the best solution. Many tools =
follow containment easily while following references is much more =
limited.
>>> - Grouping explicitly forbids this kind of construct.
>> Recursive schemas are not allowed in YANG, and I believe it was a =
design feature.
>>=20
>> Lada
>>=20
> Sadly the real world does not seem to agree with this design decision, =
which I hated originally as well.
> So is there anything better then anyXml?

Leafrefs, as you wrote. Actually, this is how interface stacks are =
supposed to be implemented.

Lada

> Balazs

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





From kwatsen@juniper.net  Mon Apr 15 13:29:28 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F405421F93BA for ; Mon, 15 Apr 2013 13:29:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.467
X-Spam-Level: 
X-Spam-Status: No, score=-3.467 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b8ygsKX9muX5 for ; Mon, 15 Apr 2013 13:29:27 -0700 (PDT)
Received: from exprod7og119.obsmtp.com (exprod7og119.obsmtp.com [64.18.2.16]) by ietfa.amsl.com (Postfix) with ESMTP id 5301721F93B7 for ; Mon, 15 Apr 2013 13:29:27 -0700 (PDT)
Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob119.postini.com ([64.18.6.12]) with SMTP ID DSNKUWxjJ48sA/SJb5UthySy6FoYWQz0GlNg@postini.com; Mon, 15 Apr 2013 13:29:27 PDT
Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 15 Apr 2013 13:26:01 -0700
Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.59) with Microsoft SMTP Server id 14.1.355.2; Mon, 15 Apr 2013 13:26:01 -0700
Received: from DB8EHSOBE025.bigfish.com (213.199.154.189) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 15 Apr 2013 13:28:18 -0700
Received: from mail183-db8-R.bigfish.com (10.174.8.232) by DB8EHSOBE025.bigfish.com (10.174.4.88) with Microsoft SMTP Server id 14.1.225.23; Mon, 15 Apr 2013 20:25:58 +0000
Received: from mail183-db8 (localhost [127.0.0.1])	by mail183-db8-R.bigfish.com (Postfix) with ESMTP id 6BF5C680530	for ; Mon, 15 Apr 2013 20:25:58 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:157.56.245.197; KIP:(null); UIP:(null); (null); H:CH1PRD0511HT001.namprd05.prod.outlook.com; R:internal; EFV:INT
X-SpamScore: -25
X-BigFish: PS-25(zzbb2dI98dI9371I936eI1432Izz1f42h1fc6h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ahzz1033IL8275bh8275dhz2dh2a8h668h839h946he5bhf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1155h)
Received: from mail183-db8 (localhost.localdomain [127.0.0.1]) by mail183-db8 (MessageSwitch) id 1366057556570470_15461; Mon, 15 Apr 2013 20:25:56 +0000 (UTC)
Received: from DB8EHSMHS016.bigfish.com (unknown [10.174.8.230])	by mail183-db8.bigfish.com (Postfix) with ESMTP id 88FCD140046; Mon, 15 Apr 2013 20:25:56 +0000 (UTC)
Received: from CH1PRD0511HT001.namprd05.prod.outlook.com (157.56.245.197) by DB8EHSMHS016.bigfish.com (10.174.4.26) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 15 Apr 2013 20:25:55 +0000
Received: from CH1PRD0511MB407.namprd05.prod.outlook.com ([169.254.5.91]) by CH1PRD0511HT001.namprd05.prod.outlook.com ([10.255.159.36]) with mapi id 14.16.0293.003; Mon, 15 Apr 2013 20:25:47 +0000
From: Kent Watsen 
To: Balazs Lengyel , Ladislav Lhotka 
Thread-Topic: [netmod] Modeling recursive containment
Thread-Index: AQHON4rsEldgx1c++UisLKXzQyJh05jSqByAgAAZxgCABLrHAA==
Date: Mon, 15 Apr 2013 20:25:46 +0000
Message-ID: 
In-Reply-To: <5168325A.8060802@ericsson.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.3.2.130206
x-originating-ip: [10.255.159.4]
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <1D8822962EFCA04381DEB01106787270@namprd05.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn%
X-FOPE-CONNECTOR: Id%12219$Dn%ERICSSON.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net
X-FOPE-CONNECTOR: Id%12219$Dn%NIC.CZ$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net
X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] Modeling recursive containment
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 15 Apr 2013 20:29:28 -0000

Hey Balazs,

I asked the same question, and for the same reason, 2-3 years ago=8A

I wound up modeling a "worst-case" containment depth:


    grouping component-type {
        leaf model-number {
           type string;
           description "The component's model-number";
        }
        leaf part-number {
           type string;
           description "The component's part-number";
        }
        leaf part-version {
           type string;
           description "The component's part-version";
        }
        leaf serial-number {
           type string;
           description "The component's serial-number";
        }
        description
           "this type is used by both the top-level chassis element
            as well as \"recursively\" by its subcomponents";
    }

    grouping subcomponent-type {
        uses component-type;
        leaf location-id {
            type string;
            mandatory true;
        }
    }
=20

    rpc get-hardware-inventory {
        description
            "Provides the hardware inventory on the device as a
             hierarchy of components rooted by a special component
             called \"chassis\".
        output {
            container hardware-inventory {
                container chassis {
                    uses component-type;
                    list subcomponent {
                        uses subcomponent-type;
                        list subcomponent {
                            uses subcomponent-type;
                            list subcomponent {
                                uses subcomponent-type;
                                list subcomponent {
                                    uses subcomponent-type;
                                    list subcomponent {
                                        uses subcomponent-type;
                                        list subcomponent {
                                            uses subcomponent-type;
                                            list subcomponent {
                                                uses subcomponent-type;
                                            }
                                        }
                                    }
                                }
                            }
                        }
                    }
                }
            }
        }
    }






Kent



On 4/12/13 12:12 PM, "Balazs Lengyel"  wrote:

>
>On 2013-04-12 16:39, Ladislav Lhotka wrote:
>> Hi Balazs,
>>
>> On Apr 12, 2013, at 4:34 PM, Balazs Lengyel
>> wrote:
>>
>>> Hello,
>>> How is it possible to model recursive containment in YANG?
>>> - I want a list representing some managed object e.g. a directory in a
>>>file system, that can contain a directory in the file system, that can
>>>contain a directory in a file system ...
>>> - I have a HW module (which can be a slot, a subrack a card, a
>>>chassis, etc.) which can contain a HW module, ...
>>>
>>> What is the best way to do this?
>>> - Using references does not seem to be the best solution. Many tools
>>>follow containment easily while following references is much more
>>>limited.
>>> - Grouping explicitly forbids this kind of construct.
>> Recursive schemas are not allowed in YANG, and I believe it was a
>>design feature.
>>
>> Lada
>>
>Sadly the real world does not seem to agree with this design decision,
>which I hated originally as well.
>So is there anything better then anyXml?
>Balazs
>_______________________________________________
>netmod mailing list
>netmod@ietf.org
>https://www.ietf.org/mailman/listinfo/netmod
>



From mbj@tail-f.com  Wed Apr 17 00:34:57 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEE5521F9697 for ; Wed, 17 Apr 2013 00:34:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.046
X-Spam-Level: 
X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aiq6vvCE5obs for ; Wed, 17 Apr 2013 00:34:57 -0700 (PDT)
Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 3D6FB21F968A for ; Wed, 17 Apr 2013 00:34:57 -0700 (PDT)
Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 65B751200AD8 for ; Wed, 17 Apr 2013 09:34:55 +0200 (CEST)
Date: Wed, 17 Apr 2013 09:34:55 +0200 (CEST)
Message-Id: <20130417.093455.1132768532036936745.mbj@tail-f.com>
To: netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: <203FE3B9-575C-436C-A2BF-DA6719B33464@nic.cz>
References: <20130409.154216.2204981475552383627.mbj@tail-f.com> <20130409144631.GA192@elstar.local> <203FE3B9-575C-436C-A2BF-DA6719B33464@nic.cz>
X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: Re: [netmod] [IANA #668518] Fwd: Re: AD review of draft-ietf-netmod-iana-if-type-04
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Apr 2013 07:34:57 -0000

Hi,

I am not sure if anything has been decided for this issue, but if we
go with the solution that values that are "reserved" in the registry
are NOT reflected in the YANG module, I suggest we add this sentence to
the second paragraph in the IANA Considerations section:


  If an interface type is marked as "reserved" in the "ifType
  definitions" registry, no "enum" statement is added to the
  "iana-if-type" typedef.


/martin




From mbj@tail-f.com  Wed Apr 17 00:42:30 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4502E21F96BC for ; Wed, 17 Apr 2013 00:42:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.538
X-Spam-Level: 
X-Spam-Status: No, score=-0.538 tagged_above=-999 required=5 tests=[AWL=-1.507, BAYES_40=-0.185, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, J_CHICKENPOX_39=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GtzUQUHppl7t for ; Wed, 17 Apr 2013 00:42:29 -0700 (PDT)
Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 7004921F968A for ; Wed, 17 Apr 2013 00:42:29 -0700 (PDT)
Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id BFB211200AD8; Wed, 17 Apr 2013 09:42:28 +0200 (CEST)
Date: Wed, 17 Apr 2013 09:42:28 +0200 (CEST)
Message-Id: <20130417.094228.1068134205727356492.mbj@tail-f.com>
To: bclaise@cisco.com
From: Martin Bjorklund 
In-Reply-To: <20130408.233810.311649160.mbj@tail-f.com>
References: <20130402.230149.92811084.mbj@tail-f.com> <5162F4D6.6020009@cisco.com> <20130408.233810.311649160.mbj@tail-f.com>
X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Multipart/Mixed; boundary="--Next_Part(Wed_Apr_17_09_42_28_2013_002)--"
Content-Transfer-Encoding: 7bit
Cc: netmod@ietf.org
Subject: Re: [netmod] AD review of draft-ietf-netmod-interfaces-cfg-09
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Apr 2013 07:42:30 -0000

----Next_Part(Wed_Apr_17_09_42_28_2013_002)--
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi Benoit,

Attached is the changes I propose as a result of your comments.  Do
you beleive that your comments are properly addressed by these
changes?


/martin

----Next_Part(Wed_Apr_17_09_42_28_2013_002)--
Content-Type: Text/Html; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline; filename="interfaces-09-10-diff.html"

Index: .
===================================================================
--- .	(revision 55158)
+++ .	(working copy)

Property changes on: .
___________________________________________________________________
Modified: svn:mergeinfo
   Merged /trunk:r55053,55061,55100
Index: lib
===================================================================
--- lib	(revision 55158)
+++ lib	(working copy)

Property changes on: lib
___________________________________________________________________
Modified: svn:mergeinfo
   Merged /trunk/lib:r55053,55061,55100
Index: lib/cli/src/cli_cisco_show.erl
===================================================================
--- lib/cli/src/cli_cisco_show.erl	(revision 55158)
+++ lib/cli/src/cli_cisco_show.erl	(working copy)
@@ -38,6 +38,8 @@
 -define(hide_in_submode(Cs), ?bit_is_set((Cs)#cs.cli_flags,
                                             ?F_CLI_HIDE_IN_SUBMODE)).
 
+-record('DOWN', {ref, type, object, info}).
+
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 %%%
 %%% Load configuration into transaction handler.
@@ -513,7 +515,9 @@
                             end,
                             Compact = use_compact_t(CiscoS, IKeypath, CsFlags),
                             if Compact, Written,
-                               ?deprecated_is_leaf(Cs) ->
+                               ?deprecated_is_leaf(Cs) orelse
+                               ?is_container(Cs) andalso
+                               ?is_flattened(Cs) ->
                                     ?put_meta([sync]),
                                     ?put_chars(undefined, [$\n, sync]);
                                true ->
@@ -3704,14 +3708,22 @@
     Visible = cs_trans:get_unhidden(Th1),
     DiffStyle = false,
     Self = self(),
-    Pid = spawn_link(fun() -> get_diff_collect(Self, []) end),
-    OutFun = fun(Chars) -> Pid ! {out, Chars} end,
-    diff_configuration3(CliS, OutFun, Th1, Th2, NsList, IKeypath, Verbosity,
-                        _Astate=undefined, Visible, DiffStyle, Chroot,
-                        NoIndent),
-    Pid ! done,
+    DiffPid =
+        spawn_link(
+          fun() ->
+                  Pid = spawn_link(fun() -> get_diff_collect(Self, []) end),
+                  OutFun = fun(Chars) -> Pid ! {out, Chars} end,
+                  diff_configuration3(CliS, OutFun, Th1, Th2, NsList, IKeypath,
+                                      Verbosity, _Astate=undefined, Visible,
+                                      DiffStyle, Chroot, NoIndent),
+                  Pid ! done
+          end),
+    MonRef = erlang:monitor(process, DiffPid),
     receive
+        #'DOWN'{ref=MonRef, info=Info} when Info =/= normal ->
+            {error, crashec};
         {accumulated, Chars} ->
+            erlang:demonitor(MonRef, [flush]),
             {ok, Chars}
     end.
 
@@ -3723,14 +3735,24 @@
     Visible = cs_trans:get_unhidden(Th1),
     DiffStyle = false,
     Self = self(),
-    Pid = spawn_link(fun() -> get_diff_collect(Self, []) end),
-    OutFun = fun(Chars) -> Pid ! {out, Chars} end,
-    diff_configuration1(CliS, OutFun, Th1, Th2, NsList, IKeypath, Verbosity,
-                        _Astate=undefined, Visible, DiffStyle, Chroot,
-                        NoIndent),
-    Pid ! done,
+    %% We nned to do this since our caller may be trapping exits
+    DiffPid =
+        spawn_link(
+          fun() ->
+                  Pid = spawn_link(fun() -> get_diff_collect(Self, []) end),
+                  OutFun = fun(Chars) -> Pid ! {out, Chars} end,
+                  diff_configuration1(CliS, OutFun, Th1, Th2, NsList, IKeypath,
+                                      Verbosity, _Astate=undefined, Visible,
+                                      DiffStyle, Chroot, NoIndent),
+                  Pid ! done
+          end),
+    MonRef = erlang:monitor(process, DiffPid),
     receive
+        #'DOWN'{ref=MonRef, info=Info} when Info =/= normal ->
+            {error, crashec};
         {accumulated, Chars} ->
+            erlang:demonitor(MonRef, [flush]),
+            %% ?liof("Chars=~p\n", [Chars]),
             {ok, Chars}
     end.
 
Index: lib/java_conf_api
===================================================================
--- lib/java_conf_api	(revision 55158)
+++ lib/java_conf_api	(working copy)

Property changes on: lib/java_conf_api
___________________________________________________________________
Modified: svn:mergeinfo
   Merged /trunk/lib/java_conf_api:r55053,55061

----Next_Part(Wed_Apr_17_09_42_28_2013_002)----

From mbj@tail-f.com  Wed Apr 17 00:52:34 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EA7921F84B7 for ; Wed, 17 Apr 2013 00:52:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.292
X-Spam-Level: 
X-Spam-Status: No, score=-1.292 tagged_above=-999 required=5 tests=[AWL=0.753,  BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MSKhkFGtgDVF for ; Wed, 17 Apr 2013 00:52:32 -0700 (PDT)
Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 2126721F8494 for ; Wed, 17 Apr 2013 00:52:32 -0700 (PDT)
Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 1E4FE1200AD8; Wed, 17 Apr 2013 09:52:31 +0200 (CEST)
Date: Wed, 17 Apr 2013 09:52:30 +0200 (CEST)
Message-Id: <20130417.095230.704520406717621094.mbj@tail-f.com>
To: bclaise@cisco.com
From: Martin Bjorklund 
In-Reply-To: <20130417.094228.1068134205727356492.mbj@tail-f.com>
References: <5162F4D6.6020009@cisco.com> <20130408.233810.311649160.mbj@tail-f.com> <20130417.094228.1068134205727356492.mbj@tail-f.com>
X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Multipart/Mixed; boundary="--Next_Part(Wed_Apr_17_09_52_30_2013_514)--"
Content-Transfer-Encoding: 7bit
Cc: netmod@ietf.org
Subject: Re: [netmod] AD review of draft-ietf-netmod-interfaces-cfg-09
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Apr 2013 07:52:34 -0000

----Next_Part(Wed_Apr_17_09_52_30_2013_514)--
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Second try with proper diff!


Attached is the changes I propose as a result of your comments.  Do
you beleive that your comments are properly addressed by these
changes?


/martin

----Next_Part(Wed_Apr_17_09_52_30_2013_514)--
Content-Type: Text/Html; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline; filename="interfaces-09-10-diff.html"








 
   
   
  Diff: draft-ietf-netmod-interfaces-cfg-09.txt - draft-ietf-netmod-interfaces-cfg-10.txt 
   
 
 
  
 
  
< draft-ietf-netmod-interfaces-cfg-09.txt   draft-ietf-netmod-interfaces-cfg-10.txt >
 
      
 

      
Network Working Group                                       M. Bjorklund Network Working Group                                       M. Bjorklund

      
Internet-Draft                                            Tail-f Systems Internet-Draft                                            Tail-f Systems

      

      
Intended status: Standards Track                        February 6, 2013 Intended status: Standards Track                          April 17, 2013

      
Expires: August 10, 2013 Expires: October 19, 2013

      
 

      
               A YANG Data Model for Interface Management                A YANG Data Model for Interface Management

      

      
                  draft-ietf-netmod-interfaces-cfg-09                   draft-ietf-netmod-interfaces-cfg-10

      
 

      
Abstract Abstract

      
 

      
   This document defines a YANG data model for the management of network    This document defines a YANG data model for the management of network

      
   interfaces.  It is expected that interface type specific data models    interfaces.  It is expected that interface type specific data models

      
   augment the generic interfaces data model defined in this document.    augment the generic interfaces data model defined in this document.

      
 

      
Status of this Memo Status of this Memo

      
 

      
   This Internet-Draft is submitted in full conformance with the    This Internet-Draft is submitted in full conformance with the

      
 

      
skipping to change at page 1, line 32 skipping to change at page 1, line 32

      
   Internet-Drafts are working documents of the Internet Engineering    Internet-Drafts are working documents of the Internet Engineering

      
   Task Force (IETF).  Note that other groups may also distribute    Task Force (IETF).  Note that other groups may also distribute

      
   working documents as Internet-Drafts.  The list of current Internet-    working documents as Internet-Drafts.  The list of current Internet-

      
   Drafts is at http://datatracker.ietf.org/drafts/current/.    Drafts is at http://datatracker.ietf.org/drafts/current/.

      
 

      
   Internet-Drafts are draft documents valid for a maximum of six months    Internet-Drafts are draft documents valid for a maximum of six months

      
   and may be updated, replaced, or obsoleted by other documents at any    and may be updated, replaced, or obsoleted by other documents at any

      
   time.  It is inappropriate to use Internet-Drafts as reference    time.  It is inappropriate to use Internet-Drafts as reference

      
   material or to cite them other than as "work in progress."    material or to cite them other than as "work in progress."

      
 

      

      
   This Internet-Draft will expire on August 10, 2013.    This Internet-Draft will expire on October 19, 2013.

      
 

      
Copyright Notice Copyright Notice

      
 

      
   Copyright (c) 2013 IETF Trust and the persons identified as the    Copyright (c) 2013 IETF Trust and the persons identified as the

      
   document authors.  All rights reserved.    document authors.  All rights reserved.

      
 

      
   This document is subject to BCP 78 and the IETF Trust's Legal    This document is subject to BCP 78 and the IETF Trust's Legal

      
   Provisions Relating to IETF Documents    Provisions Relating to IETF Documents

      
   (http://trustee.ietf.org/license-info) in effect on the date of    (http://trustee.ietf.org/license-info) in effect on the date of

      
   publication of this document.  Please review these documents    publication of this document.  Please review these documents

      
 

      
skipping to change at page 2, line 32 skipping to change at page 2, line 32

      
   Appendix A.  Example: Ethernet Interface Module  . . . . . . . . . 27    Appendix A.  Example: Ethernet Interface Module  . . . . . . . . . 27

      
   Appendix B.  Example: Ethernet Bonding Interface Module  . . . . . 29    Appendix B.  Example: Ethernet Bonding Interface Module  . . . . . 29

      
   Appendix C.  Example: VLAN Interface Module  . . . . . . . . . . . 30    Appendix C.  Example: VLAN Interface Module  . . . . . . . . . . . 30

      
   Appendix D.  Example: NETCONF <get> reply  . . . . . . . . . . . . 31    Appendix D.  Example: NETCONF <get> reply  . . . . . . . . . . . . 31

      
   Appendix E.  Examples: Interface Naming Schemes  . . . . . . . . . 32    Appendix E.  Examples: Interface Naming Schemes  . . . . . . . . . 32

      
     E.1.  Router with Restricted Interface Names . . . . . . . . . . 32      E.1.  Router with Restricted Interface Names . . . . . . . . . . 32

      
     E.2.  Router with Arbitrary Interface Names  . . . . . . . . . . 33      E.2.  Router with Arbitrary Interface Names  . . . . . . . . . . 33

      
     E.3.  Ethernet Switch with Restricted Interface Names  . . . . . 33      E.3.  Ethernet Switch with Restricted Interface Names  . . . . . 33

      
     E.4.  Generic Host with Restricted Interface Names . . . . . . . 34      E.4.  Generic Host with Restricted Interface Names . . . . . . . 34

      
     E.5.  Generic Host with Arbitrary Interface Names  . . . . . . . 35      E.5.  Generic Host with Arbitrary Interface Names  . . . . . . . 35

      

      
   Appendix F.  ChangeLog . . . . . . . . . . . . . . . . . . . . . . 36    Appendix F.  ChangeLog . . . . . . . . . . . . . . . . . . . . . . 37

      
     F.1.  Version -08  . . . . . . . . . . . . . . . . . . . . . . . 36      F.1.  Version -08  . . . . . . . . . . . . . . . . . . . . . . . 37

      
     F.2.  Version -07  . . . . . . . . . . . . . . . . . . . . . . . 36      F.2.  Version -07  . . . . . . . . . . . . . . . . . . . . . . . 37

      
     F.3.  Version -06  . . . . . . . . . . . . . . . . . . . . . . . 36      F.3.  Version -06  . . . . . . . . . . . . . . . . . . . . . . . 37

      
     F.4.  Version -05  . . . . . . . . . . . . . . . . . . . . . . . 36      F.4.  Version -05  . . . . . . . . . . . . . . . . . . . . . . . 37

      
     F.5.  Version -04  . . . . . . . . . . . . . . . . . . . . . . . 36      F.5.  Version -04  . . . . . . . . . . . . . . . . . . . . . . . 37

      
     F.6.  Version -03  . . . . . . . . . . . . . . . . . . . . . . . 36      F.6.  Version -03  . . . . . . . . . . . . . . . . . . . . . . . 37

      
     F.7.  Version -02  . . . . . . . . . . . . . . . . . . . . . . . 37      F.7.  Version -02  . . . . . . . . . . . . . . . . . . . . . . . 38

      
     F.8.  Version -01  . . . . . . . . . . . . . . . . . . . . . . . 37      F.8.  Version -01  . . . . . . . . . . . . . . . . . . . . . . . 38

      
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 38    Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 39

      
 

      
1.  Introduction 1.  Introduction

      
 

      
   This document defines a YANG [RFC6020] data model for the management    This document defines a YANG [RFC6020] data model for the management

      
   of network interfaces.  It is expected that interface type specific    of network interfaces.  It is expected that interface type specific

      
   data models augment the generic interfaces data model defined in this    data models augment the generic interfaces data model defined in this

      
   document.    document.

      
 

      
   Network interfaces are central to the management of many Internet    Network interfaces are central to the management of many Internet

      
   protocols.  Thus, it is important to establish a common data model    protocols.  Thus, it is important to establish a common data model

      
 

      
skipping to change at page 4, line 12 skipping to change at page 4, line 12

      
 

      
   o  data node    o  data node

      
 

      
2.  Objectives 2.  Objectives

      
 

      
   This section describes some of the design objectives for the model    This section describes some of the design objectives for the model

      
   presented in Section 5.    presented in Section 5.

      
 

      
   o  It is recognized that existing implementations will have to map    o  It is recognized that existing implementations will have to map

      
      the interface data model defined in this memo to their proprietary       the interface data model defined in this memo to their proprietary

      

      
      native data model.  The new data model should be simple to       native data model.  The data model should be simple to facilitate

      
      facilitate such mappings.       such mappings.

      
 

      
   o  The data model should be suitable for new implementations to use    o  The data model should be suitable for new implementations to use

      
      as-is, without requiring a mapping to a different native model.       as-is, without requiring a mapping to a different native model.

      
 

      
   o  References to interfaces should be as simple as possible,    o  References to interfaces should be as simple as possible,

      
      preferably by using a single leafref.       preferably by using a single leafref.

      
 

      
   o  The mapping to ifIndex [RFC2863] used by SNMP to identify    o  The mapping to ifIndex [RFC2863] used by SNMP to identify

      
      interfaces must be clear.       interfaces must be clear.

      
 

      
 

      
skipping to change at page 5, line 46 skipping to change at page 5, line 46

      
               +--ro out-unicast-pkts?     yang:counter64                +--ro out-unicast-pkts?     yang:counter64

      
               +--ro out-broadcast-pkts?   yang:counter64                +--ro out-broadcast-pkts?   yang:counter64

      
               +--ro out-multicast-pkts?   yang:counter64                +--ro out-multicast-pkts?   yang:counter64

      
               +--ro out-discards?         yang:counter32                +--ro out-discards?         yang:counter32

      
               +--ro out-errors?           yang:counter32                +--ro out-errors?           yang:counter32

      
 

      
3.1.  The interface List 3.1.  The interface List

      
 

      
   The data model for interfaces presented in this document uses a flat    The data model for interfaces presented in this document uses a flat

      
   list of interfaces.  Each interface in the list is identified by its    list of interfaces.  Each interface in the list is identified by its

      

      
   name.  Furthermore, each interface has a mandatory "type" leaf, and a    name.  Furthermore, each interface has a mandatory "type" leaf, and

      
   "location" leaf.  The combination of "type" and "location" is unique    an optional "location" leaf.  The combination of "type" and

      
   within the interface list.    "location" is unique within the interface list.

      
 

      
   It is expected that interface type specific data models augment the    It is expected that interface type specific data models augment the

      
   interface list, and use the "type" leaf to make the augmentation    interface list, and use the "type" leaf to make the augmentation

      
   conditional.    conditional.

      
 

      
   As an example of such an interface type specific augmentation,    As an example of such an interface type specific augmentation,

      
   consider this YANG snippet.  For a more complete example, see    consider this YANG snippet.  For a more complete example, see

      
   Appendix A.    Appendix A.

      
 

      
     import interfaces {      import interfaces {

      
 

      
skipping to change at page 8, line 9 skipping to change at page 8, line 9

      
         // other bonding config params, failover times etc.          // other bonding config params, failover times etc.

      
     }      }

      
 

      
   Two state data leaf-lists, "higher-layer-if" and "lower-layer-if",    Two state data leaf-lists, "higher-layer-if" and "lower-layer-if",

      
   represent a read-only view of the interface layering hierarchy.    represent a read-only view of the interface layering hierarchy.

      
 

      
4.  Relationship to the IF-MIB 4.  Relationship to the IF-MIB

      
 

      
   If the device implements IF-MIB [RFC2863], each entry in the    If the device implements IF-MIB [RFC2863], each entry in the

      
   "interface" list is typically mapped to one ifEntry.  The "if-index"    "interface" list is typically mapped to one ifEntry.  The "if-index"

      

      
   leaf contains the value of the corresponding ifEntry's ifIndex.    leaf MUST contain the value of the corresponding ifEntry's ifIndex.

      
 

      
   In most cases, the "name" of an "interface" entry is mapped to    In most cases, the "name" of an "interface" entry is mapped to

      
   ifName. ifName is defined as an DisplayString [RFC2579] which uses a    ifName. ifName is defined as an DisplayString [RFC2579] which uses a

      
   7-bit ASCII character set.  An implementation MAY restrict the    7-bit ASCII character set.  An implementation MAY restrict the

      
   allowed values for "name" to match the restrictions of ifName.    allowed values for "name" to match the restrictions of ifName.

      
 

      
   The IF-MIB allows two different ifEntries to have the same ifName.    The IF-MIB allows two different ifEntries to have the same ifName.

      
   Devices that support this feature, and also support the configuration    Devices that support this feature, and also support the configuration

      
   of these interfaces using the "interface" list, cannot have a 1-1    of these interfaces using the "interface" list, cannot have a 1-1

      
   mapping between the "name" leaf and ifName.    mapping between the "name" leaf and ifName.

      
 

      
skipping to change at page 32, line 22 skipping to change at page 32, line 22

      
   ports.  The slots for the cards are physically numbered from 0 to 3,    ports.  The slots for the cards are physically numbered from 0 to 3,

      
   and the ports on each card from 0 to 7.  Each card has fast- or    and the ports on each card from 0 to 7.  Each card has fast- or

      
   gigabit-ethernet ports.    gigabit-ethernet ports.

      
 

      
   The implementation restricts the names of the interfaces to one of    The implementation restricts the names of the interfaces to one of

      
   "fastethernet-N/M" or "gigabitethernet-N/M".  The "location" of an    "fastethernet-N/M" or "gigabitethernet-N/M".  The "location" of an

      
   interface is a string on the form "N/M".  The implementation auto-    interface is a string on the form "N/M".  The implementation auto-

      
   initializes the values for "type" and "location" based on the    initializes the values for "type" and "location" based on the

      
   interface name.    interface name.

      
 

      

      
    The NETCONF server does not advertise the 'arbitrary-names' feature

      
    in the <hello> message.

      
                                                                          

      
   An operator can configure a new interface by sending an <edit-config>    An operator can configure a new interface by sending an <edit-config>

      
   containing:    containing:

      
 

      
     <interface nc:operation="create">      <interface nc:operation="create">

      
       <name>fastethernet-1/0</name>        <name>fastethernet-1/0</name>

      
     </interface>      </interface>

      
 

      
   When the server processes this request, it will set the leaf "type"    When the server processes this request, it will set the leaf "type"

      
   to "ethernetCsmacd" and "location" to "1/0".  Thus, if the client    to "ethernetCsmacd" and "location" to "1/0".  Thus, if the client

      
   performs a <get-config> right after the <edit-config> above, it will    performs a <get-config> right after the <edit-config> above, it will

      
 

      
skipping to change at page 33, line 19 skipping to change at page 33, line 19

      
   and the ports on each card from 0 to 7.  Each card has fast- or    and the ports on each card from 0 to 7.  Each card has fast- or

      
   gigabit-ethernet ports.    gigabit-ethernet ports.

      
 

      
   The implementation does not restrict the interface names.  This    The implementation does not restrict the interface names.  This

      
   allows to more easily apply the interface configuration to a    allows to more easily apply the interface configuration to a

      
   different physical interface.  However, the additional level of    different physical interface.  However, the additional level of

      
   indirection also makes it a bit more complex to map interface names    indirection also makes it a bit more complex to map interface names

      
   found in other protocols to configuration entries.  The "location" of    found in other protocols to configuration entries.  The "location" of

      
   an interface is a string on the form "N/M".    an interface is a string on the form "N/M".

      
 

      

      
    The NETCONF server advertises the 'arbitrary-names' feature in the

      
    <hello> message.

      
                                                                          

      
   An operator can configure a new interface by sending an <edit-config>    An operator can configure a new interface by sending an <edit-config>

      
   containing:    containing:

      
 

      
     <interface nc:operation="create">      <interface nc:operation="create">

      
       <name>acme-interface</name>        <name>acme-interface</name>

      
       <type>ethernetCsmacd</type>        <type>ethernetCsmacd</type>

      
       <location>1/0</location>        <location>1/0</location>

      
     </interface>      </interface>

      
 

      
   If necessary, the operator can move the configuration named    If necessary, the operator can move the configuration named

      
 

      
skipping to change at page 33, line 45 skipping to change at page 33, line 48

      
     </interface>      </interface>

      
 

      
E.3.  Ethernet Switch with Restricted Interface Names E.3.  Ethernet Switch with Restricted Interface Names

      
 

      
   In this example, an ethernet switch has a number of ports, each port    In this example, an ethernet switch has a number of ports, each port

      
   identified by a simple port number.    identified by a simple port number.

      
 

      
   The implementation restricts the interface names to numbers that    The implementation restricts the interface names to numbers that

      
   match the physical port number.    match the physical port number.

      
 

      

      
    The NETCONF server does not advertise the 'arbitrary-names' feature

      
    in the <hello> message.

      
                                                                          

      
   An operator can configure a new interface by sending an <edit-config>    An operator can configure a new interface by sending an <edit-config>

      
   containing:    containing:

      
 

      
     <interface nc:operation="create">      <interface nc:operation="create">

      
       <name>6</name>        <name>6</name>

      
     </interface>      </interface>

      
 

      
   When the server processes this request, it will set the leaf "type"    When the server processes this request, it will set the leaf "type"

      
   to "ethernetCsmacd" and "location" to "6".  Thus, if the client    to "ethernetCsmacd" and "location" to "6".  Thus, if the client

      
   performs a <get-config> right after the <edit-config> above, it will    performs a <get-config> right after the <edit-config> above, it will

      
 

      
skipping to change at page 34, line 35 skipping to change at page 34, line 41

      
E.4.  Generic Host with Restricted Interface Names E.4.  Generic Host with Restricted Interface Names

      
 

      
   In this example, a generic host has interfaces named by the kernel    In this example, a generic host has interfaces named by the kernel

      
   and without easily usable location information.  The system    and without easily usable location information.  The system

      
   identifies the physical interface by the name assigned by the    identifies the physical interface by the name assigned by the

      
   operating system to the interface.    operating system to the interface.

      
 

      
   The implementation restricts the interface name to the operating    The implementation restricts the interface name to the operating

      
   system level name of the physical interface.    system level name of the physical interface.

      
 

      

      
    The NETCONF server does not advertise the 'arbitrary-names' feature

      
    in the <hello> message.

      
                                                                          

      
   An operator can configure a new interface by sending an <edit-config>    An operator can configure a new interface by sending an <edit-config>

      
   containing:    containing:

      
 

      
     <interface nc:operation="create">      <interface nc:operation="create">

      
       <name>eth8</name>        <name>eth8</name>

      
     </interface>      </interface>

      
 

      
   When the server processes this request, it will set the leaf "type"    When the server processes this request, it will set the leaf "type"

      
   to "ethernetCsmacd" and "location" to "eth8".  Thus, if the client    to "ethernetCsmacd" and "location" to "eth8".  Thus, if the client

      
   performs a <get-config> right after the <edit-config> above, it will    performs a <get-config> right after the <edit-config> above, it will

      
 

      
skipping to change at page 35, line 30 skipping to change at page 35, line 38

      
   identifies the physical interface by the name assigned by the    identifies the physical interface by the name assigned by the

      
   operating system to the interface.    operating system to the interface.

      
 

      
   The implementation does not restrict the interface name to the    The implementation does not restrict the interface name to the

      
   operating system level name of the physical interface.  This allows    operating system level name of the physical interface.  This allows

      
   to more easily apply the interface configuration to a different    to more easily apply the interface configuration to a different

      
   physical interface.  However, the additional level of indirection    physical interface.  However, the additional level of indirection

      
   also makes it a bit more complex to map interface names found in    also makes it a bit more complex to map interface names found in

      
   other protocols to configuration entries.    other protocols to configuration entries.

      
 

      

      
    The NETCONF server advertises the 'arbitrary-names' feature in the

      
    <hello> message.

      
                                                                          

      
   An operator can configure a new interface by sending an <edit-config>    An operator can configure a new interface by sending an <edit-config>

      
   containing:    containing:

      
 

      
     <interface nc:operation="create">      <interface nc:operation="create">

      
       <name>acme-interface</name>        <name>acme-interface</name>

      
       <type>ethernetCsmacd</type>        <type>ethernetCsmacd</type>

      
       <location>eth4</location>        <location>eth4</location>

      
     </interface>      </interface>

      
 

      
   If necessary, the operator can move the configuration named    If necessary, the operator can move the configuration named


     
 

     
 End of changes. 12 change blocks. 

     
20 lines changed or deleted 35 lines changed or added

     

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ 

   

   
   

----Next_Part(Wed_Apr_17_09_52_30_2013_514)----

From lhotka@nic.cz  Wed Apr 17 01:44:06 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDEAD21F8AE7 for ; Wed, 17 Apr 2013 01:44:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.714
X-Spam-Level: 
X-Spam-Status: No, score=-0.714 tagged_above=-999 required=5 tests=[AWL=1.285,  BAYES_00=-2.599, J_CHICKENPOX_23=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5OAwnn4HMZn6 for ; Wed, 17 Apr 2013 01:44:02 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 09FF821F859C for ; Wed, 17 Apr 2013 01:44:02 -0700 (PDT)
Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 1EF18140074; Wed, 17 Apr 2013 10:44:01 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1366188241; bh=5vu8wcs+iOl9W8+tt5akiLeBrHiEMZPDl97D6DwY2qw=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=Y0zV7k5MUdARh0IhCyXskW3KABqR8dpwFh6N5akHh+4JPn2HUWDVMe4fWKMU+SrxW wZmuIlvIQOpm8QScqYUKuJPToNgo4WmxqD5xumogk+AhIuQojuraZMUc840SLEZ+BC /yHC35oIAHLwjy56whzfA9Fg9/LMAQ4brP2Z+Zd0=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
From: Ladislav Lhotka 
In-Reply-To: <20130417.093455.1132768532036936745.mbj@tail-f.com>
Date: Wed, 17 Apr 2013 10:44:03 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <3E36E8F6-D532-453B-8AD2-337DBEDEC9C8@nic.cz>
References: <20130409.154216.2204981475552383627.mbj@tail-f.com> <20130409144631.GA192@elstar.local> <203FE3B9-575C-436C-A2BF-DA6719B33464@nic.cz> <20130417.093455.1132768532036936745.mbj@tail-f.com>
To: Martin Bjorklund 
X-Mailer: Apple Mail (2.1503)
X-Virus-Scanned: clamav-milter 0.97.7 at mail
X-Virus-Status: Clean
Cc: netmod@ietf.org
Subject: Re: [netmod] [IANA #668518] Fwd: Re: AD review of draft-ietf-netmod-iana-if-type-04
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Apr 2013 08:44:07 -0000

On Apr 17, 2013, at 9:34 AM, Martin Bjorklund  wrote:

> Hi,
>=20
> I am not sure if anything has been decided for this issue, but if we
> go with the solution that values that are "reserved" in the registry
> are NOT reflected in the YANG module, I suggest we add this sentence =
to
> the second paragraph in the IANA Considerations section:
>=20
>=20
>  If an interface type is marked as "reserved" in the "ifType
>  definitions" registry, no "enum" statement is added to the
>  "iana-if-type" typedef.

Yes, but for all three registries and enumerations, i.e. also for =
address family and SAFI.

Lada


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

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





From bclaise@cisco.com  Wed Apr 17 07:00:48 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7474621F8648 for ; Wed, 17 Apr 2013 07:00:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.465
X-Spam-Level: 
X-Spam-Status: No, score=-10.465 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eDvjPZ2+cMpt for ; Wed, 17 Apr 2013 07:00:48 -0700 (PDT)
Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 9391C21F8652 for ; Wed, 17 Apr 2013 07:00:47 -0700 (PDT)
X-TACSUNS: Virus Scanned
Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r3HE0inE028882 for ; Wed, 17 Apr 2013 16:00:44 +0200 (CEST)
Received: from [10.60.67.88] (ams-bclaise-8917.cisco.com [10.60.67.88]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r3HE0StW013814 for ; Wed, 17 Apr 2013 16:00:39 +0200 (CEST)
Message-ID: <516EAAFC.1050503@cisco.com>
Date: Wed, 17 Apr 2013 16:00:28 +0200
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4
MIME-Version: 1.0
To: NETMOD Working Group 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [netmod] AD review of draft-ietf-netmod-ip-cfg-09
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Apr 2013 14:00:48 -0000

Dear all,

Major issue: none
Minor issue: none

I thought I would let you know the good news.

Regards, Benoit

From bclaise@cisco.com  Wed Apr 17 07:26:18 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 222E021F8BA6 for ; Wed, 17 Apr 2013 07:26:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.175
X-Spam-Level: 
X-Spam-Status: No, score=-10.175 tagged_above=-999 required=5 tests=[AWL=-0.177, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TCzYWET1Ns-6 for ; Wed, 17 Apr 2013 07:26:17 -0700 (PDT)
Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 38C5E21F8BF8 for ; Wed, 17 Apr 2013 07:26:17 -0700 (PDT)
X-TACSUNS: Virus Scanned
Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r3HEQD6e001707; Wed, 17 Apr 2013 16:26:13 +0200 (CEST)
Received: from [10.60.67.88] (ams-bclaise-8917.cisco.com [10.60.67.88]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r3HEPghk014486; Wed, 17 Apr 2013 16:25:52 +0200 (CEST)
Message-ID: <516EB0E6.7030007@cisco.com>
Date: Wed, 17 Apr 2013 16:25:42 +0200
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4
MIME-Version: 1.0
To: Ladislav Lhotka 
References: <20130409.154216.2204981475552383627.mbj@tail-f.com> <20130409144631.GA192@elstar.local> <203FE3B9-575C-436C-A2BF-DA6719B33464@nic.cz> <20130417.093455.1132768532036936745.mbj@tail-f.com> <3E36E8F6-D532-453B-8AD2-337DBEDEC9C8@nic.cz>
In-Reply-To: <3E36E8F6-D532-453B-8AD2-337DBEDEC9C8@nic.cz>
Content-Type: multipart/alternative; boundary="------------020303010608020104060902"
Cc: netmod@ietf.org
Subject: Re: [netmod] [IANA #668518] Fwd: Re: AD review of draft-ietf-netmod-iana-if-type-04
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Apr 2013 14:26:18 -0000

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

On 17/04/2013 10:44, Ladislav Lhotka wrote:
> On Apr 17, 2013, at 9:34 AM, Martin Bjorklund  wrote:
>
>> Hi,
>>
>> I am not sure if anything has been decided for this issue, but if we
>> go with the solution that values that are "reserved" in the registry
>> are NOT reflected in the YANG module, I suggest we add this sentence to
>> the second paragraph in the IANA Considerations section:
>>
>>
>>   If an interface type is marked as "reserved" in the "ifType
>>   definitions" registry, no "enum" statement is added to the
>>   "iana-if-type" typedef.
> Yes, but for all three registries and enumerations, i.e. also for address family and SAFI.
That works for me.
As I wrote in a previous email:

    Bottom line: the IANA considerations must explain what to do with
    the "Reserved" values, for both interface type and SAFI. And if
    there are two different of "Reserved" meaning, the IANA
    considerations section must explain the different treatments, if
    different.

Martin,
I propose that you get a new version of the draft with those changes.
 From there, we could check it with the MIB doctors & yang doctors

Regards, Benoit
>
> Lada
>
>
>>
>> /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
>
>


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


  
    
  
  
    
On 17/04/2013 10:44, Ladislav Lhotka
      wrote:

    

    

      
On Apr 17, 2013, at 9:34 AM, Martin Bjorklund <mbj@tail-f.com> wrote:



      

        
Hi,

I am not sure if anything has been decided for this issue, but if we
go with the solution that values that are "reserved" in the registry
are NOT reflected in the YANG module, I suggest we add this sentence to
the second paragraph in the IANA Considerations section:


 If an interface type is marked as "reserved" in the "ifType
 definitions" registry, no "enum" statement is added to the
 "iana-if-type" typedef.


      

      
Yes, but for all three registries and enumerations, i.e. also for address family and SAFI.

    

    That works for me.

    As I wrote in a previous email: 

    
Bottom line: the IANA considerations must explain what
      to do with the "Reserved" values, for both interface type and
      SAFI. And if there are two different of "Reserved" meaning, the
      IANA considerations section must explain the different treatments,
      if different.

    

    Martin, 

    I propose that you get a new version of the draft with those
    changes.

    From there, we could check it with the MIB doctors & yang
    doctors

    

    Regards, Benoit

    

      

Lada




      

        

/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




    

    

  


--------------020303010608020104060902--

From internet-drafts@ietf.org  Wed Apr 17 07:47:25 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E063321E803D; Wed, 17 Apr 2013 07:47:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.51
X-Spam-Level: 
X-Spam-Status: No, score=-102.51 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AcD9TYDLKNiX; Wed, 17 Apr 2013 07:47:25 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F25521F8550; Wed, 17 Apr 2013 07:47:25 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.43.p4
Message-ID: <20130417144725.3209.14627.idtracker@ietfa.amsl.com>
Date: Wed, 17 Apr 2013 07:47:25 -0700
Cc: netmod@ietf.org
Subject: [netmod] I-D Action: draft-ietf-netmod-iana-if-type-05.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Apr 2013 14:47:26 -0000

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.
 This draft is a work item of the NETCONF Data Modeling Language Working Gr=
oup of the IETF.

	Title           : IANA Interface Type and Address Family YANG Modules
	Author(s)       : Martin Bjorklund
	Filename        : draft-ietf-netmod-iana-if-type-05.txt
	Pages           : 49
	Date            : 2013-04-17

Abstract:
   This document defines the initial versions of the iana-if-type and
   iana-afn-safi YANG modules.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-netmod-iana-if-type

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-netmod-iana-if-type-05

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netmod-iana-if-type-05


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


From bclaise@cisco.com  Wed Apr 17 07:53:10 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7317E21F892D for ; Wed, 17 Apr 2013 07:53:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.463
X-Spam-Level: 
X-Spam-Status: No, score=-10.463 tagged_above=-999 required=5 tests=[AWL=0.136, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9hiVdrkwFyJR for ; Wed, 17 Apr 2013 07:53:05 -0700 (PDT)
Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 0E4C921F86F7 for ; Wed, 17 Apr 2013 07:52:57 -0700 (PDT)
X-TACSUNS: Virus Scanned
Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r3HEqtxN004487; Wed, 17 Apr 2013 16:52:56 +0200 (CEST)
Received: from [10.60.67.88] (ams-bclaise-8917.cisco.com [10.60.67.88]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r3HEqU0C018878; Wed, 17 Apr 2013 16:52:45 +0200 (CEST)
Message-ID: <516EB72E.5070604@cisco.com>
Date: Wed, 17 Apr 2013 16:52:30 +0200
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4
MIME-Version: 1.0
To: Martin Bjorklund 
References: <5150CF8E.8090006@cisco.com> <20130402.230149.92811084.mbj@tail-f.com> <5162F4D6.6020009@cisco.com> <20130408.233810.311649160.mbj@tail-f.com>
In-Reply-To: <20130408.233810.311649160.mbj@tail-f.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: netmod@ietf.org
Subject: Re: [netmod] AD review of draft-ietf-netmod-interfaces-cfg-09
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Apr 2013 14:53:10 -0000

Hi Martin,

In the new draft version you sent (actually the diff), there is just one 
issue that is not addressed.
> Benoit Claise  wrote:
>> Hi Martin,
>>
>>> Hi,
>>>
>>> Benoit Claise  wrote:
>>>> Dear all,
>>>>
>>>> Disclaimer:
>>>> - If any of those points have been discussed on the mailing list, don't
>>>> - hesitate to let me know.
>>>> - I probably should have mentioned some of these documents during the last
>>>> - call. Sorry. After a year in the new position, I'm still playing catch up
>>>> - mode.
>>>>
>>>> _CLARIFYING QUE__STION__S_
>>>>
>>>> - Section 3.1 The interface List
>>>>
>>>>      The data model for interfaces presented in this document uses a flat
>>>>      list of interfaces.  Each interface in the list is identified by its
>>>>      name.  Furthermore, each interface has a mandatory "type" leaf, and a
>>>>      "location" leaf.  The combination of "type" and "location" is unique
>>>>      within the interface list.
>>>>
>>>> First time I read this, I thought the location was mandatory.
>>>> However, it's not:
>>>>
>>>>         +--rw interfaces
>>>>            +--rw interface [name]
>>>>               +--rw name                        string
>>>>               +--rw description?                string
>>>>               +--rw type                        ianaift:iana-if-type
>>>>               +--rw location?                   string
>>>>
>>>> Proposal:
>>>> OLD:
>>>> 	
>>>>      Furthermore, each interface has a mandatory "type" leaf, and a
>>>>      "location" leaf.
>>>>
>>>> NEW:
>>>>      Furthermore, each interface has a mandatory "type" leaf, and an optional
>>>>      "location" leaf.
>>> Ok, will fix.
>>>
>>>> When I understood that the location is optional, I have some difficulties to
>>>> understand the following sentence
>>>> "The combination of "type" and "location" is unique within the interface
>>>> list."
>>>> when the location is an optional field.
>>>>
>>>> - How does the mechanism above apply to subinterfaces? example: Interface
>>>>     Ethernet 0.1?
>>>>
>>>> I believe it deserves some explanation. Now, it's true that the RFC 2863
>>>> doesn't mention the notion of subinterface, and I believe that the notion of
>>>> sub-layer (in RFC 2863) and interface layering (in
>>>> draft-ietf-netmod-interfaces-cfg) notions don't apply to subinterfaces? I
>>>> would
>>>> be happy to stand corrected.
>>> It all depends what you put in your definition of a subinterface.
>>> This document does not mention subinterfaces at all.  It just talks
>>> about how interfaces are layered.
>> Having at least one example on how this module is supposed to work with
>> sub-interfaces is required IMHO, specifically because of the location related
>> sentences:
>>
>>     The combination of "type" and "location" is unique within the interface
>>     list.
>>
>>     ...
>>
>>     The "location" leaf is a string.  It is optional in the data model,
>>     but if the type represents a physical interface, it is mandatory.
>>
>> See below.
>>
>>>> For example, how should I understand the following sentence, if we speak
>>>> about
>>>> an subinterface
>>>>
>>>>      The "location" leaf is a string.  It is optional in the data model,
>>>>      but if the type represents a physical interface, it is mandatory.
>>>>
>>>> Does the subinterface really _represent _a physical interface?
>>> If you have your subinterface represent a vlan, it would not.  In this
>>> case, the subinterface would be layered on top of another (physical
>>> maybe) interface.
>> So should subinterface location be the location of the physical interface?
>> No, it can't because of
>>
>>     The combination of "type" and "location" is unique within the interface list
>>
>> You see, I'm slightly confused.
> No, you are right - the location would probably not be set for the
> type of subinterface you have in mind.  There are examples of vlan
> interfaces in the document.  You may call this a subinterface.  I
> don't think there is any defintion of the term subinterface, but I may
> be wrong.  So I don't really know what additional info you are looking
> for.
>
What would be required is a new appendix with how the config at 
http://www.youtube.com/watch?v=KdQlwm6bIpM might be defined. 
Alternatively, the appendix C could be improved.
Specifically, the combination of type and location must be clearly 
labeled (or explained) for the primary interface and subinterfaces.

Regards, Benoit

From j.schoenwaelder@jacobs-university.de  Wed Apr 17 08:19:18 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C05D21E805E for ; Wed, 17 Apr 2013 08:19:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=-0.550, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_24=0.6, J_CHICKENPOX_25=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 84oxhJwtITnu for ; Wed, 17 Apr 2013 08:19:17 -0700 (PDT)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 498BF21E8056 for ; Wed, 17 Apr 2013 08:19:17 -0700 (PDT)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 077FD20C06; Wed, 17 Apr 2013 17: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 (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id SGPc-hP4wXGu; Wed, 17 Apr 2013 17: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 5D8D120BDD; Wed, 17 Apr 2013 17:19:15 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 148A825B55F3; Wed, 17 Apr 2013 17:19:14 +0200 (CEST)
Date: Wed, 17 Apr 2013 17:19:14 +0200
From: Juergen Schoenwaelder 
To: Benoit Claise 
Message-ID: <20130417151914.GB184@elstar.local>
Mail-Followup-To: Benoit Claise , Martin Bjorklund , netmod@ietf.org
References: <5150CF8E.8090006@cisco.com> <20130402.230149.92811084.mbj@tail-f.com> <5162F4D6.6020009@cisco.com> <20130408.233810.311649160.mbj@tail-f.com> <516EB72E.5070604@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <516EB72E.5070604@cisco.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: netmod@ietf.org
Subject: Re: [netmod] AD review of draft-ietf-netmod-interfaces-cfg-09
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Apr 2013 15:19:18 -0000

On Wed, Apr 17, 2013 at 04:52:30PM +0200, Benoit Claise wrote:
> >
> What would be required is a new appendix with how the config at
> http://www.youtube.com/watch?v=KdQlwm6bIpM might be defined.
> Alternatively, the appendix C could be improved.
> Specifically, the combination of type and location must be clearly
> labeled (or explained) for the primary interface and subinterfaces.

Is the problem in appendix C that the vlan-tagging is defined only for
interfaces with if:type = 'ethernetCsmacd' or if:type =
'ieee8023adLag' while the base-interface and vlan-id leafs only exist
for interfaces with if:type = 'l2vlan'? In other words, is your
question concerning which if:types a vlan interface would have to use?

Concerning the location, I would assume that it does not exist on the
vlan interface itself because the location is a property of the base
interface.

Perhaps all that is needed is to add another vlan example interface to
the config snipped shown in Appendix D.

/js

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

From iesg-secretary@ietf.org  Wed Apr 17 08:27:48 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1745621E808A; Wed, 17 Apr 2013 08:27:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.453
X-Spam-Level: 
X-Spam-Status: No, score=-102.453 tagged_above=-999 required=5 tests=[AWL=0.147, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oikBxj1onrVy; Wed, 17 Apr 2013 08:27:47 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AD81821F871C; Wed, 17 Apr 2013 08:27:47 -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: 4.43.p4
Message-ID: <20130417152747.3417.14632.idtracker@ietfa.amsl.com>
Date: Wed, 17 Apr 2013 08:27:47 -0700
Cc: netmod@ietf.org
Subject: [netmod] Last Call:  (Common YANG Data	Types) to Proposed Standard
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: ietf@ietf.org
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Apr 2013 15:27:48 -0000

The IESG has received a request from the NETCONF Data Modeling Language
WG (netmod) to consider the following document:
- 'Common YANG Data Types'
   as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2013-05-01. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


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




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-netmod-rfc6021-bis/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-netmod-rfc6021-bis/ballot/


No IPR declarations have been submitted directly on this I-D.



From iesg-secretary@ietf.org  Wed Apr 17 08:27:48 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E85C21E808B for ; Wed, 17 Apr 2013 08:27:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.453
X-Spam-Level: 
X-Spam-Status: No, score=-102.453 tagged_above=-999 required=5 tests=[AWL=0.147, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hPkQVl4-qBQE; Wed, 17 Apr 2013 08:27:48 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CE21B21E8087; Wed, 17 Apr 2013 08:27:47 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: The IESG 
To: IANA 
X-Test-IDTracker: no
X-IETF-IDTracker: 4.43.p4
X-IETF-Draft-string: draft-ietf-netmod-rfc6021-bis
X-IETF-Draft-revision: 01
Message-ID: <20130417152747.3417.55924.idtracker@ietfa.amsl.com>
Date: Wed, 17 Apr 2013 08:27:47 -0700
Cc: netmod@ietf.org
Subject: [netmod] Last Call:  (Common YANG Data	Types) to Proposed Standard
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: noreply@ietf.org
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Apr 2013 15:27:48 -0000

The IESG has received a request from the NETCONF Data Modeling Language
WG (netmod) to consider the following document:
- 'Common YANG Data Types'
   as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2013-05-01. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


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




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-netmod-rfc6021-bis/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-netmod-rfc6021-bis/ballot/


No IPR declarations have been submitted directly on this I-D.



From mbj@tail-f.com  Wed Apr 17 13:49:33 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30F0D21E8098 for ; Wed, 17 Apr 2013 13:49:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.046
X-Spam-Level: 
X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yr6FoVgf8LNu for ; Wed, 17 Apr 2013 13:49:32 -0700 (PDT)
Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 6D3F721E8091 for ; Wed, 17 Apr 2013 13:49:32 -0700 (PDT)
Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 450501200CBB; Wed, 17 Apr 2013 22:49:31 +0200 (CEST)
Date: Wed, 17 Apr 2013 22:49:30 +0200 (CEST)
Message-Id: <20130417.224930.124544323.mbj@tail-f.com>
To: j.schoenwaelder@jacobs-university.de
From: Martin Bjorklund 
In-Reply-To: <20130417151914.GB184@elstar.local>
References: <20130408.233810.311649160.mbj@tail-f.com> <516EB72E.5070604@cisco.com> <20130417151914.GB184@elstar.local>
X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Cc: netmod@ietf.org
Subject: Re: [netmod] AD review of draft-ietf-netmod-interfaces-cfg-09
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Apr 2013 20:49:33 -0000

Juergen Schoenwaelder  wrote:
> On Wed, Apr 17, 2013 at 04:52:30PM +0200, Benoit Claise wrote:
> > >
> > What would be required is a new appendix with how the config at
> > http://www.youtube.com/watch?v=KdQlwm6bIpM might be defined.
> > Alternatively, the appendix C could be improved.
> > Specifically, the combination of type and location must be clearly
> > labeled (or explained) for the primary interface and subinterfaces.

[...]

> Perhaps all that is needed is to add another vlan example interface to
> the config snipped shown in Appendix D.

I think this makes sense.  I suggest we change the example in app. D
to:


  
    
      
        eth0
        ethernetCsmacd
        0
        true
        2
      
      
        eth1
        ethernetCsmacd
        1
        true
        7
        true
      
      
        eth1.10
        l2vlan
        true
        9
        eth1
        10
      
    
  


While doing this, I found and fixed a bug in a must expression in
Appendix C - quotes were missing around the literal 'true'.


Benoit, is this what you had in mind?



/martin

From bclaise@cisco.com  Fri Apr 19 01:55:56 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1872A21F937F for ; Fri, 19 Apr 2013 01:55:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.363
X-Spam-Level: 
X-Spam-Status: No, score=-10.363 tagged_above=-999 required=5 tests=[AWL=0.237, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0fv2censVnVS for ; Fri, 19 Apr 2013 01:55:55 -0700 (PDT)
Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 039BA21F936C for ; Fri, 19 Apr 2013 01:55:54 -0700 (PDT)
X-TACSUNS: Virus Scanned
Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r3J8tq85003619; Fri, 19 Apr 2013 10:55:52 +0200 (CEST)
Received: from [10.60.67.88] (ams-bclaise-8917.cisco.com [10.60.67.88]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r3J8tGp6028628; Fri, 19 Apr 2013 10:55:31 +0200 (CEST)
Message-ID: <51710674.5050807@cisco.com>
Date: Fri, 19 Apr 2013 10:55:16 +0200
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5
MIME-Version: 1.0
To: Martin Bjorklund 
References: <20130408.233810.311649160.mbj@tail-f.com> <516EB72E.5070604@cisco.com> <20130417151914.GB184@elstar.local> <20130417.224930.124544323.mbj@tail-f.com>
In-Reply-To: <20130417.224930.124544323.mbj@tail-f.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: netmod@ietf.org
Subject: Re: [netmod] AD review of draft-ietf-netmod-interfaces-cfg-09
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 Apr 2013 08:55:56 -0000

On 17/04/2013 22:49, Martin Bjorklund wrote:
> Juergen Schoenwaelder  wrote:
>> On Wed, Apr 17, 2013 at 04:52:30PM +0200, Benoit Claise wrote:
>>> What would be required is a new appendix with how the config at
>>> http://www.youtube.com/watch?v=KdQlwm6bIpM might be defined.
>>> Alternatively, the appendix C could be improved.
>>> Specifically, the combination of type and location must be clearly
>>> labeled (or explained) for the primary interface and subinterfaces.
> [...]
>
>> Perhaps all that is needed is to add another vlan example interface to
>> the config snipped shown in Appendix D.
> I think this makes sense.  I suggest we change the example in app. D
> to:
>
>       xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
>      message-id="101">
>    
>                xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces"
>          xmlns:vlan="http://example.com/vlan">
>        
>          eth0
>          ethernetCsmacd
>          0
>          true
>          2
>        
>        
>          eth1
>          ethernetCsmacd
>          1
>          true
>          7
>          true
>        
>        
>          eth1.10
>          l2vlan
>          true
>          9
>          eth1
>          10
>        
>      
>    
> 
>
> While doing this, I found and fixed a bug in a must expression in
> Appendix C - quotes were missing around the literal 'true'.
>
>
> Benoit, is this what you had in mind?
Exactly. Thanks
Please publish a new version, and I'll progress the document.

Regards, Benoit
>
>
>
> /martin
>
>


From internet-drafts@ietf.org  Fri Apr 19 02:59:51 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B30DE21F89B0; Fri, 19 Apr 2013 02:59:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.6
X-Spam-Level: 
X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h0dF3y66AiDJ; Fri, 19 Apr 2013 02:59:51 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5264E21F8928; Fri, 19 Apr 2013 02:59:51 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.44.p3
Message-ID: <20130419095951.21584.25395.idtracker@ietfa.amsl.com>
Date: Fri, 19 Apr 2013 02:59:51 -0700
Cc: netmod@ietf.org
Subject: [netmod] I-D Action: draft-ietf-netmod-interfaces-cfg-10.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 Apr 2013 09:59:51 -0000

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.
 This draft is a work item of the NETCONF Data Modeling Language Working Gr=
oup of the IETF.

	Title           : A YANG Data Model for Interface Management
	Author(s)       : Martin Bjorklund
	Filename        : draft-ietf-netmod-interfaces-cfg-10.txt
	Pages           : 39
	Date            : 2013-04-19

Abstract:
   This document defines a YANG data model for the management of network
   interfaces.  It is expected that interface type specific data models
   augment the generic interfaces data model defined in this document.


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

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

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


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


From balazs.lengyel@ericsson.com  Fri Apr 19 03:12:36 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09FF121F8F2F for ; Fri, 19 Apr 2013 03:12:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.249
X-Spam-Level: 
X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q2CCpV6zp5bu for ; Fri, 19 Apr 2013 03:12:35 -0700 (PDT)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id B7B2A21F8B64 for ; Fri, 19 Apr 2013 03:12:34 -0700 (PDT)
X-AuditID: c1b4fb25-b7f366d000004d10-37-517118918efb
Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 20.2C.19728.19811715; Fri, 19 Apr 2013 12:12:33 +0200 (CEST)
Received: from [159.107.197.4] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.279.1; Fri, 19 Apr 2013 12:12:33 +0200
Message-ID: <51711890.4060707@ericsson.com>
Date: Fri, 19 Apr 2013 12:12:32 +0200
From: Balazs Lengyel 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5
MIME-Version: 1.0
To: Kent Watsen 
References: 
In-Reply-To: 
Content-Type: text/plain; charset="windows-1252"; format=flowed
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupmluLIzCtJLcpLzFFi42KZGfG3VneiRGGgwYZ72hYH5rBbXFg1l81i /sVGVgdmjyVLfjJ5XG+6yu6x6fIdxgDmKC6blNSczLLUIn27BK6Mo8vWsxcsUq6YM30GUwPj VpEuRk4OCQETifUL5jFD2GISF+6tZ+ti5OIQEjjFKNF74hYTSEJIYDWjxKTpriA2r4C2xL71 HxhBbBYBVYmfr06xgdhsAkYSU/vPs4DYogJREv/e7maEqBeUODnzCVhcBKh+7aHDYHFmAQ+J +b2nweYLAx2xY+NGNohdBhJL1/WC1XMKGErcbZwOZHMA1dtLPNhaBtEqL9G8dTYzRLmGxMML f1knMArOQrJtFkLHLCQdCxiZVzGy5yZm5qSXG21iBAbowS2/VXcw3jkncohRmoNFSZw33PVC gJBAemJJanZqakFqUXxRaU5q8SFGJg5OqQZG2ymSxesnb3925dgUi7CqcIfVwp1OWUvmbku+ q3r+uQVbQ/Smy/y7TXfcWMLGerF7QuT2ja+/b12vGfPmThPro3zbgxUPdTbuK/y41t9CWuxp 23lhz4gQ6eOfFuvd2nv7e+e7i58lln8VlHmkmJKut7ChPKuM44FAuT/fFPdKKxuXlLP66bMU lFiKMxINtZiLihMBPjPW0R4CAAA=
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] Modeling recursive containment
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 Apr 2013 10:12:36 -0000

Hello Kent,
I had similar thoughts, but if you have possible containment like:
A might contain A
A might contain B
B might contain A
it becomes impossible to do the worst case.
regards Balazs

On 2013-04-15 22:25, Kent Watsen wrote:
> Hey Balazs,
>
> I asked the same question, and for the same reason, 2-3 years agoŠ
>
> I wound up modeling a "worst-case" containment depth:
>
> 
>      grouping component-type {
>          leaf model-number {
>             type string;
>             description "The component's model-number";
>          }
>          leaf part-number {
>             type string;
>             description "The component's part-number";
>          }
>          leaf part-version {
>             type string;
>             description "The component's part-version";
>          }
>          leaf serial-number {
>             type string;
>             description "The component's serial-number";
>          }
>          description
>             "this type is used by both the top-level chassis element
>              as well as \"recursively\" by its subcomponents";
>      }
>
>      grouping subcomponent-type {
>          uses component-type;
>          leaf location-id {
>              type string;
>              mandatory true;
>          }
>      }
>   
>
>      rpc get-hardware-inventory {
>          description
>              "Provides the hardware inventory on the device as a
>               hierarchy of components rooted by a special component
>               called \"chassis\".
>          output {
>              container hardware-inventory {
>                  container chassis {
>                      uses component-type;
>                      list subcomponent {
>                          uses subcomponent-type;
>                          list subcomponent {
>                              uses subcomponent-type;
>                              list subcomponent {
>                                  uses subcomponent-type;
>                                  list subcomponent {
>                                      uses subcomponent-type;
>                                      list subcomponent {
>                                          uses subcomponent-type;
>                                          list subcomponent {
>                                              uses subcomponent-type;
>                                              list subcomponent {
>                                                  uses subcomponent-type;
>                                              }
>                                          }
>                                      }
>                                  }
>                              }
>                          }
>                      }
>                  }
>              }
>          }
>      }
> 
>
>
>
>
>
> Kent
>
>
>
> On 4/12/13 12:12 PM, "Balazs Lengyel"  wrote:
>
>> On 2013-04-12 16:39, Ladislav Lhotka wrote:
>>> Hi Balazs,
>>>
>>> On Apr 12, 2013, at 4:34 PM, Balazs Lengyel
>>>  wrote:
>>>
>>>> Hello,
>>>> How is it possible to model recursive containment in YANG?
>>>> - I want a list representing some managed object e.g. a directory in a
>>>> file system, that can contain a directory in the file system, that can
>>>> contain a directory in a file system ...
>>>> - I have a HW module (which can be a slot, a subrack a card, a
>>>> chassis, etc.) which can contain a HW module, ...
>>>>
>>>> What is the best way to do this?
>>>> - Using references does not seem to be the best solution. Many tools
>>>> follow containment easily while following references is much more
>>>> limited.
>>>> - Grouping explicitly forbids this kind of construct.
>>> Recursive schemas are not allowed in YANG, and I believe it was a
>>> design feature.
>>>
>>> Lada
>>>
>> Sadly the real world does not seem to agree with this design decision,
>> which I hated originally as well.
>> So is there anything better then anyXml?
>> Balazs
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>>
>
>
>

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
System Manager
ECN: 831 7320                        Tel: +36-1-437-7320
Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.com


From internet-drafts@ietf.org  Fri Apr 19 04:26:43 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20A2F21F9579; Fri, 19 Apr 2013 04:26:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.499
X-Spam-Level: 
X-Spam-Status: No, score=-102.499 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lEb+C6G5GLwM; Fri, 19 Apr 2013 04:26:42 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B66BB21F94D9; Fri, 19 Apr 2013 04:26:42 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.44.p3
Message-ID: <20130419112642.10977.45314.idtracker@ietfa.amsl.com>
Date: Fri, 19 Apr 2013 04:26:42 -0700
Cc: netmod@ietf.org
Subject: [netmod] I-D Action: draft-ietf-netmod-iana-if-type-06.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 Apr 2013 11:26:43 -0000

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.
 This draft is a work item of the NETCONF Data Modeling Language Working Gr=
oup of the IETF.

	Title           : IANA Interface Type and Address Family YANG Modules
	Author(s)       : Martin Bjorklund
	Filename        : draft-ietf-netmod-iana-if-type-06.txt
	Pages           : 50
	Date            : 2013-04-19

Abstract:
   This document defines the initial versions of the iana-if-type and
   iana-afn-safi YANG modules.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-netmod-iana-if-type

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-netmod-iana-if-type-06

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netmod-iana-if-type-06


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


From balazs.lengyel@ericsson.com  Fri Apr 19 05:04:59 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DBE021F958A for ; Fri, 19 Apr 2013 05:04:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.249
X-Spam-Level: 
X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ESwOylo9sBtm for ; Fri, 19 Apr 2013 05:04:55 -0700 (PDT)
Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id C567121F955E for ; Fri, 19 Apr 2013 05:04:54 -0700 (PDT)
X-AuditID: c1b4fb30-b7f266d000000cb5-e5-517132e1f5d6
Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id DD.0F.03253.1E231715; Fri, 19 Apr 2013 14:04:49 +0200 (CEST)
Received: from [159.107.197.4] (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.279.1; Fri, 19 Apr 2013 14:04:49 +0200
Message-ID: <517132DF.2070305@ericsson.com>
Date: Fri, 19 Apr 2013 14:04:47 +0200
From: Balazs Lengyel 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5
MIME-Version: 1.0
To: netmod@ietf.org
References: <20130419112642.10977.45314.idtracker@ietfa.amsl.com>
In-Reply-To: <20130419112642.10977.45314.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrHJMWRmVeSWpSXmKPExsUyM+Jvre5Do8JAgx+zRC3mX2xkdWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXRsuZOywFCzkqvp1RbWCcy9bFyMkhIWAi0br4LzuELSZx4d56 oDgXh5DAKUaJ81efQzmrGSX+75wG1sEroC3x9vo+JhCbRUBV4tjX2ywgNpuAkcTU/vNgtqhA lMS/t7sZIeoFJU7OfAIWFxEQlpjY/I4VxBYWcJeYMXUFmC0k4Cix5+NssPmcAk4SRx+fArOZ BWwlLsy5zgJhy0tsfzuHGaJeQ+Lhhb+sExgFZiFZMQtJyywkLQsYmVcxsucmZuakl5tvYgSG 2cEtvw12MG66L3aIUZqDRUmcN9z1QoCQQHpiSWp2ampBalF8UWlOavEhRiYOTqkGRv3zE4X5 t/6y2f9zkfFUU+OEhYm7z5nb3KqJPSi1t+z64wmLFqst2XdmYnntzb8TlkhPiNlv2mNWXcGs oKmzMqM18ZH5Cql753fJLD79/MP7uZr/nb5YHKy9snl/wfNlXWHbFk9XPj97+dKvT92MD11c U9G1cobPhOder+9OkP5UpTRV3jjdjM1IiaU4I9FQi7moOBEARJbnOQECAAA=
Subject: [netmod] Augmenting with Mandatory lists in YANG. Why is it prohibited?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 Apr 2013 12:04:59 -0000

Hello,
 From the YANG RFC about the augment statement:
"If the target node is in another module, then nodes added by the
    augmentation MUST NOT be mandatory nodes (see Section 3.1)."

Why?
We have a datamodel in 2 parts YAM-A and YAM-B defined in two separate 
YANG Modules (YAMs).
The node must support A and may support B. However if it supports B, it 
must have at least one mandatory container/list-entry on it's top level. 
This is not allowed in YANG.

IMHO it is a perfectly valid use case, that if you indicate support 
function B the system shall automatically generate the top level 
container and all configuration updates must leave it there.
Implicitly you always have the possibility NOT to support YAM-B in which 
case its contents become non-mandatory.

How do you model this in YANG?

regards Balazs

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
System Manager
ECN: 831 7320                        Tel: +36-1-437-7320
Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.com


From mbj@tail-f.com  Fri Apr 19 05:21:42 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B19B121F95DE for ; Fri, 19 Apr 2013 05:21:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.046
X-Spam-Level: 
X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QjOkDv9X4jgj for ; Fri, 19 Apr 2013 05:21:41 -0700 (PDT)
Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 71A7521F9593 for ; Fri, 19 Apr 2013 05:21:40 -0700 (PDT)
Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id BB3371200050; Fri, 19 Apr 2013 14:21:38 +0200 (CEST)
Date: Fri, 19 Apr 2013 14:21:38 +0200 (CEST)
Message-Id: <20130419.142138.1417017007776871538.mbj@tail-f.com>
To: balazs.lengyel@ericsson.com
From: Martin Bjorklund 
In-Reply-To: <517132DF.2070305@ericsson.com>
References: <20130419112642.10977.45314.idtracker@ietfa.amsl.com> <517132DF.2070305@ericsson.com>
X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Cc: netmod@ietf.org
Subject: Re: [netmod] Augmenting with Mandatory lists in YANG. Why is it prohibited?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 Apr 2013 12:21:43 -0000

Hi,

Balazs Lengyel  wrote:
> Hello,
> From the YANG RFC about the augment statement:
> "If the target node is in another module, then nodes added by the
>    augmentation MUST NOT be mandatory nodes (see Section 3.1)."
> 
> Why?
> We have a datamodel in 2 parts YAM-A and YAM-B defined in two separate
> YANG Modules (YAMs).
> The node must support A and may support B. However if it supports B,
> it must have at least one mandatory container/list-entry on it's top
> level. This is not allowed in YANG.

Sorry but I do not understand.  What does augmentation have to do with
this?

YANG allows mandatory nodes on the top-level.

The reason for the augmentation rule is that an augment must not break
a client that doesn't understand the augmentation.  Such a client will
never be able to add the mandatory nodes...


/martin

From andy@yumaworks.com  Fri Apr 19 08:13:29 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FE6421F926E for ; Fri, 19 Apr 2013 08:13:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level: 
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n4AnWOQxAxDj for ; Fri, 19 Apr 2013 08:13:29 -0700 (PDT)
Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 8AD8421F95E9 for ; Fri, 19 Apr 2013 08:13:27 -0700 (PDT)
Received: by mail-ie0-f182.google.com with SMTP id bn7so2636792ieb.41 for ; Fri, 19 Apr 2013 08:13:27 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=zTOGdQsi1EScifBwpgG4a9yuAl0pj5+PRt4vu5Xo8iM=; b=aSSy2C5TdMrnT3T64hHHLaKNlt5YNVVlRS3fj1sMAaVRwgJJIUr6din4cYZ7iLNZEe Yu6AyNeoR8Ywc2pL5dc/aM0R/cNrln6wN16Nkpw421WLe6+//4P0AdWMcnBB1NNsEVvR Srnca5Q+bdjRx2qG6ENtliUKJ9WBr4SOziPvT+Fsw5ccoAgxVsWeH+PmyHj6v76Qw2nY QPetvTJ0OQyyS5SuuwzHm8qu/999cZOF7U+W1dI6zLhtxhAr+Rcndavsr2xXbHKVQCA0 UpXINCXub0s13XqYFut6k9lY2/JSDYhF5duOi3a41RcGgg7f7o8Olh5ryVrTgqTGcHZN aaRQ==
MIME-Version: 1.0
X-Received: by 10.43.135.68 with SMTP id if4mr8063825icc.44.1366384407116; Fri, 19 Apr 2013 08:13:27 -0700 (PDT)
Received: by 10.231.125.202 with HTTP; Fri, 19 Apr 2013 08:13:26 -0700 (PDT)
In-Reply-To: <20130419.142138.1417017007776871538.mbj@tail-f.com>
References: <20130419112642.10977.45314.idtracker@ietfa.amsl.com> <517132DF.2070305@ericsson.com> <20130419.142138.1417017007776871538.mbj@tail-f.com>
Date: Fri, 19 Apr 2013 08:13:26 -0700
Message-ID: 
From: Andy Bierman 
To: Martin Bjorklund 
Content-Type: multipart/alternative; boundary=20cf307f35fc36e04204dab829f5
X-Gm-Message-State: ALoCoQmk2UDGsxm8Hr1As8bNuxyFo8KUAVEo9bllWPQEbPkiq3o5kAUiYxbQRLnznZIUuazDgLLx
Cc: netmod@ietf.org
Subject: Re: [netmod] Augmenting with Mandatory lists in YANG. Why is it prohibited?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 Apr 2013 15:13:29 -0000

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

On Fri, Apr 19, 2013 at 5:21 AM, Martin Bjorklund  wrote:

> Hi,
>
> Balazs Lengyel  wrote:
> > Hello,
> > From the YANG RFC about the augment statement:
> > "If the target node is in another module, then nodes added by the
> >    augmentation MUST NOT be mandatory nodes (see Section 3.1)."
> >
> > Why?
> > We have a datamodel in 2 parts YAM-A and YAM-B defined in two separate
> > YANG Modules (YAMs).
> > The node must support A and may support B. However if it supports B,
> > it must have at least one mandatory container/list-entry on it's top
> > level. This is not allowed in YANG.
>
> Sorry but I do not understand.  What does augmentation have to do with
> this?
>
> YANG allows mandatory nodes on the top-level.
>
>
We never came to an agreement as to what this meant.
As I recall, Phil thought this did not even make sense,
since 'mandatory' refers to "the client must create it".
Others think mandatory means "the node must exist".

Unless the server creates a top-level mandatory node,
as soon as the module is loaded, the running config
is invalid according to YANG.

What the server does at this point is also controversial.
Either continue, or shut down and become a brick, or
maybe reject the module load request?

Then there are the pathological YANG modules that,
either alone or combined with other modules, produce
a combination of validation constraints that can never be met.
If the server is smart enough to detect them in the first place,
then what to do about this corner-case as well?


The reason for the augmentation rule is that an augment must not break
> a client that doesn't understand the augmentation.  Such a client will
> never be able to add the mandatory nodes...
>
>
> /martin
>

Andy

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



On Fri, Apr 19, 2013 at 5:21 AM, Martin =
Bjorklund <mbj@tail-f.com> wrote:

Hi,



Balazs Lengyel <balazs.le=
ngyel@ericsson.com> wrote:

> Hello,

> From the YANG RFC about the augment statement:

> "If the target node is in another module, then nodes added by the=


> =A0 =A0augmentation MUST NOT be mandatory nodes (see Section 3.1).&quo=
t;

>

> Why?

> We have a datamodel in 2 parts YAM-A and YAM-B defined in two separate=


> YANG Modules (YAMs).

> The node must support A and may support B. However if it supports B,
> it must have at least one mandatory container/list-entry on it's t=
op

> level. This is not allowed in YANG.



Sorry but I do not understand. =A0What does augmentation have to do with
this?



YANG allows mandatory nodes on the top-level.



We never came to an agreement as to wh=
at this meant.
As I recall, Phil thought this did not even make s=
ense,
since 'mandatory' refers to "the client must c=
reate it".


Others think mandatory means "the node must exist".

Unless the server creates a top-level mandatory node,
as soon as the module is loaded, the running config
is inva=
lid according to YANG.



What the server does at this point is also controversia=
l.
Either continue, or shut down and become a brick, or
maybe reject the module load request?

Then there =
are the pathological YANG modules that,


either alone or combined with other modules, produce
a combi=
nation of validation constraints that can never be met.
If the se=
rver is smart enough to detect them in the first place,
then what=
 to do about this corner-case as well?





The reason for the augmentation rule is that an augment must not break

a client that doesn't understand the augmentation. =A0Such a client wil=
l

never be able to add the mandatory nodes...





/martin

Andy



--20cf307f35fc36e04204dab829f5--

From balazs.lengyel@ericsson.com  Fri Apr 19 08:14:15 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5169221F86E8 for ; Fri, 19 Apr 2013 08:14:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.249
X-Spam-Level: 
X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bpLzMInB2IWv for ; Fri, 19 Apr 2013 08:14:14 -0700 (PDT)
Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 46B5D21F8709 for ; Fri, 19 Apr 2013 08:14:14 -0700 (PDT)
X-AuditID: c1b4fb30-b7f266d000000cb5-ec-51715f44c71a
Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id E3.DB.03253.44F51715; Fri, 19 Apr 2013 17:14:12 +0200 (CEST)
Received: from [159.107.96.36] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.279.1; Fri, 19 Apr 2013 17:14:12 +0200
Message-ID: <51715F43.9010101@ericsson.com>
Date: Fri, 19 Apr 2013 17:14:11 +0200
From: Balazs Lengyel 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5
MIME-Version: 1.0
To: Martin Bjorklund 
References: <20130419112642.10977.45314.idtracker@ietfa.amsl.com> <517132DF.2070305@ericsson.com> <20130419.142138.1417017007776871538.mbj@tail-f.com>
In-Reply-To: <20130419.142138.1417017007776871538.mbj@tail-f.com>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmphluLIzCtJLcpLzFFi42KZGfG3VtclvjDQoP2lpUV39zN2i/kXG1kd mDyWLPnJ5LHx12KWAKYoLpuU1JzMstQifbsErox/y2ayFmzlqrjZs5GtgfETexcjJ4eEgInE jE/fWSFsMYkL99azgdhCAqcYJSb+0uli5AKyVzNKXGlbwwyS4BXQlthx6TlYEYuAqsTUNbOY QGw2ASOJqf3nWUBsUYEoiX9vdzNC1AtKnJz5BCwuAlT/ZOdaMJtZQFhi9+FnYIuFBUIkvr9Z xw6xbBqjRMOJFqBmDg5OAUeJQzfdIeptJS7MuQ7VKy+x/e0cZohDNSQeXvjLOoFRcBaSdbOQ tMxC0rKAkXkVI3tuYmZOern5JkZgSB7c8ttgB+Om+2KHGKU5WJTEecNdLwQICaQnlqRmp6YW pBbFF5XmpBYfYmTi4JRqYMw4VVi6IyZeKdwwpIF7sex13+Up2U2ZH3zr1p/t9Z++gptBkFt0 ze/Gk7ttKpteXu8xPJWnzCv4+MMHdqYsCyYB0YyC076zercaR76WCgrknqRZof2/8MPSX7as vWHG/Twrn6uGyLBPm72KI/Vg+Pmjm+MvXLmXpBw+5e2xg6KKbIu9lPc1KbEUZyQaajEXFScC AFmyuGcXAgAA
Cc: netmod@ietf.org
Subject: Re: [netmod] Augmenting with Mandatory lists in YANG. Why is it prohibited?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 Apr 2013 15:14:15 -0000

Hello,
In our case the top level object is systemCreated (the node creates it 
itself), so unprepared clients are not troubled.
regards Balazs

On 2013-04-19 14:21, Martin Bjorklund wrote:
> Hi,
>
> Balazs Lengyel  wrote:
>> Hello,
>>  From the YANG RFC about the augment statement:
>> "If the target node is in another module, then nodes added by the
>>     augmentation MUST NOT be mandatory nodes (see Section 3.1)."
>>
>> Why?
>> We have a datamodel in 2 parts YAM-A and YAM-B defined in two separate
>> YANG Modules (YAMs).
>> The node must support A and may support B. However if it supports B,
>> it must have at least one mandatory container/list-entry on it's top
>> level. This is not allowed in YANG.
> Sorry but I do not understand.  What does augmentation have to do with
> this?
>
> YANG allows mandatory nodes on the top-level.
>
> The reason for the augmentation rule is that an augment must not break
> a client that doesn't understand the augmentation.  Such a client will
> never be able to add the mandatory nodes...
>
>
> /martin
>
>

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
System Manager
ECN: 831 7320                        Tel: +36-1-437-7320
Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.com


From iesg-secretary@ietf.org  Fri Apr 19 17:54:50 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B56B21F8F0D; Fri, 19 Apr 2013 17:54:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.515
X-Spam-Level: 
X-Spam-Status: No, score=-102.515 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5UZfk7IDgh6O; Fri, 19 Apr 2013 17:54:49 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FD8E21F8B35; Fri, 19 Apr 2013 17:54:49 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: IESG Secretary 
To: IETF Announcement List 
X-Test-IDTracker: no
X-IETF-IDTracker: 4.44.p3
Message-ID: <20130420005449.17298.86447.idtracker@ietfa.amsl.com>
Date: Fri, 19 Apr 2013 17:54:49 -0700
Cc: netmod@ietf.org
Subject: [netmod] Last Call:  (A YANG Data Model for	IP Management) to Proposed Standard
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 20 Apr 2013 00:54:50 -0000

The IESG has received a request from the NETCONF Data Modeling Language
WG (netmod) to consider the following document:
- 'A YANG Data Model for IP Management'
   as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2013-05-03. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


   This document defines a YANG data model for management of IP
   implementations.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-netmod-ip-cfg/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-netmod-ip-cfg/ballot/


No IPR declarations have been submitted directly on this I-D.


From iesg-secretary@ietf.org  Fri Apr 19 18:01:05 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B85921F95A0; Fri, 19 Apr 2013 18:01:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.521
X-Spam-Level: 
X-Spam-Status: No, score=-102.521 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RSdFOkRvMO0D; Fri, 19 Apr 2013 18:01:05 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 01DBA21F9196; Fri, 19 Apr 2013 18:01:05 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: IESG Secretary 
To: IETF Announcement List 
X-Test-IDTracker: no
X-IETF-IDTracker: 4.44.p3
Message-ID: <20130420010104.31983.13257.idtracker@ietfa.amsl.com>
Date: Fri, 19 Apr 2013 18:01:04 -0700
Cc: netmod@ietf.org
Subject: [netmod] Last Call:  (A YANG Data	Model for Interface Management) to Proposed Standard
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 20 Apr 2013 01:01:05 -0000

The IESG has received a request from the NETCONF Data Modeling Language
WG (netmod) to consider the following document:
- 'A YANG Data Model for Interface Management'
   as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2013-05-03. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


   This document defines a YANG data model for the management of network
   interfaces.  It is expected that interface type specific data models
   augment the generic interfaces data model defined in this document.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-netmod-interfaces-cfg/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-netmod-interfaces-cfg/ballot/


No IPR declarations have been submitted directly on this I-D.


From noreply@ietf.org  Fri Apr 19 06:25:25 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02EFF21F9005; Fri, 19 Apr 2013 06:25:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.6
X-Spam-Level: 
X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I1V8E3amClon; Fri, 19 Apr 2013 06:25:24 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D67221F8E73; Fri, 19 Apr 2013 06:25:24 -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: 4.44.p3
CC: 
Sender: 
Message-ID: <20130419132524.1622.39563.idtracker@ietfa.amsl.com>
Date: Fri, 19 Apr 2013 06:25:24 -0700
X-Mailman-Approved-At: Fri, 19 Apr 2013 23:45:58 -0700
Subject: [netmod] Last Call:  (A YANG Data	Model for Interface Management) to Proposed Standard
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: IETF Discussion List 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 Apr 2013 23:48:06 -0000

The IESG has received a request from the NETCONF Data Modeling Language
WG (netmod) to consider the following document:
- 'A YANG Data Model for Interface Management'
   as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2013-05-03. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


   This document defines a YANG data model for the management of network
   interfaces.  It is expected that interface type specific data models
   augment the generic interfaces data model defined in this document.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-netmod-interfaces-cfg/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-netmod-interfaces-cfg/ballot/


No IPR declarations have been submitted directly on this I-D.



From noreply@ietf.org  Fri Apr 19 06:24:52 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5145F21F902B; Fri, 19 Apr 2013 06:24:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.6
X-Spam-Level: 
X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E+DIxl7mz+O1; Fri, 19 Apr 2013 06:24:51 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E8C4C21F8D8E; Fri, 19 Apr 2013 06:24:51 -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: 4.44.p3
CC: 
Sender: 
Message-ID: <20130419132451.22330.4912.idtracker@ietfa.amsl.com>
Date: Fri, 19 Apr 2013 06:24:51 -0700
X-Mailman-Approved-At: Fri, 19 Apr 2013 23:45:58 -0700
Subject: [netmod] Last Call:  (A YANG Data Model for	IP Management) to Proposed Standard
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: IETF Discussion List 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 Apr 2013 23:48:06 -0000

The IESG has received a request from the NETCONF Data Modeling Language
WG (netmod) to consider the following document:
- 'A YANG Data Model for IP Management'
   as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2013-05-03. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


   This document defines a YANG data model for management of IP
   implementations.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-netmod-ip-cfg/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-netmod-ip-cfg/ballot/


No IPR declarations have been submitted directly on this I-D.



From internet-drafts@ietf.org  Sun Apr 21 16:17:18 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C984821F86AD; Sun, 21 Apr 2013 16:17:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.58
X-Spam-Level: 
X-Spam-Status: No, score=-102.58 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TDoHX-hEeZH5; Sun, 21 Apr 2013 16:17:18 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 73BCA21F8506; Sun, 21 Apr 2013 16:17:09 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.44.p3
Message-ID: <20130421231709.15944.31471.idtracker@ietfa.amsl.com>
Date: Sun, 21 Apr 2013 16:17:09 -0700
Cc: netmod@ietf.org
Subject: [netmod] I-D Action: draft-ietf-netmod-system-mgmt-06.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 21 Apr 2013 23:17:19 -0000

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.
 This draft is a work item of the NETCONF Data Modeling Language Working Gr=
oup of the IETF.

	Title           : YANG Data Model for System Management
	Author(s)       : Andy Bierman
                          Martin Bjorklund
	Filename        : draft-ietf-netmod-system-mgmt-06.txt
	Pages           : 33
	Date            : 2013-04-21

Abstract:
   This document defines a YANG data model for the configuration and
   identification of the management system of a device.


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

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-netmod-system-mgmt-06

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


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


From clint.chaplin@gmail.com  Mon Apr 22 13:39:15 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B937121E80C0; Mon, 22 Apr 2013 13:39:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17zUaQEcIklY; Mon, 22 Apr 2013 13:39:15 -0700 (PDT)
Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) by ietfa.amsl.com (Postfix) with ESMTP id C03A221E80BB; Mon, 22 Apr 2013 13:39:14 -0700 (PDT)
Received: by mail-wi0-f175.google.com with SMTP id h11so5165282wiv.2 for ; Mon, 22 Apr 2013 13:39:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=yigrVzXwH1goF8jlYAC6WaqifN25sWSTmRGqBZ0fPiU=; b=Tju9fYPZ0TvpEwrUbW9392ygIP8jL2TIeeUDZBmYHlKKwkHvBe+Xtrv7F2eqkCykXF vq/+/nvxAuCK32jcjAMdGf4LhgZ7hPRt8bS008dxPY34lU/oysiPN/qSUQz4cZVUsBHl x5il6uT2okicpMo4mqXHDSZg7HmNVAsGNxp8R7Igg9EoUQli/UxYpN3f8tNI7ZIVPwTD K2c6vr8x3MoZi8mtjYnL5igj9auWai1AnXnfYSc4nzBf+cc4jN1Su9eti0jqfi19cFm3 hO08m62n8TQsdVSaTipj8QWW+KpQ+21Rl56rCyEChutBYkV2z9h0bgJUoZYS2Ivz4iTM QVKw==
MIME-Version: 1.0
X-Received: by 10.194.109.136 with SMTP id hs8mr56391627wjb.8.1366663153915; Mon, 22 Apr 2013 13:39:13 -0700 (PDT)
Received: by 10.194.90.68 with HTTP; Mon, 22 Apr 2013 13:39:13 -0700 (PDT)
In-Reply-To: <20130419132451.22330.4912.idtracker@ietfa.amsl.com>
References: <20130419132451.22330.4912.idtracker@ietfa.amsl.com>
Date: Mon, 22 Apr 2013 13:39:13 -0700
Message-ID: 
From: Clint Chaplin 
To: IETF Discussion List 
Content-Type: multipart/alternative; boundary=089e0102e172d11f5904daf90fba
X-Mailman-Approved-At: Tue, 23 Apr 2013 06:32:37 -0700
Cc: netmod@ietf.org
Subject: Re: [netmod] Last Call:  (A YANG Data Model for IP Management) to Proposed Standard
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 Apr 2013 20:39:15 -0000

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

Why did this (and the other most recent) last call also not go to
IETF-Announce?


On Fri, Apr 19, 2013 at 6:24 AM, The IESG  wrote:

>
> The IESG has received a request from the NETCONF Data Modeling Language
> WG (netmod) to consider the following document:
> - 'A YANG Data Model for IP Management'
>    as Proposed Standard
>
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send substantive comments to the
> ietf@ietf.org mailing lists by 2013-05-03. Exceptionally, comments may be
> sent to iesg@ietf.org instead. In either case, please retain the
> beginning of the Subject line to allow automated sorting.
>
> Abstract
>
>
>    This document defines a YANG data model for management of IP
>    implementations.
>
>
>
>
> The file can be obtained via
> http://datatracker.ietf.org/doc/draft-ietf-netmod-ip-cfg/
>
> IESG discussion can be tracked via
> http://datatracker.ietf.org/doc/draft-ietf-netmod-ip-cfg/ballot/
>
>
> No IPR declarations have been submitted directly on this I-D.
>
>
>


-- 
Clint (JOATMON) Chaplin
Principal Engineer
Standards & Technology Enabling
Advanced Technology Lab
Samsung R&D Institute America - Silicon Valley

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


Why did this (and the other most recent) last call also no=
t go to IETF-Announce?


On Fri, Apr 19, 2013 at 6:24 AM, The IESG <noreply@ietf.or=
g> wrote:




The IESG has received a request from the NETCONF Data Modeling Language

WG (netmod) to consider the following document:

- 'A YANG Data Model for IP Management'

=A0 <draft-ietf-netmod-ip-cfg-09.txt> as Proposed Standard



The IESG plans to make a decision in the next few weeks, and solicits

final comments on this action. Please send substantive comments to the

ietf@ietf.org mailing lists by 2013-05=
-03. Exceptionally, comments may be

sent to iesg@ietf.org instead. In eith=
er case, please retain the

beginning of the Subject line to allow automated sorting.



Abstract





=A0 =A0This document defines a YANG data model for management of IP

=A0 =A0implementations.









The file can be obtained via

http://datatracker.ietf.org/doc/draft-ietf-netmod-ip-cfg/<=
br>


IESG discussion can be tracked via

http://datatracker.ietf.org/doc/draft-ietf-netmod-ip-cf=
g/ballot/





No IPR declarations have been submitted directly on this I-D.









-- 
Clint (JOATM=
ON) Chaplin
Principal Engineer
Standards & Technology EnablingAdvanced Technology Lab
Samsung R&D Institute America - Silicon Val=
ley



--089e0102e172d11f5904daf90fba--

From presnick@qti.qualcomm.com  Mon Apr 22 18:44:24 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB33121F8A0B; Mon, 22 Apr 2013 18:44:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.327
X-Spam-Level: 
X-Spam-Status: No, score=-102.327 tagged_above=-999 required=5 tests=[AWL=0.271, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CtpmdrNU41XS; Mon, 22 Apr 2013 18:44:23 -0700 (PDT)
Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) by ietfa.amsl.com (Postfix) with ESMTP id ED19B21F89B0; Mon, 22 Apr 2013 18:44:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1366681462; x=1398217462; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=sAmVaOAhp68ga7BemkkpSGoejCT9iQfAAq2ehg29Jkc=; b=tRGPdXY8/LFNhSFH6gsxTp82a3wJLFCSHNZD7h5RFh+y0aGfdZpEqkjj xl4VVmp3SG0L2Hi3h/pjvfoK72xeCOQHXNqWrl+WBdFvd5a3BZdlNzMmz g2NvhdiwxEg9hebiXLFx1jmG1B9MIRmtIfd/ZigFN7dDdtn046khsEF5e M=;
X-IronPort-AV: E=Sophos;i="4.87,530,1363158000"; d="scan'208,217";a="36207554"
Received: from ironmsg02-lv.qualcomm.com ([10.47.202.183]) by sabertooth02.qualcomm.com with ESMTP; 22 Apr 2013 18:44:22 -0700
Received: from nasanexhc07.na.qualcomm.com ([172.30.39.190]) by ironmsg02-lv.qualcomm.com with ESMTP/TLS/RC4-SHA; 22 Apr 2013 18:44:22 -0700
Received: from resnick2.qualcomm.com (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.190) with Microsoft SMTP Server (TLS) id 14.2.318.4; Mon, 22 Apr 2013 18:44:21 -0700
Message-ID: <5175E773.9050403@qti.qualcomm.com>
Date: Mon, 22 Apr 2013 20:44:19 -0500
From: Pete Resnick 
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4
MIME-Version: 1.0
To: Clint Chaplin 
References: <20130419132451.22330.4912.idtracker@ietfa.amsl.com> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------090305010305050707080401"
X-Originating-IP: [172.30.39.5]
X-Mailman-Approved-At: Tue, 23 Apr 2013 06:32:37 -0700
Cc: IETF Discussion List , netmod@ietf.org
Subject: Re: [netmod] Last Call:  (A YANG Data Model for IP Management) to Proposed Standard
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 Apr 2013 01:44:24 -0000

--------------090305010305050707080401
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit

It did go to IETF-Announce. It's just no longer in the To: field so 
people stop doing a reply-all and end up sending to it. (Basically, it's 
Bcc'ed. For e-mail geeks like me: An empty group list of 
"IETF-Announce:;" is now in the To: field.)

pr

On 4/22/13 3:39 PM, Clint Chaplin wrote:
> Why did this (and the other most recent) last call also not go to 
> IETF-Announce?
>
>
> On Fri, Apr 19, 2013 at 6:24 AM, The IESG  > wrote:
>
>
>     The IESG has received a request from the NETCONF Data Modeling
>     Language
>     WG (netmod) to consider the following document:
>     - 'A YANG Data Model for IP Management'
>      as Proposed Standard
>
>     The IESG plans to make a decision in the next few weeks, and solicits
>     final comments on this action. Please send substantive comments to the
>     ietf@ietf.org  mailing lists by 2013-05-03.
>     Exceptionally, comments may be
>     sent to iesg@ietf.org  instead. In either
>     case, please retain the
>     beginning of the Subject line to allow automated sorting.
>
>     Abstract
>
>
>        This document defines a YANG data model for management of IP
>        implementations.
>
>
>
>
>     The file can be obtained via
>     http://datatracker.ietf.org/doc/draft-ietf-netmod-ip-cfg/
>
>     IESG discussion can be tracked via
>     http://datatracker.ietf.org/doc/draft-ietf-netmod-ip-cfg/ballot/
>
>
>     No IPR declarations have been submitted directly on this I-D.
>
>
>
>
>
> -- 
> Clint (JOATMON) Chaplin
> Principal Engineer
> Standards & Technology Enabling
> Advanced Technology Lab
> Samsung R&D Institute America - Silicon Valley

-- 
Pete Resnick
Qualcomm Technologies, Inc. - +1 (858)651-4478


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




  


It did go to IETF-Announce. It's just no longer in the To: field so
people stop doing a reply-all and end up sending to it. (Basically,
it's Bcc'ed. For e-mail geeks like me: An empty group list of
"IETF-Announce:;" is now in the To: field.)



pr



On 4/22/13 3:39 PM, Clint Chaplin wrote:


  
Why did this (and the other most recent) last call
also not go to IETF-Announce?

  


  

  
On Fri, Apr 19, 2013 at 6:24 AM, The IESG <noreply@ietf.org> wrote:

  


The IESG has received a request from the NETCONF Data Modeling Language

WG (netmod) to consider the following document:

- 'A YANG Data Model for IP Management'

  <draft-ietf-netmod-ip-cfg-09.txt> as Proposed Standard

    

The IESG plans to make a decision in the next few weeks, and solicits

final comments on this action. Please send substantive comments to the

    ietf@ietf.org
mailing lists by 2013-05-03. Exceptionally, comments may be

sent to iesg@ietf.org
instead. In either case, please retain the

beginning of the Subject line to allow automated sorting.

    

Abstract

    

    

   This document defines a YANG data model for management of IP

   implementations.

    

    

    

    

The file can be obtained via

    http://datatracker.ietf.org/doc/draft-ietf-netmod-ip-cfg/

    

IESG discussion can be tracked via

    http://datatracker.ietf.org/doc/draft-ietf-netmod-ip-cfg/ballot/

    

    

No IPR declarations have been submitted directly on this I-D.

    

    

  

  

  

  

  


  

-- 

Clint (JOATMON) Chaplin

Principal Engineer

Standards & Technology Enabling

Advanced Technology Lab

Samsung R&D Institute America - Silicon Valley
  






-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478




--------------090305010305050707080401--

From balazs.lengyel@ericsson.com  Wed Apr 24 06:56:39 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 024CE21F8D79 for ; Wed, 24 Apr 2013 06:56:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.249
X-Spam-Level: 
X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K8wiaT45eDm4 for ; Wed, 24 Apr 2013 06:56:37 -0700 (PDT)
Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id CEA8121F8E4B for ; Wed, 24 Apr 2013 06:56:35 -0700 (PDT)
X-AuditID: c1b4fb30-b7f266d000000cb5-ea-5177e49206b7
Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 61.12.03253.294E7715; Wed, 24 Apr 2013 15:56:35 +0200 (CEST)
Received: from [159.107.197.235] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.279.1; Wed, 24 Apr 2013 15:56:34 +0200
Message-ID: <5177E491.2020103@ericsson.com>
Date: Wed, 24 Apr 2013 15:56:33 +0200
From: Balazs Lengyel 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5
MIME-Version: 1.0
To: netmod@ietf.org
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrKJMWRmVeSWpSXmKPExsUyM+Jvre7kJ+WBBkf9LeZfbGR1YPRYsuQn UwBjFJdNSmpOZllqkb5dAlfG0z7tggUsFV/2XWdsYOxj7mLk5JAQMJGYfv0DC4QtJnHh3nq2 LkYuDiGBU4wSjzp3MEE4axklVm5fyA5SxSugLfF922JWEJtFQFViwreVTCA2m4CRxNT+82CT RAWiJP693c0IUS8ocXLmE7C4iICwxMTmd2C9wgKyEmsXNIPNZBawlbgw5zoLhC0vsf3tHLDr hAQ0JB5e+Ms6gZFvFpJRs5C0zELSsoCReRUje25iZk56ufkmRmDQHNzy22AH46b7YocYpTlY lMR5w10vBAgJpCeWpGanphakFsUXleakFh9iZOLglGpgjDMuFAxe3Dxx6fNtrzOl/CUfxhja r5mgxHGVJeSle9aX2myhtKKcrA0nsp6+vMQ1f+u2Xx039u9z/cNdajODbdLsyhXT/tsuN2d8 ZXH1/dWMr+c9bp1Q0tslGfs0qCDlxSGuUyUVh/ZUJcVNO2z6sPmlVDF3tGdDtupNj7/uj0uX uL+rkH6gpMRSnJFoqMVcVJwIALj5POXoAQAA
Subject: [netmod] Keyless lists in rpc
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Apr 2013 13:56:39 -0000

Hello,
Lists sometimes need a key(s) sometimes don't depending on the config 
true/false statement.
My question is, do lists under the rpc/input/output statement need a 
key? Here the config statement is meaningless/ignored. In my view the 
key should not be needed, but the RFC does not say so. Opinions?
regards Balazs

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
System Manager
ECN: 831 7320                        Tel: +36-1-437-7320
Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.com


From lhotka@nic.cz  Wed Apr 24 07:17:11 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 963C421F90EA for ; Wed, 24 Apr 2013 07:17:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_23=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b5EtcsX76lOs for ; Wed, 24 Apr 2013 07:17:10 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 2622821F8E79 for ; Wed, 24 Apr 2013 07:17:10 -0700 (PDT)
Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 22C0113FB1F; Wed, 24 Apr 2013 16:17:05 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1366813025; bh=xozzkW52yZuQ+Zq+1LpAc5aED+f5l/mL4I3uSa0PSZ0=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=nhbqs8+tRA6Hi5TvZByoBHqJTvexOfCsC/Vd+br2C4/StdKkYEVXoiMvZTFWdiK+p ZcM6ecnggZ/O9Qd1UFTP3yEVDuH8+lussiv1xpGvuL1h5NtssrZZvvqeySlpGjRJ/u wuEpMs3G1+1lyEv7djpdq4rVLxqsdfy6rW3B1Gwo=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
From: Ladislav Lhotka 
In-Reply-To: <5177E491.2020103@ericsson.com>
Date: Wed, 24 Apr 2013 16:17:03 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <3ADDE1DF-6364-4B49-A301-CED143376226@nic.cz>
References: <5177E491.2020103@ericsson.com>
To: Balazs Lengyel 
X-Mailer: Apple Mail (2.1503)
X-Virus-Scanned: clamav-milter 0.97.7 at mail
X-Virus-Status: Clean
Cc: netmod@ietf.org
Subject: Re: [netmod] Keyless lists in rpc
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Apr 2013 14:17:11 -0000

On Apr 24, 2013, at 3:56 PM, Balazs Lengyel =
 wrote:

> Hello,
> Lists sometimes need a key(s) sometimes don't depending on the config =
true/false statement.
> My question is, do lists under the rpc/input/output statement need a =
key? Here the config statement is meaningless/ignored. In my view the =
key should not be needed, but the RFC does not say so. Opinions?

I agree. Keys are needed only in configuration data.

Lada

> regards Balazs
>=20
> --=20
> Balazs Lengyel                       Ericsson Hungary Ltd.
> System Manager
> ECN: 831 7320                        Tel: +36-1-437-7320
> Mobile: +36-70-330-7909              email: =
Balazs.Lengyel@ericsson.com
>=20
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

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





From jernej.tuljak@mg-soft.si  Wed Apr 24 07:18:04 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1414221F93B3 for ; Wed, 24 Apr 2013 07:18:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uE46AoCAXRer for ; Wed, 24 Apr 2013 07:18:03 -0700 (PDT)
Received: from gate.mg-soft.si (gate.mg-soft.si [212.30.73.66]) by ietfa.amsl.com (Postfix) with ESMTP id EF7F721F9382 for ; Wed, 24 Apr 2013 07:18:02 -0700 (PDT)
Received: from [10.0.0.222] (tp-x61t.mg-soft.si [10.0.0.222]) by gate.mg-soft.si (8.13.8/8.13.8) with ESMTP id r3OEHxfX006579; Wed, 24 Apr 2013 16:17:59 +0200
Message-ID: <5177E994.7030605@mg-soft.com>
Date: Wed, 24 Apr 2013 16:17:56 +0200
From: Jernej Tuljak 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: Balazs Lengyel 
References: <5177E491.2020103@ericsson.com>
In-Reply-To: <5177E491.2020103@ericsson.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Cc: netmod@ietf.org
Subject: Re: [netmod] Keyless lists in rpc
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Apr 2013 14:18:04 -0000

Dne 24.4.2013 15:56, piše Balazs Lengyel:
> Hello,
> Lists sometimes need a key(s) sometimes don't depending on the config 
> true/false statement.
> My question is, do lists under the rpc/input/output statement need a 
> key? Here the config statement is meaningless/ignored. In my view the 
> key should not be needed, but the RFC does not say so. Opinions?
> regards Balazs
>
I think that the RFC is clear enough on this matter. Key statements for 
lists with a rpc/notification ancestor are optional, since such lists do 
not represent configuration - they represent rpc operation 
parameters/notification body.

Jernej

From internet-drafts@ietf.org  Thu Apr 25 02:14:07 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DE7421F9446; Thu, 25 Apr 2013 02:14:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.6
X-Spam-Level: 
X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MKEMKAaso6hi; Thu, 25 Apr 2013 02:14:07 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1452921F8FF2; Thu, 25 Apr 2013 02:14:07 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.44.p4
Message-ID: <20130425091406.20009.51500.idtracker@ietfa.amsl.com>
Date: Thu, 25 Apr 2013 02:14:06 -0700
Cc: netmod@ietf.org
Subject: [netmod] I-D Action: draft-ietf-netmod-snmp-cfg-02.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 Apr 2013 09:14:07 -0000

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.
 This draft is a work item of the NETCONF Data Modeling Language Working Gr=
oup of the IETF.

	Title           : A YANG Data Model for SNMP Configuration
	Author(s)       : Martin Bjorklund
                          Juergen Schoenwaelder
	Filename        : draft-ietf-netmod-snmp-cfg-02.txt
	Pages           : 81
	Date            : 2013-04-25

Abstract:
   This document defines a collection of YANG definitions for
   configuring SNMP engines.


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

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

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


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


From mbj@tail-f.com  Thu Apr 25 02:18:22 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A79021F8FF2 for ; Thu, 25 Apr 2013 02:18:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.046
X-Spam-Level: 
X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y2iYDmp2vS99 for ; Thu, 25 Apr 2013 02:18:22 -0700 (PDT)
Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id EAEA121F9436 for ; Thu, 25 Apr 2013 02:18:21 -0700 (PDT)
Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id B673E1200AE5 for ; Thu, 25 Apr 2013 11:18:13 +0200 (CEST)
Date: Thu, 25 Apr 2013 11:18:13 +0200 (CEST)
Message-Id: <20130425.111813.1350257324758401159.mbj@tail-f.com>
To: netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: <20130425091406.20009.51500.idtracker@ietfa.amsl.com>
References: <20130425091406.20009.51500.idtracker@ietfa.amsl.com>
X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-snmp-cfg-02.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 Apr 2013 09:18:22 -0000

Hi,

We have posted a new version of the snmp cfg document.  We have
addressed the comments we received on the WGLC, which resulted in
mostly minor editorial changes.

The biggest change to this document is that based on the discussions
in NETCONF and NETMOD in Orlando, we have created a new YANG module
"ietf-x509-cert-to-name", which containts definitions for extracting a
name from certificates.  This module is used by the snmp-tls module,
and also by the upcoming version of the netconf-tls module.


/martin

From andy@yumaworks.com  Thu Apr 25 13:22:03 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 287A521F96A5 for ; Thu, 25 Apr 2013 13:22:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.222
X-Spam-Level: *
X-Spam-Status: No, score=1.222 tagged_above=-999 required=5 tests=[FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6,  NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LdsCqksePQcQ for ; Thu, 25 Apr 2013 13:22:02 -0700 (PDT)
Received: from mail-ie0-x235.google.com (mail-ie0-x235.google.com [IPv6:2607:f8b0:4001:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 89FD521F96A3 for ; Thu, 25 Apr 2013 13:21:59 -0700 (PDT)
Received: by mail-ie0-f181.google.com with SMTP id tp5so4075815ieb.40 for ; Thu, 25 Apr 2013 13:21:59 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=N2Uo+85F5F5Cf9bqw0EoV2vTgpj2GGQLNKRtL0YhnGk=; b=OkFrFXGZHhQzwL3FQ73ghko8NO9Ypeh1O2Ciqtm9glDN4uv6ucS2wYjs3OBJMGyd23 h75yIR0gsPr1hRWRZrtaqXfIlKBRGx+hofRQ3S4GN3fnWVMoXGjxr1/2J/MOlCyzKjM+ KKquZsK3hGJxisTpE/VmrUnOB58t84kH4LZsFKYrrs2c/yzHHOI7wehga+YtNkIPrmKW FzIfp41FZ3n6lZL/2cAuyBSi2jFzkNtQy6PhA7o0srYPKke3KvzD/QaIBodV7tXZVZ1y 4kFLBfQgyCbxgAcO4znFLYrIeaV08nqqFUWAyRB+JqRWW/zih4KUlYXkBHLDtFdG4dBZ idLA==
MIME-Version: 1.0
X-Received: by 10.50.114.195 with SMTP id ji3mr26393376igb.67.1366921319019; Thu, 25 Apr 2013 13:21:59 -0700 (PDT)
Received: by 10.231.125.202 with HTTP; Thu, 25 Apr 2013 13:21:58 -0700 (PDT)
Date: Thu, 25 Apr 2013 13:21:58 -0700
Message-ID: 
From: Andy Bierman 
To: netmod@ietf.org
Content-Type: multipart/alternative; boundary=089e0122ac46a8134604db352be8
X-Gm-Message-State: ALoCoQmxzn/T0F21nwS3NWAZ4W0HdvATkpD+ATea0qgTGOFc43ER+W+RuZqn5hRTm4q25FaGfCEq
Subject: [netmod] draft-ietf-netmod-system-mgmt-06
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 Apr 2013 20:22:03 -0000

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

Hi,

The ietf-system module draft has been updated:
http://www.ietf.org/id/draft-ietf-netmod-system-mgmt-06.txt

We think all requested changes were addressed except
adding additional parameters to control server auto-population
of entries. This should be left for future work.

Here is the change summary:

7.6.  05-06

   o  changed ntp/use-ntp to ntp/enabled

   o  changed ntp/ntp-server to ntp/server

   o  removed /system/platform/nodename leaf

   o  changed /system/name to /system/hostname

   o  simplified must expression in user-authentication-order

   o  added optional rounds to sha hash definition

   o  clarified the crypt-hash description

   o  clarified ntp descriptions

   o  clarified YANG module description to indicate that some system
      properties are supported, not the entire system

   o  clarified that system identification values are vendor specific,
      not the data node objects

   o  clarified sec. 2.2 and 2.3 to indicate that the server should also
      be capable of configuring these properties

   o  changed /system/dns/search from inet:host to inet:domain-name

   o  changed RFC6021 reference to 6021-bis

   o  changed /system/platform/nodename to /system/platform/hostname

   o  changed /system/radius/server/{leafs} to be within a choice and
      'udp' case statement so other transport specific parameters can
      augment this list or they can be added by the WG to a future
      version of this module. {leafs} are authentication-port and
      shared-secret.

   o  updated YANG tree diagrams for objects added in -05 and -06



Andy and Martin

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

Hi,

The ietf-system module draft has been updated:
=


We think all requested changes were addressed except
adding additional parameters to control server auto-populationof entries. This should be left for future work.


Here is the change summary:

7.6.  05-06

   o  changed ntp/use-ntp to ntp/enabled

   o  changed ntp/ntp-server to ntp/server

   o  removed /system/platform/nodename leaf

   o  changed /system/name to /system/hostname

   o  simplified must expression in user-authentication-order

   o  added optional rounds to sha hash definition

   o  clarified the crypt-hash description

   o  clarified ntp descriptions

   o  clarified YANG module description to indicate that some system
      properties are supported, not the entire system

   o  clarified that system identification values are vendor specific,
      not the data node objects

   o  clarified sec. 2.2 and 2.3 to indicate that the server should also
      be capable of configuring these properties

   o  changed /system/dns/search from inet:host to inet:domain-name

   o  changed RFC6021 reference to 6021-bis

   o  changed /system/platform/nodename to /system/platform/hostname

   o  changed /system/radius/server/{leafs} to be within a choice and
      'udp' case statement so other transport specific parameters c=
an
      augment this list or they can be added by the WG to a future
      version of this module. {leafs} are authentication-port and
      shared-secret.

   o  updated YANG tree diagrams for objects added in -05 and -06



Andy and Martin





--089e0122ac46a8134604db352be8--

From j.schoenwaelder@jacobs-university.de  Thu Apr 25 23:21:56 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0366B21F97E0 for ; Thu, 25 Apr 2013 23:21:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.249
X-Spam-Level: 
X-Spam-Status: No, score=-103.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zEFGvbgJEX39 for ; Thu, 25 Apr 2013 23:21:55 -0700 (PDT)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id DE70421F97D9 for ; Thu, 25 Apr 2013 23:21:46 -0700 (PDT)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id C8B7220BFF; Fri, 26 Apr 2013 08:21:44 +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 UvCHRSKUMHLh; Fri, 26 Apr 2013 08:21:44 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3979D20BFB; Fri, 26 Apr 2013 08:21:44 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 4BC2625DF491; Fri, 26 Apr 2013 08:21:43 +0200 (CEST)
Date: Fri, 26 Apr 2013 08:21:42 +0200
From: Juergen Schoenwaelder 
To: Andy Bierman 
Message-ID: <20130426062142.GA34767@elstar.local>
Mail-Followup-To: Andy Bierman , netmod@ietf.org
References: 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: netmod@ietf.org
Subject: Re: [netmod] draft-ietf-netmod-system-mgmt-06
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 Apr 2013 06:21:56 -0000

On Thu, Apr 25, 2013 at 01:21:58PM -0700, Andy Bierman wrote:
> Hi,
> 
> The ietf-system module draft has been updated:
> http://www.ietf.org/id/draft-ietf-netmod-system-mgmt-06.txt
> 
> We think all requested changes were addressed except
> adding additional parameters to control server auto-population
> of entries. This should be left for future work.

Thanks for the update. Do I understand correctly that the authors
believe this document is complete and ready for WG last call?

/js

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

From mbj@tail-f.com  Fri Apr 26 00:02:56 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D97021F97B0 for ; Fri, 26 Apr 2013 00:02:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.046
X-Spam-Level: 
X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id THc1YRxhfvVk for ; Fri, 26 Apr 2013 00:02:55 -0700 (PDT)
Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id AE7D321F930C for ; Fri, 26 Apr 2013 00:02:55 -0700 (PDT)
Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 0C18C1200AD8; Fri, 26 Apr 2013 09:02:54 +0200 (CEST)
Date: Fri, 26 Apr 2013 09:02:53 +0200 (CEST)
Message-Id: <20130426.090253.549985077309802438.mbj@tail-f.com>
To: j.schoenwaelder@jacobs-university.de
From: Martin Bjorklund 
In-Reply-To: <20130426062142.GA34767@elstar.local>
References:  <20130426062142.GA34767@elstar.local>
X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Cc: netmod@ietf.org
Subject: Re: [netmod] draft-ietf-netmod-system-mgmt-06
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 Apr 2013 07:02:56 -0000

Juergen Schoenwaelder  wrote:
> On Thu, Apr 25, 2013 at 01:21:58PM -0700, Andy Bierman wrote:
> > Hi,
> > 
> > The ietf-system module draft has been updated:
> > http://www.ietf.org/id/draft-ietf-netmod-system-mgmt-06.txt
> > 
> > We think all requested changes were addressed except
> > adding additional parameters to control server auto-population
> > of entries. This should be left for future work.
> 
> Thanks for the update. Do I understand correctly that the authors
> believe this document is complete and ready for WG last call?

Yes!


/martin

From jeffrey.K.lange@ge.com  Fri Apr 26 05:49:37 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43BA321F9913 for ; Fri, 26 Apr 2013 05:49:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b6E5JcPl6sSP for ; Fri, 26 Apr 2013 05:49:36 -0700 (PDT)
Received: from exprod5og114.obsmtp.com (exprod5og114.obsmtp.com [64.18.0.28]) by ietfa.amsl.com (Postfix) with ESMTP id 7920921F9870 for ; Fri, 26 Apr 2013 05:49:36 -0700 (PDT)
Received: from cinmlip11.e2k.ad.ge.com ([12.71.149.1]) (using TLSv1) by exprod5ob114.postini.com ([64.18.4.12]) with SMTP ID DSNKUXp34Dgkl7Zvs7XURhyVW9CuVxuKqUw9@postini.com; Fri, 26 Apr 2013 05:49:36 PDT
Received: from unknown (HELO cinmlef07.e2k.ad.ge.com) ([3.159.213.38]) by cinmlip11.e2k.ad.ge.com with ESMTP; 26 Apr 2013 08:49:34 -0400
Received: from cinmlef16.e2k.ad.ge.com ([3.159.213.85]) by cinmlef07.e2k.ad.ge.com with Microsoft SMTPSVC(6.0.3790.4675);  Fri, 26 Apr 2013 08:49:33 -0400
Received: from cinmlch01.e2k.ad.ge.com ([3.159.212.50]) by cinmlef16.e2k.ad.ge.com with Microsoft SMTPSVC(6.0.3790.4675);  Fri, 26 Apr 2013 08:49:24 -0400
Received: from CINURCNA06.e2k.ad.ge.com (3.159.212.107) by cinmlch01.e2k.ad.ge.com (3.159.212.50) with Microsoft SMTP Server (TLS) id 14.2.318.4; Fri, 26 Apr 2013 08:49:21 -0400
Received: from CINURCNA15.e2k.ad.ge.com ([169.254.3.88]) by CINURCNA06.e2k.ad.ge.com ([169.254.6.94]) with mapi id 14.02.0309.002; Fri, 26 Apr 2013 08:49:20 -0400
From: "Lange, Jeffrey K (GE Energy Management)" 
To: Martin Bjorklund , "j.schoenwaelder@jacobs-university.de" 
Thread-Topic: [netmod] draft-ietf-netmod-system-mgmt-06
Thread-Index: AQHOQfKdHKGa8SwR2Uafw8hK+oPBJZjoS8sAgAALgoCAAB07QA==
Date: Fri, 26 Apr 2013 12:49:20 +0000
Message-ID: 
References:  <20130426062142.GA34767@elstar.local> <20130426.090253.549985077309802438.mbj@tail-f.com>
In-Reply-To: <20130426.090253.549985077309802438.mbj@tail-f.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [3.159.212.187]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 26 Apr 2013 12:49:24.0499 (UTC) FILETIME=[7ADCC630:01CE427C]
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] draft-ietf-netmod-system-mgmt-06
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 Apr 2013 12:49:37 -0000

Looking over the system model, there seems strange that this doesn't includ=
e a sysUpTime equivalent.  Was this a conscious omission?

-Jeff


> -----Original Message-----
> From: netmod-bounces@ietf.org [mailto:netmod-bounces@ietf.org] On
> Behalf Of Martin Bjorklund
> Sent: Friday, April 26, 2013 3:03 AM
> To: j.schoenwaelder@jacobs-university.de
> Cc: netmod@ietf.org
> Subject: Re: [netmod] draft-ietf-netmod-system-mgmt-06
>=20
> Juergen Schoenwaelder  wrote:
> > On Thu, Apr 25, 2013 at 01:21:58PM -0700, Andy Bierman wrote:
> > > Hi,
> > >
> > > The ietf-system module draft has been updated:
> > > http://www.ietf.org/id/draft-ietf-netmod-system-mgmt-06.txt
> > >
> > > We think all requested changes were addressed except
> > > adding additional parameters to control server auto-population
> > > of entries. This should be left for future work.
> >
> > Thanks for the update. Do I understand correctly that the authors
> > believe this document is complete and ready for WG last call?
>=20
> Yes!
>=20
>=20
> /martin
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

From andy@yumaworks.com  Fri Apr 26 08:21:20 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D40F21F9939 for ; Fri, 26 Apr 2013 08:21:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.378
X-Spam-Level: 
X-Spam-Status: No, score=-0.378 tagged_above=-999 required=5 tests=[AWL=1.599,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rdpv2zFmTd5m for ; Fri, 26 Apr 2013 08:21:20 -0700 (PDT)
Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id C948121F9610 for ; Fri, 26 Apr 2013 08:21:19 -0700 (PDT)
Received: by mail-ie0-f173.google.com with SMTP id k5so5068242iea.32 for ; Fri, 26 Apr 2013 08:21:19 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=sRVjHt7CGhaA/+SzRrk8foLfSqPV7lJ4nRf8QLbIoTI=; b=W7pqVys8H9m/4a5EdLKoPWoFglSTgmbBJ2uHRzeGxzX5tYQ0IPHEwr52SwI7rSK5kM FyT5nIo38HFG4IAe9J3tqLsE68nt/vfJ4KOzj7swXOyYTrE/amvZocUaI3RcGt1AKp6+ BZOVQa/MAOa18oBWWgNyNvmmbelZCGuEHhN9m5LdtwbYpzaeNQjGrsuQhWuArXnXLSeL fIREh48vLtLeVTKCItYYf82RZsjLeVgrbN/s27E02zUdUlyV7HTNzkTRmZhgbucYJYF+ Ip/CP2hy5bkmtXiMqWAcgROrPBnSbfCMTNbahU1av9lMhi6ZpF5Vp6TsMdXEnKaUWUHw sQRg==
MIME-Version: 1.0
X-Received: by 10.50.114.195 with SMTP id ji3mr2158602igb.67.1366989678969; Fri, 26 Apr 2013 08:21:18 -0700 (PDT)
Received: by 10.231.125.202 with HTTP; Fri, 26 Apr 2013 08:21:18 -0700 (PDT)
In-Reply-To: 
References:  <20130426062142.GA34767@elstar.local> <20130426.090253.549985077309802438.mbj@tail-f.com> 
Date: Fri, 26 Apr 2013 08:21:18 -0700
Message-ID: 
From: Andy Bierman 
To: "Lange, Jeffrey K (GE Energy Management)" 
Content-Type: multipart/alternative; boundary=089e0122ac463a19d604db451688
X-Gm-Message-State: ALoCoQlHd9e+n4vejuYJJQC0yDSmul98eSyFjunrEPHx2SSLCrFdN2zYiqjneDDNPplctPCzIkiA
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] draft-ietf-netmod-system-mgmt-06
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 Apr 2013 15:21:20 -0000

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

Hi,

On Fri, Apr 26, 2013 at 5:49 AM, Lange, Jeffrey K (GE Energy Management) <
jeffrey.K.lange@ge.com> wrote:

> Looking over the system model, there seems strange that this doesn't
> include a sysUpTime equivalent.  Was this a conscious omission?
>
>
sysUpTime was discussed in the AD review of the interfaces module (see end):
http://www.ietf.org/mail-archive/web/netmod/current/msg07923.html

I think sysUpTime should go in the ietf-snmp module if it is needed.


-Jeff
>

Andy


>
>
> > -----Original Message-----
> > From: netmod-bounces@ietf.org [mailto:netmod-bounces@ietf.org] On
> > Behalf Of Martin Bjorklund
> > Sent: Friday, April 26, 2013 3:03 AM
> > To: j.schoenwaelder@jacobs-university.de
> > Cc: netmod@ietf.org
> > Subject: Re: [netmod] draft-ietf-netmod-system-mgmt-06
> >
> > Juergen Schoenwaelder  wrote:
> > > On Thu, Apr 25, 2013 at 01:21:58PM -0700, Andy Bierman wrote:
> > > > Hi,
> > > >
> > > > The ietf-system module draft has been updated:
> > > > http://www.ietf.org/id/draft-ietf-netmod-system-mgmt-06.txt
> > > >
> > > > We think all requested changes were addressed except
> > > > adding additional parameters to control server auto-population
> > > > of entries. This should be left for future work.
> > >
> > > Thanks for the update. Do I understand correctly that the authors
> > > believe this document is complete and ready for WG last call?
> >
> > Yes!
> >
> >
> > /martin
> > _______________________________________________
> > 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
>

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

Hi,

On Fri, Apr 26, 2013 at 5:49 AM, Lang=
e, Jeffrey K (GE Energy Management) <jeffrey.K.lange@ge.com> wrote:


Looking over the system model, there seems s=
trange that this doesn't include a sysUpTime equivalent. =A0Was this a =
conscious omission?




sysUpTime was discussed in the AD revi=
ew of the interfaces module (see end):



I think sysUpTime should go in the ietf-snmp module if =
it is needed.




-Jeff

Andy
=A0





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

> From: netmod-bounces@ietf.o=
rg [mailto:netmod-bounces@ie=
tf.org] On

> Behalf Of Martin Bjorklund

> Sent: Friday, April 26, 2013 3:03 AM

> To: j.schoenwa=
elder@jacobs-university.de

> Cc: netmod@ietf.org

> Subject: Re: [netmod] draft-ietf-netmod-system-mgmt-06

>

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

> > On Thu, Apr 25, 2013 at 01:21:58PM -0700, Andy Bierman wrote:

> > > Hi,

> > >

> > > The ietf-system module draft has been updated:

> > > http://www.ietf.org/id/draft-ietf-netmod-syst=
em-mgmt-06.txt

> > >

> > > We think all requested changes were addressed except

> > > adding additional parameters to control server auto-populati=
on

> > > of entries. This should be left for future work.

> >

> > Thanks for the update. Do I understand correctly that the authors=


> > believe this document is complete and ready for WG last call?

>

> Yes!

>

>

> /martin

> _______________________________________________

> 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





--089e0122ac463a19d604db451688--

From j.schoenwaelder@jacobs-university.de  Fri Apr 26 12:15:46 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE35321F99A5 for ; Fri, 26 Apr 2013 12:15:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.249
X-Spam-Level: 
X-Spam-Status: No, score=-103.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ctHF2+2zjtRz for ; Fri, 26 Apr 2013 12:15:45 -0700 (PDT)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id C15E021F99A3 for ; Fri, 26 Apr 2013 12:15:44 -0700 (PDT)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6D2D620BD8; Fri, 26 Apr 2013 21:15: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 rOPNN7rJgmvm; Fri, 26 Apr 2013 21:15:43 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6217C20BD7; Fri, 26 Apr 2013 21:15:42 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 5051125E13C9; Fri, 26 Apr 2013 21:15:41 +0200 (CEST)
Date: Fri, 26 Apr 2013 21:15:40 +0200
From: Juergen Schoenwaelder 
To: Andy Bierman 
Message-ID: <20130426191540.GA36791@elstar.local>
Mail-Followup-To: Andy Bierman , "Lange, Jeffrey K (GE Energy Management)" , Martin Bjorklund , "netmod@ietf.org" 
References:  <20130426062142.GA34767@elstar.local> <20130426.090253.549985077309802438.mbj@tail-f.com>  
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] draft-ietf-netmod-system-mgmt-06
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 Apr 2013 19:15:46 -0000

On Fri, Apr 26, 2013 at 08:21:18AM -0700, Andy Bierman wrote:
> 
> I think sysUpTime should go in the ietf-snmp module if it is needed.
> 

The ietf-snmp module is about config and you do obviously not
configure sysUpTime.

/js

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

From andy@yumaworks.com  Fri Apr 26 12:41:37 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5CC221F99CC for ; Fri, 26 Apr 2013 12:41:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.177
X-Spam-Level: 
X-Spam-Status: No, score=-1.177 tagged_above=-999 required=5 tests=[AWL=0.800,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZCUG8DIs62uV for ; Fri, 26 Apr 2013 12:41:37 -0700 (PDT)
Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id 49F4421F99CB for ; Fri, 26 Apr 2013 12:41:37 -0700 (PDT)
Received: by mail-ie0-f178.google.com with SMTP id aq17so5283954iec.37 for ; Fri, 26 Apr 2013 12:41:37 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type:x-gm-message-state; bh=DVHvq8FeojqtjbzHUYq6MuzA1MbDMTrcnuJ3gO7I4hg=; b=Z8ChynWKELZuKCGMYjcmOuyA5yHyGxPuhMZXSEs6sg3xgKrCPiH+kzAmJQr4Z74X9O ynVqDCnNf2TfmMpD2AYqChjFeQBXiB3bzvsFieIK68MRyIdYBFuCX2cuDnBvGs+HfSLW RsaauPzOdtbRdi9xHvow3yXZBI52zXmS8magRTYfLx4wmNAfvm5qzpph0N0Ls9wuVMwh 2HMJ7vhIGdrPdh+4CILpo9c7h6aWwQ28C1iOLp31/5+uGiIRoKyFzaJ6UWTuGtDj2/kR pV8hOKduXdeUYh/SOPjvEYiNAGYUCZA5QGkHtBiNAOdVvSGUYSf+e+eDuE/glaW1AbgI /63w==
MIME-Version: 1.0
X-Received: by 10.50.114.195 with SMTP id ji3mr2759475igb.67.1367005296903; Fri, 26 Apr 2013 12:41:36 -0700 (PDT)
Received: by 10.231.125.202 with HTTP; Fri, 26 Apr 2013 12:41:36 -0700 (PDT)
In-Reply-To: <20130426191540.GA36791@elstar.local>
References:  <20130426062142.GA34767@elstar.local> <20130426.090253.549985077309802438.mbj@tail-f.com>   <20130426191540.GA36791@elstar.local>
Date: Fri, 26 Apr 2013 12:41:36 -0700
Message-ID: 
From: Andy Bierman 
To: Juergen Schoenwaelder , Andy Bierman ,  "Lange, Jeffrey K (GE Energy Management)" , Martin Bjorklund , "netmod@ietf.org" 
Content-Type: multipart/alternative; boundary=089e0122ac4620dd0704db48b96b
X-Gm-Message-State: ALoCoQnCvcnkiOIqnRuDZp4hCdxGYb9AAUaaLyLL889L/78MPzk/dgt5rtnHaxKvef95m5etk4IV
Subject: Re: [netmod] draft-ietf-netmod-system-mgmt-06
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 Apr 2013 19:41:37 -0000

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

On Fri, Apr 26, 2013 at 12:15 PM, Juergen Schoenwaelder <
j.schoenwaelder@jacobs-university.de> wrote:

> On Fri, Apr 26, 2013 at 08:21:18AM -0700, Andy Bierman wrote:
> >
> > I think sysUpTime should go in the ietf-snmp module if it is needed.
> >
>
> The ietf-snmp module is about config and you do obviously not
> configure sysUpTime.
>
>
Then let's leave it out as already decided wrt/ ietf-interfaces.


> /js
>
>
Andy

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



On Fri, Apr 26, 2013 at 12:15 PM, Juerge=
n Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:


On Fri, Apr 26, 2013 at 08:21:18AM -0700, An=
dy Bierman wrote:

>

> I think sysUpTime should go in the ietf-snmp module if it is needed.
>



The ietf-snmp module is about config and you do obviously not

configure sysUpTime.



Then let's leave it out as already decided wrt/ =
ietf-interfaces.
=A0


/js



Andy



--089e0122ac4620dd0704db48b96b--

From johnsonhammond1@hushmail.com  Sat Apr 27 14:59:08 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C79B121F8930 for ; Sat, 27 Apr 2013 14:59:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.463
X-Spam-Level: 
X-Spam-Status: No, score=-2.463 tagged_above=-999 required=5 tests=[AWL=0.136,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mwh4jBKp-1av for ; Sat, 27 Apr 2013 14:59:06 -0700 (PDT)
Received: from smtp1.hushmail.com (smtp1a.hushmail.com [65.39.178.236]) by ietfa.amsl.com (Postfix) with ESMTP id 4663B21F9905 for ; Sat, 27 Apr 2013 14:59:04 -0700 (PDT)
Received: from smtp1.hushmail.com (smtp1a.hushmail.com [65.39.178.236]) by smtp1.hushmail.com (Postfix) with SMTP id E346230FEB for ; Sat, 27 Apr 2013 17:34:09 +0000 (UTC)
X-hush-relay-time: 213
X-hush-relay-id: b1bd903faba185ee07e5a0ed3a1fde37
Received: from smtp.hushmail.com (w5.hushmail.com [65.39.178.80]) by smtp1.hushmail.com (Postfix) with ESMTP for ; Sat, 27 Apr 2013 17:34:09 +0000 (UTC)
Received: by smtp.hushmail.com (Postfix, from userid 99) id B5554E6739; Sat, 27 Apr 2013 17:34:09 +0000 (UTC)
MIME-Version: 1.0
Date: Sat, 27 Apr 2013 13:34:09 -0400
To: netmod@ietf.org
From: johnsonhammond1@hushmail.com
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="UTF-8"
Message-Id: <20130427173409.B5554E6739@smtp.hushmail.com>
Subject: [netmod] Biggest Fake Conference in Computer Science
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 27 Apr 2013 21:59:08 -0000

Biggest Fake Conference in Computer Science


We are researchers from different parts of the world and conducted a study on  
the world’s biggest bogus computer science conference WORLDCOMP 
( http://sites.google.com/site/worlddump1 ) organized by Prof. Hamid Arabnia 
from University of Georgia, USA.


We submitted a fake paper to WORLDCOMP 2011 and again (the same paper 
with a modified title) to WORLDCOMP 2012. This paper had numerous 
fundamental mistakes. Sample statements from that paper include: 

(1). Binary logic is fuzzy logic and vice versa
(2). Pascal developed fuzzy logic
(3). Object oriented languages do not exhibit any polymorphism or inheritance
(4). TCP and IP are synonyms and are part of OSI model 
(5). Distributed systems deal with only one computer
(6). Laptop is an example for a super computer
(7). Operating system is an example for computer hardware


Also, our paper did not express any conceptual meaning.  However, it 
was accepted both the times without any modifications (and without 
any reviews) and we were invited to submit the final paper and a 
payment of $500+ fee to present the paper. We decided to use the 
fee for better purposes than making Prof. Hamid Arabnia (Chairman 
of WORLDCOMP) rich. After that, we received few reminders from 
WORLDCOMP to pay the fee but we never responded. 


We MUST say that you should look at the above website if you have any thoughts 
to submit a paper to WORLDCOMP.  DBLP and other indexing agencies have stopped 
indexing WORLDCOMP’s proceedings since 2011 due to its fakeness. See 
http://www.informatik.uni-trier.de/~ley/db/conf/icai/index.html for of one of the 
conferences of WORLDCOMP and notice that there is no listing after 2010. See Section 2 of
http://sites.google.com/site/dumpconf for comments from well-known researchers 
about WORLDCOMP. 


The status of your WORLDCOMP papers can be changed from scientific
to other (i.e., junk or non-technical) at any time. Better not to have a paper than 
having it in WORLDCOMP and spoil the resume and peace of mind forever!


Our study revealed that WORLDCOMP is a money making business, 
using University of Georgia mask, for Prof. Hamid Arabnia. He is throwing 
out a small chunk of that money (around 20 dollars per paper published 
in WORLDCOMP’s proceedings) to his puppet (Mr. Ashu Solo or A.M.G. Solo) 
who publicizes WORLDCOMP and also defends it at various forums, using 
fake/anonymous names. The puppet uses fake names and defames other conferences
to divert traffic to WORLDCOMP. He also makes anonymous phone calls and tries to 
threaten the critiques of WORLDCOMP (See Item 7 of Section 5 of above website). 
That is, the puppet does all his best to get a maximum number of papers published 
at WORLDCOMP to get more money into his (and Prof. Hamid Arabnia’s) pockets. 


Monte Carlo Resort (the venue of WORLDCOMP for more than 10 years, until 2012) has 
refused to provide the venue for WORLDCOMP’13 because of the fears of their image 
being tarnished due to WORLDCOMP’s fraudulent activities. That is why WORLDCOMP’13 
is taking place at a different resort. WORLDCOMP will not be held after 2013. 


The draft paper submission deadline is over but still there are no committee 
members, no reviewers, and there is no conference Chairman. The only contact 
details available on WORLDCOMP’s website is just an email address! 

Let us make a direct request to Prof. Hamid arabnia: publish all reviews for 
all the papers (after blocking identifiable details) since 2000 conference. Reveal 
the names and affiliations of all the reviewers (for each year) and how many 
papers each reviewer had reviewed on average. We also request him to look at 
the Open Challenge (Section 6) at https://sites.google.com/site/moneycomp1 


Sorry for posting to multiple lists. Spreading the word is the only way to stop 
this bogus conference. Please forward this message to other mailing lists and people. 


We are shocked with Prof. Hamid Arabnia and his puppet’s activities 
http://worldcomp-fake-bogus.blogspot.com   Search Google using the 
keyword worldcomp fake for additional links.


From calle@tail-f.com  Sun Apr 28 23:55:17 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C91A721F998F for ; Sun, 28 Apr 2013 23:55:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.046
X-Spam-Level: 
X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WLn6+VWda7-d for ; Sun, 28 Apr 2013 23:55:17 -0700 (PDT)
Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 29C1021F9985 for ; Sun, 28 Apr 2013 23:55:13 -0700 (PDT)
Received: from [10.0.0.3] (unknown [67.174.223.110]) by mail.tail-f.com (Postfix) with ESMTPSA id 55E7312008D2 for ; Mon, 29 Apr 2013 08:55:11 +0200 (CEST)
From: Carl Moberg 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Message-Id: 
Date: Sun, 28 Apr 2013 23:55:11 -0700
To: "netmod@ietf.org" 
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
X-Mailer: Apple Mail (2.1503)
Subject: [netmod] netconf:filterInlineType not resolved in 5277 schema?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 29 Apr 2013 06:55:17 -0000

WG,

 I've been made aware that the 'type=3D"netconf:filterInlineType"' =
present in the 'filter' element in the XML Schema for 5277 is =
unresolvable. The 'netconf' namespace maps to =
'urn:ietf:params:xml:ns:netconf:base:1.0' which does not seem to define =
this type.

 Should I raise a ticket?

--
Carl Moberg
twitter: @cmoberg
http://www.tail-f.com/


From mbj@tail-f.com  Mon Apr 29 00:01:30 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C213121F97EE for ; Mon, 29 Apr 2013 00:01:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.046
X-Spam-Level: 
X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GdPATFxQgy0i for ; Mon, 29 Apr 2013 00:01:30 -0700 (PDT)
Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 2D49A21F9720 for ; Mon, 29 Apr 2013 00:01:30 -0700 (PDT)
Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 202791200089; Mon, 29 Apr 2013 09:01:29 +0200 (CEST)
Date: Mon, 29 Apr 2013 09:01:28 +0200 (CEST)
Message-Id: <20130429.090128.2081333123291625662.mbj@tail-f.com>
To: calle@tail-f.com
From: Martin Bjorklund 
In-Reply-To: 
References: 
X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Cc: netmod@ietf.org
Subject: Re: [netmod] netconf:filterInlineType not resolved in 5277 schema?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 29 Apr 2013 07:01:30 -0000

Carl Moberg  wrote:
> WG,
> 
>  I've been made aware that the 'type="netconf:filterInlineType"'
>  present in the 'filter' element in the XML Schema for 5277 is
>  unresolvable. The 'netconf' namespace maps to
>  'urn:ietf:params:xml:ns:netconf:base:1.0' which does not seem to
>  define this type.

5277 imports the XSD from 4741.  filterInlineType is defined there.

Seems as yet another (minor...) reason to update 5277.



/martin

From lhotka@nic.cz  Mon Apr 29 05:47:07 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6246A21F9D40 for ; Mon, 29 Apr 2013 05:47:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_23=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c3EhBm3eGVw7 for ; Mon, 29 Apr 2013 05:47:06 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id B46DA21F97ED for ; Mon, 29 Apr 2013 05:47:06 -0700 (PDT)
Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 9A93113FC96 for ; Mon, 29 Apr 2013 14:47:04 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1367239624; bh=lUGLlE3GN+h7wAKnAzCaKtQSz8Qfu59wAemyTBNErXI=; h=From:Content-Type:Content-Transfer-Encoding:Subject:Message-Id: Date:To:Mime-Version; b=vNO5VeN7S7oJct6FUsbYKat1+6ggOUgXOGJ5KIVctEmtfzAQKex2UvjsnzAk72tCC tg1aij83g4S0vtgLYVfnO2zLwciR9ghu8WZk2alrWurfLrWLa+MPGie0hnac12zxV+ Ar/8WzSoVNVaE6pM0lGo9We1pEMHcOTzwDCnebqY=
From: Ladislav Lhotka 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Message-Id: <07AF9ED2-8E39-471C-93E2-E75D4DA92E1E@nic.cz>
Date: Mon, 29 Apr 2013 14:47:04 +0200
To: netmod@ietf.org
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
X-Mailer: Apple Mail (2.1503)
X-Virus-Scanned: clamav-milter 0.97.7 at mail
X-Virus-Status: Clean
Subject: [netmod] bug in ipv6-address-no-zone
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 29 Apr 2013 12:47:07 -0000

Hi,

the extra pattern in ipv6-address-no-zone (pattern '[0-9a-fA-F:]*';) is =
probably incorrect because it eliminates the IPv4-mapped addresses, such =
as ::ffff:1.2.3.4. The correct pattern would be

pattern '[0-9a-fA-F:.]*';

On the other hand, maybe IPv4-mapped addresses deserve a separate type =
because they are not allowed in all contexts. For example, I believe the =
IPv6 address configured on an interface should not be an IPv4-mapped =
address.

Lada

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





From mbj@tail-f.com  Mon Apr 29 05:52:28 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29F1121F9D71 for ; Mon, 29 Apr 2013 05:52:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.546
X-Spam-Level: 
X-Spam-Status: No, score=-2.546 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rp1v+Hm2jrCA for ; Mon, 29 Apr 2013 05:52:27 -0700 (PDT)
Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 90EEB21F9D85 for ; Mon, 29 Apr 2013 05:52:27 -0700 (PDT)
Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 66F8F1200D50; Mon, 29 Apr 2013 14:52:26 +0200 (CEST)
Date: Mon, 29 Apr 2013 14:52:26 +0200 (CEST)
Message-Id: <20130429.145226.2022342732166602338.mbj@tail-f.com>
To: lhotka@nic.cz
From: Martin Bjorklund 
In-Reply-To: <07AF9ED2-8E39-471C-93E2-E75D4DA92E1E@nic.cz>
References: <07AF9ED2-8E39-471C-93E2-E75D4DA92E1E@nic.cz>
X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Cc: netmod@ietf.org
Subject: Re: [netmod] bug in ipv6-address-no-zone
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 29 Apr 2013 12:52:28 -0000

Ladislav Lhotka  wrote:
> Hi,
> 
> the extra pattern in ipv6-address-no-zone (pattern '[0-9a-fA-F:]*';)
> is probably incorrect because it eliminates the IPv4-mapped addresses,
> such as ::ffff:1.2.3.4. The correct pattern would be
> 
> pattern '[0-9a-fA-F:.]*';

This should be

  pattern '[0-9a-fA-F:\.]*';


/martin

From lhotka@nic.cz  Mon Apr 29 06:04:56 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7E2021F9D7A for ; Mon, 29 Apr 2013 06:04:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_23=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BV6fjfCbXcYn for ; Mon, 29 Apr 2013 06:04:56 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 9055221F9D79 for ; Mon, 29 Apr 2013 06:04:55 -0700 (PDT)
Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 94B4313FC96; Mon, 29 Apr 2013 15:04:54 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1367240694; bh=6MLnKSQdjTMY+rxIUKztzMyF9riNp8IK5pDmB7Rz6m8=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=K3uWGXRzxrtU1QOd19uvyE4uPEOzI2+jzOHKa8wOwqoBx2I3T6eggEEvmf7OdXskz bGS4kRm/HCbieGEsDKqh3wn6Stjd+c5bGHsUACBn/DwZmhAlRzj2U+lQxUZbouiFW8 eMfyfXQrHGaFDSWtnODTD7/m5wByg0L9ANLf/9jU=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
From: Ladislav Lhotka 
In-Reply-To: <20130429.145226.2022342732166602338.mbj@tail-f.com>
Date: Mon, 29 Apr 2013 15:04:54 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <63D55653-A803-4011-A362-3F9EE0D564FB@nic.cz>
References: <07AF9ED2-8E39-471C-93E2-E75D4DA92E1E@nic.cz> <20130429.145226.2022342732166602338.mbj@tail-f.com>
To: Martin Bjorklund 
X-Mailer: Apple Mail (2.1503)
X-Virus-Scanned: clamav-milter 0.97.7 at mail
X-Virus-Status: Clean
Cc: netmod@ietf.org
Subject: Re: [netmod] bug in ipv6-address-no-zone
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 29 Apr 2013 13:04:56 -0000

On Apr 29, 2013, at 2:52 PM, Martin Bjorklund  wrote:

> Ladislav Lhotka  wrote:
>> Hi,
>>=20
>> the extra pattern in ipv6-address-no-zone (pattern '[0-9a-fA-F:]*';)
>> is probably incorrect because it eliminates the IPv4-mapped =
addresses,
>> such as ::ffff:1.2.3.4. The correct pattern would be
>>=20
>> pattern '[0-9a-fA-F:.]*';
>=20
> This should be
>=20
>  pattern '[0-9a-fA-F:\.]*';

Actually, no, the dot needn't be escaped in character classes (inside =
brackets).

Lada

>=20
>=20
> /martin

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





From mbj@tail-f.com  Mon Apr 29 13:46:50 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0298221F9A79; Mon, 29 Apr 2013 13:46:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.046
X-Spam-Level: 
X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pJMkqe0qdJue; Mon, 29 Apr 2013 13:46:45 -0700 (PDT)
Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id C47CB21F9A58; Mon, 29 Apr 2013 13:46:44 -0700 (PDT)
Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 913411200089; Mon, 29 Apr 2013 22:46:42 +0200 (CEST)
Date: Mon, 29 Apr 2013 22:46:41 +0200 (CEST)
Message-Id: <20130429.224641.08727383.mbj@tail-f.com>
To: cpignata@cisco.com
From: Martin Bjorklund 
In-Reply-To: <95067C434CE250468B77282634C96ED322AF32F4@xmb-aln-x02.cisco.com>
References: <95067C434CE250468B77282634C96ED322AF32F4@xmb-aln-x02.cisco.com>
X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=iso-2022-jp
Content-Transfer-Encoding: 7bit
Cc: rtg-dir@ietf.org, draft-ietf-netmod-interfaces-cfg.all@tools.ietf.org, netmod@ietf.org, rtg-ads@tools.ietf.org
Subject: Re: [netmod] RtgDir review: draft-ietf-netmod-interfaces-cfg-10.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 29 Apr 2013 20:46:50 -0000

Hi,

Thank you for your detailed review!  Comments inline.

"Carlos Pignataro (cpignata)"  wrote:
> Hello,
> 
> I have been selected as the Routing Directorate reviewer for this draft. The
> Routing Directorate seeks to review all routing or routing-related drafts as
> they pass through IETF last call and IESG review, and sometimes on special
> request. The purpose of the review is to provide assistance to the Routing
> ADs. For more information about the Routing Directorate, please see
> http://www.ietf.org/iesg/directorate/routing.html
> 
> Although these comments are primarily for the use of the Routing ADs, it would
> be helpful if you could consider them along with any other IETF Last Call
> comments that you receive, and strive to resolve them through discussion or by
> updating the draft.
> 
> Document: draft-ietf-netmod-interfaces-cfg-10.txt
> Reviewer: Carlos Pignataro
> Review Date: 01 May 2013
> IETF LC End Date: 03 May 2013
> Intended Status: Proposed Standard
> 
> Summary:
> 
> I have some minor concerns about this document that I think should be resolved
> before publication.
> 
> Comments:
> 
> This document is very well written, and sensible. It certainly achieves what
> its Abstract sets up to do, cleanly. Thank you for writing it!
> 
> However, I do believe that there are a few set of gaps that need to be resolved
> before publication. I identify some localized major issues below. Since I do
> not have context on some decisions that shaped the document, an explanation of
> the rational might suffice if sensible. Other of the identified issues, I
> believe, will require modifications or textual clarifications. In particular, I
> have a couple general concerns, about the generality of the data model defined
> in this document, details below.
> 
> I hope these review comments are clear and useful!
> 
> 
> Major Issues:
> 
> 3. Interfaces Data Model
> $B!D(B
>             +--ro if-index?                   int32
> 
> The "?" indicates that the lead is optional. From a routing perspective, the
> if-index plays an important role when for example the network layer address
> does not identify a specific interface (e.g., IP unnumbered), or when there is
> no network layer address (LAG member, etc.). Why is this optional? In which
> case you envision it would not be present?

I think you are right; this leaf should be mandatory.  This works
since it has an 'if-feature' statement.

But I would like to understand what role ifIndex plays - do you have
any pointers?

> Additionally, a stronger relationship or at least a more detailed description
> of the relationship with ifIndex would help interoperable implementations. Does
> this "if-index" leaf follow ifIndex if it changes upon reload of interface
> recreation? It seems from the definition that it is the same?

Yes, that is the intention.  The description says:

           The ifIndex value for the ifEntry represented by this
           interface.

> 3. Interfaces Data Model
> $B!D(B
>             +--rw location?                   string
> ...
> 3.1. The interface List
> $B!D(B
>    The "location" leaf is a string.  It is optional in the data model,
>    but if the type represents a physical interface, it is mandatory.
>    The format of this string is device- and type-dependent.  The device
>    uses the location string to identify the physical or logical entity
>    that the configuration applies to.  For example, if a device has a
>    single array of 8 ethernet ports, the location can be one of the
>    strings "1" to "8".  As another example, if a device has N cards of M
>    ports, the location can be on the form "n/m", such as "1/0".
> 
> I think that "location" is a poorly chosen label, a misnomer. This seems to be
> closer to an identifier than a locator. For example, some devices number slots
> left to right, and some number slots right to left :-)

Correct, and we do not try to get into this at all.  Some
devices has 2 ports called A and B, and some have chassis of cards
with rows of ports...

> This does not answer
> "where" something is; I do not mean geo-location, but I strongly suggest
> getting more precision on how this leaf is called. For example, interface
> numbering, instance id, type identifier, etc.

The intention is really to be "where" the port is.  It is not intended
to be a virtual id.  If the operator plugs in a cable in a certain
port, he has to know how to configure this port so there must be
something in the config that connects to the physical port.  We use
the name "location" for this purpose.

> 3. Interfaces Data Model
> $B!D(B
>       +--rw interfaces
>          +--rw interface [name]
>             +--rw $B!D(B
> 
> Is there a specific reason why there is no lead with the interface's MTU? It is
> quite important from a routing perspective for some protocols. MTU is not
> included even in the examples of ethernet-specific data models augmenting this
> base spec and appendices, which leaves it a bit underspecified$B!D(B

The mtu is specified in an accompanying document draft-ietf-netmod-ip.


> General:
> 
> As a general major comment: it is not clear how general or how specific this
> definition and document is.

It is a generic model. We tried to capture the intention in the
Introduction:

  This document defines a YANG ^RFC6020^ data model for the management
  of network interfaces. It is expected that interface type specific
  data models augment the generic interfaces data model defined in
  this document.

> In terms of the definition, this definition does not include information that
> applies to all interfaces (e.g., MTU), but it does include very specific
> non-general things like is_promiscuous.

Actually, ifPromiscuousMode is not part of this model.

> What is the information model on which
> this data model stands? If there was not RFC 2863, would a leaf be defined as
> ifPromiscuousMode or phys-address? Or would that belong in an ethernet-specific
> module?

You are right that phys-address might not have been included.

> In terms of the examples, basically all examples are some form of ethernet
> interface. For a document that aims at being general for managing network
> interfaces, this choice seems not inclusive.
> 
> 
> Minor Issues:
> 
> 2. Objectives
> ...
>    o  The data model should support the pre-provisioning of interface
>       configuration, i.e., it should be possible to configure an
>       interface whose physical interface hardware is not present on the
>       device.  It is recommended that devices that support dynamic
>       addition and removal of physical interfaces also support pre-
>       provisioning.
> 
> It is interesting that these design criteria do not call out the applicability
> to "physical" and "virtual" interfaces. Moreover, the text above seems to imply
> that the only "dynamic creation and deletion" of interfaces happens with the
> "addition and removal of physical interfaces" and does not call out tunnels,
> loopbacks, virtuals, and other logical entities instantiated as "interfaces".

I think you are reading too much into the statement above.  It says
that IF you support addition and removal of physical interfaces, then
...  This does NOT mean that devices cannot support tunnels, loobacks
etc.  But maybe I misunderstood your point.


> 3. Interfaces Data Model
> 
> Do some of the strings need to be described as maximum access parameter? Some
> rw attributes cannot be changed in all practical terms. The "type" leaf is
> RW. However, with what applicability (different speeds of "ethernet", different
> serials, how can it be changed)?

Implementations that cannot for some reason support changing certain
parameters simply won't support it.  But that's not a reason for the
standard to not support it.  In general, there is nothing wrong in
changing the type of an interface in the configuration - if there's
physical hardware that doesn't match the type at the moment, the
oper-status will be 'not-present'.

> 3. Interfaces Data Model
> $B!D(B
>             +--rw enabled?                    boolean
>             +--ro oper-status?                enumeration
> 
> I would have expected these two not to be optional ("?").

Actually, 'enabled' has a default value, so that's why it is marked as
optional.  For oper-status I believe you are right; since it has the
state 'unknown' it does not have to be optional.  I think we should
change this.

> 3. Interfaces Data Model
> $B!D(B
>       +--rw interfaces
>          +--rw interface [name]
>             +--ro statistics
>                +--ro in-discards?          yang:counter32
>                +--ro in-errors?            yang:counter32
>                +--ro in-unknown-protos?    yang:counter32
>                +--ro out-discards?         yang:counter32
>                +--ro out-errors?           yang:counter32
> 
> It seems like some statistics are counter32 while others are counter64. The
> ones that are counter64 seem to coincide with the ones that have HC (High
> Capacity) counters in RFC 2863 (this is from memory, might be incorrect). Is
> that the reason?

Yes.

> Is there any (other) specific reason why these are 32-bit
> counters while the rest of the statistics are 64 bit counters? I do wonder,
> however, if these should still be defined here as 64 bit...

The idea was that 64 bits are probably not needed for these counters.

> 4. Relationship to the IF-MIB
> $B!D(B
>    The following table lists the YANG data nodes with corresponding
>    objects in the IF-MIB.
> ...
>                Mapping of YANG data nodes to IF-MIB objects
> 
> This section explains how name cannot always map to ifName. However, the table
> shows a 1:1 mapping of name <-> ifName. I suggest marking with a footnote or
> "*" the elements that might not always may 1:1.
> 
> For example, "enabled" also cannot map to ifAdminStatus. "enabled" is a
> boolean, and ifAdminStatus is an INTEGER with at least 3 values specified (up,
> down, testing).
> 
> In summary, which ones map 1:1 and which ones do not?

This table is supposed to be an overview.  I think I would prefer to
add a sentence that says something like "For details about thae
mappings, please see the corresponding definition in the YANG module".

> 4. Relationship to the IF-MIB
> $B!D(B
>        | description                      | ifAlias                |
> 
> This is also a bit confusing -- the "description" maps to the ifAlias, and
> nothing maps to ifDescr.

Yes, this is b/c ifDescr is a read-only object defined as:

            This string should include the name of the
            manufacturer, the product name and the version of the
            interface hardware/software.

The only reason the "description" leaf is mapped to ifAlias is b/c
this is what many implementations do.  So we wanted to point out the
differences in the value space for these objects so that implementers
are aware of this.


> 4. Relationship to the IF-MIB
> 
>    The IF-MIB also defines the writable object ifPromiscuousMode.  Since
>    this object typically is not a configuration object, it is not mapped
>    to the "ietf-interfaces" module.
> 
> ifPromiscuousMode can actually be changed in many cases.

Right, but it is not typically a configuration parameter.

> Is that the only
> reason why attributes are being mapped to the "ietf-interfaces" module or not?

I wouldn't say that, bur for this particular object, the WG felt it
should be left out.


> 5. Interfaces YANG Module
> ...
>      organization
>        "IETF NETMOD (NETCONF Data Modeling Language) Working Group";
> 
>      contact
>        "WG Web:   
>         WG List:  
> 
>         WG Chair: David Kessens
>                   
> 
> Does the definition of the module, anchoring on a Working Group, put
> requirements or constraints on the existence of netmod? Meaning: what happens
> to these pointers when the WG ceases to exist, and the maling list is locked?
> Perhaps this is the usual way of defining contact for the YANG modules, but I
> suspect a time invariant pointer would help.

This also seems to be the usual way of defining contact info in
MIBs...

> $B!D(B
>          leaf name {
>            type string;
>            description
>              "The name of the interface.
> 
>               A device MAY restrict the allowed values for this leaf,
>               possibly depending on the type and location.
> 
>               If the device allows arbitrarily named interfaces, the
>               feature 'arbitrary-names' is advertised.
> 
>               This leaf MAY be mapped to ifName by an implementation.
>               Such an implementation MAY restrict the allowed values for
>               this leaf so that it matches the restrictions of ifName.
>               If a NETCONF server that implements this restriction is
>               sent a value that doesn't match the restriction, it MUST
>               reply with an rpc-error with the error-tag
>               'invalid-value'.";
> 
> Should the description of a YANG leaf be tied to NETCONF? Or are there
> potential uses outside NETCONF?

Currently the only standardized usage is NETCONF.  But vendors use
YANG for other purposes, and there's an individual draft that use YANG
for a RESTful api.

But the sentence really just specifies what a NETCONF server would
do.  It would be difficult to write this in a generic way, and at the
same time it is useful to specify this for NETCONF implementations.


> Please note that although this comment is made
> once, it applies to all the descriptions that say "If a NETCONF server$B!D(B", as
> there are quite a number of these.

Yes, but it is only used when we specify the NETCONF protocol behavior.

>          leaf location {
>            type string;
>            description
>              "The device-specific location of the interface of a
>               particular type.  The format of the location string
> 
> As mentioned above, this is not a "location".
> 
>          leaf phys-address {
>            type yang:phys-address;
>            config false;
>            description
>              "The interface's address at its protocol sub-layer.  For
>              example, for an 802.x interface, this object normally
>              contains a MAC address.  The interface's media-specific
>              modules must define the bit and byte ordering and the
>              format of the value of this object.  For interfaces that do
>              not have such an address (e.g., a serial line), this node
>              is not present.";
>            reference
>              "RFC 2863: The Interfaces Group MIB - ifPhysAddress";
>          }
> 
> Just by reading the description of this leaf, shouldn't this be part of an
> augmentation type-specific module? For example, for an Ethernet interface
> module, instead of the main YANG interface management top-level. Meaning: this
> specific leaf, by definition, cannot be generically specified to what it means
> for each type of interfaces. All the others can$B!D(B if this cannot be specified
> outside a media-specific module, why define it here?

See above - I think the reason is the relation to ifPhysAddress.

> 
>          leaf oper-status {
>            type enumeration {
> $B!D(B
> 
> The description of the leaf as well as the enum values for the oper-status seem
> to be a bit under-defined. For example, "Ready to pass packets" seems too
> literal from the MIB

Yes.

> while I believe there are more precise definitions.  Also,
> the description is actually listing usage of values instead of a real
> description.
> 
> 7. Security Considerations
> 
> 
>    The YANG module defined in this memo is designed to be accessed via
>    the NETCONF protocol [RFC6241].  The lowest NETCONF layer is the
>    secure transport layer and the mandatory-to-implement secure
>    transport is SSH [RFC6242].
> 
> Are there security considerations for other aspects of this language
> definition? For example, what if YANG is used via a different method? What
> about storage of the data? What about AAA aspects for RW or RO leafs?

The WG recently added a note about AAA aspects to the Security
Considerations template for YANG modules.  I will update this document
as well with the new text.

> 9.1. Normative References
> 
>    [I-D.ietf-netmod-iana-if-type]
> 
> This document points normatively to draft-ietf-netmod-iana-if-type-02. However,
> there are four additional revisions to the document and a most recent that is a
> year later than draft-ietf-netmod-iana-if-type-02. While things should be in
> sync given a common author and a hard dependency, just calling it out here
> since there are a few differences between those revisions of the normative
> reference:
> http://tools.ietf.org/rfcdiff?url2=draft-ietf-netmod-iana-if-type-06.txt&url1=draft-ietf-netmod-iana-if-type-02.txt

These documents are advanced together; but you are right, the
reference is pretty old.  I simply forgot to update it.


> Appendix A. Example: Ethernet Interface Module
> 
> Do these appendices need to explicitly say that are non-normative? I would add
> a one-liner about it.

Ok... but are examples ever normative?

> Appendix A. Example: Ethernet Interface Module
> 
> This applies to all appendices. I find it a bit incomplete that a specification
> for a language for "Interface Management" chose to ignore the richness of types
> of interfaces to show in the appendices :-) Basically, all of the ten (I think)
> different examples in the appendices are about Ethernet interfaces. While there
> is nothing underspecified, it is under-exemplified. How would a serial
> interface with sub interfaces loop like? How about a GRE Tunnel interface? Or a
> point-to-point satellite? Or a 3G interface? Or $B!D(B

It is always tricky with examples... In this case we wanted to
examplify different features of the model, and we picked examples that
build on each other.

> Nits: 
> 
> 2. Objectives
> ...
>    o  The model must support interface layering, both simple layering
>       where one interface is layered on top of exactly one other
>       interface, and more complex scenarios where one interface is
>       aggregated over N other interfaces, or when N interfaces are
>       multiplexed over one other interface.
> 
> This is a nit: are "aggregated" and "multiplexed" the right words here? I
> believe I understand what is meant, but at the same time, it's not clear how
> "one interface" can be "aggregated" (i.e., aggregate a plurality/collection of
> elements into one). Perhaps: "and more complex scenarios where one interface
> results from the aggregation of N other interfaces, or when N interfaces are
> multiplexed over one other interface."?

Yes, this is much better.  Thanks for the suggestion!


> 5. Interfaces YANG Module
> 
>          leaf oper-status {
>            type enumeration {
> $B!D(B
> 
> The description of the leaf as well as the enum values for the oper-status seem
> to be a bit under-defined. For example, "Ready to pass packets" seems too
> literal from the MIB, while I believe there are more precise definitions
> (s/packets/traffic/ at least?). Also, the description is actually listing usage
> of values instead of a real description.

[this seems to be a duplicate comment]


> I hope these are clear and useful!

It was; thank you!


/martin

From mbj@tail-f.com  Tue Apr 30 00:18:21 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3445E21F9B45; Tue, 30 Apr 2013 00:18:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.379
X-Spam-Level: 
X-Spam-Status: No, score=-2.379 tagged_above=-999 required=5 tests=[AWL=-0.333, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CFnLk8wBBO01; Tue, 30 Apr 2013 00:18:16 -0700 (PDT)
Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 2E99121F9B5A; Tue, 30 Apr 2013 00:18:11 -0700 (PDT)
Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id F1DD51200045; Tue, 30 Apr 2013 09:18:09 +0200 (CEST)
Date: Tue, 30 Apr 2013 09:18:09 +0200 (CEST)
Message-Id: <20130430.091809.2283109543662828002.mbj@tail-f.com>
To: cpignata@cisco.com
From: Martin Bjorklund 
In-Reply-To: <95067C434CE250468B77282634C96ED322AF7636@xmb-aln-x02.cisco.com>
References: <95067C434CE250468B77282634C96ED322AF32F4@xmb-aln-x02.cisco.com> <20130429.224641.08727383.mbj@tail-f.com> <95067C434CE250468B77282634C96ED322AF7636@xmb-aln-x02.cisco.com>
X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=iso-2022-jp
Content-Transfer-Encoding: 7bit
Cc: rtg-dir@ietf.org, draft-ietf-netmod-interfaces-cfg.all@tools.ietf.org, netmod@ietf.org, rtg-ads@tools.ietf.org
Subject: Re: [netmod] RtgDir review: draft-ietf-netmod-interfaces-cfg-10.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 30 Apr 2013 07:18:21 -0000

Hi,

Comments to the remaining issues inline.

"Carlos Pignataro (cpignata)"  wrote:
> On Apr 29, 2013, at 4:46 PM, Martin Bjorklund  wrote:
> > "Carlos Pignataro (cpignata)"  wrote:
> >> 3. Interfaces Data Model
> >> $B!D(B
> >>            +--ro if-index?                   int32
> >> 
> >> The "?" indicates that the lead is optional. From a routing
> >> perspective, the
> >> if-index plays an important role when for example the network layer
> >> address
> >> does not identify a specific interface (e.g., IP unnumbered), or when
> >> there is
> >> no network layer address (LAG member, etc.). Why is this optional? In
> >> which
> >> case you envision it would not be present?
> > 
> > I think you are right; this leaf should be mandatory.  This works
> > since it has an 'if-feature' statement.
> > 
> 
> Thanks. Even if it works because of the clause, I'd make this
> mandatory.

Yes, sorry for not being clear - it should be made mandatory, and I
meant that it is ok to make it mandatory since we have the
'if-feature' statement.


> >> 3. Interfaces Data Model
> >> $B!D(B
> >>            +--rw location?                   string
> >> ...
> >> 3.1. The interface List
> >> $B!D(B
> >>   The "location" leaf is a string.  It is optional in the data model,
> >>   but if the type represents a physical interface, it is mandatory.
> >>   The format of this string is device- and type-dependent.  The device
> >>   uses the location string to identify the physical or logical entity
> >>   that the configuration applies to.  For example, if a device has a
> >>   single array of 8 ethernet ports, the location can be one of the
> >>   strings "1" to "8".  As another example, if a device has N cards of M
> >>   ports, the location can be on the form "n/m", such as "1/0".
> >> 
> >> I think that "location" is a poorly chosen label, a misnomer. This
> >> seems to be
> >> closer to an identifier than a locator. For example, some devices
> >> number slots
> >> left to right, and some number slots right to left :-)
> > 
> > Correct, and we do not try to get into this at all.  Some
> > devices has 2 ports called A and B, and some have chassis of cards
> > with rows of ports...
> > 
> >> This does not answer
> >> "where" something is; I do not mean geo-location, but I strongly
> >> suggest
> >> getting more precision on how this leaf is called. For example,
> >> interface
> >> numbering, instance id, type identifier, etc.
> > 
> > The intention is really to be "where" the port is.  It is not intended
> > to be a virtual id.  If the operator plugs in a cable in a certain
> > port, he has to know how to configure this port so there must be
> > something in the config that connects to the physical port.  We use
> > the name "location" for this purpose.
> 
> Thanks for the explanation. While I appreciate (and I agree) that you
> do not get into interpreting or parsing the syntax of the field, I
> still think it is not a "location".
> 
> I believe there is still an underlying assumption that the language is
> defined for the physical world. If you have an Ethernet1/0, versus an
> Ethernet1/2, that identifies (not locates) which interface. Yes, you
> can use that to physically find them. But what if you have a
> "loopback123" vs "loopback112358 or a "Serial1/4:5.123"? I do not
> think we can "locate" the loopback, or the subinterface.
> 
> If the operator creates a "loopback", "Tunnel", or virtual interface,
> he or she does not need to physically locate it.
> 
> I believe that labeling the leaf as "location" can be harmful as it
> implies a specific meaning and shows assumptions.

Ok I think I understand your concern.  Personally, I think "location"
works also in this case, but we should pick a name that is as useful
as possible.  Let me bring this issue back to the WG.

> >> 3. Interfaces Data Model
> >> $B!D(B
> >>      +--rw interfaces
> >>         +--rw interface [name]
> >>            +--rw $B!D(B
> >> 
> >> Is there a specific reason why there is no lead with the interface's
> >> MTU? It is
> >> quite important from a routing perspective for some protocols. MTU is
> >> not
> >> included even in the examples of ethernet-specific data models
> >> augmenting this
> >> base spec and appendices, which leaves it a bit underspecified$B!D(B
> > 
> > The mtu is specified in an accompanying document draft-ietf-netmod-ip.
> > 
> 
> What draft-ietf-netmod-ip describes is the network-layer IPv4 MTU and
> IPv6 MTU. It does not describe the interface MTU. If that interface is
> used to run IS-IS, or to run MPLS, what is the MTU? It's neither the
> IPv4 MTU nor the IPv6 MTU.

This topic was discussed in the WG.  The result was that we did not
beleive we could define a generic mtu on the interface that would be
applicable to all types of interfaces.  Media-specific modules can
define this (maybe both configuration knobs and operational values).


> >> What is the information model on which
> >> this data model stands? If there was not RFC 2863, would a leaf be
> >> defined as
> >> ifPromiscuousMode or phys-address? Or would that belong in an
> >> ethernet-specific
> >> module?
> > 
> > You are right that phys-address might not have been included.
> > 
> 
> OK, thanks. Do you mean that you will be removing it?

I will have to bring this to the WG.

> >> In terms of the examples, basically all examples are some form of
> >> ethernet
> >> interface. For a document that aims at being general for managing
> >> network
> >> interfaces, this choice seems not inclusive.
> >> 
> >> 
> >> Minor Issues:
> >> 
> >> 2. Objectives
> >> ...
> >>   o  The data model should support the pre-provisioning of interface
> >>      configuration, i.e., it should be possible to configure an
> >>      interface whose physical interface hardware is not present on the
> >>      device.  It is recommended that devices that support dynamic
> >>      addition and removal of physical interfaces also support pre-
> >>      provisioning.
> >> 
> >> It is interesting that these design criteria do not call out the
> >> applicability
> >> to "physical" and "virtual" interfaces. Moreover, the text above seems
> >> to imply
> >> that the only "dynamic creation and deletion" of interfaces happens
> >> with the
> >> "addition and removal of physical interfaces" and does not call out
> >> tunnels,
> >> loopbacks, virtuals, and other logical entities instantiated as
> >> "interfaces".
> > 
> > I think you are reading too much into the statement above.  It says
> > that IF you support addition and removal of physical interfaces, then
> > ...  This does NOT mean that devices cannot support tunnels, loobacks
> > etc.  But maybe I misunderstood your point.
> > 
> 
> I was not clear. Yes, that is an important statement. I was suggesting
> that an addition of something like this would help:
> 
> "o The dat amodel should support virtual interfaces as well as
> physical interfaces blah blah".

Ok, this makese sense.  I will add this.

> >> 4. Relationship to the IF-MIB
> >> $B!D(B
> >>   The following table lists the YANG data nodes with corresponding
> >>   objects in the IF-MIB.
> >> ...
> >>               Mapping of YANG data nodes to IF-MIB objects
> >> 
> >> This section explains how name cannot always map to ifName. However,
> >> the table
> >> shows a 1:1 mapping of name <-> ifName. I suggest marking with a
> >> footnote or
> >> "*" the elements that might not always may 1:1.
> >> 
> >> For example, "enabled" also cannot map to ifAdminStatus. "enabled" is
> >> a
> >> boolean, and ifAdminStatus is an INTEGER with at least 3 values
> >> specified (up,
> >> down, testing).
> >> 
> >> In summary, which ones map 1:1 and which ones do not?
> > 
> > This table is supposed to be an overview.  I think I would prefer to
> > add a sentence that says something like "For details about thae
> > mappings, please see the corresponding definition in the YANG module".
> 
> No. I think that the table is a bit misleading when it says it
> described the "Mapping of YANG data nodes to IF-MIB objects", but some
> of these are related but do not really map.

It seems you react to the word "Mapping" here.  I am not sure why this
word would imply a one-to-one mapping, but if it helps we can change
this.

   Mapping of YANG data nodes to IF-MIB objects
   YANG data nodes and their corresponding IF-MIB objects
   YANG data nodes and their related IF-MIB objects
   ...?

> >> 5. Interfaces YANG Module
> >> ...
> >>     organization
> >>       "IETF NETMOD (NETCONF Data Modeling Language) Working Group";
> >> 
> >>     contact
> >>       "WG Web:   
> >>        WG List:  
> >> 
> >>        WG Chair: David Kessens
> >>                  
> >> 
> >> Does the definition of the module, anchoring on a Working Group, put
> >> requirements or constraints on the existence of netmod? Meaning: what
> >> happens
> >> to these pointers when the WG ceases to exist, and the maling list is
> >> locked?
> >> Perhaps this is the usual way of defining contact for the YANG
> >> modules, but I
> >> suspect a time invariant pointer would help.
> > 
> > This also seems to be the usual way of defining contact info in
> > MIBs...
> > 
> 
> But not for others. Is there value in defining the contact this way? I
> am just asking.

This is the currect practice that was decided (and documented in RFC
6087).

> >> 5. Interfaces YANG Module
> >> 
> >>         leaf oper-status {
> >>           type enumeration {
> >> $B!D(B
> >> 
> >> The description of the leaf as well as the enum values for the
> >> oper-status seem
> >> to be a bit under-defined. For example, "Ready to pass packets" seems
> >> too
> >> literal from the MIB, while I believe there are more precise
> >> definitions
> >> (s/packets/traffic/ at least?). Also, the description is actually
> >> listing usage
> >> of values instead of a real description.
> > 
> > [this seems to be a duplicate comment]
> > 
> 
> Yes, sorry. Are you planning on updating the description of the
> values?

Oh, you actually wrote:

   The description of the leaf as well as the enum values for the
   oper-status seem to be a bit under-defined. For example, "Ready to
   pass packets" seems too literal from the MIB, while I believe there
   are more precise definitions.

Maybe we can provde more precise defintions, but I am not sure it
helps.  Since this leaf is supposed to reflect the ifOperStatus, what
happens if we have a different description of the values than the MIB?




/martin

From j.schoenwaelder@jacobs-university.de  Tue Apr 30 00:27:35 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8E4921F9C55 for ; Tue, 30 Apr 2013 00:27:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.635
X-Spam-Level: 
X-Spam-Status: No, score=-100.635 tagged_above=-999 required=5 tests=[AWL=1.991, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U7m0Wrpok-4g for ; Tue, 30 Apr 2013 00:27:29 -0700 (PDT)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 49D1921F9B60 for ; Tue, 30 Apr 2013 00:27:29 -0700 (PDT)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 63AAE20C1B for ; Tue, 30 Apr 2013 09:27:28 +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 jb3-n3IYUXAk for ; Tue, 30 Apr 2013 09:27:28 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 332EB20C12 for ; Tue, 30 Apr 2013 09:27:28 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 59FE125E979F; Tue, 30 Apr 2013 09:27:27 +0200 (CEST)
Resent-From: Juergen Schoenwaelder 
Resent-Date: Tue, 30 Apr 2013 09:27:26 +0200
Resent-Message-ID: <20130430072726.GA46790@elstar.local>
Resent-To: netmod@ietf.org
Received: from hermes.jacobs-university.de (212.201.44.23) by SHUBCAS05.jacobs.jacobs-university.de (10.70.0.128) with Microsoft SMTP Server id 14.2.342.3; Tue, 30 Apr 2013 06:44:34 +0200
Received: from atlas2.jacobs-university.de (atlas2a.jacobs-university.de [212.201.44.15])	by hermes.jacobs-university.de (Postfix) with ESMTP id 8D74520C07	for ; Tue, 30 Apr 2013 06:44:35 +0200 (CEST)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48])	by atlas2.jacobs-university.de (Postfix) with ESMTP id 5F0F2B4	for ; Tue, 30 Apr 2013 06:44:35 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas2a.jacobs-university.de ([212.201.44.15])	by localhost (demetrius3.jacobs-university.de [212.201.44.48]) (amavisd-new, port 10030) with ESMTP id o23HV3voRQxr for ; Tue, 30 Apr 2013 06:44:33 +0200 (CEST)
X-JacobsISPWhiteListed: No
X-policyd-weight: using cached result; rate: -6.1
Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30])	(using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested)	by atlas2a.jacobs-university.de (Postfix) with ESMTPS	for ; Tue, 30 Apr 2013 06:44:32 +0200 (CEST)
Received: from mail-ve0-x233.google.com ([2607:f8b0:400c:c01::233]:56601)	by grenache.tools.ietf.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:128)	(Exim 4.80) (envelope-from )	id 1UX2QL-0006mr-Ix	for draft-ietf-netmod-interfaces-cfg.all@tools.ietf.org; Tue, 30 Apr 2013 06:44:22 +0200
Received: by mail-ve0-f179.google.com with SMTP id oz10so75611veb.24 for ; Mon, 29 Apr 2013 21:44:09 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:date:message-id:subject :from:to:content-type:x-gm-message-state; bh=XUzOC26uJ0W1nDVGQEXiHZGTH68hGMPIsvFm2cA+WWc=; b=jzx2Y59/8jNkLBmou2P57IlpNY91V84zxnQwrTbQK18WKakLXWMDQAcGMRDpPZOe4y 8aFtuh4qqwyaQCApHXkTcPmZ+SMjjk7hhzQdpIz/zbu037F0HL9OttNfeJP7Z45b+ABD nGT0E90Sxc45dJXvfyAb4+Spb3QMIV/ozhu6IK+QY+dH6sa5dwEOUc12UhfzF/VnbI6O m8F2cQu9XfnFRabWW3HNqvGCaJGeO16rMSsBE3J3TtcPd/UmruyBJWTqAjYtr8ZKGG4l ecoTEEPunfrwnXRNrN49B0S+bssfUSqT9qMU2BR6gibBjI1b+Inr8TxnFnDaJGrxmLem kbOQ==
X-Received: by 10.220.46.197 with SMTP id k5mr34673891vcf.40.1367297049364; Mon, 29 Apr 2013 21:44:09 -0700 (PDT)
Received: by 10.220.26.4 with HTTP; Mon, 29 Apr 2013 21:44:09 -0700 (PDT)
X-Originating-IP: [24.84.235.32]
Date: Mon, 29 Apr 2013 21:44:09 -0700
Message-ID: 
From: Tim Bray 
To: "apps-discuss@ietf.org" , , The IESG 
Content-Type: multipart/alternative; boundary="001a11c2ca40ee1d6d04db8ca655"
X-Gm-Message-State: ALoCoQleWljbvOCZArfGfev3T0tDjmyAUza/MDibbgeMqwHPYvzSXOhJS6TeCctw+76R4UuL11SJ
X-SA-Exim-Connect-IP: 2607:f8b0:400c:c01::233
X-SA-Exim-Rcpt-To: draft-ietf-netmod-interfaces-cfg.all@tools.ietf.org
X-SA-Exim-Mail-From: tbray@textuality.com
X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000)
X-SA-Exim-Scanned: Yes (on grenache.tools.ietf.org)
Resent-To: , , , 
X-MS-Exchange-Organization-AuthSource: SHUBCAS05.jacobs.jacobs-university.de
X-MS-Exchange-Organization-AuthAs: Anonymous
MIME-Version: 1.0
Subject: [netmod] Apps Area review of draft-ietf-netmod-interfaces-cfg-10
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 30 Apr 2013 07:27:36 -0000

--001a11c2ca40ee1d6d04db8ca655
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: quoted-printable

I have been selected as the Applications Area Directorate reviewer for this
draft (for background on appsdir, please see=20
http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate )=
.

Please resolve these comments along with any other Last Call comments you
may receive. Please wait for direction from your document shepherd or AD
before posting a new version of the draft.

Document: draft-ietf-netmod-interfaces-cfg-10
Title: A YANG Data Model for Interface Management
Reviewer: Tim Bray
Review Date: April 29

Summary: I see no objections to publication of this document as a
standards-track RFC

Note: I=92m not an expert in Netconf/YANG stuff, so really my only comments
are on style, coherence, and XML-sanity.  However, the presentation was
clear enough to be be comprehensible to the non-expert.

Major Issues: Don=92t see any

Minor Issues: Not obvious why all the examples are shuffled off into
Appendices, they=92re pretty essential to understanding the spec.

Nits:

3. =93The data model in the module "ietf-interfaces" has the following
structure...=94 - This is the first time the label =93ietf-interfaces=94 ha=
s
appeared. Is it a well-known name from another spec or are we defining it
here?  If the former, please reference. If the latter, maybe say something
like =93We define a module named "ietf-interfaces" whose data model has the
following structure...

3.1 =93The data model for interfaces presented in this document uses a flat
list of interfaces.=94 - does this mean that the model in section 3. should
have =93interface*=94 rather than just =93interface=94 as a child of =93int=
erfaces=94?
I have to say that this looks like a hash table indexed by name rather than
a =93flat list=94 in the conventional software sense.

--001a11c2ca40ee1d6d04db8ca655
Content-Type: text/html; charset="windows-1252"
Content-Transfer-Encoding: quoted-printable


I have been selected as the Applications Area Di=
rectorate reviewer for this draft (for background on appsdir, please see http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDire=
ctorate ).


Please resolve these comments along with any other Last Call comments y=
ou may receive. Please wait for direction from your document shepherd or AD=
 before posting a new version of the draft.

Document: draft-ietf-net=
mod-interfaces-cfg-10

Title: A YANG Data Model for Interface Management
Reviewer: Tim Bray
=
Review Date: April 29

Summary: I see no objections to publication of=
 this document as a standards-track RFC

Note: I=92m not a=
n expert in Netconf/YANG stuff, so really my only comments are on style, co=
herence, and XML-sanity.  However, the presentation was clear enough t=
o be be comprehensible to the non-expert.



Major Issues: Don=92t see any

Minor Issues: Not obvio=
us why all the examples are shuffled off into Appendices, they=92re pretty =
essential to understanding the spec.

Nits:

3. =93The data mod=
el in the module "ietf-interfaces" has the following structure...=
=94 - This is the first time the label =93ietf-interfaces=94 has appeared. =
Is it a well-known name from another spec or are we defining it here? =
 If the former, please reference. If the latter, maybe say something like =
=93We define a module named "ietf-interfaces" whose data model ha=
s the following structure...


3.1 =93The data model for interfaces presented in this document uses a =
flat list of interfaces.=94 - does this mean that the model in section 3. s=
hould have =93interface*=94 rather than just =93interface=94 as a child of =
=93interfaces=94?  I have to say that this looks like a hash table ind=
exed by name rather than a =93flat list=94 in the conventional software sen=
se.







--001a11c2ca40ee1d6d04db8ca655--

From mbj@tail-f.com  Tue Apr 30 00:29:54 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 418CA21F9C56 for ; Tue, 30 Apr 2013 00:29:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.296
X-Spam-Level: 
X-Spam-Status: No, score=-2.296 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vgRLl95q3UXu for ; Tue, 30 Apr 2013 00:29:47 -0700 (PDT)
Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id EE5B721F9C55 for ; Tue, 30 Apr 2013 00:29:46 -0700 (PDT)
Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id F23B61200045 for ; Tue, 30 Apr 2013 09:29:45 +0200 (CEST)
Date: Tue, 30 Apr 2013 09:29:45 +0200 (CEST)
Message-Id: <20130430.092945.981969607302073955.mbj@tail-f.com>
To: netmod@ietf.org
From: Martin Bjorklund 
X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=iso-2022-jp
Content-Transfer-Encoding: 7bit
Subject: [netmod] interface-cfg issues
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 30 Apr 2013 07:29:54 -0000

Hi,

The Routing Directorate review of
draft-ietf-netmod-interfaces-cfg-10.txt
brought up a couple of issues that I think the WG needs to dicsuss.

(The original mail is not in the list archive, but my reply is found
here: 
http://www.ietf.org/mail-archive/web/netmod/current/msg08031.html)


1)  The name "location"

> > >> 3. Interfaces Data Model
> > >> $B!D(B
> > >>            +--rw location?                   string
> > >> ...
> > >> 3.1. The interface List
> > >> $B!D(B
> > >>   The "location" leaf is a string.  It is optional in the data model,
> > >>   but if the type represents a physical interface, it is mandatory.
> > >>   The format of this string is device- and type-dependent.  The device
> > >>   uses the location string to identify the physical or logical entity
> > >>   that the configuration applies to.  For example, if a device has a
> > >>   single array of 8 ethernet ports, the location can be one of the
> > >>   strings "1" to "8".  As another example, if a device has N cards of M
> > >>   ports, the location can be on the form "n/m", such as "1/0".
> > >> 
> > >> I think that "location" is a poorly chosen label, a misnomer. This
> > >> seems to be
> > >> closer to an identifier than a locator. For example, some devices
> > >> number slots
> > >> left to right, and some number slots right to left :-)
> > > 
> > > Correct, and we do not try to get into this at all.  Some
> > > devices has 2 ports called A and B, and some have chassis of cards
> > > with rows of ports...
> > > 
> > >> This does not answer
> > >> "where" something is; I do not mean geo-location, but I strongly
> > >> suggest
> > >> getting more precision on how this leaf is called. For example,
> > >> interface
> > >> numbering, instance id, type identifier, etc.
> > > 
> > > The intention is really to be "where" the port is.  It is not intended
> > > to be a virtual id.  If the operator plugs in a cable in a certain
> > > port, he has to know how to configure this port so there must be
> > > something in the config that connects to the physical port.  We use
> > > the name "location" for this purpose.
> > 
> > Thanks for the explanation. While I appreciate (and I agree) that you
> > do not get into interpreting or parsing the syntax of the field, I
> > still think it is not a "location".
> > 
> > I believe there is still an underlying assumption that the language is
> > defined for the physical world. If you have an Ethernet1/0, versus an
> > Ethernet1/2, that identifies (not locates) which interface. Yes, you
> > can use that to physically find them. But what if you have a
> > "loopback123" vs "loopback112358 or a "Serial1/4:5.123"? I do not
> > think we can "locate" the loopback, or the subinterface.
> > 
> > If the operator creates a "loopback", "Tunnel", or virtual interface,
> > he or she does not need to physically locate it.
> > 
> > I believe that labeling the leaf as "location" can be harmful as it
> > implies a specific meaning and shows assumptions.
> 
> Ok I think I understand your concern.  Personally, I think "location"
> works also in this case, but we should pick a name that is as useful
> as possible.  Let me bring this issue back to the WG.


Any comments on this?


2)  phys-address

>>         leaf phys-address {
>>           type yang:phys-address;
>>           config false;
>>           description
>>             "The interface's address at its protocol sub-layer.  For
>>             example, for an 802.x interface, this object normally
>>             contains a MAC address.  The interface's media-specific
>>             modules must define the bit and byte ordering and the
>>             format of the value of this object.  For interfaces that do
>>             not have such an address (e.g., a serial line), this node
>>             is not present.";
>>           reference
>>             "RFC 2863: The Interfaces Group MIB - ifPhysAddress";
>>         }
>> 
>> Just by reading the description of this leaf, shouldn't this be
>> part of an augmentation type-specific module? For example, for an
>> Ethernet interface module, instead of the main YANG interface
>> management top-level. Meaning: this specific leaf, by definition,
>> cannot be generically specified to what it means for each type of
>> interfaces. All the others can$B!D(B if this cannot be specified outside
>> a media-specific module, why define it here?

So the proposal from him is to remove this leaf.  I think it could
stay, but we would probably not have added it if it wasn't part of
ifTable...  Comments?


/martin

From cpignata@cisco.com  Mon Apr 29 08:32:32 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC1E221F9DFE; Mon, 29 Apr 2013 08:32:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.599
X-Spam-Level: 
X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7xM1bX7LwO3U; Mon, 29 Apr 2013 08:32:31 -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 098F921F9DDF; Mon, 29 Apr 2013 08:32:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15772; q=dns/txt; s=iport; t=1367249551; x=1368459151; h=from:to:cc:subject:date:message-id:mime-version; bh=KMFEolU1O1/uKedL/AeJc8o47q0OsdtIQ7wV+XU+XBM=; b=BGTVGBZFpviJrlcOCCk4KyQrpL0QTeMRQARwEjg/aGZsDg2IV0MDA6Zi ZlmgyitbNZ/9XSY9HUidsvSsT5sLf2xMYcBZvM+RRrCiP51dWrLs80vip a4/da454daQKSt+8C4ryJ+oWEQY4GQB76b9TvRfXp1ByBxHAwEwUAELL9 0=;
X-Files: signature.asc : 203
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AjwHACmSflGtJV2d/2dsb2JhbABJAgiDBza+QYEGFm0HgiEBBCdLBxIBHA4dORQTBA4DAggBBYgIDLtXjVYIBgp7IBECgnNhA49pgSmHMpAEgxFAgSoBHx4
X-IronPort-AV: E=Sophos;i="4.87,574,1363132800";  d="asc'?scan'208";a="204421095"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-4.cisco.com with ESMTP; 29 Apr 2013 15:32:30 +0000
Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r3TFWU40017687 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 29 Apr 2013 15:32:30 GMT
Received: from xmb-aln-x02.cisco.com ([169.254.5.192]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.02.0318.004; Mon, 29 Apr 2013 10:32:29 -0500
From: "Carlos Pignataro (cpignata)" 
To: "rtg-ads@tools.ietf.org" 
Thread-Topic: RtgDir review: draft-ietf-netmod-interfaces-cfg-10.txt
Thread-Index: AQHORO7C2y3SdVUEW027VIOCZsJnvA==
Date: Mon, 29 Apr 2013 15:32:29 +0000
Message-ID: <95067C434CE250468B77282634C96ED322AF32F4@xmb-aln-x02.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [64.102.157.8]
Content-Type: multipart/signed; boundary="Apple-Mail=_928E38FA-CF0B-4B38-B59F-541EF53AF88B"; protocol="application/pgp-signature"; micalg=pgp-sha1
MIME-Version: 1.0
X-Mailman-Approved-At: Tue, 30 Apr 2013 00:33:14 -0700
Cc: "rtg-dir@ietf.org" , "draft-ietf-netmod-interfaces-cfg.all@tools.ietf.org" , "netmod@ietf.org" 
Subject: [netmod] RtgDir review: draft-ietf-netmod-interfaces-cfg-10.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 29 Apr 2013 15:32:32 -0000

--Apple-Mail=_928E38FA-CF0B-4B38-B59F-541EF53AF88B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

Hello,

I have been selected as the Routing Directorate reviewer for this draft. =
The Routing Directorate seeks to review all routing or routing-related =
drafts as they pass through IETF last call and IESG review, and =
sometimes on special request. The purpose of the review is to provide =
assistance to the Routing ADs. For more information about the Routing =
Directorate, please see =
http://www.ietf.org/iesg/directorate/routing.html

Although these comments are primarily for the use of the Routing ADs, it =
would be helpful if you could consider them along with any other IETF =
Last Call comments that you receive, and strive to resolve them through =
discussion or by updating the draft.

Document: draft-ietf-netmod-interfaces-cfg-10.txt
Reviewer: Carlos Pignataro
Review Date: 01 May 2013
IETF LC End Date: 03 May 2013
Intended Status: Proposed Standard

Summary:

I have some minor concerns about this document that I think should be =
resolved before publication.

Comments:

This document is very well written, and sensible. It certainly achieves =
what its Abstract sets up to do, cleanly. Thank you for writing it!=20

However, I do believe that there are a few set of gaps that need to be =
resolved before publication. I identify some localized major issues =
below. Since I do not have context on some decisions that shaped the =
document, an explanation of the rational might suffice if sensible. =
Other of the identified issues, I believe, will require modifications or =
textual clarifications. In particular, I have a couple general concerns, =
about the generality of the data model defined in this document, details =
below.

I hope these review comments are clear and useful!


Major Issues:

3. Interfaces Data Model
=85
            +--ro if-index?                   int32

The "?" indicates that the lead is optional. =46rom a routing =
perspective, the if-index plays an important role when for example the =
network layer address does not identify a specific interface (e.g., IP =
unnumbered), or when there is no network layer address (LAG member, =
etc.). Why is this optional? In which case you envision it would not be =
present?

Additionally, a stronger relationship or at least a more detailed =
description of the relationship with ifIndex would help interoperable =
implementations. Does this "if-index" leaf follow ifIndex if it changes =
upon reload of interface recreation? It seems from the definition that =
it is the same?

3. Interfaces Data Model
=85
            +--rw location?                   string
...
3.1. The interface List
=85
   The "location" leaf is a string.  It is optional in the data model,
   but if the type represents a physical interface, it is mandatory.
   The format of this string is device- and type-dependent.  The device
   uses the location string to identify the physical or logical entity
   that the configuration applies to.  For example, if a device has a
   single array of 8 ethernet ports, the location can be one of the
   strings "1" to "8".  As another example, if a device has N cards of M
   ports, the location can be on the form "n/m", such as "1/0".

I think that "location" is a poorly chosen label, a misnomer. This seems =
to be closer to an identifier than a locator. For example, some devices =
number slots left to right, and some number slots right to left :-) This =
does not answer "where" something is; I do not mean geo-location, but I =
strongly suggest getting more precision on how this leaf is called. For =
example, interface numbering, instance id, type identifier, etc.

3. Interfaces Data Model
=85
      +--rw interfaces
         +--rw interface [name]
            +--rw =85

Is there a specific reason why there is no lead with the interface's =
MTU? It is quite important from a routing perspective for some =
protocols. MTU is not included even in the examples of ethernet-specific =
data models augmenting this base spec and appendices, which leaves it a =
bit underspecified=85

General:

As a general major comment: it is not clear how general or how specific =
this definition and document is.

In terms of the definition, this definition does not include information =
that applies to all interfaces (e.g., MTU), but it does include very =
specific non-general things like is_promiscuous. What is the information =
model on which this data model stands? If there was not RFC 2863, would =
a leaf be defined as ifPromiscuousMode or phys-address? Or would that =
belong in an ethernet-specific module?

In terms of the examples, basically all examples are some form of =
ethernet interface. For a document that aims at being general for =
managing network interfaces, this choice seems not inclusive.


Minor Issues:

2. Objectives
...
   o  The data model should support the pre-provisioning of interface
      configuration, i.e., it should be possible to configure an
      interface whose physical interface hardware is not present on the
      device.  It is recommended that devices that support dynamic
      addition and removal of physical interfaces also support pre-
      provisioning.

It is interesting that these design criteria do not call out the =
applicability to "physical" and "virtual" interfaces. Moreover, the text =
above seems to imply that the only "dynamic creation and deletion" of =
interfaces happens with the "addition and removal of physical =
interfaces" and does not call out tunnels, loopbacks, virtuals, and =
other logical entities instantiated as "interfaces".

3. Interfaces Data Model

Do some of the strings need to be described as maximum access parameter? =
Some rw attributes cannot be changed in all practical terms. The "type" =
leaf is RW. However, with what applicability (different speeds of =
"ethernet", different serials, how can it be changed)?


3. Interfaces Data Model
=85
            +--rw enabled?                    boolean
            +--ro oper-status?                enumeration

I would have expected these two not to be optional ("?").

3. Interfaces Data Model
=85
      +--rw interfaces
         +--rw interface [name]
            +--ro statistics
               +--ro in-discards?          yang:counter32
               +--ro in-errors?            yang:counter32
               +--ro in-unknown-protos?    yang:counter32
               +--ro out-discards?         yang:counter32
               +--ro out-errors?           yang:counter32

It seems like some statistics are counter32 while others are counter64. =
The ones that are counter64 seem to coincide with the ones that have HC =
(High Capacity) counters in RFC 2863 (this is from memory, might be =
incorrect). Is that the reason? Is there any (other) specific reason why =
these are 32-bit counters while the rest of the statistics are 64 bit =
counters? I do wonder, however, if these should still be defined here as =
64 bit...

4. Relationship to the IF-MIB
=85
   The following table lists the YANG data nodes with corresponding
   objects in the IF-MIB.
...
               Mapping of YANG data nodes to IF-MIB objects

This section explains how name cannot always map to ifName. However, the =
table shows a 1:1 mapping of name <-> ifName. I suggest marking with a =
footnote or "*" the elements that might not always may 1:1.

For example, "enabled" also cannot map to ifAdminStatus. "enabled" is a =
boolean, and ifAdminStatus is an INTEGER with at least 3 values =
specified (up, down, testing).=20

In summary, which ones map 1:1 and which ones do not?

4. Relationship to the IF-MIB
=85
       | description                      | ifAlias                |

This is also a bit confusing -- the "description" maps to the ifAlias, =
and nothing maps to ifDescr.


4. Relationship to the IF-MIB

   The IF-MIB also defines the writable object ifPromiscuousMode.  Since
   this object typically is not a configuration object, it is not mapped
   to the "ietf-interfaces" module.

ifPromiscuousMode can actually be changed in many cases. Is that the =
only reason why attributes are being mapped to the "ietf-interfaces" =
module or not?

5. Interfaces YANG Module
...
     organization
       "IETF NETMOD (NETCONF Data Modeling Language) Working Group";

     contact
       "WG Web:   
        WG List:  

        WG Chair: David Kessens
                  

Does the definition of the module, anchoring on a Working Group, put =
requirements or constraints on the existence of netmod? Meaning: what =
happens to these pointers when the WG ceases to exist, and the maling =
list is locked? Perhaps this is the usual way of defining contact for =
the YANG modules, but I suspect a time invariant pointer would help.

=85
         leaf name {
           type string;
           description
             "The name of the interface.

              A device MAY restrict the allowed values for this leaf,
              possibly depending on the type and location.

              If the device allows arbitrarily named interfaces, the
              feature 'arbitrary-names' is advertised.

              This leaf MAY be mapped to ifName by an implementation.
              Such an implementation MAY restrict the allowed values for
              this leaf so that it matches the restrictions of ifName.
              If a NETCONF server that implements this restriction is
              sent a value that doesn't match the restriction, it MUST
              reply with an rpc-error with the error-tag
              'invalid-value'.";

Should the description of a YANG leaf be tied to NETCONF? Or are there =
potential uses outside NETCONF? Please note that although this comment =
is made once, it applies to all the descriptions that say "If a NETCONF =
server=85", as there are quite a number of these.

         leaf location {
           type string;
           description
             "The device-specific location of the interface of a
              particular type.  The format of the location string

As mentioned above, this is not a "location".

         leaf phys-address {
           type yang:phys-address;
           config false;
           description
             "The interface's address at its protocol sub-layer.  For
             example, for an 802.x interface, this object normally
             contains a MAC address.  The interface's media-specific
             modules must define the bit and byte ordering and the
             format of the value of this object.  For interfaces that do
             not have such an address (e.g., a serial line), this node
             is not present.";
           reference
             "RFC 2863: The Interfaces Group MIB - ifPhysAddress";
         }

Just by reading the description of this leaf, shouldn't this be part of =
an augmentation type-specific module? For example, for an Ethernet =
interface module, instead of the main YANG interface management =
top-level. Meaning: this specific leaf, by definition, cannot be =
generically specified to what it means for each type of interfaces. All =
the others can=85 if this cannot be specified outside a media-specific =
module, why define it here?

         leaf oper-status {
           type enumeration {
=85

The description of the leaf as well as the enum values for the =
oper-status seem to be a bit under-defined. For example, "Ready to pass =
packets" seems too literal from the MIB, while I believe there are more =
precise definitions. Also, the description is actually listing usage of =
values instead of a real description.

7. Security Considerations


   The YANG module defined in this memo is designed to be accessed via
   the NETCONF protocol [RFC6241].  The lowest NETCONF layer is the
   secure transport layer and the mandatory-to-implement secure
   transport is SSH [RFC6242].

Are there security considerations for other aspects of this language =
definition? For example, what if YANG is used via a different method? =
What about storage of the data? What about AAA aspects for RW or RO =
leafs?


9.1. Normative References

   [I-D.ietf-netmod-iana-if-type]

This document points normatively to draft-ietf-netmod-iana-if-type-02. =
However, there are four additional revisions to the document and a most =
recent that is a year later than draft-ietf-netmod-iana-if-type-02. =
While things should be in sync given a common author and a hard =
dependency, just calling it out here since there are a few differences =
between those revisions of the normative reference:
=
http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-netmod-iana-if-type-06.txt=
&url1=3Ddraft-ietf-netmod-iana-if-type-02.txt

Appendix A. Example: Ethernet Interface Module

Do these appendices need to explicitly say that are non-normative? I =
would add a one-liner about it.

Appendix A. Example: Ethernet Interface Module

This applies to all appendices. I find it a bit incomplete that a =
specification for a language for "Interface Management" chose to ignore =
the richness of types of interfaces to show in the appendices :-) =
Basically, all of the ten (I think) different examples in the appendices =
are about Ethernet interfaces. While there is nothing underspecified, it =
is under-exemplified. How would a serial interface with sub interfaces =
loop like? How about a GRE Tunnel interface? Or a point-to-point =
satellite? Or a 3G interface? Or =85=20


Nits:=20

2. Objectives
...
   o  The model must support interface layering, both simple layering
      where one interface is layered on top of exactly one other
      interface, and more complex scenarios where one interface is
      aggregated over N other interfaces, or when N interfaces are
      multiplexed over one other interface.

This is a nit: are "aggregated" and "multiplexed" the right words here? =
I believe I understand what is meant, but at the same time, it's not =
clear how "one interface" can be "aggregated" (i.e., aggregate a =
plurality/collection of elements into one). Perhaps: "and more complex =
scenarios where one interface results from the aggregation of N other =
interfaces, or when N interfaces are multiplexed over one other =
interface."?

5. Interfaces YANG Module

         leaf oper-status {
           type enumeration {
=85

The description of the leaf as well as the enum values for the =
oper-status seem to be a bit under-defined. For example, "Ready to pass =
packets" seems too literal from the MIB, while I believe there are more =
precise definitions (s/packets/traffic/ at least?). Also, the =
description is actually listing usage of values instead of a real =
description.


I hope these are clear and useful!

Thank you,

Carlos Pignataro.


--Apple-Mail=_928E38FA-CF0B-4B38-B59F-541EF53AF88B
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-----
Version: GnuPG/MacGPG2 v2.0.19 (Darwin)

iEYEARECAAYFAlF+ko0ACgkQtfDPGTp3USzkIgCfXK+mBxl7Xea+SUQidSrOSdXp
WKEAn3pQrDuA4eHTI0WQlF87ivPEIM6a
=kzhO
-----END PGP SIGNATURE-----

--Apple-Mail=_928E38FA-CF0B-4B38-B59F-541EF53AF88B--

From cpignata@cisco.com  Mon Apr 29 16:03:11 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDB9021F9820; Mon, 29 Apr 2013 16:02:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.599
X-Spam-Level: 
X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d8+-szYpOFDO; Mon, 29 Apr 2013 16:02:54 -0700 (PDT)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 07FF521F9B8D; Mon, 29 Apr 2013 16:02:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=24255; q=dns/txt; s=iport; t=1367276566; x=1368486166; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=SkbFE1fhTSYzqgsjY7QUFwEgGqAF9WhZAKLxLPAeRrE=; b=TY8MvYLHTobxe2dd0KAzPPtcJ4u7XwIWX6m2fkbca5q+Mb8+1MobwOT2 /J4vu5MUDRGtHDtnLf74/7Rkm1+27DlRYlZSsginlyseV3eRoptFiygtD edVS3wSOuvg9OA2Xr/UMNGAXyHvOteueG9HeIkZ5vxD6UXSxocvRcXGUM k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhcFAGj6flGtJV2a/2dsb2JhbABIAgiDBzaDN7sYgQYWdIIfAQEBAwEaBwEFSwcFCwIBCA4GBAEDBgUYAgMCMhQRAgQOAwIIAYgHBgyTDpsDAZBwgSCMNggGCnkCMQIFZIFVNWEDmESQBIMEDUCBKgEfHg
X-IronPort-AV: E=Sophos;i="4.87,576,1363132800"; d="scan'208";a="204308915"
Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-1.cisco.com with ESMTP; 29 Apr 2013 23:02:45 +0000
Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r3TN2idq028497 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 29 Apr 2013 23:02:44 GMT
Received: from xmb-aln-x02.cisco.com ([169.254.5.192]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.02.0318.004; Mon, 29 Apr 2013 18:02:44 -0500
From: "Carlos Pignataro (cpignata)" 
To: Martin Bjorklund 
Thread-Topic: RtgDir review: draft-ietf-netmod-interfaces-cfg-10.txt
Thread-Index: AQHORO7C2y3SdVUEW027VIOCZsJnvJjt/0GAgAAmAoA=
Date: Mon, 29 Apr 2013 23:02:44 +0000
Message-ID: <95067C434CE250468B77282634C96ED322AF7636@xmb-aln-x02.cisco.com>
References: <95067C434CE250468B77282634C96ED322AF32F4@xmb-aln-x02.cisco.com> <20130429.224641.08727383.mbj@tail-f.com>
In-Reply-To: <20130429.224641.08727383.mbj@tail-f.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.117.115.50]
Content-Type: text/plain; charset="iso-2022-jp"
Content-ID: <156DB78B2B75754DBA6CAD1DA12DBE58@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailman-Approved-At: Tue, 30 Apr 2013 00:33:14 -0700
Cc: "" , "" , "" , "" 
Subject: Re: [netmod] RtgDir review: draft-ietf-netmod-interfaces-cfg-10.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 29 Apr 2013 23:03:11 -0000

Hi, Martin,

Thanks for the quick response! Please find some follow-ups inline. I believ=
e some items are closed, but others need further discussion.

On Apr 29, 2013, at 4:46 PM, Martin Bjorklund  wrote:

> Hi,
>=20
> Thank you for your detailed review!  Comments inline.
>=20
> "Carlos Pignataro (cpignata)"  wrote:
>> Hello,
>>=20
>> I have been selected as the Routing Directorate reviewer for this draft.=
 The
>> Routing Directorate seeks to review all routing or routing-related draft=
s as
>> they pass through IETF last call and IESG review, and sometimes on speci=
al
>> request. The purpose of the review is to provide assistance to the Routi=
ng
>> ADs. For more information about the Routing Directorate, please see
>> http://www.ietf.org/iesg/directorate/routing.html
>>=20
>> Although these comments are primarily for the use of the Routing ADs, it=
 would
>> be helpful if you could consider them along with any other IETF Last Cal=
l
>> comments that you receive, and strive to resolve them through discussion=
 or by
>> updating the draft.
>>=20
>> Document: draft-ietf-netmod-interfaces-cfg-10.txt
>> Reviewer: Carlos Pignataro
>> Review Date: 01 May 2013
>> IETF LC End Date: 03 May 2013
>> Intended Status: Proposed Standard
>>=20
>> Summary:
>>=20
>> I have some minor concerns about this document that I think should be re=
solved
>> before publication.
>>=20
>> Comments:
>>=20
>> This document is very well written, and sensible. It certainly achieves =
what
>> its Abstract sets up to do, cleanly. Thank you for writing it!
>>=20
>> However, I do believe that there are a few set of gaps that need to be r=
esolved
>> before publication. I identify some localized major issues below. Since =
I do
>> not have context on some decisions that shaped the document, an explanat=
ion of
>> the rational might suffice if sensible. Other of the identified issues, =
I
>> believe, will require modifications or textual clarifications. In partic=
ular, I
>> have a couple general concerns, about the generality of the data model d=
efined
>> in this document, details below.
>>=20
>> I hope these review comments are clear and useful!
>>=20
>>=20
>> Major Issues:
>>=20
>> 3. Interfaces Data Model
>> =1B$B!D=1B(B
>>            +--ro if-index?                   int32
>>=20
>> The "?" indicates that the lead is optional. From a routing perspective,=
 the
>> if-index plays an important role when for example the network layer addr=
ess
>> does not identify a specific interface (e.g., IP unnumbered), or when th=
ere is
>> no network layer address (LAG member, etc.). Why is this optional? In wh=
ich
>> case you envision it would not be present?
>=20
> I think you are right; this leaf should be mandatory.  This works
> since it has an 'if-feature' statement.
>=20

Thanks. Even if it works because of the clause, I'd make this mandatory.

> But I would like to understand what role ifIndex plays - do you have
> any pointers?
>=20

Sure, you can grep for ifIndex in RFC 2328 (OSPFv2), e.g., Section 12.4.1.1=
., or RFC 5837.

>> Additionally, a stronger relationship or at least a more detailed descri=
ption
>> of the relationship with ifIndex would help interoperable implementation=
s. Does
>> this "if-index" leaf follow ifIndex if it changes upon reload of interfa=
ce
>> recreation? It seems from the definition that it is the same?
>=20
> Yes, that is the intention.  The description says:
>=20
>           The ifIndex value for the ifEntry represented by this
>           interface.
>=20

Ack.=20

>> 3. Interfaces Data Model
>> =1B$B!D=1B(B
>>            +--rw location?                   string
>> ...
>> 3.1. The interface List
>> =1B$B!D=1B(B
>>   The "location" leaf is a string.  It is optional in the data model,
>>   but if the type represents a physical interface, it is mandatory.
>>   The format of this string is device- and type-dependent.  The device
>>   uses the location string to identify the physical or logical entity
>>   that the configuration applies to.  For example, if a device has a
>>   single array of 8 ethernet ports, the location can be one of the
>>   strings "1" to "8".  As another example, if a device has N cards of M
>>   ports, the location can be on the form "n/m", such as "1/0".
>>=20
>> I think that "location" is a poorly chosen label, a misnomer. This seems=
 to be
>> closer to an identifier than a locator. For example, some devices number=
 slots
>> left to right, and some number slots right to left :-)
>=20
> Correct, and we do not try to get into this at all.  Some
> devices has 2 ports called A and B, and some have chassis of cards
> with rows of ports...
>=20
>> This does not answer
>> "where" something is; I do not mean geo-location, but I strongly suggest
>> getting more precision on how this leaf is called. For example, interfac=
e
>> numbering, instance id, type identifier, etc.
>=20
> The intention is really to be "where" the port is.  It is not intended
> to be a virtual id.  If the operator plugs in a cable in a certain
> port, he has to know how to configure this port so there must be
> something in the config that connects to the physical port.  We use
> the name "location" for this purpose.

Thanks for the explanation. While I appreciate (and I agree) that you do no=
t get into interpreting or parsing the syntax of the field, I still think i=
t is not a "location".

I believe there is still an underlying assumption that the language is defi=
ned for the physical world. If you have an Ethernet1/0, versus an Ethernet1=
/2, that identifies (not locates) which interface. Yes, you can use that to=
 physically find them. But what if you have a "loopback123" vs "loopback112=
358 or a "Serial1/4:5.123"? I do not think we can "locate" the loopback, or=
 the subinterface.

If the operator creates a "loopback", "Tunnel", or virtual interface, he or=
 she does not need to physically locate it.

I believe that labeling the leaf as "location" can be harmful as it implies=
 a specific meaning and shows assumptions.=20

>=20
>> 3. Interfaces Data Model
>> =1B$B!D=1B(B
>>      +--rw interfaces
>>         +--rw interface [name]
>>            +--rw =1B$B!D=1B(B
>>=20
>> Is there a specific reason why there is no lead with the interface's MTU=
? It is
>> quite important from a routing perspective for some protocols. MTU is no=
t
>> included even in the examples of ethernet-specific data models augmentin=
g this
>> base spec and appendices, which leaves it a bit underspecified=1B$B!D=1B=
(B
>=20
> The mtu is specified in an accompanying document draft-ietf-netmod-ip.
>=20

What draft-ietf-netmod-ip describes is the network-layer IPv4 MTU and IPv6 =
MTU. It does not describe the interface MTU. If that interface is used to r=
un IS-IS, or to run MPLS, what is the MTU? It's neither the IPv4 MTU nor th=
e IPv6 MTU.

>=20
>> General:
>>=20
>> As a general major comment: it is not clear how general or how specific =
this
>> definition and document is.
>=20
> It is a generic model. We tried to capture the intention in the
> Introduction:
>=20
>  This document defines a YANG ^RFC6020^ data model for the management
>  of network interfaces. It is expected that interface type specific
>  data models augment the generic interfaces data model defined in
>  this document.

This is great, I agree with this intention and scope. My comment however wa=
s that the examples and some leafs specified make it more specific for some=
 interfaces than others.

>=20
>> In terms of the definition, this definition does not include information=
 that
>> applies to all interfaces (e.g., MTU), but it does include very specific
>> non-general things like is_promiscuous.
>=20
> Actually, ifPromiscuousMode is not part of this model.
>=20

You are correct, thank you. Sorry my bad.

>> What is the information model on which
>> this data model stands? If there was not RFC 2863, would a leaf be defin=
ed as
>> ifPromiscuousMode or phys-address? Or would that belong in an ethernet-s=
pecific
>> module?
>=20
> You are right that phys-address might not have been included.
>=20

OK, thanks. Do you mean that you will be removing it?

>> In terms of the examples, basically all examples are some form of ethern=
et
>> interface. For a document that aims at being general for managing networ=
k
>> interfaces, this choice seems not inclusive.
>>=20
>>=20
>> Minor Issues:
>>=20
>> 2. Objectives
>> ...
>>   o  The data model should support the pre-provisioning of interface
>>      configuration, i.e., it should be possible to configure an
>>      interface whose physical interface hardware is not present on the
>>      device.  It is recommended that devices that support dynamic
>>      addition and removal of physical interfaces also support pre-
>>      provisioning.
>>=20
>> It is interesting that these design criteria do not call out the applica=
bility
>> to "physical" and "virtual" interfaces. Moreover, the text above seems t=
o imply
>> that the only "dynamic creation and deletion" of interfaces happens with=
 the
>> "addition and removal of physical interfaces" and does not call out tunn=
els,
>> loopbacks, virtuals, and other logical entities instantiated as "interfa=
ces".
>=20
> I think you are reading too much into the statement above.  It says
> that IF you support addition and removal of physical interfaces, then
> ...  This does NOT mean that devices cannot support tunnels, loobacks
> etc.  But maybe I misunderstood your point.
>=20

I was not clear. Yes, that is an important statement. I was suggesting that=
 an addition of something like this would help:

"o The dat amodel should support virtual interfaces as well as physical int=
erfaces blah blah".

>=20
>> 3. Interfaces Data Model
>>=20
>> Do some of the strings need to be described as maximum access parameter?=
 Some
>> rw attributes cannot be changed in all practical terms. The "type" leaf =
is
>> RW. However, with what applicability (different speeds of "ethernet", di=
fferent
>> serials, how can it be changed)?
>=20
> Implementations that cannot for some reason support changing certain
> parameters simply won't support it.  But that's not a reason for the
> standard to not support it.  In general, there is nothing wrong in
> changing the type of an interface in the configuration - if there's
> physical hardware that doesn't match the type at the moment, the
> oper-status will be 'not-present'.

Fair enough. Thank you.

>=20
>> 3. Interfaces Data Model
>> =1B$B!D=1B(B
>>            +--rw enabled?                    boolean
>>            +--ro oper-status?                enumeration
>>=20
>> I would have expected these two not to be optional ("?").
>=20
> Actually, 'enabled' has a default value, so that's why it is marked as
> optional.  For oper-status I believe you are right; since it has the
> state 'unknown' it does not have to be optional.  I think we should
> change this.

Perfect. Thank you.

>=20
>> 3. Interfaces Data Model
>> =1B$B!D=1B(B
>>      +--rw interfaces
>>         +--rw interface [name]
>>            +--ro statistics
>>               +--ro in-discards?          yang:counter32
>>               +--ro in-errors?            yang:counter32
>>               +--ro in-unknown-protos?    yang:counter32
>>               +--ro out-discards?         yang:counter32
>>               +--ro out-errors?           yang:counter32
>>=20
>> It seems like some statistics are counter32 while others are counter64. =
The
>> ones that are counter64 seem to coincide with the ones that have HC (Hig=
h
>> Capacity) counters in RFC 2863 (this is from memory, might be incorrect)=
. Is
>> that the reason?
>=20
> Yes.
>=20

OK.

>> Is there any (other) specific reason why these are 32-bit
>> counters while the rest of the statistics are 64 bit counters? I do wond=
er,
>> however, if these should still be defined here as 64 bit...
>=20
> The idea was that 64 bits are probably not needed for these counters.
>=20

I tend to disagree with this. But as long as the WG explicitly discussed it=
 (as opposed to blindly carry it over from the MIB).

>> 4. Relationship to the IF-MIB
>> =1B$B!D=1B(B
>>   The following table lists the YANG data nodes with corresponding
>>   objects in the IF-MIB.
>> ...
>>               Mapping of YANG data nodes to IF-MIB objects
>>=20
>> This section explains how name cannot always map to ifName. However, the=
 table
>> shows a 1:1 mapping of name <-> ifName. I suggest marking with a footnot=
e or
>> "*" the elements that might not always may 1:1.
>>=20
>> For example, "enabled" also cannot map to ifAdminStatus. "enabled" is a
>> boolean, and ifAdminStatus is an INTEGER with at least 3 values specifie=
d (up,
>> down, testing).
>>=20
>> In summary, which ones map 1:1 and which ones do not?
>=20
> This table is supposed to be an overview.  I think I would prefer to
> add a sentence that says something like "For details about thae
> mappings, please see the corresponding definition in the YANG module".

No. I think that the table is a bit misleading when it says it described th=
e "Mapping of YANG data nodes to IF-MIB objects", but some of these are rel=
ated but do not really map.

>=20
>> 4. Relationship to the IF-MIB
>> =1B$B!D=1B(B
>>       | description                      | ifAlias                |
>>=20
>> This is also a bit confusing -- the "description" maps to the ifAlias, a=
nd
>> nothing maps to ifDescr.
>=20
> Yes, this is b/c ifDescr is a read-only object defined as:
>=20
>            This string should include the name of the
>            manufacturer, the product name and the version of the
>            interface hardware/software.
>=20
> The only reason the "description" leaf is mapped to ifAlias is b/c
> this is what many implementations do.  So we wanted to point out the
> differences in the value space for these objects so that implementers
> are aware of this.
>=20

Thanks for this clarification.

>=20
>> 4. Relationship to the IF-MIB
>>=20
>>   The IF-MIB also defines the writable object ifPromiscuousMode.  Since
>>   this object typically is not a configuration object, it is not mapped
>>   to the "ietf-interfaces" module.
>>=20
>> ifPromiscuousMode can actually be changed in many cases.
>=20
> Right, but it is not typically a configuration parameter.
>=20
>> Is that the only
>> reason why attributes are being mapped to the "ietf-interfaces" module o=
r not?
>=20
> I wouldn't say that, bur for this particular object, the WG felt it
> should be left out.
>=20
>=20
>> 5. Interfaces YANG Module
>> ...
>>     organization
>>       "IETF NETMOD (NETCONF Data Modeling Language) Working Group";
>>=20
>>     contact
>>       "WG Web:   
>>        WG List:  
>>=20
>>        WG Chair: David Kessens
>>                  
>>=20
>> Does the definition of the module, anchoring on a Working Group, put
>> requirements or constraints on the existence of netmod? Meaning: what ha=
ppens
>> to these pointers when the WG ceases to exist, and the maling list is lo=
cked?
>> Perhaps this is the usual way of defining contact for the YANG modules, =
but I
>> suspect a time invariant pointer would help.
>=20
> This also seems to be the usual way of defining contact info in
> MIBs...
>=20

But not for others. Is there value in defining the contact this way? I am j=
ust asking.

>> =1B$B!D=1B(B
>>         leaf name {
>>           type string;
>>           description
>>             "The name of the interface.
>>=20
>>              A device MAY restrict the allowed values for this leaf,
>>              possibly depending on the type and location.
>>=20
>>              If the device allows arbitrarily named interfaces, the
>>              feature 'arbitrary-names' is advertised.
>>=20
>>              This leaf MAY be mapped to ifName by an implementation.
>>              Such an implementation MAY restrict the allowed values for
>>              this leaf so that it matches the restrictions of ifName.
>>              If a NETCONF server that implements this restriction is
>>              sent a value that doesn't match the restriction, it MUST
>>              reply with an rpc-error with the error-tag
>>              'invalid-value'.";
>>=20
>> Should the description of a YANG leaf be tied to NETCONF? Or are there
>> potential uses outside NETCONF?
>=20
> Currently the only standardized usage is NETCONF.  But vendors use
> YANG for other purposes, and there's an individual draft that use YANG
> for a RESTful api.
>=20
> But the sentence really just specifies what a NETCONF server would
> do.  It would be difficult to write this in a generic way, and at the
> same time it is useful to specify this for NETCONF implementations.
>=20

I still find it a bit odd that the description intertwines protocol directi=
ves.=20

>=20
>> Please note that although this comment is made
>> once, it applies to all the descriptions that say "If a NETCONF server=
=1B$B!D=1B(B", as
>> there are quite a number of these.
>=20
> Yes, but it is only used when we specify the NETCONF protocol behavior.
>=20
>>         leaf location {
>>           type string;
>>           description
>>             "The device-specific location of the interface of a
>>              particular type.  The format of the location string
>>=20
>> As mentioned above, this is not a "location".
>>=20
>>         leaf phys-address {
>>           type yang:phys-address;
>>           config false;
>>           description
>>             "The interface's address at its protocol sub-layer.  For
>>             example, for an 802.x interface, this object normally
>>             contains a MAC address.  The interface's media-specific
>>             modules must define the bit and byte ordering and the
>>             format of the value of this object.  For interfaces that do
>>             not have such an address (e.g., a serial line), this node
>>             is not present.";
>>           reference
>>             "RFC 2863: The Interfaces Group MIB - ifPhysAddress";
>>         }
>>=20
>> Just by reading the description of this leaf, shouldn't this be part of =
an
>> augmentation type-specific module? For example, for an Ethernet interfac=
e
>> module, instead of the main YANG interface management top-level. Meaning=
: this
>> specific leaf, by definition, cannot be generically specified to what it=
 means
>> for each type of interfaces. All the others can=1B$B!D=1B(B if this cann=
ot be specified
>> outside a media-specific module, why define it here?
>=20
> See above - I think the reason is the relation to ifPhysAddress.
>=20

THe question still stands -- if this is not a generic interface parameter, =
and instead is specific to some types of interfaces, should it be defined h=
ere or in type-specific submodules?

>>=20
>>         leaf oper-status {
>>           type enumeration {
>> =1B$B!D=1B(B
>>=20
>> The description of the leaf as well as the enum values for the oper-stat=
us seem
>> to be a bit under-defined. For example, "Ready to pass packets" seems to=
o
>> literal from the MIB
>=20
> Yes.
>=20
>> while I believe there are more precise definitions.  Also,
>> the description is actually listing usage of values instead of a real
>> description.
>>=20
>> 7. Security Considerations
>>=20
>>=20
>>   The YANG module defined in this memo is designed to be accessed via
>>   the NETCONF protocol [RFC6241].  The lowest NETCONF layer is the
>>   secure transport layer and the mandatory-to-implement secure
>>   transport is SSH [RFC6242].
>>=20
>> Are there security considerations for other aspects of this language
>> definition? For example, what if YANG is used via a different method? Wh=
at
>> about storage of the data? What about AAA aspects for RW or RO leafs?
>=20
> The WG recently added a note about AAA aspects to the Security
> Considerations template for YANG modules.  I will update this document
> as well with the new text.

Thank you.

>=20
>> 9.1. Normative References
>>=20
>>   [I-D.ietf-netmod-iana-if-type]
>>=20
>> This document points normatively to draft-ietf-netmod-iana-if-type-02. H=
owever,
>> there are four additional revisions to the document and a most recent th=
at is a
>> year later than draft-ietf-netmod-iana-if-type-02. While things should b=
e in
>> sync given a common author and a hard dependency, just calling it out he=
re
>> since there are a few differences between those revisions of the normati=
ve
>> reference:
>> http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-netmod-iana-if-type-06.t=
xt&url1=3Ddraft-ietf-netmod-iana-if-type-02.txt
>=20
> These documents are advanced together; but you are right, the
> reference is pretty old.  I simply forgot to update it.
>=20

Thank you.

>=20
>> Appendix A. Example: Ethernet Interface Module
>>=20
>> Do these appendices need to explicitly say that are non-normative? I wou=
ld add
>> a one-liner about it.
>=20
> Ok... but are examples ever normative?

Not typically. I was just suggesting demarcating normative vs. informative =
chunks of text.

>=20
>> Appendix A. Example: Ethernet Interface Module
>>=20
>> This applies to all appendices. I find it a bit incomplete that a specif=
ication
>> for a language for "Interface Management" chose to ignore the richness o=
f types
>> of interfaces to show in the appendices :-) Basically, all of the ten (I=
 think)
>> different examples in the appendices are about Ethernet interfaces. Whil=
e there
>> is nothing underspecified, it is under-exemplified. How would a serial
>> interface with sub interfaces loop like? How about a GRE Tunnel interfac=
e? Or a
>> point-to-point satellite? Or a 3G interface? Or =1B$B!D=1B(B
>=20
> It is always tricky with examples... In this case we wanted to
> examplify different features of the model, and we picked examples that
> build on each other.
>=20
>> Nits:=20
>>=20
>> 2. Objectives
>> ...
>>   o  The model must support interface layering, both simple layering
>>      where one interface is layered on top of exactly one other
>>      interface, and more complex scenarios where one interface is
>>      aggregated over N other interfaces, or when N interfaces are
>>      multiplexed over one other interface.
>>=20
>> This is a nit: are "aggregated" and "multiplexed" the right words here? =
I
>> believe I understand what is meant, but at the same time, it's not clear=
 how
>> "one interface" can be "aggregated" (i.e., aggregate a plurality/collect=
ion of
>> elements into one). Perhaps: "and more complex scenarios where one inter=
face
>> results from the aggregation of N other interfaces, or when N interfaces=
 are
>> multiplexed over one other interface."?
>=20
> Yes, this is much better.  Thanks for the suggestion!
>=20

:-)

>=20
>> 5. Interfaces YANG Module
>>=20
>>         leaf oper-status {
>>           type enumeration {
>> =1B$B!D=1B(B
>>=20
>> The description of the leaf as well as the enum values for the oper-stat=
us seem
>> to be a bit under-defined. For example, "Ready to pass packets" seems to=
o
>> literal from the MIB, while I believe there are more precise definitions
>> (s/packets/traffic/ at least?). Also, the description is actually listin=
g usage
>> of values instead of a real description.
>=20
> [this seems to be a duplicate comment]
>=20

Yes, sorry. Are you planning on updating the description of the values?

>=20
>> I hope these are clear and useful!
>=20
> It was; thank you!
>=20

I am glad about it. Thank you for your throughout responses.

-- Carlos.

>=20
> /martin
>=20


From j.schoenwaelder@jacobs-university.de  Tue Apr 30 00:49:38 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 671C921F9C31 for ; Tue, 30 Apr 2013 00:49:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.249
X-Spam-Level: 
X-Spam-Status: No, score=-103.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4snC1SDnfhLr for ; Tue, 30 Apr 2013 00:49:34 -0700 (PDT)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id A845321F8ECE for ; Tue, 30 Apr 2013 00:49:33 -0700 (PDT)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0899220C12; Tue, 30 Apr 2013 09:49:33 +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 fy_jifbDRYnl; Tue, 30 Apr 2013 09:49: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 3D46D20BEB; Tue, 30 Apr 2013 09:49:32 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 0CC5A25E9943; Tue, 30 Apr 2013 09:49:30 +0200 (CEST)
Date: Tue, 30 Apr 2013 09:49:30 +0200
From: Juergen Schoenwaelder 
To: Martin Bjorklund 
Message-ID: <20130430074930.GA46852@elstar.local>
Mail-Followup-To: Martin Bjorklund , netmod@ietf.org
References: <20130430.092945.981969607302073955.mbj@tail-f.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20130430.092945.981969607302073955.mbj@tail-f.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: netmod@ietf.org
Subject: Re: [netmod] interface-cfg issues
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 30 Apr 2013 07:49:38 -0000

On Tue, Apr 30, 2013 at 09:29:45AM +0200, Martin Bjorklund wrote:
> Hi,
> 
> The Routing Directorate review of
> draft-ietf-netmod-interfaces-cfg-10.txt
> brought up a couple of issues that I think the WG needs to dicsuss.
> 
> (The original mail is not in the list archive, but my reply is found
> here: 
> http://www.ietf.org/mail-archive/web/netmod/current/msg08031.html)
> 
> 
> 1)  The name "location"
> 
> > > >> 3. Interfaces Data Model
> > > >> …
> > > >>            +--rw location?                   string
> > > >> ...
> > > >> 3.1. The interface List
> > > >> …
> > > >>   The "location" leaf is a string.  It is optional in the data model,
> > > >>   but if the type represents a physical interface, it is mandatory.
> > > >>   The format of this string is device- and type-dependent.  The device
> > > >>   uses the location string to identify the physical or logical entity
> > > >>   that the configuration applies to.  For example, if a device has a
> > > >>   single array of 8 ethernet ports, the location can be one of the
> > > >>   strings "1" to "8".  As another example, if a device has N cards of M
> > > >>   ports, the location can be on the form "n/m", such as "1/0".
> > > >> 
> > > >> I think that "location" is a poorly chosen label, a misnomer. This
> > > >> seems to be
> > > >> closer to an identifier than a locator. For example, some devices
> > > >> number slots
> > > >> left to right, and some number slots right to left :-)
> > > > 
> > > > Correct, and we do not try to get into this at all.  Some
> > > > devices has 2 ports called A and B, and some have chassis of cards
> > > > with rows of ports...
> > > > 
> > > >> This does not answer
> > > >> "where" something is; I do not mean geo-location, but I strongly
> > > >> suggest
> > > >> getting more precision on how this leaf is called. For example,
> > > >> interface
> > > >> numbering, instance id, type identifier, etc.
> > > > 
> > > > The intention is really to be "where" the port is.  It is not intended
> > > > to be a virtual id.  If the operator plugs in a cable in a certain
> > > > port, he has to know how to configure this port so there must be
> > > > something in the config that connects to the physical port.  We use
> > > > the name "location" for this purpose.
> > > 
> > > Thanks for the explanation. While I appreciate (and I agree) that you
> > > do not get into interpreting or parsing the syntax of the field, I
> > > still think it is not a "location".
> > > 
> > > I believe there is still an underlying assumption that the language is
> > > defined for the physical world. If you have an Ethernet1/0, versus an
> > > Ethernet1/2, that identifies (not locates) which interface. Yes, you
> > > can use that to physically find them. But what if you have a
> > > "loopback123" vs "loopback112358 or a "Serial1/4:5.123"? I do not
> > > think we can "locate" the loopback, or the subinterface.
> > > 
> > > If the operator creates a "loopback", "Tunnel", or virtual interface,
> > > he or she does not need to physically locate it.
> > > 
> > > I believe that labeling the leaf as "location" can be harmful as it
> > > implies a specific meaning and shows assumptions.
> > 
> > Ok I think I understand your concern.  Personally, I think "location"
> > works also in this case, but we should pick a name that is as useful
> > as possible.  Let me bring this issue back to the WG.
> 
> 
> Any comments on this?
> 

My understanding is that location is primarily for physical network
interfaces. For logical interfaces, the location may not be defined.
This covers loopback, tunnel, and virtual interfaces. Perhaps all that
needs to be done is to state that for interfaces that do not have a
location like loopback interfaces, the location leaf will not exist.
 
> 2)  phys-address
> 
> >>         leaf phys-address {
> >>           type yang:phys-address;
> >>           config false;
> >>           description
> >>             "The interface's address at its protocol sub-layer.  For
> >>             example, for an 802.x interface, this object normally
> >>             contains a MAC address.  The interface's media-specific
> >>             modules must define the bit and byte ordering and the
> >>             format of the value of this object.  For interfaces that do
> >>             not have such an address (e.g., a serial line), this node
> >>             is not present.";
> >>           reference
> >>             "RFC 2863: The Interfaces Group MIB - ifPhysAddress";
> >>         }
> >> 
> >> Just by reading the description of this leaf, shouldn't this be
> >> part of an augmentation type-specific module? For example, for an
> >> Ethernet interface module, instead of the main YANG interface
> >> management top-level. Meaning: this specific leaf, by definition,
> >> cannot be generically specified to what it means for each type of
> >> interfaces. All the others can… if this cannot be specified outside
> >> a media-specific module, why define it here?
> 
> So the proposal from him is to remove this leaf.  I think it could
> stay, but we would probably not have added it if it wasn't part of
> ifTable...  Comments?

There are interfaces that do not have a physical address, e.g. the
loopback interface. For such interfaces, phys-address would not exist.
Are there interfaces that have a physical address that this object
can't represent properly? Sure, this object could be moved to
interface type specific data models. This provides the benefit of
coming up with more specific address types and representations at the
expense that there is no generic way to retrieve the physical address
of an arbitrary interface. Do we have any concrete experience that
ifPhysAddress does not work in the IF-MIB?

/js

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

From j.schoenwaelder@jacobs-university.de  Tue Apr 30 01:08:10 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E81C621F9A37 for ; Tue, 30 Apr 2013 01:08:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.925
X-Spam-Level: 
X-Spam-Status: No, score=-102.925 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id in4IJB-gsD37 for ; Tue, 30 Apr 2013 01:08:05 -0700 (PDT)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id E6EAD21F99DF for ; Tue, 30 Apr 2013 01:08:04 -0700 (PDT)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 785E920C24 for ; Tue, 30 Apr 2013 10:08:04 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 5ipWrRnxVYCy for ; Tue, 30 Apr 2013 10:08: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 C698B20C12 for ; Tue, 30 Apr 2013 10:08:03 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 86EB525E9BA6; Tue, 30 Apr 2013 10:08:03 +0200 (CEST)
Resent-From: Juergen Schoenwaelder 
Resent-Date: Tue, 30 Apr 2013 10:08:03 +0200
Resent-Message-ID: <20130430080803.GC46852@elstar.local>
Resent-To: netmod@ietf.org
Received: from hermes.jacobs-university.de (212.201.44.23) by SHUBCAS01.jacobs.jacobs-university.de (10.70.0.128) with Microsoft SMTP Server id 14.2.342.3; Mon, 29 Apr 2013 08:36:53 +0200
Received: from atlas2.jacobs-university.de (atlas2a.jacobs-university.de [212.201.44.15])	by hermes.jacobs-university.de (Postfix) with ESMTP id 55C6620BD7	for ; Mon, 29 Apr 2013 08:36:55 +0200 (CEST)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48])	by atlas2.jacobs-university.de (Postfix) with ESMTP id 4FE9065	for ; Mon, 29 Apr 2013 08:36:55 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Authentication-Results: demetrius3.jacobs-university.de (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=opendkim.org
Received: from atlas2a.jacobs-university.de ([212.201.44.15])	by localhost (demetrius3.jacobs-university.de [212.201.44.48]) (amavisd-new, port 10030) with ESMTP id viePWyaktmVQ for ; Mon, 29 Apr 2013 08:36:52 +0200 (CEST)
X-JacobsISPWhiteListed: No
X-policyd-weight: using cached result; rate: -6.1
Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30])	(using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested)	by atlas2a.jacobs-university.de (Postfix) with ESMTPS	for ; Mon, 29 Apr 2013 08:36:52 +0200 (CEST)
Received: from mx.ipv6.elandsys.com ([2001:470:f329:1::1]:50332 ident=root)	by grenache.tools.ietf.org with esmtp (Exim 4.80)	(envelope-from )	id 1UWhhf-0004KZ-RQ	for draft-ietf-netmod-rfc6021-bis.all@tools.ietf.org; Mon, 29 Apr 2013 08:36:49 +0200
Received: from SUBMAN.elandsys.com ([197.226.235.145])	(authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r3T6aK0S017956 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 28 Apr 2013 23:36:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1367217393; bh=aWp8PCMxDoEoNtGBOpYa0lKKWEERyw0seaCmWBW/eHg=; h=Date:To:From:Subject:Cc; b=B1XzKBXRArZDFabUq4olawm5k2yUJuIElMxF12jQhw2zVYDUuh8utiSSxvj60fGdh FQlYhAXU2cjGR2g2LpUlUu6DUgGD2nH4uTbqz8v84KQlbYtJWYeSTFGKfy3gEBKbqW 6Q+4WEdg+5ac4Qaw5CuVe1eSGaqhEP/Ktb/7orNo=
Message-ID: <6.2.5.6.2.20130428233426.0b62fed0@elandnews.com>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Sun, 28 Apr 2013 23:36:08 -0700
To: , 
From: Martin Thomson 
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-SA-Exim-Connect-IP: 2001:470:f329:1::1
X-SA-Exim-Rcpt-To: draft-ietf-netmod-rfc6021-bis.all@tools.ietf.org
X-SA-Exim-Mail-From: sm@elandsys.com
X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000)
X-SA-Exim-Scanned: Yes (on grenache.tools.ietf.org)
Resent-To: , , , 
X-MS-Exchange-Organization-AuthSource: SHUBCAS01.jacobs.jacobs-university.de
X-MS-Exchange-Organization-AuthAs: Anonymous
X-MS-Exchange-Organization-AVStamp-Mailbox: MSFTFF;1;0;0 0 0
MIME-Version: 1.0
Cc: iesg@ietf.org
Subject: [netmod] [appsdir] Fwd: APPSDIR review of draft-ietf-netmod-rfc6021-bis-01
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 30 Apr 2013 08:08:11 -0000

(Apologies, I have this habit of not including directorates on
directorate reviews.  Correcting this oversight.)

I have been selected as the Applications Area Directorate reviewer for
this draft (for background on appsdir, please see
http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate
).

Please resolve these comments along with any other Last Call comments
you may receive. Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-ietf-netmod-rfc6021-bis-01
Title: Common YANG Data Types
Reviewer: Martin Thomson
Review Date: 2013-04-29

Summary: This draft is ready for publication as a Proposed Standard
RFC.  I have some minor issues and questions.

This is some of the most readable code that I have seen.

Major Issues: none

Minor Issues:

Section 4:
There is an RFC that describes a canonical textual representation of
IPv6 addresses.  You should use that: RFC 5952.

domain-name doesn't mention RFC 5890 at all (5891 is cited, but not
used in the text).  I assume that these are LDH-labels:
http://tools.ietf.org/html/rfc5890#section-2.3.1 and that this
document should say as much.

Questions:

Section 3:
phys-address: why is this optionally empty?  Maybe explain why in the
document - value absent?
hex-string: why is this required to include at least one octet? The
text does not mention this at all, I tend to find lots of uses for
empty octet strings, so this seems odd.
xpath1.0: are we expected to infer that "context" includes document
and where the namespace prefixes are bound?

Section 4:
ipv6-address: that is a very short IPv6 pattern.  Is it provably
correct?  I only ask because I've had occasion to build a real
pattern, and it's very long (the following is based on the "official"
ABNF definition):

          
          
          
          
          
          
          
          
          
          
          
          
          
          

Nits: I didn't find anything at all, and the items that idnits found
were bogus, so it looks good.
_______________________________________________
appsdir mailing list
appsdir@ietf.org
https://www.ietf.org/mailman/listinfo/appsdir


From mbj@tail-f.com  Tue Apr 30 01:12:22 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3117021F9BDC for ; Tue, 30 Apr 2013 01:12:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.246
X-Spam-Level: 
X-Spam-Status: No, score=-2.246 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0p0DS1UEGCtl for ; Tue, 30 Apr 2013 01:12:16 -0700 (PDT)
Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id A4FF121F9BDF for ; Tue, 30 Apr 2013 01:12:15 -0700 (PDT)
Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id EBADF12008B7; Tue, 30 Apr 2013 10:12:13 +0200 (CEST)
Date: Tue, 30 Apr 2013 10:12:13 +0200 (CEST)
Message-Id: <20130430.101213.940183903512995864.mbj@tail-f.com>
To: j.schoenwaelder@jacobs-university.de
From: Martin Bjorklund 
In-Reply-To: <20130430074930.GA46852@elstar.local>
References: <20130430.092945.981969607302073955.mbj@tail-f.com> <20130430074930.GA46852@elstar.local>
X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=iso-2022-jp
Content-Transfer-Encoding: 7bit
Cc: netmod@ietf.org
Subject: Re: [netmod] interface-cfg issues
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 30 Apr 2013 08:12:22 -0000

Juergen Schoenwaelder  wrote:
> On Tue, Apr 30, 2013 at 09:29:45AM +0200, Martin Bjorklund wrote:
> > Hi,
> > 
> > The Routing Directorate review of
> > draft-ietf-netmod-interfaces-cfg-10.txt
> > brought up a couple of issues that I think the WG needs to dicsuss.
> > 
> > (The original mail is not in the list archive, but my reply is found
> > here: 
> > http://www.ietf.org/mail-archive/web/netmod/current/msg08031.html)
> > 
> > 
> > 1)  The name "location"
> > 
> > > > >> 3. Interfaces Data Model
> > > > >> $B!D(B
> > > > >>            +--rw location?                   string
> > > > >> ...
> > > > >> 3.1. The interface List
> > > > >> $B!D(B
> > > > >>   The "location" leaf is a string.  It is optional in the data model,
> > > > >>   but if the type represents a physical interface, it is mandatory.
> > > > >>   The format of this string is device- and type-dependent.  The device
> > > > >>   uses the location string to identify the physical or logical entity
> > > > >>   that the configuration applies to.  For example, if a device has a
> > > > >>   single array of 8 ethernet ports, the location can be one of the
> > > > >>   strings "1" to "8".  As another example, if a device has N cards of M
> > > > >>   ports, the location can be on the form "n/m", such as "1/0".
> > > > >> 
> > > > >> I think that "location" is a poorly chosen label, a misnomer. This
> > > > >> seems to be
> > > > >> closer to an identifier than a locator. For example, some devices
> > > > >> number slots
> > > > >> left to right, and some number slots right to left :-)
> > > > > 
> > > > > Correct, and we do not try to get into this at all.  Some
> > > > > devices has 2 ports called A and B, and some have chassis of cards
> > > > > with rows of ports...
> > > > > 
> > > > >> This does not answer
> > > > >> "where" something is; I do not mean geo-location, but I strongly
> > > > >> suggest
> > > > >> getting more precision on how this leaf is called. For example,
> > > > >> interface
> > > > >> numbering, instance id, type identifier, etc.
> > > > > 
> > > > > The intention is really to be "where" the port is.  It is not intended
> > > > > to be a virtual id.  If the operator plugs in a cable in a certain
> > > > > port, he has to know how to configure this port so there must be
> > > > > something in the config that connects to the physical port.  We use
> > > > > the name "location" for this purpose.
> > > > 
> > > > Thanks for the explanation. While I appreciate (and I agree) that you
> > > > do not get into interpreting or parsing the syntax of the field, I
> > > > still think it is not a "location".
> > > > 
> > > > I believe there is still an underlying assumption that the language is
> > > > defined for the physical world. If you have an Ethernet1/0, versus an
> > > > Ethernet1/2, that identifies (not locates) which interface. Yes, you
> > > > can use that to physically find them. But what if you have a
> > > > "loopback123" vs "loopback112358 or a "Serial1/4:5.123"? I do not
> > > > think we can "locate" the loopback, or the subinterface.
> > > > 
> > > > If the operator creates a "loopback", "Tunnel", or virtual interface,
> > > > he or she does not need to physically locate it.
> > > > 
> > > > I believe that labeling the leaf as "location" can be harmful as it
> > > > implies a specific meaning and shows assumptions.
> > > 
> > > Ok I think I understand your concern.  Personally, I think "location"
> > > works also in this case, but we should pick a name that is as useful
> > > as possible.  Let me bring this issue back to the WG.
> > 
> > 
> > Any comments on this?
> > 
> 
> My understanding is that location is primarily for physical network
> interfaces. For logical interfaces, the location may not be defined.
> This covers loopback, tunnel, and virtual interfaces. Perhaps all that
> needs to be done is to state that for interfaces that do not have a
> location like loopback interfaces, the location leaf will not exist.

So we should probably say that it is used *only* for physical
interfaces, not "primarily" - or is there a situation where it could
be used also for logical/virtual interfaces?  For example, for
loopbacks, you could theoretically use a plain number as the
location.  If we limit location to physical interfaces, you would have
to define a "number" leaf for loopbacks (in some other module).  But
it might be ok,

> > 2)  phys-address
> > 
> > >>         leaf phys-address {
> > >>           type yang:phys-address;
> > >>           config false;
> > >>           description
> > >>             "The interface's address at its protocol sub-layer.  For
> > >>             example, for an 802.x interface, this object normally
> > >>             contains a MAC address.  The interface's media-specific
> > >>             modules must define the bit and byte ordering and the
> > >>             format of the value of this object.  For interfaces that do
> > >>             not have such an address (e.g., a serial line), this node
> > >>             is not present.";
> > >>           reference
> > >>             "RFC 2863: The Interfaces Group MIB - ifPhysAddress";
> > >>         }
> > >> 
> > >> Just by reading the description of this leaf, shouldn't this be
> > >> part of an augmentation type-specific module? For example, for an
> > >> Ethernet interface module, instead of the main YANG interface
> > >> management top-level. Meaning: this specific leaf, by definition,
> > >> cannot be generically specified to what it means for each type of
> > >> interfaces. All the others can$B!D(B if this cannot be specified outside
> > >> a media-specific module, why define it here?
> > 
> > So the proposal from him is to remove this leaf.  I think it could
> > stay, but we would probably not have added it if it wasn't part of
> > ifTable...  Comments?
> 
> There are interfaces that do not have a physical address, e.g. the
> loopback interface. For such interfaces, phys-address would not exist.
> Are there interfaces that have a physical address that this object
> can't represent properly? Sure, this object could be moved to
> interface type specific data models. This provides the benefit of
> coming up with more specific address types and representations at the
> expense that there is no generic way to retrieve the physical address
> of an arbitrary interface. Do we have any concrete experience that
> ifPhysAddress does not work in the IF-MIB?

I don't think this was his concern.  I think the concern was that this
leaf sticks out - why do we have an object that doesn't apply to all
interface types in this module?  Maybe there are other such objects
that we should include...


/martin





From mbj@tail-f.com  Tue Apr 30 01:30:04 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84B2B21F9B1B for ; Tue, 30 Apr 2013 01:30:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.213
X-Spam-Level: 
X-Spam-Status: No, score=-2.213 tagged_above=-999 required=5 tests=[AWL=-0.167, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9rA9cipv+X-4 for ; Tue, 30 Apr 2013 01:29:59 -0700 (PDT)
Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 881AF21F9B14 for ; Tue, 30 Apr 2013 01:29:59 -0700 (PDT)
Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 9FBC112008B7; Tue, 30 Apr 2013 10:29:58 +0200 (CEST)
Date: Tue, 30 Apr 2013 10:29:58 +0200 (CEST)
Message-Id: <20130430.102958.1781600496429359767.mbj@tail-f.com>
To: j.schoenwaelder@jacobs-university.de
From: Martin Bjorklund 
In-Reply-To: <20130430.101213.940183903512995864.mbj@tail-f.com>
References: <20130430.092945.981969607302073955.mbj@tail-f.com> <20130430074930.GA46852@elstar.local> <20130430.101213.940183903512995864.mbj@tail-f.com>
X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=iso-2022-jp
Content-Transfer-Encoding: 7bit
Cc: netmod@ietf.org
Subject: Re: [netmod] interface-cfg issues
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 30 Apr 2013 08:30:04 -0000

Martin Bjorklund  wrote:
> Juergen Schoenwaelder  wrote:
> > On Tue, Apr 30, 2013 at 09:29:45AM +0200, Martin Bjorklund wrote:
> > > Hi,
> > > 
> > > The Routing Directorate review of
> > > draft-ietf-netmod-interfaces-cfg-10.txt
> > > brought up a couple of issues that I think the WG needs to dicsuss.
> > > 
> > > (The original mail is not in the list archive, but my reply is found
> > > here: 
> > > http://www.ietf.org/mail-archive/web/netmod/current/msg08031.html)
> > > 
> > > 
> > > 1)  The name "location"
> > > 
> > > > > >> 3. Interfaces Data Model
> > > > > >> $B!D(B
> > > > > >>            +--rw location?                   string
> > > > > >> ...
> > > > > >> 3.1. The interface List
> > > > > >> $B!D(B
> > > > > >>   The "location" leaf is a string.  It is optional in the data model,
> > > > > >>   but if the type represents a physical interface, it is mandatory.
> > > > > >>   The format of this string is device- and type-dependent.  The device
> > > > > >>   uses the location string to identify the physical or logical entity
> > > > > >>   that the configuration applies to.  For example, if a device has a
> > > > > >>   single array of 8 ethernet ports, the location can be one of the
> > > > > >>   strings "1" to "8".  As another example, if a device has N cards of M
> > > > > >>   ports, the location can be on the form "n/m", such as "1/0".
> > > > > >> 
> > > > > >> I think that "location" is a poorly chosen label, a misnomer. This
> > > > > >> seems to be
> > > > > >> closer to an identifier than a locator. For example, some devices
> > > > > >> number slots
> > > > > >> left to right, and some number slots right to left :-)
> > > > > > 
> > > > > > Correct, and we do not try to get into this at all.  Some
> > > > > > devices has 2 ports called A and B, and some have chassis of cards
> > > > > > with rows of ports...
> > > > > > 
> > > > > >> This does not answer
> > > > > >> "where" something is; I do not mean geo-location, but I strongly
> > > > > >> suggest
> > > > > >> getting more precision on how this leaf is called. For example,
> > > > > >> interface
> > > > > >> numbering, instance id, type identifier, etc.
> > > > > > 
> > > > > > The intention is really to be "where" the port is.  It is not intended
> > > > > > to be a virtual id.  If the operator plugs in a cable in a certain
> > > > > > port, he has to know how to configure this port so there must be
> > > > > > something in the config that connects to the physical port.  We use
> > > > > > the name "location" for this purpose.
> > > > > 
> > > > > Thanks for the explanation. While I appreciate (and I agree) that you
> > > > > do not get into interpreting or parsing the syntax of the field, I
> > > > > still think it is not a "location".
> > > > > 
> > > > > I believe there is still an underlying assumption that the language is
> > > > > defined for the physical world. If you have an Ethernet1/0, versus an
> > > > > Ethernet1/2, that identifies (not locates) which interface. Yes, you
> > > > > can use that to physically find them. But what if you have a
> > > > > "loopback123" vs "loopback112358 or a "Serial1/4:5.123"? I do not
> > > > > think we can "locate" the loopback, or the subinterface.
> > > > > 
> > > > > If the operator creates a "loopback", "Tunnel", or virtual interface,
> > > > > he or she does not need to physically locate it.
> > > > > 
> > > > > I believe that labeling the leaf as "location" can be harmful as it
> > > > > implies a specific meaning and shows assumptions.
> > > > 
> > > > Ok I think I understand your concern.  Personally, I think "location"
> > > > works also in this case, but we should pick a name that is as useful
> > > > as possible.  Let me bring this issue back to the WG.
> > > 
> > > 
> > > Any comments on this?
> > > 
> > 
> > My understanding is that location is primarily for physical network
> > interfaces. For logical interfaces, the location may not be defined.
> > This covers loopback, tunnel, and virtual interfaces. Perhaps all that
> > needs to be done is to state that for interfaces that do not have a
> > location like loopback interfaces, the location leaf will not exist.
> 
> So we should probably say that it is used *only* for physical
> interfaces, not "primarily" - or is there a situation where it could
> be used also for logical/virtual interfaces?  For example, for
> loopbacks, you could theoretically use a plain number as the
> location.  If we limit location to physical interfaces, you would have
> to define a "number" leaf for loopbacks (in some other module).  But
> it might be ok,

Hmm, for loopback you don't need anything more than the unique name
(and the type).  No location or number is needed...


/martin

From j.schoenwaelder@jacobs-university.de  Tue Apr 30 01:32:13 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC7D521F9403; Tue, 30 Apr 2013 01:32:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.249
X-Spam-Level: 
X-Spam-Status: No, score=-103.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4BWhmRVcANTg; Tue, 30 Apr 2013 01:32:09 -0700 (PDT)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id C3D9121F9AFC; Tue, 30 Apr 2013 01:32:08 -0700 (PDT)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 106AB20C19; Tue, 30 Apr 2013 10:32:08 +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 FkIdBeuzvjuP; Tue, 30 Apr 2013 10:32: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 25EBC20C0C; Tue, 30 Apr 2013 10:32:07 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 1101325E9CE6; Tue, 30 Apr 2013 10:32:07 +0200 (CEST)
Date: Tue, 30 Apr 2013 10:32:06 +0200
From: Juergen Schoenwaelder 
To: Martin Thomson 
Message-ID: <20130430083206.GD46852@elstar.local>
Mail-Followup-To: Martin Thomson , apps-discuss@ietf.org, draft-ietf-netmod-rfc6021-bis.all@tools.ietf.org, iesg@ietf.org, netmod@ietf.org
References: <6.2.5.6.2.20130428233426.0b62fed0@elandnews.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <6.2.5.6.2.20130428233426.0b62fed0@elandnews.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: draft-ietf-netmod-rfc6021-bis.all@tools.ietf.org, netmod@ietf.org, iesg@ietf.org, apps-discuss@ietf.org
Subject: Re: [netmod] [appsdir] Fwd: APPSDIR review of draft-ietf-netmod-rfc6021-bis-01
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 30 Apr 2013 08:32:13 -0000

Hi,

thanks for the review. I will respond to your questions inline.

/js

On Sun, Apr 28, 2013 at 11:36:08PM -0700, Martin Thomson wrote:
> (Apologies, I have this habit of not including directorates on
> directorate reviews.  Correcting this oversight.)
> 
> I have been selected as the Applications Area Directorate reviewer for
> this draft (for background on appsdir, please see
> http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate
> ).
> 
> Please resolve these comments along with any other Last Call comments
> you may receive. Please wait for direction from your document shepherd
> or AD before posting a new version of the draft.
> 
> Document: draft-ietf-netmod-rfc6021-bis-01
> Title: Common YANG Data Types
> Reviewer: Martin Thomson
> Review Date: 2013-04-29
> 
> Summary: This draft is ready for publication as a Proposed Standard
> RFC.  I have some minor issues and questions.
> 
> This is some of the most readable code that I have seen.
> 
> Major Issues: none
> 
> Minor Issues:
> 
> Section 4:
> There is an RFC that describes a canonical textual representation of
> IPv6 addresses.  You should use that: RFC 5952.

The typedef ipv6-address has a reference to RFC 5952. I believe the
text in the description statement is inline with RFC 5952. Note that
this text did not change since RFC 6021 (and other than clarifications
we likely do not want changes).

> domain-name doesn't mention RFC 5890 at all (5891 is cited, but not
> used in the text).  I assume that these are LDH-labels:
> http://tools.ietf.org/html/rfc5890#section-2.3.1 and that this
> document should say as much.

I am not sure what you think is unclear. Note that the definition of
the typedef domain-name is unchanged from the one in RFC 6021. Perhaps
you can make a concrete text change proposal so I better understand
what your concern is.

> Questions:
> 
> Section 3:
> phys-address: why is this optionally empty?  Maybe explain why in the
> document - value absent?

The primary reason is to be consistent with the PhysAddress textual
convention of RFC 2579. Note that this definition did not change since
RFC 6021. What an empty address means needs to be defined where the
type is used. I do not think we can regulate that in the type
definition itself. All we could do is add a 'warning' that this type
allows zero-length strings as values and hence users of this type
either need to subtype this type or explain the semantics of a
zero-length string.

> hex-string: why is this required to include at least one octet? The
> text does not mention this at all, I tend to find lots of uses for
> empty octet strings, so this seems odd.

I will take this to the WG. Note that in YANG you often use choices to
model situations where in other frameworks you give special meanings
to say zero-length strings.

> xpath1.0: are we expected to infer that "context" includes document
> and where the namespace prefixes are bound?

The term context is I think well defined in section 1 of the XML Path
Language specification  (the document
cited in the reference statement). Note that this typedef is unchanged
from the one in RFC 6021.

> Section 4:
> ipv6-address: that is a very short IPv6 pattern.  Is it provably
> correct?  I only ask because I've had occasion to build a real
> pattern, and it's very long (the following is based on the "official"
> ABNF definition):
> 
>          
>          
>          
>          
>          
>          
>          
>          
>          
>          
>          
>          
>          
>          

Note sure what the "official" ABNF definition is but we believe that
the two pattern are correct. So far nobody was able to find a case
that was not properly accepted by the pattern. You are welcome to try
to find something where our two pattern break. ;-)

/js

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

From j.schoenwaelder@jacobs-university.de  Tue Apr 30 01:42:13 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F1AB21F9AE0 for ; Tue, 30 Apr 2013 01:42:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.249
X-Spam-Level: 
X-Spam-Status: No, score=-103.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZoFJ0d2g9EMk for ; Tue, 30 Apr 2013 01:42:08 -0700 (PDT)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 5FD3121F98CA for ; Tue, 30 Apr 2013 01:42:08 -0700 (PDT)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id C305220BD6; Tue, 30 Apr 2013 10:42:07 +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 J_L5RYlLoKK9; Tue, 30 Apr 2013 10:42: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 3F8F020A13; Tue, 30 Apr 2013 10:42:07 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 20B1025E9DFB; Tue, 30 Apr 2013 10:42:07 +0200 (CEST)
Date: Tue, 30 Apr 2013 10:42:07 +0200
From: Juergen Schoenwaelder 
To: Martin Bjorklund 
Message-ID: <20130430084207.GB47140@elstar.local>
Mail-Followup-To: Martin Bjorklund , netmod@ietf.org
References: <20130430.092945.981969607302073955.mbj@tail-f.com> <20130430074930.GA46852@elstar.local> <20130430.101213.940183903512995864.mbj@tail-f.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20130430.101213.940183903512995864.mbj@tail-f.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: netmod@ietf.org
Subject: Re: [netmod] interface-cfg issues
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 30 Apr 2013 08:42:13 -0000

On Tue, Apr 30, 2013 at 10:12:13AM +0200, Martin Bjorklund wrote:
> Juergen Schoenwaelder  wrote:
> > On Tue, Apr 30, 2013 at 09:29:45AM +0200, Martin Bjorklund wrote:
> > > Hi,
> > > 
> > > The Routing Directorate review of
> > > draft-ietf-netmod-interfaces-cfg-10.txt
> > > brought up a couple of issues that I think the WG needs to dicsuss.
> > > 
> > > (The original mail is not in the list archive, but my reply is found
> > > here: 
> > > http://www.ietf.org/mail-archive/web/netmod/current/msg08031.html)
> > > 
> > > 
> > > 1)  The name "location"
> > > 
> > > > > >> 3. Interfaces Data Model
> > > > > >> …
> > > > > >>            +--rw location?                   string
> > > > > >> ...
> > > > > >> 3.1. The interface List
> > > > > >> …
> > > > > >>   The "location" leaf is a string.  It is optional in the data model,
> > > > > >>   but if the type represents a physical interface, it is mandatory.
> > > > > >>   The format of this string is device- and type-dependent.  The device
> > > > > >>   uses the location string to identify the physical or logical entity
> > > > > >>   that the configuration applies to.  For example, if a device has a
> > > > > >>   single array of 8 ethernet ports, the location can be one of the
> > > > > >>   strings "1" to "8".  As another example, if a device has N cards of M
> > > > > >>   ports, the location can be on the form "n/m", such as "1/0".
> > > > > >> 
> > > > > >> I think that "location" is a poorly chosen label, a misnomer. This
> > > > > >> seems to be
> > > > > >> closer to an identifier than a locator. For example, some devices
> > > > > >> number slots
> > > > > >> left to right, and some number slots right to left :-)
> > > > > > 
> > > > > > Correct, and we do not try to get into this at all.  Some
> > > > > > devices has 2 ports called A and B, and some have chassis of cards
> > > > > > with rows of ports...
> > > > > > 
> > > > > >> This does not answer
> > > > > >> "where" something is; I do not mean geo-location, but I strongly
> > > > > >> suggest
> > > > > >> getting more precision on how this leaf is called. For example,
> > > > > >> interface
> > > > > >> numbering, instance id, type identifier, etc.
> > > > > > 
> > > > > > The intention is really to be "where" the port is.  It is not intended
> > > > > > to be a virtual id.  If the operator plugs in a cable in a certain
> > > > > > port, he has to know how to configure this port so there must be
> > > > > > something in the config that connects to the physical port.  We use
> > > > > > the name "location" for this purpose.
> > > > > 
> > > > > Thanks for the explanation. While I appreciate (and I agree) that you
> > > > > do not get into interpreting or parsing the syntax of the field, I
> > > > > still think it is not a "location".
> > > > > 
> > > > > I believe there is still an underlying assumption that the language is
> > > > > defined for the physical world. If you have an Ethernet1/0, versus an
> > > > > Ethernet1/2, that identifies (not locates) which interface. Yes, you
> > > > > can use that to physically find them. But what if you have a
> > > > > "loopback123" vs "loopback112358 or a "Serial1/4:5.123"? I do not
> > > > > think we can "locate" the loopback, or the subinterface.
> > > > > 
> > > > > If the operator creates a "loopback", "Tunnel", or virtual interface,
> > > > > he or she does not need to physically locate it.
> > > > > 
> > > > > I believe that labeling the leaf as "location" can be harmful as it
> > > > > implies a specific meaning and shows assumptions.
> > > > 
> > > > Ok I think I understand your concern.  Personally, I think "location"
> > > > works also in this case, but we should pick a name that is as useful
> > > > as possible.  Let me bring this issue back to the WG.
> > > 
> > > 
> > > Any comments on this?
> > > 
> > 
> > My understanding is that location is primarily for physical network
> > interfaces. For logical interfaces, the location may not be defined.
> > This covers loopback, tunnel, and virtual interfaces. Perhaps all that
> > needs to be done is to state that for interfaces that do not have a
> > location like loopback interfaces, the location leaf will not exist.
> 
> So we should probably say that it is used *only* for physical
> interfaces, not "primarily" - or is there a situation where it could
> be used also for logical/virtual interfaces?  For example, for
> loopbacks, you could theoretically use a plain number as the
> location.  If we limit location to physical interfaces, you would have
> to define a "number" leaf for loopbacks (in some other module).  But
> it might be ok,

I fail to see why I now suddenly need a number for the location of my
loopback interface. It simply does not have a location, no? A VLAN
interface on top of an Ethernet trunk does not need a physical
location since the lower layer interface has one but I also do not
mind to have an implementation support a location in that case.
Perhaps I do not see the problem yet.
 
> > > 2)  phys-address
> > > 
> > > >>         leaf phys-address {
> > > >>           type yang:phys-address;
> > > >>           config false;
> > > >>           description
> > > >>             "The interface's address at its protocol sub-layer.  For
> > > >>             example, for an 802.x interface, this object normally
> > > >>             contains a MAC address.  The interface's media-specific
> > > >>             modules must define the bit and byte ordering and the
> > > >>             format of the value of this object.  For interfaces that do
> > > >>             not have such an address (e.g., a serial line), this node
> > > >>             is not present.";
> > > >>           reference
> > > >>             "RFC 2863: The Interfaces Group MIB - ifPhysAddress";
> > > >>         }
> > > >> 
> > > >> Just by reading the description of this leaf, shouldn't this be
> > > >> part of an augmentation type-specific module? For example, for an
> > > >> Ethernet interface module, instead of the main YANG interface
> > > >> management top-level. Meaning: this specific leaf, by definition,
> > > >> cannot be generically specified to what it means for each type of
> > > >> interfaces. All the others can… if this cannot be specified outside
> > > >> a media-specific module, why define it here?
> > > 
> > > So the proposal from him is to remove this leaf.  I think it could
> > > stay, but we would probably not have added it if it wasn't part of
> > > ifTable...  Comments?
> > 
> > There are interfaces that do not have a physical address, e.g. the
> > loopback interface. For such interfaces, phys-address would not exist.
> > Are there interfaces that have a physical address that this object
> > can't represent properly? Sure, this object could be moved to
> > interface type specific data models. This provides the benefit of
> > coming up with more specific address types and representations at the
> > expense that there is no generic way to retrieve the physical address
> > of an arbitrary interface. Do we have any concrete experience that
> > ifPhysAddress does not work in the IF-MIB?
> 
> I don't think this was his concern.  I think the concern was that this
> leaf sticks out - why do we have an object that doesn't apply to all
> interface types in this module?  Maybe there are other such objects
> that we should include...

We went through discussions like this and the WG finally agreed on
what we have in the I-D. I personally do not like to restart this
discussion. We need to ship things, additional leafs can always be
added later in revisions. So I only see the option we ship what we
have agreed to before or we take out phys-address and we are willing
to wait for interface type specific data models to provide something
similar. Unless ifPhysAddress has proven broken, I prefer to keep what
we have on the table right now.

/js

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

From j.schoenwaelder@jacobs-university.de  Tue Apr 30 01:44:21 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AB0921F9AFC for ; Tue, 30 Apr 2013 01:44:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.249
X-Spam-Level: 
X-Spam-Status: No, score=-103.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KnAgnMSQTnmg for ; Tue, 30 Apr 2013 01:44:16 -0700 (PDT)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 45BA721F9AE0 for ; Tue, 30 Apr 2013 01:44:16 -0700 (PDT)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id AC64C20BE0; Tue, 30 Apr 2013 10:44:15 +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 unzzVBY7WYVS; Tue, 30 Apr 2013 10:44: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 B4B7B20BD6; Tue, 30 Apr 2013 10:44:14 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 9896D25E9E60; Tue, 30 Apr 2013 10:44:14 +0200 (CEST)
Date: Tue, 30 Apr 2013 10:44:14 +0200
From: Juergen Schoenwaelder 
To: netmod@ietf.org
Message-ID: <20130430084414.GC47140@elstar.local>
Mail-Followup-To: netmod@ietf.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.21 (2010-09-15)
Subject: [netmod] hex string - allow zero length values?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 30 Apr 2013 08:44:21 -0000

Hi,

an issue that came up during reviews:

Should hex-string allow zero-length strings?

Right now it does not. Should we change that? If so, how would it
affect other documents we have using the hex-string definition?

/js

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

From mbj@tail-f.com  Tue Apr 30 02:12:32 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42EEB21F9AA3 for ; Tue, 30 Apr 2013 02:12:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.171
X-Spam-Level: 
X-Spam-Status: No, score=-2.171 tagged_above=-999 required=5 tests=[AWL=-0.125, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b-C2du408Gvs for ; Tue, 30 Apr 2013 02:12:26 -0700 (PDT)
Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id F047A21F98B5 for ; Tue, 30 Apr 2013 02:12:25 -0700 (PDT)
Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id F153412008B7; Tue, 30 Apr 2013 11:12:24 +0200 (CEST)
Date: Tue, 30 Apr 2013 11:12:24 +0200 (CEST)
Message-Id: <20130430.111224.1400052084629997469.mbj@tail-f.com>
To: j.schoenwaelder@jacobs-university.de
From: Martin Bjorklund 
In-Reply-To: <20130430084414.GC47140@elstar.local>
References: <20130430084414.GC47140@elstar.local>
X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Cc: netmod@ietf.org
Subject: Re: [netmod] hex string - allow zero length values?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 30 Apr 2013 09:12:32 -0000

Juergen Schoenwaelder  wrote:
> Hi,
> 
> an issue that came up during reviews:
> 
> Should hex-string allow zero-length strings?
> 
> Right now it does not. Should we change that? If so, how would it
> affect other documents we have using the hex-string definition?

It makes some sense to allow it.  We allow zero-length strings and
binary for example.

ietf-x509-cert-to-name and ietf-snmp-common are not affected, they
already have a length restriction.

ietf-snmp-usm uses it for keys, and does not have a restriction but
probably should anyway.


/martin

From lhotka@nic.cz  Tue Apr 30 02:51:29 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7D5D21F99C0 for ; Tue, 30 Apr 2013 02:51:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_23=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j07I8wY23VE3 for ; Tue, 30 Apr 2013 02:51:23 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 0917621F998A for ; Tue, 30 Apr 2013 02:51:22 -0700 (PDT)
Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 749F713F7BA; Tue, 30 Apr 2013 11:51:21 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1367315481; bh=v1VsD2tZaMkmNeckUfY/bDrrXdmamICAxzBB9nL0TFU=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=ovEu17t80mZZIDs6S85x0mx+/dJBUCkCTkaQyu55Rtu18aELhzDDMZyo75zDE0LRX 26+bMT2YsH+r2MnClKLpljQAR7E5gyApj7TLDMw3wD8+1Tju+3wdFb93mTs5O/mw62 v20frIk5no7M5Yc6bo0Fv/e8CPfb9r35Gpdlo98M=
Content-Type: text/plain; charset=iso-2022-jp
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
From: Ladislav Lhotka 
In-Reply-To: <20130430.092945.981969607302073955.mbj@tail-f.com>
Date: Tue, 30 Apr 2013 11:51:21 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <11B16E57-3B55-4078-AB69-BDAFA2B3E383@nic.cz>
References: <20130430.092945.981969607302073955.mbj@tail-f.com>
To: Martin Bjorklund 
X-Mailer: Apple Mail (2.1503)
X-Virus-Scanned: clamav-milter 0.97.7 at mail
X-Virus-Status: Clean
Cc: netmod@ietf.org
Subject: Re: [netmod] interface-cfg issues
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 30 Apr 2013 09:51:30 -0000

On Apr 30, 2013, at 9:29 AM, Martin Bjorklund  wrote:

> Hi,
>=20
> The Routing Directorate review of
> draft-ietf-netmod-interfaces-cfg-10.txt
> brought up a couple of issues that I think the WG needs to dicsuss.
>=20
> (The original mail is not in the list archive, but my reply is found
> here:=20
> http://www.ietf.org/mail-archive/web/netmod/current/msg08031.html)
>=20
>=20
> 1)  The name "location"
>=20
>>>>> 3. Interfaces Data Model
>>>>> =1B$B!D=1B(B
>>>>>           +--rw location?                   string
>>>>> ...
>>>>> 3.1. The interface List
>>>>> =1B$B!D=1B(B
>>>>>  The "location" leaf is a string.  It is optional in the data =
model,
>>>>>  but if the type represents a physical interface, it is mandatory.
>>>>>  The format of this string is device- and type-dependent.  The =
device
>>>>>  uses the location string to identify the physical or logical =
entity
>>>>>  that the configuration applies to.  For example, if a device has =
a
>>>>>  single array of 8 ethernet ports, the location can be one of the
>>>>>  strings "1" to "8".  As another example, if a device has N cards =
of M
>>>>>  ports, the location can be on the form "n/m", such as "1/0".
>>>>>=20
>>>>> I think that "location" is a poorly chosen label, a misnomer. This
>>>>> seems to be
>>>>> closer to an identifier than a locator. For example, some devices
>>>>> number slots
>>>>> left to right, and some number slots right to left :-)
>>>>=20
>>>> Correct, and we do not try to get into this at all.  Some
>>>> devices has 2 ports called A and B, and some have chassis of cards
>>>> with rows of ports...
>>>>=20
>>>>> This does not answer
>>>>> "where" something is; I do not mean geo-location, but I strongly
>>>>> suggest
>>>>> getting more precision on how this leaf is called. For example,
>>>>> interface
>>>>> numbering, instance id, type identifier, etc.
>>>>=20
>>>> The intention is really to be "where" the port is.  It is not =
intended
>>>> to be a virtual id.  If the operator plugs in a cable in a certain
>>>> port, he has to know how to configure this port so there must be
>>>> something in the config that connects to the physical port.  We use
>>>> the name "location" for this purpose.
>>>=20
>>> Thanks for the explanation. While I appreciate (and I agree) that =
you
>>> do not get into interpreting or parsing the syntax of the field, I
>>> still think it is not a "location".
>>>=20
>>> I believe there is still an underlying assumption that the language =
is
>>> defined for the physical world. If you have an Ethernet1/0, versus =
an
>>> Ethernet1/2, that identifies (not locates) which interface. Yes, you
>>> can use that to physically find them. But what if you have a
>>> "loopback123" vs "loopback112358 or a "Serial1/4:5.123"? I do not
>>> think we can "locate" the loopback, or the subinterface.
>>>=20
>>> If the operator creates a "loopback", "Tunnel", or virtual =
interface,
>>> he or she does not need to physically locate it.
>>>=20
>>> I believe that labeling the leaf as "location" can be harmful as it
>>> implies a specific meaning and shows assumptions.
>>=20
>> Ok I think I understand your concern.  Personally, I think "location"
>> works also in this case, but we should pick a name that is as useful
>> as possible.  Let me bring this issue back to the WG.
>=20
>=20
> Any comments on this?

Let me just throw in my earlier proposal of using "local-name" instead =
of "location". I believe the former makes sense on every platform, which =
is not the case for the latter.

>=20
>=20
> 2)  phys-address
>=20
>>>        leaf phys-address {
>>>          type yang:phys-address;
>>>          config false;
>>>          description
>>>            "The interface's address at its protocol sub-layer.  For
>>>            example, for an 802.x interface, this object normally
>>>            contains a MAC address.  The interface's media-specific
>>>            modules must define the bit and byte ordering and the
>>>            format of the value of this object.  For interfaces that =
do
>>>            not have such an address (e.g., a serial line), this node
>>>            is not present.";
>>>          reference
>>>            "RFC 2863: The Interfaces Group MIB - ifPhysAddress";
>>>        }
>>>=20
>>> Just by reading the description of this leaf, shouldn't this be
>>> part of an augmentation type-specific module? For example, for an
>>> Ethernet interface module, instead of the main YANG interface
>>> management top-level. Meaning: this specific leaf, by definition,
>>> cannot be generically specified to what it means for each type of
>>> interfaces. All the others can=1B$B!D=1B(B if this cannot be =
specified outside
>>> a media-specific module, why define it here?
>=20
> So the proposal from him is to remove this leaf.  I think it could
> stay, but we would probably not have added it if it wasn't part of
> ifTable...  Comments?

I think the reviewer is right that physical address is always defined by =
a particular technology, so it might really be appropriate to remove =
this leaf. We have the type "yang:phys-address" in 6021bis, so it is not =
a big deal to add it where it makes sense.

Lada

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

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





From mbj@tail-f.com  Tue Apr 30 03:21:01 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F418021F9BAD; Tue, 30 Apr 2013 03:20:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.157
X-Spam-Level: 
X-Spam-Status: No, score=-2.157 tagged_above=-999 required=5 tests=[AWL=-0.111, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m33qcGnNHNz8; Tue, 30 Apr 2013 03:20:53 -0700 (PDT)
Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id CB82D21F9BA3; Tue, 30 Apr 2013 03:20:51 -0700 (PDT)
Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id D5E0F1200045; Tue, 30 Apr 2013 12:20:49 +0200 (CEST)
Date: Tue, 30 Apr 2013 12:20:49 +0200 (CEST)
Message-Id: <20130430.122049.1111664509032933339.mbj@tail-f.com>
To: ietfdbh@comcast.net
From: Martin Bjorklund 
In-Reply-To: <20130427.093659.369612374.mbj@tail-f.com>
References: <20130427.093659.369612374.mbj@tail-f.com>
X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Cc: ietf@ietf.org, netmod@ietf.org
Subject: Re: [netmod] Last Call:  (A YANG Data Model for Interface Management) to Proposed Standard
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 30 Apr 2013 10:21:03 -0000

Hi David,

Thank you for your detailed review!  Comments inline.

David Harrington  wrote:
> Hi, 
>  
> I have reviewed this document and feel that is almost ready for approval. 
> This document defines a new data model in YANG format, based on the same 
> information model as the Interfaces MIB module (IF-MIB). 
> Effectively, the YANG model is a second (duplicative) standard for much of 
> the same information. 
> It is expected that devices may implement both the MIB and the YANG data 
> models. 
>  
> My primary concern regards co-existence and synchronization across data 
> models. 
> I think this document would benefit from an Operational Considerations 
> section that discusses synchronization, or an explanation why they might 
> reasonably be out-of-sync. 
> Here are a few points to consider: 
>  
> 1) the ifIndex of an interface is used within the YANG model, matching the 
> ifIndex in IF-MIB.  
> RFC2863 discusses the fact that ifIndex numbering might change during 
> hot-swaps. 

Actually, RFC 2863 points out that a ifIndex must not be reused until
after the following re-initialization of the network management
system.

> This document does not discuss the need to ensure that IF-MIB ifIndex 
> changes need to be reflected in the YANG model. 
> The ifIndex in the YANG module must match that in IF-MIB (really, that in 
> the underlying instrumentation). 

Absolutely!  That's the intention.  The description for the read-only
leaf if-index says:

           The ifIndex value for the ifEntry represented by this
           interface.


> Failure to sync the ifIndex could lead NM applications to confuse which 
> already-retrieved data records are related to which interface. 
> This could cause an NM application to misinterpret/corrupt gathered 
> trending information, and possibly to apply changes to the wrong 
> interfaces. 

Fully agree - this is why the if-index is present; to facilitate the
mapping between the models.

> 2) ifType - can an interface be hot-swapped to use a different type? Is 
> this discussed someplace? 

Hot-swapping sounds like a physical property.  The data model in this
document can handle this -- provided the system physically supports
it, of course.  Note that the type is a writable leaf just like
others.  You can change it, but as with any other leaf a device that
cannot support a particular change will reject it.

> 3) ifType - the description says the value of this mandatory object MAY be 
> initialized. What value should an NM application expect if it is NOT 
> initialized? 

None.  And since it is mandatory, in this case the NM application has
to explicitly provide the type.  If you write a completely generic NM
application you would probably always provide the type, since you
cannot count on the server auto-initializing it.  But if you *know*
that the server auto-initialize the type, you don't have to provide
it.

> 4) enabled - "Systems that implement the IF-MIB use the value of this leaf 
> to set IF-MIB.ifAdminStatus ..."; should this be a MAY/SHOULD/MUST? How 
> will this coexist with SNMP-based NM applications? Is there potential for 
> conflict? What if NETCONF sets this as enabled, then an operator sets it 
> to disabled via SNMP? 
> Does NETCONF know that its "enable" value (adminStatus) is out of date? 
> (does it matter? See note 7). 
> What if the NETCONF system directky changes the underlying instrumentation 
> for adminstatus without going through the MIB? 

It is not clear to me if we can / want to require that these objects
share the same instrumentation.

Some of this might be b/c ifAdminStatus is a a bit unclear in some
regards.  For example, it talks about how

            per configuration information
            retained by the managed system, ifAdminStatus is then
            changed [...]

I would assume (but this might be incorrect) that the "configuration
information" could be things configured through the CLI for example,
and this "configuration information" could thus also be the data
defined in this YANG model.

So it seems RFC 2863 makes a distinction between ifAdminStatus and
what is actually configured.

Also, the description of ifAdminStatus doesn't say anything about
persistence, so it might be impossible to map this to the persistently
stored configuration.


> 5) is there a reason why "description" value MAY match IF-MIB ifAlias 
> ***and MAY restrict the values***? 
> Is there a particular use case for this lack of standardization of 
> restrictions across data models? 
> The persistence is a pretty important restriction related to the 
> functionality of ifAlias, and the dynamism of ifIndex. 
> If NETCONF is used to set the value, ignoring IF-MIB restrictions, what 
> happens to IF-MIB ifAlias as a persistent "handle" to the interface? 

The only reason the "description" leaf is mapped to ifAlias is b/c
this is what many implementations do.  So we wanted to point out the
differences in the value space for these objects so that implementers
are aware of this.

And of course it is not possible to actually set *ifAlias* and ignore
its syntax constraints.  However, you can use non 7-bit ascii in
"description", and in this case the "description" value cannot be used
unmodified as ifAlias.

> 6) What error is returned via NETCONF if YANG attempts to set a value that 
> violates the SNMP agent implementation restrictions, and the SNMP agent 
> refuses the requested SET operation to ifAlias? 

The draft says:

           If a NETCONF server that implements this restriction is
           sent a value that doesn't match the restriction, it MUST
           reply with an rpc-error with the error-tag
           'invalid-value'.

> Is there a simple way for an operator to tell whether the implementation 
> supports the restrictions (other than deliberately triggering an error)? 

No.

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

The intention is that they share the same instrumentation.

> IF-MIB has substantial discussion of the relationship between 
> ifAdminStatus and ifOperStatus. The YANG module doesn't have a comparable 
> discussion. 

Which text in the MIB do you mean?  There is some text in the
description of "oper-status".

> Given that there could e additional delay incurred between setting enable, 
> updating ifAdminStatus, the change to ifOperStatus, and the update to 
> oper-status, I recommend some mention in the description of enable and/or 
> oper-status of the detailed description in RFC2863, and applicability to 
> ietf-interfaces. 
>  
> 8) link-up-down-trap-enable: The text says this "indicates" whether traps 
> should be generated for the interface; shouldn't this be "configures"? 

Or maybe "Controls ..."?

> 9) persistence isn't discussed in the config object descriptions. Do they 
> match the IF-MIB object persistences? 

Persistence in NETCONF is different from SNMP, in general.  In NETCONF,
the persistence is defined by the data store where you write the data.


> 10) IF-MIB counters do not typically start at zero; a delta must be 
> calculated. This is a common misunderstanding for new MIB developers and 
> users. 
> I don't see any comparable discussion related to ietf-interfaces counters. 
> Where should one look for a discussion of YANG counter initialization 
> values? 
> Where should one look for a discussion of YANG counter rollover? 

The couters are defined as yang:counter32 and yang:counter64.  The
"yang" prefix means module "ietf-yang-types".  This module is defined
in RFC 6021.  This RFC discusses initial values and discontinuities.

(ok, this was also suggested by yourself further below!)

> It would help to have a discussion of how to utilize discontinuity_time 
> and counters, especially for implementers not familiar with SNMP (and not 
> implementing IF-MIB). 
>  
> 11) Is it expected that counters in ietf-interfaces and counters in IF-MIB 
> are synchronized? Can an NM application reasonably compare two readings - 
> one of in-octets and one of ifHCInOctets? If not, I think that should be 
> made clear. (The reference clauses seem to link them) 

I think the intention is that the instrumentation is shared.  There is
most probably a single hw register / kernel counter for these objects,
and this is what will be used for these counters.

> 12) From IF-MIB: "Discontinuities in the value of this counter can occur 
> at re-initialization of the management system, and at other times as 
> indicated by the value of ifCounterDiscontinuityTime." 
> From ietf-interfaces: "Discontinuities in the value of this counter can 
> occur at re-initialization of the management system, and at other times as 
> indicated by the value of 'discontinuity-time'." 
> I think it is ambiguous as to whether both sets of text refer to the same 
> "management system". Is the IF-MIB management-system the SNMP agent? And 
> the YANG management-system the YANG server? Or are both based on the 
> underlying (e.g, hardware or native) management system? 

Good question!  The term is not defined anywhere (as far as I know),
and thus there is some liberty in the interpretation of it.  But I
don't think it matters.  It seems unlikely that a
NM application sometimes reads a counter over SNMP and sometimes the
same counter from the same device over NETCONF and then compare the
values.

> Are ifCounterDiscontinuityTime and discontinuity-time synchronized or 
> independent? If they are independent, then the YANG counters and MIB 
> counters could contain very different values; it might help operators to 
> have this pointed out.

See above.  There is no requirement that they MUST be synchronized,
but they surely can be.

> It might help implementers to know whether to try 
> to synchronize them or not. 
> Can an operator force restart of both YANG and MIB systems to force 
> synchronization of counters? 

No.  Is there a way to force a restart of the "MIB system"?

> 13) Some of the questions about counters might be covered in yang-types; 
> it would help if the imports clause indicated the relevant RFCs. 

As a comment?  I will raise this issue in the WG.

> 14) IF-MIB has both 32-bit and 64-bit counters; YANG only duplicates the 
> 64-bit counters, generally. It might be good to discuss this in an 
> Operations Considerations section, to explain some potential anomalies at 
> the NM application side. 

In practice I don't think this is a problem.  It seems unlikely that a
NM application sometimes reads a counter over SNMP and sometimes the
same counter from the same device over NETCONF and then compare the
values.

> 15) ietf-interfaces can modify the SNMP trap-enable settings; enabling 
> lots of traps could impact denial of service, disabling could hide 
> interface changes made by an attacker; it should probably be mentioned in 
> security considerations. 

I was thinking we could simply reference the Security Considerations
section in RFC 2863 for this, but it doesn't discuss this.

> 16) Many operators/developers may have experience with IF-MIB, and some 
> applications might be rewritten to utilize ietf-interfaces rather than (or 
> to supplement) IF-MIB. Not all IF-MIB objects are reflected in 
> ietf-interfaces; it might be helpful to show which IF-MIB objects are not 
> mapped to ietf-interfaces, and discuss why, and whether comparable info 
> can be derived using other YANG approaches. 
>  
> 17) The copyright in the module description clause needs updating. 

Ok.



/martin

From bclaise@cisco.com  Tue Apr 30 03:48:23 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2460B21F9AF0; Tue, 30 Apr 2013 03:48:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.406
X-Spam-Level: 
X-Spam-Status: No, score=-10.406 tagged_above=-999 required=5 tests=[AWL=0.193, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lxSTlJ2NK8Lq; Tue, 30 Apr 2013 03:48:19 -0700 (PDT)
Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id B142C21F9AE4; Tue, 30 Apr 2013 03:48:18 -0700 (PDT)
X-TACSUNS: Virus Scanned
Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r3UAm9wJ002917; Tue, 30 Apr 2013 12:48:09 +0200 (CEST)
Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r3UAlbwe007738; Tue, 30 Apr 2013 12:47:53 +0200 (CEST)
Message-ID: <517FA149.6050804@cisco.com>
Date: Tue, 30 Apr 2013 12:47:37 +0200
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5
MIME-Version: 1.0
To: David Harrington 
References: 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: draft-ietf-netmod-interfaces-cfg.all@tools.ietf.org, IETF Discussion List , NETMOD Working Group 
Subject: Re: [netmod] FW: Last Call:  (A YANG Data Model for Interface Management) to Proposed Standard
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 30 Apr 2013 10:48:23 -0000

Thanks Dave for your thorough review.
You have some very valid points.

I've not seen any replies from the author. Maybe he doesn't monitor this 
list. So, including some extra mailing lists.
Martin, NETMOD WG, can you please address David's points.

Note: there is also a reply from Tom Petch on this email. See 
http://www.ietf.org/mail-archive/web/ietf/current/msg78808.html

Regards, Benoit
> Hi,
>
> I have reviewed this document and feel that is almost ready for approval.
> This document defines a new data model in YANG format, based on the same
> information model as the Interfaces MIB module (IF-MIB).
> Effectively, the YANG model is a second (duplicative) standard for much of
> the same information.
> It is expected that devices may implement both the MIB and the YANG data
> models.
>
> My primary concern regards co-existence and synchronization across data
> models.
> I think this document would benefit from an Operational Considerations
> section that discusses synchronization, or an explanation why they might
> reasonably be out-of-sync.
> Here are a few points to consider:
>
> 1) the ifIndex of an interface is used within the YANG model, matching the
> ifIndex in IF-MIB.
> RFC2863 discusses the fact that ifIndex numbering might change during
> hot-swaps.
> This document does not discuss the need to ensure that IF-MIB ifIndex
> changes need to be reflected in the YANG model.
> The ifIndex in the YANG module must match that in IF-MIB (really, that in
> the underlying instrumentation).
> Failure to sync the ifIndex could lead NM applications to confuse which
> already-retrieved data records are related to which interface.
> This could cause an NM application to misinterpret/corrupt gathered
> trending information, and possibly to apply changes to the wrong
> interfaces.
>
> 2) ifType - can an interface be hot-swapped to use a different type? Is
> this discussed someplace?
>
> 3) ifType - the description says the value of this mandatory object MAY be
> initialized. What value should an NM application expect if it is NOT
> initialized?
>
> 4) enabled - "Systems that implement the IF-MIB use the value of this leaf
> to set IF-MIB.ifAdminStatus ..."; should this be a MAY/SHOULD/MUST? How
> will this coexist with SNMP-based NM applications? Is there potential for
> conflict? What if NETCONF sets this as enabled, then an operator sets it
> to disabled via SNMP?
> Does NETCONF know that its "enable" value (adminStatus) is out of date?
> (does it matter? See note 7).
> What if the NETCONF system directky changes the underlying instrumentation
> for adminstatus without going through the MIB?
>
> 5) is there a reason why "description" value MAY match IF-MIB ifAlias
> ***and MAY restrict the values***?
> Is there a particular use case for this lack of standardization of
> restrictions across data models?
> The persistence is a pretty important restriction related to the
> functionality of ifAlias, and the dynamism of ifIndex.
> If NETCONF is used to set the value, ignoring IF-MIB restrictions, what
> happens to IF-MIB ifAlias as a persistent "handle" to the interface?
>
> 6) What error is returned via NETCONF if YANG attempts to set a value that
> violates the SNMP agent implementation restrictions, and the SNMP agent
> refuses the requested SET operation to ifAlias?
> Is there a simple way for an operator to tell whether the implementation
> supports the restrictions (other than deliberately triggering an error)?
>
> 7) what should an NM application or operator do if the YANG oper-status
> and the IF-MIB operStatus differ?
> IF-MIB has substantial discussion of the relationship between
> ifAdminStatus and ifOperStatus. The YANG module doesn't have a comparable
> discussion.
> Given that there could e additional delay incurred between setting enable,
> updating ifAdminStatus, the change to ifOperStatus, and the update to
> oper-status, I recommend some mention in the description of enable and/or
> oper-status of the detailed description in RFC2863, and applicability to
> ietf-interfaces.
>
> 8) link-up-down-trap-enable: The text says this "indicates" whether traps
> should be generated for the interface; shouldn't this be "configures"?
>
> 9) persistence isn't discussed in the config object descriptions. Do they
> match the IF-MIB object persistences?
>
> 10) IF-MIB counters do not typically start at zero; a delta must be
> calculated. This is a common misunderstanding for new MIB developers and
> users.
> I don't see any comparable discussion related to ietf-interfaces counters.
> Where should one look for a discussion of YANG counter initialization
> values?
> Where should one look for a discussion of YANG counter rollover?
> It would help to have a discussion of how to utilize discontinuity_time
> and counters, especially for implementers not familiar with SNMP (and not
> implementing IF-MIB).
>
> 11) Is it expected that counters in ietf-interfaces and counters in IF-MIB
> are synchronized? Can an NM application reasonably compare two readings -
> one of in-octets and one of ifHCInOctets? If not, I think that should be
> made clear. (The reference clauses seem to link them)
>
> 12) From IF-MIB: "Discontinuities in the value of this counter can occur
> at re-initialization of the management system, and at other times as
> indicated by the value of ifCounterDiscontinuityTime."
> >From ietf-interfaces: "Discontinuities in the value of this counter can
> occur at re-initialization of the management system, and at other times as
> indicated by the value of 'discontinuity-time'."
> I think it is ambiguous as to whether both sets of text refer to the same
> "management system". Is the IF-MIB management-system the SNMP agent? And
> the YANG management-system the YANG server? Or are both based on the
> underlying (e.g, hardware or native) management system?
> Are ifCounterDiscontinuityTime and discontinuity-time synchronized or
> independent? If they are independent, then the YANG counters and MIB
> counters could contain very different values; it might help operators to
> have this pointed out. It might help implementers to know whether to try
> to synchronize them or not.
> Can an operator force restart of both YANG and MIB systems to force
> synchronization of counters?
>
> 13) Some of the questions about counters might be covered in yang-types;
> it would help if the imports clause indicated the relevant RFCs.
>
> 14) IF-MIB has both 32-bit and 64-bit counters; YANG only duplicates the
> 64-bit counters, generally. It might be good to discuss this in an
> Operations Considerations section, to explain some potential anomalies at
> the NM application side.
>
> 15) ietf-interfaces can modify the SNMP trap-enable settings; enabling
> lots of traps could impact denial of service, disabling could hide
> interface changes made by an attacker; it should probably be mentioned in
> security considerations.
>
> 16) Many operators/developers may have experience with IF-MIB, and some
> applications might be rewritten to utilize ietf-interfaces rather than (or
> to supplement) IF-MIB. Not all IF-MIB objects are reflected in
> ietf-interfaces; it might be helpful to show which IF-MIB objects are not
> mapped to ietf-interfaces, and discuss why, and whether comparable info
> can be derived using other YANG approaches.
>
> 17) The copyright in the module description clause needs updating.
>
> Hope this helps,
> --
> David Harrington
> Ietfdbh@comcast.net
> +1-603-828-1401
>
>
>
>
>
> On 4/19/13 9:25 AM, "The IESG"  wrote:
>
>> The IESG has received a request from the NETCONF Data Modeling Language
>> WG (netmod) to consider the following document:
>> - 'A YANG Data Model for Interface Management'
>>    as Proposed Standard
>>
>> The IESG plans to make a decision in the next few weeks, and solicits
>> final comments on this action. Please send substantive comments to the
>> ietf@ietf.org mailing lists by 2013-05-03. Exceptionally, comments may be
>> sent to iesg@ietf.org instead. In either case, please retain the
>> beginning of the Subject line to allow automated sorting.
>>
>> Abstract
>>
>>
>>    This document defines a YANG data model for the management of network
>>    interfaces.  It is expected that interface type specific data models
>>    augment the generic interfaces data model defined in this document.
>>
>>
>>
>>
>> The file can be obtained via
>> http://datatracker.ietf.org/doc/draft-ietf-netmod-interfaces-cfg/
>>
>> IESG discussion can be tracked via
>> http://datatracker.ietf.org/doc/draft-ietf-netmod-interfaces-cfg/ballot/
>>
>>
>> No IPR declarations have been submitted directly on this I-D.
>>
>>
>
>


From bclaise@cisco.com  Tue Apr 30 04:08:15 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19C0D21F9B2F; Tue, 30 Apr 2013 04:08:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.423
X-Spam-Level: 
X-Spam-Status: No, score=-10.423 tagged_above=-999 required=5 tests=[AWL=0.176, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id imQ3eK93HZaG; Tue, 30 Apr 2013 04:08:10 -0700 (PDT)
Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 9C73721F9AF0; Tue, 30 Apr 2013 04:08:10 -0700 (PDT)
X-TACSUNS: Virus Scanned
Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r3UB86hR005203; Tue, 30 Apr 2013 13:08:06 +0200 (CEST)
Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r3UB7Fm7023462; Tue, 30 Apr 2013 13:07:31 +0200 (CEST)
Message-ID: <517FA5E3.2010604@cisco.com>
Date: Tue, 30 Apr 2013 13:07:15 +0200
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5
MIME-Version: 1.0
To: Martin Bjorklund 
References: <20130427.093659.369612374.mbj@tail-f.com> <20130430.122049.1111664509032933339.mbj@tail-f.com>
In-Reply-To: <20130430.122049.1111664509032933339.mbj@tail-f.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: ietfdbh@comcast.net, ietf@ietf.org, netmod@ietf.org
Subject: Re: [netmod] Last Call:  (A YANG Data Model for Interface Management) to Proposed Standard
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 30 Apr 2013 11:08:15 -0000

Martin,

It's interesting to note that Dave came up with similar feedback as I 
had during my AD review.
And you had to re-explain this again, via email. This leads me to think 
that we need some more background information, typically in "Operational 
Considerations" section.
http://tools.ietf.org/html/draft-ietf-netmod-interfaces-cfg-10#section-4 
could be part of that new section, but other topics could/should be 
addressed:
- Failure to sync the ifIndex
- is there a reason why "description" value MAY match IF-MIB ifAlias 
***and MAY restrict the values***?
-  what should an NM application or operator do if the YANG oper-status 
and the IF-MIB operStatus differ?
- persistence
- Is it expected that counters in ietf-interfaces and counters in IF-MIB 
are synchronized?
- etc...

Basically addressing many points made by Dave

Regards, Benoit
> Hi David,
>
> Thank you for your detailed review!  Comments inline.
>
> David Harrington  wrote:
>> Hi,
>>   
>> I have reviewed this document and feel that is almost ready for approval.
>> This document defines a new data model in YANG format, based on the same
>> information model as the Interfaces MIB module (IF-MIB).
>> Effectively, the YANG model is a second (duplicative) standard for much of
>> the same information.
>> It is expected that devices may implement both the MIB and the YANG data
>> models.
>>   
>> My primary concern regards co-existence and synchronization across data
>> models.
>> I think this document would benefit from an Operational Considerations
>> section that discusses synchronization, or an explanation why they might
>> reasonably be out-of-sync.
>> Here are a few points to consider:
>>   
>> 1) the ifIndex of an interface is used within the YANG model, matching the
>> ifIndex in IF-MIB.
>> RFC2863 discusses the fact that ifIndex numbering might change during
>> hot-swaps.
> Actually, RFC 2863 points out that a ifIndex must not be reused until
> after the following re-initialization of the network management
> system.
>
>> This document does not discuss the need to ensure that IF-MIB ifIndex
>> changes need to be reflected in the YANG model.
>> The ifIndex in the YANG module must match that in IF-MIB (really, that in
>> the underlying instrumentation).
> Absolutely!  That's the intention.  The description for the read-only
> leaf if-index says:
>
>             The ifIndex value for the ifEntry represented by this
>             interface.
>
>
>> Failure to sync the ifIndex could lead NM applications to confuse which
>> already-retrieved data records are related to which interface.
>> This could cause an NM application to misinterpret/corrupt gathered
>> trending information, and possibly to apply changes to the wrong
>> interfaces.
> Fully agree - this is why the if-index is present; to facilitate the
> mapping between the models.
>
>> 2) ifType - can an interface be hot-swapped to use a different type? Is
>> this discussed someplace?
> Hot-swapping sounds like a physical property.  The data model in this
> document can handle this -- provided the system physically supports
> it, of course.  Note that the type is a writable leaf just like
> others.  You can change it, but as with any other leaf a device that
> cannot support a particular change will reject it.
>
>> 3) ifType - the description says the value of this mandatory object MAY be
>> initialized. What value should an NM application expect if it is NOT
>> initialized?
> None.  And since it is mandatory, in this case the NM application has
> to explicitly provide the type.  If you write a completely generic NM
> application you would probably always provide the type, since you
> cannot count on the server auto-initializing it.  But if you *know*
> that the server auto-initialize the type, you don't have to provide
> it.
>
>> 4) enabled - "Systems that implement the IF-MIB use the value of this leaf
>> to set IF-MIB.ifAdminStatus ..."; should this be a MAY/SHOULD/MUST? How
>> will this coexist with SNMP-based NM applications? Is there potential for
>> conflict? What if NETCONF sets this as enabled, then an operator sets it
>> to disabled via SNMP?
>> Does NETCONF know that its "enable" value (adminStatus) is out of date?
>> (does it matter? See note 7).
>> What if the NETCONF system directky changes the underlying instrumentation
>> for adminstatus without going through the MIB?
> It is not clear to me if we can / want to require that these objects
> share the same instrumentation.
>
> Some of this might be b/c ifAdminStatus is a a bit unclear in some
> regards.  For example, it talks about how
>
>              per configuration information
>              retained by the managed system, ifAdminStatus is then
>              changed [...]
>
> I would assume (but this might be incorrect) that the "configuration
> information" could be things configured through the CLI for example,
> and this "configuration information" could thus also be the data
> defined in this YANG model.
>
> So it seems RFC 2863 makes a distinction between ifAdminStatus and
> what is actually configured.
>
> Also, the description of ifAdminStatus doesn't say anything about
> persistence, so it might be impossible to map this to the persistently
> stored configuration.
>
>
>> 5) is there a reason why "description" value MAY match IF-MIB ifAlias
>> ***and MAY restrict the values***?
>> Is there a particular use case for this lack of standardization of
>> restrictions across data models?
>> The persistence is a pretty important restriction related to the
>> functionality of ifAlias, and the dynamism of ifIndex.
>> If NETCONF is used to set the value, ignoring IF-MIB restrictions, what
>> happens to IF-MIB ifAlias as a persistent "handle" to the interface?
> The only reason the "description" leaf is mapped to ifAlias is b/c
> this is what many implementations do.  So we wanted to point out the
> differences in the value space for these objects so that implementers
> are aware of this.
>
> And of course it is not possible to actually set *ifAlias* and ignore
> its syntax constraints.  However, you can use non 7-bit ascii in
> "description", and in this case the "description" value cannot be used
> unmodified as ifAlias.
>
>> 6) What error is returned via NETCONF if YANG attempts to set a value that
>> violates the SNMP agent implementation restrictions, and the SNMP agent
>> refuses the requested SET operation to ifAlias?
> The draft says:
>
>             If a NETCONF server that implements this restriction is
>             sent a value that doesn't match the restriction, it MUST
>             reply with an rpc-error with the error-tag
>             'invalid-value'.
>
>> Is there a simple way for an operator to tell whether the implementation
>> supports the restrictions (other than deliberately triggering an error)?
> No.
>
>> 7) what should an NM application or operator do if the YANG oper-status
>> and the IF-MIB operStatus differ?
> The intention is that they share the same instrumentation.
>
>> IF-MIB has substantial discussion of the relationship between
>> ifAdminStatus and ifOperStatus. The YANG module doesn't have a comparable
>> discussion.
> Which text in the MIB do you mean?  There is some text in the
> description of "oper-status".
>
>> Given that there could e additional delay incurred between setting enable,
>> updating ifAdminStatus, the change to ifOperStatus, and the update to
>> oper-status, I recommend some mention in the description of enable and/or
>> oper-status of the detailed description in RFC2863, and applicability to
>> ietf-interfaces.
>>   
>> 8) link-up-down-trap-enable: The text says this "indicates" whether traps
>> should be generated for the interface; shouldn't this be "configures"?
> Or maybe "Controls ..."?
>
>> 9) persistence isn't discussed in the config object descriptions. Do they
>> match the IF-MIB object persistences?
> Persistence in NETCONF is different from SNMP, in general.  In NETCONF,
> the persistence is defined by the data store where you write the data.
>
>
>> 10) IF-MIB counters do not typically start at zero; a delta must be
>> calculated. This is a common misunderstanding for new MIB developers and
>> users.
>> I don't see any comparable discussion related to ietf-interfaces counters.
>> Where should one look for a discussion of YANG counter initialization
>> values?
>> Where should one look for a discussion of YANG counter rollover?
> The couters are defined as yang:counter32 and yang:counter64.  The
> "yang" prefix means module "ietf-yang-types".  This module is defined
> in RFC 6021.  This RFC discusses initial values and discontinuities.
>
> (ok, this was also suggested by yourself further below!)
>
>> It would help to have a discussion of how to utilize discontinuity_time
>> and counters, especially for implementers not familiar with SNMP (and not
>> implementing IF-MIB).
>>   
>> 11) Is it expected that counters in ietf-interfaces and counters in IF-MIB
>> are synchronized? Can an NM application reasonably compare two readings -
>> one of in-octets and one of ifHCInOctets? If not, I think that should be
>> made clear. (The reference clauses seem to link them)
> I think the intention is that the instrumentation is shared.  There is
> most probably a single hw register / kernel counter for these objects,
> and this is what will be used for these counters.
>
>> 12) From IF-MIB: "Discontinuities in the value of this counter can occur
>> at re-initialization of the management system, and at other times as
>> indicated by the value of ifCounterDiscontinuityTime."
>>  From ietf-interfaces: "Discontinuities in the value of this counter can
>> occur at re-initialization of the management system, and at other times as
>> indicated by the value of 'discontinuity-time'."
>> I think it is ambiguous as to whether both sets of text refer to the same
>> "management system". Is the IF-MIB management-system the SNMP agent? And
>> the YANG management-system the YANG server? Or are both based on the
>> underlying (e.g, hardware or native) management system?
> Good question!  The term is not defined anywhere (as far as I know),
> and thus there is some liberty in the interpretation of it.  But I
> don't think it matters.  It seems unlikely that a
> NM application sometimes reads a counter over SNMP and sometimes the
> same counter from the same device over NETCONF and then compare the
> values.
>
>> Are ifCounterDiscontinuityTime and discontinuity-time synchronized or
>> independent? If they are independent, then the YANG counters and MIB
>> counters could contain very different values; it might help operators to
>> have this pointed out.
> See above.  There is no requirement that they MUST be synchronized,
> but they surely can be.
>
>> It might help implementers to know whether to try
>> to synchronize them or not.
>> Can an operator force restart of both YANG and MIB systems to force
>> synchronization of counters?
> No.  Is there a way to force a restart of the "MIB system"?
>
>> 13) Some of the questions about counters might be covered in yang-types;
>> it would help if the imports clause indicated the relevant RFCs.
> As a comment?  I will raise this issue in the WG.
>
>> 14) IF-MIB has both 32-bit and 64-bit counters; YANG only duplicates the
>> 64-bit counters, generally. It might be good to discuss this in an
>> Operations Considerations section, to explain some potential anomalies at
>> the NM application side.
> In practice I don't think this is a problem.  It seems unlikely that a
> NM application sometimes reads a counter over SNMP and sometimes the
> same counter from the same device over NETCONF and then compare the
> values.
>
>> 15) ietf-interfaces can modify the SNMP trap-enable settings; enabling
>> lots of traps could impact denial of service, disabling could hide
>> interface changes made by an attacker; it should probably be mentioned in
>> security considerations.
> I was thinking we could simply reference the Security Considerations
> section in RFC 2863 for this, but it doesn't discuss this.
>
>> 16) Many operators/developers may have experience with IF-MIB, and some
>> applications might be rewritten to utilize ietf-interfaces rather than (or
>> to supplement) IF-MIB. Not all IF-MIB objects are reflected in
>> ietf-interfaces; it might be helpful to show which IF-MIB objects are not
>> mapped to ietf-interfaces, and discuss why, and whether comparable info
>> can be derived using other YANG approaches.
>>   
>> 17) The copyright in the module description clause needs updating.
> Ok.
>
>
>
> /martin
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>
>


From bclaise@cisco.com  Tue Apr 30 04:26:50 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DE6D21F9ADF; Tue, 30 Apr 2013 04:26:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.438
X-Spam-Level: 
X-Spam-Status: No, score=-10.438 tagged_above=-999 required=5 tests=[AWL=0.161, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k8zdKZOAgCCG; Tue, 30 Apr 2013 04:26:46 -0700 (PDT)
Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id C3C8B21F9ADB; Tue, 30 Apr 2013 04:26:45 -0700 (PDT)
X-TACSUNS: Virus Scanned
Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r3UBQcAt007230; Tue, 30 Apr 2013 13:26:38 +0200 (CEST)
Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r3UBPkZw010198; Tue, 30 Apr 2013 13:26:01 +0200 (CEST)
Message-ID: <517FAA3A.4080904@cisco.com>
Date: Tue, 30 Apr 2013 13:25:46 +0200
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5
MIME-Version: 1.0
To: Martin Bjorklund 
References: <20130427.093659.369612374.mbj@tail-f.com> <20130430.122049.1111664509032933339.mbj@tail-f.com> <517FA5E3.2010604@cisco.com>
In-Reply-To: <517FA5E3.2010604@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: ietfdbh@comcast.net, ietf@ietf.org, netmod@ietf.org
Subject: Re: [netmod] Last Call:  (A YANG Data Model for Interface Management) to Proposed Standard
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 30 Apr 2013 11:26:50 -0000

On 30/04/2013 13:07, Benoit Claise wrote:
> Martin,
>
> It's interesting to note that Dave came up with similar feedback as I 
> had during my AD review.
> And you had to re-explain this again, via email. This leads me to 
> think that we need some more background information, typically in 
> "Operational Considerations" section.
> http://tools.ietf.org/html/draft-ietf-netmod-interfaces-cfg-10#section-4 
> could be part of that new section, but other topics could/should be 
> addressed:
> - Failure to sync the ifIndex
> - is there a reason why "description" value MAY match IF-MIB ifAlias 
> ***and MAY restrict the values***?
> -  what should an NM application or operator do if the YANG 
> oper-status and the IF-MIB operStatus differ?
> - persistence
> - Is it expected that counters in ietf-interfaces and counters in 
> IF-MIB are synchronized?
> - etc...
>
> Basically addressing many points made by Dave
And I see that Carlos, part of the "Re: RtgDir review: 
draft-ietf-netmod-interfaces-cfg-10.txt" feedback has got some similar  
points.
- physical versus virtual interfaces
- location
- counter32 and counter64, and mapping to the MIB OIDs
- etc...

That reinforces in my thinking that we need an "operational 
considerations" section.

Regards, Benoit
>
> Regards, Benoit
>> Hi David,
>>
>> Thank you for your detailed review!  Comments inline.
>>
>> David Harrington  wrote:
>>> Hi,
>>>   I have reviewed this document and feel that is almost ready for 
>>> approval.
>>> This document defines a new data model in YANG format, based on the 
>>> same
>>> information model as the Interfaces MIB module (IF-MIB).
>>> Effectively, the YANG model is a second (duplicative) standard for 
>>> much of
>>> the same information.
>>> It is expected that devices may implement both the MIB and the YANG 
>>> data
>>> models.
>>>   My primary concern regards co-existence and synchronization across 
>>> data
>>> models.
>>> I think this document would benefit from an Operational Considerations
>>> section that discusses synchronization, or an explanation why they 
>>> might
>>> reasonably be out-of-sync.
>>> Here are a few points to consider:
>>>   1) the ifIndex of an interface is used within the YANG model, 
>>> matching the
>>> ifIndex in IF-MIB.
>>> RFC2863 discusses the fact that ifIndex numbering might change during
>>> hot-swaps.
>> Actually, RFC 2863 points out that a ifIndex must not be reused until
>> after the following re-initialization of the network management
>> system.
>>
>>> This document does not discuss the need to ensure that IF-MIB ifIndex
>>> changes need to be reflected in the YANG model.
>>> The ifIndex in the YANG module must match that in IF-MIB (really, 
>>> that in
>>> the underlying instrumentation).
>> Absolutely!  That's the intention.  The description for the read-only
>> leaf if-index says:
>>
>>             The ifIndex value for the ifEntry represented by this
>>             interface.
>>
>>
>>> Failure to sync the ifIndex could lead NM applications to confuse which
>>> already-retrieved data records are related to which interface.
>>> This could cause an NM application to misinterpret/corrupt gathered
>>> trending information, and possibly to apply changes to the wrong
>>> interfaces.
>> Fully agree - this is why the if-index is present; to facilitate the
>> mapping between the models.
>>
>>> 2) ifType - can an interface be hot-swapped to use a different type? Is
>>> this discussed someplace?
>> Hot-swapping sounds like a physical property.  The data model in this
>> document can handle this -- provided the system physically supports
>> it, of course.  Note that the type is a writable leaf just like
>> others.  You can change it, but as with any other leaf a device that
>> cannot support a particular change will reject it.
>>
>>> 3) ifType - the description says the value of this mandatory object 
>>> MAY be
>>> initialized. What value should an NM application expect if it is NOT
>>> initialized?
>> None.  And since it is mandatory, in this case the NM application has
>> to explicitly provide the type.  If you write a completely generic NM
>> application you would probably always provide the type, since you
>> cannot count on the server auto-initializing it.  But if you *know*
>> that the server auto-initialize the type, you don't have to provide
>> it.
>>
>>> 4) enabled - "Systems that implement the IF-MIB use the value of 
>>> this leaf
>>> to set IF-MIB.ifAdminStatus ..."; should this be a MAY/SHOULD/MUST? How
>>> will this coexist with SNMP-based NM applications? Is there 
>>> potential for
>>> conflict? What if NETCONF sets this as enabled, then an operator 
>>> sets it
>>> to disabled via SNMP?
>>> Does NETCONF know that its "enable" value (adminStatus) is out of date?
>>> (does it matter? See note 7).
>>> What if the NETCONF system directky changes the underlying 
>>> instrumentation
>>> for adminstatus without going through the MIB?
>> It is not clear to me if we can / want to require that these objects
>> share the same instrumentation.
>>
>> Some of this might be b/c ifAdminStatus is a a bit unclear in some
>> regards.  For example, it talks about how
>>
>>              per configuration information
>>              retained by the managed system, ifAdminStatus is then
>>              changed [...]
>>
>> I would assume (but this might be incorrect) that the "configuration
>> information" could be things configured through the CLI for example,
>> and this "configuration information" could thus also be the data
>> defined in this YANG model.
>>
>> So it seems RFC 2863 makes a distinction between ifAdminStatus and
>> what is actually configured.
>>
>> Also, the description of ifAdminStatus doesn't say anything about
>> persistence, so it might be impossible to map this to the persistently
>> stored configuration.
>>
>>
>>> 5) is there a reason why "description" value MAY match IF-MIB ifAlias
>>> ***and MAY restrict the values***?
>>> Is there a particular use case for this lack of standardization of
>>> restrictions across data models?
>>> The persistence is a pretty important restriction related to the
>>> functionality of ifAlias, and the dynamism of ifIndex.
>>> If NETCONF is used to set the value, ignoring IF-MIB restrictions, what
>>> happens to IF-MIB ifAlias as a persistent "handle" to the interface?
>> The only reason the "description" leaf is mapped to ifAlias is b/c
>> this is what many implementations do.  So we wanted to point out the
>> differences in the value space for these objects so that implementers
>> are aware of this.
>>
>> And of course it is not possible to actually set *ifAlias* and ignore
>> its syntax constraints.  However, you can use non 7-bit ascii in
>> "description", and in this case the "description" value cannot be used
>> unmodified as ifAlias.
>>
>>> 6) What error is returned via NETCONF if YANG attempts to set a 
>>> value that
>>> violates the SNMP agent implementation restrictions, and the SNMP agent
>>> refuses the requested SET operation to ifAlias?
>> The draft says:
>>
>>             If a NETCONF server that implements this restriction is
>>             sent a value that doesn't match the restriction, it MUST
>>             reply with an rpc-error with the error-tag
>>             'invalid-value'.
>>
>>> Is there a simple way for an operator to tell whether the 
>>> implementation
>>> supports the restrictions (other than deliberately triggering an 
>>> error)?
>> No.
>>
>>> 7) what should an NM application or operator do if the YANG oper-status
>>> and the IF-MIB operStatus differ?
>> The intention is that they share the same instrumentation.
>>
>>> IF-MIB has substantial discussion of the relationship between
>>> ifAdminStatus and ifOperStatus. The YANG module doesn't have a 
>>> comparable
>>> discussion.
>> Which text in the MIB do you mean?  There is some text in the
>> description of "oper-status".
>>
>>> Given that there could e additional delay incurred between setting 
>>> enable,
>>> updating ifAdminStatus, the change to ifOperStatus, and the update to
>>> oper-status, I recommend some mention in the description of enable 
>>> and/or
>>> oper-status of the detailed description in RFC2863, and 
>>> applicability to
>>> ietf-interfaces.
>>>   8) link-up-down-trap-enable: The text says this "indicates" 
>>> whether traps
>>> should be generated for the interface; shouldn't this be "configures"?
>> Or maybe "Controls ..."?
>>
>>> 9) persistence isn't discussed in the config object descriptions. Do 
>>> they
>>> match the IF-MIB object persistences?
>> Persistence in NETCONF is different from SNMP, in general.  In NETCONF,
>> the persistence is defined by the data store where you write the data.
>>
>>
>>> 10) IF-MIB counters do not typically start at zero; a delta must be
>>> calculated. This is a common misunderstanding for new MIB developers 
>>> and
>>> users.
>>> I don't see any comparable discussion related to ietf-interfaces 
>>> counters.
>>> Where should one look for a discussion of YANG counter initialization
>>> values?
>>> Where should one look for a discussion of YANG counter rollover?
>> The couters are defined as yang:counter32 and yang:counter64. The
>> "yang" prefix means module "ietf-yang-types".  This module is defined
>> in RFC 6021.  This RFC discusses initial values and discontinuities.
>>
>> (ok, this was also suggested by yourself further below!)
>>
>>> It would help to have a discussion of how to utilize discontinuity_time
>>> and counters, especially for implementers not familiar with SNMP 
>>> (and not
>>> implementing IF-MIB).
>>>   11) Is it expected that counters in ietf-interfaces and counters 
>>> in IF-MIB
>>> are synchronized? Can an NM application reasonably compare two 
>>> readings -
>>> one of in-octets and one of ifHCInOctets? If not, I think that 
>>> should be
>>> made clear. (The reference clauses seem to link them)
>> I think the intention is that the instrumentation is shared. There is
>> most probably a single hw register / kernel counter for these objects,
>> and this is what will be used for these counters.
>>
>>> 12) From IF-MIB: "Discontinuities in the value of this counter can 
>>> occur
>>> at re-initialization of the management system, and at other times as
>>> indicated by the value of ifCounterDiscontinuityTime."
>>>  From ietf-interfaces: "Discontinuities in the value of this counter 
>>> can
>>> occur at re-initialization of the management system, and at other 
>>> times as
>>> indicated by the value of 'discontinuity-time'."
>>> I think it is ambiguous as to whether both sets of text refer to the 
>>> same
>>> "management system". Is the IF-MIB management-system the SNMP agent? 
>>> And
>>> the YANG management-system the YANG server? Or are both based on the
>>> underlying (e.g, hardware or native) management system?
>> Good question!  The term is not defined anywhere (as far as I know),
>> and thus there is some liberty in the interpretation of it.  But I
>> don't think it matters.  It seems unlikely that a
>> NM application sometimes reads a counter over SNMP and sometimes the
>> same counter from the same device over NETCONF and then compare the
>> values.
>>
>>> Are ifCounterDiscontinuityTime and discontinuity-time synchronized or
>>> independent? If they are independent, then the YANG counters and MIB
>>> counters could contain very different values; it might help 
>>> operators to
>>> have this pointed out.
>> See above.  There is no requirement that they MUST be synchronized,
>> but they surely can be.
>>
>>> It might help implementers to know whether to try
>>> to synchronize them or not.
>>> Can an operator force restart of both YANG and MIB systems to force
>>> synchronization of counters?
>> No.  Is there a way to force a restart of the "MIB system"?
>>
>>> 13) Some of the questions about counters might be covered in 
>>> yang-types;
>>> it would help if the imports clause indicated the relevant RFCs.
>> As a comment?  I will raise this issue in the WG.
>>
>>> 14) IF-MIB has both 32-bit and 64-bit counters; YANG only duplicates 
>>> the
>>> 64-bit counters, generally. It might be good to discuss this in an
>>> Operations Considerations section, to explain some potential 
>>> anomalies at
>>> the NM application side.
>> In practice I don't think this is a problem.  It seems unlikely that a
>> NM application sometimes reads a counter over SNMP and sometimes the
>> same counter from the same device over NETCONF and then compare the
>> values.
>>
>>> 15) ietf-interfaces can modify the SNMP trap-enable settings; enabling
>>> lots of traps could impact denial of service, disabling could hide
>>> interface changes made by an attacker; it should probably be 
>>> mentioned in
>>> security considerations.
>> I was thinking we could simply reference the Security Considerations
>> section in RFC 2863 for this, but it doesn't discuss this.
>>
>>> 16) Many operators/developers may have experience with IF-MIB, and some
>>> applications might be rewritten to utilize ietf-interfaces rather 
>>> than (or
>>> to supplement) IF-MIB. Not all IF-MIB objects are reflected in
>>> ietf-interfaces; it might be helpful to show which IF-MIB objects 
>>> are not
>>> mapped to ietf-interfaces, and discuss why, and whether comparable info
>>> can be derived using other YANG approaches.
>>>   17) The copyright in the module description clause needs updating.
>> Ok.
>>
>>
>>
>> /martin
>> _______________________________________________
>> 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 mbj@tail-f.com  Tue Apr 30 04:29:55 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70F4F21F9B84 for ; Tue, 30 Apr 2013 04:29:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.146
X-Spam-Level: 
X-Spam-Status: No, score=-2.146 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WyM2DSTnrCl9 for ; Tue, 30 Apr 2013 04:29:50 -0700 (PDT)
Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id BE4F121F9ADF for ; Tue, 30 Apr 2013 04:29:44 -0700 (PDT)
Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id D24DA12008B7; Tue, 30 Apr 2013 13:29:43 +0200 (CEST)
Date: Tue, 30 Apr 2013 13:29:43 +0200 (CEST)
Message-Id: <20130430.132943.828559691589933098.mbj@tail-f.com>
To: bclaise@cisco.com
From: Martin Bjorklund 
In-Reply-To: <517FA5E3.2010604@cisco.com>
References: <20130427.093659.369612374.mbj@tail-f.com> <20130430.122049.1111664509032933339.mbj@tail-f.com> <517FA5E3.2010604@cisco.com>
X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Cc: ietfdbh@comcast.net, netmod@ietf.org
Subject: Re: [netmod] Last Call:  (A YANG Data Model for Interface Management) to Proposed Standard
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 30 Apr 2013 11:29:55 -0000

Hi,

I am pruning the Cc a bit so we can discuss this in the WG first.

Benoit Claise  wrote:
> Martin,
> 
> It's interesting to note that Dave came up with similar feedback as I
> had during my AD review.
> And you had to re-explain this again, via email. This leads me to
> think that we need some more background information, typically in
> "Operational Considerations" section.
> http://tools.ietf.org/html/draft-ietf-netmod-interfaces-cfg-10#section-4
> could be part of that new section, but other topics could/should be
> addressed:
> - Failure to sync the ifIndex

Apparently, the current text somehow seems to imply that there is a
synchronization problem.  But to be honest, I cannot see why.  This is
the current text:

      leaf if-index {
        config false;
        ...
        description    
          "The ifIndex value for the ifEntry represented by this
           interface.
           ...";
      }

So we have a config false leaf that is described as being the ifIndex
value of the ifEntry.   Please help me to improve this text so the
meaning is clear.


> - is there a reason why "description" value MAY match IF-MIB ifAlias
> - ***and MAY restrict the values***?

Ok, I suggest we add a paragraph like this:

  The configured "description" of an "interface" has traditionally
  been mapped to ifAlias in some implementations.  This document allow
  this mapping, but implementers should be aware of the differences in
  the value space for these objects.


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

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

> - persistence

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

> - Is it expected that counters in ietf-interfaces and counters in IF-MIB
> - are synchronized?

Again, I don't really see the problem, and I do not understand what it
means for counters to be synchronized.  Please suggest some text to
add.



/martin

From lhotka@nic.cz  Tue Apr 30 04:41:59 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A33D21F9B61; Tue, 30 Apr 2013 04:41:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.699
X-Spam-Level: 
X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, J_CHICKENPOX_65=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i4K0gPKW4WW1; Tue, 30 Apr 2013 04:41:58 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id A938E21F99A2; Tue, 30 Apr 2013 04:41:58 -0700 (PDT)
Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id D2E3E13FCB8; Tue, 30 Apr 2013 13:41:57 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1367322117; bh=nWFAnvatfzsadZmcDwSzWOjNBgqz34N95M0PAIF65Gc=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=iwjx6JrPVtkQLN3MEl5bbikO9xs+yb7xWI4L0Ac4DsVB1nHjCBB8PHa29YuzBBZls 9N6DtHo+T6pDXYUw0SLE0isXOpxHw4v2sAIY455wQif0v3XMnBoPRx1SF0R2R/U1f5 N7N0iFPXcuqCla+qBs3b4q3pSin8s7EWFrg7MXuo=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
From: Ladislav Lhotka 
In-Reply-To: <20130430.122049.1111664509032933339.mbj@tail-f.com>
Date: Tue, 30 Apr 2013 13:41:47 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <8BE80629-8A71-4AB1-B008-35DEF750E4FB@nic.cz>
References: <20130427.093659.369612374.mbj@tail-f.com> <20130430.122049.1111664509032933339.mbj@tail-f.com>
To: Martin Bjorklund 
X-Mailer: Apple Mail (2.1503)
X-Virus-Scanned: clamav-milter 0.97.7 at mail
X-Virus-Status: Clean
Cc: ietfdbh@comcast.net, ietf@ietf.org, netmod@ietf.org
Subject: Re: [netmod] Last Call:  (A YANG Data Model for Interface Management) to Proposed Standard
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 30 Apr 2013 11:41:59 -0000

On Apr 30, 2013, at 12:20 PM, Martin Bjorklund  wrote:

>>=20
>> 5) is there a reason why "description" value MAY match IF-MIB ifAlias=20=

>> ***and MAY restrict the values***?=20
>> Is there a particular use case for this lack of standardization of=20
>> restrictions across data models?=20
>> The persistence is a pretty important restriction related to the=20
>> functionality of ifAlias, and the dynamism of ifIndex.=20
>> If NETCONF is used to set the value, ignoring IF-MIB restrictions, =
what=20
>> happens to IF-MIB ifAlias as a persistent "handle" to the interface?=20=

>=20
> The only reason the "description" leaf is mapped to ifAlias is b/c
> this is what many implementations do.  So we wanted to point out the

I think it is a dubious practice.

> differences in the value space for these objects so that implementers
> are aware of this.
>=20
> And of course it is not possible to actually set *ifAlias* and ignore
> its syntax constraints.  However, you can use non 7-bit ascii in
> "description", and in this case the "description" value cannot be used
> unmodified as ifAlias.

If I correctly understand IF-MIB, a natural mapping would be

       +----------------------------------+------------------------+
       | YANG data node                   | IF-MIB object          |
       +----------------------------------+------------------------+
       | name                             | ifAlias                |
       | local-name                       | ifName                 |
       +----------------------------------+------------------------+

with "local-name" being a new config=3Dfalse leaf. The "location" leaf =
then could be removed.
The lack of correspondence between "name" and "ifName" is somewhat =
confusing, so perhaps an alternative could be to follow suit of IF-MIB =
and use "alias" (=3D=3D ifAlias) as the key of interface list, and =
"name" (=3D=3D ifName) as the config=3Dfalse local name.=20

Lada


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





From j.schoenwaelder@jacobs-university.de  Tue Apr 30 04:49:12 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1FF221F9A52; Tue, 30 Apr 2013 04:49:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.249
X-Spam-Level: 
X-Spam-Status: No, score=-103.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rYhmVz2y4gMC; Tue, 30 Apr 2013 04:49:08 -0700 (PDT)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id EF90521F9B2F; Tue, 30 Apr 2013 04:49:07 -0700 (PDT)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7367B20C12; Tue, 30 Apr 2013 13:49:07 +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 2Mg_MdkrI39T; Tue, 30 Apr 2013 13:49: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 D35A520C06; Tue, 30 Apr 2013 13:49:06 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id D66D825EB6AA; Tue, 30 Apr 2013 13:49:05 +0200 (CEST)
Date: Tue, 30 Apr 2013 13:49:05 +0200
From: Juergen Schoenwaelder 
To: Benoit Claise , "Joel M. Halpern" 
Message-ID: <20130430114905.GA47531@elstar.local>
Mail-Followup-To: Benoit Claise , "Joel M. Halpern" , draft-ietf-netmod-rfc6021-bis.all@tools.ietf.org, gen-art@ietf.org, netmod@ietf.org
References: <5171C416.5070105@joelhalpern.com> <517F9AEF.8090601@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <517F9AEF.8090601@cisco.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: draft-ietf-netmod-rfc6021-bis.all@tools.ietf.org, gen-art@ietf.org, netmod@ietf.org
Subject: Re: [netmod] Fwd: [Gen-art] Review: draft-ietf-netmod-rfc6021-bis-01
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 30 Apr 2013 11:49:12 -0000

On Tue, Apr 30, 2013 at 12:20:31PM +0200, Benoit Claise wrote:
> Hi,
> 
> Just making sure that you saw this one.
> Next to the APPSDIR review, I believe that this is the one review left.
> 

Thanks for forwarding this. Answers inline. Thanks to Joel Halpern to
review this document.

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

Joel,

note that ip4-address-no-zone and ipv6-address-no-zone are _derived_
from the ipv4-address and ipv6-address types:

     typedef ipv4-address-no-zone {
       type inet:ipv4-address {
         pattern '[\.0-9]*';
       }
       // ...
     }

     typedef ipv6-address-no-zone {
       type inet:ipv6-address {
         pattern '[0-9a-fA-F:]*';
       }
       // ...
     }

This means that all rules for ipv4-address and ipv6-address
respectively apply and in addition the patterns for
ip4-address-no-zone and ipv6-address-no-zone apply. In other words,
the pattern in the -no-zone versions only aim to eliminate the zone
identifier by eliminating the % symbol.

Your comment, however, made Lada discover that I missed to allow the
. for IPv4-mapped IPv6 addresses. This was not my intention and is
indeed a bug that I think needs to be fixed. There is a thread on the
netmod mailing list about this.
 
> Minor issues:
> 
> Nits/editorial comments:
> 

/js

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

From j.schoenwaelder@jacobs-university.de  Tue Apr 30 04:51:50 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9F2021F99AE for ; Tue, 30 Apr 2013 04:51:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.249
X-Spam-Level: 
X-Spam-Status: No, score=-103.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2bVbnpVnX96q for ; Tue, 30 Apr 2013 04:51:43 -0700 (PDT)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 7022021F982F for ; Tue, 30 Apr 2013 04:51:43 -0700 (PDT)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id EBEEE20C12; Tue, 30 Apr 2013 13:51:42 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id w1bsgpbkSc2N; Tue, 30 Apr 2013 13:51: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 263F220C06; Tue, 30 Apr 2013 13:51:42 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id E644125EB6E9; Tue, 30 Apr 2013 13:51:41 +0200 (CEST)
Date: Tue, 30 Apr 2013 13:51:41 +0200
From: Juergen Schoenwaelder 
To: Ladislav Lhotka 
Message-ID: <20130430115141.GA47662@elstar.local>
Mail-Followup-To: Ladislav Lhotka , Martin Bjorklund , netmod@ietf.org
References: <07AF9ED2-8E39-471C-93E2-E75D4DA92E1E@nic.cz> <20130429.145226.2022342732166602338.mbj@tail-f.com> <63D55653-A803-4011-A362-3F9EE0D564FB@nic.cz>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <63D55653-A803-4011-A362-3F9EE0D564FB@nic.cz>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: netmod@ietf.org
Subject: Re: [netmod] bug in ipv6-address-no-zone
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 30 Apr 2013 11:51:50 -0000

On Mon, Apr 29, 2013 at 03:04:54PM +0200, Ladislav Lhotka wrote:
> 
> On Apr 29, 2013, at 2:52 PM, Martin Bjorklund  wrote:
> 
> > Ladislav Lhotka  wrote:
> >> Hi,
> >> 
> >> the extra pattern in ipv6-address-no-zone (pattern '[0-9a-fA-F:]*';)
> >> is probably incorrect because it eliminates the IPv4-mapped addresses,
> >> such as ::ffff:1.2.3.4. The correct pattern would be
> >> 
> >> pattern '[0-9a-fA-F:.]*';
> > 
> > This should be
> > 
> >  pattern '[0-9a-fA-F:\.]*';
> 
> Actually, no, the dot needn't be escaped in character classes (inside brackets).
> 

I think we need to allow for IPv4-mapped addresses and hence the dot
should be added. Where can I find a definite answer whether the dot
needs backslashing or not? The pattern for ipv4-address-no-zone has a
backslashed dot and I like to get things straight. OK, I figure I have
to check "XML Schema Part 2: Datatypes Second Edition"...

/js

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

From lhotka@nic.cz  Tue Apr 30 05:17:09 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFE9621F9AFC for ; Tue, 30 Apr 2013 05:17:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.924
X-Spam-Level: 
X-Spam-Status: No, score=-1.924 tagged_above=-999 required=5 tests=[AWL=0.075,  BAYES_00=-2.599, J_CHICKENPOX_23=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8QdB30fjlKPX for ; Tue, 30 Apr 2013 05:17:08 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 5AD9221F8E6C for ; Tue, 30 Apr 2013 05:17: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 C051313FCB8; Tue, 30 Apr 2013 14:17:06 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1367324226; bh=jIbd1ALPgAMqGvW5n6UFlo+G7o342jlZqVKhFFGM8DM=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=lbuVuXhvOEDB0rMjdjOGE4MJP9bDxK4GxMsUk/TLt0Z6TZna+QN+Bn+UnliR2Lww4 KJJK+QJQ0lYX5VktK/nRwDe3mvzFUnoVD4A25rhk0FlUu5JMQlqrPqymnExnDIiSFl Vk+gecciDF3L2XBh438RanI11bFbru+81dfW8QNI=
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
From: Ladislav Lhotka 
In-Reply-To: <20130430115141.GA47662@elstar.local>
Date: Tue, 30 Apr 2013 14:17:06 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <07AF9ED2-8E39-471C-93E2-E75D4DA92E1E@nic.cz> <20130429.145226.2022342732166602338.mbj@tail-f.com> <63D55653-A803-4011-A362-3F9EE0D564FB@nic.cz> <20130430115141.GA47662@elstar.local>
To: Juergen Schoenwaelder 
X-Mailer: Apple Mail (2.1503)
X-Virus-Scanned: clamav-milter 0.97.7 at mail
X-Virus-Status: Clean
Cc: netmod@ietf.org
Subject: Re: [netmod] bug in ipv6-address-no-zone
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 30 Apr 2013 12:17:10 -0000

On Apr 30, 2013, at 1:51 PM, Juergen Schoenwaelder =
 wrote:

> On Mon, Apr 29, 2013 at 03:04:54PM +0200, Ladislav Lhotka wrote:
>>=20
>> On Apr 29, 2013, at 2:52 PM, Martin Bjorklund  wrote:
>>=20
>>> Ladislav Lhotka  wrote:
>>>> Hi,
>>>>=20
>>>> the extra pattern in ipv6-address-no-zone (pattern =
'[0-9a-fA-F:]*';)
>>>> is probably incorrect because it eliminates the IPv4-mapped =
addresses,
>>>> such as ::ffff:1.2.3.4. The correct pattern would be
>>>>=20
>>>> pattern '[0-9a-fA-F:.]*';
>>>=20
>>> This should be
>>>=20
>>> pattern '[0-9a-fA-F:\.]*';
>>=20
>> Actually, no, the dot needn't be escaped in character classes (inside =
brackets).
>>=20
>=20
> I think we need to allow for IPv4-mapped addresses and hence the dot
> should be added. Where can I find a definite answer whether the dot

But perhaps we should also restrict the pattern so as to allow only =
IPv4-mapped addresses (::ffff:A.B.C.D), or perhaps also the obsolete =
IPv4-compatible addresses (::A.B.C.D). Currently, addresses like

2001:1dbf:cafe:f00:301:42:1.2.0.255

are also valid, which may not be correct.

> needs backslashing or not? The pattern for ipv4-address-no-zone has a
> backslashed dot and I like to get things straight. OK, I figure I have
> to check "XML Schema Part 2: Datatypes Second Edition"=85

I did it yesterday a found the text not very clear on this, but the =
derivation of "charClassExpr" eventually contains "XmlCharIncDash", =
which only excludes left and right square brackets.

In any case, using "\." is OK.

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 cpignata@cisco.com  Tue Apr 30 06:16:31 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8B0921F9820; Tue, 30 Apr 2013 06:16:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.599
X-Spam-Level: 
X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vy9YAUhjI3Dp; Tue, 30 Apr 2013 06:16:26 -0700 (PDT)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 844EB21F9A31; Tue, 30 Apr 2013 06:16:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12449; q=dns/txt; s=iport; t=1367327785; x=1368537385; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=+5/I9U2tWMaTKb1KPqmRgzSzPImRvma8EP5QWYKZ08w=; b=IkRRhZrZ4jiH/mE9pj+jMZ5AOo01xcWmkJmW9VbH9q/jkn2aw5myII0n XrDXMXuuIKeBVlFgp3QIS9SqeWfSNEq6fHCyrqEBw3BHGzgmokvJR7WZ+ YlSNQqZgyiO8izdWmkkviuptM8+Fr6o5H3OyMiiIOgBAgWXHKr4+guNvk Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgkFAGHDf1GtJXHB/2dsb2JhbABIAgiDBzaDN7sgfxZ0gh8BAQEDASEBBUsHBQsCAQgOCgEDBgUYAgMCMhQRAgQOAwIIAYgHBgyUA5sDAYJEjj+BIIw2CAYEfwIxAgWCOTVhA5hEkASDEUCBKgkXHg
X-IronPort-AV: E=Sophos;i="4.87,582,1363132800"; d="scan'208";a="204766871"
Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-6.cisco.com with ESMTP; 30 Apr 2013 13:16:24 +0000
Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r3UDGNnC003938 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 30 Apr 2013 13:16:23 GMT
Received: from xmb-aln-x02.cisco.com ([169.254.5.192]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.02.0318.004; Tue, 30 Apr 2013 08:16:23 -0500
From: "Carlos Pignataro (cpignata)" 
To: Martin Bjorklund 
Thread-Topic: RtgDir review: draft-ietf-netmod-interfaces-cfg-10.txt
Thread-Index: AQHORO7C2y3SdVUEW027VIOCZsJnvJjt/0GAgAAmAoCAAIpsgIAAZBeA
Date: Tue, 30 Apr 2013 13:16:23 +0000
Message-ID: <95067C434CE250468B77282634C96ED322AF88A9@xmb-aln-x02.cisco.com>
References: <95067C434CE250468B77282634C96ED322AF32F4@xmb-aln-x02.cisco.com> <20130429.224641.08727383.mbj@tail-f.com> <95067C434CE250468B77282634C96ED322AF7636@xmb-aln-x02.cisco.com> <20130430.091809.2283109543662828002.mbj@tail-f.com>
In-Reply-To: <20130430.091809.2283109543662828002.mbj@tail-f.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.150.44.101]
Content-Type: text/plain; charset="iso-2022-jp"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "" , "" , "" , "" 
Subject: Re: [netmod] RtgDir review: draft-ietf-netmod-interfaces-cfg-10.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 30 Apr 2013 13:16:31 -0000

Martin,

Thanks again for the short RTT and the details in your response. I think th=
is addresses most/all my concerns; details inline closing the loop.=20

On Apr 30, 2013, at 3:18 AM, Martin Bjorklund 
 wrote:

> Hi,
>=20
> Comments to the remaining issues inline.
>=20
> "Carlos Pignataro (cpignata)"  wrote:
>> On Apr 29, 2013, at 4:46 PM, Martin Bjorklund  wrote:
>>> "Carlos Pignataro (cpignata)"  wrote:
>>>> 3. Interfaces Data Model
>>>> =1B$B!D=1B(B
>>>>           +--ro if-index?                   int32
>>>>=20
>>>> The "?" indicates that the lead is optional. From a routing
>>>> perspective, the
>>>> if-index plays an important role when for example the network layer
>>>> address
>>>> does not identify a specific interface (e.g., IP unnumbered), or when
>>>> there is
>>>> no network layer address (LAG member, etc.). Why is this optional? In
>>>> which
>>>> case you envision it would not be present?
>>>=20
>>> I think you are right; this leaf should be mandatory.  This works
>>> since it has an 'if-feature' statement.
>>>=20
>>=20
>> Thanks. Even if it works because of the clause, I'd make this
>> mandatory.
>=20
> Yes, sorry for not being clear - it should be made mandatory, and I
> meant that it is ok to make it mandatory since we have the
> 'if-feature' statement.
>=20
>=20
>>>> 3. Interfaces Data Model
>>>> =1B$B!D=1B(B
>>>>           +--rw location?                   string
>>>> ...
>>>> 3.1. The interface List
>>>> =1B$B!D=1B(B
>>>>  The "location" leaf is a string.  It is optional in the data model,
>>>>  but if the type represents a physical interface, it is mandatory.
>>>>  The format of this string is device- and type-dependent.  The device
>>>>  uses the location string to identify the physical or logical entity
>>>>  that the configuration applies to.  For example, if a device has a
>>>>  single array of 8 ethernet ports, the location can be one of the
>>>>  strings "1" to "8".  As another example, if a device has N cards of M
>>>>  ports, the location can be on the form "n/m", such as "1/0".
>>>>=20
>>>> I think that "location" is a poorly chosen label, a misnomer. This
>>>> seems to be
>>>> closer to an identifier than a locator. For example, some devices
>>>> number slots
>>>> left to right, and some number slots right to left :-)
>>>=20
>>> Correct, and we do not try to get into this at all.  Some
>>> devices has 2 ports called A and B, and some have chassis of cards
>>> with rows of ports...
>>>=20
>>>> This does not answer
>>>> "where" something is; I do not mean geo-location, but I strongly
>>>> suggest
>>>> getting more precision on how this leaf is called. For example,
>>>> interface
>>>> numbering, instance id, type identifier, etc.
>>>=20
>>> The intention is really to be "where" the port is.  It is not intended
>>> to be a virtual id.  If the operator plugs in a cable in a certain
>>> port, he has to know how to configure this port so there must be
>>> something in the config that connects to the physical port.  We use
>>> the name "location" for this purpose.
>>=20
>> Thanks for the explanation. While I appreciate (and I agree) that you
>> do not get into interpreting or parsing the syntax of the field, I
>> still think it is not a "location".
>>=20
>> I believe there is still an underlying assumption that the language is
>> defined for the physical world. If you have an Ethernet1/0, versus an
>> Ethernet1/2, that identifies (not locates) which interface. Yes, you
>> can use that to physically find them. But what if you have a
>> "loopback123" vs "loopback112358 or a "Serial1/4:5.123"? I do not
>> think we can "locate" the loopback, or the subinterface.
>>=20
>> If the operator creates a "loopback", "Tunnel", or virtual interface,
>> he or she does not need to physically locate it.
>>=20
>> I believe that labeling the leaf as "location" can be harmful as it
>> implies a specific meaning and shows assumptions.
>=20
> Ok I think I understand your concern.  Personally, I think "location"
> works also in this case, but we should pick a name that is as useful
> as possible.  Let me bring this issue back to the WG.
>=20

Thank you. It seems to me you are "identifying" the instance.

>>>> 3. Interfaces Data Model
>>>> =1B$B!D=1B(B
>>>>     +--rw interfaces
>>>>        +--rw interface [name]
>>>>           +--rw =1B$B!D=1B(B
>>>>=20
>>>> Is there a specific reason why there is no lead with the interface's
>>>> MTU? It is
>>>> quite important from a routing perspective for some protocols. MTU is
>>>> not
>>>> included even in the examples of ethernet-specific data models
>>>> augmenting this
>>>> base spec and appendices, which leaves it a bit underspecified=1B$B!D=
=1B(B
>>>=20
>>> The mtu is specified in an accompanying document draft-ietf-netmod-ip.
>>>=20
>>=20
>> What draft-ietf-netmod-ip describes is the network-layer IPv4 MTU and
>> IPv6 MTU. It does not describe the interface MTU. If that interface is
>> used to run IS-IS, or to run MPLS, what is the MTU? It's neither the
>> IPv4 MTU nor the IPv6 MTU.
>=20
> This topic was discussed in the WG.  The result was that we did not
> beleive we could define a generic mtu on the interface that would be
> applicable to all types of interfaces.  Media-specific modules can
> define this (maybe both configuration knobs and operational values).
>=20
>=20

OK, thanks. I still think that this is a big gap. Even the ethernet-specifi=
c examples that the document includes, do not include MTU configuration. A =
number of protocols break without MTU defined. I agree with defining IPv4 a=
nd IPv6 specific MTUs in the netmod-ip document, but it still seems to me t=
hat the interface MTU is fundamental and generic enough to be defined (that=
 might not be applicable to every interface but enough ubiquitousness to be=
 defined and call out exceptions).

That said, I just read the thread at http://www.ietf.org/mail-archive/web/n=
etmod/current/msg07422.html and I can see it fit in media-specific modules.=
 However, those are not defined (and I expect that might not be defined for=
 every media, tunneling encap, etc.)=20

>>>> What is the information model on which
>>>> this data model stands? If there was not RFC 2863, would a leaf be
>>>> defined as
>>>> ifPromiscuousMode or phys-address? Or would that belong in an
>>>> ethernet-specific
>>>> module?
>>>=20
>>> You are right that phys-address might not have been included.
>>>=20
>>=20
>> OK, thanks. Do you mean that you will be removing it?
>=20
> I will have to bring this to the WG.
>=20

Thank you.

>>>> In terms of the examples, basically all examples are some form of
>>>> ethernet
>>>> interface. For a document that aims at being general for managing
>>>> network
>>>> interfaces, this choice seems not inclusive.
>>>>=20
>>>>=20
>>>> Minor Issues:
>>>>=20
>>>> 2. Objectives
>>>> ...
>>>>  o  The data model should support the pre-provisioning of interface
>>>>     configuration, i.e., it should be possible to configure an
>>>>     interface whose physical interface hardware is not present on the
>>>>     device.  It is recommended that devices that support dynamic
>>>>     addition and removal of physical interfaces also support pre-
>>>>     provisioning.
>>>>=20
>>>> It is interesting that these design criteria do not call out the
>>>> applicability
>>>> to "physical" and "virtual" interfaces. Moreover, the text above seems
>>>> to imply
>>>> that the only "dynamic creation and deletion" of interfaces happens
>>>> with the
>>>> "addition and removal of physical interfaces" and does not call out
>>>> tunnels,
>>>> loopbacks, virtuals, and other logical entities instantiated as
>>>> "interfaces".
>>>=20
>>> I think you are reading too much into the statement above.  It says
>>> that IF you support addition and removal of physical interfaces, then
>>> ...  This does NOT mean that devices cannot support tunnels, loobacks
>>> etc.  But maybe I misunderstood your point.
>>>=20
>>=20
>> I was not clear. Yes, that is an important statement. I was suggesting
>> that an addition of something like this would help:
>>=20
>> "o The dat amodel should support virtual interfaces as well as
>> physical interfaces blah blah".
>=20
> Ok, this makese sense.  I will add this.

Thank you.

>=20
>>>> 4. Relationship to the IF-MIB
>>>> =1B$B!D=1B(B
>>>>  The following table lists the YANG data nodes with corresponding
>>>>  objects in the IF-MIB.
>>>> ...
>>>>              Mapping of YANG data nodes to IF-MIB objects
>>>>=20
>>>> This section explains how name cannot always map to ifName. However,
>>>> the table
>>>> shows a 1:1 mapping of name <-> ifName. I suggest marking with a
>>>> footnote or
>>>> "*" the elements that might not always may 1:1.
>>>>=20
>>>> For example, "enabled" also cannot map to ifAdminStatus. "enabled" is
>>>> a
>>>> boolean, and ifAdminStatus is an INTEGER with at least 3 values
>>>> specified (up,
>>>> down, testing).
>>>>=20
>>>> In summary, which ones map 1:1 and which ones do not?
>>>=20
>>> This table is supposed to be an overview.  I think I would prefer to
>>> add a sentence that says something like "For details about thae
>>> mappings, please see the corresponding definition in the YANG module".
>>=20
>> No. I think that the table is a bit misleading when it says it
>> described the "Mapping of YANG data nodes to IF-MIB objects", but some
>> of these are related but do not really map.
>=20
> It seems you react to the word "Mapping" here.  I am not sure why this
> word would imply a one-to-one mapping, but if it helps we can change
> this.
>=20
>   Mapping of YANG data nodes to IF-MIB objects
>   YANG data nodes and their corresponding IF-MIB objects
>   YANG data nodes and their related IF-MIB objects
>   ...?

Thank you.

>=20
>>>> 5. Interfaces YANG Module
>>>> ...
>>>>    organization
>>>>      "IETF NETMOD (NETCONF Data Modeling Language) Working Group";
>>>>=20
>>>>    contact
>>>>      "WG Web:   
>>>>       WG List:  
>>>>=20
>>>>       WG Chair: David Kessens
>>>>                 
>>>>=20
>>>> Does the definition of the module, anchoring on a Working Group, put
>>>> requirements or constraints on the existence of netmod? Meaning: what
>>>> happens
>>>> to these pointers when the WG ceases to exist, and the maling list is
>>>> locked?
>>>> Perhaps this is the usual way of defining contact for the YANG
>>>> modules, but I
>>>> suspect a time invariant pointer would help.
>>>=20
>>> This also seems to be the usual way of defining contact info in
>>> MIBs...
>>>=20
>>=20
>> But not for others. Is there value in defining the contact this way? I
>> am just asking.
>=20
> This is the currect practice that was decided (and documented in RFC
> 6087).

Thanks much for this pointer, I have not seen it.

>=20
>>>> 5. Interfaces YANG Module
>>>>=20
>>>>        leaf oper-status {
>>>>          type enumeration {
>>>> =1B$B!D=1B(B
>>>>=20
>>>> The description of the leaf as well as the enum values for the
>>>> oper-status seem
>>>> to be a bit under-defined. For example, "Ready to pass packets" seems
>>>> too
>>>> literal from the MIB, while I believe there are more precise
>>>> definitions
>>>> (s/packets/traffic/ at least?). Also, the description is actually
>>>> listing usage
>>>> of values instead of a real description.
>>>=20
>>> [this seems to be a duplicate comment]
>>>=20
>>=20
>> Yes, sorry. Are you planning on updating the description of the
>> values?
>=20
> Oh, you actually wrote:
>=20
>   The description of the leaf as well as the enum values for the
>   oper-status seem to be a bit under-defined. For example, "Ready to
>   pass packets" seems too literal from the MIB, while I believe there
>   are more precise definitions.
>=20
> Maybe we can provde more precise defintions, but I am not sure it
> helps.  Since this leaf is supposed to reflect the ifOperStatus, what
> happens if we have a different description of the values than the MIB?
>=20
>=20

Many thanks again!

-- Carlos.

>=20
>=20
> /martin
>=20


From j.schoenwaelder@jacobs-university.de  Tue Apr 30 07:20:48 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 821F221F9AB5 for ; Tue, 30 Apr 2013 07:20:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.249
X-Spam-Level: 
X-Spam-Status: No, score=-103.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id boFxQkdF0LM3 for ; Tue, 30 Apr 2013 07:20:40 -0700 (PDT)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 6C89621F9A6A for ; Tue, 30 Apr 2013 07:20:40 -0700 (PDT)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id B691720C2F; Tue, 30 Apr 2013 16:20:39 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id AZexV6xTK1th; Tue, 30 Apr 2013 16:20: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 3AE1020C30; Tue, 30 Apr 2013 16:20:39 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 6C63E25EC18E; Tue, 30 Apr 2013 16:20:36 +0200 (CEST)
Date: Tue, 30 Apr 2013 16:20:36 +0200
From: Juergen Schoenwaelder 
To: Ladislav Lhotka 
Message-ID: <20130430142036.GA178@elstar.local>
Mail-Followup-To: Ladislav Lhotka , Martin Bjorklund , netmod@ietf.org
References: <07AF9ED2-8E39-471C-93E2-E75D4DA92E1E@nic.cz> <20130429.145226.2022342732166602338.mbj@tail-f.com> <63D55653-A803-4011-A362-3F9EE0D564FB@nic.cz> <20130430115141.GA47662@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.5.21 (2010-09-15)
Cc: netmod@ietf.org
Subject: Re: [netmod] bug in ipv6-address-no-zone
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 30 Apr 2013 14:20:48 -0000

On Tue, Apr 30, 2013 at 02:17:06PM +0200, Ladislav Lhotka wrote:
> 
> > I think we need to allow for IPv4-mapped addresses and hence the dot
> > should be added. Where can I find a definite answer whether the dot
> 
> But perhaps we should also restrict the pattern so as to allow only IPv4-mapped addresses (::ffff:A.B.C.D), or perhaps also the obsolete IPv4-compatible addresses (::A.B.C.D). Currently, addresses like
> 
> 2001:1dbf:cafe:f00:301:42:1.2.0.255
> 
> are also valid, which may not be correct.

This is a different topic - ipv6-address allows them and hence this is
not an issue for the -no-zone subtype.
 
> > needs backslashing or not? The pattern for ipv4-address-no-zone has a
> > backslashed dot and I like to get things straight. OK, I figure I have
> > to check "XML Schema Part 2: Datatypes Second Edition"…
> 
> I did it yesterday a found the text not very clear on this, but the derivation of "charClassExpr" eventually contains "XmlCharIncDash", which only excludes left and right square brackets.
> 
> In any case, using "\." is OK.
> 

Then I will use \. in both cases.

/js

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

From cpignata@cisco.com  Tue Apr 30 07:33:36 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F12521F9AAF; Tue, 30 Apr 2013 07:33:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.599
X-Spam-Level: 
X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e4Fd4ppuS5Il; Tue, 30 Apr 2013 07:33:31 -0700 (PDT)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 3D90021F9AA5; Tue, 30 Apr 2013 07:33:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14735; q=dns/txt; s=iport; t=1367332411; x=1368542011; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=mPRG20mYryJ6tnGpXhzRcVhP0KDkw5/tjhlNHsbMYe8=; b=kzQ4zoFAPX1h+WmhAJlWHGiFUXvkB2X+hM8H6EWWMQY6pKFWgAXuHqVN fs+mRRwV7jym94m5zx+bPL6zo+9wROzF70wKPrlh0bVncwtfKgcq3Fua/ DXu/9eLEmjktLO1q8LkmkEQu8GjOXSf4uvNpgv6CDAPm298wG+cY7x0T2 A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgsFAATVf1GtJV2Z/2dsb2JhbABSgwc2vlx+FnSCHwEBAQMBAQEBRCcEBwULAgEIGAoZCycLJQIEDgUIAYdxAwkGDLE9gTyFFwiHZI1XEH8CMQIFgm9hA4hdj2+QB4FVgTiBcjU
X-IronPort-AV: E=Sophos;i="4.87,582,1363132800"; d="scan'208";a="201816906"
Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-9.cisco.com with ESMTP; 30 Apr 2013 14:33:30 +0000
Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r3UEXURl015248 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 30 Apr 2013 14:33:30 GMT
Received: from xmb-aln-x02.cisco.com ([169.254.5.192]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.02.0318.004; Tue, 30 Apr 2013 09:33:29 -0500
From: "Carlos Pignataro (cpignata)" 
To: "Benoit Claise (bclaise)" 
Thread-Topic: [netmod] Last Call:  (A YANG Data Model for Interface Management) to Proposed Standard
Thread-Index: AQHORa+u8LmgzJGA90uA8V28u5gtcA==
Date: Tue, 30 Apr 2013 14:33:29 +0000
Message-ID: <95067C434CE250468B77282634C96ED322AF8E8F@xmb-aln-x02.cisco.com>
References: <20130427.093659.369612374.mbj@tail-f.com> <20130430.122049.1111664509032933339.mbj@tail-f.com> <517FA5E3.2010604@cisco.com> <517FAA3A.4080904@cisco.com>
In-Reply-To: <517FAA3A.4080904@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.150.44.101]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "ietfdbh@comcast.net" , "ietf@ietf.org" , "netmod@ietf.org" 
Subject: Re: [netmod] Last Call:  (A YANG Data Model for Interface Management) to Proposed Standard
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 30 Apr 2013 14:33:36 -0000

On Apr 30, 2013, at 7:25 AM, Benoit Claise  wrote:

> On 30/04/2013 13:07, Benoit Claise wrote:
>> Martin,
>>=20
>> It's interesting to note that Dave came up with similar feedback as I ha=
d during my AD review.
>> And you had to re-explain this again, via email. This leads me to think =
that we need some more background information, typically in "Operational Co=
nsiderations" section.
>> http://tools.ietf.org/html/draft-ietf-netmod-interfaces-cfg-10#section-4=
 could be part of that new section, but other topics could/should be addres=
sed:
>> - Failure to sync the ifIndex
>> - is there a reason why "description" value MAY match IF-MIB ifAlias ***=
and MAY restrict the values***?
>> -  what should an NM application or operator do if the YANG oper-status =
and the IF-MIB operStatus differ?
>> - persistence
>> - Is it expected that counters in ietf-interfaces and counters in IF-MIB=
 are synchronized?
>> - etc...
>>=20
>> Basically addressing many points made by Dave
> And I see that Carlos, part of the "Re: RtgDir review: draft-ietf-netmod-=
interfaces-cfg-10.txt" feedback has got some similar  points.
> - physical versus virtual interfaces
> - location
> - counter32 and counter64, and mapping to the MIB OIDs
> - etc...
>=20
> That reinforces in my thinking that we need an "operational consideration=
s" section.

+1.

I think that an "Operational Considerations" addressing these issues would =
be a most useful addition to this document.

For context, full review at http://www.ietf.org/mail-archive/web/netmod/cur=
rent/msg08035.html

Thanks,

-- Carlos.

>=20
> Regards, Benoit
>>=20
>> Regards, Benoit
>>> Hi David,
>>>=20
>>> Thank you for your detailed review!  Comments inline.
>>>=20
>>> David Harrington  wrote:
>>>> Hi,
>>>>  I have reviewed this document and feel that is almost ready for appro=
val.
>>>> This document defines a new data model in YANG format, based on the sa=
me
>>>> information model as the Interfaces MIB module (IF-MIB).
>>>> Effectively, the YANG model is a second (duplicative) standard for muc=
h of
>>>> the same information.
>>>> It is expected that devices may implement both the MIB and the YANG da=
ta
>>>> models.
>>>>  My primary concern regards co-existence and synchronization across da=
ta
>>>> models.
>>>> I think this document would benefit from an Operational Considerations
>>>> section that discusses synchronization, or an explanation why they mig=
ht
>>>> reasonably be out-of-sync.
>>>> Here are a few points to consider:
>>>>  1) the ifIndex of an interface is used within the YANG model, matchin=
g the
>>>> ifIndex in IF-MIB.
>>>> RFC2863 discusses the fact that ifIndex numbering might change during
>>>> hot-swaps.
>>> Actually, RFC 2863 points out that a ifIndex must not be reused until
>>> after the following re-initialization of the network management
>>> system.
>>>=20
>>>> This document does not discuss the need to ensure that IF-MIB ifIndex
>>>> changes need to be reflected in the YANG model.
>>>> The ifIndex in the YANG module must match that in IF-MIB (really, that=
 in
>>>> the underlying instrumentation).
>>> Absolutely!  That's the intention.  The description for the read-only
>>> leaf if-index says:
>>>=20
>>>            The ifIndex value for the ifEntry represented by this
>>>            interface.
>>>=20
>>>=20
>>>> Failure to sync the ifIndex could lead NM applications to confuse whic=
h
>>>> already-retrieved data records are related to which interface.
>>>> This could cause an NM application to misinterpret/corrupt gathered
>>>> trending information, and possibly to apply changes to the wrong
>>>> interfaces.
>>> Fully agree - this is why the if-index is present; to facilitate the
>>> mapping between the models.
>>>=20
>>>> 2) ifType - can an interface be hot-swapped to use a different type? I=
s
>>>> this discussed someplace?
>>> Hot-swapping sounds like a physical property.  The data model in this
>>> document can handle this -- provided the system physically supports
>>> it, of course.  Note that the type is a writable leaf just like
>>> others.  You can change it, but as with any other leaf a device that
>>> cannot support a particular change will reject it.
>>>=20
>>>> 3) ifType - the description says the value of this mandatory object MA=
Y be
>>>> initialized. What value should an NM application expect if it is NOT
>>>> initialized?
>>> None.  And since it is mandatory, in this case the NM application has
>>> to explicitly provide the type.  If you write a completely generic NM
>>> application you would probably always provide the type, since you
>>> cannot count on the server auto-initializing it.  But if you *know*
>>> that the server auto-initialize the type, you don't have to provide
>>> it.
>>>=20
>>>> 4) enabled - "Systems that implement the IF-MIB use the value of this =
leaf
>>>> to set IF-MIB.ifAdminStatus ..."; should this be a MAY/SHOULD/MUST? Ho=
w
>>>> will this coexist with SNMP-based NM applications? Is there potential =
for
>>>> conflict? What if NETCONF sets this as enabled, then an operator sets =
it
>>>> to disabled via SNMP?
>>>> Does NETCONF know that its "enable" value (adminStatus) is out of date=
?
>>>> (does it matter? See note 7).
>>>> What if the NETCONF system directky changes the underlying instrumenta=
tion
>>>> for adminstatus without going through the MIB?
>>> It is not clear to me if we can / want to require that these objects
>>> share the same instrumentation.
>>>=20
>>> Some of this might be b/c ifAdminStatus is a a bit unclear in some
>>> regards.  For example, it talks about how
>>>=20
>>>             per configuration information
>>>             retained by the managed system, ifAdminStatus is then
>>>             changed [...]
>>>=20
>>> I would assume (but this might be incorrect) that the "configuration
>>> information" could be things configured through the CLI for example,
>>> and this "configuration information" could thus also be the data
>>> defined in this YANG model.
>>>=20
>>> So it seems RFC 2863 makes a distinction between ifAdminStatus and
>>> what is actually configured.
>>>=20
>>> Also, the description of ifAdminStatus doesn't say anything about
>>> persistence, so it might be impossible to map this to the persistently
>>> stored configuration.
>>>=20
>>>=20
>>>> 5) is there a reason why "description" value MAY match IF-MIB ifAlias
>>>> ***and MAY restrict the values***?
>>>> Is there a particular use case for this lack of standardization of
>>>> restrictions across data models?
>>>> The persistence is a pretty important restriction related to the
>>>> functionality of ifAlias, and the dynamism of ifIndex.
>>>> If NETCONF is used to set the value, ignoring IF-MIB restrictions, wha=
t
>>>> happens to IF-MIB ifAlias as a persistent "handle" to the interface?
>>> The only reason the "description" leaf is mapped to ifAlias is b/c
>>> this is what many implementations do.  So we wanted to point out the
>>> differences in the value space for these objects so that implementers
>>> are aware of this.
>>>=20
>>> And of course it is not possible to actually set *ifAlias* and ignore
>>> its syntax constraints.  However, you can use non 7-bit ascii in
>>> "description", and in this case the "description" value cannot be used
>>> unmodified as ifAlias.
>>>=20
>>>> 6) What error is returned via NETCONF if YANG attempts to set a value =
that
>>>> violates the SNMP agent implementation restrictions, and the SNMP agen=
t
>>>> refuses the requested SET operation to ifAlias?
>>> The draft says:
>>>=20
>>>            If a NETCONF server that implements this restriction is
>>>            sent a value that doesn't match the restriction, it MUST
>>>            reply with an rpc-error with the error-tag
>>>            'invalid-value'.
>>>=20
>>>> Is there a simple way for an operator to tell whether the implementati=
on
>>>> supports the restrictions (other than deliberately triggering an error=
)?
>>> No.
>>>=20
>>>> 7) what should an NM application or operator do if the YANG oper-statu=
s
>>>> and the IF-MIB operStatus differ?
>>> The intention is that they share the same instrumentation.
>>>=20
>>>> IF-MIB has substantial discussion of the relationship between
>>>> ifAdminStatus and ifOperStatus. The YANG module doesn't have a compara=
ble
>>>> discussion.
>>> Which text in the MIB do you mean?  There is some text in the
>>> description of "oper-status".
>>>=20
>>>> Given that there could e additional delay incurred between setting ena=
ble,
>>>> updating ifAdminStatus, the change to ifOperStatus, and the update to
>>>> oper-status, I recommend some mention in the description of enable and=
/or
>>>> oper-status of the detailed description in RFC2863, and applicability =
to
>>>> ietf-interfaces.
>>>>  8) link-up-down-trap-enable: The text says this "indicates" whether t=
raps
>>>> should be generated for the interface; shouldn't this be "configures"?
>>> Or maybe "Controls ..."?
>>>=20
>>>> 9) persistence isn't discussed in the config object descriptions. Do t=
hey
>>>> match the IF-MIB object persistences?
>>> Persistence in NETCONF is different from SNMP, in general.  In NETCONF,
>>> the persistence is defined by the data store where you write the data.
>>>=20
>>>=20
>>>> 10) IF-MIB counters do not typically start at zero; a delta must be
>>>> calculated. This is a common misunderstanding for new MIB developers a=
nd
>>>> users.
>>>> I don't see any comparable discussion related to ietf-interfaces count=
ers.
>>>> Where should one look for a discussion of YANG counter initialization
>>>> values?
>>>> Where should one look for a discussion of YANG counter rollover?
>>> The couters are defined as yang:counter32 and yang:counter64. The
>>> "yang" prefix means module "ietf-yang-types".  This module is defined
>>> in RFC 6021.  This RFC discusses initial values and discontinuities.
>>>=20
>>> (ok, this was also suggested by yourself further below!)
>>>=20
>>>> It would help to have a discussion of how to utilize discontinuity_tim=
e
>>>> and counters, especially for implementers not familiar with SNMP (and =
not
>>>> implementing IF-MIB).
>>>>  11) Is it expected that counters in ietf-interfaces and counters in I=
F-MIB
>>>> are synchronized? Can an NM application reasonably compare two reading=
s -
>>>> one of in-octets and one of ifHCInOctets? If not, I think that should =
be
>>>> made clear. (The reference clauses seem to link them)
>>> I think the intention is that the instrumentation is shared. There is
>>> most probably a single hw register / kernel counter for these objects,
>>> and this is what will be used for these counters.
>>>=20
>>>> 12) From IF-MIB: "Discontinuities in the value of this counter can occ=
ur
>>>> at re-initialization of the management system, and at other times as
>>>> indicated by the value of ifCounterDiscontinuityTime."
>>>> From ietf-interfaces: "Discontinuities in the value of this counter ca=
n
>>>> occur at re-initialization of the management system, and at other time=
s as
>>>> indicated by the value of 'discontinuity-time'."
>>>> I think it is ambiguous as to whether both sets of text refer to the s=
ame
>>>> "management system". Is the IF-MIB management-system the SNMP agent? A=
nd
>>>> the YANG management-system the YANG server? Or are both based on the
>>>> underlying (e.g, hardware or native) management system?
>>> Good question!  The term is not defined anywhere (as far as I know),
>>> and thus there is some liberty in the interpretation of it.  But I
>>> don't think it matters.  It seems unlikely that a
>>> NM application sometimes reads a counter over SNMP and sometimes the
>>> same counter from the same device over NETCONF and then compare the
>>> values.
>>>=20
>>>> Are ifCounterDiscontinuityTime and discontinuity-time synchronized or
>>>> independent? If they are independent, then the YANG counters and MIB
>>>> counters could contain very different values; it might help operators =
to
>>>> have this pointed out.
>>> See above.  There is no requirement that they MUST be synchronized,
>>> but they surely can be.
>>>=20
>>>> It might help implementers to know whether to try
>>>> to synchronize them or not.
>>>> Can an operator force restart of both YANG and MIB systems to force
>>>> synchronization of counters?
>>> No.  Is there a way to force a restart of the "MIB system"?
>>>=20
>>>> 13) Some of the questions about counters might be covered in yang-type=
s;
>>>> it would help if the imports clause indicated the relevant RFCs.
>>> As a comment?  I will raise this issue in the WG.
>>>=20
>>>> 14) IF-MIB has both 32-bit and 64-bit counters; YANG only duplicates t=
he
>>>> 64-bit counters, generally. It might be good to discuss this in an
>>>> Operations Considerations section, to explain some potential anomalies=
 at
>>>> the NM application side.
>>> In practice I don't think this is a problem.  It seems unlikely that a
>>> NM application sometimes reads a counter over SNMP and sometimes the
>>> same counter from the same device over NETCONF and then compare the
>>> values.
>>>=20
>>>> 15) ietf-interfaces can modify the SNMP trap-enable settings; enabling
>>>> lots of traps could impact denial of service, disabling could hide
>>>> interface changes made by an attacker; it should probably be mentioned=
 in
>>>> security considerations.
>>> I was thinking we could simply reference the Security Considerations
>>> section in RFC 2863 for this, but it doesn't discuss this.
>>>=20
>>>> 16) Many operators/developers may have experience with IF-MIB, and som=
e
>>>> applications might be rewritten to utilize ietf-interfaces rather than=
 (or
>>>> to supplement) IF-MIB. Not all IF-MIB objects are reflected in
>>>> ietf-interfaces; it might be helpful to show which IF-MIB objects are =
not
>>>> mapped to ietf-interfaces, and discuss why, and whether comparable inf=
o
>>>> can be derived using other YANG approaches.
>>>>  17) The copyright in the module description clause needs updating.
>>> Ok.
>>>=20
>>>=20
>>>=20
>>> /martin
>>> _______________________________________________
>>> netmod mailing list
>>> netmod@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netmod
>>>=20
>>>=20
>>=20
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>>=20
>>=20
>=20


From bclaise@cisco.com  Tue Apr 30 07:35:17 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F4D921F9AC2 for ; Tue, 30 Apr 2013 07:35:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.461
X-Spam-Level: 
X-Spam-Status: No, score=-10.461 tagged_above=-999 required=5 tests=[AWL=0.137, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IC2ar1O1r2vL for ; Tue, 30 Apr 2013 07:35:13 -0700 (PDT)
Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id D0C6D21F9AA8 for ; Tue, 30 Apr 2013 07:35:12 -0700 (PDT)
X-TACSUNS: Virus Scanned
Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r3UEZ0Ee028248; Tue, 30 Apr 2013 16:35:00 +0200 (CEST)
Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r3UEYP9w016086; Tue, 30 Apr 2013 16:34:40 +0200 (CEST)
Message-ID: <517FD670.9080807@cisco.com>
Date: Tue, 30 Apr 2013 16:34:24 +0200
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5
MIME-Version: 1.0
To: Martin Bjorklund 
References: <20130427.093659.369612374.mbj@tail-f.com> <20130430.122049.1111664509032933339.mbj@tail-f.com> <517FA5E3.2010604@cisco.com> <20130430.132943.828559691589933098.mbj@tail-f.com>
In-Reply-To: <20130430.132943.828559691589933098.mbj@tail-f.com>
Content-Type: multipart/alternative; boundary="------------090706030500020501030601"
Cc: ietfdbh@comcast.net, netmod@ietf.org
Subject: Re: [netmod] Last Call:  (A YANG Data Model for Interface Management) to Proposed Standard
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 30 Apr 2013 14:35:17 -0000

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

Hi Martin,
> Hi,
>
> I am pruning the Cc a bit so we can discuss this in the WG first.
>
> Benoit Claise  wrote:
>> Martin,
>>
>> It's interesting to note that Dave came up with similar feedback as I
>> had during my AD review.
>> And you had to re-explain this again, via email. This leads me to
>> think that we need some more background information, typically in
>> "Operational Considerations" section.
>> http://tools.ietf.org/html/draft-ietf-netmod-interfaces-cfg-10#section-4
>> could be part of that new section, but other topics could/should be
>> addressed:
>> - Failure to sync the ifIndex
> Apparently, the current text somehow seems to imply that there is a
> synchronization problem.  But to be honest, I cannot see why.
The point is not that there is something wrong with your text.
The point is that you have 2 types of audience for this document.
1. the data model audience
2. the operators audience.

A typical question the audience 2. will ask themselves, while reading 
this draft, is: what about the relationship regarding the ifIndex (which 
I know about)?
And we could make this more obvious in a "operational considerations" 
section, if I understand David correctly.
For example (I trust you on the right text):

    The ifIndex value must match the YANG if-index leaf. So a change in
    the ifIndex allocation (RFC 2863 points out that an ifIndex must not
    be reused until after the following re-initialization of the network
    management system) implies a change in the YANG if-index leaf. The
    key in interface list is the "name", therefore an ifIndex change
    doesn't require a full table discovery (as it is the case with the
    ifTable)


> This is
> the current text:
>
>        leaf if-index {
>          config false;
>          ...
>          description
>            "The ifIndex value for the ifEntry represented by this
>             interface.
>             ...";
>        }
>
> So we have a config false leaf that is described as being the ifIndex
> value of the ifEntry.   Please help me to improve this text so the
> meaning is clear.
>
>
>> - is there a reason why "description" value MAY match IF-MIB ifAlias
>> - ***and MAY restrict the values***?
> Ok, I suggest we add a paragraph like this:
>
>    The configured "description" of an "interface" has traditionally
>    been mapped to ifAlias in some implementations.  This document allow
>    this mapping, but implementers should be aware of the differences in
>    the value space for these objects.
Perfect text for this "operational considerations" section
>
>
>> -  what should an NM application or operator do if the YANG oper-status
>> -  and the IF-MIB operStatus differ?
> I need help also with this one.  I do not understand the problem, so I
> cannot suggest a solution :(
>
>> - persistence
> I don't think this document is the right place to describe the
> persistency model for SNMP vs. NETCONF - if we do it here we probably
> have to do it in all other data-model specific documents as well...
>
>> - Is it expected that counters in ietf-interfaces and counters in IF-MIB
>> - are synchronized?
> Again, I don't really see the problem, and I do not understand what it
> means for counters to be synchronized.  Please suggest some text to
> add.
I'm an operator. The simple question is: I can query the counters with 
SNMP or with NETCONF. Are these counters the same?

Regards, Benoit
>
>
>
> /martin
>
>


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


  
    
  
  
    
Hi Martin,

    

    

      
Hi,

I am pruning the Cc a bit so we can discuss this in the WG first.

Benoit Claise <bclaise@cisco.com> wrote:


      

        
Martin,

It's interesting to note that Dave came up with similar feedback as I
had during my AD review.
And you had to re-explain this again, via email. This leads me to
think that we need some more background information, typically in
"Operational Considerations" section.
http://tools.ietf.org/html/draft-ietf-netmod-interfaces-cfg-10#section-4
could be part of that new section, but other topics could/should be
addressed:
- Failure to sync the ifIndex


      

      
Apparently, the current text somehow seems to imply that there is a
synchronization problem.  But to be honest, I cannot see why.  

    

    The point is not that there is something wrong with your text.

    The point is that you have 2 types of audience for this document.

    1. the data model audience

    2. the operators audience.

    

    A typical question the audience 2. will ask themselves, while
    reading this draft, is: what about the relationship regarding the
    ifIndex (which I know about)? 

    And we could make this more obvious in a "operational
    considerations" section, if I understand David correctly.

    For example (I trust you on the right text):

    
The ifIndex value must match the YANG if-index leaf. So
      a change in the ifIndex allocation (RFC 2863 points out that an
      ifIndex must not be reused until
      after the following re-initialization of the network management
      system) implies a change in the YANG if-index leaf. The key in
      interface list is the "name", therefore an ifIndex change doesn't
      require a full table discovery (as it is the case with the
      ifTable)

    

        

    

      
This is
the current text:

      leaf if-index {
        config false;
        ...
        description    
          "The ifIndex value for the ifEntry represented by this
           interface.
           ...";
      }

So we have a config false leaf that is described as being the ifIndex
value of the ifEntry.   Please help me to improve this text so the
meaning is clear.




      

        
- is there a reason why "description" value MAY match IF-MIB ifAlias
- ***and MAY restrict the values***?


      

      
Ok, I suggest we add a paragraph like this:

  The configured "description" of an "interface" has traditionally
  been mapped to ifAlias in some implementations.  This document allow
  this mapping, but implementers should be aware of the differences in
  the value space for these objects.

    

    Perfect text for this "operational considerations" section

    

      




      

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


      

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



      

        
- persistence


      

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



      

        
- Is it expected that counters in ietf-interfaces and counters in IF-MIB
- are synchronized?


      

      
Again, I don't really see the problem, and I do not understand what it
means for counters to be synchronized.  Please suggest some text to
add.

    

    I'm an operator. The simple question is: I can query the counters
    with SNMP or with NETCONF. Are these counters the same?

    

    Regards, Benoit

    

      



/martin




    

    

  


--------------090706030500020501030601--

From lhotka@nic.cz  Tue Apr 30 07:41:47 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F8C221F9A46 for ; Tue, 30 Apr 2013 07:41:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.939
X-Spam-Level: 
X-Spam-Status: No, score=-1.939 tagged_above=-999 required=5 tests=[AWL=0.060,  BAYES_00=-2.599, J_CHICKENPOX_23=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eX5gKEgFiO8A for ; Tue, 30 Apr 2013 07:41:46 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 859B221F9814 for ; Tue, 30 Apr 2013 07:41: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 C455913F955; Tue, 30 Apr 2013 16:41:45 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1367332905; bh=5bd5ATsJqyNWl+LyjZBCClCmN22PwuwwNQxqRFrEsCU=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=YevjxZpzjDgz0S+Ar9ibnt3nXjGvytTG3iqTH7TCLvCC/+kv4PCPRorF5be8j2+yj to0srwpPVBnv4HzFs7sY6U+8lnChtMkIV+iG9VsgtcbhLDULsI1tr4lrBHXxLUeGyf Wl28XBgl0cjebOg12wLzWu4B0VW0fSh7OQWokEB4=
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
From: Ladislav Lhotka 
In-Reply-To: <20130430142036.GA178@elstar.local>
Date: Tue, 30 Apr 2013 16:41:45 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <52D39340-3D8E-4EB5-9521-2801E868BF21@nic.cz>
References: <07AF9ED2-8E39-471C-93E2-E75D4DA92E1E@nic.cz> <20130429.145226.2022342732166602338.mbj@tail-f.com> <63D55653-A803-4011-A362-3F9EE0D564FB@nic.cz> <20130430115141.GA47662@elstar.local>  <20130430142036.GA178@elstar.local>
To: Juergen Schoenwaelder 
X-Mailer: Apple Mail (2.1503)
X-Virus-Scanned: clamav-milter 0.97.7 at mail
X-Virus-Status: Clean
Cc: netmod@ietf.org
Subject: Re: [netmod] bug in ipv6-address-no-zone
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 30 Apr 2013 14:41:47 -0000

On Apr 30, 2013, at 4:20 PM, Juergen Schoenwaelder =
 wrote:

> On Tue, Apr 30, 2013 at 02:17:06PM +0200, Ladislav Lhotka wrote:
>>=20
>>> I think we need to allow for IPv4-mapped addresses and hence the dot
>>> should be added. Where can I find a definite answer whether the dot
>>=20
>> But perhaps we should also restrict the pattern so as to allow only =
IPv4-mapped addresses (::ffff:A.B.C.D), or perhaps also the obsolete =
IPv4-compatible addresses (::A.B.C.D). Currently, addresses like
>>=20
>> 2001:1dbf:cafe:f00:301:42:1.2.0.255
>>=20
>> are also valid, which may not be correct.
>=20
> This is a different topic - ipv6-address allows them and hence this is
> not an issue for the -no-zone subtype.

Yes, this comment aimed at ipv6-address and ipv6-prefix.

Lada

>=20
>>> needs backslashing or not? The pattern for ipv4-address-no-zone has =
a
>>> backslashed dot and I like to get things straight. OK, I figure I =
have
>>> to check "XML Schema Part 2: Datatypes Second Edition"=85
>>=20
>> I did it yesterday a found the text not very clear on this, but the =
derivation of "charClassExpr" eventually contains "XmlCharIncDash", =
which only excludes left and right square brackets.
>>=20
>> In any case, using "\." is OK.
>>=20
>=20
> Then I will use \. in both cases.
>=20
> /js
>=20
> --=20
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
> Fax:   +49 421 200 3103         

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





From j.schoenwaelder@jacobs-university.de  Tue Apr 30 07:55:00 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8066921F9B21 for ; Tue, 30 Apr 2013 07:55:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.249
X-Spam-Level: 
X-Spam-Status: No, score=-103.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z8Dy2YqEFRft for ; Tue, 30 Apr 2013 07:54:55 -0700 (PDT)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 3AB7721F9B7C for ; Tue, 30 Apr 2013 07:54:55 -0700 (PDT)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7D74D20C24; Tue, 30 Apr 2013 16:54:54 +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 oGeEEW6SqbSj; Tue, 30 Apr 2013 16:54: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 B296720C06; Tue, 30 Apr 2013 16:54:53 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id DD19225EC3D8; Tue, 30 Apr 2013 16:54:52 +0200 (CEST)
Date: Tue, 30 Apr 2013 16:54:52 +0200
From: Juergen Schoenwaelder 
To: Ladislav Lhotka 
Message-ID: <20130430145452.GA348@elstar.local>
Mail-Followup-To: Ladislav Lhotka , Martin Bjorklund , netmod@ietf.org
References: <07AF9ED2-8E39-471C-93E2-E75D4DA92E1E@nic.cz> <20130429.145226.2022342732166602338.mbj@tail-f.com> <63D55653-A803-4011-A362-3F9EE0D564FB@nic.cz> <20130430115141.GA47662@elstar.local>  <20130430142036.GA178@elstar.local> <52D39340-3D8E-4EB5-9521-2801E868BF21@nic.cz>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <52D39340-3D8E-4EB5-9521-2801E868BF21@nic.cz>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: netmod@ietf.org
Subject: Re: [netmod] bug in ipv6-address-no-zone
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 30 Apr 2013 14:55:00 -0000

On Tue, Apr 30, 2013 at 04:41:45PM +0200, Ladislav Lhotka wrote:
> 
> On Apr 30, 2013, at 4:20 PM, Juergen Schoenwaelder  wrote:
> 
> > On Tue, Apr 30, 2013 at 02:17:06PM +0200, Ladislav Lhotka wrote:
> >> 
> >>> I think we need to allow for IPv4-mapped addresses and hence the dot
> >>> should be added. Where can I find a definite answer whether the dot
> >> 
> >> But perhaps we should also restrict the pattern so as to allow only IPv4-mapped addresses (::ffff:A.B.C.D), or perhaps also the obsolete IPv4-compatible addresses (::A.B.C.D). Currently, addresses like
> >> 
> >> 2001:1dbf:cafe:f00:301:42:1.2.0.255
> >> 
> >> are also valid, which may not be correct.
> > 
> > This is a different topic - ipv6-address allows them and hence this is
> > not an issue for the -no-zone subtype.
> 
> Yes, this comment aimed at ipv6-address and ipv6-prefix.
> 

I prefer to not change these definitions (and who knows whether any
other 'mapped' address formats get invented in the future).

/js

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

From j.schoenwaelder@jacobs-university.de  Tue Apr 30 08:23:33 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1174121F9BE4 for ; Tue, 30 Apr 2013 08:23:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.249
X-Spam-Level: 
X-Spam-Status: No, score=-103.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4nKJ8gpOVXdU for ; Tue, 30 Apr 2013 08:23:27 -0700 (PDT)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id D806E21F98E6 for ; Tue, 30 Apr 2013 08:23:26 -0700 (PDT)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 41F5820C0C; Tue, 30 Apr 2013 17:23:26 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id L1890bVjgPyc; Tue, 30 Apr 2013 17:23:26 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5931D20C0F; Tue, 30 Apr 2013 17:23:25 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id EB3FF25EC4DF; Tue, 30 Apr 2013 17:23:22 +0200 (CEST)
Date: Tue, 30 Apr 2013 17:23:22 +0200
From: Juergen Schoenwaelder 
To: Martin Bjorklund 
Message-ID: <20130430152322.GB348@elstar.local>
Mail-Followup-To: Martin Bjorklund , bclaise@cisco.com, ietfdbh@comcast.net, netmod@ietf.org
References: <20130427.093659.369612374.mbj@tail-f.com> <20130430.122049.1111664509032933339.mbj@tail-f.com> <517FA5E3.2010604@cisco.com> <20130430.132943.828559691589933098.mbj@tail-f.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20130430.132943.828559691589933098.mbj@tail-f.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: ietfdbh@comcast.net, netmod@ietf.org
Subject: Re: [netmod] Last Call:  (A YANG Data Model for Interface Management) to Proposed Standard
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 30 Apr 2013 15:23:33 -0000

On Tue, Apr 30, 2013 at 01:29:43PM +0200, Martin Bjorklund wrote:
 
> > - Is it expected that counters in ietf-interfaces and counters in IF-MIB
> > - are synchronized?
> 
> Again, I don't really see the problem, and I do not understand what it
> means for counters to be synchronized.  Please suggest some text to
> add.

The counters typically exist has hardware registers on line cards or
as software counters in an OS kernel. The managment protocols read
those counters and export them - they do not maintain these counters
themself. As such, there is no synchronization issue.

That said, operators were somewhat fed up (they had clear words about
this) with counter accuracy at the NM IAB workshop because they
experienced that SNMP counters sometimes do not line up with CLI
counters. Part of the problem is that SNMP agents sometimes cache
values for performance optimizations or other weird reasons influence
the accuracy (e.g. row-by-row table retrieval can very easily screw
your data accuracy in SNMP land generally). As such, this is mostly an
implementation issue and an SNMP protocol, not a counter specification
issue. Will NETCONF implementations do better? We hope so.

In other words, I assume operators prefer that NETCONF counters are
'synchronized' with CLI counters much more than being 'synchronized'
with potentially screwed SNMP counters. I hope we do not end with
"SNMP had screwed counters" so lets be consistent with our standards
and mandate that NETCONF also reports the same screwed SNMP counters.

/js

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

From j.schoenwaelder@jacobs-university.de  Tue Apr 30 12:03:01 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A13421F9A38 for ; Tue, 30 Apr 2013 12:03:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.249
X-Spam-Level: 
X-Spam-Status: No, score=-103.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g8w6uQfBjQYR for ; Tue, 30 Apr 2013 12:02:56 -0700 (PDT)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 294EC21F8523 for ; Tue, 30 Apr 2013 12:02:56 -0700 (PDT)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 89F3020C2C; Tue, 30 Apr 2013 21:02:55 +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 GahOGMPaMAlT; Tue, 30 Apr 2013 21:02: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 0ACB920C0C; Tue, 30 Apr 2013 21:02:55 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 5DE5925ECB31; Tue, 30 Apr 2013 21:02:52 +0200 (CEST)
Date: Tue, 30 Apr 2013 21:02:52 +0200
From: Juergen Schoenwaelder 
To: Martin Bjorklund 
Message-ID: <20130430190252.GA987@elstar.local>
Mail-Followup-To: Martin Bjorklund , netmod@ietf.org
References: <20130430084414.GC47140@elstar.local> <20130430.111224.1400052084629997469.mbj@tail-f.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20130430.111224.1400052084629997469.mbj@tail-f.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: netmod@ietf.org
Subject: Re: [netmod] hex string - allow zero length values?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 30 Apr 2013 19:03:01 -0000

On Tue, Apr 30, 2013 at 11:12:24AM +0200, Martin Bjorklund wrote:
> Juergen Schoenwaelder  wrote:
> > Hi,
> > 
> > an issue that came up during reviews:
> > 
> > Should hex-string allow zero-length strings?
> > 
> > Right now it does not. Should we change that? If so, how would it
> > affect other documents we have using the hex-string definition?
> 
> It makes some sense to allow it.  We allow zero-length strings and
> binary for example.
> 
> ietf-x509-cert-to-name and ietf-snmp-common are not affected, they
> already have a length restriction.
> 
> ietf-snmp-usm uses it for keys, and does not have a restriction but
> probably should anyway.
> 

OK. So I propose to change hex-string to this:

  typedef hex-string {
    type string {
      pattern '([0-9a-fA-F]{2}(:[0-9a-fA-F]{2})*)?';
    }
    description
     "A hexadecimal string with octets represented as hex digits
      separated by colons.  The canonical representation uses
      lowercase characters.";
  }

/js

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

From lhotka@nic.cz  Tue Apr 30 12:37:19 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A736021F84CD for ; Tue, 30 Apr 2013 12:37:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.949
X-Spam-Level: 
X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.050,  BAYES_00=-2.599, J_CHICKENPOX_23=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w8vs34pMoq8B for ; Tue, 30 Apr 2013 12:37:19 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id ED76221F8496 for ; Tue, 30 Apr 2013 12:37:18 -0700 (PDT)
Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id C1DF513F6AB; Tue, 30 Apr 2013 21:37:17 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1367350637; bh=J6QmqvU2Z8vYx5AVkAS8vx+Zkry3FPnxyP+T21RBwCk=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=Z2/vpnVgSqkUNQsg8lObr45w+dUK1a0j+jWHNuOREcxIOrRe+5DH/aAuuGt28S92k Xew49Dit+AsmzvYesV5czkCdhqZ58biOV+RaDidYmFb42CZNduyBKeA5VzzkKLAUiP Z1g+1qYe2EKd+8axNYM0ZgXLQORZoVNpa7BJ6MmI=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
From: Ladislav Lhotka 
In-Reply-To: <20130430190252.GA987@elstar.local>
Date: Tue, 30 Apr 2013 21:37:17 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <954E459F-7F26-4DE9-AFA7-EAE141EA2968@nic.cz>
References: <20130430084414.GC47140@elstar.local> <20130430.111224.1400052084629997469.mbj@tail-f.com> <20130430190252.GA987@elstar.local>
To: Juergen Schoenwaelder 
X-Mailer: Apple Mail (2.1503)
X-Virus-Scanned: clamav-milter 0.97.7 at mail
X-Virus-Status: Clean
Cc: netmod@ietf.org
Subject: Re: [netmod] hex string - allow zero length values?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 30 Apr 2013 19:37:19 -0000

On Apr 30, 2013, at 9:02 PM, Juergen Schoenwaelder =
 wrote:

> On Tue, Apr 30, 2013 at 11:12:24AM +0200, Martin Bjorklund wrote:
>> Juergen Schoenwaelder  wrote:
>>> Hi,
>>>=20
>>> an issue that came up during reviews:
>>>=20
>>> Should hex-string allow zero-length strings?
>>>=20
>>> Right now it does not. Should we change that? If so, how would it
>>> affect other documents we have using the hex-string definition?
>>=20
>> It makes some sense to allow it.  We allow zero-length strings and
>> binary for example.
>>=20
>> ietf-x509-cert-to-name and ietf-snmp-common are not affected, they
>> already have a length restriction.
>>=20
>> ietf-snmp-usm uses it for keys, and does not have a restriction but
>> probably should anyway.
>>=20
>=20
> OK. So I propose to change hex-string to this:
>=20
>  typedef hex-string {
>    type string {
>      pattern '([0-9a-fA-F]{2}(:[0-9a-fA-F]{2})*)?';
>    }
>    description
>     "A hexadecimal string with octets represented as hex digits
>      separated by colons.  The canonical representation uses
>      lowercase characters.";
>  }

+1

Lada

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

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