From lhotka@nic.cz Sun Dec 2 00:28:50 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7139021F8FC2 for ; Sun, 2 Dec 2012 00:28:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.23 X-Spam-Level: X-Spam-Status: No, score=-1.23 tagged_above=-999 required=5 tests=[AWL=-0.720, BAYES_05=-1.11, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UCOTFlY6C21F for ; Sun, 2 Dec 2012 00:28:49 -0800 (PST) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 9675621F8FBE for ; Sun, 2 Dec 2012 00:28:49 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id E09715407C4 for ; Sun, 2 Dec 2012 09:28:46 +0100 (CET) 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 tU8LKU4ztZrw for ; Sun, 2 Dec 2012 09:28:42 +0100 (CET) Received: from localhost (unknown [10.107.191.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id B7AB65401C8 for ; Sun, 2 Dec 2012 09:28:38 +0100 (CET) From: Ladislav Lhotka To: netmod@ietf.org In-Reply-To: <20121130105318.GA7104@elstar.local> References: <20121128173510.GA891@elstar.local> <743AE045-177A-4C9C-B90A-45B769E8EE64@nic.cz> <20121129092233.GA2172@elstar.local> <20121129.224738.335399884.mbj@tail-f.com> <20121130101545.GA6989@elstar.local> <3CDC6495-DDAE-4190-B84E-D3BA6EAF5F4D@nic.cz> <20121130104426.GA7067@elstar.local> <20121130105318.GA7104@elstar.local> User-Agent: Notmuch/0.14+100~ge0adf10 (http://notmuchmail.org) Emacs/23.3.50.1 (i386-apple-darwin9.8.0) Mail-Followup-To: netmod@ietf.org Date: Sun, 02 Dec 2012 09:28:18 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [netmod] IP addresses with zone indices X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 02 Dec 2012 08:28:50 -0000 Juergen Schoenwaelder writes: > On Fri, Nov 30, 2012 at 11:49:43AM +0100, Ladislav Lhotka wrote: >> >> > >> > I believe the proper type for ipv4/address/ip is ipv4-address. >> >> I had the impression we all agreed that zone indices are not desirable there and therefore the "ipv4-address" type won't be used for it - at least the one from "ietf-inet-types". >> > > The ipv4-address type is more generic, so you subtype it to make it > specific to what ipv4/address/ip needs. This can very easily be done > inline of the leaf definition. Not a big deal, get it done, move on. > >> > Perhaps there could be a universal dotted-quad type somewhere at >> > sometime. But our goal right now is to finish and deliver. Having a >> > dotted-quad pattern copied is not worth further delaying the >> > completion of this work. >> >> If it is defined in "ietf-ip", it won't create any (new) downrefs. > > But then it will still be in the wrong place. And ietf-ip won't > need this type since ipv4/address/ip is an ipv4-address (and > ipv6/address/ip is an IPv6 address without a zone id). This is actually not true. The "ietf-ip" draft also uses the "ipv4-address" type for the "netmask" leaf, which has both problems as "router-id": semantically, it is not an IP address, and a zone index must not be present. Lada > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From mbj@tail-f.com Mon Dec 3 00:28:35 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DD7221F88BD for ; Mon, 3 Dec 2012 00:28:35 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rDI9xzSYBrt7 for ; Mon, 3 Dec 2012 00:28:34 -0800 (PST) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id B7F9E21F883A for ; Mon, 3 Dec 2012 00:28:34 -0800 (PST) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 9B12F12008FC; Mon, 3 Dec 2012 09:28:32 +0100 (CET) Date: Mon, 03 Dec 2012 09:28:32 +0100 (CET) Message-Id: <20121203.092832.51056648946647154.mbj@tail-f.com> To: alex@cisco.com From: Martin Bjorklund In-Reply-To: References: <20121116084024.GA2302@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] 2nd wg last call on interfaces / ip / routing data models X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 08:28:35 -0000 "Alexander Clemm (alex)" wrote: > - leaf location (p13): > It seems to make sense to add a clause analogous to the description in > leaf "name" that spells out what happens if an application were to try > to set location in a manner that is invalid. There, it states "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'." Ok. How about this description: OLD: "The device-specific location of the interface of a particular type. The format of the location string depends on the interface type and the device. NEW: "The device-specific location of the interface of a particular type. The format of the location string depends on the interface type and the device. If a NETCONF server is sent a value that doesn't match this format, it MUST reply with an rpc-error with the error-tag 'invalid-value'. > - leaf enabled (p13): > Just as a thought, here is always a possibility that an application > does not initially populate all leaves when creating an interface, but > sends them e.g. in successive operations. That raises the question > when the interface should actually go into effect . Would it make > sense to add a clause to the description that states that if an > interface is initially created but does not yet contain all the > settings, an application SHOULD set the leaf to "enabled=false"? (Or > should perhaps even the default be false, not true, for that reason to > require explicit turning on of the interface when the configuration is > fully ready?) It is trivial for an application to set enabled to false when it creates the interface, if it cannot set all parameters at once. > - leaf oper-status, enum value "not-present" (p14): I am wondering if > the description can be made a little more specific - the precise > meaning of "some component is missing" is not clear. At a minimum, > the enum description should add what is stated further below > (typically, missing hardware components)? This text is copied from the MIB. But we can at least do what you suggest: "Some component (typically hardware) is missing."; > - leaf last-change (p15): > Would it make sense to name this "last-oper-change"? "last-change" > could also be interpreted to mean "last config change", but this is > not what is meant here. The corresponding MIB object is called ifLastChange, and whenever a YANG node has the same semantics as the corresponding MIB object, we try to not rename them (except to follow YANG conventions). This said, I agree with your concern, and I think last-oper-change is a better name. What do other people think? /martin From mbj@tail-f.com Mon Dec 3 00:41:10 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C789821F85AA for ; Mon, 3 Dec 2012 00:41:10 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aqA-ilIhcVE4 for ; Mon, 3 Dec 2012 00:41:10 -0800 (PST) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 3B7D921F858B for ; Mon, 3 Dec 2012 00:41:10 -0800 (PST) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 1FF9D12008FC; Mon, 3 Dec 2012 09:41:09 +0100 (CET) Date: Mon, 03 Dec 2012 09:41:08 +0100 (CET) Message-Id: <20121203.094108.1034288734689078012.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: References: <20121116084024.GA2302@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] LL review of interfaces and ip drafts X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 03 Dec 2012 08:41:10 -0000 Ladislav Lhotka wrote: > OLD > > There are two state data leaf-list nodes "higher-layer-if" and > "lower-layer-if" defined, that contains a read-only view of the > interface layering hierarchy. > > NEW > > Two state data leaf-lists, "higher-layer-if" and "lower-layer-if", > represent a read-only view of the interface layering hierarchy. Ok. > *** Appendix E.1 > > Since the IANA type doesn't discriminate fast and gigabit ethernet, > what is supposed to happen if a physical interface is pre-provisioned > as "fastethernet-1/0" and then a gigabit ethernet port appears at > location "1/0"? This would be up to the vendor, but I'd expect that if a vendor discriminates between fastethernet and gigabitethernet in the name, it would not apply the fastethernet config to a gigabitethernet port. I understand your concern that this essentially puts type information that is not available in 'type' into the name. > ** draft-ietf-netmod-ip-cfg-07 > > *** Section 4 > > - Why are the defaults for "prefix-length" set to 32 for IPv4 and > 128 for IPv6? Such values are only useful for loopback > interfaces. I'd recommend to remove the defaults and make these > leafs mandatory. I think these defaults were suggested by someone on the list? Anyway, I would like to hear other people's opinion as well before changing this. > - As we've been discussing in a separate thread, the "ip" leafs > should not use the "inet:ipv[46]-address" types because of the > zone indices. Yes, will be fixed. /martin From j.schoenwaelder@jacobs-university.de Mon Dec 3 02:47:14 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AABC21F8581 for ; Mon, 3 Dec 2012 02:47:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.158 X-Spam-Level: X-Spam-Status: No, score=-103.158 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v0VUqXqtfjdr for ; Mon, 3 Dec 2012 02:47:13 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 9020921F85D8 for ; Mon, 3 Dec 2012 02:47:13 -0800 (PST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id A115420C33; Mon, 3 Dec 2012 11:47:12 +0100 (CET) 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 gSxC8QCnT5e8; Mon, 3 Dec 2012 11:47:12 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3182520C32; Mon, 3 Dec 2012 11:47:11 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 3C4462326648; Mon, 3 Dec 2012 11:47:18 +0100 (CET) Date: Mon, 3 Dec 2012 11:47:18 +0100 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20121203104717.GA16869@elstar.local> Mail-Followup-To: Ladislav Lhotka , Martin Bjorklund , netmod@ietf.org References: <743AE045-177A-4C9C-B90A-45B769E8EE64@nic.cz> <20121129092233.GA2172@elstar.local> <20121129.224738.335399884.mbj@tail-f.com> <20121130101545.GA6989@elstar.local> <3CDC6495-DDAE-4190-B84E-D3BA6EAF5F4D@nic.cz> <20121130104426.GA7067@elstar.local> <20121130105318.GA7104@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] IP addresses with zone indices 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, 03 Dec 2012 10:47:14 -0000 On Fri, Nov 30, 2012 at 04:51:05PM +0100, Ladislav Lhotka wrote: > Not a big deal for human readers, if they never mind the regular > expressions, but it means a performance penalty for automatic > validation. Given that something like 95 % IP addresses appearing > elsewhere in configurations or state data will not use zone indices, > I am not sure it is worth the extra cycles. Perhaps a better model > for those places that permit zone indices would be I do not know where your 95% are coming from. I also do not see what the performance penalty really is in the sense that I have not seen hard numbers. YANG was designed to allow such (inline) subtypings and unless there is _evidence_ it is broken, I think we should be fine using it. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From lhotka@nic.cz Mon Dec 3 03:05:50 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D82C21F86CC for ; Mon, 3 Dec 2012 03:05:50 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DSu9JlQxKI4R for ; Mon, 3 Dec 2012 03:05:50 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 148A721F86C0 for ; Mon, 3 Dec 2012 03:05:49 -0800 (PST) Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 2BC7113F8B3; Mon, 3 Dec 2012 12:05:48 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1354532748; bh=5GuKdVxwyvC0/W/eDJDJSTUH90MVmafzUly4LxFk0O4=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=i7qfLKyK6OqdF7JjiqiYteajSRiuezRJ7dyVVxNZbwKIEhTIDNQaygX351tG9wkJ0 69nSD13RNpH1c/5o7SfBNCUfPAgwVuhqPxyDdqGAz00J2R15aDJ3V/I5PvUViLhMLn AEiwXqUYmsmbfxt8exfTLfKJq+uq75KMW32F+8GA= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ladislav Lhotka In-Reply-To: <20121203104717.GA16869@elstar.local> Date: Mon, 3 Dec 2012 12:05:42 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <8C4E91C9-7D8B-4F51-A9E6-867CBB7D979F@nic.cz> References: <743AE045-177A-4C9C-B90A-45B769E8EE64@nic.cz> <20121129092233.GA2172@elstar.local> <20121129.224738.335399884.mbj@tail-f.com> <20121130101545.GA6989@elstar.local> <3CDC6495-DDAE-4190-B84E-D3BA6EAF5F4D@nic.cz> <20121130104426.GA7067@elstar.local> <20121130105318.GA7104@elstar.local> <20121203104717.GA16869@elstar.local> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.1499) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] IP addresses with zone indices X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 03 Dec 2012 11:05:50 -0000 On Dec 3, 2012, at 11:47 AM, Juergen Schoenwaelder = wrote: > On Fri, Nov 30, 2012 at 04:51:05PM +0100, Ladislav Lhotka wrote: >=20 >> Not a big deal for human readers, if they never mind the regular >> expressions, but it means a performance penalty for automatic >> validation. Given that something like 95 % IP addresses appearing >> elsewhere in configurations or state data will not use zone indices, >> I am not sure it is worth the extra cycles. Perhaps a better model >> for those places that permit zone indices would be >=20 > I do not know where your 95% are coming from. I also do not see what Zone indices are used in routes with destination prefixes based on = link-local addresses. In my experience, these are pretty rare. Are there = any other uses? Maybe 95 % is still too low. Anyway, by including support for these corner cases in the essential = "ipv4-address" type, every use of this type is forced to check for the = presence of a zone index. Implementors who forget about this (I and = Martin also did, right?) will open security holes for attackers. Lada > the performance penalty really is in the sense that I have not seen > hard numbers. YANG was designed to allow such (inline) subtypings and > unless there is _evidence_ it is broken, I think we should be fine > using it. >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From j.schoenwaelder@jacobs-university.de Mon Dec 3 07:15:45 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4311321F87EF for ; Mon, 3 Dec 2012 07:15:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.165 X-Spam-Level: X-Spam-Status: No, score=-103.165 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GHCy79gB4bh9 for ; Mon, 3 Dec 2012 07:15:44 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 5C5CE21F846B for ; Mon, 3 Dec 2012 07:15:44 -0800 (PST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7B52320C1F; Mon, 3 Dec 2012 16:15:43 +0100 (CET) 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 aI_MIZqZKrpu; Mon, 3 Dec 2012 16:15:43 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 07E8520C1B; Mon, 3 Dec 2012 16:15:43 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 2149A2327148; Mon, 3 Dec 2012 16:15:51 +0100 (CET) Date: Mon, 3 Dec 2012 16:15:50 +0100 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20121203151550.GC17342@elstar.local> Mail-Followup-To: Ladislav Lhotka , Martin Bjorklund , netmod@ietf.org References: <20121129.224738.335399884.mbj@tail-f.com> <20121130101545.GA6989@elstar.local> <3CDC6495-DDAE-4190-B84E-D3BA6EAF5F4D@nic.cz> <20121130104426.GA7067@elstar.local> <20121130105318.GA7104@elstar.local> <20121203104717.GA16869@elstar.local> <8C4E91C9-7D8B-4F51-A9E6-867CBB7D979F@nic.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8C4E91C9-7D8B-4F51-A9E6-867CBB7D979F@nic.cz> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] IP addresses with zone indices 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, 03 Dec 2012 15:15:45 -0000 On Mon, Dec 03, 2012 at 12:05:42PM +0100, Ladislav Lhotka wrote: > > On Dec 3, 2012, at 11:47 AM, Juergen Schoenwaelder wrote: > > > On Fri, Nov 30, 2012 at 04:51:05PM +0100, Ladislav Lhotka wrote: > > > >> Not a big deal for human readers, if they never mind the regular > >> expressions, but it means a performance penalty for automatic > >> validation. Given that something like 95 % IP addresses appearing > >> elsewhere in configurations or state data will not use zone indices, > >> I am not sure it is worth the extra cycles. Perhaps a better model > >> for those places that permit zone indices would be > > > > I do not know where your 95% are coming from. I also do not see what > > Zone indices are used in routes with destination prefixes based on link-local addresses. In my experience, these are pretty rare. Are there any other uses? > > Maybe 95 % is still too low. > > Anyway, by including support for these corner cases in the essential "ipv4-address" type, every use of this type is forced to check for the presence of a zone index. Implementors who forget about this (I and Martin also did, right?) will open security holes for attackers. > Our goal is to finish up the interfaces/ip/routing documents and there seems to be a simple solution to get this done with what we have. If you want to make proposals for 6021bis, please feel free to do so but mark such proposals clearly as that. /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 Dec 3 08:25:08 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4378E21F887C for ; Mon, 3 Dec 2012 08:25:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.929 X-Spam-Level: X-Spam-Status: No, score=-1.929 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0zCB40K9tF54 for ; Mon, 3 Dec 2012 08:25:07 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 1166921F887D for ; Mon, 3 Dec 2012 08:25:06 -0800 (PST) Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id F23C513F97A; Mon, 3 Dec 2012 17:25:04 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1354551905; bh=tp+UInMPFrVf0p4ZXy8Rw+FldizpPNTrx/zqfxYZvEU=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=H9EIT/sIZ6acUf8+zNXvtVw+En1v8OnVCHgORWtlSe/7MBNTekpznDoMhl/HNU7/Y GAU5DGzUvUjXSMmlty9W9vFprVNgzbq1/qbKPZpkHJF+i6ia+kLOp8JLHBS+zPfqO/ lPFA0HVRANZLqCieQA3LacTgUM77S+iVcyQOUW+0= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ladislav Lhotka In-Reply-To: <20121203151550.GC17342@elstar.local> Date: Mon, 3 Dec 2012 17:24:59 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <2105C80D-48CA-494B-A62A-8A1BA5919D42@nic.cz> References: <20121129.224738.335399884.mbj@tail-f.com> <20121130101545.GA6989@elstar.local> <3CDC6495-DDAE-4190-B84E-D3BA6EAF5F4D@nic.cz> <20121130104426.GA7067@elstar.local> <20121130105318.GA7104@elstar.local> <20121203104717.GA16869@elstar.local> <8C4E91C9-7D8B-4F51-A9E6-867CBB7D979F@nic.cz> <20121203151550.GC17342@elstar.local> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.1499) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] IP addresses with zone indices X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 03 Dec 2012 16:25:08 -0000 On Dec 3, 2012, at 4:15 PM, Juergen Schoenwaelder = wrote: > On Mon, Dec 03, 2012 at 12:05:42PM +0100, Ladislav Lhotka wrote: >>=20 >> On Dec 3, 2012, at 11:47 AM, Juergen Schoenwaelder = wrote: >>=20 >>> On Fri, Nov 30, 2012 at 04:51:05PM +0100, Ladislav Lhotka wrote: >>>=20 >>>> Not a big deal for human readers, if they never mind the regular >>>> expressions, but it means a performance penalty for automatic >>>> validation. Given that something like 95 % IP addresses appearing >>>> elsewhere in configurations or state data will not use zone = indices, >>>> I am not sure it is worth the extra cycles. Perhaps a better model >>>> for those places that permit zone indices would be >>>=20 >>> I do not know where your 95% are coming from. I also do not see what >>=20 >> Zone indices are used in routes with destination prefixes based on = link-local addresses. In my experience, these are pretty rare. Are there = any other uses? >>=20 >> Maybe 95 % is still too low. >>=20 >> Anyway, by including support for these corner cases in the essential = "ipv4-address" type, every use of this type is forced to check for the = presence of a zone index. Implementors who forget about this (I and = Martin also did, right?) will open security holes for attackers. >>=20 >=20 > Our goal is to finish up the interfaces/ip/routing documents and there > seems to be a simple solution to get this done with what we have. If > you want to make proposals for 6021bis, please feel free to do so but > mark such proposals clearly as that. No, I don't want to do this, at least not now. But we have two problems = with the ip and routing documents, and I think we should agree on a = coordinated approach and avoid repeating type definitions: 1. For some IPv4 and IPv6 addresses we don't want to allow the zone-id = part. 2. Some leafs ("netmask" in ip and "router-id" in routing) use the = "inet:ipv4-address" type but are no IP addresses, and cannot contain the = zone-id either. #1 can be solved by restricting the "inet:ipv[46]-address" with another = pattern, though I am not happy with it. (Note, however, that there is now way to restrict the union type = "inet:ip-address" in order to get rid of the zone-id.) To solve #2, I propose to add the following typedef to the "ietf-ip" = module, which can be used for "ip:netmask", "rt:router-id", and later = for OSPF Area ID etc. typedef dotted-quad { type string { pattern '(([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])\.){3}' + '([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])'; } description "An unsigned 32-bit number expressed in the dotted-quad notation, i.e., four octets written as decimal numbers and separated with the '.' (full stop) character. In the canonical format, leading zeros in all octets are suppressed except for a zero octet which is written as '0' (single digit zero). "; }=20 Lada >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From mbj@tail-f.com Tue Dec 4 12:19:07 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8A1C21F8BA0 for ; Tue, 4 Dec 2012 12:19:07 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sZpyqhqBLi9o for ; Tue, 4 Dec 2012 12:19:06 -0800 (PST) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 7CD8421F8AA3 for ; Tue, 4 Dec 2012 12:19:06 -0800 (PST) Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 1B8FE1200D00; Tue, 4 Dec 2012 21:19:04 +0100 (CET) Date: Tue, 04 Dec 2012 21:19:03 +0100 (CET) Message-Id: <20121204.211903.458434883.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: <2105C80D-48CA-494B-A62A-8A1BA5919D42@nic.cz> References: <8C4E91C9-7D8B-4F51-A9E6-867CBB7D979F@nic.cz> <20121203151550.GC17342@elstar.local> <2105C80D-48CA-494B-A62A-8A1BA5919D42@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] IP addresses with zone indices X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 04 Dec 2012 20:19:07 -0000 Ladislav Lhotka wrote: > > On Dec 3, 2012, at 4:15 PM, Juergen Schoenwaelder > wrote: > > > On Mon, Dec 03, 2012 at 12:05:42PM +0100, Ladislav Lhotka wrote: > >> > >> On Dec 3, 2012, at 11:47 AM, Juergen Schoenwaelder > >> wrote: > >> > >>> On Fri, Nov 30, 2012 at 04:51:05PM +0100, Ladislav Lhotka wrote: > >>> > >>>> Not a big deal for human readers, if they never mind the regular > >>>> expressions, but it means a performance penalty for automatic > >>>> validation. Given that something like 95 % IP addresses appearing > >>>> elsewhere in configurations or state data will not use zone indices, > >>>> I am not sure it is worth the extra cycles. Perhaps a better model > >>>> for those places that permit zone indices would be > >>> > >>> I do not know where your 95% are coming from. I also do not see what > >> > >> Zone indices are used in routes with destination prefixes based on > >> link-local addresses. In my experience, these are pretty rare. Are there > >> any other uses? > >> > >> Maybe 95 % is still too low. > >> > >> Anyway, by including support for these corner cases in the essential > >> "ipv4-address" type, every use of this type is forced to check for the > >> presence of a zone index. Implementors who forget about this (I and Martin > >> also did, right?) will open security holes for attackers. > >> > > > > Our goal is to finish up the interfaces/ip/routing documents and there > > seems to be a simple solution to get this done with what we have. If > > you want to make proposals for 6021bis, please feel free to do so but > > mark such proposals clearly as that. > > No, I don't want to do this, at least not now. But we have two problems with > the ip and routing documents, and I think we should agree on a coordinated > approach and avoid repeating type definitions: > > 1. For some IPv4 and IPv6 addresses we don't want to allow the zone-id part. This is currently a problem only for ip, and my intention is to solve it there. > 2. Some leafs ("netmask" in ip and "router-id" in routing) use the > "inet:ipv4-address" type but are no IP addresses, and cannot contain the > zone-id either. > > #1 can be solved by restricting the "inet:ipv[46]-address" with another > #pattern, though I am not happy with it. This is what I had in mind. > (Note, however, that there is now way to restrict the union type > "inet:ip-address" in order to get rid of the zone-id.) > > To solve #2, I propose to add the following typedef to the "ietf-ip" module, > which can be used for "ip:netmask", "rt:router-id", and later for OSPF Area ID > etc. > > typedef dotted-quad { > type string { > pattern > '(([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])\.){3}' > + '([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])'; > } > description > "An unsigned 32-bit number expressed in the dotted-quad > notation, i.e., four octets written as decimal numbers > and separated with the '.' (full stop) character. > > In the canonical format, leading zeros in all octets are > suppressed except for a zero octet which is written as '0' > (single digit zero). > "; > } This is not particularly elegant :( But this is what we have to do today. It would be nice to write: type uint32 { display-format "1d."; } ... in some kind of extended DISPLAY-HINT syntax... Anyway, I don't understand why such a type would belong to either ietf-ip or ietf-inet-types. For now, I think the quickest way forward is to solve this separately in each module. /martin From lhotka@nic.cz Wed Dec 5 01:33:23 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB47321F8BD3 for ; Wed, 5 Dec 2012 01:33:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0wM1zhyg9Mkf for ; Wed, 5 Dec 2012 01:33:22 -0800 (PST) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 49B1321F87CA for ; Wed, 5 Dec 2012 01:33:22 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id ABFE55406A9 for ; Wed, 5 Dec 2012 10:33:16 +0100 (CET) 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 2k42xQNMug8D for ; Wed, 5 Dec 2012 10:33:08 +0100 (CET) Received: from localhost (unknown [217.31.207.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 2EC3D5402D9 for ; Wed, 5 Dec 2012 10:33:04 +0100 (CET) From: Ladislav Lhotka To: netmod@ietf.org In-Reply-To: <20121204.211903.458434883.mbj@tail-f.com> References: <8C4E91C9-7D8B-4F51-A9E6-867CBB7D979F@nic.cz> <20121203151550.GC17342@elstar.local> <2105C80D-48CA-494B-A62A-8A1BA5919D42@nic.cz> <20121204.211903.458434883.mbj@tail-f.com> User-Agent: Notmuch/0.14+100~ge0adf10 (http://notmuchmail.org) Emacs/23.3.50.1 (i386-apple-darwin9.8.0) Mail-Followup-To: netmod@ietf.org Date: Wed, 05 Dec 2012 10:33:02 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [netmod] IP addresses with zone indices X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 05 Dec 2012 09:33:24 -0000 Martin Bjorklund writes: >> >> 1. For some IPv4 and IPv6 addresses we don't want to allow the zone-id part. > > This is currently a problem only for ip, and my intention is to solve > it there. Hmm, I am hesitating about things like next-hop in the routing module, but I will probably leave it as it is, i.e. with the optional zone-id. > >> 2. Some leafs ("netmask" in ip and "router-id" in routing) use the >> "inet:ipv4-address" type but are no IP addresses, and cannot contain the >> zone-id either. >> >> #1 can be solved by restricting the "inet:ipv[46]-address" with another >> #pattern, though I am not happy with it. > > This is what I had in mind. > >> (Note, however, that there is now way to restrict the union type >> "inet:ip-address" in order to get rid of the zone-id.) >> >> To solve #2, I propose to add the following typedef to the "ietf-ip" module, >> which can be used for "ip:netmask", "rt:router-id", and later for OSPF Area ID >> etc. >> >> typedef dotted-quad { >> type string { >> pattern >> '(([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])\.){3}' >> + '([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])'; >> } >> description >> "An unsigned 32-bit number expressed in the dotted-quad >> notation, i.e., four octets written as decimal numbers >> and separated with the '.' (full stop) character. >> >> In the canonical format, leading zeros in all octets are >> suppressed except for a zero octet which is written as '0' >> (single digit zero). >> "; >> } > > This is not particularly elegant :( But this is what we have to do Actually, the second paragraph is unnecessary because the pattern doesn't allow leading zeros. > today. It would be nice to write: > > type uint32 { > display-format "1d."; > } I am not sure about this one, because we want the dotted quad format to appear on the wire, but I was thinking about display hints covering several leafs, for instance container ip-address { display-format "concat(ip, '%', 'zone-id')"; leaf ip { type dotted-quad; } leaf zone-id { type string; ... } } > > ... in some kind of extended DISPLAY-HINT syntax... > > > Anyway, I don't understand why such a type would belong to either > ietf-ip or ietf-inet-types. Because then we can avoid having the same pattern in multiple places. What's wrong on such a type? I think it is quite comparable to types like "uint32" which also have no special semantics. > > For now, I think the quickest way forward is to solve this separately > in each module. If you define the above type in ietf-ip, then I can reuse it - ietf-routing already imports ietf-ip. Would this be any slower? Lada -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From andy@yumaworks.com Wed Dec 5 14:50:19 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4E7821F8C3E for ; Wed, 5 Dec 2012 14:50:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YGNPSKxuX1hQ for ; Wed, 5 Dec 2012 14:50:19 -0800 (PST) Received: from mail-vb0-f54.google.com (mail-vb0-f54.google.com [209.85.212.54]) by ietfa.amsl.com (Postfix) with ESMTP id 596B821F8C23 for ; Wed, 5 Dec 2012 14:50:19 -0800 (PST) Received: by mail-vb0-f54.google.com with SMTP id l1so7952846vba.27 for ; Wed, 05 Dec 2012 14:50:18 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :x-gm-message-state; bh=2Fa+M424QDghpLpMpamdxdlY3OlZfoQGTSc/5lQgKI4=; b=jeAbl34qufG3/FdXA3MI5BX/DXEsqSVOecpQT3Ul03rzWkjCXmh8ccWB6E7x4571s7 QYyb2pjNWpEuGEKED0f737JCgPn6yLXcfziDAUMmEUpHm4rXPKaYUnjmowXyr9AGgnvE cOxVqvpvruIcXASD3cyi7d7FUsmnH27fTBgq2o52PrbO38u1dZfGFU50rK0RR9r8yZnq A4xKEhWQ54Z52ta433JwgrwltqFZ1zjE9cG7a4UefYV0ypiBw7KKZ6v3JMwQijuzdA+y fED19+Hua2l2waNMEG6CxpfPu2wo3XrijBjbKYSKxOKpLSLJlgUz5a4FtLoVod6xDd1e tU2w== MIME-Version: 1.0 Received: by 10.52.66.34 with SMTP id c2mr14196923vdt.62.1354747818359; Wed, 05 Dec 2012 14:50:18 -0800 (PST) Received: by 10.58.117.234 with HTTP; Wed, 5 Dec 2012 14:50:17 -0800 (PST) Date: Wed, 5 Dec 2012 14:50:17 -0800 Message-ID: From: Andy Bierman To: netmod@ietf.org Content-Type: multipart/alternative; boundary=20cf307f35c2793d2104d022ceb5 X-Gm-Message-State: ALoCoQkavdfbaOUICMbBrSs9ChBIvZ0LdzV/DBfE3esNQ8l6ww/VAeVNqTWyCsAmKDANGeWnIbCU Subject: [netmod] default NP container question X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 05 Dec 2012 22:50:20 -0000 --20cf307f35c2793d2104d022ceb5 Content-Type: text/plain; charset=UTF-8 Hi, I am not sure which RFC should or does say what to do: container npcon { leaf a { type int32; default 42; } leaf b { type string; } } If you do a in normal mode, the 'npcon' container is not returned. If you do a with-defaults=report-all, the 'npcon' container is returned: npcon { a 42 } So what happens if you do a create operation on /npcon? Is this OK or is it a 'data-exists' error? What about a delete operation on /npcon? Is this OK or a 'data-missing' error? Currently, yuma is doing something wrong -- returning both data-exists on a create and data-missing error on a delete. What are the correct responses? thanks, Andy --20cf307f35c2793d2104d022ceb5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi,

I am not sure which RFC should or does say what to d= o:

container npcon {
=C2=A0 =C2=A0leaf a= { type int32; default 42; }
=C2=A0 =C2=A0leaf b { type string; }=
}

If you do a <get-config> in normal mode, the '= ;npcon' container
is not returned.

<= div>If you do a <get-config> with-defaults=3Dreport-all, the 'npc= on' container
is returned:

=C2=A0npcon {
= =C2=A0 =C2=A0 a 42
=C2=A0}

So what happe= ns if you do a create operation on /npcon?

Is this= OK or is it a 'data-exists' error?

What about a delete operation on /npcon?

=
Is this OK or a 'data-missing' error?

Currently, yuma is doing something wrong -- returning both
data-exists on a create and data-missing error on a delete.
=
What are the correct responses?

thanks,
Andy

--20cf307f35c2793d2104d022ceb5-- From mbj@tail-f.com Wed Dec 5 23:34:46 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9A6D21F8D73 for ; Wed, 5 Dec 2012 23:34:46 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fTvfVnzVZUSL for ; Wed, 5 Dec 2012 23:34:46 -0800 (PST) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 289FD21F8D72 for ; Wed, 5 Dec 2012 23:34:45 -0800 (PST) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 875F712008F7; Thu, 6 Dec 2012 08:34:43 +0100 (CET) Date: Thu, 06 Dec 2012 08:34:43 +0100 (CET) Message-Id: <20121206.083443.1671890726041786212.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] default NP container question X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 06 Dec 2012 07:34:46 -0000 Andy Bierman wrote: > Hi, > > I am not sure which RFC should or does say what to do: 6020 _should_. But it is fuzzy. > container npcon { > leaf a { type int32; default 42; } > leaf b { type string; } > } > > If you do a in normal mode, the 'npcon' container > is not returned. > > If you do a with-defaults=report-all, the 'npcon' container > is returned: > > npcon { > a 42 > } > > So what happens if you do a create operation on /npcon? First of all, operationally this is not very useful, since there is no semantics attached to the presence of such a container. > Is this OK or is it a 'data-exists' error? In my implementation this is a data-exists error. But I can imagine that an implementation that auto-deletes empty NP-containers would allow this create (but then probably auto-delete it right away??) > What about a delete operation on /npcon? > > Is this OK or a 'data-missing' error? In my implementation the effect is that everything below this NP container is deleted. Then if you do a create on the NP container right after the delete you will still get the data-exists error. > Currently, yuma is doing something wrong -- returning both > data-exists on a create and data-missing error on a delete. > > What are the correct responses? Unclear. /martin From lhotka@nic.cz Thu Dec 6 01:21:17 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0363321F862A for ; Thu, 6 Dec 2012 01:21:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_23=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Z8un4QkBvdN for ; Thu, 6 Dec 2012 01:21:16 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 4233721F8629 for ; Thu, 6 Dec 2012 01:21:15 -0800 (PST) Received: from [IPv6:2001:1488:ac14:1400:f825:e1d:2a69:1c6] (unknown [IPv6:2001:1488:ac14:1400:f825:e1d:2a69:1c6]) by mail.nic.cz (Postfix) with ESMTPSA id D39B613F889 for ; Thu, 6 Dec 2012 10:21:13 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1354785673; bh=vDC2wLPQCpuP1HCE0QI5IKHDFLT9h5I+bV7IQq2Ge6I=; h=From:Content-Type:Content-Transfer-Encoding:Subject:Message-Id: Date:To:Mime-Version; b=rppvSQKLIjhgkrl/YVYKC1eU3V6KA0SphY7SYCiPsXArP8xbcVegXdWpnP7ZUm092 h3n1dNccMA+ky7aGtTZSxO1Cmu20TGaK2QadGxnxQcSPhQ3KqSjoQGjBoLhnMWIroP EpEKwOWnXoAFcUwz85+wW3EPLThaK4z4vX5BhsmY= From: Ladislav Lhotka Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <292933AD-8875-4DD0-8FBC-FBCF2212F7E9@nic.cz> Date: Thu, 6 Dec 2012 10:21:15 +0100 To: netmod@ietf.org Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Subject: [netmod] canonical order X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 06 Dec 2012 09:21:17 -0000 Hi, RFC 6020 says in Sec. 12: "The ABNF grammar [RFC5234] defines the canonical order." Does this also include the order of top level nodes as specified in the = ABNF production "body-stmts"? For instance, in the canonical order, should typedefs and groupings come = before data definition statements? Lada -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From mbj@tail-f.com Thu Dec 6 01:41:25 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C74BA21F84F8 for ; Thu, 6 Dec 2012 01:41:25 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qrCGN5ng8Hrh for ; Thu, 6 Dec 2012 01:41:25 -0800 (PST) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 43BE921F8499 for ; Thu, 6 Dec 2012 01:41:25 -0800 (PST) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 1676612008F7; Thu, 6 Dec 2012 10:41:24 +0100 (CET) Date: Thu, 06 Dec 2012 10:41:23 +0100 (CET) Message-Id: <20121206.104123.1917752356435627971.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: <292933AD-8875-4DD0-8FBC-FBCF2212F7E9@nic.cz> References: <292933AD-8875-4DD0-8FBC-FBCF2212F7E9@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] canonical order X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 06 Dec 2012 09:41:25 -0000 Ladislav Lhotka wrote: > Hi, > > RFC 6020 says in Sec. 12: > > "The ABNF grammar [RFC5234] defines the canonical order." > > Does this also include the order of top level nodes as specified in > the ABNF production "body-stmts"? > For instance, in the canonical order, should typedefs and groupings > come before data definition statements? No, since the ABNF defines this as: body-stmts = *((extension-stmt / feature-stmt / identity-stmt / typedef-stmt / grouping-stmt / data-def-stmt / augment-stmt / rpc-stmt / notification-stmt / deviation-stmt) stmtsep) I.e., the grammar explicitly allows any order. /martin From lhotka@nic.cz Thu Dec 6 01:48:22 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8D5821F8680 for ; Thu, 6 Dec 2012 01:48:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_23=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7gYVsDehqo7D for ; Thu, 6 Dec 2012 01:48:22 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 59FB521F867B for ; Thu, 6 Dec 2012 01:48:22 -0800 (PST) Received: from [IPv6:2001:1488:ac14:1400:f825:e1d:2a69:1c6] (unknown [IPv6:2001:1488:ac14:1400:f825:e1d:2a69:1c6]) by mail.nic.cz (Postfix) with ESMTPSA id 4299F13FE21; Thu, 6 Dec 2012 10:48:21 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1354787301; bh=gPUwLMtriS+1ePvgnTkuMp7d0cO7Qpt1d7ibAzMKIDk=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=rnZyejMAcXtVA+DT2l/EU2Y/jNImCrZMzHjGadJXRvOxv+jKHS3BTmkciyMDBXTWF Vw9DEFhxw6eHcxJRuNatbSJ3iT8nAxq1qOo1VbUmgihAZhQj1Ugz3xiuGAeiiCe5M+ 7pmX7S5KjxPdXGosrWD28mZfvEWzZT+GQnv6A6LQ= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ladislav Lhotka In-Reply-To: <20121206.104123.1917752356435627971.mbj@tail-f.com> Date: Thu, 6 Dec 2012 10:48:22 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <3241F08B-14E1-4DFF-AA50-5053DB36F6D0@nic.cz> References: <292933AD-8875-4DD0-8FBC-FBCF2212F7E9@nic.cz> <20121206.104123.1917752356435627971.mbj@tail-f.com> To: Martin Bjorklund X-Mailer: Apple Mail (2.1499) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] canonical order X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 06 Dec 2012 09:48:23 -0000 On Dec 6, 2012, at 10:41 AM, Martin Bjorklund wrote: > Ladislav Lhotka wrote: >> Hi, >>=20 >> RFC 6020 says in Sec. 12: >>=20 >> "The ABNF grammar [RFC5234] defines the canonical order." >>=20 >> Does this also include the order of top level nodes as specified in >> the ABNF production "body-stmts"? >> For instance, in the canonical order, should typedefs and groupings >> come before data definition statements? >=20 > No, since the ABNF defines this as: >=20 > body-stmts =3D *((extension-stmt / > feature-stmt / > identity-stmt / > typedef-stmt / > grouping-stmt / > data-def-stmt / > augment-stmt / > rpc-stmt / > notification-stmt / > deviation-stmt) stmtsep) >=20 >=20 > I.e., the grammar explicitly allows any order. Yet this is probably the level where a canonical ordering is most = important because the items are most spread apart. For instance, if one = is looking for a typedef in a module, it would be good to know that it = is supposed to be somewhere near the beginning of the module. Lada >=20 >=20 > /martin -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From lhotka@nic.cz Thu Dec 6 02:06:55 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A0BF21F85E7 for ; Thu, 6 Dec 2012 02:06:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.256 X-Spam-Level: X-Spam-Status: No, score=-1.256 tagged_above=-999 required=5 tests=[AWL=-0.744, BAYES_05=-1.11, J_CHICKENPOX_23=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yiLVRkH+3kxe for ; Thu, 6 Dec 2012 02:06:55 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id B43CB21F85B4 for ; Thu, 6 Dec 2012 02:06:54 -0800 (PST) Received: from [IPv6:2001:1488:ac14:1400:f825:e1d:2a69:1c6] (unknown [IPv6:2001:1488:ac14:1400:f825:e1d:2a69:1c6]) by mail.nic.cz (Postfix) with ESMTPSA id DD52B13F889 for ; Thu, 6 Dec 2012 11:06:53 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1354788413; bh=iG+KZAaOiPyLiHFtBtMDKgYAhC1jn5/yvS3jHv2SfW8=; h=From:Content-Type:Content-Transfer-Encoding:Subject:Message-Id: Date:To:Mime-Version; b=wDYoX4h0yTghCtO9ehK+Px3NL0ZLp+bpXSu2gJIwIoiWPb+hY1apr7bda/H3rzoEh +yUeABvuOQIQIBxMQ2qcz/v1dI/YeRRSVjEO9oGsm6hFl39eiPUPZSnaai+h2HfnkF oGv0P74Bir4FQREJTNKMrCVr626sHms1487uOU9E= From: Ladislav Lhotka Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <3D0B9D01-444B-49CF-B5D5-29F80E91A5A6@nic.cz> Date: Thu, 6 Dec 2012 11:06:54 +0100 To: netmod@ietf.org Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Subject: [netmod] is identity derivation reflexive? X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 06 Dec 2012 10:06:55 -0000 Hi, Jernej sent me a bug report for RFC 6110 which surprised me: So far, I = have assumed that identity derivation is a reflexive relation, so that, = using for example the "my-crypto" module in RFC 6020, Sec. 9.10.5, = "crypto:crypto-alg" is a valid value of the "crypto" leaf. Is it correct? Lada -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From mbj@tail-f.com Thu Dec 6 02:13:21 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E11D21F861E for ; Thu, 6 Dec 2012 02:13:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.839 X-Spam-Level: X-Spam-Status: No, score=-0.839 tagged_above=-999 required=5 tests=[AWL=-1.207, BAYES_40=-0.185, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cnESIHbufKjw for ; Thu, 6 Dec 2012 02:13:21 -0800 (PST) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 6F19A21F861A for ; Thu, 6 Dec 2012 02:13:20 -0800 (PST) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id AA30412008B7; Thu, 6 Dec 2012 11:13:19 +0100 (CET) Date: Thu, 06 Dec 2012 11:13:19 +0100 (CET) Message-Id: <20121206.111319.487627637617721147.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: <3D0B9D01-444B-49CF-B5D5-29F80E91A5A6@nic.cz> References: <3D0B9D01-444B-49CF-B5D5-29F80E91A5A6@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] is identity derivation reflexive? X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 06 Dec 2012 10:13:21 -0000 Ladislav Lhotka wrote: > Hi, > > Jernej sent me a bug report for RFC 6110 which surprised me: So far, I > have assumed that identity derivation is a reflexive relation, so > that, using for example the "my-crypto" module in RFC 6020, > Sec. 9.10.5, "crypto:crypto-alg" is a valid value of the "crypto" > leaf. > > Is it correct? No. Section 9.10.2 says: Valid values for an identityref are any identities derived from the identityref's base identity. /martin From jernej.tuljak@mg-soft.si Thu Dec 6 03:15:02 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D783721F8728 for ; Thu, 6 Dec 2012 03:15:02 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fwJjbV2wcP02 for ; Thu, 6 Dec 2012 03:15:02 -0800 (PST) Received: from gate.mg-soft.si (gate.mg-soft.si [212.30.73.66]) by ietfa.amsl.com (Postfix) with ESMTP id EA66721F873C for ; Thu, 6 Dec 2012 03:15:01 -0800 (PST) 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 qB6BEtIc007771; Thu, 6 Dec 2012 12:14:56 +0100 Message-ID: <50C07E2F.3060806@mg-soft.com> Date: Thu, 06 Dec 2012 12:14:55 +0100 From: Jernej Tuljak User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Martin Bjorklund References: <3D0B9D01-444B-49CF-B5D5-29F80E91A5A6@nic.cz> <20121206.111319.487627637617721147.mbj@tail-f.com> In-Reply-To: <20121206.111319.487627637617721147.mbj@tail-f.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] is identity derivation reflexive? X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 06 Dec 2012 11:15:03 -0000 Dne 6.12.2012 11:13, piše Martin Bjorklund: > Ladislav Lhotka wrote: >> Hi, >> >> Jernej sent me a bug report for RFC 6110 which surprised me: So far, I >> have assumed that identity derivation is a reflexive relation, so >> that, using for example the "my-crypto" module in RFC 6020, >> Sec. 9.10.5, "crypto:crypto-alg" is a valid value of the "crypto" >> leaf. >> >> Is it correct? > No. Section 9.10.2 says: > > Valid values for an identityref are any identities derived from the > identityref's base identity. Is it transitive? Can one assume that Z is derived from X, if Y is derived from X and Z is derived from Y? Can an identity which is used as an argument to another identities' base-stmt ever appear as a value of a data node at all? Jernej > > /martin > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From mbj@tail-f.com Thu Dec 6 03:23:21 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 536DC21F84C7 for ; Thu, 6 Dec 2012 03:23:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.805 X-Spam-Level: X-Spam-Status: No, score=-1.805 tagged_above=-999 required=5 tests=[AWL=0.241, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WMkEl1JJbtLT for ; Thu, 6 Dec 2012 03:23:20 -0800 (PST) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id A3B0B21F8648 for ; Thu, 6 Dec 2012 03:23:20 -0800 (PST) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id A255C12008F7; Thu, 6 Dec 2012 12:23:19 +0100 (CET) Date: Thu, 06 Dec 2012 12:23:19 +0100 (CET) Message-Id: <20121206.122319.2144453488107033976.mbj@tail-f.com> To: jernej.tuljak@mg-soft.si From: Martin Bjorklund In-Reply-To: <50C07E2F.3060806@mg-soft.com> References: <3D0B9D01-444B-49CF-B5D5-29F80E91A5A6@nic.cz> <20121206.111319.487627637617721147.mbj@tail-f.com> <50C07E2F.3060806@mg-soft.com> X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-15 Content-Transfer-Encoding: quoted-printable Cc: netmod@ietf.org Subject: Re: [netmod] is identity derivation reflexive? X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 06 Dec 2012 11:23:21 -0000 Jernej Tuljak wrote: > Dne 6.12.2012 11:13, pi=A8e Martin Bjorklund: > > Ladislav Lhotka wrote: > >> Hi, > >> > >> Jernej sent me a bug report for RFC 6110 which surprised me: So fa= r, I > >> have assumed that identity derivation is a reflexive relation, so > >> that, using for example the "my-crypto" module in RFC 6020, > >> Sec. 9.10.5, "crypto:crypto-alg" is a valid value of the "crypto" > >> leaf. > >> > >> Is it correct? > > No. Section 9.10.2 says: > > > > Valid values for an identityref are any identities derived from= the > > identityref's base identity. > = > Is it transitive? Can one assume that Z is derived from X, if Y is > derived from X and Z is derived from Y? Yes (it seems this could be made more clear in the text). > Can an identity which is used > as an argument to another identities' base-stmt ever appear as a valu= e > of a data node at all? Sure: identity a; identity b { base a; } identity c { base b; } leaf foo { type identityref { base a; } default b; // valid } = /martin From lhotka@nic.cz Thu Dec 6 03:32:46 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29B3E21F8728 for ; Thu, 6 Dec 2012 03:32:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.752 X-Spam-Level: X-Spam-Status: No, score=-1.752 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wHn+1iSn1+4V for ; Thu, 6 Dec 2012 03:32:45 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 7BAB221F865D for ; Thu, 6 Dec 2012 03:32:45 -0800 (PST) Received: from [IPv6:2001:1488:ac14:1400:f825:e1d:2a69:1c6] (unknown [IPv6:2001:1488:ac14:1400:f825:e1d:2a69:1c6]) by mail.nic.cz (Postfix) with ESMTPSA id 435AA13FDF5 for ; Thu, 6 Dec 2012 12:32:44 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1354793564; bh=Z2hqz5/3D9P5MDL3SQB2Cm7M59t9IHltXQvwux84zGs=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date: Content-Transfer-Encoding:Message-Id:References:To; b=PAyAR6pWIe2d1/r2fNBjQJO3zPCNzD0BXdqpVIkjjC3a09U0XmO90zaSW5qE6xZ9c hh4pRge8e1TfTYqOKho3q7Tilpofj0uyc1K0MtDLRNyrNLm1bveeZcYAX1eutLMqMA kf3eJkc3d36aaCyLIofobKHZFaHD6jeENNMI6eMo= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ladislav Lhotka In-Reply-To: <20121206.122319.2144453488107033976.mbj@tail-f.com> Date: Thu, 6 Dec 2012 12:32:45 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <3D0B9D01-444B-49CF-B5D5-29F80E91A5A6@nic.cz> <20121206.111319.487627637617721147.mbj@tail-f.com> <50C07E2F.3060806@mg-soft.com> <20121206.122319.2144453488107033976.mbj@tail-f.com> To: netmod@ietf.org X-Mailer: Apple Mail (2.1499) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Subject: Re: [netmod] is identity derivation reflexive? X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 06 Dec 2012 11:32:46 -0000 On Dec 6, 2012, at 12:23 PM, Martin Bjorklund wrote: > Jernej Tuljak wrote: >> Dne 6.12.2012 11:13, pi=9Ae Martin Bjorklund: >>> Ladislav Lhotka wrote: >>>> Hi, >>>>=20 >>>> Jernej sent me a bug report for RFC 6110 which surprised me: So = far, I >>>> have assumed that identity derivation is a reflexive relation, so >>>> that, using for example the "my-crypto" module in RFC 6020, >>>> Sec. 9.10.5, "crypto:crypto-alg" is a valid value of the "crypto" >>>> leaf. >>>>=20 >>>> Is it correct? >>> No. Section 9.10.2 says: >>>=20 >>> Valid values for an identityref are any identities derived from = the >>> identityref's base identity. >>=20 >> Is it transitive? Can one assume that Z is derived from X, if Y is >> derived from X and Z is derived from Y? >=20 > Yes (it seems this could be made more clear in the text). >=20 >> Can an identity which is used >> as an argument to another identities' base-stmt ever appear as a = value >> of a data node at all? >=20 > Sure: >=20 > identity a; >=20 > identity b { > base a; > } >=20 > identity c { > base b; > } >=20 > leaf foo { > type identityref { > base a; > } > default b; // valid > } >=20 OK, so what are the permitted values of the following type in this case? type identityref { base b; } Lada >=20 > /martin -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From jernej.tuljak@mg-soft.si Thu Dec 6 06:43:02 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B766321F86EA for ; Thu, 6 Dec 2012 06:43:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SiyZAtDvciMr for ; Thu, 6 Dec 2012 06:43:02 -0800 (PST) Received: from gate.mg-soft.si (gate.mg-soft.si [212.30.73.66]) by ietfa.amsl.com (Postfix) with ESMTP id 9A8C821F86C6 for ; Thu, 6 Dec 2012 06:43:01 -0800 (PST) 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 qB6EgxQG011949; Thu, 6 Dec 2012 15:42:59 +0100 Message-ID: <50C0AEF2.4030102@mg-soft.com> Date: Thu, 06 Dec 2012 15:42:58 +0100 From: Jernej Tuljak User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Ladislav Lhotka References: <3D0B9D01-444B-49CF-B5D5-29F80E91A5A6@nic.cz> <20121206.111319.487627637617721147.mbj@tail-f.com> <50C07E2F.3060806@mg-soft.com> <20121206.122319.2144453488107033976.mbj@tail-f.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] is identity derivation reflexive? X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 06 Dec 2012 14:43:02 -0000 Dne 6.12.2012 12:32, piše Ladislav Lhotka: > On Dec 6, 2012, at 12:23 PM, Martin Bjorklund wrote: > >> Jernej Tuljak wrote: >>> Dne 6.12.2012 11:13, piše Martin Bjorklund: >>>> Ladislav Lhotka wrote: >>>>> Hi, >>>>> >>>>> Jernej sent me a bug report for RFC 6110 which surprised me: So far, I >>>>> have assumed that identity derivation is a reflexive relation, so >>>>> that, using for example the "my-crypto" module in RFC 6020, >>>>> Sec. 9.10.5, "crypto:crypto-alg" is a valid value of the "crypto" >>>>> leaf. >>>>> >>>>> Is it correct? >>>> No. Section 9.10.2 says: >>>> >>>> Valid values for an identityref are any identities derived from the >>>> identityref's base identity. >>> Is it transitive? Can one assume that Z is derived from X, if Y is >>> derived from X and Z is derived from Y? >> Yes (it seems this could be made more clear in the text). >> >>> Can an identity which is used >>> as an argument to another identities' base-stmt ever appear as a value >>> of a data node at all? >> Sure: >> >> identity a; >> >> identity b { >> base a; >> } >> >> identity c { >> base b; >> } >> >> leaf foo { >> type identityref { >> base a; >> } >> default b; // valid >> } >> > OK, so what are the permitted values of the following type in this case? > > type identityref { > base b; > } "c" only I guess. Since that is the only identity derived from "b" which is your identityref's base. For Martin's example both "b" and "c" are valid (due to transitivity). A bit strange that such values are allowed only indirectly. Changing the module this way: identity x; identity a {base x;} identity b {base a;} identity c {base b;} leaf foo { type identityref { base x; } default b; } would allow "a" too. I agree that all of this needs clarifications in the RFC. I tested it during inter-op and I remember that at least one server allowed the referenced base identity to be a valid value for an identityref leaf. Jernej > Lada > >> /martin > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From andy@yumaworks.com Thu Dec 6 07:25:14 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF10721F8774 for ; Thu, 6 Dec 2012 07:25:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CMh36ywBZTbF for ; Thu, 6 Dec 2012 07:25:14 -0800 (PST) Received: from mail-vb0-f54.google.com (mail-vb0-f54.google.com [209.85.212.54]) by ietfa.amsl.com (Postfix) with ESMTP id 0D10021F86FF for ; Thu, 6 Dec 2012 07:25:13 -0800 (PST) Received: by mail-vb0-f54.google.com with SMTP id l1so9392049vba.27 for ; Thu, 06 Dec 2012 07:25:11 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=nguVp6EJLHrOvuE2nMraMU9/WzVhPcU8xhSC6WHiC04=; b=Kfe6u2S8Fa70npL7QoVCUqf+ccepXgIiudzapEfXRl3s5zvzQZhWTCdjIcDN6quGYi s6Y3CAxyQDnGhO4SmjR3SvzdzTlpQN798BmX4U9II8UG3tVS4OL4opGYSPmC0u0F1j3E 7K8mRYjc0Wy/2+9Q3mJfjaWAisG8AEW9WZxHDMZeeu3N0YriYd/5Q6BZZYMyr9eg1JDb BgWPpokEaAiDr7T0d8MA2W3mraWlzJwgC0haioDnq2l4RGpDIrou3TPwmQCM03R3xoBO j4vzoLgHB3TezbDYEOBiX4n+mXAUco7nVtOrt83X540c76C83qug4BT5f+6xx0T4PIeY +ahw== MIME-Version: 1.0 Received: by 10.220.141.206 with SMTP id n14mr1290342vcu.64.1354807510888; Thu, 06 Dec 2012 07:25:10 -0800 (PST) Received: by 10.58.117.234 with HTTP; Thu, 6 Dec 2012 07:25:10 -0800 (PST) In-Reply-To: <20121206.083443.1671890726041786212.mbj@tail-f.com> References: <20121206.083443.1671890726041786212.mbj@tail-f.com> Date: Thu, 6 Dec 2012 07:25:10 -0800 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: multipart/alternative; boundary=f46d042f9d486cef9504d030b4c3 X-Gm-Message-State: ALoCoQn/hE/nn2Nflb3bJcwyETZs43S/yItwvw/XjX9fSEOi5xuCn6SkGCPKNsSKDWlqZ5n1ID/G Cc: netmod@ietf.org Subject: Re: [netmod] default NP container question X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 06 Dec 2012 15:25:15 -0000 --f46d042f9d486cef9504d030b4c3 Content-Type: text/plain; charset=UTF-8 On Wed, Dec 5, 2012 at 11:34 PM, Martin Bjorklund wrote: > Andy Bierman wrote: > > Hi, > > > > I am not sure which RFC should or does say what to do: > > 6020 _should_. But it is fuzzy. > > > container npcon { > > leaf a { type int32; default 42; } > > leaf b { type string; } > > } > > > > If you do a in normal mode, the 'npcon' container > > is not returned. > > > > If you do a with-defaults=report-all, the 'npcon' container > > is returned: > > > > npcon { > > a 42 > > } > > > > So what happens if you do a create operation on /npcon? > > First of all, operationally this is not very useful, since there is no > semantics attached to the presence of such a container. > > The code doesn't know which nodes are useful or not, > > Is this OK or is it a 'data-exists' error? > > In my implementation this is a data-exists error. But I can imagine > that an implementation that auto-deletes empty NP-containers would > allow this create (but then probably auto-delete it right away??) > > I think it should be based on what the server returns as its with-defaults basic mode. In my case, the create should succeed and the delete should fail, because the basic mode does not return the NP container. It is only returned as a default for report-all or report-all-tagged. > > What about a delete operation on /npcon? > > > > Is this OK or a 'data-missing' error? > > In my implementation the effect is that everything below this NP > container is deleted. Then if you do a create on the NP container > right after the delete you will still get the data-exists error. > So you return the NP containers in 'plain' retrieval requests? If so this is consistent. > > > Currently, yuma is doing something wrong -- returning both > > data-exists on a create and data-missing error on a delete. > > > > What are the correct responses? > > Unclear. > Clearly one should fail (create or delete) but not both. > > > /martin > Andy --f46d042f9d486cef9504d030b4c3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Wed, Dec 5, 2012 at 11:34 PM, Martin = Bjorklund <mbj@tail-f.com> wrote:
Andy Bierman <andy@yumaworks.com> wrote:
> Hi,
>
> I am not sure which RFC should or does say what to do:

6020 _should_. =C2=A0But it is fuzzy.

> container npcon {
> =C2=A0 =C2=A0leaf a { type int32; default 42; }
> =C2=A0 =C2=A0leaf b { type string; }
> }
>
> If you do a <get-config> in normal mode, the 'npcon' con= tainer
> is not returned.
>
> If you do a <get-config> with-defaults=3Dreport-all, the 'np= con' container
> is returned:
>
> =C2=A0npcon {
> =C2=A0 =C2=A0 a 42
> =C2=A0}
>
> So what happens if you do a create operation on /npcon?

First of all, operationally this is not very useful, since there is no
semantics attached to the presence of such a container.


> Is this OK or is it a 'data-exists' error?

In my implementation this is a data-exists error. =C2=A0But I can imagine that an implementation that auto-deletes empty NP-containers would
allow this create (but then probably auto-delete it right away??)


because t= he basic mode does not return the NP container. =C2=A0It is only returned
as a default for report-all or report-all-tagged.
=C2=A0
> What about a delete operation on /npcon?
>
> Is this OK or a 'data-missing' error?

In my implementation the effect is that everything below this NP
container is deleted. =C2=A0Then if you do a create on the NP container
right after the delete you will still get the data-exists error.

So you return the NP containers in 'plain'= ; retrieval requests?
If so this is consistent.
=C2=A0<= /div>

> Currently, yuma is doing something wrong -- returning both
> data-exists on a create and data-missing error on a delete.
>
> What are the correct responses?

Unclear.

Clearly one should fail (creat= e or delete) but not both.
=C2=A0


/martin

Andy

--f46d042f9d486cef9504d030b4c3-- From andy@yumaworks.com Thu Dec 6 07:48:41 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F96B21F86F0 for ; Thu, 6 Dec 2012 07:48:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0oeljU1HAWPt for ; Thu, 6 Dec 2012 07:48:40 -0800 (PST) Received: from mail-vb0-f54.google.com (mail-vb0-f54.google.com [209.85.212.54]) by ietfa.amsl.com (Postfix) with ESMTP id 4B3B221F86EE for ; Thu, 6 Dec 2012 07:48:40 -0800 (PST) Received: by mail-vb0-f54.google.com with SMTP id l1so9430578vba.27 for ; Thu, 06 Dec 2012 07:48:39 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=im99bwsF9Rv8je8W+HtExa4ciqJl8UT3lnMeZVl3wro=; b=RgoV/Q7OGOQAdEZD1kCzd2s1ICIbdX5QyBTuCJbW2dAINwGOkp9pHc09IgHJFxUnR0 r7a6t2tAMAuek5sXMpmj2y3luiyzyKKOtIlrQB8McebG1X2bHn4L6MrE3tK2XSFWJWEU c+ZbrPU4O4E3LYsoJep+3K4vi+PKES4xcrVos2hwZNU51j+qR9uzlEZonRSfu+7CWlLV HKi0gs93QRH2qt+Dln8F80aXYCjWoR1ySBcOYmFvbW/Y0Q1lSopnR+8CtcCfuQHGwWyj GrQXA91Wkri8pd/QIMwUMEDPg5oVHGp0oNPk7w+Z3+59U/HI09ujDc4+K5XsAhm5Uso5 aNBA== MIME-Version: 1.0 Received: by 10.58.221.130 with SMTP id qe2mr1482254vec.14.1354808919608; Thu, 06 Dec 2012 07:48:39 -0800 (PST) Received: by 10.58.117.234 with HTTP; Thu, 6 Dec 2012 07:48:39 -0800 (PST) In-Reply-To: <50C0AEF2.4030102@mg-soft.com> References: <3D0B9D01-444B-49CF-B5D5-29F80E91A5A6@nic.cz> <20121206.111319.487627637617721147.mbj@tail-f.com> <50C07E2F.3060806@mg-soft.com> <20121206.122319.2144453488107033976.mbj@tail-f.com> <50C0AEF2.4030102@mg-soft.com> Date: Thu, 6 Dec 2012 07:48:39 -0800 Message-ID: From: Andy Bierman To: Jernej Tuljak Content-Type: multipart/alternative; boundary=047d7bf0cabe644b8604d0310802 X-Gm-Message-State: ALoCoQk3PbkbUruteyvYmuLM91/Hb+Vf8kXqLBl2bH2NSKlJnGs3EWzEf0FegTHVUdylbnkfNP+o Cc: netmod@ietf.org Subject: Re: [netmod] is identity derivation reflexive? X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 06 Dec 2012 15:48:41 -0000 --047d7bf0cabe644b8604d0310802 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Dec 6, 2012 at 6:42 AM, Jernej Tuljak wro= te: > Dne 6.12.2012 12:32, pi=C5=A1e Ladislav Lhotka: > >> On Dec 6, 2012, at 12:23 PM, Martin Bjorklund wrote: >> >> Jernej Tuljak wrote: >>> >>>> Dne 6.12.2012 11:13, pi=C5=A1e Martin Bjorklund: >>>> >>>>> Ladislav Lhotka wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> Jernej sent me a bug report for RFC 6110 which surprised me: So far,= I >>>>>> have assumed that identity derivation is a reflexive relation, so >>>>>> that, using for example the "my-crypto" module in RFC 6020, >>>>>> Sec. 9.10.5, "crypto:crypto-alg" is a valid value of the "crypto" >>>>>> leaf. >>>>>> >>>>>> Is it correct? >>>>>> >>>>> No. Section 9.10.2 says: >>>>> >>>>> Valid values for an identityref are any identities derived from th= e >>>>> identityref's base identity. >>>>> >>>> Is it transitive? Can one assume that Z is derived from X, if Y is >>>> derived from X and Z is derived from Y? >>>> >>> Yes (it seems this could be made more clear in the text). >>> >>> Can an identity which is used >>>> as an argument to another identities' base-stmt ever appear as a value >>>> of a data node at all? >>>> >>> Sure: >>> >>> identity a; >>> >>> identity b { >>> base a; >>> } >>> >>> identity c { >>> base b; >>> } >>> >>> leaf foo { >>> type identityref { >>> base a; >>> } >>> default b; // valid >>> } >>> >>> OK, so what are the permitted values of the following type in this cas= e? >> >> type identityref { >> base b; >> } >> > > "c" only I guess. Since that is the only identity derived from "b" which > is your identityref's base. For Martin's example both "b" and "c" are val= id > (due to transitivity). A bit strange that such values are allowed only > indirectly. Changing the module this way: > > identity x; > > identity a {base x;} > identity b {base a;} > identity c {base b;} > > leaf foo { > type identityref { > base x; > } > default b; > } > > would allow "a" too. > > I agree that all of this needs clarifications in the RFC. I tested it > during inter-op and I remember that at least one server allowed the > referenced base identity to be a valid value for an identityref leaf. > > The identityref does not distinguish between abstract and concrete identities. snacks / \ chips candy / \ | corn potato chocolate The YANG designer picks the base for an identityref leaf and the intent is that only down-stream identities can be used as values. A base(chips) leaf can have corn or potato as values. leaf chip-type { type identityref { base chips; } } But I think the RFC says that chips and snacks would also be valid. Operationally, this is not correct since these values provide no semantics to the 'chip-type' leaf. Jernej > > Lada >> >> /martin >>> >> Andy --047d7bf0cabe644b8604d0310802 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Thu, Dec 6, 2012 at 6:42 AM, Jernej T= uljak <jernej.tuljak@mg-soft.si> wrote:
Dne 6.12.2012 12:32, pi=C5=A1e Ladislav Lhotka:
On Dec 6, 2012, at 12:23 PM, Martin Bjorklund <mbj@tail-f.com> wrote:

Jernej Tuljak <jernej.tuljak@mg-soft.si> wrote:
Dne 6.12.2012 11:13, pi=C5=A1e Martin Bjorklund:
Ladislav Lhotka <lhot= ka@nic.cz> wrote:
Hi,

Jernej sent me a bug report for RFC 6110 which surprised me: So far, I
have assumed that identity derivation is a reflexive relation, so
that, using for example the "my-crypto" module in RFC 6020,
Sec. 9.10.5, "crypto:crypto-alg" is a valid value of the "cr= ypto"
leaf.

Is it correct?
No. =C2=A0Section 9.10.2 says:

=C2=A0 =C2=A0Valid values for an identityref are any identities derived fro= m the
=C2=A0 =C2=A0identityref's base identity.
Is it transitive? Can one assume that Z is derived from X, if Y is
derived from X and Z is derived from Y?
Yes (it seems this could be made more clear in the text).

Can an identity which is used
as an argument to another identities' base-stmt ever appear as a value<= br> of a data node at all?
Sure:

identity a;

identity b {
=C2=A0 =C2=A0base a;
}

identity c {
=C2=A0 =C2=A0base b;
}

leaf foo {
=C2=A0 =C2=A0type identityref {
=C2=A0 =C2=A0 =C2=A0base a;
=C2=A0 =C2=A0}
=C2=A0 =C2=A0default b; =C2=A0// valid
}

OK, so what are the permitted values of the following type in this case?
type identityref {
=C2=A0 base b;
}

"c" only I guess. Since that is the only identity derived from &q= uot;b" which is your identityref's base. For Martin's example = both "b" and "c" are valid (due to transitivity). A bit= strange that such values are allowed only indirectly. Changing the module = this way:

identity x;

identity a {base x;}
identity b {base a;}
identity c {base b;}

leaf foo {
=C2=A0 type identityref {
=C2=A0 =C2=A0 base x;
=C2=A0 }
=C2=A0 default b;
}

would allow "a" too.

I agree that all of this needs clarifications in the RFC. I tested it durin= g inter-op and I remember that at least one server allowed the referenced b= ase identity to be a valid value for an identityref leaf.


The identityref does not distinguish b= etween abstract and concrete identities.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0snacks
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0/ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0\
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0chips =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0candy
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/ = =C2=A0 =C2=A0 \ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0corn =C2=A0 potato =C2=A0 chocolate
The YANG designer picks the base for an identityref leaf
and the intent is that only down-stream identities can be used as valu= es.

A base(chips) leaf can have corn or potato as = values.

=C2=A0 =C2=A0leaf chip-type {
= =C2=A0 =C2=A0 =C2=A0type identityref { base chips; }
=C2=A0 =C2=A0}

But I think the RFC says that = chips and snacks would also be valid.
Operationally, this is not = correct since these values provide no semantics
to the 'chip-= type' leaf.

Jernej

Lada

/martin


<= /div>
Andy

--047d7bf0cabe644b8604d0310802-- From lhotka@nic.cz Thu Dec 6 08:05:57 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E62B221F87D2 for ; Thu, 6 Dec 2012 08:05:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.813 X-Spam-Level: X-Spam-Status: No, score=-1.813 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uHh27ArPHeRK for ; Thu, 6 Dec 2012 08:05:56 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 5056C21F85DB for ; Thu, 6 Dec 2012 08:05:56 -0800 (PST) Received: from [192.168.43.183] (89-24-15-128.i4g.tmcz.cz [89.24.15.128]) by mail.nic.cz (Postfix) with ESMTPSA id 40DC313FDF5; Thu, 6 Dec 2012 17:05:55 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1354809955; bh=gfgUlEDaU9tq3hS0/30coMT3Hx2/mEZAnEXQGG0ImOQ=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=wOb1Po6aI1ih4pEHC0OQAqAXUlDm8ENptaK8ha70eu6KtzaR1pzLA3ih+0vZbjsJR MR6dzmcxPusXIE9h2GyvON8XXaVETh7w4zVhpM3x8HzD2o7gYOUWrpxYw4Fp9XEtGs dSUi2Cbeft7fc11GYYeW/keok4/kRr6gc9C3xFMk= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ladislav Lhotka In-Reply-To: <50C0AEF2.4030102@mg-soft.com> Date: Thu, 6 Dec 2012 17:05:50 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <3D0B9D01-444B-49CF-B5D5-29F80E91A5A6@nic.cz> <20121206.111319.487627637617721147.mbj@tail-f.com> <50C07E2F.3060806@mg-soft.com> <20121206.122319.2144453488107033976.mbj@tail-f.com> <50C0AEF2.4030102@mg-soft.com> To: Jernej Tuljak X-Mailer: Apple Mail (2.1499) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] is identity derivation reflexive? X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 06 Dec 2012 16:05:58 -0000 On Dec 6, 2012, at 3:42 PM, Jernej Tuljak = wrote: > Dne 6.12.2012 12:32, pi=9Ae Ladislav Lhotka: >> On Dec 6, 2012, at 12:23 PM, Martin Bjorklund wrote: >>=20 >>> Jernej Tuljak wrote: >>>> Dne 6.12.2012 11:13, pi=9Ae Martin Bjorklund: >>>>> Ladislav Lhotka wrote: >>>>>> Hi, >>>>>>=20 >>>>>> Jernej sent me a bug report for RFC 6110 which surprised me: So = far, I >>>>>> have assumed that identity derivation is a reflexive relation, so >>>>>> that, using for example the "my-crypto" module in RFC 6020, >>>>>> Sec. 9.10.5, "crypto:crypto-alg" is a valid value of the "crypto" >>>>>> leaf. >>>>>>=20 >>>>>> Is it correct? >>>>> No. Section 9.10.2 says: >>>>>=20 >>>>> Valid values for an identityref are any identities derived from = the >>>>> identityref's base identity. >>>> Is it transitive? Can one assume that Z is derived from X, if Y is >>>> derived from X and Z is derived from Y? >>> Yes (it seems this could be made more clear in the text). >>>=20 >>>> Can an identity which is used >>>> as an argument to another identities' base-stmt ever appear as a = value >>>> of a data node at all? >>> Sure: >>>=20 >>> identity a; >>>=20 >>> identity b { >>> base a; >>> } >>>=20 >>> identity c { >>> base b; >>> } >>>=20 >>> leaf foo { >>> type identityref { >>> base a; >>> } >>> default b; // valid >>> } >>>=20 >> OK, so what are the permitted values of the following type in this = case? >>=20 >> type identityref { >> base b; >> } >=20 > "c" only I guess. Since that is the only identity derived from "b" = which is your identityref's base. For Martin's example both "b" and "c" = are valid (due to transitivity). A bit strange that such values are = allowed only indirectly. Changing the module this way: >=20 > identity x; >=20 > identity a {base x;} > identity b {base a;} > identity c {base b;} >=20 > leaf foo { > type identityref { > base x; > } > default b; > } >=20 > would allow "a" too. >=20 > I agree that all of this needs clarifications in the RFC. I tested it = during inter-op and I remember that at least one server allowed the = referenced base identity to be a valid value for an identityref leaf. I checked the corresponding sections in RFC 6020 and found no text from = which one could conclude that identity derivation is transitive. Section = 9.10.2 only says: "Valid values for an identityref are any identities derived from the = identityref's base identity." In my opinion, the identity derivation should in fact be a partial = ordering, i.e. reflexive, transitive and antisymmetric. Antisymmetricity = is stated in 6020 (no circular derivations) but the other two properties = are not mentioned. Lada =20 >=20 > Jernej >=20 >> Lada >>=20 >>> /martin >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From andy@yumaworks.com Thu Dec 6 08:17:26 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0991B21F86FC for ; Thu, 6 Dec 2012 08:17:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.676 X-Spam-Level: X-Spam-Status: No, score=-2.676 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UH-6xSRjVlAb for ; Thu, 6 Dec 2012 08:17:25 -0800 (PST) Received: from mail-vb0-f54.google.com (mail-vb0-f54.google.com [209.85.212.54]) by ietfa.amsl.com (Postfix) with ESMTP id 11BA221F86EC for ; Thu, 6 Dec 2012 08:17:24 -0800 (PST) Received: by mail-vb0-f54.google.com with SMTP id l1so9481297vba.27 for ; Thu, 06 Dec 2012 08:17:24 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=RKQ3JXPNqZP9saiQ3jFN8RoRO5afEPA+Q7fRkCRYFaU=; b=TVQ1Ryf3T1N+oo8/37wsbXbgc4v2Wsk7sBe/VKVzbNR4FGUm5BhfXcMHAHv3WwRJgT YPoKuQ+VENYLxqgHnQmZp/uArzkJGlDkzE//gGhGBmfIyGIAipwTE8yTxubk1HsBqlGx A5KsU5n/6Hr5JxjhfPbUZioHbBEDrUAi1vxc7JnqktXRz/uzWkkblKLD/ZFSNuYTRaw/ aNC+WQ31dNhKaNxpPv9do7ft0L6D/Tb94/rLQJTOPFHnvb/VLUYkhL7ujXXxizJXkX/Z FOHh+SICI1YyVNY+2jBv5LWprSR9uGqrn8rSaEdj6lTi/xAVBzyz9FUjYM25tLvxLrZD Larw== MIME-Version: 1.0 Received: by 10.52.67.133 with SMTP id n5mr1330987vdt.24.1354810644269; Thu, 06 Dec 2012 08:17:24 -0800 (PST) Received: by 10.58.117.234 with HTTP; Thu, 6 Dec 2012 08:17:24 -0800 (PST) In-Reply-To: References: <3D0B9D01-444B-49CF-B5D5-29F80E91A5A6@nic.cz> <20121206.111319.487627637617721147.mbj@tail-f.com> <50C07E2F.3060806@mg-soft.com> <20121206.122319.2144453488107033976.mbj@tail-f.com> <50C0AEF2.4030102@mg-soft.com> Date: Thu, 6 Dec 2012 08:17:24 -0800 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=20cf307f397c308bbc04d0316f61 X-Gm-Message-State: ALoCoQknGfgdl6DFdlwpE5OSNsZXkHzoCSZEv5NzeIB1g6nlH3jZzxuAPPfKzgF4c9lzejlabtRj Cc: netmod@ietf.org Subject: Re: [netmod] is identity derivation reflexive? X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 06 Dec 2012 16:17:26 -0000 --20cf307f397c308bbc04d0316f61 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Dec 6, 2012 at 8:05 AM, Ladislav Lhotka wrote: > > On Dec 6, 2012, at 3:42 PM, Jernej Tuljak > wrote: > > > Dne 6.12.2012 12:32, pi=C5=A1e Ladislav Lhotka: > >> On Dec 6, 2012, at 12:23 PM, Martin Bjorklund wrote: > >> > >>> Jernej Tuljak wrote: > >>>> Dne 6.12.2012 11:13, pi=C5=A1e Martin Bjorklund: > >>>>> Ladislav Lhotka wrote: > >>>>>> Hi, > >>>>>> > >>>>>> Jernej sent me a bug report for RFC 6110 which surprised me: So > far, I > >>>>>> have assumed that identity derivation is a reflexive relation, so > >>>>>> that, using for example the "my-crypto" module in RFC 6020, > >>>>>> Sec. 9.10.5, "crypto:crypto-alg" is a valid value of the "crypto" > >>>>>> leaf. > >>>>>> > >>>>>> Is it correct? > >>>>> No. Section 9.10.2 says: > >>>>> > >>>>> Valid values for an identityref are any identities derived from t= he > >>>>> identityref's base identity. > >>>> Is it transitive? Can one assume that Z is derived from X, if Y is > >>>> derived from X and Z is derived from Y? > >>> Yes (it seems this could be made more clear in the text). > >>> > >>>> Can an identity which is used > >>>> as an argument to another identities' base-stmt ever appear as a val= ue > >>>> of a data node at all? > >>> Sure: > >>> > >>> identity a; > >>> > >>> identity b { > >>> base a; > >>> } > >>> > >>> identity c { > >>> base b; > >>> } > >>> > >>> leaf foo { > >>> type identityref { > >>> base a; > >>> } > >>> default b; // valid > >>> } > >>> > >> OK, so what are the permitted values of the following type in this cas= e? > >> > >> type identityref { > >> base b; > >> } > > > > "c" only I guess. Since that is the only identity derived from "b" whic= h > is your identityref's base. For Martin's example both "b" and "c" are val= id > (due to transitivity). A bit strange that such values are allowed only > indirectly. Changing the module this way: > > > > identity x; > > > > identity a {base x;} > > identity b {base a;} > > identity c {base b;} > > > > leaf foo { > > type identityref { > > base x; > > } > > default b; > > } > > > > would allow "a" too. > > > > I agree that all of this needs clarifications in the RFC. I tested it > during inter-op and I remember that at least one server allowed the > referenced base identity to be a valid value for an identityref leaf. > > I checked the corresponding sections in RFC 6020 and found no text from > which one could conclude that identity derivation is transitive. Section > 9.10.2 only says: > > "Valid values for an identityref are any identities derived from the > identityref's base identity." > you are right -- I checked my code and it would allow 'chips' (the base) as a value, but not 'snacks'. But YANG has no way to say that the base identity is not intended to be a valid value. > > In my opinion, the identity derivation should in fact be a partial > ordering, i.e. reflexive, transitive and antisymmetric. Antisymmetricity = is > stated in 6020 (no circular derivations) but the other two properties are > not mentioned. > > Lada > > Andy > > > > Jernej > > > >> Lada > >> > >>> /martin > >> -- > >> 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 > --20cf307f397c308bbc04d0316f61 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Thu, Dec 6, 2012 at 8:05 AM, Ladislav= Lhotka <lhotka@nic.cz> wrote:

On Dec 6, 2012, at 3:42 PM, Jernej Tuljak <jernej.tuljak@mg-soft.si> wrote:

> Dne 6.12.2012 12:32, pi=C5=A1e Ladislav Lhotka:
>> On Dec 6, 2012, at 12:23 PM, Martin Bjorklund <mbj@tail-f.com> wrote:
>>
>>> Jernej Tuljak <= jernej.tuljak@mg-soft.si> wrote:
>>>> Dne 6.12.2012 11:13, pi=C5=A1e Martin Bjorklund:
>>>>> Ladislav Lhotka <l= hotka@nic.cz> wrote:
>>>>>> Hi,
>>>>>>
>>>>>> Jernej sent me a bug report for RFC 6110 which sur= prised me: So far, I
>>>>>> have assumed that identity derivation is a reflexi= ve relation, so
>>>>>> that, using for example the "my-crypto" = module in RFC 6020,
>>>>>> Sec. 9.10.5, "crypto:crypto-alg" is a va= lid value of the "crypto"
>>>>>> leaf.
>>>>>>
>>>>>> Is it correct?
>>>>> No. =C2=A0Section 9.10.2 says:
>>>>>
>>>>> =C2=A0 Valid values for an identityref are any identit= ies derived from the
>>>>> =C2=A0 identityref's base identity.
>>>> Is it transitive? Can one assume that Z is derived from X,= if Y is
>>>> derived from X and Z is derived from Y?
>>> Yes (it seems this could be made more clear in the text).
>>>
>>>> Can an identity which is used
>>>> as an argument to another identities' base-stmt ever a= ppear as a value
>>>> of a data node at all?
>>> Sure:
>>>
>>> identity a;
>>>
>>> identity b {
>>> =C2=A0 base a;
>>> }
>>>
>>> identity c {
>>> =C2=A0 base b;
>>> }
>>>
>>> leaf foo {
>>> =C2=A0 type identityref {
>>> =C2=A0 =C2=A0 base a;
>>> =C2=A0 }
>>> =C2=A0 default b; =C2=A0// valid
>>> }
>>>
>> OK, so what are the permitted values of the following type in this= case?
>>
>> type identityref {
>> =C2=A0base b;
>> }
>
> "c" only I guess. Since that is the only identity derived fr= om "b" which is your identityref's base. For Martin's exa= mple both "b" and "c" are valid (due to transitivity). = A bit strange that such values are allowed only indirectly. Changing the mo= dule this way:
>
> identity x;
>
> identity a {base x;}
> identity b {base a;}
> identity c {base b;}
>
> leaf foo {
> =C2=A0type identityref {
> =C2=A0 =C2=A0base x;
> =C2=A0}
> =C2=A0default b;
> }
>
> would allow "a" too.
>
> I agree that all of this needs clarifications in the RFC. I tested it = during inter-op and I remember that at least one server allowed the referen= ced base identity to be a valid value for an identityref leaf.

I checked the corresponding sections in RFC 6020 and found no text from whi= ch one could conclude that identity derivation is transitive. Section 9.10.= 2 only says:

"Valid values for an identityref are any identities derived from the i= dentityref's base identity."

<= br>
you are right -- I checked my code and it would allow 'ch= ips' (the base)
as a value, but not 'snacks'. =C2=A0But YANG has no way to say= that the base identity
is not intended to be a valid value.

=C2=A0

In my opinion, the identity derivation should in fact be a partial ordering= , i.e. reflexive, transitive and antisymmetric. Antisymmetricity is stated = in 6020 (no circular derivations) but the other two properties are not ment= ioned.

Lada


Andy
=C2=A0
>
> Jernej
>
>> Lada
>>
>>> /martin
>> --
>> 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

--20cf307f397c308bbc04d0316f61-- From lhotka@nic.cz Thu Dec 6 08:17:31 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3815C21F8796 for ; Thu, 6 Dec 2012 08:17:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.851 X-Spam-Level: X-Spam-Status: No, score=-1.851 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ihm-ehaOb5t4 for ; Thu, 6 Dec 2012 08:17:30 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 913EF21F873C for ; Thu, 6 Dec 2012 08:17:30 -0800 (PST) Received: from [192.168.43.183] (89-24-15-128.i4g.tmcz.cz [89.24.15.128]) by mail.nic.cz (Postfix) with ESMTPSA id 758B513FDF5; Thu, 6 Dec 2012 17:17:29 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1354810649; bh=s3l2e51zflDtQu2L/a3KlpWHCNSN3TrXnrHr15Jyklc=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=jxgxIJ7S5QrScyLSttwL2SYCX5MSF9zg3QQtFzHkRmJB2CrLBrANNigXxDkWwUJHx 5AgnvYBArTV1e9IXKtvzusrVGRh1gJwBsd4ywQngwiVzWl1V1pQiBVjGH+mrxLH0jg D802AkEXUFT5jj9iwyBZC4DiQcAhb+kpZzYvJY70= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ladislav Lhotka In-Reply-To: Date: Thu, 6 Dec 2012 17:17:27 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <59C1CCA6-4A17-4E2D-B871-75781FEB09FF@nic.cz> References: <3D0B9D01-444B-49CF-B5D5-29F80E91A5A6@nic.cz> <20121206.111319.487627637617721147.mbj@tail-f.com> <50C07E2F.3060806@mg-soft.com> <20121206.122319.2144453488107033976.mbj@tail-f.com> <50C0AEF2.4030102@mg-soft.com> To: Andy Bierman X-Mailer: Apple Mail (2.1499) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] is identity derivation reflexive? X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 06 Dec 2012 16:17:31 -0000 On Dec 6, 2012, at 4:48 PM, Andy Bierman wrote: >=20 > The identityref does not distinguish between abstract and concrete = identities. 6020 makes no distinction between abstract and concrete identities. I can have an identity like identity beer; and I hope everybody agrees it is perfectly concrete. However, the lack of reflexivity means that I cannot refer to such = identities created "from scratch" via identityrefs. Lada >=20 >=20 > snacks > / \ > chips candy > / \ | > corn potato chocolate >=20 > The YANG designer picks the base for an identityref leaf > and the intent is that only down-stream identities can be used as = values. >=20 > A base(chips) leaf can have corn or potato as values. >=20 > leaf chip-type { > type identityref { base chips; } > } >=20 > But I think the RFC says that chips and snacks would also be valid. > Operationally, this is not correct since these values provide no = semantics > to the 'chip-type' leaf. >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From lhotka@nic.cz Thu Dec 6 08:35:32 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75A2A21F867A for ; Thu, 6 Dec 2012 08:35:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.875 X-Spam-Level: X-Spam-Status: No, score=-1.875 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s+scQ9oCyIiB for ; Thu, 6 Dec 2012 08:35:31 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 5B84F21F8674 for ; Thu, 6 Dec 2012 08:35:31 -0800 (PST) Received: from [192.168.43.183] (89-24-22-96.i4g.tmcz.cz [89.24.22.96]) by mail.nic.cz (Postfix) with ESMTPSA id D0DAE13FDF5; Thu, 6 Dec 2012 17:35:29 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1354811730; bh=loaStR4lNeqFC6GFLYwKO/bf2YV1xBf+bbX/Hxv5fso=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=aViLhTIrL+C75SFFy+HAMAL3f0fVR1VpQZe4d6/ZfEDb5P4NK5H92m/4az2/XRz2f G5dvTzSfdZ4FK8PbjzDKdNVFQWdVT9yvmdtGhOI8DpMG3Rach8NanFCuJdv3iM1m5S Xd+d1XR1SZFVKSAnVubP9wqJn9mVuEHqQmEoa3fw= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ladislav Lhotka In-Reply-To: Date: Thu, 6 Dec 2012 17:35:26 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <3D0B9D01-444B-49CF-B5D5-29F80E91A5A6@nic.cz> <20121206.111319.487627637617721147.mbj@tail-f.com> <50C07E2F.3060806@mg-soft.com> <20121206.122319.2144453488107033976.mbj@tail-f.com> <50C0AEF2.4030102@mg-soft.com> To: Andy Bierman X-Mailer: Apple Mail (2.1499) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] is identity derivation reflexive? X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 06 Dec 2012 16:35:32 -0000 On Dec 6, 2012, at 5:17 PM, Andy Bierman wrote: >=20 >=20 > On Thu, Dec 6, 2012 at 8:05 AM, Ladislav Lhotka wrote: >=20 > On Dec 6, 2012, at 3:42 PM, Jernej Tuljak = wrote: >=20 > > Dne 6.12.2012 12:32, pi=9Ae Ladislav Lhotka: > >> On Dec 6, 2012, at 12:23 PM, Martin Bjorklund = wrote: > >> > >>> Jernej Tuljak wrote: > >>>> Dne 6.12.2012 11:13, pi=9Ae Martin Bjorklund: > >>>>> Ladislav Lhotka wrote: > >>>>>> Hi, > >>>>>> > >>>>>> Jernej sent me a bug report for RFC 6110 which surprised me: So = far, I > >>>>>> have assumed that identity derivation is a reflexive relation, = so > >>>>>> that, using for example the "my-crypto" module in RFC 6020, > >>>>>> Sec. 9.10.5, "crypto:crypto-alg" is a valid value of the = "crypto" > >>>>>> leaf. > >>>>>> > >>>>>> Is it correct? > >>>>> No. Section 9.10.2 says: > >>>>> > >>>>> Valid values for an identityref are any identities derived = from the > >>>>> identityref's base identity. > >>>> Is it transitive? Can one assume that Z is derived from X, if Y = is > >>>> derived from X and Z is derived from Y? > >>> Yes (it seems this could be made more clear in the text). > >>> > >>>> Can an identity which is used > >>>> as an argument to another identities' base-stmt ever appear as a = value > >>>> of a data node at all? > >>> Sure: > >>> > >>> identity a; > >>> > >>> identity b { > >>> base a; > >>> } > >>> > >>> identity c { > >>> base b; > >>> } > >>> > >>> leaf foo { > >>> type identityref { > >>> base a; > >>> } > >>> default b; // valid > >>> } > >>> > >> OK, so what are the permitted values of the following type in this = case? > >> > >> type identityref { > >> base b; > >> } > > > > "c" only I guess. Since that is the only identity derived from "b" = which is your identityref's base. For Martin's example both "b" and "c" = are valid (due to transitivity). A bit strange that such values are = allowed only indirectly. Changing the module this way: > > > > identity x; > > > > identity a {base x;} > > identity b {base a;} > > identity c {base b;} > > > > leaf foo { > > type identityref { > > base x; > > } > > default b; > > } > > > > would allow "a" too. > > > > I agree that all of this needs clarifications in the RFC. I tested = it during inter-op and I remember that at least one server allowed the = referenced base identity to be a valid value for an identityref leaf. >=20 > I checked the corresponding sections in RFC 6020 and found no text = from which one could conclude that identity derivation is transitive. = Section 9.10.2 only says: >=20 > "Valid values for an identityref are any identities derived from the = identityref's base identity." >=20 >=20 > you are right -- I checked my code and it would allow 'chips' (the = base) > as a value, but not 'snacks'. But YANG has no way to say that the = base identity > is not intended to be a valid value. Well, in your example the identityref has base "chips", so it cannot = reach beyond this base to "snack". The more interesting question is = this: leaf snack-type { type identityref { base snacks; } } Are the allowed values: 1. chips, candy (current 6020 wording) 2. snacks, chips, candy (reflexivity) 3. chips, candy, corn, potato, chocolate (transitivity) 4. snacks, chips, candy, corn, potato, chocolate (reflexivity & = transitivity) Lada >=20 > =20 >=20 > In my opinion, the identity derivation should in fact be a partial = ordering, i.e. reflexive, transitive and antisymmetric. Antisymmetricity = is stated in 6020 (no circular derivations) but the other two properties = are not mentioned. >=20 > Lada >=20 >=20 > Andy > =20 > > > > Jernej > > > >> Lada > >> > >>> /martin > >> -- > >> Ladislav Lhotka, CZ.NIC Labs > >> PGP Key ID: E74E8C0C > >> > >> > >> > >> > >> _______________________________________________ > >> netmod mailing list > >> netmod@ietf.org > >> https://www.ietf.org/mailman/listinfo/netmod > > >=20 > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C >=20 >=20 >=20 >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From andy@yumaworks.com Thu Dec 6 08:39:44 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71D7D21F86AD for ; Thu, 6 Dec 2012 08:39:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.626 X-Spam-Level: X-Spam-Status: No, score=-2.626 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6KFIoFP7W0lF for ; Thu, 6 Dec 2012 08:39:43 -0800 (PST) Received: from mail-vb0-f54.google.com (mail-vb0-f54.google.com [209.85.212.54]) by ietfa.amsl.com (Postfix) with ESMTP id A041F21F8676 for ; Thu, 6 Dec 2012 08:39:43 -0800 (PST) Received: by mail-vb0-f54.google.com with SMTP id l1so9515731vba.27 for ; Thu, 06 Dec 2012 08:39:43 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=On1IpKtV/vxToWDpIHLBkmf73UmJioMhKKub+svyit8=; b=PkOrksUAfvwBnYSQDHhIUYs7Bm51M1M7pyy9iXK03oojx+ON5MSOHukLppkfqsK7fw C9rVMOABA8fdvkLsbhXERgMfkFp3a/q/BRozp5ktoN6oTyuWcIHvNW7zLeg7LrTX86nT 6ms3WF+vRtrUY1CQwNcoSb+v0V1WM31bxvh0IDgrOsnrVx7OoaBQeVmeZdhAqynWlpuh z1DbZ5zB9DqcvQjqrjgahArPm5FNkBj1qfltDgQgUoY/2b8SOaH9YTNA8kUkpm/9wbtp 37gpbHxcnjScRiBouzs2rkIXwNl+fVvpEqtdN6NGfnzpJR9j0y1LC0PfU7jENWgCv/2f 8/pQ== MIME-Version: 1.0 Received: by 10.52.66.34 with SMTP id c2mr1367438vdt.62.1354811983000; Thu, 06 Dec 2012 08:39:43 -0800 (PST) Received: by 10.58.117.234 with HTTP; Thu, 6 Dec 2012 08:39:42 -0800 (PST) In-Reply-To: <59C1CCA6-4A17-4E2D-B871-75781FEB09FF@nic.cz> References: <3D0B9D01-444B-49CF-B5D5-29F80E91A5A6@nic.cz> <20121206.111319.487627637617721147.mbj@tail-f.com> <50C07E2F.3060806@mg-soft.com> <20121206.122319.2144453488107033976.mbj@tail-f.com> <50C0AEF2.4030102@mg-soft.com> <59C1CCA6-4A17-4E2D-B871-75781FEB09FF@nic.cz> Date: Thu, 6 Dec 2012 08:39:42 -0800 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=20cf307f35c2fbf47704d031bef1 X-Gm-Message-State: ALoCoQl88pfdb6aKR8I7pYL2+f0RhAlR11AWhUg2lPuDma8rWjyUcmkRBWNRY8Fl0ZOu8s96mM7d Cc: netmod@ietf.org Subject: Re: [netmod] is identity derivation reflexive? X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 06 Dec 2012 16:39:44 -0000 --20cf307f35c2fbf47704d031bef1 Content-Type: text/plain; charset=UTF-8 On Thu, Dec 6, 2012 at 8:17 AM, Ladislav Lhotka wrote: > > On Dec 6, 2012, at 4:48 PM, Andy Bierman wrote: > > > > The identityref does not distinguish between abstract and concrete > identities. > > 6020 makes no distinction between abstract and concrete identities. I can have an identity like > > identity beer; > > and I hope everybody agrees it is perfectly concrete. > > And the same applies to each new base that is derived from this one, etc. These non-root base identities are more interesting. I checked RFC 6020, sec. 10, and there is no mention of adding a base to an identity statement, which means it is not allowed. IMO this should be legal (create rev B after A is published): Rev A: identity beer; leaf beer-type { type identityref { base beer; } } Rev B: identity beverage; identity beer { base beverage; } identity wine { base beverage; } leaf beer-type { type identityref { base beer; } } leaf beverage-type { type identityref {base beverage; } } This implies that we cannot really define abstract vs. concrete, because it can change depending on the data model. It doesn't seem likely that the base can ever provide any semantics (beer-type = beer, beverage-type = beverage). However, the lack of reflexivity means that I cannot refer to such > identities created "from scratch" via identityrefs. > > Not sure what you mean since identityrefs can only refer to identity statements, not other identityref leafs. Can you give a YANG example? > Lada > > Andy > > > > > > snacks > > / \ > > chips candy > > / \ | > > corn potato chocolate > > > > The YANG designer picks the base for an identityref leaf > > and the intent is that only down-stream identities can be used as values. > > > > A base(chips) leaf can have corn or potato as values. > > > > leaf chip-type { > > type identityref { base chips; } > > } > > > > But I think the RFC says that chips and snacks would also be valid. > > Operationally, this is not correct since these values provide no > semantics > > to the 'chip-type' leaf. > > > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > --20cf307f35c2fbf47704d031bef1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Thu, Dec 6, 2012 at 8:17 AM, Ladislav= Lhotka <lhotka@nic.cz> wrote:

On Dec 6, 2012, at 4:48 PM, Andy Bierman <andy@yumaworks.com> wrote:
>
> The identityref does not distinguish between abstract and concrete ide= ntities.

6020 makes no distinction between abstract and concrete identities.=C2=A0
=C2=A0
I can have an identity like

identity beer;

and I hope everybody agrees it is perfectly concrete.


And the same applies to each new base = that is derived from this one, etc.
These non-root base identitie= s are more interesting.

I checked RFC 6020, sec. 1= 0, and there is no mention of adding a base
to an identity statement, which means it is not allowed.
IMO this should be legal (create rev B after A is published):

Rev A:

=C2=A0 =C2=A0 ident= ity beer;

=C2=A0 =C2=A0 leaf beer-type { type identityref { base = beer; } }

Rev B:

=C2=A0 = =C2=A0 identity beverage;

=C2=A0=C2=A0 =C2=A0= identity beer { base beverage; }

=C2=A0 =C2=A0 identity wine { base beverage; }

=C2=A0 =C2=A0 leaf beer-type { type identityref { base bee= r; } }

=C2=A0=C2=A0 =C2=A0leaf beverage-type= { type identityref {base beverage; } }


This implies that we cannot really defin= e abstract vs. concrete, because it can
change depending on the d= ata model. =C2=A0It doesn't seem likely that the base
can eve= r provide any semantics (beer-type =3D beer, beverage-type =3D beverage).

However, the lack of reflexivity means that I cannot refer to such identiti= es created "from scratch" via identityrefs.


Not sure what you mean since identityr= efs can only refer to identity statements,
not other identityref = leafs. =C2=A0Can you give a YANG example?
=C2=A0
Lada



Andy
=C2=A0
>
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0snacks
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/ =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0\
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0chips =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0candy
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/ =C2=A0 =C2=A0 \ =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0corn =C2=A0 potato =C2=A0 chocolate
>
> The YANG designer picks the base for an identityref leaf
> and the intent is that only down-stream identities can be used as valu= es.
>
> A base(chips) leaf can have corn or potato as values.
>
> =C2=A0 =C2=A0leaf chip-type {
> =C2=A0 =C2=A0 =C2=A0type identityref { base chips; }
> =C2=A0 =C2=A0}
>
> But I think the RFC says that chips and snacks would also be valid. > Operationally, this is not correct since these values provide no seman= tics
> to the 'chip-type' leaf.
>

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





--20cf307f35c2fbf47704d031bef1-- From andy@yumaworks.com Thu Dec 6 08:42:12 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BAD521F86BD for ; Thu, 6 Dec 2012 08:42:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.89 X-Spam-Level: X-Spam-Status: No, score=-2.89 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eL60WjNtZBcb for ; Thu, 6 Dec 2012 08:42:12 -0800 (PST) Received: from mail-ye0-f172.google.com (mail-ye0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0A10C21F86B9 for ; Thu, 6 Dec 2012 08:42:11 -0800 (PST) Received: by mail-ye0-f172.google.com with SMTP id r14so1144825yen.31 for ; Thu, 06 Dec 2012 08:42:11 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=7kwruCsnaiZRQJOdNgAo5ZlN2fFCxVVY7Sap4h+chXk=; b=LclC7E3BGt08yUEUhj4VHTxyBO9LVo4P7ufycXMtaqKJfr1RCSevN9kx4lj4xiH7yX /cGAE4SMw7yDj9qKbo7eP6Jn92XifatMugCfQd1ZrZL7d4mN1wbn92XLiRg52A3evS1s t4IE9p3SF+48e6JKXuO1El29js/yg5pfeNC2oO55Gt1RojIEBhctbZ9jYfng6rCRlnqH G61jJWegjRv4Yi56CWXhDS+iwdi8mVze/S3J0fa0RzFf2MeSd/apR+SpVmXSrKvdSk8N mUMUP+i4DO5phdkeIRnlmg1JyCzta+AeF641suaoeM99iHTL5zcRnByyZ7zjETRJM62c Dlog== MIME-Version: 1.0 Received: by 10.59.6.70 with SMTP id cs6mr1579261ved.60.1354812131304; Thu, 06 Dec 2012 08:42:11 -0800 (PST) Received: by 10.58.117.234 with HTTP; Thu, 6 Dec 2012 08:42:11 -0800 (PST) In-Reply-To: References: <3D0B9D01-444B-49CF-B5D5-29F80E91A5A6@nic.cz> <20121206.111319.487627637617721147.mbj@tail-f.com> <50C07E2F.3060806@mg-soft.com> <20121206.122319.2144453488107033976.mbj@tail-f.com> <50C0AEF2.4030102@mg-soft.com> Date: Thu, 6 Dec 2012 08:42:11 -0800 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=047d7bf0effed2e38404d031c7f7 X-Gm-Message-State: ALoCoQmJU9BZUjhSg9R+moHSZPHmyfJJmnqXT+8Y+bNkDVU8aSvmppP2tOAdrpApIKc+Lp3/GgKj Cc: netmod@ietf.org Subject: Re: [netmod] is identity derivation reflexive? X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 06 Dec 2012 16:42:12 -0000 --047d7bf0effed2e38404d031c7f7 Content-Type: text/plain; charset=UTF-8 .... > > Well, in your example the identityref has base "chips", so it cannot reach > beyond this base to "snack". The more interesting question is this: > > leaf snack-type { > type identityref { base snacks; } > } > > Are the allowed values: > > 1. chips, candy (current 6020 wording) > > 2. snacks, chips, candy (reflexivity) > > 3. chips, candy, corn, potato, chocolate (transitivity) > > 4. snacks, chips, candy, corn, potato, chocolate (reflexivity & > transitivity) > > (4) > Lada > Andy --047d7bf0effed2e38404d031c7f7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable ....

Well, in your example the identityref has base "chips", so it can= not reach beyond this base to "snack". The more interesting quest= ion is this:

=C2=A0 =C2=A0leaf snack-type {
=C2=A0 =C2=A0 =C2=A0type identityref { base snacks; }
=C2=A0 =C2=A0}

Are the allowed values:

1. chips, candy (current 6020 wording)

2. snacks, chips, candy (reflexivity)

3. chips, candy, corn, potato, chocolate (transitivity)

4. snacks, chips, candy, corn, potato, chocolate (reflexivity & transit= ivity)


(4)
=C2=A0
Lada

Andy
=C2=A0
--047d7bf0effed2e38404d031c7f7-- From lhotka@nic.cz Thu Dec 6 08:43:16 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 704B021F8703 for ; Thu, 6 Dec 2012 08:43:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.893 X-Spam-Level: X-Spam-Status: No, score=-1.893 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g1E9rv-TBgJ7 for ; Thu, 6 Dec 2012 08:43:16 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id DFEDE21F86EA for ; Thu, 6 Dec 2012 08:43:15 -0800 (PST) Received: from [192.168.43.183] (89-24-22-96.i4g.tmcz.cz [89.24.22.96]) by mail.nic.cz (Postfix) with ESMTPSA id 4FA6013FDF5; Thu, 6 Dec 2012 17:43:12 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1354812194; bh=vyXQaNlQqtFKatOUQ3hp+OnRykJibTOrbUHqFVSb1RE=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=Q4z1gpoNSoRnauJnX3/OcR2T1qbsrKIsKv4jykG3goWaQ4UfiuSXc9WZdLZaYOPMW 91eEV1l6L/vUHMqz5YI07fyPUlKBDIK0Ll+xLovCDHcAp8lKhPPgOhcDLxZId/VmTC nGn0wGzuilJEETvoFOVaCFHhyXoZdA6WgfzQkJik= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ladislav Lhotka In-Reply-To: Date: Thu, 6 Dec 2012 17:43:08 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <5061DD46-8352-44B7-A78E-2F76290D9A6F@nic.cz> References: <3D0B9D01-444B-49CF-B5D5-29F80E91A5A6@nic.cz> <20121206.111319.487627637617721147.mbj@tail-f.com> <50C07E2F.3060806@mg-soft.com> <20121206.122319.2144453488107033976.mbj@tail-f.com> <50C0AEF2.4030102@mg-soft.com> <59C1CCA6-4A17-4E2D-B871-75781FEB09FF@nic.cz> To: Andy Bierman X-Mailer: Apple Mail (2.1499) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] is identity derivation reflexive? X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 06 Dec 2012 16:43:16 -0000 On Dec 6, 2012, at 5:39 PM, Andy Bierman wrote: > Not sure what you mean since identityrefs can only refer to identity = statements, > not other identityref leafs. Can you give a YANG example? >=20 identity beer; leaf pint { type identityref { base beer; } } Lada -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From lhotka@nic.cz Thu Dec 6 08:44:52 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3275221F873C for ; Thu, 6 Dec 2012 08:44:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.906 X-Spam-Level: X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bIBh-S9LNtdW for ; Thu, 6 Dec 2012 08:44:51 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 60CD321F86EA for ; Thu, 6 Dec 2012 08:44:37 -0800 (PST) Received: from [192.168.43.183] (89-24-22-96.i4g.tmcz.cz [89.24.22.96]) by mail.nic.cz (Postfix) with ESMTPSA id E253D13FDF5; Thu, 6 Dec 2012 17:44:13 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1354812276; bh=/CKGSfqeeanJQiEcbwPG1BCx6bAV+888r6uUzic7MkQ=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=isATRnScp1RNLgsiRKmUqTbLRw/pxSFz3RwZDqfNRh0w4aKnctkVAPfF9TA5WLWgz TD0bgUfjOj1Flz4wktuk9NCuLM7yYTFNx+RB+HG3hyDcu/VdvCXfcuswLRGpwyHOIo QDbX+ODX+k6xnP+hj7frGeaCtrx8qwhIsX/3YJkw= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ladislav Lhotka In-Reply-To: Date: Thu, 6 Dec 2012 17:44:11 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <56F5C7A8-FDC1-4FCA-963F-8D1343DCACAF@nic.cz> References: <3D0B9D01-444B-49CF-B5D5-29F80E91A5A6@nic.cz> <20121206.111319.487627637617721147.mbj@tail-f.com> <50C07E2F.3060806@mg-soft.com> <20121206.122319.2144453488107033976.mbj@tail-f.com> <50C0AEF2.4030102@mg-soft.com> To: Andy Bierman X-Mailer: Apple Mail (2.1499) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] is identity derivation reflexive? X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 06 Dec 2012 16:44:52 -0000 On Dec 6, 2012, at 5:42 PM, Andy Bierman wrote: > .... >=20 > Well, in your example the identityref has base "chips", so it cannot = reach beyond this base to "snack". The more interesting question is = this: >=20 > leaf snack-type { > type identityref { base snacks; } > } >=20 > Are the allowed values: >=20 > 1. chips, candy (current 6020 wording) >=20 > 2. snacks, chips, candy (reflexivity) >=20 > 3. chips, candy, corn, potato, chocolate (transitivity) >=20 > 4. snacks, chips, candy, corn, potato, chocolate (reflexivity & = transitivity) >=20 >=20 > (4) Right, that was my original idea, too, but Martin said no. Lada > =20 > Lada >=20 > Andy > =20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From mbj@tail-f.com Thu Dec 6 12:30:10 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43BAF21F8A57 for ; Thu, 6 Dec 2012 12:30:10 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bLyhx4vw1Mbh for ; Thu, 6 Dec 2012 12:30:09 -0800 (PST) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 57EC521F89CB for ; Thu, 6 Dec 2012 12:30:09 -0800 (PST) Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id E27C312008F7; Thu, 6 Dec 2012 21:30:06 +0100 (CET) Date: Thu, 06 Dec 2012 21:30:06 +0100 (CET) Message-Id: <20121206.213006.481309519.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: <56F5C7A8-FDC1-4FCA-963F-8D1343DCACAF@nic.cz> References: <56F5C7A8-FDC1-4FCA-963F-8D1343DCACAF@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] is identity derivation reflexive? X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 06 Dec 2012 20:30:10 -0000 Ladislav Lhotka wrote: > > On Dec 6, 2012, at 5:42 PM, Andy Bierman wrote: > > > .... > > > > Well, in your example the identityref has base "chips", so it cannot reach > > beyond this base to "snack". The more interesting question is this: > > > > leaf snack-type { > > type identityref { base snacks; } > > } > > > > Are the allowed values: > > > > 1. chips, candy (current 6020 wording) > > > > 2. snacks, chips, candy (reflexivity) > > > > 3. chips, candy, corn, potato, chocolate (transitivity) > > > > 4. snacks, chips, candy, corn, potato, chocolate (reflexivity & transitivity) > > > > > > (4) > > Right, that was my original idea, too, but Martin said no. Right, it should be (3). In order to support (4) we would also need a 'abstract' keyword, to indicate that the base class cannot be used as a proper value. This just adds complexity for very little gain. With the current design, you have to create identities for all values you want to support, not a big deal. Is there any real use case that cannot be handled today? /martin From andy@yumaworks.com Thu Dec 6 13:01:10 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51CC321F8587 for ; Thu, 6 Dec 2012 13:01:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.901 X-Spam-Level: X-Spam-Status: No, score=-2.901 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id snN5xtWxaxqf for ; Thu, 6 Dec 2012 13:01:09 -0800 (PST) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 543AC21F87D8 for ; Thu, 6 Dec 2012 13:01:09 -0800 (PST) Received: by mail-vc0-f172.google.com with SMTP id fw7so7089717vcb.31 for ; Thu, 06 Dec 2012 13:01:08 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=Lf8YpMoUCnfiw0a6dEGxODYXyICvjqM/trOCsMV1T5s=; b=b1zvLy04ptH7Cdz4nO+6q0kP1proy02exUsCKkH4IUu3M9Xc4UHalnAKuT2JW2rqtz NYCxXRe2uWonDAMp5BifvHa/xsaVsQNRNiw/e3DutolTH+0n7kVLieFML6lGNOdr/S9T W2GI0I91Lx5FI6rDjMbFDsnNH4TfAtJN8F3uuF7rc9jtxdclBjWbK2O9GmmnWUV9IVKA Ep9j2kWlW/Q6chkfqDAjNFUmXIW9t2Sqt7uBrxWL2Q5zbXQ2P1GrzR+WuUWaD0I4pPsG WV9+4AKKEZszX7B0duvHatFtAEKdeSK6go7q0PCCOAn9/VgaqB2aCD1mXtADqfi63YFf fyoA== MIME-Version: 1.0 Received: by 10.220.239.14 with SMTP id ku14mr2290207vcb.57.1354827668567; Thu, 06 Dec 2012 13:01:08 -0800 (PST) Received: by 10.58.117.234 with HTTP; Thu, 6 Dec 2012 13:01:08 -0800 (PST) In-Reply-To: <20121206.213006.481309519.mbj@tail-f.com> References: <56F5C7A8-FDC1-4FCA-963F-8D1343DCACAF@nic.cz> <20121206.213006.481309519.mbj@tail-f.com> Date: Thu, 6 Dec 2012 13:01:08 -0800 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: multipart/alternative; boundary=14dae9cfcc30eab59204d035658c X-Gm-Message-State: ALoCoQmP1kelDj5dbQF6RgtDwP+U/d/FYE44WPgsyeZGdPy/YjsJU6pqGeBwVCnoyGC9Ze/0W33C Cc: netmod@ietf.org Subject: Re: [netmod] is identity derivation reflexive? X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 06 Dec 2012 21:01:10 -0000 --14dae9cfcc30eab59204d035658c Content-Type: text/plain; charset=UTF-8 On Thu, Dec 6, 2012 at 12:30 PM, Martin Bjorklund wrote: > Ladislav Lhotka wrote: > > > > On Dec 6, 2012, at 5:42 PM, Andy Bierman wrote: > > > > > .... > > > > > > Well, in your example the identityref has base "chips", so it cannot > reach > > > beyond this base to "snack". The more interesting question is this: > > > > > > leaf snack-type { > > > type identityref { base snacks; } > > > } > > > > > > Are the allowed values: > > > > > > 1. chips, candy (current 6020 wording) > > > > > > 2. snacks, chips, candy (reflexivity) > > > > > > 3. chips, candy, corn, potato, chocolate (transitivity) > > > > > > 4. snacks, chips, candy, corn, potato, chocolate (reflexivity & > transitivity) > > > > > > > > > (4) > > > > Right, that was my original idea, too, but Martin said no. > Right, it should be (3) but the RFC text seems to say that it is (4). In order to support (4) we would also need a 'abstract' keyword, to > indicate that the base class cannot be used as a proper value. This > just adds complexity for very little gain. With the current design, > you have to create identities for all values you want to support, not > a big deal We don't need a new keyword. I can't think of a use-case to use the base itself, as determined by the identityref leaf. snack-type = snacks chip-type = chips candy-type = candy You can't tell from the identity-stmt that a base is also a concrete identity, but you can tell from the leaf's type-stmt. Meaningless assignments like above should produce an invalid-value error. . > > Is there any real use case that cannot be handled today? > > > /martin > > > Andy --14dae9cfcc30eab59204d035658c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Thu, Dec 6, 2012 at 12:30 PM, Martin = Bjorklund <mbj@tail-f.com> wrote:
Ladislav Lhotka <lhotka@nic.cz> = wrote:
>
> On Dec 6, 2012, at 5:42 PM, Andy Bierman <andy@yumaworks.com> wrote:
>
> > ....
> >
> > Well, in your example the identityref has base "chips",= so it cannot reach
> > beyond this base to "snack". The more interesting quest= ion is this:
> >
> > =C2=A0 =C2=A0leaf snack-type {
> > =C2=A0 =C2=A0 =C2=A0type identityref { base snacks; }
> > =C2=A0 =C2=A0}
> >
> > Are the allowed values:
> >
> > 1. chips, candy (current 6020 wording)
> >
> > 2. snacks, chips, candy (reflexivity)
> >
> > 3. chips, candy, corn, potato, chocolate (transitivity)
> >
> > 4. snacks, chips, candy, corn, potato, chocolate (reflexivity &am= p; transitivity)
> >
> >
> > (4)
>
> Right, that was my original idea, too, but Martin said no.
=C2=A0

Right, it should be (3) but the R= FC text seems to say that it is (4).


In order to support (4) we would also need a 'abstract' keyword, to=
indicate that the base class cannot be used as a proper value. =C2=A0This just adds complexity for very little gain. =C2=A0With the current design, you have to create identities for all values you want to support, not
a big deal

We don't need a new keyword.=
I can't think of a use-case to use the base itself, as deter= mined
by the identityref leaf.

=C2=A0 = =C2=A0snack-type =3D snacks
=C2=A0 =C2=A0chip-type =3D chips
=C2=A0 =C2=A0candy-type =3D= candy

You can't tell from the identity-stmt t= hat a base is also a concrete identity,
but you can tell from the= leaf's type-stmt. Meaningless assignments like above
should produce an invalid-value error.

.

Is there any real use case that cannot be handled today?


/martin



Andy

--14dae9cfcc30eab59204d035658c-- From mbj@tail-f.com Thu Dec 6 14:09:23 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37CCA21F8659 for ; Thu, 6 Dec 2012 14:09:23 -0800 (PST) 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=[AWL=-0.000, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gt+o5K4Acsze for ; Thu, 6 Dec 2012 14:09:22 -0800 (PST) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 8FFED21F87C9 for ; Thu, 6 Dec 2012 14:09:22 -0800 (PST) Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 3EC0C12008F7; Thu, 6 Dec 2012 23:09:20 +0100 (CET) Date: Thu, 06 Dec 2012 23:09:19 +0100 (CET) Message-Id: <20121206.230919.415162795.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: <56F5C7A8-FDC1-4FCA-963F-8D1343DCACAF@nic.cz> <20121206.213006.481309519.mbj@tail-f.com> X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] is identity derivation reflexive? X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 06 Dec 2012 22:09:23 -0000 Andy Bierman wrote: > On Thu, Dec 6, 2012 at 12:30 PM, Martin Bjorklund wrote: > > > Ladislav Lhotka wrote: > > > > > > On Dec 6, 2012, at 5:42 PM, Andy Bierman wrote: > > > > > > > .... > > > > > > > > Well, in your example the identityref has base "chips", so it cannot > > reach > > > > beyond this base to "snack". The more interesting question is this: > > > > > > > > leaf snack-type { > > > > type identityref { base snacks; } > > > > } > > > > > > > > Are the allowed values: > > > > > > > > 1. chips, candy (current 6020 wording) > > > > > > > > 2. snacks, chips, candy (reflexivity) > > > > > > > > 3. chips, candy, corn, potato, chocolate (transitivity) > > > > > > > > 4. snacks, chips, candy, corn, potato, chocolate (reflexivity & > > transitivity) > > > > > > > > > > > > (4) > > > > > > Right, that was my original idea, too, but Martin said no. > > > > > Right, it should be (3) but the RFC text seems to say that it is (4). I think it might say (1) as Lada suggests. But the intention was always to say (3). /martin From j.schoenwaelder@jacobs-university.de Thu Dec 6 14:24:10 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1B9421F86FD for ; Thu, 6 Dec 2012 14:24:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.172 X-Spam-Level: X-Spam-Status: No, score=-103.172 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f3Z3gAJgT9AV for ; Thu, 6 Dec 2012 14:24:10 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 0D42421F86FC for ; Thu, 6 Dec 2012 14:24:10 -0800 (PST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id C57C120C0B; Thu, 6 Dec 2012 23:24:08 +0100 (CET) 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 zOF6YMso9PUJ; Thu, 6 Dec 2012 23:24:08 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4A00D20C0A; Thu, 6 Dec 2012 23:24:08 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 29AC52350AFA; Thu, 6 Dec 2012 23:24:15 +0100 (CET) Date: Thu, 6 Dec 2012 23:24:15 +0100 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20121206222415.GA37446@elstar.local> Mail-Followup-To: Martin Bjorklund , andy@yumaworks.com, netmod@ietf.org References: <56F5C7A8-FDC1-4FCA-963F-8D1343DCACAF@nic.cz> <20121206.213006.481309519.mbj@tail-f.com> <20121206.230919.415162795.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20121206.230919.415162795.mbj@tail-f.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] is identity derivation reflexive? 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, 06 Dec 2012 22:24:10 -0000 On Thu, Dec 06, 2012 at 11:09:19PM +0100, Martin Bjorklund wrote: > Andy Bierman wrote: > > On Thu, Dec 6, 2012 at 12:30 PM, Martin Bjorklund wrote: > > > > > Ladislav Lhotka wrote: > > > > > > > > On Dec 6, 2012, at 5:42 PM, Andy Bierman wrote: > > > > > > > > > .... > > > > > > > > > > Well, in your example the identityref has base "chips", so it cannot > > > reach > > > > > beyond this base to "snack". The more interesting question is this: > > > > > > > > > > leaf snack-type { > > > > > type identityref { base snacks; } > > > > > } > > > > > > > > > > Are the allowed values: > > > > > > > > > > 1. chips, candy (current 6020 wording) > > > > > > > > > > 2. snacks, chips, candy (reflexivity) > > > > > > > > > > 3. chips, candy, corn, potato, chocolate (transitivity) > > > > > > > > > > 4. snacks, chips, candy, corn, potato, chocolate (reflexivity & > > > transitivity) > > > > > > > > > > > > > > > (4) > > > > > > > > Right, that was my original idea, too, but Martin said no. > > > > > > > > > Right, it should be (3) but the RFC text seems to say that it is (4). > > I think it might say (1) as Lada suggests. But the intention was > always to say (3). This matches my recollection. In any case, I think this needs to be clarified since the current text apparently leads to different interpretations. Someone wants to open an errata? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From lhotka@nic.cz Fri Dec 7 01:52:14 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C68521F85B2 for ; Fri, 7 Dec 2012 01:52:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2OyRnJ+yvcCc for ; Fri, 7 Dec 2012 01:52:13 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 271EE21F8573 for ; Fri, 7 Dec 2012 01:52:12 -0800 (PST) Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 2D9BE13FD9A; Fri, 7 Dec 2012 10:52:11 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1354873931; bh=8NHHzjnQEtOprzmjT2A0YtcIMnThrDENa90NsNVHluQ=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=t10kf2GQy38YZiGtXD/24QYf2ZIOqK0dSF4PAirLVIJbu9rjVx5SAckLEAD2pF/Oa dBPxHTCyQTjfB+p8VVYnj7e1OJS0JpyrlIKlc5Hkdh5AbxqMuEteUAUYBk1gJTEnDw 72KrZKXLJvfQdsz+nopMSgpM9Mue0AWe/tsjbDX0= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ladislav Lhotka In-Reply-To: Date: Fri, 7 Dec 2012 10:52:10 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <56F5C7A8-FDC1-4FCA-963F-8D1343DCACAF@nic.cz> <20121206.213006.481309519.mbj@tail-f.com> To: Andy Bierman X-Mailer: Apple Mail (2.1499) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] is identity derivation reflexive? X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 07 Dec 2012 09:52:14 -0000 On Dec 6, 2012, at 10:01 PM, Andy Bierman wrote: > --14dae9cfcc30eab59204d035658c > Content-Type: text/plain; charset=3DUTF-8 >=20 > On Thu, Dec 6, 2012 at 12:30 PM, Martin Bjorklund = wrote: >=20 >> Ladislav Lhotka wrote: >>>=20 >>> On Dec 6, 2012, at 5:42 PM, Andy Bierman wrote: >>>=20 >>>> .... >>>>=20 >>>> Well, in your example the identityref has base "chips", so it = cannot >> reach >>>> beyond this base to "snack". The more interesting question is this: >>>>=20 >>>> leaf snack-type { >>>> type identityref { base snacks; } >>>> } >>>>=20 >>>> Are the allowed values: >>>>=20 >>>> 1. chips, candy (current 6020 wording) >>>>=20 >>>> 2. snacks, chips, candy (reflexivity) >>>>=20 >>>> 3. chips, candy, corn, potato, chocolate (transitivity) >>>>=20 >>>> 4. snacks, chips, candy, corn, potato, chocolate (reflexivity & >> transitivity) >>>>=20 >>>>=20 >>>> (4) >>>=20 >>> Right, that was my original idea, too, but Martin said no. >>=20 >=20 >=20 > Right, it should be (3) but the RFC text seems to say that it is (4). >=20 >=20 > In order to support (4) we would also need a 'abstract' keyword, to >> indicate that the base class cannot be used as a proper value. This >> just adds complexity for very little gain. With the current design, >> you have to create identities for all values you want to support, not >> a big deal >=20 >=20 > We don't need a new keyword. > I can't think of a use-case to use the base itself, as determined > by the identityref leaf. >=20 > snack-type =3D snacks > chip-type =3D chips > candy-type =3D candy But one can easily argue that chips and candy are also "abstract" = identities so that only leaf identities are supposed to be assigned to = leafrefs. Lada >=20 > You can't tell from the identity-stmt that a base is also a concrete > identity, > but you can tell from the leaf's type-stmt. Meaningless assignments = like > above > should produce an invalid-value error. >=20 > . >>=20 >> Is there any real use case that cannot be handled today? >>=20 >>=20 >> /martin >>=20 >>=20 >>=20 > Andy >=20 > --14dae9cfcc30eab59204d035658c > Content-Type: text/html; charset=3DUTF-8 > Content-Transfer-Encoding: quoted-printable >=20 >

On Thu, Dec 6, 2012 at 12:30 PM, = Martin =3D > Bjorklund < "_blank">mbj@tail-f.com> wrote:
_quote" style=3D3D"margin:0 0 0 .8ex;border-left:1px #ccc = solid;padding-left:=3D > 1ex"> > Ladislav Lhotka <lhotka@nic.cz> =3D > wrote:
> >
> > On Dec 6, 2012, at 5:42 PM, Andy Bierman < maworks.com">andy@yumaworks.com> wrote:
> >
> > > ....
> > >
> > > Well, in your example the identityref has base = "chips",=3D > so it cannot reach
> > > beyond this base to "snack". The more interesting = quest=3D > ion is this:
> > >
> > > =3DC2=3DA0 =3DC2=3DA0leaf snack-type {
> > > =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0type identityref { base = snacks; }
> > > =3DC2=3DA0 =3DC2=3DA0}
> > >
> > > Are the allowed values:
> > >
> > > 1. chips, candy (current 6020 wording)
> > >
> > > 2. snacks, chips, candy (reflexivity)
> > >
> > > 3. chips, candy, corn, potato, chocolate (transitivity)
> > >
> > > 4. snacks, chips, candy, corn, potato, chocolate = (reflexivity &am=3D > p; transitivity)
> > >
> > >
> > > (4)
> >
> > Right, that was my original idea, too, but Martin said = no.
uote>
=3DC2=3DA0

Right, it should be (3) = but the R=3D > FC text seems to say that it is = (4).


ockquote class=3D3D"gmail_quote" style=3D3D"margin:0 0 0 = .8ex;border-left:1px #=3D > ccc solid;padding-left:1ex"> >=20 > In order to support (4) we would also need a 'abstract' = keyword, to=3D >
> indicate that the base class cannot be used as a proper value. = =3DC2=3DA0This r> > just adds complexity for very little gain. =3DC2=3DA0With the current = design, r> > you have to create identities for all values you want to support, = not
> a big deal

We don't need a new = keyword.=3D >
I can't think of a use-case to use the base itself, as = deter=3D > mined
by the identityref = leaf.

=3DC2=3DA0 =3D > =3DC2=3DA0snack-type =3D3D snacks
>
=3DC2=3DA0 =3DC2=3DA0chip-type =3D3D chips
=3DC2=3DA0 = =3DC2=3DA0candy-type =3D3D=3D > candy

You can't tell from the = identity-stmt t=3D > hat a base is also a concrete identity,
but you can tell = from the=3D > leaf's type-stmt. Meaningless assignments like above
>
should produce an invalid-value = error.

class=3D3D"gmail_quote" style=3D3D"margin:0 0 0 .8ex;border-left:1px = #ccc soli=3D > d;padding-left:1ex">.
>
> Is there any real use case that cannot be handled today?
>
>
> /martin
>
>
>

Andy

>=20 > --14dae9cfcc30eab59204d035658c-- -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From jernej.tuljak@mg-soft.si Fri Dec 7 02:25:03 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59BF321F86CD for ; Fri, 7 Dec 2012 02:25:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q+DDHVmuJKTF for ; Fri, 7 Dec 2012 02:25:02 -0800 (PST) Received: from gate.mg-soft.si (gate.mg-soft.si [212.30.73.66]) by ietfa.amsl.com (Postfix) with ESMTP id 35B9E21F8735 for ; Fri, 7 Dec 2012 02:25:01 -0800 (PST) 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 qB7AP0jX023945; Fri, 7 Dec 2012 11:25:00 +0100 Message-ID: <50C1C3FB.90706@mg-soft.com> Date: Fri, 07 Dec 2012 11:24:59 +0100 From: Jernej Tuljak User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Ladislav Lhotka References: <56F5C7A8-FDC1-4FCA-963F-8D1343DCACAF@nic.cz> <20121206.213006.481309519.mbj@tail-f.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] is identity derivation reflexive? X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 07 Dec 2012 10:25:03 -0000 Dne 7.12.2012 10:52, piše Ladislav Lhotka: > On Dec 6, 2012, at 10:01 PM, Andy Bierman wrote: > >> --14dae9cfcc30eab59204d035658c >> Content-Type: text/plain; charset=UTF-8 >> >> On Thu, Dec 6, 2012 at 12:30 PM, Martin Bjorklund wrote: >> >>> Ladislav Lhotka wrote: >>>> On Dec 6, 2012, at 5:42 PM, Andy Bierman wrote: >>>> >>>>> .... >>>>> >>>>> Well, in your example the identityref has base "chips", so it cannot >>> reach >>>>> beyond this base to "snack". The more interesting question is this: >>>>> >>>>> leaf snack-type { >>>>> type identityref { base snacks; } >>>>> } >>>>> >>>>> Are the allowed values: >>>>> >>>>> 1. chips, candy (current 6020 wording) >>>>> >>>>> 2. snacks, chips, candy (reflexivity) >>>>> >>>>> 3. chips, candy, corn, potato, chocolate (transitivity) >>>>> >>>>> 4. snacks, chips, candy, corn, potato, chocolate (reflexivity & >>> transitivity) >>>>> >>>>> (4) >>>> Right, that was my original idea, too, but Martin said no. >> >> Right, it should be (3) but the RFC text seems to say that it is (4). >> >> >> In order to support (4) we would also need a 'abstract' keyword, to >>> indicate that the base class cannot be used as a proper value. This >>> just adds complexity for very little gain. With the current design, >>> you have to create identities for all values you want to support, not >>> a big deal >> >> We don't need a new keyword. >> I can't think of a use-case to use the base itself, as determined >> by the identityref leaf. >> >> snack-type = snacks >> chip-type = chips >> candy-type = candy > But one can easily argue that chips and candy are also "abstract" identities so that only leaf identities are supposed to be assigned to leafrefs. Yes. That is why I asked Can an identity which is used as an argument to another identities' base-stmt ever appear as a value of a data node at all? There's a fifth option: 5. corn, potato, chocolate (transitivity with abstract identities) Imagine a leaf-list indentityref with option (3) which is what Martin and Juergen say was the WG intention. leaf-list foo { type indentityref {base snacks;} } Since "chips" implies both "corn" and "potato", what does the following mean in a config: chips corn Technically speaking, one could argue that this breaks the unique constraint for leaf-list values ("corn" is duplicated), since the values have a special meaning. Anyways, I also understood the RFC as (1). There's nothing in there about transitivity. If this was not the intention, it should be fixed. Jernej > > Lada > >> You can't tell from the identity-stmt that a base is also a concrete >> identity, >> but you can tell from the leaf's type-stmt. Meaningless assignments like >> above >> should produce an invalid-value error. >> >> . >>> Is there any real use case that cannot be handled today? >>> >>> >>> /martin >>> >>> >>> >> Andy >> >> --14dae9cfcc30eab59204d035658c >> Content-Type: text/html; charset=UTF-8 >> Content-Transfer-Encoding: quoted-printable >> >>

On Thu, Dec 6, 2012 at 12:30 PM, Martin = >> Bjorklund <> "_blank">mbj@tail-f.com> wrote:
> _quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:= >> 1ex"> >> Ladislav Lhotka <lhotka@nic.cz> = >> wrote:
>> >
>> > On Dec 6, 2012, at 5:42 PM, Andy Bierman <> maworks.com">andy@yumaworks.com> wrote:
>> >
>> > > ....
>> > >
>> > > Well, in your example the identityref has base "chips",= >> so it cannot reach
>> > > beyond this base to "snack". The more interesting quest= >> ion is this:
>> > >
>> > > =C2=A0 =C2=A0leaf snack-type {
>> > > =C2=A0 =C2=A0 =C2=A0type identityref { base snacks; }
>> > > =C2=A0 =C2=A0}
>> > >
>> > > Are the allowed values:
>> > >
>> > > 1. chips, candy (current 6020 wording)
>> > >
>> > > 2. snacks, chips, candy (reflexivity)
>> > >
>> > > 3. chips, candy, corn, potato, chocolate (transitivity)
>> > >
>> > > 4. snacks, chips, candy, corn, potato, chocolate (reflexivity &am= >> p; transitivity)
>> > >
>> > >
>> > > (4)
>> >
>> > Right, that was my original idea, too, but Martin said no.
> uote>
=C2=A0

Right, it should be (3) but the R= >> FC text seems to say that it is (4).


> ockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #= >> ccc solid;padding-left:1ex"> >> >> In order to support (4) we would also need a 'abstract' keyword, to= >>
>> indicate that the base class cannot be used as a proper value. =C2=A0This> r> >> just adds complexity for very little gain. =C2=A0With the current design,> r> >> you have to create identities for all values you want to support, not
>> a big deal

We don't need a new keyword.= >>
I can't think of a use-case to use the base itself, as deter= >> mined
by the identityref leaf.

=C2=A0 = >> =C2=A0snack-type =3D snacks
>>
=C2=A0 =C2=A0chip-type =3D chips
=C2=A0 =C2=A0candy-type =3D= >> candy

You can't tell from the identity-stmt t= >> hat a base is also a concrete identity,
but you can tell from the= >> leaf's type-stmt. Meaningless assignments like above
>>
should produce an invalid-value error.

> class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc soli= >> d;padding-left:1ex">.
>>
>> Is there any real use case that cannot be handled today?
>>
>>
>> /martin
>>
>>
>>

Andy

>> >> --14dae9cfcc30eab59204d035658c-- > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From xiangli@seguesoft.com Fri Dec 7 07:22:21 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6B7D21F851B for ; Fri, 7 Dec 2012 07:22:21 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4J6X6HUe5Osm for ; Fri, 7 Dec 2012 07:22:16 -0800 (PST) Received: from p3plsmtpa07-06.prod.phx3.secureserver.net (p3plsmtpa07-06.prod.phx3.secureserver.net [173.201.192.235]) by ietfa.amsl.com (Postfix) with SMTP id CA5B921F85E3 for ; Fri, 7 Dec 2012 07:22:15 -0800 (PST) Received: (qmail 14980 invoked from network); 7 Dec 2012 15:22:13 -0000 Received: from unknown (98.212.151.151) by p3plsmtpa07-06.prod.phx3.secureserver.net (173.201.192.235) with ESMTP; 07 Dec 2012 15:22:13 -0000 Message-ID: <50C209A6.9050002@seguesoft.com> Date: Fri, 07 Dec 2012 09:22:14 -0600 From: Xiang Li User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: netmod@ietf.org References: <56F5C7A8-FDC1-4FCA-963F-8D1343DCACAF@nic.cz> <20121206.213006.481309519.mbj@tail-f.com> <50C1C3FB.90706@mg-soft.com> In-Reply-To: <50C1C3FB.90706@mg-soft.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [netmod] is identity derivation reflexive? X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 07 Dec 2012 15:22:21 -0000 > > Yes. That is why I asked > > Can an identity which is used > as an argument to another identities' base-stmt ever appear as a value > of a data node at all? > > There's a fifth option: > > 5. corn, potato, chocolate (transitivity with abstract identities) > I don't see this can count as another option. I think it's really the same as 3). > Imagine a leaf-list indentityref with option (3) which is what Martin > and Juergen say was the WG intention. > > leaf-list foo { > type indentityref {base snacks;} > } > > Since "chips" implies both "corn" and "potato", what does the > following mean in a config: > > chips > corn > > Technically speaking, one could argue that this breaks the unique > constraint for leaf-list values ("corn" is duplicated), since the > values have a special meaning. > > Anyways, I also understood the RFC as (1). There's nothing in there > about transitivity. If this was not the intention, it should be fixed. For me, since RFC6020 says: " Valid values for an identityref are any identities derived from the identityref's base identity." I think it's natural for me to consider "corn, potato, chocolate" (the descendants of snacks) are also derived from the the identityref's base identity "Snacks". If RFC6020 says the following instead: " Valid values for an identityref are any identities *directly* derived from the identityref's base identity." Then 1) will be my understanding. But since the word "directly" is not there in RFC6020, I think that the current wording is Ok. Of course it can be made clearer but IMO it's not a real problem. --Xiang From andy@yumaworks.com Fri Dec 7 07:39:36 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 725D921F88D9 for ; Fri, 7 Dec 2012 07:39:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.776 X-Spam-Level: X-Spam-Status: No, score=-1.776 tagged_above=-999 required=5 tests=[AWL=-1.066, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iYvPQWYXBBrH for ; Fri, 7 Dec 2012 07:39:35 -0800 (PST) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id C933A21F879A for ; Fri, 7 Dec 2012 07:39:34 -0800 (PST) Received: by mail-vc0-f172.google.com with SMTP id fw7so589495vcb.31 for ; Fri, 07 Dec 2012 07:39:34 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=G7jElnku3b8G2HJV3wkDUAxFQfPN/qxlUOhmgBHSfgA=; b=hHHlwu/hWQzpMEDZ9Qnig7GYTrUDHvIwRM0FkuJSDYk4fCibcIE2PNX5cekRqyr6+U qXPm+B5jJ7Kw3FscBUyl2Cji+VWLpDfYAwhHkM7KSc2IFb8k1d4p+8KYHZtqRdk4IJBP X9JueeXJWZSjkIvBpc6dXvLnhuLw+AzCeYZY8zPeVHKC3UIcVR2bXhOsKEpFoxjA6u3t GGnXO28Mgw97+kTMQSILSwpLIh2QAMzYuM6Cpb39tkMrFziPP4njQQ2Gd1NdSBIAtkEf NgBjCT+dpHrt9bAw1/unlMwZ0wXuBwcA5MGJt6QD0jO0fmoUZy3jNDX7DKLoytPvblLN mWWw== MIME-Version: 1.0 Received: by 10.58.64.51 with SMTP id l19mr4166248ves.15.1354894774029; Fri, 07 Dec 2012 07:39:34 -0800 (PST) Received: by 10.58.117.234 with HTTP; Fri, 7 Dec 2012 07:39:33 -0800 (PST) In-Reply-To: <50C1C3FB.90706@mg-soft.com> References: <56F5C7A8-FDC1-4FCA-963F-8D1343DCACAF@nic.cz> <20121206.213006.481309519.mbj@tail-f.com> <50C1C3FB.90706@mg-soft.com> Date: Fri, 7 Dec 2012 07:39:33 -0800 Message-ID: From: Andy Bierman To: Jernej Tuljak Content-Type: multipart/alternative; boundary=047d7b6d8102b6ced304d04505af X-Gm-Message-State: ALoCoQkimMcsifuG2j41+Wln1FWqkmYUa183SW9JhzuWzrLZds+A9ocAdJG2wRSxgzDQ0IBlt8bS Cc: netmod@ietf.org Subject: Re: [netmod] is identity derivation reflexive? X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 07 Dec 2012 15:39:36 -0000 --047d7b6d8102b6ced304d04505af Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, On Fri, Dec 7, 2012 at 2:24 AM, Jernej Tuljak wro= te: > Dne 7.12.2012 10:52, pi=C5=A1e Ladislav Lhotka: > >> On Dec 6, 2012, at 10:01 PM, Andy Bierman wrote: >> >> --14dae9cfcc30eab59204d035658c >>> Content-Type: text/plain; charset=3DUTF-8 >>> >>> On Thu, Dec 6, 2012 at 12:30 PM, Martin Bjorklund >>> wrote: >>> >>> Ladislav Lhotka wrote: >>>> >>>>> On Dec 6, 2012, at 5:42 PM, Andy Bierman wrote: >>>>> >>>>> .... >>>>>> >>>>>> Well, in your example the identityref has base "chips", so it cannot >>>>>> >>>>> reach >>>> >>>>> beyond this base to "snack". The more interesting question is this: >>>>>> >>>>>> leaf snack-type { >>>>>> type identityref { base snacks; } >>>>>> } >>>>>> >>>>>> Are the allowed values: >>>>>> >>>>>> 1. chips, candy (current 6020 wording) >>>>>> >>>>>> 2. snacks, chips, candy (reflexivity) >>>>>> >>>>>> 3. chips, candy, corn, potato, chocolate (transitivity) >>>>>> >>>>>> 4. snacks, chips, candy, corn, potato, chocolate (reflexivity & >>>>>> >>>>> transitivity) >>>> >>>>> >>>>>> (4) >>>>>> >>>>> Right, that was my original idea, too, but Martin said no. >>>>> >>>> >>> Right, it should be (3) but the RFC text seems to say that it is (4). >>> >>> >>> In order to support (4) we would also need a 'abstract' keyword, to >>> >>>> indicate that the base class cannot be used as a proper value. This >>>> just adds complexity for very little gain. With the current design, >>>> you have to create identities for all values you want to support, not >>>> a big deal >>>> >>> >>> We don't need a new keyword. >>> I can't think of a use-case to use the base itself, as determined >>> by the identityref leaf. >>> >>> snack-type =3D snacks >>> chip-type =3D chips >>> candy-type =3D candy >>> >> But one can easily argue that chips and candy are also "abstract" >> identities so that only leaf identities are supposed to be assigned to >> leafrefs. >> > > Yes. That is why I asked > > Can an identity which is used > as an argument to another identities' base-stmt ever appear as a value > of a data node at all? > > There's a fifth option: > > 5. corn, potato, chocolate (transitivity with abstract identities) > > Imagine a leaf-list indentityref with option (3) which is what Martin and > Juergen say was the WG intention. leaf-list foo { > type indentityref {base snacks;} > } > But 'chips' is only a base if there are more identities defined off of it that are supported by the server -- 'beer and chips' can be considered a valid snack, so even non-terminal identities may be valid values, depending on the leaf semantics. Leafref is not an issue -- any identityref value accepted by the server is valid to point at with a leafref. The issue is that the client doesn't know from reading the YANG module(s) what the server will accept for a given identityref leaf. I also raised the issue of adding a base-stmt to an identity in a later release. This should be allowed and does not seem to break any existing functionality. (e.g., add 'beverages' after 'beer' was the root) > Since "chips" implies both "corn" and "potato", what does the following > mean in a config: > > chips > corn > > The leaf-list needs to define the semantics I guess. I agree the current RFC does not specify the server behavior here. Does it accept 'chips' and ignore it? Send an invalid-value error? Should it be up to each implementation? I hope not. > Technically speaking, one could argue that this breaks the unique > constraint for leaf-list values ("corn" is duplicated), since the values > have a special meaning. > > Anyways, I also understood the RFC as (1). There's nothing in there about > transitivity. If this was not the intention, it should be fixed. > > Jernej > > Andy > >> Lada >> >> You can't tell from the identity-stmt that a base is also a concrete >>> identity, >>> but you can tell from the leaf's type-stmt. Meaningless assignments lik= e >>> above >>> should produce an invalid-value error. >>> >>> . >>> >>>> Is there any real use case that cannot be handled today? >>>> >>>> >>>> /martin >>>> >>>> >>>> >>>> Andy >>> >>> --14dae9cfcc30eab59204d035658c >>> Content-Type: text/html; charset=3DUTF-8 >>> Content-Transfer-Encoding: quoted-printable >>> >>>

On Thu, Dec 6, 2012 at 12:30 PM, >>> Martin =3D >>> Bjorklund <>> target=3D3D=3D >>> "_blank">mbj@tail-f.com&**gt; wrote:
>> class=3D3D"gmail=3D >>> _quote" style=3D3D"margin:0 0 0 .8ex;border-left:1px #ccc >>> solid;padding-left:=3D >>> 1ex"> >>> Ladislav Lhotka <**lhotka@nic.cz<= lhotka@nic.cz>> >>> =3D >>> wrote:
>>> >
>>> > On Dec 6, 2012, at 5:42 PM, Andy Bierman <>> andy@yu=3D >>> maworks.com">andy@yumaworks.**com > >>> wrote:
>>> >
>>> > > ....
>>> > >
>>> > > Well, in your example the identityref has base >>> "chips",=3D >>> so it cannot reach
>>> > > beyond this base to "snack". The more interesting >>> quest=3D >>> ion is this:
>>> > >
>>> > > =3DC2=3DA0 =3DC2=3DA0leaf snack-type {
>>> > > =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0type identityref { base snack= s; }
>>> > > =3DC2=3DA0 =3DC2=3DA0}
>>> > >
>>> > > Are the allowed values:
>>> > >
>>> > > 1. chips, candy (current 6020 wording)
>>> > >
>>> > > 2. snacks, chips, candy (reflexivity)
>>> > >
>>> > > 3. chips, candy, corn, potato, chocolate (transitivity)
>>> > >
>>> > > 4. snacks, chips, candy, corn, potato, chocolate (reflexivity >>> &am=3D >>> p; transitivity)
>>> > >
>>> > >
>>> > > (4)
>>> >
>>> > Right, that was my original idea, too, but Martin said >>> no.
>> uote>
=3DC2=3DA0
<**br>
Right, it should be (3)= but >>> the R=3D >>> FC text seems to say that it is (4).

** >>>
>> ockquote class=3D3D"gmail_quote" style=3D3D"margin:0 0 0 >>> .8ex;border-left:1px #=3D >>> ccc solid;padding-left:1ex"> >>> >>> In order to support (4) we would also need a 'abstract' keyword= , >>> to=3D >>>
>>> indicate that the base class cannot be used as a proper value. >>> =3DC2=3DA0This>> r> >>> just adds complexity for very little gain. =3DC2=3DA0With the current >>> design,>> r> >>> you have to create identities for all values you want to support, not >>> a big deal

We don't need a new >>> keyword.=3D >>>
I can't think of a use-case to use the base itself, as >>> deter=3D >>> mined
by the identityref leaf.

<**div>=3D= C2=3DA0 >>> =3D >>> =3DC2=3DA0snack-type =3D3D snacks
>>>
=3DC2=3DA0 =3DC2=3DA0chip-type =3D3D chips
=3DC2=3DA0 = =3DC2=3DA0candy-type >>> =3D3D=3D >>> candy

<**div>You can't tell from the >>> identity-stmt t=3D >>> hat a base is also a concrete identity,
but you can tell from >>> the=3D >>> leaf's type-stmt. Meaningless assignments like above
>>>
should produce an invalid-value error.

<** >>> blockquote=3D >>> class=3D3D"gmail_quote" style=3D3D"margin:0 0 0 .8ex;border-left:1px #c= cc >>> soli=3D >>> d;padding-left:1ex">.
>>>
>>> Is there any real use case that cannot be handled today?
>>>
>>>
>>> /martin
>>>
>>>
>>>
Andy
<**br>
>>> >>> --**14dae9cfcc30eab59204d035658c-- >>> >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C >> >> >> >> >> ______________________________**_________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/**listinfo/netmod >> > > --047d7b6d8102b6ced304d04505af Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi,


On Fri, Dec 7, 2012 at 2:24 AM, = Jernej Tuljak <jernej.tuljak@mg-soft.si> wrote:
Dne 7.12.2012 10:52, pi=C5=A1e Ladislav Lhotka:
On Dec 6, 2012, at 10:01 PM, Andy Bierman <andy@yumaworks.com> wrote:

--14dae9cfcc30eab59204d035658c
Content-Type: text/plain; charset=3DUTF-8

On Thu, Dec 6, 2012 at 12:30 PM, Martin Bjorklund <mbj@tail-f.com> wrote:

Ladislav Lhotka <lhot= ka@nic.cz> wrote:
On Dec 6, 2012, at 5:42 PM, Andy Bierman <andy@yumaworks.com> wrote:

....

Well, in your example the identityref has base "chips", so it can= not
reach
beyond this base to "snack". The more interesting question is thi= s:

=C2=A0 =C2=A0leaf snack-type {
=C2=A0 =C2=A0 =C2=A0type identityref { base snacks; }
=C2=A0 =C2=A0}

Are the allowed values:

1. chips, candy (current 6020 wording)

2. snacks, chips, candy (reflexivity)

3. chips, candy, corn, potato, chocolate (transitivity)

4. snacks, chips, candy, corn, potato, chocolate (reflexivity &
transitivity)

(4)
Right, that was my original idea, too, but Martin said no.

Right, it should be (3) but the RFC text seems to say that it is (4).


In order to support (4) we would also need a 'abstract' keyword, to=
indicate that the base class cannot be used as a proper value. =C2=A0This just adds complexity for very little gain. =C2=A0With the current design, you have to create identities for all values you want to support, not
a big deal

We don't need a new keyword.
I can't think of a use-case to use the base itself, as determined
by the identityref leaf.

=C2=A0 =C2=A0snack-type =3D snacks
=C2=A0 =C2=A0chip-type =3D chips
=C2=A0 =C2=A0candy-type =3D candy
But one can easily argue that chips and candy are also "abstract"= identities so that only leaf identities are supposed to be assigned to lea= frefs.

Yes. That is why I asked

Can an identity which is used
as an argument to another identities' base-stmt ever appear as a value<= br> of a data node at all?

There's a fifth option:

5. corn, potato, chocolate (transitivity with abstract identities)

Imagine a leaf-list indentityref with option (3) which is what Martin and J= uergen say was the WG intention.=C2=A0
leaf-list foo {
type indentityref {base snacks;}
}

But 'chips' is only a base if= there are more identities defined off of it that are supported
b= y the server -- 'beer and chips' can be considered a valid snack, s= o
even non-terminal identities may be valid values, depending on the lea= f semantics.

Leafref is not an issue -- any identi= tyref value accepted by the server is valid to point at
with a le= afref.

The issue is that the client doesn't know from read= ing the YANG module(s) what
the server will accept for a given id= entityref leaf.

I also raised the issue of adding = a base-stmt to an identity in a later release.
This should be allowed and does not seem to break any existing functio= nality.
(e.g., add 'beverages' after 'beer' was t= he root)



Since "chips" implies both "corn" and "potato"= ;, what does the following mean in a config:

<foo>chips</foo>
<foo>corn</foo>


The leaf-list needs to define the sema= ntics I guess.
I agree the current RFC does not specify the serve= r behavior here.
Does it accept 'chips' and ignore it? Se= nd an invalid-value error?
Should it be up to each implementation? I hope not.

=C2=A0
Technically speaking, one could argue that this breaks the unique constrain= t for leaf-list values ("corn" is duplicated), since the values h= ave a special meaning.

Anyways, I also understood the RFC as (1). There's nothing in there abo= ut transitivity. If this was not the intention, it should be fixed.

Jernej




Andy

=C2=A0

Lada

You can't tell from the identity-stmt that a base is also a concrete identity,
but you can tell from the leaf's type-stmt. Meaningless assignments lik= e
above
should produce an invalid-value error.

.
Is there any real use case that cannot be handled today?


/martin



Andy

--14dae9cfcc30eab59204d035658c
Content-Type: text/html; charset=3DUTF-8
Content-Transfer-Encoding: quoted-printable

<br><br><div class=3D3D"gmail_quote">On Thu, De= c 6, 2012 at 12:30 PM, Martin =3D
Bjorklund <span dir=3D3D"ltr">&lt;<a href=3D3D"= mailto:mbj@tail-f.com" target=3D3D=3D
"_blank">m= bj@tail-f.com</a>&gt;</span> wrote:<br><= ;blockquote class=3D3D"gmail=3D
_quote" style=3D3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;p= adding-left:=3D
1ex">
Ladislav Lhotka &lt;<a href=3D3D"mailto:lhotka@nic.cz">lhotka@nic.cz</a>&gt; = =3D
wrote:<br>
&gt;<br>
&gt; On Dec 6, 2012, at 5:42 PM, Andy Bierman &lt;<a href=3D3D&q= uot;mailto:andy@yu=3D
maworks.com"><= a href=3D"mailto:andy@yumaworks.com" target=3D"_blank">andy@yumaworks.com</a>&gt; wrote:<br>
&gt;<br>
&gt; &gt; ....<br>
&gt; &gt;<br>
&gt; &gt; Well, in your example the identityref has base &quot;= chips&quot;,=3D
so it cannot reach<br>
&gt; &gt; beyond this base to &quot;snack&quot;. The more i= nteresting quest=3D
ion is this:<br>
&gt; &gt;<br>
&gt; &gt; =3DC2=3DA0 =3DC2=3DA0leaf snack-type {<br>
&gt; &gt; =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0type identityref { base s= nacks; }<br>
&gt; &gt; =3DC2=3DA0 =3DC2=3DA0}<br>
&gt; &gt;<br>
&gt; &gt; Are the allowed values:<br>
&gt; &gt;<br>
&gt; &gt; 1. chips, candy (current 6020 wording)<br>
&gt; &gt;<br>
&gt; &gt; 2. snacks, chips, candy (reflexivity)<br>
&gt; &gt;<br>
&gt; &gt; 3. chips, candy, corn, potato, chocolate (transitivity)&l= t;br>
&gt; &gt;<br>
&gt; &gt; 4. snacks, chips, candy, corn, potato, chocolate (reflexi= vity &am=3D
p; transitivity)<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt; (4)<br>
&gt;<br>
&gt; Right, that was my original idea, too, but Martin said no.<br&g= t;</blockq=3D
uote><div>=3DC2=3DA0</div><div><br></d= iv><div>Right, it should be (3) but the R=3D
FC text seems to say that it is (4).</div><div><br></d= iv><div><br></div><bl=3D
ockquote class=3D3D"gmail_quote" style=3D3D"margin:0 0 0 .8e= x;border-left:1px #=3D
ccc solid;padding-left:1ex">

In order to support (4) we would also need a &#39;abstract&#39; key= word, to=3D
<br>
indicate that the base class cannot be used as a proper value. =3DC2=3DA0Th= is<b=3D
r>
just adds complexity for very little gain. =3DC2=3DA0With the current desig= n,<b=3D
r>
you have to create identities for all values you want to support, not<br= >
a big deal</blockquote><div><br></div><di= v>We don&#39;t need a new keyword.=3D
</div><div>I can&#39;t think of a use-case to use the base = itself, as deter=3D
mined</div><div>by the identityref leaf.</div><div>= <br></div><div>=3DC2=3DA0 =3D
=3DC2=3DA0snack-type =3D3D snacks</div>
<div>=3DC2=3DA0 =3DC2=3DA0chip-type =3D3D chips</div><div>= ;=3DC2=3DA0 =3DC2=3DA0candy-type =3D3D=3D
candy</div><div><br></div><div>You can= &#39;t tell from the identity-stmt t=3D
hat a base is also a concrete identity,</div><div>but you can t= ell from the=3D
leaf&#39;s type-stmt. Meaningless assignments like above</div> <div>should produce an invalid-value error.</div><div><= ;br></div><blockquote=3D
class=3D3D"gmail_quote" style=3D3D"margin:0 0 0 .8ex;border-= left:1px #ccc soli=3D
d;padding-left:1ex">.<br>
<br>
Is there any real use case that cannot be handled today?<br>
<span class=3D3D"HOEnZb"><font color=3D3D"#888888&q= uot;><br>
<br>
/martin<br>
<br>
<br>
</font></span></blockquote></div><br>&= lt;div>Andy</div><div><br></div>

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




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


--047d7b6d8102b6ced304d04505af-- From lhotka@nic.cz Fri Dec 7 08:10:10 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 004F721F898B for ; Fri, 7 Dec 2012 08:10:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eVqPfnUtVGBb for ; Fri, 7 Dec 2012 08:10:09 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 1218121F88CD for ; Fri, 7 Dec 2012 08:10:08 -0800 (PST) Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 60F1613FE20; Fri, 7 Dec 2012 17:10:07 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1354896607; bh=x3o5fdwFLiW/VrfQyCKqA9vDJMUYj4TLwgEc6bobzP8=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=jwuR67a+97riH18gWpnFFTTDdPUtEU+KauQQx9KQCodvzGMIKaeMxFqpi617KoWup bMD+63/uXN6AMQXg0DZPSLfmLLm+1whqqySg+vGrd+nKHpkknCbZ62jwQsGUXjE6K8 zJ/hJVhThCoktA606J2Bp4yodbFa4NvUup6PEb4o= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ladislav Lhotka In-Reply-To: <50C209A6.9050002@seguesoft.com> Date: Fri, 7 Dec 2012 17:10:06 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <76EA121E-C753-4E29-B33E-1C1528732EB0@nic.cz> References: <56F5C7A8-FDC1-4FCA-963F-8D1343DCACAF@nic.cz> <20121206.213006.481309519.mbj@tail-f.com> <50C1C3FB.90706@mg-soft.com> <50C209A6.9050002@seguesoft.com> To: Xiang Li X-Mailer: Apple Mail (2.1499) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] is identity derivation reflexive? X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 07 Dec 2012 16:10:10 -0000 On Dec 7, 2012, at 4:22 PM, Xiang Li wrote: >=20 >>=20 >> Yes. That is why I asked >>=20 >> Can an identity which is used >> as an argument to another identities' base-stmt ever appear as a = value >> of a data node at all? >>=20 >> There's a fifth option: >>=20 >> 5. corn, potato, chocolate (transitivity with abstract identities) >>=20 >=20 > I don't see this can count as another option. I think it's really the = same as 3). It's not the same because two values from (3) are not valid here. >=20 >> Imagine a leaf-list indentityref with option (3) which is what Martin = and Juergen say was the WG intention. >>=20 >> leaf-list foo { >> type indentityref {base snacks;} >> } >>=20 >> Since "chips" implies both "corn" and "potato", what does the = following mean in a config: >>=20 >> chips >> corn >>=20 >> Technically speaking, one could argue that this breaks the unique = constraint for leaf-list values ("corn" is duplicated), since the values = have a special meaning. >>=20 >> Anyways, I also understood the RFC as (1). There's nothing in there = about transitivity. If this was not the intention, it should be fixed. >=20 > For me, since RFC6020 says: >=20 > " Valid values for an identityref are any identities derived from the = identityref's base identity." >=20 > I think it's natural for me to consider "corn, potato, chocolate" = (the descendants of snacks) are also derived from the the identityref's = base identity "Snacks". Apparently, different things are natural for different people, so the = spec has to be more precise. There is no definition of what "deriving an = identity" means, except in sec. 7.16.1: 'The "base" statement, which is optional, takes as an argument a string = that is the name of an existing identity, from which the new identity is = derived.' This means the relation "derived from" is established only between an = identity and its base identity, if there is any. Lada >=20 > If RFC6020 says the following instead: >=20 > " Valid values for an identityref are any identities *directly* = derived from the identityref's base identity." >=20 > Then 1) will be my understanding. But since the word "directly" is not = there in RFC6020, I think that the current wording is Ok. Of course it = can be made clearer but IMO it's not a real problem. >=20 >=20 > --Xiang >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From lhotka@nic.cz Sat Dec 8 23:19:40 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE36021F8BE2 for ; Sat, 8 Dec 2012 23:19:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZtAblgUs8sgd for ; Sat, 8 Dec 2012 23:19:40 -0800 (PST) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 5011821F8BDD for ; Sat, 8 Dec 2012 23:19:40 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 6044A54049E; Sun, 9 Dec 2012 08:19:38 +0100 (CET) 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 cCXZNQRTkpoK; Sun, 9 Dec 2012 08:19:35 +0100 (CET) Received: from localhost (unknown [10.107.191.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id EF13C5402E4; Sun, 9 Dec 2012 08:19:28 +0100 (CET) From: Ladislav Lhotka To: Juergen Schoenwaelder , Martin Bjorklund In-Reply-To: <20121206222415.GA37446@elstar.local> References: <56F5C7A8-FDC1-4FCA-963F-8D1343DCACAF@nic.cz> <20121206.213006.481309519.mbj@tail-f.com> <20121206.230919.415162795.mbj@tail-f.com> <20121206222415.GA37446@elstar.local> User-Agent: Notmuch/0.14+100~ge0adf10 (http://notmuchmail.org) Emacs/23.3.50.1 (i386-apple-darwin9.8.0) Mail-Followup-To: Juergen Schoenwaelder , Martin Bjorklund , netmod@ietf.org Date: Sun, 09 Dec 2012 08:19:08 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: netmod@ietf.org Subject: Re: [netmod] is identity derivation reflexive? X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 09 Dec 2012 07:19:40 -0000 Juergen Schoenwaelder writes: > > In any case, I think this needs to be clarified since the current text > apparently leads to different interpretations. Someone wants to open > an errata? How about this? Section 7.16.2 says: An identity MUST NOT reference itself, neither directly nor indirectly through a chain of other identities. It should say: The derivation of identities has the following properties: o It is irreflexive, which means that no identity is derived from itself. o It is transitive, which means that if identity B is derived from A and C is derived from B, then C is also derived from A. Lada -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From muthu@cisco.com Sun Dec 9 08:51:39 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B5A321F8431 for ; Sun, 9 Dec 2012 08:51:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26XHEaaYtPO4 for ; Sun, 9 Dec 2012 08:51:38 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id AB96921F8421 for ; Sun, 9 Dec 2012 08:51:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7291; q=dns/txt; s=iport; t=1355071898; x=1356281498; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=KnUoAhfLD+hMymPhB+7e6pUikDFYVHdoUGW+UGErTVQ=; b=LRB2hOXxnKg1OJsuvYuft8nBqBQkwKHw22z7xJW3tjFKqEpJx2LgxpQo df9QoCWOM8fHUUnqahcomIh65sRT9G5EHZu9KwobSnLlgJjOI6ID/XDu0 9f3wH4ioAUW3Ye7rs9wWP7vvmjRW+fYbyCxYvLyi+EyMHoOF1A4E+nBhk Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAJbAxFCtJXG9/2dsb2JhbABDgkm8FRZzgh4BAQEEgQsBCBEDAQILHTkUCQgCBAESCIgJvleMPwmDWWEDpk6Cc4FkPg X-IronPort-AV: E=McAfee;i="5400,1158,6920"; a="150958385" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-2.cisco.com with ESMTP; 09 Dec 2012 16:51:38 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id qB9GpcIc021215 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 9 Dec 2012 16:51:38 GMT Received: from xmb-rcd-x13.cisco.com ([169.254.3.77]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.02.0318.004; Sun, 9 Dec 2012 10:51:37 -0600 From: "Muthumayan Madhayyan (muthu)" To: Andy Bierman , "netmod@ietf.org" Thread-Topic: [netmod] default NP container question Thread-Index: AQHN0zrpXH/Y1w46PkCFL8W83mymNZgQkuaA Date: Sun, 9 Dec 2012 16:51:37 +0000 Message-ID: <5A949C32AF740C4798AEECF2568F0D84216EFA@xmb-rcd-x13.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.2.120421 x-originating-ip: [10.21.95.201] Content-Type: multipart/alternative; boundary="_000_5A949C32AF740C4798AEECF2568F0D84216EFAxmbrcdx13ciscocom_" MIME-Version: 1.0 Subject: Re: [netmod] default NP container question X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 09 Dec 2012 16:51:39 -0000 --_000_5A949C32AF740C4798AEECF2568F0D84216EFAxmbrcdx13ciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable From: Andy Bierman > Date: Wednesday, December 5, 2012 2:50 PM To: "netmod@ietf.org" > Subject: [netmod] default NP container question Hi, I am not sure which RFC should or does say what to do: container npcon { leaf a { type int32; default 42; } leaf b { type string; } } I read this to mean that if the container npcon gets created, then the leaf= 'a' is automatically created with value 42. If the leaf npcon/b gets crea= ted, then both npcon and npcon/a are created. If you do a in normal mode, the 'npcon' container is not returned. This is fine. So, I presume there was never an attempt to create npcon. If you do a with-defaults=3Dreport-all, the 'npcon' container is returned: npcon { a 42 } Is this correct ? Do we really need to return npcon/a when there was no att= empt to create npcon in the first place ? So what happens if you do a create operation on /npcon? Is this OK or is it a 'data-exists' error? Shouldn't create on /npcon should be allowed ONLY for containers with 'pre= sence' statement -OR=96 if a container has immediate descendant leaf nodes = with default values (like npcon), the container should automatically become= 'presence' containers ? Creation of the container then makes semantic se= nse, because creation of npcon automatically creates npcon/a=3D42. What about a delete operation on /npcon? Is this OK or a 'data-missing' error? Deletion of /npcon can result in deletion of all descendant nodes and the c= ontainer itself (like Martin had mentioned). Currently, yuma is doing something wrong -- returning both data-exists on a create and data-missing error on a delete. What are the correct responses? thanks, Andy --_000_5A949C32AF740C4798AEECF2568F0D84216EFAxmbrcdx13ciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable


From: Andy Bierman <andy@yumaworks.com>
Date: Wednesday, December 5, 2012 2= :50 PM
To: "netmod@ietf.org" <= netmod@ietf.org>
Subject: [netmod] default NP contai= ner question

Hi,

I am not sure which RFC should or does say what to do:

container npcon {
   leaf a { type int32; default 42; }
   leaf b { type string; }
}

I read this to mean that if the container npcon gets created, then the= leaf 'a' is automatically created with value 42.  If the leaf npcon/b= gets created, then both npcon and npcon/a are created.  


If you do a <get-config> in normal mode, the 'npcon' container
is not returned.

This is fine.  So, I presume there was never an attempt to create= npcon.

If you do a <get-config> with-defaults=3Dreport-all, the 'npcon'= container
is returned:

 npcon {
    a 42
 }

Is this correct ? Do we really need to return npcon/a when there was n= o attempt to create npcon in the first place ?


So what happens if you do a create operation on /npcon?

Is this OK or is it a 'data-exists' error?

Shouldn't  create on /npcon should be allowed ONLY for containers= with 'presence' statement -OR=96 if a container has immediate descendant l= eaf nodes with default values (like npcon), the container should automatica= lly become  'presence' containers ?  Creation of the container then makes semantic sense, because creation of npcon auto= matically creates npcon/a=3D42.


What about a delete operation on /npcon?

Is this OK or a 'data-missing' error?

Deletion of /npcon can result in deletion of all descendant nodes and = the container itself  (like Martin had mentioned).


Currently, yuma is doing something wrong -- returning both
data-exists on a create and data-missing error on a delete.

What are the correct responses?


thanks,
Andy

 --_000_5A949C32AF740C4798AEECF2568F0D84216EFAxmbrcdx13ciscocom_-- From andy@yumaworks.com Sun Dec 9 09:23:31 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4200921F8C01 for ; Sun, 9 Dec 2012 09:23:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.803 X-Spam-Level: X-Spam-Status: No, score=-2.803 tagged_above=-999 required=5 tests=[AWL=0.173, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DnGFLPFkrBWF for ; Sun, 9 Dec 2012 09:23:30 -0800 (PST) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 020E421F8BB6 for ; Sun, 9 Dec 2012 09:23:29 -0800 (PST) Received: by mail-vc0-f172.google.com with SMTP id fw7so1977966vcb.31 for ; Sun, 09 Dec 2012 09:23:29 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=z6nmkw1FaKWjV0y5tuLRPEP6vsnzFRjBeqbmxNyDCiM=; b=F+IBR/ZOIDzgrkyDvVdlm1rAbppQJH+GCJ3iKA2xGr89jycaaAa1LdxciskZSM/do2 VLduNbpxbDiI2HQU7cWOrBRSNtnDtHxFsYTBV0xw0NfyKDxFKZr4Zzx3ReMKyluhGtA1 73oxmcHZZ1r0I8griL1pVKpUhldmkRMXTsJmZhKGv4T1m0GVFMh9rLQ+WpP635KJfmSM I+oZcwcjEkvx5EkwJHGceXWQ+l9bFn/JpEw0CMkoHuqAyAV4d5hA1DKZVi6WrGYReQII uPkZgBusnjHl1auDOZXw27Sbum7CqbZ5U98tH9uSQDgFD2dTOQv6YMXNEDbG1wFAZkfS ZYvg== MIME-Version: 1.0 Received: by 10.52.66.34 with SMTP id c2mr6482646vdt.62.1355073809403; Sun, 09 Dec 2012 09:23:29 -0800 (PST) Received: by 10.58.117.234 with HTTP; Sun, 9 Dec 2012 09:23:29 -0800 (PST) In-Reply-To: <5A949C32AF740C4798AEECF2568F0D84216EFA@xmb-rcd-x13.cisco.com> References: <5A949C32AF740C4798AEECF2568F0D84216EFA@xmb-rcd-x13.cisco.com> Date: Sun, 9 Dec 2012 09:23:29 -0800 Message-ID: From: Andy Bierman To: "Muthumayan Madhayyan (muthu)" Content-Type: multipart/alternative; boundary=20cf307f35c20dd09b04d06eb513 X-Gm-Message-State: ALoCoQnjVKCmMhjRgg8Mrl+Gakue2SlyKK9NbR136u/Z68LuqhmVjOvAQwBjKVm7I4qxc3kVdYP8 Cc: "netmod@ietf.org" Subject: Re: [netmod] default NP container question X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 09 Dec 2012 17:23:31 -0000 --20cf307f35c20dd09b04d06eb513 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, NP containers are transparent in some ways. Since they are just containment nodes, their child nodes can impact their properties. A default leaf in an NP-container causes the NP-container to be a default. A mandatory child node causes the NP-container to be mandatory. Yuma doesn't actually handle default NP containers at all (just YumaPro). After fixing the code, IMO the correct answer is that a create succeeds and a delete fails on a default NP-container. A delete on a real NP-container can be immediately replaced by the server. I agree with Martin that it is OK for the server to create NP containers and the client needs to check the with-defaults to use create/delete. The client can always use merge/remove instead and ignore defaults. Remember that with-defaults=3Dreport-all adds nodes in the reply that are missing from the server -- these are the defaults in use because no node exists. The server basic-mode for defaults handling determines if a node exists or not. Andy On Sun, Dec 9, 2012 at 8:51 AM, Muthumayan Madhayyan (muthu) < muthu@cisco.com> wrote: > > > From: Andy Bierman > Date: Wednesday, December 5, 2012 2:50 PM > To: "netmod@ietf.org" > Subject: [netmod] default NP container question > > Hi, > > I am not sure which RFC should or does say what to do: > > container npcon { > leaf a { type int32; default 42; } > leaf b { type string; } > } > > > I read this to mean that if the container npcon gets created, then the > leaf 'a' is automatically created with value 42. If the leaf npcon/b get= s > created, then both npcon and npcon/a are created. > > > If you do a in normal mode, the 'npcon' container > is not returned. > > > This is fine. So, I presume there was never an attempt to create npcon. > > > If you do a with-defaults=3Dreport-all, the 'npcon' contain= er > is returned: > > npcon { > a 42 > } > > > Is this correct ? Do we really need to return npcon/a when there was no > attempt to create npcon in the first place ? > > > So what happens if you do a create operation on /npcon? > > Is this OK or is it a 'data-exists' error? > > > Shouldn't create on /npcon should be allowed ONLY for containers with > 'presence' statement -OR=E2=80=93 if a container has immediate descendant= leaf > nodes with default values (like npcon), the container should automaticall= y > become 'presence' containers ? Creation of the container then makes > semantic sense, because creation of npcon automatically creates npcon/a= =3D42. > > > What about a delete operation on /npcon? > > Is this OK or a 'data-missing' error? > > > Deletion of /npcon can result in deletion of all descendant nodes and > the container itself (like Martin had mentioned). > > > Currently, yuma is doing something wrong -- returning both > data-exists on a create and data-missing error on a delete. > > What are the correct responses? > > > thanks, > Andy > > --20cf307f35c20dd09b04d06eb513 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi,

NP containers are transparent in some ways.
Since they are just containment nodes, their child nodes
can im= pact their properties. =C2=A0A default leaf in an NP-container
ca= uses the NP-container to be a default.
A mandatory child node causes the NP-container to be mandatory.
<= div>
Yuma doesn't actually handle default NP containers a= t all (just YumaPro).
After fixing the code, IMO the correct answ= er is that a create succeeds and
a delete fails on a default NP-container. A delete on a real NP-contai= ner
can be immediately replaced by the server. =C2=A0I agree with= Martin that it
is OK for the server to create NP containers and = the client needs to check
the with-defaults to use create/delete. =C2=A0The client can always us= e merge/remove
instead and ignore defaults.

<= div>Remember that with-defaults=3Dreport-all adds nodes in the reply that a= re missing
from the server -- these are the defaults in use because no node exist= s.
The server basic-mode for defaults handling determines if a no= de exists or not.


Andy

On Sun, Dec 9, 2012 at 8:51 AM, Muthumayan Madhayyan (muthu) <muthu@cisco.co= m> wrote:


From: Andy Bierman <andy@yumaworks.com>
Date: Wednesday, December 5, 2012 2= :50 PM
To: "netmod@ietf.org" <netmod@ietf.org>
Subject: [netmod] default NP contai= ner question

Hi,

I am not sure which RFC should or does say what to do:

container npcon {
=C2=A0 =C2=A0leaf a { type int32; default 42; }
=C2=A0 =C2=A0leaf b { type string; }
}

I read this to mean that if the container npcon gets created, then the= leaf 'a' is automatically created with value 42. =C2=A0If the leaf= npcon/b gets created, then both npcon and npcon/a are created. =C2=A0


If you do a <get-config> in normal mode, the 'npcon' con= tainer
is not returned.

This is fine. =C2=A0So, I presume there was never an attempt to create= npcon.

If you do a <get-config> with-defaults=3Dreport-all, the 'np= con' container
is returned:

=C2=A0npcon {
=C2=A0 =C2=A0 a 42
=C2=A0}

Is this correct ? Do we really need to return npcon/a when there was n= o attempt to create npcon in the first place ?


So what happens if you do a create operation on /npcon?

Is this OK or is it a 'data-exists' error?

Shouldn't =C2=A0create on /npcon should be allowed ONLY for contai= ners with 'presence' statement -OR=E2=80=93 if a container has imme= diate descendant leaf nodes with default values (like npcon), the container= should automatically become =C2=A0'presence' containers ? =C2=A0Cr= eation of the container then makes semantic sense, because creation of npcon auto= matically creates npcon/a=3D42.


What about a delete operation on /npcon?

Is this OK or a 'data-missing' error?

Deletion of /npcon can result in deletion of all descendant nodes and = the container itself =C2=A0(like Martin had mentioned).


Currently, yuma is doing something wrong -- returning both
data-exists on a create and data-missing error on a delete.

What are the correct responses?


thanks,
Andy

--20cf307f35c20dd09b04d06eb513-- From muthu@cisco.com Sun Dec 9 10:16:31 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6042521F8CB3 for ; Sun, 9 Dec 2012 10:16:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CpyaVgMbPd54 for ; Sun, 9 Dec 2012 10:16:30 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 329B621F8CB1 for ; Sun, 9 Dec 2012 10:16:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12108; q=dns/txt; s=iport; t=1355076990; x=1356286590; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=ILuRcVkthzv2aCbhHZHpDDVm2iSe5NFjXnhgJQxsMb8=; b=D6OJ+fO+aKay8FjqJZdpCIZJsYjt0zIcjB338gbs2ax3sN+jiPsckW9X g/aq8d/IpwX5IE9rGpaDojqNLwm/nANWWBlU/Ke98Cc5/v3fsztNk3dkx sI1Irr/ifaMgk0rZ8+3EDSIV4OU8EWqHR2GGXa9b2TjeStwhdMBfPSe87 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFADXUxFCtJV2Z/2dsb2JhbABEgkm8FRZzgh4BAQEEeRIBCBEDAQILHTkUCQgCBA4FCIgJvmSMPwmDWWEDpk6Cc4FkPg X-IronPort-AV: E=McAfee;i="5400,1158,6921"; a="150999134" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-8.cisco.com with ESMTP; 09 Dec 2012 18:16:29 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id qB9IGTef017384 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 9 Dec 2012 18:16:29 GMT Received: from xmb-rcd-x13.cisco.com ([169.254.3.77]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.02.0318.004; Sun, 9 Dec 2012 12:16:29 -0600 From: "Muthumayan Madhayyan (muthu)" To: Andy Bierman Thread-Topic: [netmod] default NP container question Thread-Index: AQHN0zrpXH/Y1w46PkCFL8W83mymNZgQkuaAgACPCID//4itAA== Date: Sun, 9 Dec 2012 18:16:29 +0000 Message-ID: <5A949C32AF740C4798AEECF2568F0D84217FC9@xmb-rcd-x13.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.2.120421 x-originating-ip: [10.21.95.201] Content-Type: multipart/alternative; boundary="_000_5A949C32AF740C4798AEECF2568F0D84217FC9xmbrcdx13ciscocom_" MIME-Version: 1.0 Cc: "netmod@ietf.org" Subject: Re: [netmod] default NP container question X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 09 Dec 2012 18:16:31 -0000 --_000_5A949C32AF740C4798AEECF2568F0D84217FC9xmbrcdx13ciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable From: Andy Bierman > Date: Sunday, December 9, 2012 9:23 AM To: Muthumayan M > Cc: "netmod@ietf.org" > Subject: Re: [netmod] default NP container question Hi, NP containers are transparent in some ways. Since they are just containment nodes, their child nodes can impact their properties. A default leaf in an NP-container causes the NP-container to be a default. A mandatory child node causes the NP-container to be mandatory. I was under the impression that the default settings and mandatory nodes ex= ist only if the immediate parent-node exists. What happens if the parent node for the container is a list ? On what basi= s would the server create a 'default list' ? Yuma doesn't actually handle default NP containers at all (just YumaPro). After fixing the code, IMO the correct answer is that a create succeeds and a delete fails on a default NP-container. A delete on a real NP-container can be immediately replaced by the server. I agree with Martin that it is OK for the server to create NP containers and the client needs to check the with-defaults to use create/delete. The client can always use merge/re= move instead and ignore defaults. Remember that with-defaults=3Dreport-all adds nodes in the reply that are m= issing from the server -- these are the defaults in use because no node exists. The server basic-mode for defaults handling determines if a node exists or = not. Andy On Sun, Dec 9, 2012 at 8:51 AM, Muthumayan Madhayyan (muthu) > wrote: From: Andy Bierman > Date: Wednesday, December 5, 2012 2:50 PM To: "netmod@ietf.org" > Subject: [netmod] default NP container question Hi, I am not sure which RFC should or does say what to do: container npcon { leaf a { type int32; default 42; } leaf b { type string; } } I read this to mean that if the container npcon gets created, then the leaf= 'a' is automatically created with value 42. If the leaf npcon/b gets crea= ted, then both npcon and npcon/a are created. If you do a in normal mode, the 'npcon' container is not returned. This is fine. So, I presume there was never an attempt to create npcon. If you do a with-defaults=3Dreport-all, the 'npcon' container is returned: npcon { a 42 } Is this correct ? Do we really need to return npcon/a when there was no att= empt to create npcon in the first place ? So what happens if you do a create operation on /npcon? Is this OK or is it a 'data-exists' error? Shouldn't create on /npcon should be allowed ONLY for containers with 'pre= sence' statement -OR=96 if a container has immediate descendant leaf nodes = with default values (like npcon), the container should automatically become= 'presence' containers ? Creation of the container then makes semantic se= nse, because creation of npcon automatically creates npcon/a=3D42. What about a delete operation on /npcon? Is this OK or a 'data-missing' error? Deletion of /npcon can result in deletion of all descendant nodes and the c= ontainer itself (like Martin had mentioned). Currently, yuma is doing something wrong -- returning both data-exists on a create and data-missing error on a delete. What are the correct responses? thanks, Andy --_000_5A949C32AF740C4798AEECF2568F0D84217FC9xmbrcdx13ciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable


From: Andy Bierman <andy@yumaworks.com>
Date: Sunday, December 9, 2012 9:23= AM
To: Muthumayan M <muthu@cisco.com>
Cc: "netmod@ietf.org" <= netmod@ietf.org>
Subject: Re: [netmod] default NP co= ntainer question

Hi,

NP containers are transparent in some ways.
Since they are just containment nodes, their child nodes
can impact their properties.  A default leaf in an NP-container
causes the NP-container to be a default.
A mandatory child node causes the NP-container to be mandatory.

I was under the impression that the default settings and mandatory nod= es exist only if the immediate parent-node exists. 
What happens if the parent node for the container is a list ?  On= what basis would the server create a  'default list' ?


Yuma doesn't actually handle default NP containers at all (just YumaPr= o).
After fixing the code, IMO the correct answer is that a create succeed= s and
a delete fails on a default NP-container. A delete on a real NP-contai= ner
can be immediately replaced by the server.  I agree with Martin t= hat it
is OK for the server to create NP containers and the client needs to c= heck
the with-defaults to use create/delete.  The client can always us= e merge/remove
instead and ignore defaults.

Remember that with-defaults=3Dreport-all adds nodes in the reply that = are missing
from the server -- these are the defaults in use because no node exist= s.
The server basic-mode for defaults handling determines if a node exist= s or not.


Andy

On Sun, Dec 9, 2012 at 8:51 AM, Muthumayan Madha= yyan (muthu) <= muthu@cisco.com> wrote:


From: Andy Bierman <andy@yumaworks.com>
Date: Wednesday, December 5, 2012 2= :50 PM
To: "netmod@ietf.org" <netmod@ietf.org>
Subject: [netmod] default NP contai= ner question

Hi,

I am not sure which RFC should or does say what to do:

container npcon {
   leaf a { type int32; default 42; }
   leaf b { type string; }
}

I read this to mean that if the container npcon gets created, then the= leaf 'a' is automatically created with value 42.  If the leaf npcon/b= gets created, then both npcon and npcon/a are created.  


If you do a <get-config> in normal mode, the 'npcon' container
is not returned.

This is fine.  So, I presume there was never an attempt to create= npcon.

If you do a <get-config> with-defaults=3Dreport-all, the 'npcon'= container
is returned:

 npcon {
    a 42
 }

Is this correct ? Do we really need to return npcon/a when there was n= o attempt to create npcon in the first place ?


So what happens if you do a create operation on /npcon?

Is this OK or is it a 'data-exists' error?

Shouldn't  create on /npcon should be allowed ONLY for containers= with 'presence' statement -OR=96 if a container has immediate descendant l= eaf nodes with default values (like npcon), the container should automatica= lly become  'presence' containers ?  Creation of the container then makes semantic sense, because creation of npcon auto= matically creates npcon/a=3D42.


What about a delete operation on /npcon?

Is this OK or a 'data-missing' error?

Deletion of /npcon can result in deletion of all descendant nodes and = the container itself  (like Martin had mentioned).


Currently, yuma is doing something wrong -- returning both
data-exists on a create and data-missing error on a delete.

What are the correct responses?


thanks,
Andy


 --_000_5A949C32AF740C4798AEECF2568F0D84217FC9xmbrcdx13ciscocom_-- From andy@yumaworks.com Sun Dec 9 14:54:38 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1685221F8D23 for ; Sun, 9 Dec 2012 14:54:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.818 X-Spam-Level: X-Spam-Status: No, score=-2.818 tagged_above=-999 required=5 tests=[AWL=0.158, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lX3R405aExHn for ; Sun, 9 Dec 2012 14:54:37 -0800 (PST) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id E532021F8D04 for ; Sun, 9 Dec 2012 14:54:36 -0800 (PST) Received: by mail-vc0-f172.google.com with SMTP id fw7so2125842vcb.31 for ; Sun, 09 Dec 2012 14:54:36 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=ZRYf859XW1mU7zgJB5cjdfmCD2i/gd4Z5HAgPWeaPyw=; b=GxmaSLNIZ4QKIpmMWFKQXvj1p9Nm+FUUcCkMm+xY0B3sCYItdEs5NK5WE2UEGD7GRh Id6GI+Xqy09+KSyo8qJdJmmNvspkOdCvwQDdeZXOsN4n0L2/zRBoKD4I2cwHCYXTGScc Km97kvVE6UaqlCsjlogdmp/2wT1u3bFzfD+YvnFLDvDQvFsQAas/UWJqF8ANE8cBmy+p Tvbo6em3mB/oNoZRhy76++s+BdxC4BAEbknAO+L31ddPl3eUGKBkFVJ6/yHj+uAdlZ1h ATYQuSsIrB86H3rFd5hzHKd9KyMcH8p19WOxgczoVVa8FdK/+nr58nb+H6/SMlNemLjz SaYg== MIME-Version: 1.0 Received: by 10.220.153.80 with SMTP id j16mr7827958vcw.21.1355093676385; Sun, 09 Dec 2012 14:54:36 -0800 (PST) Received: by 10.58.117.234 with HTTP; Sun, 9 Dec 2012 14:54:36 -0800 (PST) In-Reply-To: <5A949C32AF740C4798AEECF2568F0D84217FC9@xmb-rcd-x13.cisco.com> References: <5A949C32AF740C4798AEECF2568F0D84217FC9@xmb-rcd-x13.cisco.com> Date: Sun, 9 Dec 2012 14:54:36 -0800 Message-ID: From: Andy Bierman To: "Muthumayan Madhayyan (muthu)" Content-Type: multipart/alternative; boundary=f46d043be15a37e64e04d0735556 X-Gm-Message-State: ALoCoQnwp6tEspQDyLqrEf9QLaSF3En68xfHLe5PItO+IXVDCvHKwNh0XR8tzcMJN230w1ztewzr Cc: "netmod@ietf.org" Subject: Re: [netmod] default NP container question X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 09 Dec 2012 22:54:38 -0000 --f46d043be15a37e64e04d0735556 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sun, Dec 9, 2012 at 10:16 AM, Muthumayan Madhayyan (muthu) < muthu@cisco.com> wrote: > > > From: Andy Bierman > Date: Sunday, December 9, 2012 9:23 AM > To: Muthumayan M > Cc: "netmod@ietf.org" > Subject: Re: [netmod] default NP container question > > Hi, > > NP containers are transparent in some ways. > Since they are just containment nodes, their child nodes > can impact their properties. A default leaf in an NP-container > causes the NP-container to be a default. > A mandatory child node causes the NP-container to be mandatory. > > > I was under the impression that the default settings and mandatory nodes > exist only if the immediate parent-node exists. > What happens if the parent node for the container is a list ? On what > basis would the server create a 'default list' ? > > Just an NP-container. Sec 7.5.7 has this text: A NETCONF server that replies to a or request MAY choose not to send a container element if the container node does not have the "presence" statement and no child nodes exist. Thus, a client that receives an for a or request, must be prepared to handle the case that a container node without a "presence" statement is not present in the XML. I cannot find any text that says the server MAY create NP containers. There is text that says an NP container carries no meaning in the data model. Andy > > Yuma doesn't actually handle default NP containers at all (just YumaPro)= . > After fixing the code, IMO the correct answer is that a create succeeds a= nd > a delete fails on a default NP-container. A delete on a real NP-container > can be immediately replaced by the server. I agree with Martin that it > is OK for the server to create NP containers and the client needs to chec= k > the with-defaults to use create/delete. The client can always use > merge/remove > instead and ignore defaults. > > Remember that with-defaults=3Dreport-all adds nodes in the reply that ar= e > missing > from the server -- these are the defaults in use because no node exists. > The server basic-mode for defaults handling determines if a node exists o= r > not. > > > Andy > > On Sun, Dec 9, 2012 at 8:51 AM, Muthumayan Madhayyan (muthu) < > muthu@cisco.com> wrote: > >> >> >> From: Andy Bierman >> Date: Wednesday, December 5, 2012 2:50 PM >> To: "netmod@ietf.org" >> Subject: [netmod] default NP container question >> >> Hi, >> >> I am not sure which RFC should or does say what to do: >> >> container npcon { >> leaf a { type int32; default 42; } >> leaf b { type string; } >> } >> >> >> I read this to mean that if the container npcon gets created, then the >> leaf 'a' is automatically created with value 42. If the leaf npcon/b ge= ts >> created, then both npcon and npcon/a are created. >> >> >> If you do a in normal mode, the 'npcon' container >> is not returned. >> >> >> This is fine. So, I presume there was never an attempt to create npcon= . >> >> >> If you do a with-defaults=3Dreport-all, the 'npcon' contai= ner >> is returned: >> >> npcon { >> a 42 >> } >> >> >> Is this correct ? Do we really need to return npcon/a when there was no >> attempt to create npcon in the first place ? >> >> >> So what happens if you do a create operation on /npcon? >> >> Is this OK or is it a 'data-exists' error? >> >> >> Shouldn't create on /npcon should be allowed ONLY for containers with >> 'presence' statement -OR=E2=80=93 if a container has immediate descendan= t leaf >> nodes with default values (like npcon), the container should automatical= ly >> become 'presence' containers ? Creation of the container then makes >> semantic sense, because creation of npcon automatically creates npcon/a= =3D42. >> >> >> What about a delete operation on /npcon? >> >> Is this OK or a 'data-missing' error? >> >> >> Deletion of /npcon can result in deletion of all descendant nodes and >> the container itself (like Martin had mentioned). >> >> >> Currently, yuma is doing something wrong -- returning both >> data-exists on a create and data-missing error on a delete. >> >> What are the correct responses? >> >> >> thanks, >> Andy >> >> > --f46d043be15a37e64e04d0735556 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Sun, Dec 9, 2012 at 10:16 AM, Muthuma= yan Madhayyan (muthu) <muthu@cisco.com> wrote:


From: Andy Bierman <andy@yumaworks.com>
Date: Sunday, December 9, 2012 9:23= AM
To: Muthumayan M <muthu@cisco.com>
Cc: "netmod@ietf.org" <netmod@ietf.org>
Subject: Re: [netmod] default NP co= ntainer question

Hi,

NP containers are transparent in some ways.
Since they are just containment nodes, their child nodes
can impact their properties. =C2=A0A default leaf in an NP-container
causes the NP-container to be a default.
A mandatory child node causes the NP-container to be mandatory.

I was under the impression that the default settings and mandatory nod= es exist only if the immediate parent-node exists.=C2=A0
What happens if the parent node for the container is a list ? =C2=A0On= what basis would the server create a =C2=A0'default list' ?


Just an NP-container.=

Sec 7.5.7 has this text:

A NETCONF server th= at replies to a <get> or <get-config> request MAY choose not to send a container element if the container node does not have the "presence" statement and no child nodes exist. Thus,= a client that receives an <rpc-reply> for a <get> or <get-c= onfig> request, must be prepared to handle the case that a container node=C2=A0 without a "presence" statement is not present in the XML.


I cannot find any text that says the se= rver MAY create NP containers.
There is text that says an NP cont= ainer carries no meaning in the data model.


Andy
=C2=A0

Yuma doesn't actually handle default NP containers at all (just Yu= maPro).
After fixing the code, IMO the correct answer is that a create succeed= s and
a delete fails on a default NP-container. A delete on a real NP-contai= ner
can be immediately replaced by the server. =C2=A0I agree with Martin t= hat it
is OK for the server to create NP containers and the client needs to c= heck
the with-defaults to use create/delete. =C2=A0The client can always us= e merge/remove
instead and ignore defaults.

Remember that with-defaults=3Dreport-all adds nodes in the reply that = are missing
from the server -- these are the defaults in use because no node exist= s.
The server basic-mode for defaults handling determines if a node exist= s or not.


Andy

On Sun, Dec 9, 2012 at 8:51 AM, Muthumayan Madha= yyan (muthu) <= muthu@cisco.com> wrote:


From: Andy Bierman <andy@yumaworks.com>
Date: Wednesday, December 5, 2012 2= :50 PM
To: "netmod@ietf.org" <netmod@ietf.org>
Subject: [netmod] default NP contai= ner question

Hi,

I am not sure which RFC should or does say what to do:

container npcon {
=C2=A0 =C2=A0leaf a { type int32; default 42; }
=C2=A0 =C2=A0leaf b { type string; }
}

I read this to mean that if the container npcon gets created, then the= leaf 'a' is automatically created with value 42. =C2=A0If the leaf= npcon/b gets created, then both npcon and npcon/a are created. =C2=A0


If you do a <get-config> in normal mode, the 'npcon' con= tainer
is not returned.

This is fine. =C2=A0So, I presume there was never an attempt to create= npcon.

If you do a <get-config> with-defaults=3Dreport-all, the 'np= con' container
is returned:

=C2=A0npcon {
=C2=A0 =C2=A0 a 42
=C2=A0}

Is this correct ? Do we really need to return npcon/a when there was n= o attempt to create npcon in the first place ?


So what happens if you do a create operation on /npcon?

Is this OK or is it a 'data-exists' error?

Shouldn't =C2=A0create on /npcon should be allowed ONLY for contai= ners with 'presence' statement -OR=E2=80=93 if a container has imme= diate descendant leaf nodes with default values (like npcon), the container= should automatically become =C2=A0'presence' containers ? =C2=A0Cr= eation of the container then makes semantic sense, because creation of npcon auto= matically creates npcon/a=3D42.


What about a delete operation on /npcon?

Is this OK or a 'data-missing' error?

Deletion of /npcon can result in deletion of all descendant nodes and = the container itself =C2=A0(like Martin had mentioned).


Currently, yuma is doing something wrong -- returning both
data-exists on a create and data-missing error on a delete.

What are the correct responses?


thanks,
Andy

--f46d043be15a37e64e04d0735556-- From mbj@tail-f.com Mon Dec 10 06:57:57 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32C5921F8500 for ; Mon, 10 Dec 2012 06:57:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.915 X-Spam-Level: X-Spam-Status: No, score=-0.915 tagged_above=-999 required=5 tests=[AWL=-0.728, BAYES_20=-0.74, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wbGIgjPXKu5o for ; Mon, 10 Dec 2012 06:57:56 -0800 (PST) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 8EB3321F8507 for ; Mon, 10 Dec 2012 06:57:56 -0800 (PST) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 6A44212008B7; Mon, 10 Dec 2012 15:57:54 +0100 (CET) Date: Mon, 10 Dec 2012 15:57:54 +0100 (CET) Message-Id: <20121210.155754.589804255154826193.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: References: <2105C80D-48CA-494B-A62A-8A1BA5919D42@nic.cz> <20121204.211903.458434883.mbj@tail-f.com> X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] IP addresses with zone indices X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 10 Dec 2012 14:57:57 -0000 Hi, Ladislav Lhotka wrote: > Martin Bjorklund writes: > >> > >> 1. For some IPv4 and IPv6 addresses we don't want to allow the zone-id part. > > > > This is currently a problem only for ip, and my intention is to solve > > it there. > > Hmm, I am hesitating about things like next-hop in the routing module, but I will probably leave it as it is, i.e. with the optional zone-id. > > > > >> 2. Some leafs ("netmask" in ip and "router-id" in routing) use the > >> "inet:ipv4-address" type but are no IP addresses, and cannot contain the > >> zone-id either. > >> > >> #1 can be solved by restricting the "inet:ipv[46]-address" with another > >> #pattern, though I am not happy with it. > > > > This is what I had in mind. > > > >> (Note, however, that there is now way to restrict the union type > >> "inet:ip-address" in order to get rid of the zone-id.) > >> > >> To solve #2, I propose to add the following typedef to the "ietf-ip" module, > >> which can be used for "ip:netmask", "rt:router-id", and later for OSPF Area ID > >> etc. > >> > >> typedef dotted-quad { > >> type string { > >> pattern > >> '(([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])\.){3}' > >> + '([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])'; > >> } > >> description > >> "An unsigned 32-bit number expressed in the dotted-quad > >> notation, i.e., four octets written as decimal numbers > >> and separated with the '.' (full stop) character. > >> > >> In the canonical format, leading zeros in all octets are > >> suppressed except for a zero octet which is written as '0' > >> (single digit zero). > >> "; > >> } > > > > This is not particularly elegant :( But this is what we have to do > > Actually, the second paragraph is unnecessary because the pattern > doesn't allow leading zeros. Ok. > > today. It would be nice to write: > > > > type uint32 { > > display-format "1d."; > > } > > I am not sure about this one, because we want the dotted quad format > to appear on the wire Yes, the idea was that it would affect the lexical value. lexical-format might be better. > > Anyway, I don't understand why such a type would belong to either > > ietf-ip or ietf-inet-types. > > Because then we can avoid having the same pattern in multiple > places. What's wrong on such a type? I think it is quite > comparable to types like "uint32" which also have no special > semantics. My point was that it is not clear why it would be defined in ietf-ip or ietf-inet. There is no ip or inet specific semantics associated with this type. ietf-yang would be a better place for it... But see below. > > For now, I think the quickest way forward is to solve this separately > > in each module. > > If you define the above type in ietf-ip, then I can reuse it - > ietf-routing already imports ietf-ip. Would this be any slower? Ok, I'd like to make progress, so I am prepared to define this type in ietf-ip, and use it for the netmask. /martin From lhotka@nic.cz Mon Dec 10 07:23:42 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F423921F84FA for ; Mon, 10 Dec 2012 07:23:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.255 X-Spam-Level: X-Spam-Status: No, score=-1.255 tagged_above=-999 required=5 tests=[AWL=-0.744, BAYES_05=-1.11, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5GexHJXnUVRg for ; Mon, 10 Dec 2012 07:23:41 -0800 (PST) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 6221621F843F for ; Mon, 10 Dec 2012 07:23:40 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 854BD54057F for ; Mon, 10 Dec 2012 16:23:31 +0100 (CET) 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 aCS9m0iPRS0K for ; Mon, 10 Dec 2012 16:23:21 +0100 (CET) Received: from localhost (unknown [10.107.191.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id C2C4F5402B7 for ; Mon, 10 Dec 2012 16:23:17 +0100 (CET) From: Ladislav Lhotka To: netmod@ietf.org In-Reply-To: <20121210.155754.589804255154826193.mbj@tail-f.com> References: <2105C80D-48CA-494B-A62A-8A1BA5919D42@nic.cz> <20121204.211903.458434883.mbj@tail-f.com> <20121210.155754.589804255154826193.mbj@tail-f.com> User-Agent: Notmuch/0.14+100~ge0adf10 (http://notmuchmail.org) Emacs/23.3.50.1 (i386-apple-darwin9.8.0) Mail-Followup-To: netmod@ietf.org Date: Mon, 10 Dec 2012 16:22:56 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [netmod] IP addresses with zone indices X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 10 Dec 2012 15:23:42 -0000 Martin Bjorklund writes: >> > Anyway, I don't understand why such a type would belong to either >> > ietf-ip or ietf-inet-types. >> >> Because then we can avoid having the same pattern in multiple >> places. What's wrong on such a type? I think it is quite >> comparable to types like "uint32" which also have no special >> semantics. > > My point was that it is not clear why it would be defined in ietf-ip > or ietf-inet. There is no ip or inet specific semantics associated > with this type. ietf-yang would be a better place for it... But see > below. I agree, such a type probably belongs to ietf-inet-types, but we can't afford a new downref to 6021bis now. The scenario could IMO look like this: 1. Define this type temporarily in ietf-ip and use where necessary; 2. Add it also to ietf-inet-types; 3. After 6021bis is published, change "ip:dotted-quad" to "inet:dotted-quad" in next revisions of ietf-ip, ietf-routing etc; 4. Obsolete "ip:dotted-quad". Could this work? > > >> > For now, I think the quickest way forward is to solve this separately >> > in each module. >> >> If you define the above type in ietf-ip, then I can reuse it - >> ietf-routing already imports ietf-ip. Would this be any slower? > > Ok, I'd like to make progress, so I am prepared to define this type in > ietf-ip, and use it for the netmask. Good, I'm going to use it for "router-id". Thanks, Lada > > > /martin -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From andy@yumaworks.com Mon Dec 10 08:34:58 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBC0A21F853D for ; Mon, 10 Dec 2012 08:34:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.532 X-Spam-Level: X-Spam-Status: No, score=-2.532 tagged_above=-999 required=5 tests=[AWL=-0.156, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aeh78XSrPnzg for ; Mon, 10 Dec 2012 08:34:58 -0800 (PST) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0B54F21F84FC for ; Mon, 10 Dec 2012 08:34:57 -0800 (PST) Received: by mail-vb0-f44.google.com with SMTP id fc26so2928138vbb.31 for ; Mon, 10 Dec 2012 08:34:57 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=Y32CZ7OmQYNBLOW3V6zX74tw4D9Vp5LdqkS3DihcN4E=; b=fGum9Sf+G+Gl1TPdTb9IaJ1ofDI4jdu01QZXIfuTHiRGtdEkx3fQAwsn8pluVO7anr AuiziBn7zeUZNDFsh0YG9G+ALv2znQJ4FASBQPG8VBpJHqJ3EJO7cUVCdAwNGrn0CJ+x EHOanN9PTo20xdaaMC1s6Qu8DkOKfZXNs4wXC6kjNS2OONcQObxouGMqImK/D2dZiy6v yAcGd6ExRa+pPZBJxXer4yCmDy1/61xZv7/G7coP729tKl9zSww+j1v9Z8dFtX9rGbFg vs7wXfr7P4s5tIEsi6m/0c4jAz9wAK773xfBw89jw3K+7slHL8YMS8D8WBZEnY1f0rRR 3iRw== MIME-Version: 1.0 Received: by 10.52.66.34 with SMTP id c2mr7992902vdt.62.1355157297327; Mon, 10 Dec 2012 08:34:57 -0800 (PST) Received: by 10.58.117.234 with HTTP; Mon, 10 Dec 2012 08:34:57 -0800 (PST) In-Reply-To: References: <2105C80D-48CA-494B-A62A-8A1BA5919D42@nic.cz> <20121204.211903.458434883.mbj@tail-f.com> <20121210.155754.589804255154826193.mbj@tail-f.com> Date: Mon, 10 Dec 2012 08:34:57 -0800 Message-ID: From: Andy Bierman To: netmod@ietf.org Content-Type: multipart/alternative; boundary=20cf307f35c2526f5f04d0822559 X-Gm-Message-State: ALoCoQl5Gs/ejMDtgL+LGH/GMtOuqndLYuqelpG7nijZNaxYodUzVkFVkRm4ctKwGf+9tFVVYm89 Subject: Re: [netmod] IP addresses with zone indices X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 10 Dec 2012 16:34:59 -0000 --20cf307f35c2526f5f04d0822559 Content-Type: text/plain; charset=UTF-8 On Mon, Dec 10, 2012 at 7:22 AM, Ladislav Lhotka wrote: > Martin Bjorklund writes: > > >> > Anyway, I don't understand why such a type would belong to either > >> > ietf-ip or ietf-inet-types. > >> > >> Because then we can avoid having the same pattern in multiple > >> places. What's wrong on such a type? I think it is quite > >> comparable to types like "uint32" which also have no special > >> semantics. > > > > My point was that it is not clear why it would be defined in ietf-ip > > or ietf-inet. There is no ip or inet specific semantics associated > > with this type. ietf-yang would be a better place for it... But see > > below. > > I agree, such a type probably belongs to ietf-inet-types, but we can't > afford a new downref to 6021bis now. The scenario could IMO look like this: > > 1. Define this type temporarily in ietf-ip and use where necessary; > 2. Add it also to ietf-inet-types; > 3. After 6021bis is published, change "ip:dotted-quad" to > "inet:dotted-quad" in next revisions of ietf-ip, ietf-routing etc; > 4. Obsolete "ip:dotted-quad". > > A: deploying standards is very expensive. Temporary fixes last 10 - 20 years around here. There is no such thing. Get it right the first time or pay the price for many years to come. B: There happens to be a 6021bis draft: http://www.ietf.org/id/draft-schoenw-netmod-rfc6021-bis-00.txt It adds 'hex-string' and 'uuid' to ietf-yang-types.yang. (A 'Changes Since RFC 6021' section would make that more clear.) There are many useful typedefs in the common-types.yang module in the proposed ACL draft. http://www.ietf.org/id/draft-huang-netmod-acl-01.txt I don't know how practical it is to re-open 6021 every time the WG thinks of a new typedef to add. But it seems easier than chartering and publishing new work, and it is better for YANG developers to keep the standard types in a lot of random modules. I don't agree with any of the 4 options above. I prefer: 5) work on 6021bis for a short time (1 - 2 months) and publish reusable data types only in 1 place (6021bis). Andy Could this work? > > > > > > >> > For now, I think the quickest way forward is to solve this separately > >> > in each module. > >> > >> If you define the above type in ietf-ip, then I can reuse it - > >> ietf-routing already imports ietf-ip. Would this be any slower? > > > > Ok, I'd like to make progress, so I am prepared to define this type in > > ietf-ip, and use it for the netmask. > > Good, I'm going to use it for "router-id". > > Thanks, Lada > > > > > > > /martin > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --20cf307f35c2526f5f04d0822559 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Mon, Dec 10, 2012 at 7:22 AM, Ladisla= v Lhotka <lhotka@nic.cz> wrote:
mbj@tail-f.com&g= t; writes:

>> > Anyway, I don't understand why such a type would belong t= o either
>> > ietf-ip or ietf-inet-types.
>>
>> Because then we can avoid having the same pattern in multiple
>> places. What's wrong on such a type? I think it is quite
>> comparable to types like "uint32" which also have no spe= cial
>> semantics.
>
> My point was that it is not clear why it would be defined in ietf-ip > or ietf-inet. =C2=A0There is no ip or inet specific semantics associat= ed
> with this type. =C2=A0ietf-yang would be a better place for it... =C2= =A0But see
> below.

I agree, such a type probably belongs to ietf-inet-types, but we can't = afford a new downref to 6021bis now. The scenario could IMO look like this:=

1. Define this type temporarily in ietf-ip and use where necessary;
2. Add it also to ietf-inet-types;
3. After 6021bis is published, change "ip:dotted-quad" to "i= net:dotted-quad" in next revisions of ietf-ip, ietf-routing etc;
4. Obsolete "ip:dotted-quad".



A: deploying standards = is very expensive. =C2=A0Temporary fixes last 10 - 20 years around here.
There is no such thing. =C2=A0Get it right the first time or pay th= e price for many years to come.

B: There happens to be a 6021bis draft:
It = adds 'hex-string' and 'uuid' to ietf-yang-types.yang.
(A 'Changes Since RFC 6021' section would make that more clear= .)

There are many useful typedefs in the common-ty= pes.yang module in
the proposed ACL draft.

I don't know how practical it is to re-open 6021 ev= ery time the WG thinks of
a new typedef to add. =C2=A0But it seem= s easier than chartering and publishing new work,
and it is bette= r for YANG developers to keep the standard types in a lot
of random modules.

I don't agree with any= of the 4 options above. I prefer:

5) work on 6021= bis for a short time (1 - 2 months) and
publish reusable data typ= es only in 1 place (6021bis).


Andy

Could this work?

>
>
>> > For now, I think the quickest way forward is to solve this se= parately
>> > in each module.
>>
>> If you define the above type in ietf-ip, then I can reuse it -
>> ietf-routing already imports ietf-ip. Would this be any slower? >
> Ok, I'd like to make progress, so I am prepared to define this typ= e in
> ietf-ip, and use it for the netmask.

Good, I'm going to use it for "router-id".

Thanks, Lada

>
>
> /martin

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

--20cf307f35c2526f5f04d0822559-- From lhotka@nic.cz Mon Dec 10 08:49:38 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4485521F850C for ; Mon, 10 Dec 2012 08:49:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.813 X-Spam-Level: X-Spam-Status: No, score=-1.813 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PdY7-0usE5Za for ; Mon, 10 Dec 2012 08:49:37 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 5C56621F850B for ; Mon, 10 Dec 2012 08:49:37 -0800 (PST) Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id B77F51402DC; Mon, 10 Dec 2012 17:49:26 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1355158166; bh=ZIEPR/1whxEW1eaor25wcdUClyNM8x1pmRcjJg9ewis=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=G1IgEI/VWyFrXNRwd+/4MiWuZEcFOQgn/2EwyrgPOgmtPeBUXl15gHr4A+w7CSPow nmjbWMiK5e3tS0pFz3qLT2Q7I+ggyjIY/ltbesloCz63xnxkCqa3nvEeWblwVCj0YT C/9qaIuvCnjsUyNs1V2iHn7JN2JB+f+9ysHiG82I= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ladislav Lhotka In-Reply-To: Date: Mon, 10 Dec 2012 17:49:26 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <38DD469B-1D72-4ABB-B695-3C40D2B410AD@nic.cz> References: <2105C80D-48CA-494B-A62A-8A1BA5919D42@nic.cz> <20121204.211903.458434883.mbj@tail-f.com> <20121210.155754.589804255154826193.mbj@tail-f.com> To: Andy Bierman X-Mailer: Apple Mail (2.1499) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] IP addresses with zone indices X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 10 Dec 2012 16:49:38 -0000 On Dec 10, 2012, at 5:34 PM, Andy Bierman wrote: >=20 >=20 > On Mon, Dec 10, 2012 at 7:22 AM, Ladislav Lhotka = wrote: > Martin Bjorklund writes: >=20 > >> > Anyway, I don't understand why such a type would belong to either > >> > ietf-ip or ietf-inet-types. > >> > >> Because then we can avoid having the same pattern in multiple > >> places. What's wrong on such a type? I think it is quite > >> comparable to types like "uint32" which also have no special > >> semantics. > > > > My point was that it is not clear why it would be defined in ietf-ip > > or ietf-inet. There is no ip or inet specific semantics associated > > with this type. ietf-yang would be a better place for it... But = see > > below. >=20 > I agree, such a type probably belongs to ietf-inet-types, but we can't = afford a new downref to 6021bis now. The scenario could IMO look like = this: >=20 > 1. Define this type temporarily in ietf-ip and use where necessary; > 2. Add it also to ietf-inet-types; > 3. After 6021bis is published, change "ip:dotted-quad" to = "inet:dotted-quad" in next revisions of ietf-ip, ietf-routing etc; > 4. Obsolete "ip:dotted-quad". >=20 >=20 >=20 > A: deploying standards is very expensive. Temporary fixes last 10 - = 20 years around here. > There is no such thing. Get it right the first time or pay the price = for many years to come. Well, "dotted-quad" could stay in ietf-ip for 10 years, no problem, = though the new status should be "deprecated" and not "obsolete". >=20 > B: There happens to be a 6021bis draft: > http://www.ietf.org/id/draft-schoenw-netmod-rfc6021-bis-00.txt > It adds 'hex-string' and 'uuid' to ietf-yang-types.yang. > (A 'Changes Since RFC 6021' section would make that more clear.) >=20 > There are many useful typedefs in the common-types.yang module in > the proposed ACL draft. > http://www.ietf.org/id/draft-huang-netmod-acl-01.txt >=20 > I don't know how practical it is to re-open 6021 every time the WG = thinks of > a new typedef to add. But it seems easier than chartering and = publishing new work, > and it is better for YANG developers to keep the standard types in a = lot > of random modules. >=20 > I don't agree with any of the 4 options above. I prefer: I didn't mean it as options but rather as a sequence of actions. >=20 > 5) work on 6021bis for a short time (1 - 2 months) and > publish reusable data types only in 1 place (6021bis). And I don't agree with this one. Your time estimate is ultra-optimistic. Lada >=20 >=20 > Andy >=20 > Could this work? >=20 > > > > > >> > For now, I think the quickest way forward is to solve this = separately > >> > in each module. > >> > >> If you define the above type in ietf-ip, then I can reuse it - > >> ietf-routing already imports ietf-ip. Would this be any slower? > > > > Ok, I'd like to make progress, so I am prepared to define this type = in > > ietf-ip, and use it for the netmask. >=20 > Good, I'm going to use it for "router-id". >=20 > Thanks, Lada >=20 > > > > > > /martin >=20 > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From j.schoenwaelder@jacobs-university.de Mon Dec 10 09:02:08 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B183B21F8235 for ; Mon, 10 Dec 2012 09:02:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.186 X-Spam-Level: X-Spam-Status: No, score=-103.186 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UYi+6mo--WJK for ; Mon, 10 Dec 2012 09:02:08 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 0CB3121F8201 for ; Mon, 10 Dec 2012 09:02:08 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3272020BFF; Mon, 10 Dec 2012 18:02:07 +0100 (CET) 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 LtR-OJLaDpOG; Mon, 10 Dec 2012 18:02:07 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id ACCE720C0E; Mon, 10 Dec 2012 18:02:06 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id E39C9235FDBA; Mon, 10 Dec 2012 18:02:13 +0100 (CET) Date: Mon, 10 Dec 2012 18:02:13 +0100 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20121210170213.GG49658@elstar.local> Mail-Followup-To: Andy Bierman , netmod@ietf.org References: <2105C80D-48CA-494B-A62A-8A1BA5919D42@nic.cz> <20121204.211903.458434883.mbj@tail-f.com> <20121210.155754.589804255154826193.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] IP addresses with zone indices 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, 10 Dec 2012 17:02:08 -0000 On Mon, Dec 10, 2012 at 08:34:57AM -0800, Andy Bierman wrote: > > A: deploying standards is very expensive. Temporary fixes last 10 - 20 > years around here. > There is no such thing. Get it right the first time or pay the price for > many years to come. > > B: There happens to be a 6021bis draft: > http://www.ietf.org/id/draft-schoenw-netmod-rfc6021-bis-00.txt > It adds 'hex-string' and 'uuid' to ietf-yang-types.yang. > (A 'Changes Since RFC 6021' section would make that more clear.) > > There are many useful typedefs in the common-types.yang module in > the proposed ACL draft. > http://www.ietf.org/id/draft-huang-netmod-acl-01.txt > > I don't know how practical it is to re-open 6021 every time the WG thinks of > a new typedef to add. But it seems easier than chartering and publishing > new work, > and it is better for YANG developers to keep the standard types in a lot > of random modules. > > I don't agree with any of the 4 options above. I prefer: > > 5) work on 6021bis for a short time (1 - 2 months) and > publish reusable data types only in 1 place (6021bis). The question is whether 1-2 months is realistic. It will likely be 6 months in the WG. The devil is in the details and some of the details tend to only pop up at WG last calls. So are we fine with having the IP and routing data models sitting in the RFC queue for whatever time it takes to revise, approve, publish 6021 (in my calculation this is more likely 6 months plus IESG processing plus RFC queue time, so 8-10 months)? /js PS: My record so far has been RFC 4789 which took about 6 months from initial I-D to RFC published. This was AD sponsored (no WG to reach concensus) and a topic most people find kind of esoteric. Hence I am questioning the 1-2 months unless we already limit the scope of additions to consider for 6021bis. -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From andy@yumaworks.com Mon Dec 10 09:14:36 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58B4D21F8521 for ; Mon, 10 Dec 2012 09:14:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.82 X-Spam-Level: X-Spam-Status: No, score=-2.82 tagged_above=-999 required=5 tests=[AWL=0.156, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NRalTqQDWPLu for ; Mon, 10 Dec 2012 09:14:35 -0800 (PST) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5140421F8527 for ; Mon, 10 Dec 2012 09:14:35 -0800 (PST) Received: by mail-vc0-f172.google.com with SMTP id fw7so2991264vcb.31 for ; Mon, 10 Dec 2012 09:14:30 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=tj51B2PK5hj7LxeGgmklcwSX+r0TH/juolDijTQA8h4=; b=icPZbWd4gb4Q3FioZCYhVM5Hw1kT42hV7gLRUzLDgwWC88R6Ss7Ug32FYSnSE3BwlA 2BaKpMhUmlDrgtpOf4BZ8RwwEN7soKcuNzWPmOX/yIwdM6fZJFLlfO4AzUHeAz/EWYF+ ixGHK9SaceaHsrUgmZl51Km8+uUVH5kIPT9bczljr8WLXAtJe7Cqc3GyLY+XmEWYf/jW 6C7NW8+6Qwev6J23l4Ss1uEUuINGKQBFZ/vUPsnL1x4I/jOEEHFamYKL+h2+5VidiOR7 lIh1Z7onrpquIpZgQI++wgzx5O0p+ttc7Jy490koH6GYCJxZo/TOT3wdbvTgCd5MgfG0 LRNQ== MIME-Version: 1.0 Received: by 10.52.66.34 with SMTP id c2mr8054577vdt.62.1355159670563; Mon, 10 Dec 2012 09:14:30 -0800 (PST) Received: by 10.58.117.234 with HTTP; Mon, 10 Dec 2012 09:14:30 -0800 (PST) In-Reply-To: <20121210170213.GG49658@elstar.local> References: <2105C80D-48CA-494B-A62A-8A1BA5919D42@nic.cz> <20121204.211903.458434883.mbj@tail-f.com> <20121210.155754.589804255154826193.mbj@tail-f.com> <20121210170213.GG49658@elstar.local> Date: Mon, 10 Dec 2012 09:14:30 -0800 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , Andy Bierman , netmod@ietf.org Content-Type: multipart/alternative; boundary=20cf307f35c2c7243204d082b29b X-Gm-Message-State: ALoCoQlewirWukzPKBM4WfnLHHELpqX5VQ6IwauiPijhRxdS+yL6v0bWKyBqFGmgXtH7PniZDZPu Subject: Re: [netmod] IP addresses with zone indices X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 10 Dec 2012 17:14:36 -0000 --20cf307f35c2c7243204d082b29b Content-Type: text/plain; charset=UTF-8 On Mon, Dec 10, 2012 at 9:02 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Mon, Dec 10, 2012 at 08:34:57AM -0800, Andy Bierman wrote: > > > > A: deploying standards is very expensive. Temporary fixes last 10 - 20 > > years around here. > > There is no such thing. Get it right the first time or pay the price for > > many years to come. > > > > B: There happens to be a 6021bis draft: > > http://www.ietf.org/id/draft-schoenw-netmod-rfc6021-bis-00.txt > > It adds 'hex-string' and 'uuid' to ietf-yang-types.yang. > > (A 'Changes Since RFC 6021' section would make that more clear.) > > > > There are many useful typedefs in the common-types.yang module in > > the proposed ACL draft. > > http://www.ietf.org/id/draft-huang-netmod-acl-01.txt > > > > I don't know how practical it is to re-open 6021 every time the WG > thinks of > > a new typedef to add. But it seems easier than chartering and publishing > > new work, > > and it is better for YANG developers to keep the standard types in a lot > > of random modules. > > > > I don't agree with any of the 4 options above. I prefer: > > > > 5) work on 6021bis for a short time (1 - 2 months) and > > publish reusable data types only in 1 place (6021bis). > > The question is whether 1-2 months is realistic. It will likely be 6 > months in the WG. The devil is in the details and some of the details > tend to only pop up at WG last calls. So are we fine with having the > IP and routing data models sitting in the RFC queue for whatever time > it takes to revise, approve, publish 6021 (in my calculation this is > more likely 6 months plus IESG processing plus RFC queue time, so 8-10 > months)? > > OK -- it is not realistic if common-types.yang is considered, although IMO that module has some very useful datatypes based on other standards (so it's either right or it's wrong, but it isn't purple vs. dark blue). Adding 3 or 4 types (and 2 are done already) better not take 6 months. That would indicate a major process failure by the WG and its chairs. It's the translation of a complex operational model into a data model that takes all the time. It 's the delay itself -- it promotes endless late comments and rewrites. We need to learn how to do a Code Sprint for I-Ds. /js > > Andy > PS: My record so far has been RFC 4789 which took about 6 months from > initial I-D to RFC published. This was AD sponsored (no WG to > reach concensus) and a topic most people find kind of esoteric. > Hence I am questioning the 1-2 months unless we already limit the > scope of additions to consider for 6021bis. > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > --20cf307f35c2c7243204d082b29b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Mon, Dec 10, 2012 at 9:02 AM, Juergen= Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Mon, Dec 10, 2012 at 08:34:57AM -0800, An= dy Bierman wrote:
>
> A: deploying standards is very expensive. =C2=A0Temporary fixes last 1= 0 - 20
> years around here.
> There is no such thing. =C2=A0Get it right the first time or pay the p= rice for
> many years to come.
>
> B: There happens to be a 6021bis draft:
> http://www.ietf.org/id/draft-schoenw-netmod-rfc6021-= bis-00.txt
> It adds 'hex-string' and 'uuid' to ietf-yang-types.yan= g.
> (A 'Changes Since RFC 6021' section would make that more clear= .)
>
> There are many useful typedefs in the common-types.yang module in
> the proposed ACL draft.
> http://www.ietf.org/id/draft-huang-netmod-acl-01.txt
>
> I don't know how practical it is to re-open 6021 every time the WG= thinks of
> a new typedef to add. =C2=A0But it seems easier than chartering and pu= blishing
> new work,
> and it is better for YANG developers to keep the standard types in a l= ot
> of random modules.
>
> I don't agree with any of the 4 options above. I prefer:
>
> 5) work on 6021bis for a short time (1 - 2 months) and
> publish reusable data types only in 1 place (6021bis).

The question is whether 1-2 months is realistic. It will likely be 6
months in the WG. The devil is in the details and some of the details
tend to only pop up at WG last calls. So are we fine with having the
IP and routing data models sitting in the RFC queue for whatever time
it takes to revise, approve, publish 6021 (in my calculation this is
more likely 6 months plus IESG processing plus RFC queue time, so 8-10
months)?


OK -- it is not realistic if common-ty= pes.yang is considered,
although IMO that module has some very us= eful datatypes
based on other standards (so it's either right= or it's wrong,
but it isn't purple vs. dark blue).=C2=A0

Adding 3 or 4 types (and 2 are done already) better not take 6 months.
That would indicate a major process failure by the WG and its chairs= .
It's the translation of a complex operational model into a data mo= del
that takes all the time. =C2=A0It 's the delay itself -- = it promotes endless
late comments and rewrites. =C2=A0We need to = learn how to do a Code Sprint
for I-Ds.


/js


Andy

=C2=A0
PS: My record so far has been RFC 4789 which took about 6 months from
=C2=A0 =C2=A0 initial I-D to RFC published. This was AD sponsored (no WG to=
=C2=A0 =C2=A0 reach concensus) and a topic most people find kind of esoteri= c.
=C2=A0 =C2=A0 Hence I am questioning the 1-2 months unless we already limit= the
=C2=A0 =C2=A0 scope of additions to consider for 6021bis.

--
Juergen Schoenwaelder =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Jacobs University = Bremen gGmbH
Phone: +49 421 200 3587 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Campus Ring 1, 28759 Br= emen, Germany
Fax: =C2=A0 +49 421 200 3103 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <http://www.jacobs-universi= ty.de/>

--20cf307f35c2c7243204d082b29b-- From lhotka@nic.cz Mon Dec 10 09:54:30 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0734921F857B for ; Mon, 10 Dec 2012 09:54:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.85 X-Spam-Level: X-Spam-Status: No, score=-1.85 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BaB+BlHFIFNq for ; Mon, 10 Dec 2012 09:54:29 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 289E321F8510 for ; Mon, 10 Dec 2012 09:54:28 -0800 (PST) Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id CB1771402DC; Mon, 10 Dec 2012 18:54:27 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1355162067; bh=kr8b20g8uPoYfUs6v4IOdEcPh0xwv6MfnZ+SP8D3wtk=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=vM5bWZR9m9/SUDHWdlk4raJAW6IVIkH8wN9jCOVYNE7UPIZCCjf7HCvRamgbAHnf7 EpRPA54EbD4Z9iAgJkseQLMtAgY5p9Y3brosAsmoymkLfXNrUwA69aWTMpDIQaf6Nz GM7iKxGOGBZYVOztP+uNp8jOkac/NvNaCxs3+BFE= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ladislav Lhotka In-Reply-To: Date: Mon, 10 Dec 2012 18:54:26 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <25D99809-7A95-4F8E-B013-09ACFE52232B@nic.cz> References: <2105C80D-48CA-494B-A62A-8A1BA5919D42@nic.cz> <20121204.211903.458434883.mbj@tail-f.com> <20121210.155754.589804255154826193.mbj@tail-f.com> <20121210170213.GG49658@elstar.local> To: Andy Bierman X-Mailer: Apple Mail (2.1499) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] IP addresses with zone indices X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 10 Dec 2012 17:54:30 -0000 On Dec 10, 2012, at 6:14 PM, Andy Bierman wrote: >=20 >=20 > On Mon, Dec 10, 2012 at 9:02 AM, Juergen Schoenwaelder = wrote: > On Mon, Dec 10, 2012 at 08:34:57AM -0800, Andy Bierman wrote: > > > > A: deploying standards is very expensive. Temporary fixes last 10 - = 20 > > years around here. > > There is no such thing. Get it right the first time or pay the = price for > > many years to come. > > > > B: There happens to be a 6021bis draft: > > http://www.ietf.org/id/draft-schoenw-netmod-rfc6021-bis-00.txt > > It adds 'hex-string' and 'uuid' to ietf-yang-types.yang. > > (A 'Changes Since RFC 6021' section would make that more clear.) > > > > There are many useful typedefs in the common-types.yang module in > > the proposed ACL draft. > > http://www.ietf.org/id/draft-huang-netmod-acl-01.txt > > > > I don't know how practical it is to re-open 6021 every time the WG = thinks of > > a new typedef to add. But it seems easier than chartering and = publishing > > new work, > > and it is better for YANG developers to keep the standard types in a = lot > > of random modules. > > > > I don't agree with any of the 4 options above. I prefer: > > > > 5) work on 6021bis for a short time (1 - 2 months) and > > publish reusable data types only in 1 place (6021bis). >=20 > The question is whether 1-2 months is realistic. It will likely be 6 > months in the WG. The devil is in the details and some of the details > tend to only pop up at WG last calls. So are we fine with having the > IP and routing data models sitting in the RFC queue for whatever time > it takes to revise, approve, publish 6021 (in my calculation this is > more likely 6 months plus IESG processing plus RFC queue time, so 8-10 > months)? >=20 >=20 > OK -- it is not realistic if common-types.yang is considered, > although IMO that module has some very useful datatypes > based on other standards (so it's either right or it's wrong, > but it isn't purple vs. dark blue).=20 >=20 > Adding 3 or 4 types (and 2 are done already) better not take 6 months. > That would indicate a major process failure by the WG and its chairs. > It's the translation of a complex operational model into a data model > that takes all the time. It 's the delay itself -- it promotes = endless > late comments and rewrites. We need to learn how to do a Code Sprint > for I-Ds. The need for new types arises (naturally) during module development, = often quite late in the process, so I think the only option in most = cases is to define the type right in the module which needs it. If such a type is found applicable in other modules, it might be useful = to move it later to a type library. We need to figure out a reliable = procedure for performing this migration, within the existing constraints = of the IETF workflow. This procedure must not put ongoing development of = modules on hold.=20 Lada=20 >=20 >=20 > /js >=20 >=20 > Andy >=20 > =20 > PS: My record so far has been RFC 4789 which took about 6 months from > initial I-D to RFC published. This was AD sponsored (no WG to > reach concensus) and a topic most people find kind of esoteric. > Hence I am questioning the 1-2 months unless we already limit the > scope of additions to consider for 6021bis. >=20 > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From j.schoenwaelder@jacobs-university.de Mon Dec 10 11:19:00 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E02A121F8608 for ; Mon, 10 Dec 2012 11:19:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.19 X-Spam-Level: X-Spam-Status: No, score=-103.19 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AeU-8HK-VCQG for ; Mon, 10 Dec 2012 11:19:00 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 3835521F85AA for ; Mon, 10 Dec 2012 11:19:00 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6B87620BEC; Mon, 10 Dec 2012 20:18:59 +0100 (CET) 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 9B2fO4_k_cNL; Mon, 10 Dec 2012 20:18:59 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id F0C6320BE1; Mon, 10 Dec 2012 20:18:58 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id BA9582360254; Mon, 10 Dec 2012 20:19:07 +0100 (CET) Date: Mon, 10 Dec 2012 20:19:07 +0100 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20121210191906.GB50035@elstar.local> Mail-Followup-To: Andy Bierman , netmod@ietf.org References: <2105C80D-48CA-494B-A62A-8A1BA5919D42@nic.cz> <20121204.211903.458434883.mbj@tail-f.com> <20121210.155754.589804255154826193.mbj@tail-f.com> <20121210170213.GG49658@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] IP addresses with zone indices 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, 10 Dec 2012 19:19:01 -0000 On Mon, Dec 10, 2012 at 09:14:30AM -0800, Andy Bierman wrote: > Adding 3 or 4 types (and 2 are done already) better not take 6 months. > That would indicate a major process failure by the WG and its chairs. I heard you talking about more than 2 types. I probably mis-understood your email. As I stated in my email, the question is how you scope 6021bis work. If we open up 6021 for general additions, I continue to believe that my estimation is more realistic than yours (but I might be equally well just a failing WG co-chair). /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 Dec 10 11:29:26 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 364C421F860A for ; Mon, 10 Dec 2012 11:29:26 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rfyi1CR68tVZ for ; Mon, 10 Dec 2012 11:29:25 -0800 (PST) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id A5B4521F8608 for ; Mon, 10 Dec 2012 11:29:25 -0800 (PST) Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id A56641200D10; Mon, 10 Dec 2012 20:29:24 +0100 (CET) Date: Mon, 10 Dec 2012 20:29:24 +0100 (CET) Message-Id: <20121210.202924.394214026.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20121210191906.GB50035@elstar.local> References: <20121210170213.GG49658@elstar.local> <20121210191906.GB50035@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] IP addresses with zone indices X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 10 Dec 2012 19:29:26 -0000 Juergen Schoenwaelder wrote: > On Mon, Dec 10, 2012 at 09:14:30AM -0800, Andy Bierman wrote: > > > Adding 3 or 4 types (and 2 are done already) better not take 6 months. > > That would indicate a major process failure by the WG and its chairs. > > I heard you talking about more than 2 types. I probably mis-understood > your email. As I stated in my email, the question is how you scope > 6021bis work. If we open up 6021 for general additions, I continue to > believe that my estimation is more realistic than yours (but I might > be equally well just a failing WG co-chair). I am not convinced that dotted-quad is such a common type that we should include it in 6021bis. (I also do not think that the ip/tcp-packet-specific types from the acl draft should be included in 6021bis.) /martin From andy@yumaworks.com Mon Dec 10 11:40:27 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACC0121F85E0 for ; Mon, 10 Dec 2012 11:40:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.531 X-Spam-Level: X-Spam-Status: No, score=-2.531 tagged_above=-999 required=5 tests=[AWL=-0.155, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gNuoWx49E0fU for ; Mon, 10 Dec 2012 11:40:27 -0800 (PST) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id DEC6F21F8576 for ; Mon, 10 Dec 2012 11:40:26 -0800 (PST) Received: by mail-vb0-f44.google.com with SMTP id fc26so3127701vbb.31 for ; Mon, 10 Dec 2012 11:40:26 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=TEK9GGZy2PhPisKur4gyn8EuKNxuf18gkEA+//4thVA=; b=Q6YZgWFXqjx8VaGbbPbz1cyGDwYU84O2dzqBfW7+oECpbMbfGtiUUzLic/WnuZgobC WmA1bIK0TOGRy89900lNdwlxFFDdru9P/PQPff7X/bF0gUQKGOVYxRZpLLwQ8wtn5ta2 EONOY0ftzBkdUwGyaNhkK/f1M0XSI4G/iuXKp3lCi8JIb546WVWmE5N7/skKsra/Iz5C DJbfxTB85j88fAhasR6rxn/6cqi/XGwvwgqVzptCH2l0VJzxczvaqisXYZ70hZUT0OQA 08TebQ1PyS/cyCKRKuOdKXjuVOkDZkgp43KZTNW0LPDttGdIbys0kYCgEtKuahgOYLOj oKVw== MIME-Version: 1.0 Received: by 10.52.67.133 with SMTP id n5mr8385742vdt.24.1355168426178; Mon, 10 Dec 2012 11:40:26 -0800 (PST) Received: by 10.58.117.234 with HTTP; Mon, 10 Dec 2012 11:40:26 -0800 (PST) In-Reply-To: <20121210191906.GB50035@elstar.local> References: <2105C80D-48CA-494B-A62A-8A1BA5919D42@nic.cz> <20121204.211903.458434883.mbj@tail-f.com> <20121210.155754.589804255154826193.mbj@tail-f.com> <20121210170213.GG49658@elstar.local> <20121210191906.GB50035@elstar.local> Date: Mon, 10 Dec 2012 11:40:26 -0800 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , Andy Bierman , netmod@ietf.org Content-Type: multipart/alternative; boundary=20cf307f397ca736f604d084bc40 X-Gm-Message-State: ALoCoQkU6y5xHQOPPXGjtirgmcQJS9rG2muN/bETYJhvpVec9nrThBqAtHpnPCxI/YpVFaamJS+2 Subject: Re: [netmod] IP addresses with zone indices X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 10 Dec 2012 19:40:27 -0000 --20cf307f397ca736f604d084bc40 Content-Type: text/plain; charset=UTF-8 On Mon, Dec 10, 2012 at 11:19 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Mon, Dec 10, 2012 at 09:14:30AM -0800, Andy Bierman wrote: > > > Adding 3 or 4 types (and 2 are done already) better not take 6 months. > > That would indicate a major process failure by the WG and its chairs. > > I heard you talking about more than 2 types. I probably mis-understood > your email. As I stated in my email, the question is how you scope > 6021bis work. If we open up 6021 for general additions, I continue to > believe that my estimation is more realistic than yours (but I might > be equally well just a failing WG co-chair). > > No -- I think documents are waiting their turn in the NETMOD queue, and highest priority is finishing the current documents. I don't think moving typedefs from 1 module to 6021bis will work. We will never find it more efficient to re-open 6021bis than just publish new typedefs in the current work. But we can establish some conventions instead. IMO it would help to publish the reusable typedefs in a separate module (e.g., publishing foo.yang, then split reusable typedefs into foo-types.yang). This will make conformance more clear, and make it easier for YANG authors to find the datatypes that are intended for reuse. > /js > Andy --20cf307f397ca736f604d084bc40 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Mon, Dec 10, 2012 at 11:19 AM, Juerge= n Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Mon, Dec 10, 2012 at 09:14:30AM -0800, An= dy Bierman wrote:

> Adding 3 or 4 types (and 2 are done already) better not take 6 months.=
> That would indicate a major process failure by the WG and its chairs.<= br>
I heard you talking about more than 2 types. I probably mis-understood
your email. As I stated in my email, the question is how you scope
6021bis work. If we open up 6021 for general additions, I continue to
believe that my estimation is more realistic than yours (but I might
be equally well just a failing WG co-chair).


No -- I =C2=A0think documents are waiting their turn= in the NETMOD queue,
and highest priority is finishing the curre= nt documents.
I don't think moving typedefs from 1 module to 6021bis will work.<= /div>

We will never find it more efficient to re-open 60= 21bis than
just publish new typedefs in the current work. =C2=A0B= ut we can
establish some conventions instead.

IMO it wo= uld help to publish the reusable typedefs in a separate module
(e= .g., publishing foo.yang, then split reusable typedefs into foo-types.yang)= .
This will make conformance more clear, and make it easier for
YANG authors to find the datatypes that are intended for reuse.

/js


--20cf307f397ca736f604d084bc40-- From mbj@tail-f.com Mon Dec 10 12:04:40 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AD4321F865B for ; Mon, 10 Dec 2012 12:04:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.746 X-Spam-Level: X-Spam-Status: No, score=-0.746 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9uuZQgiFH2LT for ; Mon, 10 Dec 2012 12:04:39 -0800 (PST) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id BBD8D21F8653 for ; Mon, 10 Dec 2012 12:04:39 -0800 (PST) Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id A547C12008B7 for ; Mon, 10 Dec 2012 21:04:38 +0100 (CET) Date: Mon, 10 Dec 2012 21:04:38 +0100 (CET) Message-Id: <20121210.210438.342222070.mbj@tail-f.com> To: netmod@ietf.org From: Martin Bjorklund X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [netmod] ietf-ip open issue X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2012 20:04:40 -0000 Hi, One WGLC comment was if the prefix-length really should have a default value (32 resp. 128). There are two options: 1. Keep the defaults 2. Make prefix-length mandatory I think I agree with Lada that we should do (2). The current defaults are not so common that it saves lots of config to use the default values. Comments? /martin From j.schoenwaelder@jacobs-university.de Mon Dec 10 12:08:56 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B35A21F866D for ; Mon, 10 Dec 2012 12:08:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.193 X-Spam-Level: X-Spam-Status: No, score=-103.193 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k5JdvHm49Z+1 for ; Mon, 10 Dec 2012 12:08:51 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 1776521F8653 for ; Mon, 10 Dec 2012 12:08:51 -0800 (PST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6A91020BF6; Mon, 10 Dec 2012 21:08:50 +0100 (CET) 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 gBkd-8kuABdB; Mon, 10 Dec 2012 21:08:50 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0347320BF3; Mon, 10 Dec 2012 21:08:50 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 99A6B23606F2; Mon, 10 Dec 2012 21:08:57 +0100 (CET) Date: Mon, 10 Dec 2012 21:08:56 +0100 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20121210200855.GA50491@elstar.local> Mail-Followup-To: Martin Bjorklund , netmod@ietf.org References: <20121210.210438.342222070.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20121210.210438.342222070.mbj@tail-f.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] ietf-ip open issue X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2012 20:08:56 -0000 On Mon, Dec 10, 2012 at 09:04:38PM +0100, Martin Bjorklund wrote: > Hi, > > One WGLC comment was if the prefix-length really should have a default > value (32 resp. 128). There are two options: > > 1. Keep the defaults > > 2. Make prefix-length mandatory > > > I think I agree with Lada that we should do (2). The current defaults > are not so common that it saves lots of config to use the default > values. Comments? I generally agree with the direction. But how would this work for IPv4 where we have either a prefix-length or a netmask? /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 Dec 10 13:18:25 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D770E21F867B for ; Mon, 10 Dec 2012 13:18:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.884 X-Spam-Level: X-Spam-Status: No, score=-1.884 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OQdTM33crxA0 for ; Mon, 10 Dec 2012 13:18:25 -0800 (PST) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 3F98F21F867A for ; Mon, 10 Dec 2012 13:18:25 -0800 (PST) Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 1636712008B7; Mon, 10 Dec 2012 22:18:24 +0100 (CET) Date: Mon, 10 Dec 2012 22:18:23 +0100 (CET) Message-Id: <20121210.221823.456701977.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20121210200855.GA50491@elstar.local> References: <20121210.210438.342222070.mbj@tail-f.com> <20121210200855.GA50491@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] ietf-ip open issue X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2012 21:18:26 -0000 Juergen Schoenwaelder wrote: > On Mon, Dec 10, 2012 at 09:04:38PM +0100, Martin Bjorklund wrote: > > Hi, > > > > One WGLC comment was if the prefix-length really should have a default > > value (32 resp. 128). There are two options: > > > > 1. Keep the defaults > > > > 2. Make prefix-length mandatory > > > > > > I think I agree with Lada that we should do (2). The current defaults > > are not so common that it saves lots of config to use the default > > values. Comments? > > I generally agree with the direction. But how would this work for IPv4 > where we have either a prefix-length or a netmask? It actually works fine: choice subnet { mandatory true; ... leaf prefix-length { ... } leaf netmask { if-feature ipv4-non-contiguous-netmasks; ... } } /martin From lhotka@nic.cz Tue Dec 11 01:17:17 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A83021F84B2 for ; Tue, 11 Dec 2012 01:17:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.875 X-Spam-Level: X-Spam-Status: No, score=-1.875 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DAE05BvpW9fP for ; Tue, 11 Dec 2012 01:17:16 -0800 (PST) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 3FC8B21F85D2 for ; Tue, 11 Dec 2012 01:17:16 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id D95FC54072B for ; Tue, 11 Dec 2012 10:17:14 +0100 (CET) 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 k0Ep0C8q6k9l for ; Tue, 11 Dec 2012 10:17:09 +0100 (CET) Received: from localhost (unknown [10.107.191.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 7FCC95402A1 for ; Tue, 11 Dec 2012 10:17:05 +0100 (CET) From: Ladislav Lhotka To: netmod@ietf.org In-Reply-To: <20121210.202924.394214026.mbj@tail-f.com> References: <20121210170213.GG49658@elstar.local> <20121210191906.GB50035@elstar.local> <20121210.202924.394214026.mbj@tail-f.com> User-Agent: Notmuch/0.14+100~ge0adf10 (http://notmuchmail.org) Emacs/23.3.50.1 (i386-apple-darwin9.8.0) Mail-Followup-To: netmod@ietf.org Date: Tue, 11 Dec 2012 10:16:47 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [netmod] IP addresses with zone indices X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 11 Dec 2012 09:17:17 -0000 Martin Bjorklund writes: > Juergen Schoenwaelder wrote: >> On Mon, Dec 10, 2012 at 09:14:30AM -0800, Andy Bierman wrote: >> >> > Adding 3 or 4 types (and 2 are done already) better not take 6 months. >> > That would indicate a major process failure by the WG and its chairs. >> >> I heard you talking about more than 2 types. I probably mis-understood >> your email. As I stated in my email, the question is how you scope >> 6021bis work. If we open up 6021 for general additions, I continue to >> believe that my estimation is more realistic than yours (but I might >> be equally well just a failing WG co-chair). > > I am not convinced that dotted-quad is such a common type that we > should include it in 6021bis. It is currently supposed to be used in at least three different modules. I don't know what's the alternative - let each module define its own version? Lada > > (I also do not think that the ip/tcp-packet-specific types from the acl > draft should be included in 6021bis.) > > > /martin > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From j.schoenwaelder@jacobs-university.de Tue Dec 11 01:40:37 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 291CE21F8784 for ; Tue, 11 Dec 2012 01:40:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.196 X-Spam-Level: X-Spam-Status: No, score=-103.196 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U-KD9M5JAXX6 for ; Tue, 11 Dec 2012 01:40:36 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 57F4721F8782 for ; Tue, 11 Dec 2012 01:40:36 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 49C8520BEF; Tue, 11 Dec 2012 10:40:35 +0100 (CET) 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 jF_RUsF_Zo77; Tue, 11 Dec 2012 10:40:35 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id DB9F420BE9; Tue, 11 Dec 2012 10:40:34 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id B96B42362126; Tue, 11 Dec 2012 10:40:43 +0100 (CET) Date: Tue, 11 Dec 2012 10:40:43 +0100 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20121211094043.GA52035@elstar.local> Mail-Followup-To: netmod@ietf.org References: <20121210170213.GG49658@elstar.local> <20121210191906.GB50035@elstar.local> <20121210.202924.394214026.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) Subject: Re: [netmod] IP addresses with zone indices 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, 11 Dec 2012 09:40:37 -0000 On Tue, Dec 11, 2012 at 10:16:47AM +0100, Ladislav Lhotka wrote: > Martin Bjorklund writes: > > > Juergen Schoenwaelder wrote: > >> On Mon, Dec 10, 2012 at 09:14:30AM -0800, Andy Bierman wrote: > >> > >> > Adding 3 or 4 types (and 2 are done already) better not take 6 months. > >> > That would indicate a major process failure by the WG and its chairs. > >> > >> I heard you talking about more than 2 types. I probably mis-understood > >> your email. As I stated in my email, the question is how you scope > >> 6021bis work. If we open up 6021 for general additions, I continue to > >> believe that my estimation is more realistic than yours (but I might > >> be equally well just a failing WG co-chair). > > > > I am not convinced that dotted-quad is such a common type that we > > should include it in 6021bis. > > It is currently supposed to be used in at least three different modules. I don't know what's the alternative - let each module define its own version? > Speaking as 6021bis editor: A type that is used by multiple data models without being highly technology specific or modeling something controlled by IANA is a decent candidate for inclusion in 6021bis. I do not see a problem to add a dotted quad type to ietf-yang-types, probably with some additional text that for IPv4 addresses, the specific type provided by the ietf-inet-types module must be used. /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 Dec 11 01:48:13 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8225421F850B for ; Tue, 11 Dec 2012 01:48:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.916 X-Spam-Level: X-Spam-Status: No, score=-1.916 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N5Hrdf0md6eR for ; Tue, 11 Dec 2012 01:48:12 -0800 (PST) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 89D2121F84F3 for ; Tue, 11 Dec 2012 01:48:12 -0800 (PST) Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 36A341200AC8; Tue, 11 Dec 2012 10:48:10 +0100 (CET) Date: Tue, 11 Dec 2012 10:48:09 +0100 (CET) Message-Id: <20121211.104809.396474807.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20121211094043.GA52035@elstar.local> References: <20121210.202924.394214026.mbj@tail-f.com> <20121211094043.GA52035@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] IP addresses with zone indices X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 11 Dec 2012 09:48:13 -0000 Juergen Schoenwaelder wrote: > Speaking as 6021bis editor: A type that is used by multiple data > models without being highly technology specific or modeling something > controlled by IANA is a decent candidate for inclusion in 6021bis. I > do not see a problem to add a dotted quad type to ietf-yang-types, > probably with some additional text that for IPv4 addresses, the > specific type provided by the ietf-inet-types module must be used. So, one thing we said about 6021 was something along the lines "it is easy to add new types". We just have three new types 'hex-string', 'uuid' and 'dotted-quad'. Why don't we try to do this quickly and a WGLC on 6021bis "now", and send all five document to the IESG at the same time. If this process works, it means we don't have to argue to death about even more new types to add - we can add them just as quickly at a later time instead! /martin From j.schoenwaelder@jacobs-university.de Tue Dec 11 02:30:35 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE5B721F86BE for ; Tue, 11 Dec 2012 02:30:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.199 X-Spam-Level: X-Spam-Status: No, score=-103.199 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ge9hWrcxtE6Y for ; Tue, 11 Dec 2012 02:30:35 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id B658621F8625 for ; Tue, 11 Dec 2012 02:30:34 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id C767620BF5; Tue, 11 Dec 2012 11:30:33 +0100 (CET) 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 kjFtsoUbC5bP; Tue, 11 Dec 2012 11:30:33 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 33A7920BCD; Tue, 11 Dec 2012 11:30:33 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id E23F32362302; Tue, 11 Dec 2012 11:30:41 +0100 (CET) Date: Tue, 11 Dec 2012 11:30:41 +0100 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20121211103041.GA52155@elstar.local> Mail-Followup-To: Martin Bjorklund , netmod@ietf.org References: <20121210.202924.394214026.mbj@tail-f.com> <20121211094043.GA52035@elstar.local> <20121211.104809.396474807.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20121211.104809.396474807.mbj@tail-f.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] IP addresses with zone indices 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, 11 Dec 2012 10:30:35 -0000 On Tue, Dec 11, 2012 at 10:48:09AM +0100, Martin Bjorklund wrote: > Juergen Schoenwaelder wrote: > > Speaking as 6021bis editor: A type that is used by multiple data > > models without being highly technology specific or modeling something > > controlled by IANA is a decent candidate for inclusion in 6021bis. I > > do not see a problem to add a dotted quad type to ietf-yang-types, > > probably with some additional text that for IPv4 addresses, the > > specific type provided by the ietf-inet-types module must be used. > > So, one thing we said about 6021 was something along the lines "it is > easy to add new types". > > We just have three new types 'hex-string', 'uuid' and 'dotted-quad'. > > Why don't we try to do this quickly and a WGLC on 6021bis "now", and > send all five document to the IESG at the same time. > > If this process works, it means we don't have to argue to death about > even more new types to add - we can add them just as quickly at a > later time instead! There were previously some suggestions. Here is my (likely incomplete) list of things: * DONE hex-string * DONE uuid * TODO dotted-quad * TODO ipv4-address-with-prefix, ipv6-address-with-prefix, ip-address-with-prefix So far, it seems noneof our current modules needs this sincewe keep the prefix length separated fromthe ip address.So I amnot sure what to do aboutit, probably keep it pending. * TODO yang-identifier I noticed in ietf-netconf-acm.yang that leafs such as "module-name" "rpc-name", and "notification-name" are used to represent YANG identifiers, but the data type is plain "string". IMO, this is not correct. The string should be constrained to only valid YANG identifiers, which chould be a standard typedef. I think the ietf-yang-types module needs to be updated with a typedef for yang-identifier. E.g.: typedef yang-identifier { type string { length "1..max"; pattern '[a-z,A-Z,_][a-z,A-Z,0-9,\-,_,\.]*'; } description "YANG identifier string"; // An identifier MUST NOT start with (('X'|'x') ('M'|'m') ('L'|'l')) // identifier = (ALPHA / "_") *(ALPHA / DIGIT / "_" / "-" / ".") reference "RFC 6020, page 163"; } Does anybody know how to write a regex pattern for the must not start with "xml" requirement that is not in the ABNF? * TODO yang types for ip multicast addresses See post by Markus Rothmann, not sure what to do about it. * TODO any yang types to lift from the ACL module? One option to try to run such a process fast is to run it by hard deadlines. That is, we make a call for additions and people need to propose additions with close to complete writeups of the typedefs proposed. For each proposal a separate email thread is created. 2-3 weeks should be enough for proposals to come in. We then work through the list, seeing which clarifications are needed and on which typedefs we reach concensus. Discussions are cut after another 2-3 weeks, typedefs not reaching concensus by then will not be considered for this update. By end of January, we have an I-D to be WG last called. /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 Dec 11 02:44:27 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B02FE21F87FA for ; Tue, 11 Dec 2012 02:44:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.928 X-Spam-Level: X-Spam-Status: No, score=-1.928 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gGvnP90YRutB for ; Tue, 11 Dec 2012 02:44:27 -0800 (PST) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id A03AC21F8528 for ; Tue, 11 Dec 2012 02:44:26 -0800 (PST) Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id A68F61200D10; Tue, 11 Dec 2012 11:44:25 +0100 (CET) Date: Tue, 11 Dec 2012 11:44:25 +0100 (CET) Message-Id: <20121211.114425.307660122.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20121211103041.GA52155@elstar.local> References: <20121211094043.GA52035@elstar.local> <20121211.104809.396474807.mbj@tail-f.com> <20121211103041.GA52155@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] IP addresses with zone indices X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 11 Dec 2012 10:44:27 -0000 Juergen Schoenwaelder wrote: > On Tue, Dec 11, 2012 at 10:48:09AM +0100, Martin Bjorklund wrote: > > Juergen Schoenwaelder wrote: > > > Speaking as 6021bis editor: A type that is used by multiple data > > > models without being highly technology specific or modeling something > > > controlled by IANA is a decent candidate for inclusion in 6021bis. I > > > do not see a problem to add a dotted quad type to ietf-yang-types, > > > probably with some additional text that for IPv4 addresses, the > > > specific type provided by the ietf-inet-types module must be used. > > > > So, one thing we said about 6021 was something along the lines "it is > > easy to add new types". > > > > We just have three new types 'hex-string', 'uuid' and 'dotted-quad'. > > > > Why don't we try to do this quickly and a WGLC on 6021bis "now", and > > send all five document to the IESG at the same time. > > > > If this process works, it means we don't have to argue to death about > > even more new types to add - we can add them just as quickly at a > > later time instead! > > There were previously some suggestions. Here is my (likely incomplete) > list of things: > > * DONE hex-string > > * DONE uuid > > * TODO dotted-quad > > * TODO ipv4-address-with-prefix, ipv6-address-with-prefix, > ip-address-with-prefix > > So far, it seems noneof our current modules needs this sincewe > keep the prefix length separated fromthe ip address.So I amnot > sure what to do aboutit, probably keep it pending. I know that people define their own type for this one all the time, but IMO, these are really two different leafs and they should be modelled as such. If we do this, why not also do :, ... it is a slippery slope. > * TODO yang-identifier > > I noticed in ietf-netconf-acm.yang that leafs such as "module-name" > "rpc-name", and "notification-name" are used to represent YANG > identifiers, but the data type is plain "string". IMO, this is not > correct. The string should be constrained to only valid YANG > identifiers, which chould be a standard typedef. > > I think the ietf-yang-types module needs to be updated with a typedef > for yang-identifier. E.g.: > > typedef yang-identifier { > type string { > length "1..max"; > pattern '[a-z,A-Z,_][a-z,A-Z,0-9,\-,_,\.]*'; > } > description > "YANG identifier string"; > // An identifier MUST NOT start with (('X'|'x') ('M'|'m') ('L'|'l')) > // identifier = (ALPHA / "_") *(ALPHA / DIGIT / "_" / "-" / ".") > reference "RFC 6020, page 163"; > } Ok. This should be non-controversial. > Does anybody know how to write a regex pattern for the must not start > with "xml" requirement that is not in the ABNF? > > * TODO yang types for ip multicast addresses > > See post by Markus Rothmann, not sure what to do about it. Keep them pending. > * TODO any yang types to lift from the ACL module? IMO no. Maybe vlan id, but we had that one early on and remvoed it. > One option to try to run such a process fast is to run it by hard > deadlines. I like this idea. > That is, we make a call for additions and people need to > propose additions with close to complete writeups of the typedefs > proposed. For each proposal a separate email thread is created. 2-3 > weeks should be enough for proposals to come in. We then work through > the list, seeing which clarifications are needed and on which typedefs > we reach concensus. Discussions are cut after another 2-3 weeks, > typedefs not reaching concensus by then will not be considered for > this update. By end of January, we have an I-D to be WG last called. /martin From lhotka@nic.cz Tue Dec 11 05:15:58 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73D4121F8784 for ; Tue, 11 Dec 2012 05:15:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.441 X-Spam-Level: X-Spam-Status: No, score=-1.441 tagged_above=-999 required=5 tests=[AWL=-0.346, BAYES_00=-2.599, HOST_EQ_CZ=0.904, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id paTqEB2Blv6t for ; Tue, 11 Dec 2012 05:15:57 -0800 (PST) Received: from trail.lhotka.name (nat-5.bravonet.cz [77.48.224.5]) by ietfa.amsl.com (Postfix) with ESMTP id 867F321F87AD for ; Tue, 11 Dec 2012 05:15:56 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 5583854072B for ; Tue, 11 Dec 2012 14:15:38 +0100 (CET) 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 1gSW2UMbW0EM for ; Tue, 11 Dec 2012 14:14:54 +0100 (CET) Received: from localhost (unknown [172.29.2.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id E848F5402B7 for ; Tue, 11 Dec 2012 14:14:33 +0100 (CET) From: Ladislav Lhotka To: netmod@ietf.org In-Reply-To: <20121211094043.GA52035@elstar.local> References: <20121210170213.GG49658@elstar.local> <20121210191906.GB50035@elstar.local> <20121210.202924.394214026.mbj@tail-f.com> <20121211094043.GA52035@elstar.local> User-Agent: Notmuch/0.14+100~ge0adf10 (http://notmuchmail.org) Emacs/23.3.50.1 (i386-apple-darwin9.8.0) Mail-Followup-To: netmod@ietf.org Date: Tue, 11 Dec 2012 14:14:27 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [netmod] IP addresses with zone indices X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 11 Dec 2012 13:15:58 -0000 Juergen Schoenwaelder writes: > On Tue, Dec 11, 2012 at 10:16:47AM +0100, Ladislav Lhotka wrote: >> Martin Bjorklund writes: >> >> > Juergen Schoenwaelder wrote: >> >> On Mon, Dec 10, 2012 at 09:14:30AM -0800, Andy Bierman wrote: >> >> >> >> > Adding 3 or 4 types (and 2 are done already) better not take 6 months. >> >> > That would indicate a major process failure by the WG and its chairs. >> >> >> >> I heard you talking about more than 2 types. I probably mis-understood >> >> your email. As I stated in my email, the question is how you scope >> >> 6021bis work. If we open up 6021 for general additions, I continue to >> >> believe that my estimation is more realistic than yours (but I might >> >> be equally well just a failing WG co-chair). >> > >> > I am not convinced that dotted-quad is such a common type that we >> > should include it in 6021bis. >> >> It is currently supposed to be used in at least three different modules. I don't know what's the alternative - let each module define its own version? >> > > Speaking as 6021bis editor: A type that is used by multiple data > models without being highly technology specific or modeling something > controlled by IANA is a decent candidate for inclusion in 6021bis. I > do not see a problem to add a dotted quad type to ietf-yang-types, > probably with some additional text that for IPv4 addresses, the > specific type provided by the ietf-inet-types module must be used. I agree, but maybe the right place for the dotted-quad type is ietf-inet-types because I don't remember seeing it outside the Internet/IP context. Even IS-IS uses its own NSAP address for both router-id and area-id. Lada > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From j.schoenwaelder@jacobs-university.de Tue Dec 11 06:26:48 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C77E321F8776 for ; Tue, 11 Dec 2012 06:26:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.203 X-Spam-Level: X-Spam-Status: No, score=-103.203 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YUwzM5RLXDHM for ; Tue, 11 Dec 2012 06:26:48 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 0A76321F8746 for ; Tue, 11 Dec 2012 06:26:48 -0800 (PST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6D01D20BF6; Tue, 11 Dec 2012 15:26:47 +0100 (CET) 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 P0h2sF8D9e9j; Tue, 11 Dec 2012 15:26:47 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0A77720BF5; Tue, 11 Dec 2012 15:26:47 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 7E57D2365861; Tue, 11 Dec 2012 15:26:56 +0100 (CET) Date: Tue, 11 Dec 2012 15:26:56 +0100 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20121211142656.GB52721@elstar.local> Mail-Followup-To: netmod@ietf.org References: <20121210170213.GG49658@elstar.local> <20121210191906.GB50035@elstar.local> <20121210.202924.394214026.mbj@tail-f.com> <20121211094043.GA52035@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) Subject: Re: [netmod] IP addresses with zone indices 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, 11 Dec 2012 14:26:48 -0000 On Tue, Dec 11, 2012 at 02:14:27PM +0100, Ladislav Lhotka wrote: > > > > Speaking as 6021bis editor: A type that is used by multiple data > > models without being highly technology specific or modeling something > > controlled by IANA is a decent candidate for inclusion in 6021bis. I > > do not see a problem to add a dotted quad type to ietf-yang-types, > > probably with some additional text that for IPv4 addresses, the > > specific type provided by the ietf-inet-types module must be used. > > I agree, but maybe the right place for the dotted-quad type is ietf-inet-types because I don't remember seeing it outside the Internet/IP context. Even IS-IS uses its own NSAP address for both router-id and area-id. > But there is no reason to limit dotted-quad to IP only. In fact, a dotted-quad is a special case of a dot-decimal notation, which we for example use of OIDs. I would rather not 'restrict' its usage to IP since the definition of the type truely is generic. /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 Dec 11 06:30:16 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C87DD21F869F for ; Tue, 11 Dec 2012 06:30:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.397 X-Spam-Level: X-Spam-Status: No, score=-1.397 tagged_above=-999 required=5 tests=[AWL=-0.302, BAYES_00=-2.599, HOST_EQ_CZ=0.904, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IvsESTRJvJKe for ; Tue, 11 Dec 2012 06:30:16 -0800 (PST) Received: from trail.lhotka.name (nat-5.bravonet.cz [77.48.224.5]) by ietfa.amsl.com (Postfix) with ESMTP id 1EA9221F869E for ; Tue, 11 Dec 2012 06:30:15 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 9B8AA54072B; Tue, 11 Dec 2012 15:29:58 +0100 (CET) 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 b5h919llXFmu; Tue, 11 Dec 2012 15:29:14 +0100 (CET) Received: from localhost (unknown [172.29.2.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id AB9975402A1; Tue, 11 Dec 2012 15:28:37 +0100 (CET) From: Ladislav Lhotka To: Juergen Schoenwaelder , Martin Bjorklund In-Reply-To: <20121211103041.GA52155@elstar.local> References: <20121210.202924.394214026.mbj@tail-f.com> <20121211094043.GA52035@elstar.local> <20121211.104809.396474807.mbj@tail-f.com> <20121211103041.GA52155@elstar.local> User-Agent: Notmuch/0.14+100~ge0adf10 (http://notmuchmail.org) Emacs/23.3.50.1 (i386-apple-darwin9.8.0) Mail-Followup-To: Juergen Schoenwaelder , Martin Bjorklund , netmod@ietf.org Date: Tue, 11 Dec 2012 15:28:31 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: netmod@ietf.org Subject: Re: [netmod] IP addresses with zone indices X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 11 Dec 2012 14:30:16 -0000 Juergen Schoenwaelder writes: > * TODO ipv4-address-with-prefix, ipv6-address-with-prefix, > ip-address-with-prefix > > So far, it seems noneof our current modules needs this sincewe > keep the prefix length separated fromthe ip address.So I amnot > sure what to do aboutit, probably keep it pending. IMO the only potential use for this is the configuration of an IP address on an interface, so unless ietf-ip uses it, I don't see any reason for defining it. > > * TODO yang-identifier > > I noticed in ietf-netconf-acm.yang that leafs such as "module-name" > "rpc-name", and "notification-name" are used to represent YANG > identifiers, but the data type is plain "string". IMO, this is not > correct. The string should be constrained to only valid YANG > identifiers, which chould be a standard typedef. > > I think the ietf-yang-types module needs to be updated with a typedef > for yang-identifier. E.g.: > > typedef yang-identifier { > type string { > length "1..max"; > pattern '[a-z,A-Z,_][a-z,A-Z,0-9,\-,_,\.]*'; The commas must not be there, and '.' (dot) needn't be escaped in a character class, i.e. it could be '[a-zA-Z_][a-zA-Z0-9\-_.]*'. > } > description > "YANG identifier string"; > // An identifier MUST NOT start with (('X'|'x') ('M'|'m') ('L'|'l')) > // identifier = (ALPHA / "_") *(ALPHA / DIGIT / "_" / "-" / ".") > reference "RFC 6020, page 163"; > } > > Does anybody know how to write a regex pattern for the must not start > with "xml" requirement that is not in the ABNF? '[^xX].*|.[^mM].*|..[^lL].*' Lada -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From lhotka@nic.cz Tue Dec 11 06:31:07 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E56021F8746 for ; Tue, 11 Dec 2012 06:31:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id didfi+6biBbQ for ; Tue, 11 Dec 2012 06:31:06 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 1E10F21F869F for ; Tue, 11 Dec 2012 06:31:06 -0800 (PST) Received: from [172.20.26.113] (unknown [217.31.207.1]) by mail.nic.cz (Postfix) with ESMTPSA id 0A172140871; Tue, 11 Dec 2012 15:31:05 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1355236265; bh=SD/LLcT/c6KInbN9guS4TIwxDUtXnfW2onsau7f4CSY=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=Kop/vA6gZHGG+oz1eGxAOkeGTQgHOlZ9TcS1idNlRxHOVbAm6jyTI0U6Tvr8praEa /CkObPrKug19/nDSIVt6lIEjAwziZYwM/3z7b0iWH1S9h4RP0TMha+4EIA/DRHgnnd IjIg3cUCrdHxtm6tmDR88Jlq+bv9PcfpGK2HrnRI= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ladislav Lhotka In-Reply-To: <20121211142656.GB52721@elstar.local> Date: Tue, 11 Dec 2012 15:31:07 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <4F59A0F8-7039-4C18-B82D-39F6B86D1665@nic.cz> References: <20121210170213.GG49658@elstar.local> <20121210191906.GB50035@elstar.local> <20121210.202924.394214026.mbj@tail-f.com> <20121211094043.GA52035@elstar.local> <20121211142656.GB52721@elstar.local> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.1499) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] IP addresses with zone indices X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 11 Dec 2012 14:31:07 -0000 On Dec 11, 2012, at 3:26 PM, Juergen Schoenwaelder = wrote: > On Tue, Dec 11, 2012 at 02:14:27PM +0100, Ladislav Lhotka wrote: >>>=20 >>> Speaking as 6021bis editor: A type that is used by multiple data >>> models without being highly technology specific or modeling = something >>> controlled by IANA is a decent candidate for inclusion in 6021bis. I >>> do not see a problem to add a dotted quad type to ietf-yang-types, >>> probably with some additional text that for IPv4 addresses, the >>> specific type provided by the ietf-inet-types module must be used. >>=20 >> I agree, but maybe the right place for the dotted-quad type is = ietf-inet-types because I don't remember seeing it outside the = Internet/IP context. Even IS-IS uses its own NSAP address for both = router-id and area-id. >>=20 >=20 > But there is no reason to limit dotted-quad to IP only. In fact, a > dotted-quad is a special case of a dot-decimal notation, which we for > example use of OIDs. I would rather not 'restrict' its usage to IP > since the definition of the type truely is generic. OK. 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 From andy@yumaworks.com Tue Dec 11 06:51:52 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00F6A21F8779 for ; Tue, 11 Dec 2012 06:51:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.82 X-Spam-Level: X-Spam-Status: No, score=-2.82 tagged_above=-999 required=5 tests=[AWL=0.156, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SJjlgaTE62cc for ; Tue, 11 Dec 2012 06:51:48 -0800 (PST) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id A95FF21F8645 for ; Tue, 11 Dec 2012 06:51:47 -0800 (PST) Received: by mail-vb0-f44.google.com with SMTP id fc26so4053507vbb.31 for ; Tue, 11 Dec 2012 06:51:46 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=nRWkax62YkTYvUDrg1pbXE4iUI+Z1XPTAtSjmQ9GW8c=; b=EHhDMVPciVNy/ePnc3EvAlVNOJ/M8jccPw7wa2ByqdmwwQ0rvqSkFhsH7eUAZ5PAKe uZo+gNCPK77eHAHayQg677R1/zTiH07plC52KmFU5ZBffnRfC+zQu7KD+njJ16aLacsM 2KH2Erp6/ORAQZx49UqKRPyWH7JDfzg5rLng5JqT5AH9vzKWlPl+nUGogW6voBkelU4R USQauwZ9fF4mlxwjkEDnvaSrgo9fECc2TMZCj0TTf+uhEG3PhvUXCzpjWpZxuGjhK7As LEySVFApv/IcclbA+esc9JETpRXnQoW+eruZ1XhSUL6qprCeinmw54xkEU96jmgTzjcc VKWA== MIME-Version: 1.0 Received: by 10.220.153.80 with SMTP id j16mr11052998vcw.21.1355237506722; Tue, 11 Dec 2012 06:51:46 -0800 (PST) Received: by 10.58.117.234 with HTTP; Tue, 11 Dec 2012 06:51:46 -0800 (PST) In-Reply-To: <20121211103041.GA52155@elstar.local> References: <20121210.202924.394214026.mbj@tail-f.com> <20121211094043.GA52035@elstar.local> <20121211.104809.396474807.mbj@tail-f.com> <20121211103041.GA52155@elstar.local> Date: Tue, 11 Dec 2012 06:51:46 -0800 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , Martin Bjorklund , netmod@ietf.org Content-Type: multipart/alternative; boundary=f46d043be15a2caccc04d094d217 X-Gm-Message-State: ALoCoQmah0SdS5gJgWGb4rSA1jfINYVLSCxnrSZ06yBAmuTSLBzkF2FcKILc/f3VPGzPeRrmlP+K Subject: Re: [netmod] IP addresses with zone indices X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 11 Dec 2012 14:51:52 -0000 --f46d043be15a2caccc04d094d217 Content-Type: text/plain; charset=UTF-8 On Tue, Dec 11, 2012 at 2:30 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Tue, Dec 11, 2012 at 10:48:09AM +0100, Martin Bjorklund wrote: > > Juergen Schoenwaelder wrote: > > > Speaking as 6021bis editor: A type that is used by multiple data > > > models without being highly technology specific or modeling something > > > controlled by IANA is a decent candidate for inclusion in 6021bis. I > > > do not see a problem to add a dotted quad type to ietf-yang-types, > > > probably with some additional text that for IPv4 addresses, the > > > specific type provided by the ietf-inet-types module must be used. > > > > So, one thing we said about 6021 was something along the lines "it is > > easy to add new types". > > > > We just have three new types 'hex-string', 'uuid' and 'dotted-quad'. > > > > Why don't we try to do this quickly and a WGLC on 6021bis "now", and > > send all five document to the IESG at the same time. > > > > If this process works, it means we don't have to argue to death about > > even more new types to add - we can add them just as quickly at a > > later time instead! > > There were previously some suggestions. Here is my (likely incomplete) > list of things: > > * DONE hex-string > > * DONE uuid > > * TODO dotted-quad > > * TODO ipv4-address-with-prefix, ipv6-address-with-prefix, > ip-address-with-prefix > > So far, it seems noneof our current modules needs this sincewe > keep the prefix length separated fromthe ip address.So I amnot > sure what to do aboutit, probably keep it pending. > > * TODO yang-identifier > > I noticed in ietf-netconf-acm.yang that leafs such as "module-name" > "rpc-name", and "notification-name" are used to represent YANG > identifiers, but the data type is plain "string". IMO, this is not > correct. The string should be constrained to only valid YANG > identifiers, which chould be a standard typedef. > > I think the ietf-yang-types module needs to be updated with a typedef > for yang-identifier. E.g.: > > typedef yang-identifier { > type string { > length "1..max"; > pattern '[a-z,A-Z,_][a-z,A-Z,0-9,\-,_,\.]*'; > } > description > "YANG identifier string"; > // An identifier MUST NOT start with (('X'|'x') ('M'|'m') > ('L'|'l')) > // identifier = (ALPHA / "_") *(ALPHA / DIGIT / "_" / "-" / ".") > reference "RFC 6020, page 163"; > } > > Does anybody know how to write a regex pattern for the must not start > with "xml" requirement that is not in the ABNF? > > * TODO yang types for ip multicast addresses > > See post by Markus Rothmann, not sure what to do about it. > > * TODO any yang types to lift from the ACL module? > > One option to try to run such a process fast is to run it by hard > deadlines. That is, we make a call for additions and people need to > propose additions with close to complete writeups of the typedefs > proposed. For each proposal a separate email thread is created. 2-3 > weeks should be enough for proposals to come in. We then work through > the list, seeing which clarifications are needed and on which typedefs > we reach concensus. Discussions are cut after another 2-3 weeks, > typedefs not reaching concensus by then will not be considered for > this update. By end of January, we have an I-D to be WG last called. > > I said a 1 - 2 month process. You guys said "1 to 2 months in the IETF is 6 months". I said "You're right". Now you are saying 4 - 6 weeks. Without some sort of process to update 6021, then the only updates we can add are typedefs nobody actually needs at the moment. There are 3 process options: 1) put reusable metadata anywhere. YANG tools can find it, even if humans can't. 2) separate out reusable metadata into a different YANG module like common-types.yang in the ACL draft. 3) publish reusable metadata in RFC 6021-bis. The time issue will always be a factor for each new YANG module. Waiting until the end of the process to figure out there are reusable typedefs will produce the greatest delays and make (3) too impractical. /js > Andy > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --f46d043be15a2caccc04d094d217 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Tue, Dec 11, 2012 at 2:30 AM, Juergen= Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Tue, Dec 11, 2012 at 10:48:09AM +0100, Ma= rtin Bjorklund wrote:
> Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
> > Speaking as 6021bis editor: A type that is used by multiple data<= br> > > models without being highly technology specific or modeling somet= hing
> > controlled by IANA is a decent candidate for inclusion in 6021bis= . I
> > do not see a problem to add a dotted quad type to ietf-yang-types= ,
> > probably with some additional text that for IPv4 addresses, the > > specific type provided by the ietf-inet-types module must be used= .
>
> So, one thing we said about 6021 was something along the lines "i= t is
> easy to add new types".
>
> We just have three new types 'hex-string', 'uuid' and = 'dotted-quad'.
>
> Why don't we try to do this quickly and a WGLC on 6021bis "no= w", and
> send all five document to the IESG at the same time.
>
> If this process works, it means we don't have to argue to death ab= out
> even more new types to add - we can add them just as quickly at a
> later time instead!

There were previously some suggestions. Here is my (likely incomplete)
list of things:

* DONE hex-string

* DONE uuid

* TODO dotted-quad

* TODO ipv4-address-with-prefix, ipv6-address-with-prefix,
=C2=A0 ip-address-with-prefix

=C2=A0 So far, it seems noneof our current modules needs this sincewe
=C2=A0 keep the prefix length separated fromthe ip address.So I amnot
=C2=A0 sure what to do aboutit, probably keep it pending.

* TODO yang-identifier

=C2=A0 I noticed in ietf-netconf-acm.yang that leafs such as "module-n= ame"
=C2=A0 "rpc-name", and "notification-name" are used to = represent YANG
=C2=A0 identifiers, but the data type is plain "string". =C2=A0IM= O, this is not
=C2=A0 correct. =C2=A0The string should be constrained to only valid YANG =C2=A0 identifiers, which chould be a standard typedef.

=C2=A0 I think the ietf-yang-types module needs to be updated with a typede= f
=C2=A0 for yang-identifier. =C2=A0E.g.:

=C2=A0 =C2=A0 =C2=A0typedef yang-identifier {
=C2=A0 =C2=A0 =C2=A0 =C2=A0type string {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0length "1..max";
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0pattern '[a-z,A-Z,_][a-z,A-Z,0-9,\-,_= ,\.]*';
=C2=A0 =C2=A0 =C2=A0 =C2=A0}
=C2=A0 =C2=A0 =C2=A0 =C2=A0description
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"YANG identifier string";
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0// An identifier MUST NOT start with ((&#= 39;X'|'x') ('M'|'m') ('L'|'l'))=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0// identifier =3D (ALPHA / "_")= *(ALPHA / DIGIT / "_" / "-" / ".")
=C2=A0 =C2=A0 =C2=A0 =C2=A0 reference "RFC 6020, page 163";
=C2=A0 =C2=A0 =C2=A0 }

=C2=A0 Does anybody know how to write a regex pattern for the must not star= t
=C2=A0 with "xml" requirement that is not in the ABNF?

* TODO yang types for ip multicast addresses

=C2=A0 See post by Markus Rothmann, not sure what to do about it.

* TODO any yang types to lift from the ACL module?

One option to try to run such a process fast is to run it by hard
deadlines. That is, we make a call for additions and people need to
propose additions with close to complete writeups of the typedefs
proposed. For each proposal a separate email thread is created. 2-3
weeks should be enough for proposals to come in. We then work through
the list, seeing which clarifications are needed and on which typedefs
we reach concensus. Discussions are cut after another 2-3 weeks,
typedefs not reaching concensus by then will not be considered for
this update. By end of January, we have an I-D to be WG last called.


I said a 1 - 2 month process.
You guys sai= d "1 to 2 months in the IETF is 6 months".
I said "= ;You're right". =C2=A0Now you are saying 4 - 6 weeks.

Without some sort of process to update 6021, then the o= nly updates we can
add are typedefs nobody actually needs at the = moment.

There are 3 process options:

1) put reusable metadata anywhere. =C2=A0YANG tools can find= it,
=C2=A0 =C2=A0 even if humans can't.

=
2) separate out reusable metadata into a different YANG module like co= mmon-types.yang
=C2=A0 =C2=A0 in the ACL draft.

3) publish re= usable metadata in RFC 6021-bis.

The time issue wi= ll always be a factor for each new YANG module.
Waiting until the= end of the process to figure out there are reusable typedefs
will produce the greatest delays and make (3) too impractical.



<= span class=3D"HOEnZb"> /js

Andy
=C2=A0=

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

--f46d043be15a2caccc04d094d217-- From j.schoenwaelder@jacobs-university.de Tue Dec 11 06:57:15 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75EF421F86FD for ; Tue, 11 Dec 2012 06:57:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.205 X-Spam-Level: X-Spam-Status: No, score=-103.205 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rlJAgrOTnRYk for ; Tue, 11 Dec 2012 06:57:14 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 613AD21F86D4 for ; Tue, 11 Dec 2012 06:57:06 -0800 (PST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id A4DFB20BF6; Tue, 11 Dec 2012 15:57:05 +0100 (CET) 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 7PhlWPoap0jW; Tue, 11 Dec 2012 15:57:05 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id CE94C20BEB; Tue, 11 Dec 2012 15:57:04 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 86F652365A97; Tue, 11 Dec 2012 15:57:13 +0100 (CET) Date: Tue, 11 Dec 2012 15:57:13 +0100 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20121211145713.GA52916@elstar.local> Mail-Followup-To: Andy Bierman , Martin Bjorklund , netmod@ietf.org References: <20121210.202924.394214026.mbj@tail-f.com> <20121211094043.GA52035@elstar.local> <20121211.104809.396474807.mbj@tail-f.com> <20121211103041.GA52155@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] IP addresses with zone indices 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, 11 Dec 2012 14:57:15 -0000 On Tue, Dec 11, 2012 at 06:51:46AM -0800, Andy Bierman wrote: > I said a 1 - 2 month process. > You guys said "1 to 2 months in the IETF is 6 months". > I said "You're right". Now you are saying 4 - 6 weeks. See, there is progress. ;-) > Without some sort of process to update 6021, then the only updates we can > add are typedefs nobody actually needs at the moment. > > There are 3 process options: > > 1) put reusable metadata anywhere. YANG tools can find it, > even if humans can't. > > 2) separate out reusable metadata into a different YANG module like > common-types.yang > in the ACL draft. > > 3) publish reusable metadata in RFC 6021-bis. The term 'metadata' is more than confusing. > The time issue will always be a factor for each new YANG module. > Waiting until the end of the process to figure out there are reusable > typedefs will produce the greatest delays and make (3) too impractical. I open to try experiments. Perhaps it is even possible to turn things around fast if we follow a strict process that kill endless WG discussions by removing any proposed typedefs from the update that cause endless discussion, essentially postponing them to the next update cycle. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From andy@yumaworks.com Tue Dec 11 07:20:16 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15CE121F87FA for ; Tue, 11 Dec 2012 07:20:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.83 X-Spam-Level: X-Spam-Status: No, score=-2.83 tagged_above=-999 required=5 tests=[AWL=0.146, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c4lPxOIrpJfr for ; Tue, 11 Dec 2012 07:20:12 -0800 (PST) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 82DA821F86E4 for ; Tue, 11 Dec 2012 07:20:10 -0800 (PST) Received: by mail-vc0-f172.google.com with SMTP id fw7so4124693vcb.31 for ; Tue, 11 Dec 2012 07:20:10 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=anWCXJrFZ3K2qmoDHQjEGTKb1uovX8cGGMQqc+KNp1E=; b=J7zli2GwZ2W5kuUpS5BTvfgs1civvPrN2rsMANUzswWYXY3LtIea/SJHEUk70IxiXW /aRoAEJBpWwb5AJY/2R9YEfjlJjEWP5YUAVlkPUNOePqcgq2FLj8iCwdHVA32C6Xe3Vd xS2iHgDWtllTxc015yvj61UOTBIIA2hKvyCyumSLG50xCKuWuVBvWkCOYzXMOIGiIkJn Ops0OPtreoWq5sy124rD7v8B+Fw16q/oaZ0X5s/D8DfbrJMoq5tAzpPwsHIot1NKVvkh vCPbMM1R5KtSH43MNXmK0r0mqskUAx63gfxRnByrn5GsXMiF6fYtaPzvGabIW9dV6hyI gfSg== MIME-Version: 1.0 Received: by 10.52.26.115 with SMTP id k19mr9860752vdg.67.1355239209928; Tue, 11 Dec 2012 07:20:09 -0800 (PST) Received: by 10.58.117.234 with HTTP; Tue, 11 Dec 2012 07:20:09 -0800 (PST) In-Reply-To: <20121211145713.GA52916@elstar.local> References: <20121210.202924.394214026.mbj@tail-f.com> <20121211094043.GA52035@elstar.local> <20121211.104809.396474807.mbj@tail-f.com> <20121211103041.GA52155@elstar.local> <20121211145713.GA52916@elstar.local> Date: Tue, 11 Dec 2012 07:20:09 -0800 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , Andy Bierman , Martin Bjorklund , netmod@ietf.org Content-Type: multipart/alternative; boundary=20cf307f39d6b187d104d0953753 X-Gm-Message-State: ALoCoQnDphTmo05WQE3n3qUbicA658RPvopZotqFANADpGA+Mf19ZyPp35XRz8BbHVLgoeowfoMg Subject: Re: [netmod] IP addresses with zone indices X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 11 Dec 2012 15:20:16 -0000 --20cf307f39d6b187d104d0953753 Content-Type: text/plain; charset=UTF-8 On Tue, Dec 11, 2012 at 6:57 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Tue, Dec 11, 2012 at 06:51:46AM -0800, Andy Bierman wrote: > > > I said a 1 - 2 month process. > > You guys said "1 to 2 months in the IETF is 6 months". > > I said "You're right". Now you are saying 4 - 6 weeks. > > See, there is progress. ;-) > > > Without some sort of process to update 6021, then the only updates we can > > add are typedefs nobody actually needs at the moment. > > > > There are 3 process options: > > > > 1) put reusable metadata anywhere. YANG tools can find it, > > even if humans can't. > > > > 2) separate out reusable metadata into a different YANG module like > > common-types.yang > > in the ACL draft. > > > > 3) publish reusable metadata in RFC 6021-bis. > > The term 'metadata' is more than confusing. > > It might include identities to go with an identityref typedef. A different RFC would be for groupings I suppose, but it is possible that we create reusable groupings that we want to be used in domain-specific modules. > The time issue will always be a factor for each new YANG module. > > Waiting until the end of the process to figure out there are reusable > > typedefs will produce the greatest delays and make (3) too impractical. > > I open to try experiments. Perhaps it is even possible to turn things > around fast if we follow a strict process that kill endless WG > discussions by removing any proposed typedefs from the update that > cause endless discussion, essentially postponing them to the next > update cycle. > > Perhaps, but republishing 6021 is a big deal, and probably needs more than 2 -3 weeks to conduct detailed reviews. I think option (1) or (2) is sufficient for the 1 or 2 new types needed by the current modules. Updating 6021 doesn't seem realistic -- ever. I don't think the 2 typedefs added are urgently needed, and bumping the number to 3 or 4 isn't very compelling. It would be worth updating if it was significantly enhanced, and then not touched again for 3+ years. > /js > Andy --20cf307f39d6b187d104d0953753 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Tue, Dec 11, 2012 at 6:57 AM, Juergen= Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Tue, Dec 11, 2012 at 06:51:46AM -0800, An= dy Bierman wrote:

> I said a 1 - 2 month process.
> You guys said "1 to 2 months in the IETF is 6 months".
> I said "You're right". =C2=A0Now you are saying 4 - 6 we= eks.

See, there is progress. ;-)

> Without some sort of process to update 6021, then the only updates we = can
> add are typedefs nobody actually needs at the moment.
>
> There are 3 process options:
>
> 1) put reusable metadata anywhere. =C2=A0YANG tools can find it,
> =C2=A0 =C2=A0 even if humans can't.
>
> 2) separate out reusable metadata into a different YANG module like > common-types.yang
> =C2=A0 =C2=A0 in the ACL draft.
>
> 3) publish reusable metadata in RFC 6021-bis.

The term 'metadata' is more than confusing.


It might include identities to go with= an identityref typedef.
A different RFC would be for groupings I= suppose, but it
is possible that we create reusable groupings th= at we want
to be used in domain-specific modules.

> The time issue will always be a factor for each new YANG module.
> Waiting until the end of the process to figure out there are reusable<= br> > typedefs will produce the greatest delays and make (3) too impractical= .

I open to try experiments. Perhaps it is even possible to turn things
around fast if we follow a strict process that kill endless WG
discussions by removing any proposed typedefs from the update that
cause endless discussion, essentially postponing them to the next
update cycle.


Perhaps, but republishing 6021 is a big deal, and pr= obably needs more than
2 -3 weeks to conduct detailed reviews. = =C2=A0I think option (1) or (2) is sufficient for the
1 or 2 new types needed by the current modules.

Updating 6021 doesn't seem realistic -- ever. =C2=A0I don't thin= k the 2 typedefs added
It would be worth updating if it was significantly enhanced, and then = not touched again
for 3+ years.

=C2=A0
/js
=C2=A0

Andy=

--20cf307f39d6b187d104d0953753-- From lhotka@nic.cz Tue Dec 11 07:20:25 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA31A21F8842 for ; Tue, 11 Dec 2012 07:20:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pqznZmlj55HT for ; Tue, 11 Dec 2012 07:20:25 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 2489721F883F for ; Tue, 11 Dec 2012 07:20:25 -0800 (PST) Received: from [172.20.26.113] (unknown [217.31.207.1]) by mail.nic.cz (Postfix) with ESMTPSA id 6926213F968; Tue, 11 Dec 2012 16:20:24 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1355239224; bh=px6oD420xG9wPpeI0R8UTznFKyHc/RveuwW848nvYQI=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=XBpkpDvnnDXkmASP0PM3haAMF2nIHFXoABV+FDzzmybhEX2sOH+3ZkDEcAqmOz7Qb tBrGKVcRerDNnWwFS7hwubA0oOPXqYCk+CH0a5IZICSPO3hjFIQl/IzLPiNEgkolBA t0glpggYC6A/quIBGReCK6bXf6IFYd6djjdLwPC0= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ladislav Lhotka In-Reply-To: <20121211103041.GA52155@elstar.local> Date: Tue, 11 Dec 2012 16:20:26 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20121210.202924.394214026.mbj@tail-f.com> <20121211094043.GA52035@elstar.local> <20121211.104809.396474807.mbj@tail-f.com> <20121211103041.GA52155@elstar.local> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.1499) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] IP addresses with zone indices X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 11 Dec 2012 15:20:25 -0000 On Dec 11, 2012, at 11:30 AM, Juergen Schoenwaelder = wrote: > Does anybody know how to write a regex pattern for the must not start > with "xml" requirement that is not in the ABNF? Second try: '.|..|[^xX].*|.[^mM].*|..[^lL].*' Lada -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From mbj@tail-f.com Tue Dec 11 07:29:56 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 250A621F8778 for ; Tue, 11 Dec 2012 07:29:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.938 X-Spam-Level: X-Spam-Status: No, score=-1.938 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TclafB6bBAoR for ; Tue, 11 Dec 2012 07:29:55 -0800 (PST) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 7DF6721F8857 for ; Tue, 11 Dec 2012 07:29:55 -0800 (PST) Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id E7C591200D7A; Tue, 11 Dec 2012 16:29:53 +0100 (CET) Date: Tue, 11 Dec 2012 16:29:53 +0100 (CET) Message-Id: <20121211.162953.200903334.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: <20121211145713.GA52916@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] IP addresses with zone indices X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 11 Dec 2012 15:29:56 -0000 Andy Bierman wrote: > Perhaps, but republishing 6021 is a big deal, and probably needs more than > 2 -3 weeks to conduct detailed reviews. I think option (1) or (2) is > sufficient for the > 1 or 2 new types needed by the current modules. > > Updating 6021 doesn't seem realistic -- ever. Wow. If we can publish these typedefs in other modules (like ietf-ip), why would moving them to 6021bis be such a big deal? /martin From andy@yumaworks.com Tue Dec 11 07:47:46 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFFC621F8473 for ; Tue, 11 Dec 2012 07:47:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.839 X-Spam-Level: X-Spam-Status: No, score=-2.839 tagged_above=-999 required=5 tests=[AWL=0.137, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3ADEZ5PmS1Gl for ; Tue, 11 Dec 2012 07:47:46 -0800 (PST) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 18B8021F8477 for ; Tue, 11 Dec 2012 07:47:45 -0800 (PST) Received: by mail-vb0-f44.google.com with SMTP id fc26so4124640vbb.31 for ; Tue, 11 Dec 2012 07:47:45 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=3XTJ1UG38+856wtLTOn/m5MDzZVJxeFelf2t2MBYpHY=; b=fDHTi7kxGFJSzdF7Y3E722hnqX/n/V1kxFfsQt9nKe8w0iYdpN2kKzf2g1VEQjD23l 5bXw7/SLo3og1xtWb7LbaksfsYihIwZX7fSqtiq4/58TsdPLePiUyJK8///dMOhVbyMQ FZVBOTljcewh1pjuxy16eCLcA1Y9W4bcoc3OZWGyevmscF/ZnpODpz+Cd4mkukVnqozq K6G7QTbkO8/XfQGdzDWlmBLjRVDpcVIQLVcWvzkeHqvsPB4d8W5FvMpcAQkp5DMT/80L r/+XEElBDIVDk6KD2HbVPlYHjZGt4gXfwhR524ytjo+fsqLPMXYKlmpY6hZH+kns/SCx OLjw== MIME-Version: 1.0 Received: by 10.52.75.100 with SMTP id b4mr9800365vdw.52.1355240865479; Tue, 11 Dec 2012 07:47:45 -0800 (PST) Received: by 10.58.117.234 with HTTP; Tue, 11 Dec 2012 07:47:45 -0800 (PST) In-Reply-To: <20121211.162953.200903334.mbj@tail-f.com> References: <20121211145713.GA52916@elstar.local> <20121211.162953.200903334.mbj@tail-f.com> Date: Tue, 11 Dec 2012 07:47:45 -0800 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: multipart/alternative; boundary=bcaec50166c95f3d3f04d0959af1 X-Gm-Message-State: ALoCoQkv3sChhlJf0UDBuWwyOz8Oo8mQMCpQRnBn7tjN81/siNpKn5d8H199M+l4sB1zxGnwdYFn Cc: netmod@ietf.org Subject: Re: [netmod] IP addresses with zone indices X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 11 Dec 2012 15:47:46 -0000 --bcaec50166c95f3d3f04d0959af1 Content-Type: text/plain; charset=UTF-8 On Tue, Dec 11, 2012 at 7:29 AM, Martin Bjorklund wrote: > Andy Bierman wrote: > > Perhaps, but republishing 6021 is a big deal, and probably needs more > than > > 2 -3 weeks to conduct detailed reviews. I think option (1) or (2) is > > sufficient for the > > 1 or 2 new types needed by the current modules. > > > > Updating 6021 doesn't seem realistic -- ever. > > Wow. > > > If we can publish these typedefs in other modules (like ietf-ip), why > would moving them to 6021bis be such a big deal? > > IMO, moving a typedef is a really bad idea. I prefer these types be in ietf-ip-types.yang, but even if they are in ietf-ip.yang, that is better than deprecating, then obsoleting them, and cut-and-pasting new ones. Then every module using the deprecated typedef has to be republished to use the new one instead. > /martin > Andy --bcaec50166c95f3d3f04d0959af1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Tue, Dec 11, 2012 at 7:29 AM, Martin = Bjorklund <mbj@tail-f.com> wrote:
Andy Bierman <andy@yumaworks.com> wrote:
> Perhaps, but republishing 6021 is a big deal, and probably needs more = than
> 2 -3 weeks to conduct detailed reviews. =C2=A0I think option (1) or (2= ) is
> sufficient for the
> 1 or 2 new types needed by the current modules.
>
> Updating 6021 doesn't seem realistic -- ever.

Wow.


If we can publish these typedefs in other modules (like ietf-ip), why
would moving them to 6021bis be such a big deal?


IMO, moving a typedef is a really bad idea.
I prefer these types be in ietf-ip-types.yang, but even if they are in ie= tf-ip.yang,
that is better than deprecating, then obsoleting them, and cut-and-pas= ting
new ones. Then every module using the deprecated typedef has= to be republished
to use the new one instead.


/martin

Andy

--bcaec50166c95f3d3f04d0959af1-- From lhotka@nic.cz Tue Dec 11 08:05:51 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFCFE21F87A2 for ; Tue, 11 Dec 2012 08:05:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Xqu1+FgNYtz for ; Tue, 11 Dec 2012 08:05:51 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id AE20621F8780 for ; Tue, 11 Dec 2012 08:05:50 -0800 (PST) Received: from [172.20.26.113] (unknown [217.31.207.1]) by mail.nic.cz (Postfix) with ESMTPSA id 88C2513F968; Tue, 11 Dec 2012 17:05:49 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1355241949; bh=8IWf9VHGJfdJwS96qHYXjTN8zxuHslXD7J2TCGW+5Uc=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=SiS6Rzwe1bW/7oiTi+8LaOUET9iBVUj+GmbAfbJmxcHwK/WQI1UUrkT7Mgz0ibTN4 1225VX+NtBVuruHagP6b1mSW54730RXGjwbgQrdl2EyQTyi96KgCbs4/z0EJ1ssjwD NgddA8up033rTH6DpO1xCiwVXGrhHjvsEbz8hbUk= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ladislav Lhotka In-Reply-To: Date: Tue, 11 Dec 2012 17:05:51 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <33E0A4AB-849A-4C29-A1F3-68A1622C24FB@nic.cz> References: <20121211145713.GA52916@elstar.local> <20121211.162953.200903334.mbj@tail-f.com> To: Andy Bierman X-Mailer: Apple Mail (2.1499) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] IP addresses with zone indices X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 11 Dec 2012 16:05:51 -0000 On Dec 11, 2012, at 4:47 PM, Andy Bierman wrote: >=20 >=20 > On Tue, Dec 11, 2012 at 7:29 AM, Martin Bjorklund = wrote: > Andy Bierman wrote: > > Perhaps, but republishing 6021 is a big deal, and probably needs = more than > > 2 -3 weeks to conduct detailed reviews. I think option (1) or (2) = is > > sufficient for the > > 1 or 2 new types needed by the current modules. > > > > Updating 6021 doesn't seem realistic -- ever. >=20 > Wow. >=20 >=20 > If we can publish these typedefs in other modules (like ietf-ip), why > would moving them to 6021bis be such a big deal? >=20 >=20 > IMO, moving a typedef is a really bad idea. > I prefer these types be in ietf-ip-types.yang, but even if they are in = ietf-ip.yang, > that is better than deprecating, then obsoleting them, and = cut-and-pasting > new ones. Then every module using the deprecated typedef has to be = republished > to use the new one instead. Moving a type to "deprecated" status doesn't force modules that use the = type to immediately upgrade. So the type can be changed at the next = suitable occasion when the module is being republished anyway. Lada >=20 >=20 > /martin >=20 > Andy >=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 Tue Dec 11 08:08:07 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBA0421F8797 for ; Tue, 11 Dec 2012 08:08:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.226 X-Spam-Level: X-Spam-Status: No, score=-2.226 tagged_above=-999 required=5 tests=[AWL=-0.490, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qPh4nXSFlWzE for ; Tue, 11 Dec 2012 08:08:07 -0800 (PST) Received: from mail-ye0-f172.google.com (mail-ye0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 286D721F8780 for ; Tue, 11 Dec 2012 08:08:05 -0800 (PST) Received: by mail-ye0-f172.google.com with SMTP id r14so834129yen.31 for ; Tue, 11 Dec 2012 08:08:04 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=djvzqXXAYAk3vJnu2QkH1v0Fwh2R9yCYmenfPzXSpus=; b=DMyxvWhc5HjJe7qJaIui67MWP6iY5jYZf3waT/VWGsUJWK3JAuU5fIRrrO3cXOBL/m K2hlhp08XpvKsurgn/HI3sUjLMmFsPsmKebgy0GZocX/Wxe+fTVvi+ziScQhuGb4+dYf 5q1P43G+J+h5gq7HClgc06SGVEQztvA4o65eKbyZ1BFXUxpErXTXxmeWmuHCLiH9wKJd wa03RLCPV/UGPLBSeIoORnbZX9Cn7CCbdOnSLujZDPImtF5YwHHhPKDjK5cf3baCma59 4WNpGuOO6kfMBC77kHrXlD5Bus48m/6xfKE2s7L06bHhjb+TWMN9bXe4blAFuDe7osMT 3UnA== MIME-Version: 1.0 Received: by 10.59.6.70 with SMTP id cs6mr11526303ved.60.1355242084606; Tue, 11 Dec 2012 08:08:04 -0800 (PST) Received: by 10.58.117.234 with HTTP; Tue, 11 Dec 2012 08:08:04 -0800 (PST) In-Reply-To: References: <20121211145713.GA52916@elstar.local> <20121211.162953.200903334.mbj@tail-f.com> Date: Tue, 11 Dec 2012 08:08:04 -0800 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: multipart/alternative; boundary=047d7bf0effe09a17204d095e35d X-Gm-Message-State: ALoCoQkGodjKPPcq6sNUytAS+ITGnNBDNdN66ItJiayk3UZk0ttbXiqVdazTLPdBAdkaBpWSxmcJ Cc: netmod@ietf.org Subject: Re: [netmod] IP addresses with zone indices X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 11 Dec 2012 16:08:08 -0000 --047d7bf0effe09a17204d095e35d Content-Type: text/plain; charset=UTF-8 On Tue, Dec 11, 2012 at 7:47 AM, Andy Bierman wrote: > > > On Tue, Dec 11, 2012 at 7:29 AM, Martin Bjorklund wrote: > >> Andy Bierman wrote: >> > Perhaps, but republishing 6021 is a big deal, and probably needs more >> than >> > 2 -3 weeks to conduct detailed reviews. I think option (1) or (2) is >> > sufficient for the >> > 1 or 2 new types needed by the current modules. >> > >> > Updating 6021 doesn't seem realistic -- ever. >> >> Wow. >> >> >> Because we are not quite smart enough to plan ahead or patient enough to wait for the IETF process. We should realize that since we are creating the framework, that the reusable type issue will come up now. But Juergen thinks 4 - 6 weeks, and I think 4 - 8 weeks, especially over the holidays. It's not like 2 weeks is a lot of IETF time. I agree with Juergen's experiment except for the agree-now-or-toss-it review process. I prefer just an extended WGLC review process lasting 3 or 4 weeks. We are not promoting long term YANG reuse unless we take steps in the short term to make that feasible. But if the short-term steps are quick-and-dirty, we end up making things worse in the long-term. Andy > If we can publish these typedefs in other modules (like ietf-ip), why >> would moving them to 6021bis be such a big deal? >> >> > IMO, moving a typedef is a really bad idea. > I prefer these types be in ietf-ip-types.yang, but even if they are in > ietf-ip.yang, > that is better than deprecating, then obsoleting them, and cut-and-pasting > new ones. Then every module using the deprecated typedef has to be > republished > to use the new one instead. > > >> /martin >> > > Andy > > --047d7bf0effe09a17204d095e35d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Tue, Dec 11, 2012 at 7:47 AM, Andy Bi= erman <andy@yumaworks.com> wrote:


On Tue, Dec 11, 2012 at 7:29 AM, Martin = Bjorklund <mbj@tail-f.com> wrote:
Andy Bierman <an= dy@yumaworks.com> wrote:
> Perhaps, but republishing 6021 is a big deal, and probably needs more = than
> 2 -3 weeks to conduct detailed reviews. =C2=A0I think option (1) or (2= ) is
> sufficient for the
> 1 or 2 new types needed by the current modules.
>
> Updating 6021 doesn't seem realistic -- ever.

Wow.



Because we are not = quite smart enough to plan ahead or patient enough to
wait for th= e IETF process. =C2=A0We should realize that since we are creating
the framework, that the reusable type issue will come up now.
But Juergen thinks 4 - 6 weeks, and I think 4 - 8 weeks, especi= ally over
the holidays. =C2=A0It's not like 2 weeks is a lot = of IETF time.
I agree with Juergen's experiment except for the agree-now-or-toss= -it
review process. =C2=A0I prefer just an extended WGLC review p= rocess lasting 3 or 4 weeks.

We are not promoting = long term YANG reuse unless we take steps in the short term
to make that feasible. =C2=A0But if the short-term steps are quick-and= -dirty, we
end up making things worse in the long-term.

Andy


=C2=A0
If we can publish these typedefs in other modules (like ietf-ip), why
would moving them to 6021bis be such a big deal?


IMO, moving a typedef is a really bad idea.
I prefer these = types be in ietf-ip-types.yang, but even if they are in ietf-ip.yang,
that is better than deprecating, then obsoleting them, and cut-and-pas= ting
new ones. Then every module using the deprecated typedef has= to be republished
to use the new one instead.


/martin

Andy


--047d7bf0effe09a17204d095e35d-- From andy@yumaworks.com Tue Dec 11 08:14:12 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FB7921F878B for ; Tue, 11 Dec 2012 08:14:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.821 X-Spam-Level: X-Spam-Status: No, score=-2.821 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tu8l37A52pqn for ; Tue, 11 Dec 2012 08:14:12 -0800 (PST) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id C6FB821F86E4 for ; Tue, 11 Dec 2012 08:14:11 -0800 (PST) Received: by mail-vb0-f44.google.com with SMTP id fc26so4154406vbb.31 for ; Tue, 11 Dec 2012 08:14:11 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=ZkJwj+uZwANK7h9RPeEnB3AVNHZv4hPe74OCDHHCy5A=; b=oNW3KadqplG/xBYsVPztHQC2Ehi5T0QoxhON2wO9k53ovydOuXWZkS5LZ8w8/+Udwd AypInVunW6aBa4nit8PARsne+qIqiVb9wXppdzAqsLGnyLFfXbwIthPz6agPgdDc4q8/ 5BIDj1DiBf5DQKCDoHoxpTcRQng/0RMFA+s28ySTxNVghIBJMgLhD1CpYwr3VHvEwNnI 9vwhh7DycxGB3KNYZWgYrFybBtwK49Hp9zLRzmaOecWNxKTNu2U1x34fKLhG3keHNW/E sRAm0KcMmgfmepqYChWyPYl8zyWJ6nvSU++S9IfyQSAQrX48fe1uGLYGRUa99WqkPH7u B1oA== MIME-Version: 1.0 Received: by 10.52.66.34 with SMTP id c2mr9843397vdt.62.1355242451218; Tue, 11 Dec 2012 08:14:11 -0800 (PST) Received: by 10.58.117.234 with HTTP; Tue, 11 Dec 2012 08:14:11 -0800 (PST) In-Reply-To: <33E0A4AB-849A-4C29-A1F3-68A1622C24FB@nic.cz> References: <20121211145713.GA52916@elstar.local> <20121211.162953.200903334.mbj@tail-f.com> <33E0A4AB-849A-4C29-A1F3-68A1622C24FB@nic.cz> Date: Tue, 11 Dec 2012 08:14:11 -0800 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=20cf307f35c2e3b0c004d095f88e X-Gm-Message-State: ALoCoQnVyFW9VS6kIJGUnhRoT7qbqI0knHNpfXehciBrjlHhNdufaz7FJpKYPoGwHLs2Khyj7Iq7 Cc: netmod@ietf.org Subject: Re: [netmod] IP addresses with zone indices X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 11 Dec 2012 16:14:12 -0000 --20cf307f35c2e3b0c004d095f88e Content-Type: text/plain; charset=UTF-8 On Tue, Dec 11, 2012 at 8:05 AM, Ladislav Lhotka wrote: > > On Dec 11, 2012, at 4:47 PM, Andy Bierman wrote: > > > > > > > On Tue, Dec 11, 2012 at 7:29 AM, Martin Bjorklund > wrote: > > Andy Bierman wrote: > > > Perhaps, but republishing 6021 is a big deal, and probably needs more > than > > > 2 -3 weeks to conduct detailed reviews. I think option (1) or (2) is > > > sufficient for the > > > 1 or 2 new types needed by the current modules. > > > > > > Updating 6021 doesn't seem realistic -- ever. > > > > Wow. > > > > > > If we can publish these typedefs in other modules (like ietf-ip), why > > would moving them to 6021bis be such a big deal? > > > > > > IMO, moving a typedef is a really bad idea. > > I prefer these types be in ietf-ip-types.yang, but even if they are in > ietf-ip.yang, > > that is better than deprecating, then obsoleting them, and > cut-and-pasting > > new ones. Then every module using the deprecated typedef has to be > republished > > to use the new one instead. > > Moving a type to "deprecated" status doesn't force modules that use the > type to immediately upgrade. So the type can be changed at the next > suitable occasion when the module is being republished anyway. > > It has to be republished, which is a lot of overhead, so it won't get done. The definition exists in 2 places for years, causing lots of confusion. What is the point of moving a typedef anyway? To reduce confusion and complexity? IMO it does the opposite. Lada > > Andy --20cf307f35c2e3b0c004d095f88e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Tue, Dec 11, 2012 at 8:05 AM, Ladisla= v Lhotka <lhotka@nic.cz> wrote:
andy@yumaworks.com> wrote:

>
>
> On Tue, Dec 11, 2012 at 7:29 AM, Martin Bjorklund <mbj@tail-f.com> wrote:
> Andy Bierman <andy@yumaworks.= com> wrote:
> > Perhaps, but republishing 6021 is a big deal, and probably needs = more than
> > 2 -3 weeks to conduct detailed reviews. =C2=A0I think option (1) = or (2) is
> > sufficient for the
> > 1 or 2 new types needed by the current modules.
> >
> > Updating 6021 doesn't seem realistic -- ever.
>
> Wow.
>
>
> If we can publish these typedefs in other modules (like ietf-ip), why<= br> > would moving them to 6021bis be such a big deal?
>
>
> IMO, moving a typedef is a really bad idea.
> I prefer these types be in ietf-ip-types.yang, but even if they are in= ietf-ip.yang,
> that is better than deprecating, then obsoleting them, and cut-and-pas= ting
> new ones. Then every module using the deprecated typedef has to be rep= ublished
> to use the new one instead.

Moving a type to "deprecated" status doesn't force modules th= at use the type to immediately upgrade. So the type can be changed at the n= ext suitable occasion when the module is being republished anyway.


It has to be republished, which is a l= ot of overhead,
so it won't get done.

The definition exists in 2 places for years, causing lots of
confusion. =C2=A0What is the point of moving a typedef anyway?
To= reduce confusion and complexity? IMO it does the opposite.

<= /div>
Lada


Andy

--20cf307f35c2e3b0c004d095f88e-- From j.schoenwaelder@jacobs-university.de Tue Dec 11 08:15:33 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D30721F879E for ; Tue, 11 Dec 2012 08:15:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.207 X-Spam-Level: X-Spam-Status: No, score=-103.207 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id shun3Z0enS-t for ; Tue, 11 Dec 2012 08:15:33 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id DB7F421F86E4 for ; Tue, 11 Dec 2012 08:15:32 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1B70E20C03; Tue, 11 Dec 2012 17:15:32 +0100 (CET) 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 o8nj3zcu3Fit; Tue, 11 Dec 2012 17:15:31 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8A7BD20BFD; Tue, 11 Dec 2012 17:15:31 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 0646E2365E30; Tue, 11 Dec 2012 17:15:40 +0100 (CET) Date: Tue, 11 Dec 2012 17:15:40 +0100 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20121211161540.GA53087@elstar.local> Mail-Followup-To: Andy Bierman , Martin Bjorklund , netmod@ietf.org References: <20121210.202924.394214026.mbj@tail-f.com> <20121211094043.GA52035@elstar.local> <20121211.104809.396474807.mbj@tail-f.com> <20121211103041.GA52155@elstar.local> <20121211145713.GA52916@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] IP addresses with zone indices 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, 11 Dec 2012 16:15:33 -0000 On Tue, Dec 11, 2012 at 07:20:09AM -0800, Andy Bierman wrote: > > Updating 6021 doesn't seem realistic -- ever. Boy, now you are going extreme. I will agree only if the world stops spinning on December 21st. What really kills progress in this WG is endless debate about non-important little issues that should be much quicker to settle. We seem to not have big pressure to deliver important things. Yep, I am frustrated - why can't we say put the definition there, lets move on? Perhaps I should just stay silence and watch you guys arguing every little detail to death until there is clear concensus. I should stop thinking constructively. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From andy@yumaworks.com Tue Dec 11 08:25:30 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C974621F84CD for ; Tue, 11 Dec 2012 08:25:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.828 X-Spam-Level: X-Spam-Status: No, score=-2.828 tagged_above=-999 required=5 tests=[AWL=0.148, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R3zm4Y1qEUPN for ; Tue, 11 Dec 2012 08:25:28 -0800 (PST) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 02C5D21F849E for ; Tue, 11 Dec 2012 08:25:27 -0800 (PST) Received: by mail-vb0-f44.google.com with SMTP id fc26so4168957vbb.31 for ; Tue, 11 Dec 2012 08:25:27 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=6Rm9DkTNrztGqEOseRuA1czM6pEz9/MOA8Cy8TT3Bvg=; b=GaQKpmLYj6lv8C1Fx8g1tnDCBWMr4AW3/NZ8ThtHLeKiGUbQ6rYvADsblexBZoCc/T G1dwwE5kclt2AKw1APsO7kLoEiUcugMXoHAtNN0wOuKwSc9ohew3URAocLxBEBqhMRtE RJ6P47EHGHJcIyYfkrzWPz5Z66GvHInKbaRP7dDETyImV/zOzg9BasvyVQw85QPaHKAe 7m0PKibppCoj0k56Cl2dZwaqEy2gELdG98N0FXb9b4/7ZUfXz3Rr7bhgxvVshf9j4W/Q lIACOgAO8Uz4R6JTnEzhMLwy+b/a4JOQ1XgUV38Bh71Aq6rq9EXOcdapeoCDtrNFo2h+ P/Ug== MIME-Version: 1.0 Received: by 10.220.239.14 with SMTP id ku14mr11326118vcb.57.1355243127476; Tue, 11 Dec 2012 08:25:27 -0800 (PST) Received: by 10.58.117.234 with HTTP; Tue, 11 Dec 2012 08:25:27 -0800 (PST) In-Reply-To: <20121211161540.GA53087@elstar.local> References: <20121210.202924.394214026.mbj@tail-f.com> <20121211094043.GA52035@elstar.local> <20121211.104809.396474807.mbj@tail-f.com> <20121211103041.GA52155@elstar.local> <20121211145713.GA52916@elstar.local> <20121211161540.GA53087@elstar.local> Date: Tue, 11 Dec 2012 08:25:27 -0800 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , Andy Bierman , Martin Bjorklund , netmod@ietf.org Content-Type: multipart/alternative; boundary=14dae9cfcc3032911f04d096212a X-Gm-Message-State: ALoCoQku7ufOpoTIfsPcJq7j2UCyiSSwruGuV3G9Lim3i9AGy0h+bSrFWzaG3iawqjuEnBMe5IRN Subject: Re: [netmod] IP addresses with zone indices X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 11 Dec 2012 16:25:30 -0000 --14dae9cfcc3032911f04d096212a Content-Type: text/plain; charset=UTF-8 On Tue, Dec 11, 2012 at 8:15 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Tue, Dec 11, 2012 at 07:20:09AM -0800, Andy Bierman wrote: > > > > Updating 6021 doesn't seem realistic -- ever. > > Boy, now you are going extreme. I will agree only if the world stops > spinning on December 21st. > > What really kills progress in this WG is endless debate about > non-important little issues that should be much quicker to settle. We > seem to not have big pressure to deliver important things. Yep, I am > frustrated - why can't we say put the definition there, lets move on? > Perhaps I should just stay silence and watch you guys arguing every > little detail to death until there is clear concensus. I should stop > thinking constructively. > > Updating the YANG Types RFC is a big deal. IMO it should be done carefully. Publishing an ietf-ip-types.yang module is a really painless solution. I am concerned about a long-term module library maintenance nightmare. Unless there are lots of useful typedefs added to RFC 6021-bis, I don't think it is worth re-publishing. Just make more module names. They are free. A significant improvement to 6021bis would require some time to complete. > /js > Andy --14dae9cfcc3032911f04d096212a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Tue, Dec 11, 2012 at 8:15 AM, Juergen= Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Tue, Dec 11, 2012 at 07:20:09AM -0800, An= dy Bierman wrote:
>
> Updating 6021 doesn't seem realistic -- ever.

Boy, now you are going extreme. I will agree only if the world stops
spinning on December 21st.

What really kills progress in this WG is endless debate about
non-important little issues that should be much quicker to settle. =C2=A0We=
seem to not have big pressure to deliver important things. Yep, I am
frustrated - why can't we say put the definition there, lets move on? Perhaps I should just stay silence and watch you guys arguing every
little detail to death until there is clear concensus. I should stop
thinking constructively.


Updating the YANG Types RFC is a big deal.
IMO it should be done carefully. =C2=A0Publishing
I am concerned about a long-term module library maintenance nightmare.=

Unless there are lots of useful typedefs added to= RFC 6021-bis, I don't think
it is worth re-publishing. =C2= =A0Just make more module names. =C2=A0They are free.
A significant improvement to 6021bis would require some time to comple= te.

=C2=A0
/js

Andy

--14dae9cfcc3032911f04d096212a-- From lhotka@nic.cz Tue Dec 11 08:36:53 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B3FC21F8882 for ; Tue, 11 Dec 2012 08:36:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RNPkJ7nAT9Ew for ; Tue, 11 Dec 2012 08:36:52 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 892E321F887E for ; Tue, 11 Dec 2012 08:36:52 -0800 (PST) Received: from [172.20.26.113] (unknown [217.31.207.1]) by mail.nic.cz (Postfix) with ESMTPSA id 0E84713F968; Tue, 11 Dec 2012 17:36:51 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1355243811; bh=D1xKfpOjhw7+VCjyuAqgos2z/SUpPKSHxwlIv6TCbFo=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=IpmLqovPCoJs9wfRPtOcqVEfXUXK3KQE0Czog7xTUPUtIiPykEX0t2QLszTnFGTmL Ca8J4Ms/RtJvYMom880NkU6kWJ4gOWSdSg+ZHSK2uoxpOiD8R9zwSWOLgZa/pwDIwe JDovqHwvgOmNE3WDTTsqGqHY8M9Vuc9GX+aODtgw= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ladislav Lhotka In-Reply-To: Date: Tue, 11 Dec 2012 17:36:53 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20121211145713.GA52916@elstar.local> <20121211.162953.200903334.mbj@tail-f.com> <33E0A4AB-849A-4C29-A1F3-68A1622C24FB@nic.cz> To: Andy Bierman X-Mailer: Apple Mail (2.1499) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] IP addresses with zone indices X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 11 Dec 2012 16:36:53 -0000 On Dec 11, 2012, at 5:14 PM, Andy Bierman wrote: >=20 >=20 > On Tue, Dec 11, 2012 at 8:05 AM, Ladislav Lhotka = wrote: >=20 > On Dec 11, 2012, at 4:47 PM, Andy Bierman wrote: >=20 > > > > > > On Tue, Dec 11, 2012 at 7:29 AM, Martin Bjorklund = wrote: > > Andy Bierman wrote: > > > Perhaps, but republishing 6021 is a big deal, and probably needs = more than > > > 2 -3 weeks to conduct detailed reviews. I think option (1) or (2) = is > > > sufficient for the > > > 1 or 2 new types needed by the current modules. > > > > > > Updating 6021 doesn't seem realistic -- ever. > > > > Wow. > > > > > > If we can publish these typedefs in other modules (like ietf-ip), = why > > would moving them to 6021bis be such a big deal? > > > > > > IMO, moving a typedef is a really bad idea. > > I prefer these types be in ietf-ip-types.yang, but even if they are = in ietf-ip.yang, > > that is better than deprecating, then obsoleting them, and = cut-and-pasting > > new ones. Then every module using the deprecated typedef has to be = republished > > to use the new one instead. >=20 > Moving a type to "deprecated" status doesn't force modules that use = the type to immediately upgrade. So the type can be changed at the next = suitable occasion when the module is being republished anyway. >=20 >=20 > It has to be republished, which is a lot of overhead, > so it won't get done. Why? o "deprecated" indicates an obsolete definition, but it permits new/ continued implementation in order to foster interoperability with older/existing implementations. >=20 > The definition exists in 2 places for years, causing lots of > confusion. What is the point of moving a typedef anyway? > To reduce confusion and complexity? IMO it does the opposite. It would be a big problem to have generally useful definitions scattered = in a dozen or so modules. Importing a module is not without cost, given = all the issues with revisions. Lada >=20 > Lada >=20 >=20 > Andy >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From mbj@tail-f.com Tue Dec 11 09:19:34 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EAFD21F86D4 for ; Tue, 11 Dec 2012 09:19:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.946 X-Spam-Level: X-Spam-Status: No, score=-1.946 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tzuyJ-xFfU4Y for ; Tue, 11 Dec 2012 09:19:34 -0800 (PST) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id C304321F8505 for ; Tue, 11 Dec 2012 09:19:33 -0800 (PST) Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 1F34B1200AC8; Tue, 11 Dec 2012 18:19:32 +0100 (CET) Date: Tue, 11 Dec 2012 18:19:31 +0100 (CET) Message-Id: <20121211.181931.460124790.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20121211161540.GA53087@elstar.local> References: <20121211145713.GA52916@elstar.local> <20121211161540.GA53087@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] IP addresses with zone indices X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 11 Dec 2012 17:19:34 -0000 Juergen Schoenwaelder wrote: > What really kills progress in this WG is endless debate about > non-important little issues that should be much quicker to settle. +1 > We > seem to not have big pressure to deliver important things. Yep, I am > frustrated - why can't we say put the definition there, lets move > on? +1 > Perhaps I should just stay silence and watch you guys arguing every > little detail to death until there is clear concensus. I should stop > thinking constructively. Please. Can we try this process? It seems we have at least three people who would like to try, and one that does not. What do other people think? /martin From lhotka@nic.cz Tue Dec 11 09:41:26 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E2FE21F8782 for ; Tue, 11 Dec 2012 09:41:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l2B2F8RWh3fI for ; Tue, 11 Dec 2012 09:41:26 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id E600E21F850B for ; Tue, 11 Dec 2012 09:41:25 -0800 (PST) Received: from [172.20.26.113] (unknown [217.31.207.1]) by mail.nic.cz (Postfix) with ESMTPSA id A67C7140871; Tue, 11 Dec 2012 18:41:24 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1355247684; bh=dYSz8FG0b1IkdXh7JN3IYAKMQk2W+ijFwlG6y8k2Dqg=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=Ufki+RMGjxRZ5v7Wu/WvylQpqPTXztF/jZ+I9rCHxULR6oU5p1EE9TNDN5ZivA9fy oHYQWLWBbxsVI+qPk1v+oADBsEDLwUeNHzQEx1zGFrvdRHtUPOkgNt3TqOStqvIIcX jgIqD/Op4wvqT/ai+x+6/UOMyXrkHe6vwIPJnU4U= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ladislav Lhotka In-Reply-To: <20121211.181931.460124790.mbj@tail-f.com> Date: Tue, 11 Dec 2012 18:41:27 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20121211145713.GA52916@elstar.local> <20121211161540.GA53087@elstar.local> <20121211.181931.460124790.mbj@tail-f.com> To: Martin Bjorklund X-Mailer: Apple Mail (2.1499) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] IP addresses with zone indices X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 11 Dec 2012 17:41:26 -0000 On Dec 11, 2012, at 6:19 PM, Martin Bjorklund wrote: > Juergen Schoenwaelder wrote: >> What really kills progress in this WG is endless debate about >> non-important little issues that should be much quicker to settle. >=20 > +1 It is easy to agree with this claim, the problem is that people differ = in their assessment regarding which issues are small and which are big. >=20 >> We >> seem to not have big pressure to deliver important things. Yep, I am >> frustrated - why can't we say put the definition there, lets move >> on? >=20 > +1 >=20 >> Perhaps I should just stay silence and watch you guys arguing every >> little detail to death until there is clear concensus. I should stop >> thinking constructively. >=20 > Please. Can we try this process? It seems we have at least three > people who would like to try, and one that does not. What do other > people think? I don't know who is the one that does not, so just to make sure - it's = not me. Lada >=20 >=20 > /martin > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From andy@yumaworks.com Tue Dec 11 10:38:15 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5F8E21F8593 for ; Tue, 11 Dec 2012 10:38:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.835 X-Spam-Level: X-Spam-Status: No, score=-2.835 tagged_above=-999 required=5 tests=[AWL=0.141, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BimndrMNsXdM for ; Tue, 11 Dec 2012 10:38:15 -0800 (PST) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2BE6821F8573 for ; Tue, 11 Dec 2012 10:38:15 -0800 (PST) Received: by mail-ob0-f172.google.com with SMTP id za17so4196285obc.31 for ; Tue, 11 Dec 2012 10:38:14 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=IZX6Yygl0u0lPJlakjM7sLj+YKb5jaoj0HThBFlDgug=; b=P3UqV0ZXWjpt0lV+5bz/WOE4cwW6tVt/BI25SVHXhn0S6pV7RDQTqkExo4ITvBgrzK 7LsD5igWm2PNcw45UJVtpnFFsptkR/pVjBPqk/8QCazoZxRsVCbd1AZGo52j5BZ77MkR QnLadlsP9YCuk3oO8gTq8utjEzSxjVT/MhQr6K/mZOqhACoTrAo04gBhH5eBxeymagJo 7DDMcqZpPRLCPdpDAoFraozsCDWuqtVbUT7gkrkk+p3KVLFOuX107KtYhH/2lKqDAgl7 s8OarX6qWCd6X9TJEuF1BH/Y+1gQ/H70AfWW8KFS2W8WvuG7iGoc+LjrEvdzXcCG5a5E MuUw== MIME-Version: 1.0 Received: by 10.60.32.69 with SMTP id g5mr10208539oei.21.1355251094689; Tue, 11 Dec 2012 10:38:14 -0800 (PST) Received: by 10.76.167.167 with HTTP; Tue, 11 Dec 2012 10:38:14 -0800 (PST) In-Reply-To: <20121211.181931.460124790.mbj@tail-f.com> References: <20121211145713.GA52916@elstar.local> <20121211161540.GA53087@elstar.local> <20121211.181931.460124790.mbj@tail-f.com> Date: Tue, 11 Dec 2012 10:38:14 -0800 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: multipart/alternative; boundary=e89a8fb1fe541498f004d097fc9f X-Gm-Message-State: ALoCoQmNspgzLCw7N1Mf4Mjg3QcR/8sNNpMYXH7MeXU7X8xCxbmT0PTkUHDK3EKYT/LI39p/u+vc Cc: netmod@ietf.org Subject: Re: [netmod] IP addresses with zone indices X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 11 Dec 2012 18:38:15 -0000 --e89a8fb1fe541498f004d097fc9f Content-Type: text/plain; charset=UTF-8 So what is the problem that you are trying to solve? There are 1 or 2 IP related types and importing them from ietf-ip.yang is unacceptable? I don't think a tiny update of 6021-bis helps, and a full update takes some time to write and review, and maybe even a charter update. Andy On Tue, Dec 11, 2012 at 9:19 AM, Martin Bjorklund wrote: > Juergen Schoenwaelder wrote: > > What really kills progress in this WG is endless debate about > > non-important little issues that should be much quicker to settle. > > +1 > > > We > > seem to not have big pressure to deliver important things. Yep, I am > > frustrated - why can't we say put the definition there, lets move > > on? > > +1 > > > Perhaps I should just stay silence and watch you guys arguing every > > little detail to death until there is clear concensus. I should stop > > thinking constructively. > > Please. Can we try this process? It seems we have at least three > people who would like to try, and one that does not. What do other > people think? > > > /martin > --e89a8fb1fe541498f004d097fc9f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable So what is the problem that you are trying to solve?
There are 1 or 2 I= P related types and importing them
from ietf-ip.yang is unaccepta= ble?

I don't think a tiny update of 6021-bis h= elps, and a full update
takes some time to write and review, and maybe even a charter update.<= /div>

Andy
 --e89a8fb1fe541498f004d097fc9f-- From mbj@tail-f.com Tue Dec 11 11:43:41 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F87521F8608 for ; Tue, 11 Dec 2012 11:43:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.953 X-Spam-Level: X-Spam-Status: No, score=-1.953 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yEKP7FzZ0bGg for ; Tue, 11 Dec 2012 11:43:41 -0800 (PST) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id C68DD21F8566 for ; Tue, 11 Dec 2012 11:43:40 -0800 (PST) Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 4F13E1200AC8; Tue, 11 Dec 2012 20:43:38 +0100 (CET) Date: Tue, 11 Dec 2012 20:43:38 +0100 (CET) Message-Id: <20121211.204338.498175409.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: <20121211161540.GA53087@elstar.local> <20121211.181931.460124790.mbj@tail-f.com> X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] IP addresses with zone indices X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 11 Dec 2012 19:43:41 -0000 Andy Bierman wrote: > So what is the problem that you are trying to solve? Put the types where they belong. > There are 1 or 2 IP related types and importing them > from ietf-ip.yang is unacceptable? dotted-quad is not ip specific. > I don't think a tiny update of 6021-bis helps, and a full update > takes some time to write and review, and maybe even a charter update. 6021 has almost no text; the rfc is the yang modules. If the 6021bis editor thinks this is too much work to handle, I am sure he will speak up. The typedefs are the same so the reviwers have the same amount of work to do anyway. /martin From jonathan@hansfords.net Wed Dec 12 02:09:46 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2745C21F89A9 for ; Wed, 12 Dec 2012 02:09:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.998 X-Spam-Level: X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i2t2skZSY-ZF for ; Wed, 12 Dec 2012 02:09:45 -0800 (PST) Received: from avasout03.plus.net (avasout03.plus.net [84.93.230.244]) by ietfa.amsl.com (Postfix) with ESMTP id 0E67321F89A8 for ; Wed, 12 Dec 2012 02:09:44 -0800 (PST) Received: from webmail.plus.net ([84.93.228.147]) by avasout03 with smtp id aa9i1k0063BT6uC01a9ira; Wed, 12 Dec 2012 10:09:42 +0000 X-CM-Score: 0.00 X-CNFS-Analysis: v=2.0 cv=Z5cy6gtA c=1 sm=1 a=jSQgp9IWXRf89EXR5FPwJg==:17 a=F3ckWTiu8f8A:10 a=fIUNk3G47tUA:10 a=n7d1xWTCOeoA:10 a=0B8HqoTn75oA:10 a=6bkCdLdQAAAA:8 a=0Bzu9jTXAAAA:8 a=Xv9pVMa8PJcA:10 a=u07AKapRAAAA:8 a=48vgC7mUAAAA:8 a=Iac997GB5RUx4nTUNYYA:9 a=QEXdDO2ut3YA:10 a=XqebBV1NYWwA:10 a=zeshHG33Dl4A:10 a=lZB815dzVvQA:10 a=XjdJDpCdLsf3ai40w5kA:9 a=_W_S_7VecoQA:10 a=FMv19V3ji_16fgwM:21 a=jSQgp9IWXRf89EXR5FPwJg==:117 X-AUTH: hansfords+us:2500 Received: from host81-136-210-13.in-addr.btopenworld.com ([81.136.210.13]) by webmail.plus.net with HTTP (HTTP/1.1 POST); Wed, 12 Dec 2012 10:09:42 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_541b1e85fca80a535b132d420556dceb" Date: Wed, 12 Dec 2012 10:09:42 +0000 From: Jonathan Hansford To: In-Reply-To: References: <20121211145713.GA52916@elstar.local> <20121211161540.GA53087@elstar.local> <20121211.181931.460124790.mbj@tail-f.com> Message-ID: <765b7b152de8a9f20b5fe44a7b6e5c19@imap.plus.net> X-Sender: Jonathan@hansfords.net User-Agent: Roundcube Webmail/0.7.2 X-Originating-IP: [81.136.210.13] Subject: Re: [netmod] IP addresses with zone indices X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 12 Dec 2012 10:09:46 -0000 --=_541b1e85fca80a535b132d420556dceb Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=UTF-8 If the process represents a 4 to 6-week turnaround (if I remember correctly), then give it a try. In the scheme of things, a 6-week wait is nothing and if it proves the process works then we can have confidence in turning the handle each time the need arises. If it doesn't work (and we cannot fix it) then we'll know better in future and can confidently adopt an alternative approach. Jonathan On 11.12.2012 17:41, Ladislav Lhotka wrote: > On Dec 11, 2012, at 6:19 PM, Martin Bjorklund wrote: > >> Juergen Schoenwaelder wrote: >> >>> What really kills progress in this WG is endless debate about non-important little issues that should be much quicker to settle. >> +1 > > It is easy to agree with this claim, the problem is that people differ in their assessment regarding which issues are small and which are big. > >>> We seem to not have big pressure to deliver important things. Yep, I am frustrated - why can't we say put the definition there, lets move on? >> +1 >> >>> Perhaps I should just stay silence and watch you guys arguing every little detail to death until there is clear concensus. I should stop thinking constructively. >> Please. Can we try this process? It seems we have at least three people who would like to try, and one that does not. What do other people think? > > I don't know who is the one that does not, so just to make sure - it's not me. > > Lada > /martin _______________________________________________ netmod mailing list netmod@ietf.org [3] Links: ------ [1] mailto:j.schoenwaelder@jacobs-university.de [2] mailto:netmod@ietf.org [3] mailto:netmod@ietf.org --=_541b1e85fca80a535b132d420556dceb Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8

If the process represents a 4 to 6-week turnaround (if I remember correc= tly), then give it a try. In the scheme of things, a 6-week wait is nothing= and if it proves the process works then we can have confidence in turning = the handle each time the need arises. If it doesn't work (and we cannot fix= it) then we'll know better in future and can confidently adopt an alternat= ive approach.

Jonathan

On 11.12.2012 17:41, Ladislav Lhotka wrote:

On Dec 11, 2012, at 6:19 PM, Martin Bjorklund <mbj@tail-f.com> wrote:
Juergen Schoenwaelder <j.schoenwaelder@jacobs-univers= ity.de> wrote:
What really kills progress in this WG= is endless debate about non-important little issues that should be much qu= icker to settle.
+1
It is easy to agree with this claim, the problem is that people differ=
 in their assessment regarding which issues are small and which are big.



We seem to not have big pressure to d=
eliver important things. Yep, I am frustrated - why can't we say put the de=
finition there, lets move on?

+1

Perhaps I should just stay silence an=
d watch you guys arguing every little detail to death until there is clear =
concensus. I should stop thinking constructively.

Please. Can we try this process? It seems we have at least three people who=
 would like to try, and one that does not. What do other people think?

I don't know who is the one that does not, so just to make sure - it's=
 not me.

Lada


/martin _____________________________=
__________________ netmod mailing list n=
etmod@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=
=2Eorg/mailman/listinfo/netmod





 



--=_541b1e85fca80a535b132d420556dceb--


From ietfc@btconnect.com  Wed Dec 12 03:16:37 2012
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30A9E21F89E2 for ; Wed, 12 Dec 2012 03:16:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.356
X-Spam-Level: 
X-Spam-Status: No, score=-5.356 tagged_above=-999 required=5 tests=[AWL=1.243,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dQ98BphOk0y9 for ; Wed, 12 Dec 2012 03:16:34 -0800 (PST)
Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe006.messaging.microsoft.com [216.32.180.16]) by ietfa.amsl.com (Postfix) with ESMTP id 12F2F21F89E0 for ; Wed, 12 Dec 2012 03:16:33 -0800 (PST)
Received: from mail131-va3-R.bigfish.com (10.7.14.254) by VA3EHSOBE009.bigfish.com (10.7.40.29) with Microsoft SMTP Server id 14.1.225.23; Wed, 12 Dec 2012 11:16:27 +0000
Received: from mail131-va3 (localhost [127.0.0.1])	by mail131-va3-R.bigfish.com (Postfix) with ESMTP id 642C524019C; Wed, 12 Dec 2012 11:16:27 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:157.56.249.213; KIP:(null); UIP:(null); IPV:NLI; H:AM2PRD0710HT005.eurprd07.prod.outlook.com; RD:none; EFVD:NLI
X-SpamScore: -20
X-BigFish: PS-20(zz98dI9371I542I1432Izz1de0h1202h1e76h1d1ah1d2ahzz1033IL8275bh8275dhz2dh2a8h5a9h668h839h947hd24hf0ah1177h1179h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h1758h304l1155h)
Received: from mail131-va3 (localhost.localdomain [127.0.0.1]) by mail131-va3 (MessageSwitch) id 1355310985328343_10300; Wed, 12 Dec 2012 11:16:25 +0000 (UTC)
Received: from VA3EHSMHS029.bigfish.com (unknown [10.7.14.238])	by mail131-va3.bigfish.com (Postfix) with ESMTP id 46F68C0055; Wed, 12 Dec 2012 11:16:25 +0000 (UTC)
Received: from AM2PRD0710HT005.eurprd07.prod.outlook.com (157.56.249.213) by VA3EHSMHS029.bigfish.com (10.7.99.39) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 12 Dec 2012 11:16:22 +0000
Received: from DBXPRD0310HT005.eurprd03.prod.outlook.com (157.56.252.133) by pod51017.outlook.com (10.255.165.40) with Microsoft SMTP Server (TLS) id 14.16.245.2; Wed, 12 Dec 2012 11:16:21 +0000
Message-ID: <032e01cdd859$e34ee5a0$4001a8c0@gateway.2wire.net>
From: t.petch 
To: Juergen Schoenwaelder 
References: <20121210.202924.394214026.mbj@tail-f.com> <20121211094043.GA52035@elstar.local><20121211.104809.396474807.mbj@tail-f.com><20121211103041.GA52155@elstar.local><20121211145713.GA52916@elstar.local> <20121211161540.GA53087@elstar.local>
Date: Wed, 12 Dec 2012 11:13:39 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Originating-IP: [157.56.252.133]
X-OriginatorOrg: btconnect.com
Cc: netmod@ietf.org
Subject: Re: [netmod] IP addresses with zone indices
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 12 Dec 2012 11:16:37 -0000

----- Original Message -----
From: "Juergen Schoenwaelder" 
To: "Andy Bierman" 
Cc: 
Sent: Tuesday, December 11, 2012 4:15 PM
> On Tue, Dec 11, 2012 at 07:20:09AM -0800, Andy Bierman wrote:
> >
> > Updating 6021 doesn't seem realistic -- ever.
>
> Boy, now you are going extreme. I will agree only if the world stops
> spinning on December 21st.

The Mayan calendar reaches the end of its current cycle on 12th
December, which it is already where I am at present.  I am working on
the assumption that a fresh cycle will start so an update to 6021 will
happen.

Tom Petch



From ietfc@btconnect.com  Wed Dec 12 03:16:37 2012
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4383121F89E0 for ; Wed, 12 Dec 2012 03:16:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.712
X-Spam-Level: 
X-Spam-Status: No, score=-3.712 tagged_above=-999 required=5 tests=[AWL=-0.713, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EfXaZKo5l9b3 for ; Wed, 12 Dec 2012 03:16:34 -0800 (PST)
Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe003.messaging.microsoft.com [216.32.180.13]) by ietfa.amsl.com (Postfix) with ESMTP id 0C15221F89A3 for ; Wed, 12 Dec 2012 03:16:29 -0800 (PST)
Received: from mail146-va3-R.bigfish.com (10.7.14.240) by VA3EHSOBE003.bigfish.com (10.7.40.23) with Microsoft SMTP Server id 14.1.225.23; Wed, 12 Dec 2012 11:16:27 +0000
Received: from mail146-va3 (localhost [127.0.0.1])	by mail146-va3-R.bigfish.com (Postfix) with ESMTP id 048CB801F6; Wed, 12 Dec 2012 11:16:27 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:157.56.249.213; KIP:(null); UIP:(null); IPV:NLI; H:AM2PRD0710HT005.eurprd07.prod.outlook.com; RD:none; EFVD:NLI
X-SpamScore: -22
X-BigFish: PS-22(zz98dI9371I146fI542I1432I4015Izz1de0h1202h1e76h1d1ah1d2ahzz1033IL17326ah8275bh8275dhz2dh2a8h5a9h668h839h93fhd24hf0ah1177h1179h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h1758h304l1155h)
Received: from mail146-va3 (localhost.localdomain [127.0.0.1]) by mail146-va3 (MessageSwitch) id 1355310985261908_30521; Wed, 12 Dec 2012 11:16:25 +0000 (UTC)
Received: from VA3EHSMHS029.bigfish.com (unknown [10.7.14.254])	by mail146-va3.bigfish.com (Postfix) with ESMTP id 3A8092A0048; Wed, 12 Dec 2012 11:16:25 +0000 (UTC)
Received: from AM2PRD0710HT005.eurprd07.prod.outlook.com (157.56.249.213) by VA3EHSMHS029.bigfish.com (10.7.99.39) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 12 Dec 2012 11:16:22 +0000
Received: from DBXPRD0310HT005.eurprd03.prod.outlook.com (157.56.252.133) by pod51017.outlook.com (10.255.165.40) with Microsoft SMTP Server (TLS) id 14.16.245.2; Wed, 12 Dec 2012 11:16:20 +0000
Message-ID: <032d01cdd859$e2faf940$4001a8c0@gateway.2wire.net>
From: t.petch 
To: Andy Bierman , 
References: <2105C80D-48CA-494B-A62A-8A1BA5919D42@nic.cz><20121204.211903.458434883.mbj@tail-f.com><20121210.155754.589804255154826193.mbj@tail-f.com> 
Date: Wed, 12 Dec 2012 11:08:11 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Originating-IP: [157.56.252.133]
X-OriginatorOrg: btconnect.com
Subject: Re: [netmod] IP addresses with zone indices
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 12 Dec 2012 11:16:37 -0000

----- Original Message -----
From: "Andy Bierman" 
To: 
Sent: Monday, December 10, 2012 4:34 PM
> On Mon, Dec 10, 2012 at 7:22 AM, Ladislav Lhotka 
wrote:
>
> > Martin Bjorklund  writes:
> >
> > >> > Anyway, I don't understand why such a type would belong to
either
> > >> > ietf-ip or ietf-inet-types.
> > >>
> > >> Because then we can avoid having the same pattern in multiple
> > >> places. What's wrong on such a type? I think it is quite
> > >> comparable to types like "uint32" which also have no special
> > >> semantics.
> > >
> > > My point was that it is not clear why it would be defined in
ietf-ip
> > > or ietf-inet.  There is no ip or inet specific semantics
associated
> > > with this type.  ietf-yang would be a better place for it...  But
see
> > > below.
> >
> > I agree, such a type probably belongs to ietf-inet-types, but we
can't
> > afford a new downref to 6021bis now. The scenario could IMO look
like this:
> >
> > 1. Define this type temporarily in ietf-ip and use where necessary;
> > 2. Add it also to ietf-inet-types;
> > 3. After 6021bis is published, change "ip:dotted-quad" to
> > "inet:dotted-quad" in next revisions of ietf-ip, ietf-routing etc;
> > 4. Obsolete "ip:dotted-quad".
> >
> A: deploying standards is very expensive.  Temporary fixes last 10 -
20
> years around here.
> There is no such thing.  Get it right the first time or pay the price
for
> many years to come.

Yes, or perhaps YES YES YES (with whatever the emoticon is for extreme
anguish).

Perhaps because I have been doing this sort of thing for decades, I have
decades of experience of paying the price, which I would rather not have
had; so yes, get it right first time.

Tom Petch

> B: There happens to be a 6021bis draft:
> http://www.ietf.org/id/draft-schoenw-netmod-rfc6021-bis-00.txt
> It adds 'hex-string' and 'uuid' to ietf-yang-types.yang.
> (A 'Changes Since RFC 6021' section would make that more clear.)
>
> There are many useful typedefs in the common-types.yang module in
> the proposed ACL draft.
> http://www.ietf.org/id/draft-huang-netmod-acl-01.txt
>
> I don't know how practical it is to re-open 6021 every time the WG
thinks of
> a new typedef to add.  But it seems easier than chartering and
publishing
> new work,
> and it is better for YANG developers to keep the standard types in a
lot
> of random modules.
>
> I don't agree with any of the 4 options above. I prefer:
>
> 5) work on 6021bis for a short time (1 - 2 months) and
> publish reusable data types only in 1 place (6021bis).
>
>
> Andy
>
> Could this work?
> >
> > >
> > >
> > >> > For now, I think the quickest way forward is to solve this
separately
> > >> > in each module.
> > >>
> > >> If you define the above type in ietf-ip, then I can reuse it -
> > >> ietf-routing already imports ietf-ip. Would this be any slower?
> > >
> > > Ok, I'd like to make progress, so I am prepared to define this
type in
> > > ietf-ip, and use it for the netmask.
> >
> > Good, I'm going to use it for "router-id".
> >
> > Thanks, Lada
> >
> > >
> > >
> > > /martin
> >
> > --
> > 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
>



From ietfc@btconnect.com  Wed Dec 12 03:16:39 2012
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B6DB21F89E5 for ; Wed, 12 Dec 2012 03:16:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.932
X-Spam-Level: 
X-Spam-Status: No, score=-3.932 tagged_above=-999 required=5 tests=[AWL=-0.333, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2wImA7rDBQeT for ; Wed, 12 Dec 2012 03:16:35 -0800 (PST)
Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe002.messaging.microsoft.com [216.32.180.12]) by ietfa.amsl.com (Postfix) with ESMTP id 00BF621F89DF for ; Wed, 12 Dec 2012 03:16:34 -0800 (PST)
Received: from mail103-va3-R.bigfish.com (10.7.14.250) by VA3EHSOBE008.bigfish.com (10.7.40.28) with Microsoft SMTP Server id 14.1.225.23; Wed, 12 Dec 2012 11:16:27 +0000
Received: from mail103-va3 (localhost [127.0.0.1])	by mail103-va3-R.bigfish.com (Postfix) with ESMTP id 923DF4C0072; Wed, 12 Dec 2012 11:16:27 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:157.56.249.213; KIP:(null); UIP:(null); IPV:NLI; H:AM2PRD0710HT005.eurprd07.prod.outlook.com; RD:none; EFVD:NLI
X-SpamScore: -20
X-BigFish: PS-20(zz98dI9371I542I1432Izz1de0h1202h1e76h1d1ah1d2ahzz1033IL8275dhz2dh2a8h5a9h668h839h947hd24hf0ah1177h1179h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h1758h304l1155h)
Received: from mail103-va3 (localhost.localdomain [127.0.0.1]) by mail103-va3 (MessageSwitch) id 1355310985115274_653; Wed, 12 Dec 2012 11:16:25 +0000 (UTC)
Received: from VA3EHSMHS029.bigfish.com (unknown [10.7.14.236])	by mail103-va3.bigfish.com (Postfix) with ESMTP id 0FE59C0050; Wed, 12 Dec 2012 11:16:25 +0000 (UTC)
Received: from AM2PRD0710HT005.eurprd07.prod.outlook.com (157.56.249.213) by VA3EHSMHS029.bigfish.com (10.7.99.39) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 12 Dec 2012 11:16:21 +0000
Received: from DBXPRD0310HT005.eurprd03.prod.outlook.com (157.56.252.133) by pod51017.outlook.com (10.255.165.40) with Microsoft SMTP Server (TLS) id 14.16.245.2; Wed, 12 Dec 2012 11:16:20 +0000
Message-ID: <032c01cdd859$e29f6bc0$4001a8c0@gateway.2wire.net>
From: t.petch 
To: Juergen Schoenwaelder , 
References: <20121210170213.GG49658@elstar.local><20121210191906.GB50035@elstar.local><20121210.202924.394214026.mbj@tail-f.com> <20121211094043.GA52035@elstar.local>  <20121211142656.GB52721@elstar.local>
Date: Wed, 12 Dec 2012 10:53:20 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Originating-IP: [157.56.252.133]
X-OriginatorOrg: btconnect.com
Subject: Re: [netmod] IP addresses with zone indices
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 12 Dec 2012 11:16:39 -0000

----- Original Message -----
From: "Juergen Schoenwaelder" 
To: 
Sent: Tuesday, December 11, 2012 2:26 PM

> On Tue, Dec 11, 2012 at 02:14:27PM +0100, Ladislav Lhotka wrote:
> > >
> > > Speaking as 6021bis editor: A type that is used by multiple data
> > > models without being highly technology specific or modeling
something
> > > controlled by IANA is a decent candidate for inclusion in 6021bis.
I
> > > do not see a problem to add a dotted quad type to ietf-yang-types,
> > > probably with some additional text that for IPv4 addresses, the
> > > specific type provided by the ietf-inet-types module must be used.
> >
> > I agree, but maybe the right place for the dotted-quad type is
ietf-inet-types because I don't remember seeing it outside the
Internet/IP context. Even IS-IS uses its own NSAP address for both
router-id and area-id.
> >
>
> But there is no reason to limit dotted-quad to IP only. In fact, a
> dotted-quad is a special case of a dot-decimal notation, which we for
> example use of OIDs. I would rather not 'restrict' its usage to IP
> since the definition of the type truely is generic.

Juergen

Two of the examples I quoted earlier are not strictly IP.  They identify
MPLS switches and there is a requirement that these can operate in boxes
with no IP support.  Of course, there will likely be IP support
somewhere, for management protocols, but boxes in the middle of an LSP
can be identified by dot-decimal notation but have no IP capability in
them, being controlled by non-IP control protocols.

Tom Petch

>
> /js
>
> --



From andy@yumaworks.com  Wed Dec 12 03:48:16 2012
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9145521F8901 for ; Wed, 12 Dec 2012 03:48:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.542
X-Spam-Level: 
X-Spam-Status: No, score=-2.542 tagged_above=-999 required=5 tests=[AWL=-0.166, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S88+APDq44nW for ; Wed, 12 Dec 2012 03:48:15 -0800 (PST)
Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 91C7621F8900 for ; Wed, 12 Dec 2012 03:48:15 -0800 (PST)
Received: by mail-vc0-f172.google.com with SMTP id fw7so611934vcb.31 for ; Wed, 12 Dec 2012 03:48:15 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=xjn+de/eCrHPiUVYRCDsFZNSFc4gxasUFE6awV08PdY=; b=k5m76H7rY4IwYhd1bl4NKmtCU9URf0UEOHskYkTEa4PGsklvtXWu4RxiONA+m4D/HM Mp5zms6ru9oDILPcD7bmPw2369ud3jYqBz9Iy9uziwieDjSYOg5JdHy3g69VACx/oXLU Csu6Khnvzc52rYxlXL1KJvpn0FTvyHGXcvT+kcG6ddsBdVh2LN2uGvcOE/SBFsPE25MI BDc0LvaIDytwRwwtBLCfKM8fBvOv1ef052x5IbeKLjjoLEnzk+5amC4Eu+uD4VD4Wq2v h/+HUuGV4APAyZmi9LTyp0oEWfq0twQaLCDJEVp5qFFjQWaXCYOvpbyn8dToTuQHpm52 bdqA==
MIME-Version: 1.0
Received: by 10.52.97.230 with SMTP id ed6mr305505vdb.90.1355312894975; Wed, 12 Dec 2012 03:48:14 -0800 (PST)
Received: by 10.58.46.204 with HTTP; Wed, 12 Dec 2012 03:48:14 -0800 (PST)
In-Reply-To: <765b7b152de8a9f20b5fe44a7b6e5c19@imap.plus.net>
References: <20121211145713.GA52916@elstar.local>  <20121211161540.GA53087@elstar.local> <20121211.181931.460124790.mbj@tail-f.com>  <765b7b152de8a9f20b5fe44a7b6e5c19@imap.plus.net>
Date: Wed, 12 Dec 2012 03:48:14 -0800
Message-ID: 
From: Andy Bierman 
To: Jonathan Hansford 
Content-Type: multipart/alternative; boundary=20cf307ac437aa1ecc04d0a65f9c
X-Gm-Message-State: ALoCoQlE7egwMvLQueTG+BTdzDfc/k6ljCLU/nVAXaE9ZTCeR2GSNU0MezrOWg9p3XjI0q0iEvMb
Cc: netmod@ietf.org
Subject: Re: [netmod] IP addresses with zone indices
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 12 Dec 2012 11:48:16 -0000

--20cf307ac437aa1ecc04d0a65f9c
Content-Type: text/plain; charset=UTF-8

On Wed, Dec 12, 2012 at 2:09 AM, Jonathan Hansford
wrote:

> **
>
> If the process represents a 4 to 6-week turnaround (if I remember
> correctly), then give it a try. In the scheme of things, a 6-week wait is
> nothing and if it proves the process works then we can have confidence in
> turning the handle each time the need arises. If it doesn't work (and we
> cannot fix it) then we'll know better in future and can confidently adopt
> an alternative approach.
>

The ACL draft has a module called common-types.yang.
http://www.ietf.org/id/draft-huang-netmod-acl-01.txt

It has the following typedefs:

   - cos
   - tos
   - precedence
   - tcp-flag-type
   - ether-type
   - ip-protocol
   - igmp-code
   - icmp-code
   - vlan-identifier
   - time-to-live

I don't know how many proposals there will be in 2 weeks, there here are 10
published typedefs
to consider adding to 6021-bis.  Will there be 15 typedefs to review or 50?
 If there are no more
than 15 typedef proposals then I agree this can be finished quickly.

Jonathan
>

Andy


> On 11.12.2012 17:41, Ladislav Lhotka wrote:
>
> On Dec 11, 2012, at 6:19 PM, Martin Bjorklund  wrote:
>
> Juergen Schoenwaelder  wrote:
>
> What really kills progress in this WG is endless debate about
> non-important little issues that should be much quicker to settle.
>
> +1
>
> It is easy to agree with this claim, the problem is that people differ in their assessment regarding which issues are small and which are big.
>
>  We seem to not have big pressure to deliver important things. Yep, I am
> frustrated - why can't we say put the definition there, lets move on?
>
> +1
>
> Perhaps I should just stay silence and watch you guys arguing every little
> detail to death until there is clear concensus. I should stop thinking
> constructively.
>
> Please. Can we try this process? It seems we have at least three people
> who would like to try, and one that does not. What do other people think?
>
> I don't know who is the one that does not, so just to make sure - it's not me.
>
> 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 listnetmod@ietf.orghttps://www.ietf.org/mailman/listinfo/netmod
>
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>
>

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



On Wed, Dec 12, 2012 at 2:09 AM, Jonatha=
n Hansford <Jonathan@hansfords.net> wrote:





If the process represents a 4 to 6-week turnaround (if I remember correc=
tly), then give it a try. In the scheme of things, a 6-week wait is nothing=
 and if it proves the process works then we can have confidence in turning =
the handle each time the need arises. If it doesn't work (and we cannot=
 fix it) then we'll know better in future and can confidently adopt an =
alternative approach.

The ACL draft has a module called co= mmon-types.yang.
http://www.ietf.org/id/draft-huang-netmod-acl-01.txt

It has the following typedefs:
  • cos
  • tos
  • precedence
  • tcp-flag-type
  • ether-type
    • <= li>ip-protocol
  • igmp-code
  • icmp-code
  • vlan-identifier<= /li>
  • time-to-live
I don't know how many proposals there wi= ll be in 2 weeks, there here are 10 published typedefs
to c= onsider adding to 6021-bis. =C2=A0Will there be 15 typedefs to review or 50= ? =C2=A0If there are no more
than 15 typedef proposals then I agree this can be finished quickly.

Jonathan


Andy
=C2=A0=

On 11.12.2012 17:41, Ladislav Lhotka wrote:

On Dec 11, 2012, at 6:19 PM, Martin Bjorklund <mbj@tail-f.com> wrote:
Juergen Schoenwaelder <j.schoenwaelder= @jacobs-university.de> wrote:
What really kills progress in this WG is= endless debate about non-important little issues that should be much quick= er to settle.
+1
It is easy to agree with this claim, the problem is that people differ=
 in their assessment regarding which issues are small and which are big.



We seem to not have big pressure to deli=
ver important things. Yep, I am frustrated - why can't we say put the d=
efinition there, lets move on?


+1

Perhaps I should just stay silence and w=
atch you guys arguing every little detail to death until there is clear con=
census. I should stop thinking constructively.


Please. Can we try this process? It seems we have at least three people who=
 would like to try, and one that does not. What do other people think?

I don't know who is the one that does not, so just to make sure - =
it's not me.

Lada


/martin ________________________________=
_______________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/net=
mod



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




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





=C2=A0

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


--20cf307ac437aa1ecc04d0a65f9c-- From j.schoenwaelder@jacobs-university.de Wed Dec 12 06:06:12 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 214EF21F8A32 for ; Wed, 12 Dec 2012 06:06:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.883 X-Spam-Level: X-Spam-Status: No, score=-102.883 tagged_above=-999 required=5 tests=[AWL=0.366, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u8Dn7b7bS01w for ; Wed, 12 Dec 2012 06:06:11 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 2503A21F8A28 for ; Wed, 12 Dec 2012 06:06:11 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8271120C15 for ; Wed, 12 Dec 2012 15:06:04 +0100 (CET) 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 vQHy_H1ZnP8u for ; Wed, 12 Dec 2012 15:06:04 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 545E520BF1 for ; Wed, 12 Dec 2012 15:06:04 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 5FB7D23690BB; Wed, 12 Dec 2012 15:06:12 +0100 (CET) Resent-From: Juergen Schoenwaelder Resent-Date: Wed, 12 Dec 2012 15:06:12 +0100 Resent-Message-ID: <20121212140612.GA58677@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.318.4; Wed, 12 Dec 2012 15:05:07 +0100 Received: from atlas2.jacobs-university.de (atlas2a.jacobs-university.de [212.201.44.15]) by hermes.jacobs-university.de (Postfix) with ESMTP id B213D20BF1 for ; Wed, 12 Dec 2012 15:05:14 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by atlas2.jacobs-university.de (Postfix) with ESMTP id ACF066B8 for ; Wed, 12 Dec 2012 15:05:14 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Authentication-Results: demetrius3.jacobs-university.de (amavisd-new); dkim=pass (1024-bit key) header.d=ietf.org Received: from atlas2a.jacobs-university.de ([212.201.44.15]) by localhost (demetrius3.jacobs-university.de [212.201.44.48]) (amavisd-new, port 10030) with ESMTP id Ue754w2ag0T8 for ; Wed, 12 Dec 2012 15:05:13 +0100 (CET) X-JacobsISPWhiteListed: No X-policyd-weight: using cached result; rate:hard: -7.6 Received: from mail.ietf.org (mail.ietf.org [64.170.98.30]) by atlas2a.jacobs-university.de (Postfix) with ESMTP for ; Wed, 12 Dec 2012 15:05:13 +0100 (CET) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F7AA21F89A0; Wed, 12 Dec 2012 06:04:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1355321082; bh=Wb/XKb6MZWTrXsRy7QnoqRtXLu+4P2UT1uuoKemAuLA=; h=MIME-Version:From:To:Subject:Message-ID:Date:Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=dBCG5dPRpu8z4ng8Ulbj+so84plnbd6X6j7YC5fSrpO12mlBq7OBj+yridYL0aP8v 3bsjZdUpw9Ian6OHYIKPzI7wN5FYlDyEl0ne/1Dk+HY74L5NoRoGW9KsuQ73BlQu4m K7yeCWYc7RBDlrQajL2SWD0w7juNPtRX5xDIee68= X-Original-To: i-d-announce@ietfa.amsl.com Delivered-To: i-d-announce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BBFA21F89A8 for ; Wed, 12 Dec 2012 06:04:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QycyV3Cp7rLS for ; Wed, 12 Dec 2012 06:04:38 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D3A721F8516 for ; Wed, 12 Dec 2012 06:04:38 -0800 (PST) From: To: X-Test-IDTracker: no X-IETF-IDTracker: 4.36 Message-ID: <20121212140438.11727.32276.idtracker@ietfa.amsl.com> Date: Wed, 12 Dec 2012 06:04:38 -0800 X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: Errors-To: i-d-announce-bounces@ietf.org X-MS-Exchange-Organization-AuthSource: SHUBCAS05.jacobs.jacobs-university.de X-MS-Exchange-Organization-AuthAs: Anonymous MIME-Version: 1.0 Subject: [netmod] I-D Action: draft-schoenw-netmod-rfc6021-bis-01.txt X-BeenThere: netmod@ietf.org Reply-To: internet-drafts@ietf.org List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 14:06:12 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Common YANG Data Types Author(s) : Juergen Schoenwaelder Filename : draft-schoenw-netmod-rfc6021-bis-01.txt Pages : 36 Date : 2012-12-12 Abstract: This document introduces a collection of common data types to be used with the YANG data modeling language. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-schoenw-netmod-rfc6021-bis There's also a htmlized version available at: http://tools.ietf.org/html/draft-schoenw-netmod-rfc6021-bis-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-schoenw-netmod-rfc6021-bis-01 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 alex@cisco.com Thu Dec 20 17:26:58 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB21B21F889C for ; Thu, 20 Dec 2012 17:26:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l8hWQkj7t8f2 for ; Thu, 20 Dec 2012 17:26:57 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id B457A21F86B4 for ; Thu, 20 Dec 2012 17:26:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7682; q=dns/txt; s=iport; t=1356053217; x=1357262817; h=from:to:subject:date:message-id:mime-version; bh=ryZ1lKdeq51szDM+9NZ/NK2yYGwCzspBTFrLavJNmII=; b=gun2Sj5/yHIBTZcP7wbBJoP1u9t02UzqAktOTY0NHVDAShCNL0bI36uD wB7YAuPFfs8CN3cGFD6dR9Xk0cTzLeid8IYLp0L/CF2oojCnQddBnQITK WZyuTHvyERvpbR4Iwn4v6+70IPGm0NhI9ouGe6IN6GB3nkQJTMh602NF3 k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAFK601CtJV2Z/2dsb2JhbABFgkm7KBZzgiABBC0+IAEqViYBBBuIC5YHoV6QOWEDplOCdIIi X-IronPort-AV: E=Sophos;i="4.84,327,1355097600"; d="scan'208,217";a="155314670" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-7.cisco.com with ESMTP; 21 Dec 2012 01:26:57 +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 qBL1Qvtk031324 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 21 Dec 2012 01:26:57 GMT Received: from xmb-rcd-x05.cisco.com ([169.254.15.161]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.02.0318.004; Thu, 20 Dec 2012 19:26:56 -0600 From: "Alexander Clemm (alex)" To: "netmod@ietf.org" Thread-Topic: YANG question Thread-Index: Ac3fGESj6b8maG8TTO24e/HxwE6dfA== Date: Fri, 21 Dec 2012 01:26:56 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.154.201.58] Content-Type: multipart/alternative; boundary="_000_DBC595ED2346914F9F81D17DD5C32B570F57F43Fxmbrcdx05ciscoc_" MIME-Version: 1.0 Subject: [netmod] YANG question X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 21 Dec 2012 01:26:59 -0000 --_000_DBC595ED2346914F9F81D17DD5C32B570F57F43Fxmbrcdx05ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello YANG experts, I have a quick question: is it possible to specify for an augmentation of = a list, that the augmenting information needs to be unique? I would like to do something like (to modify the example in RFC 6020 slighl= y) import interface-module { prefix "if"; } augment "/if:interfaces/if:ifEntry" { when "if:ifType=3D'foobar'"; unique "foobarNumber"; leaf foobarNumber { type foobarNumber; } } Can I do this? RFC 6020 section 7.15.1 does not list "unique" under the su= bstatements that are allowed. On the other hand, the "uniqueness" property= does not refer to information in the augmented module (which would be unde= rstandably illegal to introduce), but only in the information that is added= . How can I accomplish what I need to do? Thanks --- Alex --_000_DBC595ED2346914F9F81D17DD5C32B570F57F43Fxmbrcdx05ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello YANG experts,

 

I have a quick question:  is it possible to spe= cify for an augmentation of a list, that the augmenting information needs t= o be unique?

 

I would like to do something like (to modify the exa= mple in RFC 6020 slighly)

 

  = ;   import interface-module {

  = ;       prefix "if";

  = ;   }

  = ;   augment "/if:interfaces/if:ifEntry" {

  = ;       when "if:ifType=3D'foobar'"= ;

  = ;       unique “foobarNumber”;

  = ;       leaf foobarNumber {=

  = ;           type foobarNu= mber;

  = ;       }

  = ;   }

 =

Can I do th= is?  RFC 6020 section 7.15.1 does not list “unique” under = the substatements that are allowed.  On the other hand, the “uni= queness” property does not refer to information in the augmented module (which woul= d be understandably illegal to introduce), but only in the information that= is added. 

 =

How can I a= ccomplish what I need to do?

 =

Thanks=

--- Alex

 

--_000_DBC595ED2346914F9F81D17DD5C32B570F57F43Fxmbrcdx05ciscoc_-- From yihuan@cisco.com Thu Dec 20 22:30:06 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC24B21F8A9A for ; Thu, 20 Dec 2012 22:30:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cSKwA5O6tGV6 for ; Thu, 20 Dec 2012 22:30:05 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id A413821F8A95 for ; Thu, 20 Dec 2012 22:30:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11608; q=dns/txt; s=iport; t=1356071405; x=1357281005; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=lVOpUM0R1LQgBwv27fak34FnfrFxPbdD/BhK4txgfZU=; b=TFhHtTW09Ghogmx+S1kWgaJsP4P2nz80oN0Z6PnOnZzjE4WtSQO//Yne mFjp8oUoSesIGKA1jdrBq02GdEc4t5rK6GqJFca4foX01r6eIrEFJ+6T0 9gt2zK+48vdMGRyRWxwgPGw6bqWnK8lG37Tclb2+CWCg3e6Hq1JvNAj0B k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAIQB1FCtJXG9/2dsb2JhbABEgkm7KxZzgh4BAQEELT4gAQgRAwECCx05FAkIAQEEARIIiAu3RIxXg2JhA6ZTgnSCIg X-IronPort-AV: E=Sophos;i="4.84,328,1355097600"; d="scan'208,217";a="155407268" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-3.cisco.com with ESMTP; 21 Dec 2012 06:30:05 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id qBL6U4Zo027782 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 21 Dec 2012 06:30:05 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.209]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.02.0318.004; Fri, 21 Dec 2012 00:30:04 -0600 From: "Lisa Huang (yihuan)" To: "Alexander Clemm (alex)" , "netmod@ietf.org" Thread-Topic: [netmod] YANG question Thread-Index: Ac3fGESj6b8maG8TTO24e/HxwE6dfAAG5MgA Date: Fri, 21 Dec 2012 06:30:04 +0000 Message-ID: <559E176269AD64429F1582D4EB94F86FBBF4C4@xmb-aln-x03.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.21.166.61] Content-Type: multipart/alternative; boundary="_000_559E176269AD64429F1582D4EB94F86FBBF4C4xmbalnx03ciscocom_" MIME-Version: 1.0 Subject: Re: [netmod] YANG question X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 21 Dec 2012 06:30:07 -0000 --_000_559E176269AD64429F1582D4EB94F86FBBF4C4xmbalnx03ciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Alex, Where did you see "uniqueness=94 property does not refer to information in = the augmented module" in RFC 6020? Since unique could apply to optional leaf, I do not understand why it can n= ot apply to augment module ( but as you said, section 7.15.1 does not list = "unique" in the sub statements. I could not think of another way as both must and unique are not allowed in= 7.15.1 Thanks, Lisa From: "Alexander Clemm (alex)" > Date: Thursday, December 20, 2012 5:26 PM To: "netmod@ietf.org" > Subject: [netmod] YANG question Hello YANG experts, I have a quick question: is it possible to specify for an augmentation of = a list, that the augmenting information needs to be unique? I would like to do something like (to modify the example in RFC 6020 slighl= y) import interface-module { prefix "if"; } augment "/if:interfaces/if:ifEntry" { when "if:ifType=3D'foobar'"; unique =93foobarNumber=94; leaf foobarNumber { type foobarNumber; } } Can I do this? RFC 6020 section 7.15.1 does not list =93unique=94 under th= e substatements that are allowed. On the other hand, the =93uniqueness=94 = property does not refer to information in the augmented module (which would= be understandably illegal to introduce), but only in the information that = is added. How can I accomplish what I need to do? Thanks --- Alex --_000_559E176269AD64429F1582D4EB94F86FBBF4C4xmbalnx03ciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <9E897A8B96D1F246B7AC03CD7B4B8014@cisco.com> Content-Transfer-Encoding: quoted-printable Enscript Output 
Alex,

Where did you see "uniqueness=94 property does not refer to information in the augme=
nted module" in RFC 6020?

Since unique could apply to optiona=
l leaf, I do not understand why it can not apply to augment module ( but as=
 you said, section 7.15.1 does not list "unique" in the sub state=
ments.

I could not think of another way as=
 both must and unique are not allowed in 7.15.1

Thanks,

Lisa

From: "Alexander Clemm (alex)&= quot; <alex@cisco.com>
Date: Thursday, December 20, 2012 5= :26 PM
To: "netmod@ietf.org" <= netmod@ietf.org>
Subject: [netmod] YANG question

Hello YANG experts,

 

I have a quick question:  is it possible to spe= cify for an augmentation of a list, that the augmenting information needs t= o be unique?

 

I would like to do something like (to modify the exa= mple in RFC 6020 slighly)

 

   =   import interface-module {

   =       prefix "if";

   =   }

   =   augment "/if:interfaces/if:ifEntry" {

   =       when "if:ifType=3D'foobar'";<= /o:p>

   =       unique =93foobarNumber=94;=

   =      leaf foobarNumber {

   =           type foobarNumber;

   =       }

   =   }

 <= /span>

Can I do this?&nbs= p; RFC 6020 section 7.15.1 does not list =93unique=94 under the substatemen= ts that are allowed.  On the other hand, the =93uniqueness=94 property does not refer to information in the augmented module (which woul= d be understandably illegal to introduce), but only in the information that= is added. 

 <= /span>

How can I accompli= sh what I need to do?

 <= /span>

Thanks<= /span>

--- Alex

 

 --_000_559E176269AD64429F1582D4EB94F86FBBF4C4xmbalnx03ciscocom_-- From mbj@tail-f.com Thu Dec 20 23:26:59 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC4EC21F8AD1 for ; Thu, 20 Dec 2012 23:26:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.959 X-Spam-Level: X-Spam-Status: No, score=-1.959 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gu1-HnumRJPo for ; Thu, 20 Dec 2012 23:26:59 -0800 (PST) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 2F47321F8ABD for ; Thu, 20 Dec 2012 23:26:59 -0800 (PST) Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 0910D12008F7; Fri, 21 Dec 2012 08:26:57 +0100 (CET) Date: Fri, 21 Dec 2012 08:26:56 +0100 (CET) Message-Id: <20121221.082656.473772804.mbj@tail-f.com> To: alex@cisco.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] YANG question X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 21 Dec 2012 07:26:59 -0000 Hi, "Alexander Clemm (alex)" wrote: > Hello YANG experts, > > I have a quick question: is it possible to specify for an augmentation of a > list, that the augmenting information needs to be unique? > > I would like to do something like (to modify the example in RFC 6020 slighly) > > import interface-module { > prefix "if"; > } > augment "/if:interfaces/if:ifEntry" { > when "if:ifType='foobar'"; > unique "foobarNumber"; > leaf foobarNumber { > type foobarNumber; > } > } > > Can I do this? No, unfortunately. (I am sure Lada can come up with an XPath expression involving preceding-sibling or something that solves this :) /martin From jernej.tuljak@mg-soft.si Fri Dec 21 01:04:00 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA7CC21F8546 for ; Fri, 21 Dec 2012 01:04:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id irLNnB2z7Yb2 for ; Fri, 21 Dec 2012 01:03:59 -0800 (PST) Received: from gate.mg-soft.si (gate.mg-soft.si [212.30.73.66]) by ietfa.amsl.com (Postfix) with ESMTP id E555D21F850C for ; Fri, 21 Dec 2012 01:03:58 -0800 (PST) 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 qBL93rjb031814; Fri, 21 Dec 2012 10:03:53 +0100 Message-ID: <50D425EC.1020903@mg-soft.com> Date: Fri, 21 Dec 2012 10:03:40 +0100 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: "Alexander Clemm (alex)" References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------090202070908020905050003" Cc: "netmod@ietf.org" Subject: Re: [netmod] YANG question X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 21 Dec 2012 09:04:01 -0000 This is a multi-part message in MIME format. --------------090202070908020905050003 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dne 21.12.2012 2:26, pis(e Alexander Clemm (alex): > > Hello YANG experts, > > I have a quick question: is it possible to specify for an > augmentation of a list, that the augmenting information needs to be > unique? > > I would like to do something like (to modify the example in RFC 6020 > slighly) > > import interface-module { > > prefix "if"; > > } > > augment "/if:interfaces/if:ifEntry" { > > when "if:ifType='foobar'"; > > unique "foobarNumber"; > > leaf foobarNumber { > > type foobarNumber; > > } > > } > > Can I do this? RFC 6020 section 7.15.1 does not list "unique" under > the substatements that are allowed. On the other hand, the > "uniqueness" property does not refer to information in the augmented > module (which would be understandably illegal to introduce), but only > in the information that is added. > > How can I accomplish what I need to do? > Like Martin already suggested you can work around this by putting a must-stmt constaint on valid foobarNumber data nodes, not on the list itself. For your example that would probably be the following statement block as a child to leaf foobarNumber: must "not(parent::if:ifEntry/preceding-sibling::if:ifEntry[current()=pfx:foobarNumber])" { error-message "Violated uniqueness constraint for pfx:foobarNumber" } where pfx is the prefix of the augmenting module. However, I'm not entirely sure how you would handle a multi-valued unique (if you augmented two leafs and wanted both of them to be part of the same uniqueness constraint). That would probably require some more thinking. Jernej > Thanks > > --- Alex > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod --------------090202070908020905050003 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Dne 21.12.2012 2:26, piše Alexander Clemm (alex):

Hello YANG experts,

 

I have a quick question:  is it possible to specify for an augmentation of a list, that the augmenting information needs to be unique?

 

I would like to do something like (to modify the example in RFC 6020 slighly)

 

     import interface-module {

         prefix "if";

     }

     augment "/if:interfaces/if:ifEntry" {

         when "if:ifType='foobar'";

         unique “foobarNumber”;

         leaf foobarNumber {

             type foobarNumber;

         }

     }

 

Can I do this?  RFC 6020 section 7.15.1 does not list “unique” under the substatements that are allowed.  On the other hand, the “uniqueness” property does not refer to information in the augmented module (which would be understandably illegal to introduce), but only in the information that is added. 

 

How can I accomplish what I need to do?


Like Martin already suggested you can work around this by putting a must-stmt constaint on valid foobarNumber data nodes, not on the list itself. For your example that would probably be the following statement block as a child to leaf foobarNumber:

must "not(parent::if:ifEntry/preceding-sibling::if:ifEntry[current()=pfx:foobarNumber])" {
    error-message "Violated uniqueness constraint for pfx:foobarNumber"
}

where pfx is the prefix of the augmenting module.

However, I'm not entirely sure how you would handle a multi-valued unique (if you augmented two leafs and wanted both of them to be part of the same uniqueness constraint). That would probably require some more thinking.

Jernej

 

Thanks

--- Alex

 



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

--------------090202070908020905050003-- From mbj@tail-f.com Fri Dec 21 02:03:36 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AC0B21F86FA for ; Fri, 21 Dec 2012 02:03:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.665 X-Spam-Level: X-Spam-Status: No, score=-1.665 tagged_above=-999 required=5 tests=[AWL=-0.219, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_34=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cbKolVdHiBpe for ; Fri, 21 Dec 2012 02:03:35 -0800 (PST) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 2227521F8B09 for ; Fri, 21 Dec 2012 02:03:35 -0800 (PST) Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 80EDE1200D78; Fri, 21 Dec 2012 11:03:33 +0100 (CET) Date: Fri, 21 Dec 2012 11:03:33 +0100 (CET) Message-Id: <20121221.110333.321656007.mbj@tail-f.com> To: jeffrey.K.lange@ge.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] RADIUS enhancement to ietf-system X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 21 Dec 2012 10:03:36 -0000 Hi, "Lange, Jeffrey K (GE Energy)" wrote: > I've realized that there is a rather critical configuration component missing > from the RADIUS configuration section of the ietf-system model. There is no > way to specify the authentication type to use for a server (PAP/CHAP/EAP > etc...) > > I have added the following to the model, and I'm passing it along in hopes that > it can make it into the official model. > > I have included the types PAP,CHAP, and EAP-MD5. There are a plethora other > types, as well, but I think these are probably the most common. This is why I > created it as an identity as opposed to an enumeration. > > I guess there are a few general questions > > 1) Should this be included in the standard model (I clearly think yes) Yes, I think needs to be done. > 2) Should more types be defined (MS-CHAP / MS-CHAPv2 / SIP Digest / LEAP / > Cisco LEAP / etc...), this gets tricky for things like EAP-TLS where you also > need to configure keying material. We got a comment from Alan DeKok regarding EAP, and he pointed to the IANA registry for EAP types (http://www.iana.org/assignments/eap-numbers/eap-numbers.xml) There are a bunch of them, and as you say some might require more paramaters, so I feel the best way to handle this now is to add the authentication-type leaf and the base identity, and leave the handling of EAP etc to future models. But we should add the pap and chap identities, since these are defined in the base RFC (2865). So I suggest we add: identity radius-authentication-type { description "Base identity for RADIUS authentiation types."; } identity radius-pap { base radius-authentication-type; ... } identity radius-chap { base radius-authentication-type; ... } and leaf authentication-type { type identityref { base radius-authentication-type; } default radius-pap; description "The authentication type requested from the RADIUS server."; } > 3) Should each identity be wrapped in a feature that determines whether or not > the device supports that particular Auth type? Or should the server validate > the settings at runtime? I think features for all identities in general are overkill. /martin From lhotka@nic.cz Fri Dec 21 06:00:38 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88C2D21F84F5 for ; Fri, 21 Dec 2012 06:00:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.082 X-Spam-Level: X-Spam-Status: No, score=-1.082 tagged_above=-999 required=5 tests=[AWL=-0.587, BAYES_00=-2.599, HOST_EQ_CZ=0.904, J_CHICKENPOX_23=0.6, J_CHICKENPOX_31=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vE95Q3Ydh-e5 for ; Fri, 21 Dec 2012 06:00:37 -0800 (PST) Received: from trail.lhotka.name (nat-5.bravonet.cz [77.48.224.5]) by ietfa.amsl.com (Postfix) with ESMTP id 961AA21F84E8 for ; Fri, 21 Dec 2012 06:00:36 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id D9CD45406AF for ; Fri, 21 Dec 2012 15:00:28 +0100 (CET) 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 GWg4uJ4SQ48S for ; Fri, 21 Dec 2012 15:00:13 +0100 (CET) Received: from localhost (unknown [172.29.2.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 146685403DC for ; Fri, 21 Dec 2012 15:00:09 +0100 (CET) From: Ladislav Lhotka To: netmod@ietf.org In-Reply-To: <50D425EC.1020903@mg-soft.com> References: <50D425EC.1020903@mg-soft.com> User-Agent: Notmuch/0.14+100~ge0adf10 (http://notmuchmail.org) Emacs/23.3.50.1 (i386-apple-darwin9.8.0) Mail-Followup-To: netmod@ietf.org Date: Fri, 21 Dec 2012 15:00:08 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [netmod] YANG question X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 21 Dec 2012 14:00:38 -0000 Jernej Tuljak writes: > Dne 21.12.2012 2:26, pis(e Alexander Clemm (alex): >> >> Hello YANG experts, >> >> I have a quick question: is it possible to specify for an >> augmentation of a list, that the augmenting information needs to be >> unique? >> >> I would like to do something like (to modify the example in RFC 6020 >> slighly) >> >> import interface-module { >> >> prefix "if"; >> >> } >> >> augment "/if:interfaces/if:ifEntry" { >> >> when "if:ifType='foobar'"; >> >> unique "foobarNumber"; >> >> leaf foobarNumber { >> >> type foobarNumber; >> >> } >> >> } >> >> Can I do this? RFC 6020 section 7.15.1 does not list "unique" under >> the substatements that are allowed. On the other hand, the >> "uniqueness" property does not refer to information in the augmented >> module (which would be understandably illegal to introduce), but only >> in the information that is added. >> >> How can I accomplish what I need to do? >> > > Like Martin already suggested you can work around this by putting a > must-stmt constaint on valid foobarNumber data nodes, not on the list > itself. For your example that would probably be the following statement > block as a child to leaf foobarNumber: > > must > "not(parent::if:ifEntry/preceding-sibling::if:ifEntry[current()=pfx:foobarNumber])" > { > error-message "Violated uniqueness constraint for pfx:foobarNumber" > } > > where pfx is the prefix of the augmenting module. > > However, I'm not entirely sure how you would handle a multi-valued > unique (if you augmented two leafs and wanted both of them to be part of > the same uniqueness constraint). That would probably require some more > thinking. Here is an example for two nodes "foo" and "bar" that are required to be unique, it could be done analogically for any number of nodes: augment "/if:interfaces/if:interface" { when "if:type='other'"; leaf foo { type uint8; must "not(../preceding-sibling::if:interface[foo = current() " + "and bar = current()/../bar])" { error-message "Violated uniqueness of foo & bar."; } } leaf bar { type string; } } Lada > > Jernej > >> Thanks >> >> --- Alex >> >> >> >> _______________________________________________ >> 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 alex@cisco.com Fri Dec 21 09:42:52 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B73C21F86A1 for ; Fri, 21 Dec 2012 09:42:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.998 X-Spam-Level: X-Spam-Status: No, score=-9.998 tagged_above=-999 required=5 tests=[AWL=-0.599, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WROWyiHSB2Wp for ; Fri, 21 Dec 2012 09:42:51 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 5EDDC21F8652 for ; Fri, 21 Dec 2012 09:42:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3259; q=dns/txt; s=iport; t=1356111771; x=1357321371; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=8ZFaxVfUbA0zwKQ6e/RNd0QtsgjM2zjT4P7IN4C9oYM=; b=RTh2oByG3D8dJiiSJlDL8rUbDb9V083mcvMMC9yiJSD0NZNci/ZONrpD i7xl7W21uGpQgH0KLJH47mPCeNjpfXbjVW4jF6i4aM/m4D2JtRjwAJaOi be23wkhZdAyTVYNh3BT95+kvHjoARUfCirYDSWsOvsGuCawLJ6zVtMT80 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAFCe1FCtJXHA/2dsb2JhbABFvXwWc4IeAQEBAwEBAQE3MQMQBwQCAQgRBAEBCxQJBycLFAkIAQEEARIIiAUGDLY+BIxXg2JhA6ZTgnSCIg X-IronPort-AV: E=Sophos;i="4.84,331,1355097600"; d="scan'208";a="152581101" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-9.cisco.com with ESMTP; 21 Dec 2012 17:42:50 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id qBLHgn8R003544 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 21 Dec 2012 17:42:49 GMT Received: from xmb-rcd-x05.cisco.com ([169.254.15.223]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.02.0318.004; Fri, 21 Dec 2012 11:42:49 -0600 From: "Alexander Clemm (alex)" To: Ladislav Lhotka , "netmod@ietf.org" Thread-Topic: [netmod] YANG question Thread-Index: Ac3fGESj6b8maG8TTO24e/HxwE6dfAAdBegAAApangAABODSkA== Date: Fri, 21 Dec 2012 17:42:49 +0000 Message-ID: References: <50D425EC.1020903@mg-soft.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.154.201.58] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [netmod] YANG question X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 21 Dec 2012 17:42:52 -0000 Lada, Jernej, Martin, thank you for your responses! Will go with the xpath expression then. Happy holidays --- Alex -----Original Message----- From: netmod-bounces@ietf.org [mailto:netmod-bounces@ietf.org] On Behalf Of= Ladislav Lhotka Sent: Friday, December 21, 2012 6:00 AM To: netmod@ietf.org Subject: Re: [netmod] YANG question Jernej Tuljak writes: > Dne 21.12.2012 2:26, pis(e Alexander Clemm (alex): >> >> Hello YANG experts, >> >> I have a quick question: is it possible to specify for an=20 >> augmentation of a list, that the augmenting information needs to be=20 >> unique? >> >> I would like to do something like (to modify the example in RFC 6020 >> slighly) >> >> import interface-module { >> >> prefix "if"; >> >> } >> >> augment "/if:interfaces/if:ifEntry" { >> >> when "if:ifType=3D'foobar'"; >> >> unique "foobarNumber"; >> >> leaf foobarNumber { >> >> type foobarNumber; >> >> } >> >> } >> >> Can I do this? RFC 6020 section 7.15.1 does not list "unique" under=20 >> the substatements that are allowed. On the other hand, the=20 >> "uniqueness" property does not refer to information in the augmented=20 >> module (which would be understandably illegal to introduce), but only=20 >> in the information that is added. >> >> How can I accomplish what I need to do? >> > > Like Martin already suggested you can work around this by putting a=20 > must-stmt constaint on valid foobarNumber data nodes, not on the list=20 > itself. For your example that would probably be the following=20 > statement block as a child to leaf foobarNumber: > > must > "not(parent::if:ifEntry/preceding-sibling::if:ifEntry[current()=3Dpfx:foo= barNumber])"=20 > { > error-message "Violated uniqueness constraint for pfx:foobarNumber" > } > > where pfx is the prefix of the augmenting module. > > However, I'm not entirely sure how you would handle a multi-valued=20 > unique (if you augmented two leafs and wanted both of them to be part=20 > of the same uniqueness constraint). That would probably require some=20 > more thinking. Here is an example for two nodes "foo" and "bar" that are required to be un= ique, it could be done analogically for any number of nodes: augment "/if:interfaces/if:interface" { when "if:type=3D'other'"; leaf foo { type uint8; must "not(../preceding-sibling::if:interface[foo =3D current() " + "and bar =3D current()/../bar])" { error-message "Violated uniqueness of foo & bar."; } } leaf bar { type string; } } Lada > > Jernej > >> Thanks >> >> --- Alex >> >> >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From internet-drafts@ietf.org Wed Dec 26 12:45:29 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BD1A21F88D6; Wed, 26 Dec 2012 12:45:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.523 X-Spam-Level: X-Spam-Status: No, score=-102.523 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2seWMrRBJTvl; Wed, 26 Dec 2012 12:45:28 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE0D421F8D05; Wed, 26 Dec 2012 12:45:28 -0800 (PST) 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.37 Message-ID: <20121226204528.1846.85674.idtracker@ietfa.amsl.com> Date: Wed, 26 Dec 2012 12:45:28 -0800 Cc: netmod@ietf.org Subject: [netmod] I-D Action: draft-ietf-netmod-system-mgmt-04.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Dec 2012 20:45:29 -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-04.txt Pages : 31 Date : 2012-12-26 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-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netmod-system-mgmt-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/