From wwwrun@rfc-editor.org Sat Feb 1 01:42:35 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F3141A1F66; Sat, 1 Feb 2014 01:42:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.953 X-Spam-Level: X-Spam-Status: No, score=0.953 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.793, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gRZ1oOxquq97; Sat, 1 Feb 2014 01:42:34 -0800 (PST) Received: from rfc-editor.org (unknown [IPv6:2607:f170:8000:1500::d3]) by ietfa.amsl.com (Postfix) with ESMTP id 20D8A1A04CD; Sat, 1 Feb 2014 01:42:34 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 5821E7FC2C7; Sat, 1 Feb 2014 01:42:28 -0800 (PST) To: jonathan@hansfords.net, mbj@tail-f.com From: RFC Errata System Message-Id: <20140201094228.5821E7FC2C7@rfc-editor.org> Date: Sat, 1 Feb 2014 01:42:28 -0800 (PST) Cc: iesg@ietf.org, netmod@ietf.org, rfc-editor@rfc-editor.org Subject: [netmod] [Errata Verified] RFC6020 (3871) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Feb 2014 09:42:35 -0000 The following errata report has been verified for RFC6020, "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6020&eid=3871 -------------------------------------- Status: Verified Type: Technical Reported by: Jonathan Hansford Date Reported: 2014-01-23 Verified by: Benoit Claise (IESG) Section: 9.6.4.2 Original Text ------------- If a value is not specified, then one will be automatically assigned. If the "enum" substatement is the first one defined, the assigned value is zero (0); otherwise, the assigned value is one greater than the current highest enum value. Corrected Text -------------- If a value is not specified, then one will be automatically assigned. If the "enum" substatement is the first one defined, the assigned value is zero (0); otherwise, the assigned value is one greater than the current highest enum value (that is, the highest enum value, implicit or explicit, prior to the current "enum" substatement in the parent "type" statement). Notes ----- Clarification that 'current highest' does not refer to all enum values, implicit or explicit, in the parent "type" statement but only to those that precede the current "enum" substatement. -------------------------------------- RFC6020 (draft-ietf-netmod-yang-13) -------------------------------------- Title : YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF) Publication Date : October 2010 Author(s) : M. Bjorklund, Ed. Category : PROPOSED STANDARD Source : NETCONF Data Modeling Language Area : Operations and Management Stream : IETF Verifying Party : IESG From wwwrun@rfc-editor.org Sat Feb 1 01:56:01 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E6521ACCDE; Sat, 1 Feb 2014 01:56:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.953 X-Spam-Level: X-Spam-Status: No, score=0.953 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.793, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YY-i33FDlBJR; Sat, 1 Feb 2014 01:56:00 -0800 (PST) Received: from rfc-editor.org (unknown [IPv6:2607:f170:8000:1500::d3]) by ietfa.amsl.com (Postfix) with ESMTP id 2EEB31A057A; Sat, 1 Feb 2014 01:56:00 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 0A8B57FC2C7; Sat, 1 Feb 2014 01:55:52 -0800 (PST) To: jonathan@hansfords.net, mbj@tail-f.com From: RFC Errata System Message-Id: <20140201095555.0A8B57FC2C7@rfc-editor.org> Date: Sat, 1 Feb 2014 01:55:52 -0800 (PST) Cc: iesg@ietf.org, netmod@ietf.org, rfc-editor@rfc-editor.org Subject: [netmod] [Errata Verified] RFC6020 (3872) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Feb 2014 09:56:01 -0000 The following errata report has been verified for RFC6020, "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6020&eid=3872 -------------------------------------- Status: Verified Type: Technical Reported by: Jonathan Hansford Date Reported: 2014-01-23 Verified by: Benoit Claise (IESG) Section: 9.7.4.2 Original Text ------------- If a bit position is not specified, then one will be automatically assigned. If the "bit" substatement is the first one defined, the assigned value is zero (0); otherwise, the assigned value is one greater than the current highest bit position. Corrected Text -------------- If a bit position is not specified, then one will be automatically assigned. If the "bit" substatement is the first one defined, the assigned value is zero (0); otherwise, the assigned value is one greater than the current highest bit position (that is, the highest bit position, implicit or explicit, prior to the current "bit" substatement in the parent "type" statement). Notes ----- Clarification that 'current highest' does not refer to all bit positions, implicit or explicit, in the parent "type" statement but only to those that precede the current "bit" substatement. -------------------------------------- RFC6020 (draft-ietf-netmod-yang-13) -------------------------------------- Title : YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF) Publication Date : October 2010 Author(s) : M. Bjorklund, Ed. Category : PROPOSED STANDARD Source : NETCONF Data Modeling Language Area : Operations and Management Stream : IETF Verifying Party : IESG From lhotka@nic.cz Sat Feb 1 01:57:02 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED0F31ACCEB for ; Sat, 1 Feb 2014 01:57:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.886 X-Spam-Level: X-Spam-Status: No, score=-0.886 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.535] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BED7Ttz-9D7U for ; Sat, 1 Feb 2014 01:57:00 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id D14B81ACCE2 for ; Sat, 1 Feb 2014 01:56:59 -0800 (PST) Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 2B1E0140119; Sat, 1 Feb 2014 10:56:55 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1391248615; bh=4OtwV0wr+B0SjSoXpRvAokAZtlmFF8ZfnRp1YyZ0jX4=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=ig7cOBFRuBBjxZBxntAU+U/tzdSHzSKeN8Rd8Bw9RzB9cLEkQPN22ynAalArhc5Uc rLYKG13uV0eFcvq6mEMhO8FJnfzT5herHYTmroW3W56yqS83HtikrpJt+JNUrEAOyz sF1PQncxS+MMslZ9V9X4CS2QroMauQoOIjSNmzyg= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Ladislav Lhotka In-Reply-To: <20140131205059.GA31573@elstar.local> Date: Sat, 1 Feb 2014 10:56:54 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0B4780F9-FC24-4D8E-8F9E-BE5D2E55B2FB@nic.cz> <20140131.174532.535193369.mbj@tail-f.com> <20140131202620.GB31150@elstar.local> <20140131.214042.353989959.mbj@tail-f.com> <20140131205059.GA31573@elstar.local> To: =?windows-1252?Q?J=FCrgen_Sch=F6nw=E4lder?= X-Mailer: Apple Mail (2.1827) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Cc: netmod@ietf.org, netmod-chairs@tools.ietf.org Subject: Re: [netmod] consensus all: timezone-location and draft-ietf-netmod-iana-timezones-03 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Feb 2014 09:57:02 -0000 On 31 Jan 2014, at 21:50, Juergen Schoenwaelder = wrote: > On Fri, Jan 31, 2014 at 09:40:42PM +0100, Martin Bjorklund wrote: >> Juergen Schoenwaelder wrote: >>> On Fri, Jan 31, 2014 at 05:45:32PM +0100, Martin Bjorklund wrote: >>>>=20 >>>> I think you do have a valid point. It is probably be better to = have >>>> one fixed version of the enumeration standardized. But the problem = is >>>> how this module would be maintained. Apparently the database = changes >>>> too often for being maintained in RFCs. And there also seems to be >>>> a political dimension to it that I don't think we are prepared to >>>> handle. And if we simply publish an RFC with the current version = of >>>> the names from the database, what does it mean that the >>>> IANA-maintained db differs? >>>>=20 >>>=20 >>> I completely fail to understand which value an RFC with an almost >>> immediately outdated list of TZ names has. >>=20 >> I don't think it is "immediately outdated". Locations are rarely = added and >> removed. >=20 > The numbers I recall indicate a certain chance it comes out of the > whole process already outdated. But even if it takes a year, the value > is rather questionable. =46rom the network management point of view, it is important to be able = to set the behaviour of the system clock properly. I would consider the = module to be outdated only if it makes this impossible, and then it = should be updated. >=20 >>> I would then rather prefer >>> to code my manager to use my local list and be prepared that names = can >>> be rejected. >>=20 >> I expect this to work reasonably well in practice. But the point is >> that you don't know if a value will be accepted or not. >=20 > So what? I believe we will see other leaf where you can't predict for > 100% that the value will be accepted. If we continue to strive for a > perfect world, we will never ever achieve anything. I really doubt > setting the timezone name is the biggest interoperability problem to > solve. It certainly isn=92t, but we now have the enumeration and the proposal = is to dump it for reasons that are not clear to me. We can have strings = everywhere and forget about types. 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 lhotka@nic.cz Sat Feb 1 02:02:03 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14EFE1ACCDE for ; Sat, 1 Feb 2014 02:02:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.886 X-Spam-Level: X-Spam-Status: No, score=-0.886 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.535] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZhR2j-3q1L55 for ; Sat, 1 Feb 2014 02:02:02 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 06AA71A04CD for ; Sat, 1 Feb 2014 02:02:02 -0800 (PST) Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 5E3AA140119; Sat, 1 Feb 2014 11:01:57 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1391248917; bh=49NfoC20vth6hNNPJyel6wVJa+k2+bNPyoMgn1KQUWg=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=it8m8gfqd8leYG4LLk+9P87LmsAW0PRJa2594JagJq/OtXK08cB/c3CZy5zs9LHd9 fbLBPX+qQWPM7Y/n0w60Ta/Mq0TreFMkXFCoaio8YOyY631hT4RbnxhJ/jNUTiUJox wywD9p87I2alSKgz1490Ota37ZxKgJnIPWEpYMUI= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Ladislav Lhotka In-Reply-To: <20140131.214042.353989959.mbj@tail-f.com> Date: Sat, 1 Feb 2014 11:01:56 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <32D90073-85DC-40A5-AA8E-EC6FA31DFF21@nic.cz> References: <0B4780F9-FC24-4D8E-8F9E-BE5D2E55B2FB@nic.cz> <20140131.174532.535193369.mbj@tail-f.com> <20140131202620.GB31150@elstar.local> <20140131.214042.353989959.mbj@tail-f.com> To: =?windows-1252?Q?Martin_Bj=F6rklund?= X-Mailer: Apple Mail (2.1827) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Cc: netmod-chairs@tools.ietf.org, netmod@ietf.org Subject: Re: [netmod] consensus all: timezone-location and draft-ietf-netmod-iana-timezones-03 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Feb 2014 10:02:03 -0000 On 31 Jan 2014, at 21:40, Martin Bjorklund wrote: > Juergen Schoenwaelder wrote: >> On Fri, Jan 31, 2014 at 05:45:32PM +0100, Martin Bjorklund wrote: >>>=20 >>> I think you do have a valid point. It is probably be better to have >>> one fixed version of the enumeration standardized. But the problem = is >>> how this module would be maintained. Apparently the database = changes >>> too often for being maintained in RFCs. And there also seems to be >>> a political dimension to it that I don't think we are prepared to >>> handle. And if we simply publish an RFC with the current version of >>> the names from the database, what does it mean that the >>> IANA-maintained db differs? >>>=20 >>=20 >> I completely fail to understand which value an RFC with an almost >> immediately outdated list of TZ names has. >=20 > I don't think it is "immediately outdated". Locations are rarely = added and > removed. Yes. >=20 >> I would then rather prefer >> to code my manager to use my local list and be prepared that names = can >> be rejected. >=20 > I expect this to work reasonably well in practice. But the point is > that you don't know if a value will be accepted or not. You know it, at least from the NETCONF point of view - that=92s what the = module is for. You wouldn't know it if it was a string, unless there is = another mechanism to learn it (which is out of scope though). Lada >=20 >=20 > /martin >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From j.schoenwaelder@jacobs-university.de Sat Feb 1 05:06:29 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78DF71AD6B9 for ; Sat, 1 Feb 2014 05:06:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.785 X-Spam-Level: X-Spam-Status: No, score=-2.785 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.535] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id etTYwv_Oic1R for ; Sat, 1 Feb 2014 05:06:26 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id A3E161AD687 for ; Sat, 1 Feb 2014 05:06:26 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 43DE720076; Sat, 1 Feb 2014 14:06:22 +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 7_lKLKBp4T-3; Sat, 1 Feb 2014 14:06:22 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 62C532004E; Sat, 1 Feb 2014 14:06:21 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 0DC0A2B04D77; Sat, 1 Feb 2014 14:06:18 +0100 (CET) Date: Sat, 1 Feb 2014 14:06:18 +0100 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20140201130618.GA33052@elstar.local> Mail-Followup-To: Ladislav Lhotka , Martin =?iso-8859-1?Q?Bj=F6rklund?= , Thomas Nadeau , netmod-chairs@tools.ietf.org, netmod@ietf.org References: <0B4780F9-FC24-4D8E-8F9E-BE5D2E55B2FB@nic.cz> <20140131.174532.535193369.mbj@tail-f.com> <20140131202620.GB31150@elstar.local> <20140131.214042.353989959.mbj@tail-f.com> <20140131205059.GA31573@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, netmod-chairs@tools.ietf.org Subject: Re: [netmod] consensus all: timezone-location and draft-ietf-netmod-iana-timezones-03 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Feb 2014 13:06:29 -0000 On Sat, Feb 01, 2014 at 10:56:54AM +0100, Ladislav Lhotka wrote: > > From the network management point of view, it is important to be able to set the behaviour of the system clock properly. I would consider the module to be outdated only if it makes this impossible, and then it should be updated. > Having two definitions of timezone names that are not synced is the worst of all solutions. I want 3rd party NETCONF implementations to function on open systems where the packaging and maintenance of the timezone database is separate from the packaging and maintenance of the NETCONF implementation. We started with the idealistic idea there could be a maintained enumeration and it turns out this is not realistic to establish and likely also difficult to implement on open systems. So we are going with a string which I believe will work just fine for a large part of the world. If we find out later that this is not workable, we can add additional objects to report which time zone names are available. At this point in time, we have to ship things. I leave it to Tom to determine concensus. But I note that concensus can be rough. /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 Sat Feb 1 05:46:46 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B66171AE06E for ; Sat, 1 Feb 2014 05:46:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.436 X-Spam-Level: X-Spam-Status: No, score=-2.436 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7SiJBQ2PHl-R for ; Sat, 1 Feb 2014 05:46:45 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id 65DB21AE072 for ; Sat, 1 Feb 2014 05:46:45 -0800 (PST) Received: from localhost (unknown [193.12.32.88]) by mail.tail-f.com (Postfix) with ESMTPSA id C8C8E240C5B2; Sat, 1 Feb 2014 14:46:40 +0100 (CET) Date: Sat, 01 Feb 2014 14:46:39 +0100 (CET) Message-Id: <20140201.144639.122030524.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20140201130618.GA33052@elstar.local> References: <20140131205059.GA31573@elstar.local> <20140201130618.GA33052@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-chairs@tools.ietf.org, netmod@ietf.org Subject: Re: [netmod] consensus all: timezone-location and draft-ietf-netmod-iana-timezones-03 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Feb 2014 13:46:46 -0000 Juergen Schoenwaelder wrote: > I leave it to Tom to determine concensus. But I note that concensus > can be rough. Just to make it clear; I do (still) believe that the string approach is the only realistic alternative at this point. /martin From j.schoenwaelder@jacobs-university.de Sat Feb 1 05:50:56 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 091801AE0E1 for ; Sat, 1 Feb 2014 05:50:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.785 X-Spam-Level: X-Spam-Status: No, score=-2.785 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.535] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L8cDdr-R5spQ for ; Sat, 1 Feb 2014 05:50:54 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id AA98F1AE0D5 for ; Sat, 1 Feb 2014 05:50:54 -0800 (PST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5800320070; Sat, 1 Feb 2014 14:50:50 +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 FdU1vjPs3Z1S; Sat, 1 Feb 2014 14:50: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 B89512005F; Sat, 1 Feb 2014 14:50:49 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 85E212B05075; Sat, 1 Feb 2014 14:50:48 +0100 (CET) Date: Sat, 1 Feb 2014 14:50:48 +0100 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20140201135048.GB33236@elstar.local> Mail-Followup-To: Martin Bjorklund , lhotka@nic.cz, tnadeau@lucidvision.com, netmod-chairs@tools.ietf.org, netmod@ietf.org References: <20140131205059.GA31573@elstar.local> <20140201130618.GA33052@elstar.local> <20140201.144639.122030524.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140201.144639.122030524.mbj@tail-f.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod-chairs@tools.ietf.org, netmod@ietf.org Subject: Re: [netmod] consensus all: timezone-location and draft-ietf-netmod-iana-timezones-03 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Feb 2014 13:50:56 -0000 On Sat, Feb 01, 2014 at 02:46:39PM +0100, Martin Bjorklund wrote: > Juergen Schoenwaelder wrote: > > I leave it to Tom to determine concensus. But I note that concensus > > can be rough. > > Just to make it clear; I do (still) believe that the string approach > is the only realistic alternative at this point. Thanks. So it seems only Lada is unhappy with the resolution. /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 Sat Feb 1 07:00:25 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFE6E1AD8F1 for ; Sat, 1 Feb 2014 07:00:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.886 X-Spam-Level: X-Spam-Status: No, score=-0.886 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.535] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kpl1-OrXL6lQ for ; Sat, 1 Feb 2014 07:00:24 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 79FBA1ADDD2 for ; Sat, 1 Feb 2014 07:00:23 -0800 (PST) Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id C9851140119; Sat, 1 Feb 2014 16:00:18 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1391266819; bh=m9pSpSGnDY/Iyb9+7kQFcYRf45xnbkKV0RvhCRcGG6c=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=bja326DEwPHvviHrLaae0NyKMrYobNtMse64m1Hy0FEU++Za0LlggSO7l5JdrSwV1 BlD+jrF3hj5U6SGEaHXLIKIhofYn885wYh/4p6+/1A6Tr6aO5zAXSqxbNenesm64QZ CWNsXCl6MwLMaJvQVgooq6F/EG8fNVVXVHlDM4io= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Ladislav Lhotka In-Reply-To: <20140201130618.GA33052@elstar.local> Date: Sat, 1 Feb 2014 16:00:16 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <72D0C0E8-37D8-4D06-8AE6-CA42E6073678@nic.cz> References: <0B4780F9-FC24-4D8E-8F9E-BE5D2E55B2FB@nic.cz> <20140131.174532.535193369.mbj@tail-f.com> <20140131202620.GB31150@elstar.local> <20140131.214042.353989959.mbj@tail-f.com> <20140131205059.GA31573@elstar.local> <20140201130618.GA33052@elstar.local> To: =?windows-1252?Q?J=FCrgen_Sch=F6nw=E4lder?= X-Mailer: Apple Mail (2.1827) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Cc: netmod@ietf.org, netmod-chairs@tools.ietf.org Subject: Re: [netmod] consensus all: timezone-location and draft-ietf-netmod-iana-timezones-03 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Feb 2014 15:00:26 -0000 On 01 Feb 2014, at 14:06, Juergen Schoenwaelder = wrote: > On Sat, Feb 01, 2014 at 10:56:54AM +0100, Ladislav Lhotka wrote: >>=20 >> =46rom the network management point of view, it is important to be = able to set the behaviour of the system clock properly. I would consider = the module to be outdated only if it makes this impossible, and then it = should be updated. >>=20 >=20 > Having two definitions of timezone names that are not synced is the > worst of all solutions. I want 3rd party NETCONF implementations to > function on open systems where the packaging and maintenance of the > timezone database is separate from the packaging and maintenance of > the NETCONF implementation. Even if the tzdata package is upgraded and the module isn=92t, I fail to = see the reason why it should stop functioning, except in really singular = cases. >=20 > We started with the idealistic idea there could be a maintained > enumeration and it turns out this is not realistic to establish and > likely also difficult to implement on open systems. So we are going > with a string which I believe will work just fine for a large part of > the world. If we find out later that this is not workable, we can add > additional objects to report which time zone names are available. At > this point in time, we have to ship things. >=20 > I leave it to Tom to determine concensus. But I note that concensus > can be rough. Sure, if everybody else is happy with the string type, then go ahead = with it. 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 andy@yumaworks.com Sat Feb 1 07:26:06 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9665F1A1F3F for ; Sat, 1 Feb 2014 07:26:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BqhUzx_94_05 for ; Sat, 1 Feb 2014 07:26:04 -0800 (PST) Received: from mail-qa0-f42.google.com (mail-qa0-f42.google.com [209.85.216.42]) by ietfa.amsl.com (Postfix) with ESMTP id 118E21A02C5 for ; Sat, 1 Feb 2014 07:26:03 -0800 (PST) Received: by mail-qa0-f42.google.com with SMTP id k4so8059138qaq.29 for ; Sat, 01 Feb 2014 07:26:00 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=oe0reaij2m1fDv7OJxa0fFAz9xqi4NBLUHCCGpkcgTo=; b=b6diWz8l1oqdLoABtDixFbcF9ONdXO+XMZTwOUHZFweLHG/g8k/mS4vL8g/X3IA6N5 Khw2j1XUOk31+MdfQ27CWvWcRg3O5CknH6RlRVcBia6cmQaiQoJDDHLBjKbOL5DD6Nd+ 0gdLE+DbdIaTQd9XFo3r+HejKooJRpe5gFHArLg/8jrIWbmvonaVo24I95XQ3yLWGUWI V/4tiZZ5X2KK9rC2GtXnHY8kGyfFVDgt3w5G56UYw7X/4K2Gd11sl1/Pi6v8dCtK+C6a APCxPLQBrMGXASawxdsUalLoY5q45h7QodTJLbeWQ74BdPAVFfKNMeSuIBYJJhF8W1Rm f88g== X-Gm-Message-State: ALoCoQkOyCMYH1sF2huVR/wH/94bTh+YQTmf8AgoHro3UhE0Bxf0DmoKz5HfkG8f6zmfMQBcsrkN MIME-Version: 1.0 X-Received: by 10.224.46.130 with SMTP id j2mr41068170qaf.7.1391268359950; Sat, 01 Feb 2014 07:25:59 -0800 (PST) Received: by 10.140.48.75 with HTTP; Sat, 1 Feb 2014 07:25:59 -0800 (PST) In-Reply-To: <72D0C0E8-37D8-4D06-8AE6-CA42E6073678@nic.cz> References: <0B4780F9-FC24-4D8E-8F9E-BE5D2E55B2FB@nic.cz> <20140131.174532.535193369.mbj@tail-f.com> <20140131202620.GB31150@elstar.local> <20140131.214042.353989959.mbj@tail-f.com> <20140131205059.GA31573@elstar.local> <20140201130618.GA33052@elstar.local> <72D0C0E8-37D8-4D06-8AE6-CA42E6073678@nic.cz> Date: Sat, 1 Feb 2014 07:25:59 -0800 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=001a11c2a9ca61e91c04f159e8fe Cc: netmod-chairs@tools.ietf.org, "netmod@ietf.org" Subject: Re: [netmod] consensus all: timezone-location and draft-ietf-netmod-iana-timezones-03 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Feb 2014 15:26:06 -0000 --001a11c2a9ca61e91c04f159e8fe Content-Type: text/plain; charset=ISO-8859-1 > > .... > > > > Having two definitions of timezone names that are not synced is the > > worst of all solutions. I want 3rd party NETCONF implementations to > > function on open systems where the packaging and maintenance of the > > timezone database is separate from the packaging and maintenance of > > the NETCONF implementation. > > Even if the tzdata package is upgraded and the module isn't, I fail to see > the reason why it should stop functioning, except in really singular cases. > > It is important that the data type be correct 100% of the time. The failure mode will always be singular cases here. We would like to use enumeration, but it doesn't work for this particular typedef. Identity names cannot have forward slashes or whitespace. The only base type that will work 100% is string. > > > > We started with the idealistic idea there could be a maintained > > enumeration and it turns out this is not realistic to establish and > > likely also difficult to implement on open systems. So we are going > > with a string which I believe will work just fine for a large part of > > the world. If we find out later that this is not workable, we can add > > additional objects to report which time zone names are available. At > > this point in time, we have to ship things. > > > > I leave it to Tom to determine concensus. But I note that concensus > > can be rough. > > Sure, if everybody else is happy with the string type, then go ahead with > it. > > Lada > > > > > /js > Andy --001a11c2a9ca61e91c04f159e8fe Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
....
>
> Having two definitions of timezone names that are not synced is the > worst of all solutions. I want 3rd party NETCONF implementations to > function on open systems where the packaging and maintenance of the > timezone database is separate from the packaging and maintenance of > the NETCONF implementation.

Even if the tzdata package is upgraded and the module isn’t, I fail t= o see the reason why it should stop functioning, except in really singular = cases.



It is important that th= e data type be correct 100% of the time.
The failure mode will al= ways be singular cases here.  We would
like to use enumerati= on, but it doesn't work for this particular typedef.
Identity names cannot have forward slashes or whitespace.
Th= e only base type that will work 100% is string.

&n= bsp;
>
> We started with the idealistic idea there could be a maintained
> enumeration and it turns out this is not realistic to establish and > likely also difficult to implement on open systems. So we are going > with a string which I believe will work just fine for a large part of<= br> > the world. If we find out later that this is not workable, we can add<= br> > additional objects to report which time zone names are available. At > this point in time, we have to ship things.
>
> I leave it to Tom to determine concensus. But I note that concensus > can be rough.

Sure, if everybody else is happy with the string type, then go ahead with i= t.

Lada

>
> /js


Andy
=
--001a11c2a9ca61e91c04f159e8fe-- From andy@yumaworks.com Sat Feb 1 12:54:53 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B4A61A3BDF for ; Sat, 1 Feb 2014 12:54:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eqdXi7pSgw4s for ; Sat, 1 Feb 2014 12:54:51 -0800 (PST) Received: from mail-qc0-f176.google.com (mail-qc0-f176.google.com [209.85.216.176]) by ietfa.amsl.com (Postfix) with ESMTP id 5F7CD1A1F76 for ; Sat, 1 Feb 2014 12:54:51 -0800 (PST) Received: by mail-qc0-f176.google.com with SMTP id e16so9063307qcx.7 for ; Sat, 01 Feb 2014 12:54:47 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=zVkjrACHYXlQ/rumbkJfkSls5MIbIvqq0uIUZnRp/UE=; b=GnVZfH/Y48qjACV6nIIrbrdrHAkuHcnDBlMdNEBPR0aYdC5aZmMQFgKsWse7bNE7sK jSkVLGR/v/oVvHKqjNW88QnEjKPbY/DODy8RkU4MkeCpyoT/V2FF3YxUg7iZGBbsTp1y ui9wCjowtQj9viNMORM/SszjcOuNMDLJThUrXdK827mGx6PZweo7lg4XGYKKWAhSwnaR hZZh+AekKaOnT8+wszeEKDRjj4cvmsQK+vpcXsby0iQJ3+vhBZKTBSbeNdWvVUQ54DIB AF1QmbNzrnaJaUN7/B0TdBnYiipMm2Tost6GMYWa6sNQLM13azti0U0oNciSsrB2vuKJ mNNA== X-Gm-Message-State: ALoCoQm+OsxI74ryBb3ZYeYO7j+wtsLIjLbXQusJCViXoy8r+U6Ae6HZMdpC2j1NrlAyKROV3HGW MIME-Version: 1.0 X-Received: by 10.224.49.69 with SMTP id u5mr11103560qaf.88.1391288087185; Sat, 01 Feb 2014 12:54:47 -0800 (PST) Received: by 10.140.48.75 with HTTP; Sat, 1 Feb 2014 12:54:47 -0800 (PST) In-Reply-To: <0B4780F9-FC24-4D8E-8F9E-BE5D2E55B2FB@nic.cz> References: <2A72C094-7CBC-474B-8413-8F60842142C8@lucidvision.com> <0B4780F9-FC24-4D8E-8F9E-BE5D2E55B2FB@nic.cz> Date: Sat, 1 Feb 2014 12:54:47 -0800 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=001a11c2f5a8378ee104f15e80e9 Cc: netmod-chairs@tools.ietf.org, "netmod@ietf.org" Subject: Re: [netmod] consensus all: timezone-location and draft-ietf-netmod-iana-timezones-03 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Feb 2014 20:54:53 -0000 --001a11c2f5a8378ee104f15e80e9 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Jan 31, 2014 at 7:20 AM, Ladislav Lhotka wrote: > > On 31 Jan 2014, at 16:02, Thomas Nadeau wrote: > > > > > I would like to call consensus on this matter. I've received %100 > supporting comments for the proposal from the WG with no one not liking the > proposal. The only comments received were from Martin and > > You must have missed my comments, so let me say I don't like the proposal. > I think we are throwing out the baby with the bath water. > > I think I have a compromise solution that saves the baby :-) typedef timezone-enum { // TZ snapshot we have now } typedef timezone-name { type union { type timezone-enum; type string; } } 1) The NETMOD WG would maintain this module, not IANA. 2) The snapshot would be updated at long-term intervals, such as every 2 years This forces the server to support a set of values the client can predict and also supports extra strings not in the snapshot. This prevents false negatives wrt/ YANG validation, but not false positives (i.e., values have been removed from the snapshot). Do timezone names get removed from the database? IMO, this seems rare enough not to worry about until the next YANG snapshot RFC is published with the now obsolete enums. > Lada > > Andy --001a11c2f5a8378ee104f15e80e9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On F= ri, Jan 31, 2014 at 7:20 AM, Ladislav Lhotka <lhotka@nic.cz> wr= ote:

On 31 Jan 2014, at 16:02, Thomas Nadeau <tnadeau@lucidvision.com> wrote:

>
>       I would like to call consensus on this matter. I&= #39;ve received %100 supporting comments for the proposal from the WG with = no one not liking the proposal. The only comments received were from Martin= and

You must have missed my comments, so let me say I don’t like the prop= osal. I think we are throwing out the baby with the bath water.


I think I have a compromise solution t= hat saves the baby :-)

typedef timezone-enum {
  // TZ snapshot we have now
}

typedef timezone-name {
   type union {
 = ;     type timezone-enum;
      type str= ing;
   }
}


1) The NETMOD WG would maintain this module, not IANA.
2) The snapshot would be updated at long-term intervals, such as every= 2 years

This forces the server to support a set o= f values the client can predict
and also supports extra strings n= ot in the snapshot.  This prevents false negatives
wrt/ YANG validation, but not false positives (i.e., values have been = removed
from the snapshot).

Do timezone = names get removed from the database? IMO, this seems rare
enough = not to worry about until the next YANG snapshot RFC is published
with the now obsolete enums.


&= nbsp;
Lada


Andy
 
--001a11c2f5a8378ee104f15e80e9-- From andy@yumaworks.com Sat Feb 1 14:02:54 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1D3C1AC3DA for ; Sat, 1 Feb 2014 14:02:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PqX9eG0tY6F5 for ; Sat, 1 Feb 2014 14:02:52 -0800 (PST) Received: from mail-qc0-f169.google.com (mail-qc0-f169.google.com [209.85.216.169]) by ietfa.amsl.com (Postfix) with ESMTP id CD0F51A03FE for ; Sat, 1 Feb 2014 14:02:51 -0800 (PST) Received: by mail-qc0-f169.google.com with SMTP id w7so9193589qcr.14 for ; Sat, 01 Feb 2014 14:02:47 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=HUkVIaroehIDZq4OYo/tDvUEihuDlIF4aUoSMlRhZYs=; b=hsOyz23DYmIt5uv6r0qdXu1Ma0tvfl8pBWGWEdvRUpsaCwTcmN2Y4hCps/3LMcIOlT p6SsgmzgIO028+12O8gyyt/WJtK6mlLq/ZLRmr7DLjvFa23yKzhJKIcH3jZGn/8STI8T yZF8Bu0yMeGv0ozIx7gkTQPaRmfpMSNIpl7x1IT/fEFRw7QUORMTsU4sw60dkHRqj2t+ CMhlq2+sdo1A/iKizxEd+U485QxTcOSy3o9zqlW4uyqEDARwuZmQ5Rv2OLSQGCwPBUsY hz2eL8eBHjQiUoKiU0MrlV5QfNlwlMO3J9XUZi4a/siHcIBEEmZGcWBKRfAoPPm+czrz FPUg== X-Gm-Message-State: ALoCoQlkbWQWB9qbMyvLLVzEZSPx3r9c5y/IKl4Iw4hIKboSg+zwwhbkSDrPJr7vTDjTwEnN38Gc MIME-Version: 1.0 X-Received: by 10.229.84.198 with SMTP id k6mr24764362qcl.20.1391292167482; Sat, 01 Feb 2014 14:02:47 -0800 (PST) Received: by 10.140.48.75 with HTTP; Sat, 1 Feb 2014 14:02:47 -0800 (PST) In-Reply-To: References: <2A72C094-7CBC-474B-8413-8F60842142C8@lucidvision.com> <0B4780F9-FC24-4D8E-8F9E-BE5D2E55B2FB@nic.cz> Date: Sat, 1 Feb 2014 14:02:47 -0800 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=001a1134541a6c12d504f15f7339 Cc: netmod-chairs@tools.ietf.org, "netmod@ietf.org" Subject: Re: [netmod] consensus all: timezone-location and draft-ietf-netmod-iana-timezones-03 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Feb 2014 22:02:54 -0000 --001a1134541a6c12d504f15f7339 Content-Type: text/plain; charset=ISO-8859-1 Hi, This does not address the political problems that seem to be associated with the mere existence of a YANG snapshot of the TZ database, so it is OK if we just use a string. Since Lada is OK with a string, and that is already seems to be the consensus, I will withdraw this union typedef idea so we can finish this draft. Andy On Sat, Feb 1, 2014 at 12:54 PM, Andy Bierman wrote: > On Fri, Jan 31, 2014 at 7:20 AM, Ladislav Lhotka wrote: > >> >> On 31 Jan 2014, at 16:02, Thomas Nadeau wrote: >> >> > >> > I would like to call consensus on this matter. I've received %100 >> supporting comments for the proposal from the WG with no one not liking the >> proposal. The only comments received were from Martin and >> >> You must have missed my comments, so let me say I don't like the >> proposal. I think we are throwing out the baby with the bath water. >> >> > I think I have a compromise solution that saves the baby :-) > > typedef timezone-enum { > // TZ snapshot we have now > } > > typedef timezone-name { > type union { > type timezone-enum; > type string; > } > } > > > 1) The NETMOD WG would maintain this module, not IANA. > 2) The snapshot would be updated at long-term intervals, such as every 2 > years > > This forces the server to support a set of values the client can predict > and also supports extra strings not in the snapshot. This prevents false > negatives > wrt/ YANG validation, but not false positives (i.e., values have been > removed > from the snapshot). > > Do timezone names get removed from the database? IMO, this seems rare > enough not to worry about until the next YANG snapshot RFC is published > with the now obsolete enums. > > > > >> Lada >> >> > Andy > > --001a1134541a6c12d504f15f7339 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

This does not address the political= problems that seem to be
associated with the mere existence of a= YANG snapshot
of the TZ database, so it is OK if we just use a s= tring.
Since Lada is OK with a string, and that is already seems
to= be the consensus, I will withdraw this union typedef idea
so we = can finish this draft.


Andy



On S= at, Feb 1, 2014 at 12:54 PM, Andy Bierman <andy@yumaworks.com> wrote:
=
On Fri, Jan 31, 2014 at 7:20 AM, Ladislav Lhotka= <l= hotka@nic.cz> wrote:

On 31 Jan 2014, at 16:02, Thomas Nadeau <tnadeau@lucidvision.com> wrote:

>
>       I would like to call consensus on this matter. I&= #39;ve received %100 supporting comments for the proposal from the WG with = no one not liking the proposal. The only comments received were from Martin= and

You must have missed my comments, so let me say I don’t like the prop= osal. I think we are throwing out the baby with the bath water.


I think I have a compromise solution t= hat saves the baby :-)

typedef timezone-enum {
  // TZ snapshot we have now
}

typedef timezone-name {
   type union {
 = ;     type timezone-enum;
      type str= ing;
   }
}


1) The NETMOD WG would maintain this module, not IANA.
2) The snapshot would be updated at long-term intervals, such as every= 2 years

This forces the server to support a set o= f values the client can predict
and also supports extra strings n= ot in the snapshot.  This prevents false negatives
wrt/ YANG validation, but not false positives (i.e., values have been = removed
from the snapshot).

Do timezone = names get removed from the database? IMO, this seems rare
enough = not to worry about until the next YANG snapshot RFC is published
with the now obsolete enums.


&= nbsp;
Lada


Andy
 

--001a1134541a6c12d504f15f7339-- From mbj@tail-f.com Sat Feb 1 14:19:23 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF28C1A0005 for ; Sat, 1 Feb 2014 14:19:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.436 X-Spam-Level: X-Spam-Status: No, score=-2.436 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HGNdLW7Tr10k for ; Sat, 1 Feb 2014 14:19:22 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id 5DDF01A0004 for ; Sat, 1 Feb 2014 14:19:22 -0800 (PST) Received: from localhost (unknown [193.12.32.88]) by mail.tail-f.com (Postfix) with ESMTPSA id A73A3240C1AF for ; Sat, 1 Feb 2014 23:19:17 +0100 (CET) Date: Sat, 01 Feb 2014 23:19:17 +0100 (CET) Message-Id: <20140201.231917.173114733.mbj@tail-f.com> To: netmod@ietf.org From: Martin Bjorklund In-Reply-To: References: <0B4780F9-FC24-4D8E-8F9E-BE5D2E55B2FB@nic.cz> X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [netmod] consensus all: timezone-location and draft-ietf-netmod-iana-timezones-03 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Feb 2014 22:19:24 -0000 Hi, As suggested by Tom, here's a proposal for the new typedef, which will go into the ietf-system module: typedef timezone-name { type string; description "A timezone name as used by the Time Zone Database, sometimes referred to as the 'Olson Database'. The exact set of valid values is an implementation-specific matter. Client discovery of the exact set of time zone names for a particular server is out of scope."; reference "RFC 6557: Procedures for Maintaining the Time Zone Database"; } We also realized that we were calling the feature and the leaf "timezone-location", and this is not correct. So we propose we rename the feature and leaf to "timezone-name". (The timezone has a name in the database, and the name is often a location; but some names like "Etc/GMT-1" are not locations.) So with these changes, this the new definition: OLD: case timezone-location { if-feature timezone-location; leaf timezone-location { type ianatz:iana-timezone; description "The TZ database location identifier string to use for the system, such as 'Europe/Stockholm'."; } } NEW: case timezone-name { if-feature timezone-name; leaf timezone-name { type timezone-name; description "The TZ database name to use for the system, such as 'Europe/Stockholm'."; } } /martin & andy From j.schoenwaelder@jacobs-university.de Sun Feb 2 05:56:20 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 242CA1A00D7 for ; Sun, 2 Feb 2014 05:56:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.785 X-Spam-Level: X-Spam-Status: No, score=-2.785 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.535] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M56QcGHNgfys for ; Sun, 2 Feb 2014 05:56:18 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id D53C31A00D5 for ; Sun, 2 Feb 2014 05:56:17 -0800 (PST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 476202005B; Sun, 2 Feb 2014 14:56:12 +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 Wombby675ss3; Sun, 2 Feb 2014 14:56: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 CB8C220055; Sun, 2 Feb 2014 14:56:11 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 2049A2B06D6C; Sun, 2 Feb 2014 14:56:10 +0100 (CET) Date: Sun, 2 Feb 2014 14:56:10 +0100 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20140202135609.GA35596@elstar.local> Mail-Followup-To: netmod@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [netmod] charter revision - please comment on charter-ietf-netmod-06-05 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Feb 2014 13:56:20 -0000 Hi, we (the WG chairs and Benoit) have been working on a new charter for the NETMOD working group. The current version can always be found here. https://datatracker.ietf.org/doc/charter-ietf-netmod/ The current version is called charter-ietf-netmod-06-05 https://datatracker.ietf.org/doc/charter-ietf-netmod/withmilestones-06-05.txt Please review and feel invited to comment and ask questions. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From andy@yumaworks.com Sun Feb 2 07:27:46 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D4981A00A4 for ; Sun, 2 Feb 2014 07:27:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MrkAMe7hBUyc for ; Sun, 2 Feb 2014 07:27:43 -0800 (PST) Received: from mail-qa0-f46.google.com (mail-qa0-f46.google.com [209.85.216.46]) by ietfa.amsl.com (Postfix) with ESMTP id 60B851A00D9 for ; Sun, 2 Feb 2014 07:27:43 -0800 (PST) Received: by mail-qa0-f46.google.com with SMTP id ii20so8713780qab.33 for ; Sun, 02 Feb 2014 07:27:38 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=PNQg/F0uf5LXNk7MxnzY8/634du4V2Fnun4limHTsrg=; b=FgKGO+REC3IlQdAl3ZxQybF0Qng53Jy+UBQvC+bf5/syNhet0FZ6HcWn0zV8XmIb5M Z+KWgqV2dGShqqbfdULqAoA969CKYkKgZtYbXpzqFqyhTHiFTI8I09Fafp3irFBz80qB YQx6/3He/8skJmgC69qBqZiAGkjoR6abx+c3orrMAjhn4go9EMMLkpCunTL68GGQsZVw xOfwi57jjQHGP61Qk5I1GyCZ4pbkwZ/fOZUWVnriy9NeMjIjotMT69Ss92UwXTPgWsgi u7WmlIdJfD1mD3P+zDeqILIto8oHzGg0ytRVi7P0f12tY2NDdCTY+BPS1OMExIOVLciQ tanw== X-Gm-Message-State: ALoCoQkLZEJkhxVLHIwnG9VT3wUGfPPIz/64PiG81ZCAEitp5O5dQollZC9AfoLllhSA3MBmbGUu MIME-Version: 1.0 X-Received: by 10.140.36.107 with SMTP id o98mr45951446qgo.25.1391354858612; Sun, 02 Feb 2014 07:27:38 -0800 (PST) Received: by 10.140.48.75 with HTTP; Sun, 2 Feb 2014 07:27:38 -0800 (PST) In-Reply-To: <20140202135609.GA35596@elstar.local> References: <20140202135609.GA35596@elstar.local> Date: Sun, 2 Feb 2014 07:27:38 -0800 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , "netmod@ietf.org" Content-Type: multipart/alternative; boundary=001a11c154b61abcdb04f16e0c64 Subject: Re: [netmod] charter revision - please comment on charter-ietf-netmod-06-05 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Feb 2014 15:27:46 -0000 --001a11c154b61abcdb04f16e0c64 Content-Type: text/plain; charset=ISO-8859-1 Hi, Since the WG already agreed that adding new XPath functions cannot be done without changing the YANG language version, I think the charter needs to be clear that a new YANG language version is being developed, that is not backward compatible with the existing version. IMO, the cost of introducing a new YANG version is too high just so a few XPath functions can be introduced. As soon as the line "yang-version 1.1;" is added to the module, every existing YANG tool is going to reject the module. The operational impact of a new language version is unavoidable, whether we add 1 new feature or 100. There are many small improvements or nice-to-have features we could add, but nothing really important (short of YANG++). IMO the NETMOD WG should be working on things that add to the usefulness of YANG 1.0, such as YANG Conformance + ACL + and topology modules. Andy On Sun, Feb 2, 2014 at 5:56 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > Hi, > > we (the WG chairs and Benoit) have been working on a new charter for > the NETMOD working group. The current version can always be found > here. > > https://datatracker.ietf.org/doc/charter-ietf-netmod/ > > The current version is called charter-ietf-netmod-06-05 > > > https://datatracker.ietf.org/doc/charter-ietf-netmod/withmilestones-06-05.txt > > Please review and feel invited to comment and ask questions. > > /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 > --001a11c154b61abcdb04f16e0c64 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

Since the WG already agreed that ad= ding new XPath functions
cannot be done without changing the YANG= language version,
I think the charter needs to be clear that a n= ew YANG language
version is being developed, that is not backward compatible with
=
the existing version.

IMO, the cost of introd= ucing a new YANG version is too high
just so a few XPath function= s can be introduced. As soon as the
line "yang-version 1.1;" is added to the module, every exist= ing
YANG tool is going to reject the module. =A0The operational
impact of a new language version is unavoidable, whether we add
1 new feature or 100.

There are many small im= provements or nice-to-have features
we could add, but nothing rea= lly important (short of YANG++).
IMO the NETMOD WG should be work= ing on things that add to
the usefulness of YANG 1.0, such as YANG Conformance +
ACL += and topology modules.


Andy



On Sun, Feb 2, 2014 at 5:56 AM, Juergen Schoenwaelder <= ;= j.schoenwaelder@jacobs-university.de> wrote:
Hi,

we (the WG chairs and Benoit) have been working on a new charter for
the NETMOD working group. The current version can always be found
here.

=A0 https://datatracker.ietf.org/doc/charter-ietf-netmod/

The current version is called charter-ietf-netmod-06-05

=A0 https://datatracker.ietf.org/doc/chart= er-ietf-netmod/withmilestones-06-05.txt

Please review and feel invited to comment and ask questions.

/js

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

--001a11c154b61abcdb04f16e0c64-- From andy@yumaworks.com Sun Feb 2 08:35:11 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8610D1A0043 for ; Sun, 2 Feb 2014 08:35:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X1NnBY5Kutnt for ; Sun, 2 Feb 2014 08:35:09 -0800 (PST) Received: from mail-qa0-f54.google.com (mail-qa0-f54.google.com [209.85.216.54]) by ietfa.amsl.com (Postfix) with ESMTP id 3BC561A001E for ; Sun, 2 Feb 2014 08:35:09 -0800 (PST) Received: by mail-qa0-f54.google.com with SMTP id i13so8688993qae.41 for ; Sun, 02 Feb 2014 08:35:04 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=NL9nr1R3a+LEUrCIgffi0dTOIBX+vJgCDpYh4LE19xY=; b=g2R9+D4W7bO7vCrz41GhOtQJrs05hbED+rBsu35HeRKZBz9vTk4WS1zc/Ue6NuGkbO OO4lF2UN/dM019g4YmR8JeY0lrVJv7HNXEjOSTcPi3f987IPhMj7NOYGGDDeA5ZDcPjo tn31mtEoupHHSgQ+wJPRVv1S25ToBH7ijULUIFPOv/ryY3FsyPHWXyZ+NnRs+0Q+i78g v16Pj6Ugmv+1/cugjLJa0K4bdVG0t49djSL8yERimfOTJhWpcgzSyn7a235zQ5UIlXWA /ggxwbGwAys6X2KsKLaBH+T1I6eio8wPm2skCNpCxAvr4HWAGW2nOBaz8qf3ot1WEesA GHrw== X-Gm-Message-State: ALoCoQmcq4KVLVWlOR9v9uO0O9iJHD1OEbHX5O4jBqpCNk0SjSCUTF4u6Dx1oXZgryVfsLL1TdI+ MIME-Version: 1.0 X-Received: by 10.229.84.198 with SMTP id k6mr30337063qcl.20.1391358904528; Sun, 02 Feb 2014 08:35:04 -0800 (PST) Received: by 10.140.48.75 with HTTP; Sun, 2 Feb 2014 08:35:04 -0800 (PST) In-Reply-To: References: <20140202135609.GA35596@elstar.local> Date: Sun, 2 Feb 2014 08:35:04 -0800 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , "netmod@ietf.org" Content-Type: multipart/alternative; boundary=001a1134541a42850504f16efd15 Subject: Re: [netmod] charter revision - please comment on charter-ietf-netmod-06-05 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Feb 2014 16:35:11 -0000 --001a1134541a42850504f16efd15 Content-Type: text/plain; charset=ISO-8859-1 Hi, I changed my mind -- if the charter item was called YANG 1.1 Maintenance Version, that would be OK. All bug-fixes (when-stmt, etc.) and very minor enhancements should be on the table, subject to WG consensus. Andy On Sun, Feb 2, 2014 at 7:27 AM, Andy Bierman wrote: > Hi, > > Since the WG already agreed that adding new XPath functions > cannot be done without changing the YANG language version, > I think the charter needs to be clear that a new YANG language > version is being developed, that is not backward compatible with > the existing version. > > IMO, the cost of introducing a new YANG version is too high > just so a few XPath functions can be introduced. As soon as the > line "yang-version 1.1;" is added to the module, every existing > YANG tool is going to reject the module. The operational > impact of a new language version is unavoidable, whether we add > 1 new feature or 100. > > There are many small improvements or nice-to-have features > we could add, but nothing really important (short of YANG++). > IMO the NETMOD WG should be working on things that add to > the usefulness of YANG 1.0, such as YANG Conformance + > ACL + and topology modules. > > > Andy > > > > On Sun, Feb 2, 2014 at 5:56 AM, Juergen Schoenwaelder < > j.schoenwaelder@jacobs-university.de> wrote: > >> Hi, >> >> we (the WG chairs and Benoit) have been working on a new charter for >> the NETMOD working group. The current version can always be found >> here. >> >> https://datatracker.ietf.org/doc/charter-ietf-netmod/ >> >> The current version is called charter-ietf-netmod-06-05 >> >> >> https://datatracker.ietf.org/doc/charter-ietf-netmod/withmilestones-06-05.txt >> >> Please review and feel invited to comment and ask questions. >> >> /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 >> > > --001a1134541a42850504f16efd15 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

I changed my mind -- if the charter= item was called
YANG 1.1 Maintenance Version, that would be OK.<= /div>
All bug-fixes (when-stmt, etc.) and very minor enhancements
should be on the table, subject to WG consensus.

<= div>
Andy



On Sun, Feb 2, 2014 at 7:27 AM, Andy Bierman <an= dy@yumaworks.com> wrote:
Hi,

Sinc= e the WG already agreed that adding new XPath functions
cannot be= done without changing the YANG language version,
I think the charter needs to be clear that a new YANG language
version is being developed, that is not backward compatible with
=
the existing version.

IMO, the cost of introd= ucing a new YANG version is too high
just so a few XPath function= s can be introduced. As soon as the
line "yang-version 1.1;" is added to the module, every exist= ing
YANG tool is going to reject the module. =A0The operational
impact of a new language version is unavoidable, whether we add
1 new feature or 100.

There are many small im= provements or nice-to-have features
we could add, but nothing rea= lly important (short of YANG++).
IMO the NETMOD WG should be work= ing on things that add to
the usefulness of YANG 1.0, such as YANG Conformance +
ACL += and topology modules.


Andy



On Sun, Feb 2, 2014 at 5:56 AM, Juergen Schoenwaelder <= ;= j.schoenwaelder@jacobs-university.de> wrote:
Hi,

we (the WG chairs and Benoit) have been working on a new charter for
the NETMOD working group. The current version can always be found
here.

=A0 https://datatracker.ietf.org/doc/charter-ietf-netmod/

The current version is called charter-ietf-netmod-06-05

=A0 https://datatracker.ietf.org/doc/chart= er-ietf-netmod/withmilestones-06-05.txt

Please review and feel invited to comment and ask questions.

/js

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


--001a1134541a42850504f16efd15-- From mbj@tail-f.com Sun Feb 2 13:09:56 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E295F1A00E8 for ; Sun, 2 Feb 2014 13:09:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.436 X-Spam-Level: X-Spam-Status: No, score=-2.436 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZRot3Ko-SPga for ; Sun, 2 Feb 2014 13:09:55 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id 634C81A00A8 for ; Sun, 2 Feb 2014 13:09:55 -0800 (PST) Received: from localhost (unknown [193.12.32.88]) by mail.tail-f.com (Postfix) with ESMTPSA id BC3EC240C1E9; Sun, 2 Feb 2014 22:09:49 +0100 (CET) Date: Sun, 02 Feb 2014 22:09:48 +0100 (CET) Message-Id: <20140202.220948.230573655.mbj@tail-f.com> To: blukovic@ndt-inc.com From: Martin Bjorklund In-Reply-To: <52D9B9CF.5010605@ndt-inc.com> References: <014201cef85b$81260cf0$837226d0$@comcast.net> <20140111.101300.219049272.mbj@tail-f.com> <52D9B9CF.5010605@ndt-inc.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] Last Call: draft-ietf-netmod-snmp-cfg-03 (20131220) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Feb 2014 21:09:57 -0000 Hi, B Lukovic wrote: > Hi, > > Re: target address/target params tables. > snmpTargetParamsName is not mapped into yang module. > This prevents agent from restoring snmp configuration after > restart/reload (assuming configuration is yang based). > E.g. agent is configured through snmp, "t1" and "t2" are rows in > targetAddress, "p1" is row in targetParams. > Both rows in targetAddressTable: > "t1",...,"p1",... > "t2",...,"p1",... > "point" to the same row in targetParamsTable: > "p1", "v2c", "public" > saved as yang, targetParams row(s) are merged with rows of targetAddress: > > t1 > ... > > public > > .. > > > t2 > ... > > public > > .. > > > SNMP agent initialized from this config would not know the original > index ("p1") used in targetParamsTable. > One can argue that "locally arbitrary" in description of > snmpTargetParamsName allows agent to reassign indices, > but I believe this would lead to confusion. If data is created over NETCONF, the system will invent some index for the snmpTargetParamsName. If the data is created over SNMP, the snmpTargetParamsName is simply not shown over NETCONF. > Possible solutions: > - create "targetparams" list (index = leaf "name"), replace > "params" choice with leaf "params" with type leafref { path > "/snmp/targetparams/name" } This is certainly possible, but it introduces an extra level of indirection that complicates the model. > - leave "params" choice, replace optional "notify-filter-profile" > leaf with mandatory "param-name" leaf, > explain relation between "param-name" and > "notify-filter-profile/name" in description of "param-name" I don't think this solves the problem, since some reference is needed between the notify-filter-profile and the target-params. /martin From blukovic@ndt-inc.com Mon Feb 3 08:31:17 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CA411A0117 for ; Mon, 3 Feb 2014 08:31:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.799 X-Spam-Level: X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mkgutoKWYBCk for ; Mon, 3 Feb 2014 08:31:15 -0800 (PST) Received: from mail19g.g19.rapidsite.net (mail19g.g19.rapidsite.net [204.202.242.83]) by ietfa.amsl.com (Postfix) with ESMTP id 880CB1A0032 for ; Mon, 3 Feb 2014 08:31:15 -0800 (PST) Received: from mxmtaout05.va1.mxservers.net (208.55.215.83) by mail19g.g19.rapidsite.net (RS ver 1.0.95vs) with SMTP id 0-010895075 for ; Mon, 3 Feb 2014 11:31:15 -0500 (EST) Received: from unknown [161.58.75.15] (EHLO mmm1913.dulles19-verio.com) by mxmtaout05.va1.mxservers.net(mxl_mta-6.15.0-3) with ESMTP id 154cfe25.0.4106830.00-489.7207771.mxmtaout05.va1.mxservers.net (envelope-from ); Mon, 03 Feb 2014 11:31:13 -0500 (EST) X-MXL-Hash: 52efc4516a16d0fb-ba44492eec20d1a6c3530b15d9487ec88c0d93e6 Received: (qmail 42436 invoked from network); 3 Feb 2014 16:31:13 -0000 Received: from unknown (HELO ?192.168.0.21?) (blukovic@135.23.154.141) by with ESMTPA; 3 Feb 2014 16:31:13 -0000 Message-ID: <52EFC452.2000406@ndt-inc.com> Date: Mon, 03 Feb 2014 11:31:14 -0500 From: B Lukovic User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: mbj@tail-f.com References: <014201cef85b$81260cf0$837226d0$@comcast.net> <20140111.101300.219049272.mbj@tail-f.com> <52D9B9CF.5010605@ndt-inc.com> <20140202.220948.230573655.mbj@tail-f.com> In-Reply-To: <20140202.220948.230573655.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam: [F=0.2000000000; CM=0.500; MH=0.500(2014020311); S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [161.58.75.15] X-AnalysisOut: [v=2.0 cv=dvBs/Sc4 c=1 sm=1 a=IcBn81/O6j4k4bHiM4CBQw==:17 a] X-AnalysisOut: [=jl2ymW9NZSsA:10 a=AYCwLKwzVxgA:10 a=63bDUHjCYPkA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=8nJEP1OIZ-IA:10 a=A1sffi52AAAA:8 a=TohxSeLk] X-AnalysisOut: [LhgA:10 a=Cu5yUJOAILstRd5oQ9MA:9 a=wPNLvfGTeEIA:10 a=pbPsB] X-AnalysisOut: [PsJn90A:10 a=Suolaw17ZHt0xvOx:21 a=DYOlKQh9GRrrwVIj:21] X-SF-Loop: 1 Cc: netmod@ietf.org Subject: Re: [netmod] Last Call: draft-ietf-netmod-snmp-cfg-03 (20131220) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Feb 2014 16:31:17 -0000 The point is that if the data is created over SNMP there is no way with proposed yang module to preserve all info in the configuration. When the agent is restarted (or new config committed), agent would "invent indices" and this is, in my opinion, the problem (not functionally, agent would still function correctly). But for SNMP manager monitoring the agent: - index change would indicate change in configuration. - getnext order could be different A few examples: Lets say target address table has N entries, all using the same set of parameters ( = one row in snmpTargetParamsTable). Changing parameters for all N addresses: SNMP - one row changed NETCONF- N rows changed Suspend communication with all N targets: SNMP - delete one row in target params table (or set it to notInService), target address table preserves all targets NETCONF- delete whole target list Regarding proposed solutions 1) create "list targetparams" ... basically map snmpTargetParamsTable to Yang, complication could be solved as in SNMP mib, i.e. instead of leafref (forcing each target row to have valid params) this could be just a string making "loose" coupling. 2) replace optional "notify-filter-profile" leaf with mandatory "param-name" leaf, ... You are right, I overlooked that "list notify-filter-profile" should be updated with "param-name" as well and a new one 3) add optional "leaf param-name" to "list target" so snmpTargetParamsName could be preserved If missing, agent would generate appropriate index for snmpTargetParamsTable I prefer option 1) Borislav On 2/2/2014 4:09 PM, Martin Bjorklund wrote: > Hi, > > B Lukovic wrote: >> Hi, >> >> Re: target address/target params tables. >> snmpTargetParamsName is not mapped into yang module. >> This prevents agent from restoring snmp configuration after >> restart/reload (assuming configuration is yang based). >> E.g. agent is configured through snmp, "t1" and "t2" are rows in >> targetAddress, "p1" is row in targetParams. >> Both rows in targetAddressTable: >> "t1",...,"p1",... >> "t2",...,"p1",... >> "point" to the same row in targetParamsTable: >> "p1", "v2c", "public" >> saved as yang, targetParams row(s) are merged with rows of targetAddress: >> >> t1 >> ... >> >> public >> >> .. >> >> >> t2 >> ... >> >> public >> >> .. >> >> >> SNMP agent initialized from this config would not know the original >> index ("p1") used in targetParamsTable. >> One can argue that "locally arbitrary" in description of >> snmpTargetParamsName allows agent to reassign indices, >> but I believe this would lead to confusion. > If data is created over NETCONF, the system will invent some index for > the snmpTargetParamsName. If the data is created over SNMP, the > snmpTargetParamsName is simply not shown over NETCONF. > > >> Possible solutions: >> - create "targetparams" list (index = leaf "name"), replace >> "params" choice with leaf "params" with type leafref { path >> "/snmp/targetparams/name" } > This is certainly possible, but it introduces an extra level of > indirection that complicates the model. > >> - leave "params" choice, replace optional "notify-filter-profile" >> leaf with mandatory "param-name" leaf, >> explain relation between "param-name" and >> "notify-filter-profile/name" in description of "param-name" > I don't think this solves the problem, since some reference is needed > between the notify-filter-profile and the target-params. > > > > /martin > From mbj@tail-f.com Mon Feb 3 12:20:03 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7C0C1A020C for ; Mon, 3 Feb 2014 12:20:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.436 X-Spam-Level: X-Spam-Status: No, score=-2.436 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BxdC3c245foP for ; Mon, 3 Feb 2014 12:20:00 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id 885EA1A015A for ; Mon, 3 Feb 2014 12:20:00 -0800 (PST) Received: from localhost (unknown [193.12.32.88]) by mail.tail-f.com (Postfix) with ESMTPSA id B3E5E37C1AB; Mon, 3 Feb 2014 21:19:59 +0100 (CET) Date: Mon, 03 Feb 2014 21:19:58 +0100 (CET) Message-Id: <20140203.211958.484352430.mbj@tail-f.com> To: blukovic@ndt-inc.com From: Martin Bjorklund In-Reply-To: <52EFC452.2000406@ndt-inc.com> References: <52D9B9CF.5010605@ndt-inc.com> <20140202.220948.230573655.mbj@tail-f.com> <52EFC452.2000406@ndt-inc.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] Last Call: draft-ietf-netmod-snmp-cfg-03 (20131220) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Feb 2014 20:20:03 -0000 Hi, B Lukovic wrote: > The point is that if the data is created over SNMP there is no way with > proposed yang module > to preserve all info in the configuration. > When the agent is restarted (or new config committed), agent would "invent > indices" and > this is, in my opinion, the problem (not functionally, agent would still > function correctly). > But for SNMP manager monitoring the agent: > - index change would indicate change in configuration. > - getnext order could be different > > A few examples: > Lets say target address table has N entries, all using the same set of > parameters ( = one row in snmpTargetParamsTable). > > Changing parameters for all N addresses: > SNMP - one row changed > NETCONF- N rows changed > > Suspend communication with all N targets: > SNMP - delete one row in target params table (or set it to notInService), > target address table preserves all targets [Note that setting a row to notInService allows the agent to delete the row after some time. Suggested time is 5 minutes (RFC 2579).] > NETCONF- delete whole target list > > Regarding proposed solutions > 1) create "list targetparams" ... > basically map snmpTargetParamsTable to Yang, > complication could be solved as in SNMP mib, i.e. instead of leafref (forcing > each target row to have valid params) > this could be just a string making "loose" coupling. The loose coupling that makes the model very flexible, but also a bit difficult to configure correctly. I would prefer leafrefs to make a stricter coupling, but we have already had that discussion. > 2) replace optional "notify-filter-profile" leaf with mandatory "param-name" > leaf, ... > You are right, I overlooked that "list notify-filter-profile" should be updated > with "param-name" as well > > and a new one > > 3) add optional "leaf param-name" to "list target" so snmpTargetParamsName > could be preserved > If missing, agent would generate appropriate index for snmpTargetParamsTable > > I prefer option 1) Ok. /martin From mbj@tail-f.com Mon Feb 3 13:21:32 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86A261A0225 for ; Mon, 3 Feb 2014 13:21:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.436 X-Spam-Level: X-Spam-Status: No, score=-2.436 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H40uqZFNSSKW for ; Mon, 3 Feb 2014 13:21:31 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id C70611A01FB for ; Mon, 3 Feb 2014 13:21:30 -0800 (PST) Received: from localhost (unknown [193.12.32.88]) by mail.tail-f.com (Postfix) with ESMTPSA id 4D5EE37C1A6; Mon, 3 Feb 2014 22:21:30 +0100 (CET) Date: Mon, 03 Feb 2014 22:21:29 +0100 (CET) Message-Id: <20140203.222129.457630286.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20140202135609.GA35596@elstar.local> References: <20140202135609.GA35596@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] charter revision - please comment on charter-ietf-netmod-06-05 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Feb 2014 21:21:32 -0000 Juergen Schoenwaelder wrote: > Hi, > > we (the WG chairs and Benoit) have been working on a new charter for > the NETMOD working group. The current version can always be found > here. > > https://datatracker.ietf.org/doc/charter-ietf-netmod/ > > The current version is called charter-ietf-netmod-06-05 > > https://datatracker.ietf.org/doc/charter-ietf-netmod/withmilestones-06-05.txt > > Please review and feel invited to comment and ask questions. I think that in order to solve Y1 and Y3, we need an update to YANG. Since the proposed charter allows us to this, I guess the charter is ok. Regarding Y3 (YANG conformance), I don't think it is clear what problem we want to solve. In my experience, I have not seen the interoperability problems Andy's draft mentions. The draft raises some valid issues (e.g., hello message size explosion and if-feature with AND as only operator is too limiting), but I am not convinced that the current conformance mechanisms of YANG are not good enough. /martin From andy@yumaworks.com Mon Feb 3 13:40:06 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 972151A0232 for ; Mon, 3 Feb 2014 13:40:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ozpA0txYABsE for ; Mon, 3 Feb 2014 13:40:01 -0800 (PST) Received: from mail-pb0-f52.google.com (mail-pb0-f52.google.com [209.85.160.52]) by ietfa.amsl.com (Postfix) with ESMTP id 014911A0218 for ; Mon, 3 Feb 2014 13:40:00 -0800 (PST) Received: by mail-pb0-f52.google.com with SMTP id jt11so7585474pbb.39 for ; Mon, 03 Feb 2014 13:40:01 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=2iD62hNQ9jWbjr7/Jj0wBpP7T0HMV8bbS18q1aeF9LQ=; b=NHC1Qzh1kIGsOYc8L1MHhm0C7wcVvkB02YZwwfbAZl98FcK+05am8kAZyLo1t8A5+D WSHZI3ufqJJG2b3Pxmx0MAnpQooMpQdBgGkVSBdGm5c1s8aKWYU15Nu8hwDYyuETsmz3 bLeihB5iJ23g++Shk0lPZealnuchS7SkJVAdLDWVW1EUOUCryOM7WN6UiHhXKe8PaFI0 alZo8YrZ70kAACAF+/Km4Z+piPr6JJEIEHdn/UdqMMWzpPkQjxK5MwGISey6e4Ghc6BB as9dCa8zPCcJl7+3ZHpihQbjGJmQnpHoEZ9x9OqUws9hDhbHNXd5iO7KG71jxh8AtL7r et4w== X-Gm-Message-State: ALoCoQmsjP/m+uY1EhxrZyS7u6s87gMc2jDi6T+SFFipMgNw9uCTM7mYWJQQrh5K0dIY2kyx5RdG MIME-Version: 1.0 X-Received: by 10.69.19.139 with SMTP id gu11mr5766919pbd.149.1391463600964; Mon, 03 Feb 2014 13:40:00 -0800 (PST) Received: by 10.70.0.135 with HTTP; Mon, 3 Feb 2014 13:40:00 -0800 (PST) In-Reply-To: <20140203.222129.457630286.mbj@tail-f.com> References: <20140202135609.GA35596@elstar.local> <20140203.222129.457630286.mbj@tail-f.com> Date: Mon, 3 Feb 2014 13:40:00 -0800 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: multipart/alternative; boundary=001a11367374a75ed304f1875d25 Cc: "netmod@ietf.org" Subject: Re: [netmod] charter revision - please comment on charter-ietf-netmod-06-05 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Feb 2014 21:40:06 -0000 --001a11367374a75ed304f1875d25 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Feb 3, 2014 at 1:21 PM, Martin Bjorklund wrote: > Juergen Schoenwaelder wrote: > > Hi, > > > > we (the WG chairs and Benoit) have been working on a new charter for > > the NETMOD working group. The current version can always be found > > here. > > > > https://datatracker.ietf.org/doc/charter-ietf-netmod/ > > > > The current version is called charter-ietf-netmod-06-05 > > > > > https://datatracker.ietf.org/doc/charter-ietf-netmod/withmilestones-06-05.txt > > > > Please review and feel invited to comment and ask questions. > > I think that in order to solve Y1 and Y3, we need an update to YANG. > Since the proposed charter allows us to this, I guess the charter is > ok. > > Regarding Y3 (YANG conformance), I don't think it is clear what > problem we want to solve. In my experience, I have not seen the > interoperability problems Andy's draft mentions. The draft raises > some valid issues (e.g., hello message size explosion and if-feature > with AND as only operator is too limiting), but I am not convinced > that the current conformance mechanisms of YANG are not good enough. > > > I do not agree that Y3 would require an update to YANG that would impact the yang "module" and "submodule" constructions. None of the items in the charter proposal are must-have features. IMO, service-oriented conformance is better than the implied-mandatory + if-feature conformance model we have now. I have never actually seen the "identityref conflict" problem that the xpath functions need to address. Sure it is possible that a server will have 2 modules, each with the same named identity, each with the same base type, but I have never seen it actually done. There are several known issues with YANG that actually impact usage, and more XPath functions are fairly low on the list. We are not helping anyone by introducing a new YANG version with 1 of 10 known bugs fixed. Might as well fix all 10 if we bother with a YANG 1.1 release at all. IMO there are better things to work on, but a new YANG version just to introduce a few XPath functions would be net harmful to interoperability /martin > > Andy --001a11367374a75ed304f1875d25 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Mon, Feb 3, 2014 at 1:21 PM, Martin Bjorklund = <mbj@tail-f.com&= gt; wrote:
Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de<= /a>> wrote:
> Hi,
>
> we (the WG chairs and Benoit) have been working on a new charter for > the NETMOD working group. The current version can always be found
> here.
>
> =A0 https://datatracker.ietf.org/doc/charter-ietf-netmod/=
>
> The current version is called charter-ietf-netmod-06-05
>
> =A0 https://datatracker.ietf.org/doc/= charter-ietf-netmod/withmilestones-06-05.txt
>
> Please review and feel invited to comment and ask questions.

I think that in order to solve Y1 and Y3, we need an update to YANG.
Since the proposed charter allows us to this, I guess the charter is
ok.

Regarding Y3 (YANG conformance), I don't think it is clear what
problem we want to solve. =A0In my experience, I have not seen the
interoperability problems Andy's draft mentions. =A0The draft raises some valid issues (e.g., hello message size explosion and if-feature
with AND as only operator is too limiting), but I am not convinced
that the current conformance mechanisms of YANG are not good enough.



I do not agree that Y3 would require a= n update to YANG
that would impact the yang "module" an= d "submodule"
constructions. =A0None of the items in th= e charter proposal
are must-have features. =A0IMO, service-oriented conformance
is better than the implied-mandatory + if-feature conformance
mo= del we have now.

I have never actually seen the &q= uot;identityref conflict" problem that
the xpath functions need to address. Sure it is possible that
a server will have 2 modules, each with the same named
identity= , each with the same base type, but I have never seen it actually done.

There are several known issues with YANG that actually = impact usage,
and more XPath functions are fairly low on the list= . =A0We are not helping
anyone by introducing a new YANG version = with 1 of 10 known bugs fixed.
Might as well fix all 10 if we bother with a YANG 1.1 release at all.<= /div>

IMO there are better things to work on, but a new = YANG version just
to introduce a few XPath functions would be net= harmful to interoperability


/martin


Andy

<= /div> --001a11367374a75ed304f1875d25-- From mbj@tail-f.com Mon Feb 3 13:52:10 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31C1C1A019F for ; Mon, 3 Feb 2014 13:52:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.436 X-Spam-Level: X-Spam-Status: No, score=-2.436 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gjH8OEL9qlfv for ; Mon, 3 Feb 2014 13:52:08 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id 26B621A015D for ; Mon, 3 Feb 2014 13:52:08 -0800 (PST) Received: from localhost (unknown [193.12.32.88]) by mail.tail-f.com (Postfix) with ESMTPSA id 43DCE37C1A6; Mon, 3 Feb 2014 22:52:07 +0100 (CET) Date: Mon, 03 Feb 2014 22:52:06 +0100 (CET) Message-Id: <20140203.225206.439715352.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: <20140202135609.GA35596@elstar.local> <20140203.222129.457630286.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] charter revision - please comment on charter-ietf-netmod-06-05 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Feb 2014 21:52:10 -0000 Andy Bierman wrote: > On Mon, Feb 3, 2014 at 1:21 PM, Martin Bjorklund wrote: > > > Juergen Schoenwaelder wrote: > > > Hi, > > > > > > we (the WG chairs and Benoit) have been working on a new charter for > > > the NETMOD working group. The current version can always be found > > > here. > > > > > > https://datatracker.ietf.org/doc/charter-ietf-netmod/ > > > > > > The current version is called charter-ietf-netmod-06-05 > > > > > > > > https://datatracker.ietf.org/doc/charter-ietf-netmod/withmilestones-06-05.txt > > > > > > Please review and feel invited to comment and ask questions. > > > > I think that in order to solve Y1 and Y3, we need an update to YANG. > > Since the proposed charter allows us to this, I guess the charter is > > ok. > > > > Regarding Y3 (YANG conformance), I don't think it is clear what > > problem we want to solve. In my experience, I have not seen the > > interoperability problems Andy's draft mentions. The draft raises > > some valid issues (e.g., hello message size explosion and if-feature > > with AND as only operator is too limiting), but I am not convinced > > that the current conformance mechanisms of YANG are not good enough. > > > > > > > I do not agree that Y3 would require an update to YANG > that would impact the yang "module" and "submodule" > constructions. RFC 6020 says that a server MUST advertise the module namespace URI to indicate support for a module. I think your draft says that instead of doing that, the server can advertise a package. This changes RFC 6020 (yes, it does not change YANG syntax, but it sure impacts existing clients). [...] > We are not helping > anyone by introducing a new YANG version with 1 of 10 known bugs fixed. > Might as well fix all 10 if we bother with a YANG 1.1 release at all. Agreed. /martin From jasmbhat@cisco.com Mon Feb 3 09:59:28 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 701CF1A01C9 for ; Mon, 3 Feb 2014 09:59:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.035 X-Spam-Level: X-Spam-Status: No, score=-15.035 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ITJcusH1vZ6p for ; Mon, 3 Feb 2014 09:59:25 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id F12991A016D for ; Mon, 3 Feb 2014 09:59:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6456; q=dns/txt; s=iport; t=1391450365; x=1392659965; h=from:to:subject:date:message-id:mime-version; bh=RMc1X8yZqzujMZT3dx71vDbgxdXJUiWPfAn+jfuQ8Cc=; b=ILRgWrTx+c7lK97PZ0EmN6C73hVVskglcpdClrN8lAFj3ec40a5/rOAo yI81AWgMlJ2S3ECVUAMVAs8InhwZ3OMsTJKOT7emMDKj64bsfQhlwMMi2 rpyOjOST0g1Lml+5Zh/yEMRUs9MTM6Tv7PJRcV+o8xdD5KtoQPLfzpYn/ A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai4FAEDY71KtJXG8/2dsb2JhbABZgkhEgQ+/FRZ0giyBCwGBACcEiBidALBBF5NIBJgqkiGDLYFqJBw X-IronPort-AV: E=Sophos;i="4.95,773,1384300800"; d="scan'208,217";a="301603058" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-4.cisco.com with ESMTP; 03 Feb 2014 17:59:24 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id s13HxOaR015429 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 3 Feb 2014 17:59:24 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.60]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.03.0123.003; Mon, 3 Feb 2014 11:59:24 -0600 From: "Jasmeet Bhatia (jasmbhat)" To: "netmod@ietf.org" Thread-Topic: Issue with Choice Statement inside a List Statement Thread-Index: AQHPIQmrDQEuzncRlUmu+6BdultlUw== Date: Mon, 3 Feb 2014 17:59:23 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.156.45.3] Content-Type: multipart/alternative; boundary="_000_CF1518F978F5jasmbhatciscocom_" MIME-Version: 1.0 X-Mailman-Approved-At: Mon, 03 Feb 2014 14:05:47 -0800 Subject: [netmod] Issue with Choice Statement inside a List Statement X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Feb 2014 18:23:55 -0000 --_000_CF1518F978F5jasmbhatciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I am having issues defining a "choice" scenario inside a list statement. I = can't find any examples on how to do this either. The pyang validator is gi= ving me "error: the key "id" does not reference an existing leaf". Basicall= y I am trying to create a list where a list of "YangCar" can contain either= a "YangFordCar" or a "YangHondaCar". The key "id" of the YangCar list can'= t seem to find the reference to the leaf id used for the yang car. How do I= resolve this? container YangPersonList { list YangPerson { key id; uses YangPerson; container YangCarList { list YangCar { //The following id key id; choice YangCar { case YangFordCar { container YangFordCar{ uses YangFordCar; } } case YangHondaCar { container YangHondaCar{ uses YangHondaCar; } } } } } } } grouping YangCar { reference "com.cisco.xmp.model.test.containment.YangCar"; leaf id { mandatory true; type int64; } // Non-containment Associations } grouping YangHondaCar { reference "com.cisco.xmp.model.test.containment.YangHondaCar"; uses YangCar; // Non-containment Associations } grouping YangFordCar { reference "com.cisco.xmp.model.test.containment.YangFordCar"; uses YangCar; // Non-containment Associations } --_000_CF1518F978F5jasmbhatciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
I am having issues defining a "choice" scenario inside a lis= t statement. I can't find any examples on how to do this either. The pyang = validator is giving me "error: the key "id" does not referen= ce an existing leaf". Basically I am trying to create a list where a list of "YangCar" can contain either a "YangFordCar= " or a "YangHondaCar". The key "id" of the YangCar= list can't seem to find the reference to the leaf id used for the yang car= . How do I resolve this?

container YangPersonList {
      list YangPerson {
         key id;
         uses YangPerson;
         container YangCarList {
            list YangCar {
//The = following id 
key id= ;
choice= YangCar {
 = case YangFordCar {
contai= ner YangFordCar{
 =            uses YangFordCar;
}
 =         }
 = case YangHondaCar {
contai= ner YangHondaCar{
 =    uses YangHondaCar;
}
 =         }
 =      }
            }
         }
      }
   }


   grouping YangCar {
      reference
        "com.cisco.xmp.model.test.containment.YangCar&qu= ot;;
      leaf id {
      mandatory true;
         type int64;
      }

         // Non-containment Associations
   }
   grouping YangHondaCar {
      reference
        "com.cisco.xmp.model.test.containment.YangHondaC= ar";
      uses YangCar;
         // Non-containment Associations
   }
   grouping YangFordCar {
      reference
        "com.cisco.xmp.model.test.containment.YangFordCa= r";
      uses YangCar;
         // Non-containment Associations
   }





--_000_CF1518F978F5jasmbhatciscocom_-- From andy@yumaworks.com Mon Feb 3 14:20:10 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DB881A0248 for ; Mon, 3 Feb 2014 14:20:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w8E5EAeaA-qn for ; Mon, 3 Feb 2014 14:20:07 -0800 (PST) Received: from mail-qa0-f48.google.com (mail-qa0-f48.google.com [209.85.216.48]) by ietfa.amsl.com (Postfix) with ESMTP id 7E77C1A015D for ; Mon, 3 Feb 2014 14:20:07 -0800 (PST) Received: by mail-qa0-f48.google.com with SMTP id f11so10915894qae.21 for ; Mon, 03 Feb 2014 14:20:07 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=iKNWh/pPzSQavn2QZQVrbUCr68+7f7BM6s5naEiUfgQ=; b=HaahfHubedS+/8j8hko3xh11LV1PerRO9unxkLGO5RXpXEqhiw+QiCQVl+aK17gsra +Niy2qkVKzvWpVv7tVub9gbMI0hqAZO7FBPCLIN0bX+LHWIB8b+kx7bzXxGSVf3r4t7r Q0f7gcpAchAJqedMXS+JFUCABzxbHk2XkH/+1JFQBElwHjDgeeIKBk1lI6yb+gqqS311 egRJymAKJK6wnh8Ibc4Qdt3MLUyBky8YGAhoUbiL8Dxw/aeI5raqOI9VEl9zcTcbnFU7 TzGKrs5OrLPpQPRMIK4D5saRqIMsqK67PU0W0VwgF38g2rPDfmto5VmxVMzdkhlgeV+3 fLvQ== X-Gm-Message-State: ALoCoQmY0dmBs/lsojYGWewnaXTPf0LCqrwUWw/VoYqF6H7LCm52sPyB6SQpngV4Wov8LaIsgRWZ MIME-Version: 1.0 X-Received: by 10.229.139.199 with SMTP id f7mr60268330qcu.2.1391466006234; Mon, 03 Feb 2014 14:20:06 -0800 (PST) Received: by 10.140.48.75 with HTTP; Mon, 3 Feb 2014 14:20:06 -0800 (PST) In-Reply-To: <20140203.225206.439715352.mbj@tail-f.com> References: <20140202135609.GA35596@elstar.local> <20140203.222129.457630286.mbj@tail-f.com> <20140203.225206.439715352.mbj@tail-f.com> Date: Mon, 3 Feb 2014 14:20:06 -0800 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: multipart/alternative; boundary=001a11c3e45404d08b04f187edf7 Cc: "netmod@ietf.org" Subject: Re: [netmod] charter revision - please comment on charter-ietf-netmod-06-05 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Feb 2014 22:20:10 -0000 --001a11c3e45404d08b04f187edf7 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Feb 3, 2014 at 1:52 PM, Martin Bjorklund wrote: > Andy Bierman wrote: > > On Mon, Feb 3, 2014 at 1:21 PM, Martin Bjorklund wrote: > > > > > Juergen Schoenwaelder wrote: > > > > Hi, > > > > > > > > we (the WG chairs and Benoit) have been working on a new charter for > > > > the NETMOD working group. The current version can always be found > > > > here. > > > > > > > > https://datatracker.ietf.org/doc/charter-ietf-netmod/ > > > > > > > > The current version is called charter-ietf-netmod-06-05 > > > > > > > > > > > > https://datatracker.ietf.org/doc/charter-ietf-netmod/withmilestones-06-05.txt > > > > > > > > Please review and feel invited to comment and ask questions. > > > > > > I think that in order to solve Y1 and Y3, we need an update to YANG. > > > Since the proposed charter allows us to this, I guess the charter is > > > ok. > > > > > > Regarding Y3 (YANG conformance), I don't think it is clear what > > > problem we want to solve. In my experience, I have not seen the > > > interoperability problems Andy's draft mentions. The draft raises > > > some valid issues (e.g., hello message size explosion and if-feature > > > with AND as only operator is too limiting), but I am not convinced > > > that the current conformance mechanisms of YANG are not good enough. > > > > > > > > > > > I do not agree that Y3 would require an update to YANG > > that would impact the yang "module" and "submodule" > > constructions. > > RFC 6020 says that a server MUST advertise the module namespace URI to > indicate support for a module. I think your draft says that instead > of doing that, the server can advertise a package. This changes RFC > 6020 (yes, it does not change YANG syntax, but it sure impacts > existing clients). > No -- I was wrong about that. I think that text was in a slide at the IETF but not in the draft. There is no text that says the server does not send module URIs. > [...] > > > We are not helping > > anyone by introducing a new YANG version with 1 of 10 known bugs fixed. > > Might as well fix all 10 if we bother with a YANG 1.1 release at all. > > Agreed. > > /martin > > Andy --001a11c3e45404d08b04f187edf7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Mon, Feb 3, 2014 at 1:52 PM, Martin Bjorklund = <mbj@tail-f.com&= gt; wrote:
Andy Bierman <and= y@yumaworks.com> wrote:
> On Mon, Feb 3, 2014 at 1:21 PM, Martin Bjorklund <mbj@tail-f.com> wrote:
>
> > Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
> > > Hi,
> > >
> > > we (the WG chairs and Benoit) have been working on a new cha= rter for
> > > the NETMOD working group. The current version can always be = found
> > > here.
> > >
> > > =A0 https://datatracker.ietf.org/doc/charter-ietf-n= etmod/
> > >
> > > The current version is called charter-ietf-netmod-06-05
> > >
> > >
> > https://datatracker.ietf.org/doc= /charter-ietf-netmod/withmilestones-06-05.txt
> > >
> > > Please review and feel invited to comment and ask questions.=
> >
> > I think that in order to solve Y1 and Y3, we need an update to YA= NG.
> > Since the proposed charter allows us to this, I guess the charter= is
> > ok.
> >
> > Regarding Y3 (YANG conformance), I don't think it is clear wh= at
> > problem we want to solve. =A0In my experience, I have not seen th= e
> > interoperability problems Andy's draft mentions. =A0The draft= raises
> > some valid issues (e.g., hello message size explosion and if-feat= ure
> > with AND as only operator is too limiting), but I am not convince= d
> > that the current conformance mechanisms of YANG are not good enou= gh.
> >
> >
> >
> I do not agree that Y3 would require an update to YANG
> that would impact the yang "module" and "submodule"= ;
> constructions.

RFC 6020 says that a server MUST advertise the module namespace URI to
indicate support for a module. =A0I think your draft says that instead
of doing that, the server can advertise a package. =A0This changes RFC
6020 (yes, it does not change YANG syntax, but it sure impacts
existing clients).

No -- I was wrong ab= out that.
I think that text was in a slide at the IETF but not in= the draft.
There is no text that says the server does not send m= odule URIs.



[...]

> We are not helping
> anyone by introducing a new YANG version with 1 of 10 known bugs fixed= .
> Might as well fix all 10 if we bother with a YANG 1.1 release at all.<= br>
Agreed.=A0

/martin


Andy<= /div>

--001a11c3e45404d08b04f187edf7-- From mbj@tail-f.com Mon Feb 3 14:26:13 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98DF71A01EE for ; Mon, 3 Feb 2014 14:26:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.436 X-Spam-Level: X-Spam-Status: No, score=-2.436 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HBDHWxlTT0ov for ; Mon, 3 Feb 2014 14:26:11 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id B618A1A015D for ; Mon, 3 Feb 2014 14:26:11 -0800 (PST) Received: from localhost (unknown [193.12.32.88]) by mail.tail-f.com (Postfix) with ESMTPSA id E51A337C1A6; Mon, 3 Feb 2014 23:26:10 +0100 (CET) Date: Mon, 03 Feb 2014 23:26:10 +0100 (CET) Message-Id: <20140203.232610.166683380.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: <20140203.225206.439715352.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] charter revision - please comment on charter-ietf-netmod-06-05 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Feb 2014 22:26:13 -0000 Andy Bierman wrote: > On Mon, Feb 3, 2014 at 1:52 PM, Martin Bjorklund wrote: > > > Andy Bierman wrote: > > > On Mon, Feb 3, 2014 at 1:21 PM, Martin Bjorklund wrote: > > > > > > > Juergen Schoenwaelder wrote: > > > > > Hi, > > > > > > > > > > we (the WG chairs and Benoit) have been working on a new charter for > > > > > the NETMOD working group. The current version can always be found > > > > > here. > > > > > > > > > > https://datatracker.ietf.org/doc/charter-ietf-netmod/ > > > > > > > > > > The current version is called charter-ietf-netmod-06-05 > > > > > > > > > > > > > > > > https://datatracker.ietf.org/doc/charter-ietf-netmod/withmilestones-06-05.txt > > > > > > > > > > Please review and feel invited to comment and ask questions. > > > > > > > > I think that in order to solve Y1 and Y3, we need an update to YANG. > > > > Since the proposed charter allows us to this, I guess the charter is > > > > ok. > > > > > > > > Regarding Y3 (YANG conformance), I don't think it is clear what > > > > problem we want to solve. In my experience, I have not seen the > > > > interoperability problems Andy's draft mentions. The draft raises > > > > some valid issues (e.g., hello message size explosion and if-feature > > > > with AND as only operator is too limiting), but I am not convinced > > > > that the current conformance mechanisms of YANG are not good enough. > > > > > > > > > > > > > > > I do not agree that Y3 would require an update to YANG > > > that would impact the yang "module" and "submodule" > > > constructions. > > > > RFC 6020 says that a server MUST advertise the module namespace URI to > > indicate support for a module. I think your draft says that instead > > of doing that, the server can advertise a package. This changes RFC > > 6020 (yes, it does not change YANG syntax, but it sure impacts > > existing clients). > > > > No -- I was wrong about that. > I think that text was in a slide at the IETF but not in the draft. > There is no text that says the server does not send module URIs. Ok. Then I agree an update to YANG is not necessary. But then it also doesn't solve the hello message size problem... :( But... if all 6020-compliant module capabilities are advertised, what information in the package can the client use that is not in the normal module advertisment (and doesn't break 6020 rules)? /martin From andy@yumaworks.com Mon Feb 3 14:39:05 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5045C1A028F for ; Mon, 3 Feb 2014 14:39:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yJG0ukr9l6yv for ; Mon, 3 Feb 2014 14:39:02 -0800 (PST) Received: from mail-qc0-f179.google.com (mail-qc0-f179.google.com [209.85.216.179]) by ietfa.amsl.com (Postfix) with ESMTP id 3310B1A015D for ; Mon, 3 Feb 2014 14:39:02 -0800 (PST) Received: by mail-qc0-f179.google.com with SMTP id e16so12148357qcx.38 for ; Mon, 03 Feb 2014 14:39:01 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=VZTgWAo3dhK9veg53Lef5UECphFf5TveL6LFpJapO4k=; b=Deajlpy+7i8ZGWP92udLVcy/pAtAAvshQANDXwHMK2jbwFJO1lSRuBC4+/qRG3xoPd QBpFCUrSqp3/sm9dZcG8Q0lUfvomBjPIlQpZ1A/CG3RU9X/JxKS5YvoGJBbg9yjHTvrx LPKI0MDT/KB9391H2Pq+pgFaqvlwAXF8R1AghueXaLkMg0mc8QQdPtLkuMZg/8feSd49 vQ+IvgGZ0dKF9KlW4qMb3eOAT+s+PmMicmnxieCLIEgbURSKS6Fh9kIoTbg3DHrCYBu5 84WcdM1yqFGmrFDwnHoDBWzRw0x+kl7+WGRocsDjFmvBSVKv4UJxzf+P/j0OWfRLK4fd yQ8A== X-Gm-Message-State: ALoCoQmywxt55Wb7CU/0dJ84ps/nzBLo9kPNMGz41rHItgQ6Bqbe7+BMYEBtB75n2ebDBxPfq861 MIME-Version: 1.0 X-Received: by 10.140.27.179 with SMTP id 48mr56529532qgx.18.1391467141639; Mon, 03 Feb 2014 14:39:01 -0800 (PST) Received: by 10.140.48.75 with HTTP; Mon, 3 Feb 2014 14:39:01 -0800 (PST) In-Reply-To: <20140203.232610.166683380.mbj@tail-f.com> References: <20140203.225206.439715352.mbj@tail-f.com> <20140203.232610.166683380.mbj@tail-f.com> Date: Mon, 3 Feb 2014 14:39:01 -0800 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: multipart/alternative; boundary=001a11c00434b1c13e04f188307e Cc: "netmod@ietf.org" Subject: Re: [netmod] charter revision - please comment on charter-ietf-netmod-06-05 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Feb 2014 22:39:05 -0000 --001a11c00434b1c13e04f188307e Content-Type: text/plain; charset=ISO-8859-1 On Mon, Feb 3, 2014 at 2:26 PM, Martin Bjorklund wrote: > Andy Bierman wrote: > > On Mon, Feb 3, 2014 at 1:52 PM, Martin Bjorklund wrote: > > > > > Andy Bierman wrote: > > > > On Mon, Feb 3, 2014 at 1:21 PM, Martin Bjorklund > wrote: > > > > > > > > > Juergen Schoenwaelder > wrote: > > > > > > Hi, > > > > > > > > > > > > we (the WG chairs and Benoit) have been working on a new charter > for > > > > > > the NETMOD working group. The current version can always be found > > > > > > here. > > > > > > > > > > > > https://datatracker.ietf.org/doc/charter-ietf-netmod/ > > > > > > > > > > > > The current version is called charter-ietf-netmod-06-05 > > > > > > > > > > > > > > > > > > > > > https://datatracker.ietf.org/doc/charter-ietf-netmod/withmilestones-06-05.txt > > > > > > > > > > > > Please review and feel invited to comment and ask questions. > > > > > > > > > > I think that in order to solve Y1 and Y3, we need an update to > YANG. > > > > > Since the proposed charter allows us to this, I guess the charter > is > > > > > ok. > > > > > > > > > > Regarding Y3 (YANG conformance), I don't think it is clear what > > > > > problem we want to solve. In my experience, I have not seen the > > > > > interoperability problems Andy's draft mentions. The draft raises > > > > > some valid issues (e.g., hello message size explosion and > if-feature > > > > > with AND as only operator is too limiting), but I am not convinced > > > > > that the current conformance mechanisms of YANG are not good > enough. > > > > > > > > > > > > > > > > > > > I do not agree that Y3 would require an update to YANG > > > > that would impact the yang "module" and "submodule" > > > > constructions. > > > > > > RFC 6020 says that a server MUST advertise the module namespace URI to > > > indicate support for a module. I think your draft says that instead > > > of doing that, the server can advertise a package. This changes RFC > > > 6020 (yes, it does not change YANG syntax, but it sure impacts > > > existing clients). > > > > > > > No -- I was wrong about that. > > I think that text was in a slide at the IETF but not in the draft. > > There is no text that says the server does not send module URIs. > > Ok. Then I agree an update to YANG is not necessary. But then it > also doesn't solve the hello message size problem... :( > > Unless the client message has some indication that the client knows YANG 1.1 then the server cannot send the abbreviated (in the NETCONF-EX draft). But... if all 6020-compliant module capabilities are advertised, what > information in the package can the client use that is not in the > normal module advertisment (and doesn't break 6020 rules)? > Some basic stuff like import-only vs. conformance. Some fancy stuff like multi-module service profiles. IMO we will already these features if you count all the vendor modules. We could do the work in phases: phase 1) address the real deficiencies with the current conformance phase 2) develop reusable service level conformance abstraction mechanisms > > /martin > Andy --001a11c00434b1c13e04f188307e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Mon, Feb 3, 2014 at 2:26 PM, Martin Bjorklund = <mbj@tail-f.com&= gt; wrote:
Andy Bierman <andy@yumaworks.com> wrote:
> On Mon, Feb 3, 2014 at 1:52 PM, Martin Bjorklund <mbj@tail-f.com> wrote:
>
> > Andy Bierman <andy@yumaw= orks.com> wrote:
> > > On Mon, Feb 3, 2014 at 1:21 PM, Martin Bjorklund <mbj@tail-f.com> wrote:
> > >
> > > > Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wro= te:
> > > > > Hi,
> > > > >
> > > > > we (the WG chairs and Benoit) have been working on= a new charter for
> > > > > the NETMOD working group. The current version can = always be found
> > > > > here.
> > > > >
> > > > > =A0 https://datatracker.ietf.org/doc/char= ter-ietf-netmod/
> > > > >
> > > > > The current version is called charter-ietf-netmod-= 06-05
> > > > >
> > > > >
> > > >
> > https://datatracker.ietf.org/doc= /charter-ietf-netmod/withmilestones-06-05.txt
> > > > >
> > > > > Please review and feel invited to comment and ask = questions.
> > > >
> > > > I think that in order to solve Y1 and Y3, we need an up= date to YANG.
> > > > Since the proposed charter allows us to this, I guess t= he charter is
> > > > ok.
> > > >
> > > > Regarding Y3 (YANG conformance), I don't think it i= s clear what
> > > > problem we want to solve. =A0In my experience, I have n= ot seen the
> > > > interoperability problems Andy's draft mentions. = =A0The draft raises
> > > > some valid issues (e.g., hello message size explosion a= nd if-feature
> > > > with AND as only operator is too limiting), but I am no= t convinced
> > > > that the current conformance mechanisms of YANG are not= good enough.
> > > >
> > > >
> > > >
> > > I do not agree that Y3 would require an update to YANG
> > > that would impact the yang "module" and "subm= odule"
> > > constructions.
> >
> > RFC 6020 says that a server MUST advertise the module namespace U= RI to
> > indicate support for a module. =A0I think your draft says that in= stead
> > of doing that, the server can advertise a package. =A0This change= s RFC
> > 6020 (yes, it does not change YANG syntax, but it sure impacts > > existing clients).
> >
>
> No -- I was wrong about that.
> I think that text was in a slide at the IETF but not in the draft.
> There is no text that says the server does not send module URIs.

Ok. =A0Then I agree an update to YANG is not necessary. =A0But then it
also doesn't solve the hello message size problem... :(


Unless the client <hello> messag= e has some indication
that the client knows YANG 1.1 then the ser= ver cannot send
the abbreviated <hello> (in the NETCONF-EX = draft).

But... if all 6020-compliant module capabilities are advertised, what
information in the package can the client use that is not in the
normal module advertisment (and doesn't break 6020 rules)?

Some basic stuff like import-only vs. conformance.<= /div>
Some fancy stuff like multi-module service profiles.
IMO we will already these features if you count all
the vendor mo= dules. =A0

We could do the work in phases:

phase 1) address the real deficiencies with the current c= onformance
phase 2) develop reusable service level conformance abstraction mechan= isms




/martin


<= /div>
Andy

--001a11c00434b1c13e04f188307e-- From lhotka@nic.cz Tue Feb 4 01:10:55 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC6911A03A1 for ; Tue, 4 Feb 2014 01:10:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.996 X-Spam-Level: X-Spam-Status: No, score=-0.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HOST_EQ_CZ=0.904] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aGGzsC4OZs8B for ; Tue, 4 Feb 2014 01:10:53 -0800 (PST) Received: from trail.lhotka.name (nat-5.bravonet.cz [77.48.224.5]) by ietfa.amsl.com (Postfix) with ESMTP id B3D801A03C6 for ; Tue, 4 Feb 2014 01:10:52 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id E35F1540653; Tue, 4 Feb 2014 10:10:51 +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 tGJOBGCGKXD6; Tue, 4 Feb 2014 10:10:48 +0100 (CET) Received: from localhost (unknown [172.29.2.201]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 307855401F0; Tue, 4 Feb 2014 10:10:48 +0100 (CET) From: Ladislav Lhotka To: "Jasmeet Bhatia \(jasmbhat\)" , "netmod\@ietf.org" In-Reply-To: References: User-Agent: Notmuch/0.17~rc2+11~g2de8ce9 (http://notmuchmail.org) Emacs/24.3.50.2 (x86_64-apple-darwin13.0.0) Date: Tue, 04 Feb 2014 10:10:47 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Subject: Re: [netmod] Issue with Choice Statement inside a List Statement X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2014 09:10:56 -0000 Hi, "Jasmeet Bhatia (jasmbhat)" writes: > I am having issues defining a "choice" scenario inside a list statement. I can't find any examples on how to do this either. The pyang validator is giving me "error: the key "id" does not reference an existing leaf". Basically I am trying to create a list where a list of "YangCar" can contain either a "YangFordCar" or a "YangHondaCar". The key "id" of the YangCar list can't seem to find the reference to the leaf id used for the yang car. How do I resolve this? > > container YangPersonList { > list YangPerson { > key id; > uses YangPerson; > container YangCarList { > list YangCar { > //The following id > key id; > choice YangCar { > case YangFordCar { > container YangFordCar{ The key leaf has to be a child of the list node, so either remove this container (and the one in the other case) or move the definition of "id" out of the choice. Lada > uses YangFordCar; > } > } > case YangHondaCar { > container YangHondaCar{ > uses YangHondaCar; > } > } > } > } > } > } > } > > > grouping YangCar { > reference > "com.cisco.xmp.model.test.containment.YangCar"; > leaf id { > mandatory true; > type int64; > } > > // Non-containment Associations > } > grouping YangHondaCar { > reference > "com.cisco.xmp.model.test.containment.YangHondaCar"; > uses YangCar; > // Non-containment Associations > } > grouping YangFordCar { > reference > "com.cisco.xmp.model.test.containment.YangFordCar"; > uses YangCar; > // Non-containment Associations > } > > > > > > _______________________________________________ > 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 Tue Feb 4 01:13:53 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68BE31A03C6 for ; Tue, 4 Feb 2014 01:13:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.186 X-Spam-Level: X-Spam-Status: No, score=-1.186 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RP_MATCHES_RCVD=-0.535] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dQPgkCQvgvc5 for ; Tue, 4 Feb 2014 01:13: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 E8F5B1A03A1 for ; Tue, 4 Feb 2014 01:13:51 -0800 (PST) Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 37B4A13F721; Tue, 4 Feb 2014 10:13:51 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1391505231; bh=avHwsYIS1OWoD+5NrOx5CT6pEuiHPruMhw3uZOk2lq0=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date: Content-Transfer-Encoding:Message-Id:References:To; b=CDvm4swnJUJ6WQX9gPchCpu79D0J33CQ2qBV7n4hjTqHYoQk9H6acDIJUQVhZtqMc wZ6IS9oWfXQUVIfKIKLcFd+OOsPeSNlrQn8YxxMWhrps5ZSYiT5hM3nBk7cVVn3BeG 5UoaB3oA8yUPVeQE4QcTYiQDzP7tXujbmjJ8SMlI= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Ladislav Lhotka In-Reply-To: Date: Tue, 4 Feb 2014 10:13:50 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <5F29237C-B533-495E-A126-F0CDAD248E1B@nic.cz> References: To: "Jasmeet Bhatia (jasmbhat)" , "netmod@ietf.org" X-Mailer: Apple Mail (2.1827) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Subject: Re: [netmod] Issue with Choice Statement inside a List Statement X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2014 09:13:53 -0000 On 04 Feb 2014, at 10:10, Ladislav Lhotka wrote: > Hi, >=20 > "Jasmeet Bhatia (jasmbhat)" writes: >=20 >> I am having issues defining a "choice" scenario inside a list = statement. I can't find any examples on how to do this either. The pyang = validator is giving me "error: the key "id" does not reference an = existing leaf". Basically I am trying to create a list where a list of = "YangCar" can contain either a "YangFordCar" or a "YangHondaCar". The = key "id" of the YangCar list can't seem to find the reference to the = leaf id used for the yang car. How do I resolve this? >>=20 >> container YangPersonList { >> list YangPerson { >> key id; >> uses YangPerson; >> container YangCarList { >> list YangCar { >> //The following id >> key id; >> choice YangCar { >> case YangFordCar { >> container YangFordCar{ >=20 > The key leaf has to be a child of the list node, so either remove this = container (and the one in the other case) or move the definition of "id" = out of the choice. Actually only the latter works here because =93id=94 cannot be defined = twice in both cases. Lada >=20 > Lada >=20 >> uses YangFordCar; >> } >> } >> case YangHondaCar { >> container YangHondaCar{ >> uses YangHondaCar; >> } >> } >> } >> } >> } >> } >> } >>=20 >>=20 >> grouping YangCar { >> reference >> "com.cisco.xmp.model.test.containment.YangCar"; >> leaf id { >> mandatory true; >> type int64; >> } >>=20 >> // Non-containment Associations >> } >> grouping YangHondaCar { >> reference >> "com.cisco.xmp.model.test.containment.YangHondaCar"; >> uses YangCar; >> // Non-containment Associations >> } >> grouping YangFordCar { >> reference >> "com.cisco.xmp.model.test.containment.YangFordCar"; >> uses YangCar; >> // Non-containment Associations >> } >>=20 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >=20 > --=20 > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From mbj@tail-f.com Tue Feb 4 01:19:25 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C36D1A03C7 for ; Tue, 4 Feb 2014 01:19:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.436 X-Spam-Level: X-Spam-Status: No, score=-2.436 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VBxnP6PFMfV0 for ; Tue, 4 Feb 2014 01:19:22 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id 2BCF01A03A1 for ; Tue, 4 Feb 2014 01:19:22 -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 7DC0437C19C; Tue, 4 Feb 2014 10:19:21 +0100 (CET) Date: Tue, 04 Feb 2014 10:19:21 +0100 (CET) Message-Id: <20140204.101921.724083919961589738.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: <20140203.232610.166683380.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] charter revision - please comment on charter-ietf-netmod-06-05 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2014 09:19:25 -0000 Andy Bierman wrote: > On Mon, Feb 3, 2014 at 2:26 PM, Martin Bjorklund wrote: > > > Andy Bierman wrote: > > > On Mon, Feb 3, 2014 at 1:52 PM, Martin Bjorklund wrote: > > > > > > > Andy Bierman wrote: > > > > > On Mon, Feb 3, 2014 at 1:21 PM, Martin Bjorklund > > wrote: > > > > > > > > > > > Juergen Schoenwaelder > > wrote: > > > > > > > Hi, > > > > > > > > > > > > > > we (the WG chairs and Benoit) have been working on a new charter > > for > > > > > > > the NETMOD working group. The current version can always be found > > > > > > > here. > > > > > > > > > > > > > > https://datatracker.ietf.org/doc/charter-ietf-netmod/ > > > > > > > > > > > > > > The current version is called charter-ietf-netmod-06-05 > > > > > > > > > > > > > > > > > > > > > > > > > > https://datatracker.ietf.org/doc/charter-ietf-netmod/withmilestones-06-05.txt > > > > > > > > > > > > > > Please review and feel invited to comment and ask questions. > > > > > > > > > > > > I think that in order to solve Y1 and Y3, we need an update to > > YANG. > > > > > > Since the proposed charter allows us to this, I guess the charter > > is > > > > > > ok. > > > > > > > > > > > > Regarding Y3 (YANG conformance), I don't think it is clear what > > > > > > problem we want to solve. In my experience, I have not seen the > > > > > > interoperability problems Andy's draft mentions. The draft raises > > > > > > some valid issues (e.g., hello message size explosion and > > if-feature > > > > > > with AND as only operator is too limiting), but I am not convinced > > > > > > that the current conformance mechanisms of YANG are not good > > enough. > > > > > > > > > > > > > > > > > > > > > > > I do not agree that Y3 would require an update to YANG > > > > > that would impact the yang "module" and "submodule" > > > > > constructions. > > > > > > > > RFC 6020 says that a server MUST advertise the module namespace URI to > > > > indicate support for a module. I think your draft says that instead > > > > of doing that, the server can advertise a package. This changes RFC > > > > 6020 (yes, it does not change YANG syntax, but it sure impacts > > > > existing clients). > > > > > > > > > > No -- I was wrong about that. > > > I think that text was in a slide at the IETF but not in the draft. > > > There is no text that says the server does not send module URIs. > > > > Ok. Then I agree an update to YANG is not necessary. But then it > > also doesn't solve the hello message size problem... :( > > > > > Unless the client message has some indication > that the client knows YANG 1.1 then the server cannot send > the abbreviated (in the NETCONF-EX draft). That's what I was saying - if we want to change what's advertised, we need to update 6020. If a prerequisite is that we don't update 6020, I don't think we can much about the problems listed in your draft. > > But... if all 6020-compliant module capabilities are advertised, what > > information in the package can the client use that is not in the > > normal module advertisment (and doesn't break 6020 rules)? > > > > Some basic stuff like import-only vs. conformance. I think it must be clear from the YANG spec what it means to advertise a module. If this is not clear we need to fix that in the spec. > Some fancy stuff like multi-module service profiles. > IMO we will already these features if you count all > the vendor modules. > > We could do the work in phases: > > phase 1) address the real deficiencies with the current conformance > phase 2) develop reusable service level conformance abstraction mechanisms I think this makes sense. /martin From lhotka@nic.cz Tue Feb 4 01:33:20 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1856B1A03D0 for ; Tue, 4 Feb 2014 01:33:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.996 X-Spam-Level: X-Spam-Status: No, score=-0.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HOST_EQ_CZ=0.904] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kSF7X6ZC5IAU for ; Tue, 4 Feb 2014 01:33:19 -0800 (PST) Received: from trail.lhotka.name (nat-5.bravonet.cz [77.48.224.5]) by ietfa.amsl.com (Postfix) with ESMTP id C6FA91A03A1 for ; Tue, 4 Feb 2014 01:33:18 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 2978D540653; Tue, 4 Feb 2014 10:33:18 +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 mIozqPRCoXjJ; Tue, 4 Feb 2014 10:33:12 +0100 (CET) Received: from localhost (unknown [172.29.2.201]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id E23855401F0; Tue, 4 Feb 2014 10:33:11 +0100 (CET) From: Ladislav Lhotka To: Juergen Schoenwaelder , netmod@ietf.org In-Reply-To: <20140202135609.GA35596@elstar.local> References: <20140202135609.GA35596@elstar.local> User-Agent: Notmuch/0.17~rc2+11~g2de8ce9 (http://notmuchmail.org) Emacs/24.3.50.2 (x86_64-apple-darwin13.0.0) Date: Tue, 04 Feb 2014 10:33:11 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Subject: Re: [netmod] charter revision - please comment on charter-ietf-netmod-06-05 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2014 09:33:20 -0000 Hi, I like the charter and I have two questions/comments: 1. One of the aims of YANG 1.1 should be to relax the limitation of YANG to NETCONF, as a reaction to the recent developments (RESTCONF, I2RS and a few projects outside IETF). 2. Is it intentional that no specific new data models are mentioned, except the stateless packet filter example? A few items are already on the table. Lada Juergen Schoenwaelder writes: > Hi, > > we (the WG chairs and Benoit) have been working on a new charter for > the NETMOD working group. The current version can always be found > here. > > https://datatracker.ietf.org/doc/charter-ietf-netmod/ > > The current version is called charter-ietf-netmod-06-05 > > https://datatracker.ietf.org/doc/charter-ietf-netmod/withmilestones-06-05.txt > > Please review and feel invited to comment and ask questions. > > /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 Feb 4 01:45:09 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DA211A03EF for ; Tue, 4 Feb 2014 01:45:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.785 X-Spam-Level: X-Spam-Status: No, score=-2.785 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.535] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TNCVeB_QlY9f for ; Tue, 4 Feb 2014 01:45:07 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id D3F371A03DC for ; Tue, 4 Feb 2014 01:45:06 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3F61320122; Tue, 4 Feb 2014 10:45:06 +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 9g8hQX3aZMGc; Tue, 4 Feb 2014 10:45:06 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id E882420032; Tue, 4 Feb 2014 10:43:00 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id CACF22B0CFA5; Tue, 4 Feb 2014 10:42:58 +0100 (CET) Date: Tue, 4 Feb 2014 10:42:58 +0100 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20140204094258.GA42890@elstar.local> Mail-Followup-To: Ladislav Lhotka , netmod@ietf.org References: <20140202135609.GA35596@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] charter revision - please comment on charter-ietf-netmod-06-05 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2014 09:45:09 -0000 On Tue, Feb 04, 2014 at 10:33:11AM +0100, Ladislav Lhotka wrote: > > 2. Is it intentional that no specific new data models are mentioned, except the stateless packet filter example? A few items are already on the table. > The idea was to let the charter be flexible such that the WG can take on data models without having to recharter. From what has been proposed, the stateless packet filter work seems to be a relatively clear cut case. The topology work interacts with the information model work submitted by the same authors to I2RS so it seems we need to figure out where this work will be entertained. The other proposals do not really seem to be mature enough to work on them at this point in time. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From lhotka@nic.cz Tue Feb 4 02:02:23 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DD321A036E for ; Tue, 4 Feb 2014 02:02:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.886 X-Spam-Level: X-Spam-Status: No, score=-0.886 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.535] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xqmHe2eHaRKX for ; Tue, 4 Feb 2014 02:02: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 DF2E71A02BC for ; Tue, 4 Feb 2014 02:02:21 -0800 (PST) Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 8CBE013FBD3; Tue, 4 Feb 2014 11:02:20 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1391508140; bh=o9RftTcTpLTieWcD2bFhsuZyhGbNZ3imIrcxUGLXHgw=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=hjf6fTNj/m3ONw3AieOUyD9kep3/c1FwyNz6AFaeEqT833+OBTYP3bR4jVrJKzS5S FFxVHvc1/cv/Xo0+uSJJPFzgIbZO2YQ/nw2scll4Kaop9GgUZKjkEiFz/nXkagRNoy DqQe/EW/VEZto5VtzcIRteXEbkVqCSO3gmC8shZk= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Ladislav Lhotka In-Reply-To: <20140204094258.GA42890@elstar.local> Date: Tue, 4 Feb 2014 11:02:19 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <99860237-B703-43F1-A511-AD87760B9872@nic.cz> References: <20140202135609.GA35596@elstar.local> <20140204094258.GA42890@elstar.local> To: =?windows-1252?Q?J=FCrgen_Sch=F6nw=E4lder?= X-Mailer: Apple Mail (2.1827) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] charter revision - please comment on charter-ietf-netmod-06-05 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2014 10:02:23 -0000 On 04 Feb 2014, at 10:42, Juergen Schoenwaelder = wrote: > On Tue, Feb 04, 2014 at 10:33:11AM +0100, Ladislav Lhotka wrote: >>=20 >> 2. Is it intentional that no specific new data models are mentioned, = except the stateless packet filter example? A few items are already on = the table. >>=20 >=20 > The idea was to let the charter be flexible such that the WG can take > on data models without having to recharter. =46rom what has been OK, it this is possible, then it=92s fine. Lada > proposed, the stateless packet filter work seems to be a relatively > clear cut case. The topology work interacts with the information > model work submitted by the same authors to I2RS so it seems we need > to figure out where this work will be entertained. The other proposals > do not really seem to be mature enough to work on them at this point > in time. >=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 lhotka@nic.cz Tue Feb 4 02:19:13 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 232341A036E for ; Tue, 4 Feb 2014 02:19:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.996 X-Spam-Level: X-Spam-Status: No, score=-0.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HOST_EQ_CZ=0.904] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lhwBzdh_6eZp for ; Tue, 4 Feb 2014 02:19:11 -0800 (PST) Received: from trail.lhotka.name (nat-5.bravonet.cz [77.48.224.5]) by ietfa.amsl.com (Postfix) with ESMTP id E91381A02BC for ; Tue, 4 Feb 2014 02:19:10 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id D0149540653; Tue, 4 Feb 2014 11:19:09 +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 bsgECh9eD5m6; Tue, 4 Feb 2014 11:19:06 +0100 (CET) Received: from localhost (unknown [172.29.2.201]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id EAF69540010; Tue, 4 Feb 2014 11:19:03 +0100 (CET) From: Ladislav Lhotka To: Andy Bierman , Martin Bjorklund In-Reply-To: References: <20140202135609.GA35596@elstar.local> <20140203.222129.457630286.mbj@tail-f.com> User-Agent: Notmuch/0.17~rc2+11~g2de8ce9 (http://notmuchmail.org) Emacs/24.3.50.2 (x86_64-apple-darwin13.0.0) Date: Tue, 04 Feb 2014 11:19:02 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: "netmod@ietf.org" Subject: Re: [netmod] charter revision - please comment on charter-ietf-netmod-06-05 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2014 10:19:13 -0000 Andy Bierman writes: > On Mon, Feb 3, 2014 at 1:21 PM, Martin Bjorklund wrote: > >> Juergen Schoenwaelder wrote: >> > Hi, >> > >> > we (the WG chairs and Benoit) have been working on a new charter for >> > the NETMOD working group. The current version can always be found >> > here. >> > >> > https://datatracker.ietf.org/doc/charter-ietf-netmod/ >> > >> > The current version is called charter-ietf-netmod-06-05 >> > >> > >> https://datatracker.ietf.org/doc/charter-ietf-netmod/withmilestones-06-0= 5.txt >> > >> > Please review and feel invited to comment and ask questions. >> >> I think that in order to solve Y1 and Y3, we need an update to YANG. >> Since the proposed charter allows us to this, I guess the charter is >> ok. >> >> Regarding Y3 (YANG conformance), I don't think it is clear what >> problem we want to solve. In my experience, I have not seen the >> interoperability problems Andy's draft mentions. The draft raises >> some valid issues (e.g., hello message size explosion and if-feature >> with AND as only operator is too limiting), but I am not convinced >> that the current conformance mechanisms of YANG are not good enough. >> >> >> > I do not agree that Y3 would require an update to YANG > that would impact the yang "module" and "submodule" > constructions. None of the items in the charter proposal > are must-have features. IMO, service-oriented conformance > is better than the implied-mandatory + if-feature conformance > model we have now. > > I have never actually seen the "identityref conflict" problem that > the xpath functions need to address. Sure it is possible that > a server will have 2 modules, each with the same named > identity, each with the same base type, but I have never seen it actually > done. > > There are several known issues with YANG that actually impact usage, > and more XPath functions are fairly low on the list. We are not helping > anyone by introducing a new YANG version with 1 of 10 known bugs fixed. > Might as well fix all 10 if we bother with a YANG 1.1 release at all. > > IMO there are better things to work on, but a new YANG version just > to introduce a few XPath functions would be net harmful to interoperabili= ty I don't agree. There are other things in the 1.1 todo list but even the XPa= th functions are a good-enough reason. The main problem IMO are identities = because currently they are essentially usable only if they are flat, i.e. a= base identity and identities derived directly form it, and nothing else. For example, in a real Ethernet module that is modelled after Appendix=C2= =A0A in the interfaces I-D, the condition when "if:type =3D 'ianaift:ethernetCsmacd'"; won't work for Ethernet interfaces whose type is *derived* from ethernetCsm= acd. Combined with the limited extensibility of enumerations, this is a serious = problem. Lada > > > /martin >> >> > Andy > _______________________________________________ > 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 Tue Feb 4 03:43:13 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2E691A03F9 for ; Tue, 4 Feb 2014 03:43:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ykAH0gHpgZlT for ; Tue, 4 Feb 2014 03:43:10 -0800 (PST) Received: from mail-qa0-f42.google.com (mail-qa0-f42.google.com [209.85.216.42]) by ietfa.amsl.com (Postfix) with ESMTP id A36FB1A03F3 for ; Tue, 4 Feb 2014 03:43:10 -0800 (PST) Received: by mail-qa0-f42.google.com with SMTP id k4so12021158qaq.15 for ; Tue, 04 Feb 2014 03:43:10 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=8Z2MO5nu7MH15CCzSW7O5Eu76G9/r3Med4aMQK2E8KY=; b=DVFii7lK67eFztNn6O5X8tgNI4UQGnmY4kSfGJWiDaUAAOlXXJJcjR3i5XXamMSzD9 KUBHCF+tiZAHRKyp0vFo85sSIZLzngxWpDaGyqZq1hg9AZZTaGAzk/geck/Cwt0JPMRp Edh1KNWnSIJ+WeGVcc51Z9smC3rBabQGfQ27U8HMY5+cl7e5yUmD6T0m6xe0iA/QI2ph hp9yg80/6mIvjUNyy3plccXgbnP+f7yJ8yTOovBgSNEYy2Nn9Kgd2aaYz38VPuJKO82b fCz6icxVSGLhqBFiAUKcZDMyfqZLvTZUaWMSWcjEF8MM3UJcGXdiyIVUoLiHXOSXIXW4 iETg== X-Gm-Message-State: ALoCoQlqlG0X6sJwsp72J+nEMVuGKO3rsb5/VQlQS3G6GOEJSVxfE4+maKMd9WibKv+Wx2Zc6Zt2 MIME-Version: 1.0 X-Received: by 10.224.46.130 with SMTP id j2mr64967163qaf.7.1391514189944; Tue, 04 Feb 2014 03:43:09 -0800 (PST) Received: by 10.140.48.75 with HTTP; Tue, 4 Feb 2014 03:43:09 -0800 (PST) In-Reply-To: References: <20140202135609.GA35596@elstar.local> <20140203.222129.457630286.mbj@tail-f.com> Date: Tue, 4 Feb 2014 03:43:09 -0800 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=001a11c2a9cafdec9204f1932408 Cc: "netmod@ietf.org" Subject: Re: [netmod] charter revision - please comment on charter-ietf-netmod-06-05 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2014 11:43:14 -0000 --001a11c2a9cafdec9204f1932408 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Feb 4, 2014 at 2:19 AM, Ladislav Lhotka wrote: > Andy Bierman writes: > > > On Mon, Feb 3, 2014 at 1:21 PM, Martin Bjorklund wrote: > > > >> Juergen Schoenwaelder wrote: > >> > Hi, > >> > > >> > we (the WG chairs and Benoit) have been working on a new charter for > >> > the NETMOD working group. The current version can always be found > >> > here. > >> > > >> > https://datatracker.ietf.org/doc/charter-ietf-netmod/ > >> > > >> > The current version is called charter-ietf-netmod-06-05 > >> > > >> > > >> > https://datatracker.ietf.org/doc/charter-ietf-netmod/withmilestones-06-05.txt > >> > > >> > Please review and feel invited to comment and ask questions. > >> > >> I think that in order to solve Y1 and Y3, we need an update to YANG. > >> Since the proposed charter allows us to this, I guess the charter is > >> ok. > >> > >> Regarding Y3 (YANG conformance), I don't think it is clear what > >> problem we want to solve. In my experience, I have not seen the > >> interoperability problems Andy's draft mentions. The draft raises > >> some valid issues (e.g., hello message size explosion and if-feature > >> with AND as only operator is too limiting), but I am not convinced > >> that the current conformance mechanisms of YANG are not good enough. > >> > >> > >> > > I do not agree that Y3 would require an update to YANG > > that would impact the yang "module" and "submodule" > > constructions. None of the items in the charter proposal > > are must-have features. IMO, service-oriented conformance > > is better than the implied-mandatory + if-feature conformance > > model we have now. > > > > I have never actually seen the "identityref conflict" problem that > > the xpath functions need to address. Sure it is possible that > > a server will have 2 modules, each with the same named > > identity, each with the same base type, but I have never seen it actually > > done. > > > > There are several known issues with YANG that actually impact usage, > > and more XPath functions are fairly low on the list. We are not helping > > anyone by introducing a new YANG version with 1 of 10 known bugs fixed. > > Might as well fix all 10 if we bother with a YANG 1.1 release at all. > > > > IMO there are better things to work on, but a new YANG version just > > to introduce a few XPath functions would be net harmful to > interoperability > > I don't agree. There are other things in the 1.1 todo list but even the > XPath functions are a good-enough reason. The main problem IMO are > identities because currently they are essentially usable only if they are > flat, i.e. a base identity and identities derived directly form it, and > nothing else. > > For example, in a real Ethernet module that is modelled after Appendix A > in the interfaces I-D, the condition > > when "if:type = 'ianaift:ethernetCsmacd'"; > > won't work for Ethernet interfaces whose type is *derived* from > ethernetCsmacd. > > Combined with the limited extensibility of enumerations, this is a serious > problem. > > If it were a serious problem then we would see it showing up in real implementations. In fact, this problem has never occurred even once -- not in standard modules or vendor modules. The local names have to be for the same base. If not, the tool knows (because the leaf includes the base identity type). In theory this XPath cannot possibly work. In reality it works OK. Lada > > > > > > > /martin > >> > >> > > Andy > Andy --001a11c2a9cafdec9204f1932408 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Tue, Feb 4, 2014 at 2:19 AM, Ladislav Lhotka &= lt;lhotka@nic.cz>= wrote:
Andy Bierman <andy@yumaworks.com> writes:

> On Mon, Feb 3, 2014 at 1:21 PM, Martin Bjorklund <mbj@tail-f.com> wrote:
>
>> Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
>> > Hi,
>> >
>> > we (the WG chairs and Benoit) have been working on a new char= ter for
>> > the NETMOD working group. The current version can always be f= ound
>> > here.
>> >
>> > =A0 https://datatracker.ietf.org/doc/charter-ietf-ne= tmod/
>> >
>> > The current version is called charter-ietf-netmod-06-05
>> >
>> >
>> https://datatracker.ietf.org/doc/= charter-ietf-netmod/withmilestones-06-05.txt
>> >
>> > Please review and feel invited to comment and ask questions.<= br> >>
>> I think that in order to solve Y1 and Y3, we need an update to YAN= G.
>> Since the proposed charter allows us to this, I guess the charter = is
>> ok.
>>
>> Regarding Y3 (YANG conformance), I don't think it is clear wha= t
>> problem we want to solve. =A0In my experience, I have not seen the=
>> interoperability problems Andy's draft mentions. =A0The draft = raises
>> some valid issues (e.g., hello message size explosion and if-featu= re
>> with AND as only operator is too limiting), but I am not convinced=
>> that the current conformance mechanisms of YANG are not good enoug= h.
>>
>>
>>
> I do not agree that Y3 would require an update to YANG
> that would impact the yang "module" and "submodule"= ;
> constructions. =A0None of the items in the charter proposal
> are must-have features. =A0IMO, service-oriented conformance
> is better than the implied-mandatory + if-feature conformance
> model we have now.
>
> I have never actually seen the "identityref conflict" proble= m that
> the xpath functions need to address. Sure it is possible that
> a server will have 2 modules, each with the same named
> identity, each with the same base type, but I have never seen it actua= lly
> done.
>
> There are several known issues with YANG that actually impact usage, > and more XPath functions are fairly low on the list. =A0We are not hel= ping
> anyone by introducing a new YANG version with 1 of 10 known bugs fixed= .
> Might as well fix all 10 if we bother with a YANG 1.1 release at all.<= br> >
> IMO there are better things to work on, but a new YANG version just > to introduce a few XPath functions would be net harmful to interoperab= ility

I don't agree. There are other things in the 1.1 todo list but even the= XPath functions are a good-enough reason. The main problem IMO are identit= ies because currently they are essentially usable only if they are flat, i.= e. a base identity and identities derived directly form it, and nothing els= e.

For example, in a real Ethernet module that is modelled after Appendix=A0A = in the interfaces I-D, the condition

when "if:type =3D 'ianaift:ethernetCsmacd'";

won't work for Ethernet interfaces whose type is *derived* from etherne= tCsmacd.

Combined with the limited extensibility of enumerations, this is a serious = problem.


If it were a serious problem then we w= ould see it showing up
in real implementations. =A0In fact, this = problem has never occurred
even once -- not in standard modules o= r vendor modules.
The local names have to be for the same base. =A0If not, the tool
knows (because the leaf includes the base identity type).
In theory this XPath cannot possibly work. =A0In reality it works OK.


Lada

>
>
> /martin
>>
>>
> Andy

Andy

--001a11c2a9cafdec9204f1932408-- From andy@yumaworks.com Tue Feb 4 03:48:55 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF2331A03FA for ; Tue, 4 Feb 2014 03:48:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cV_sDvYT5Plj for ; Tue, 4 Feb 2014 03:48:53 -0800 (PST) Received: from mail-qc0-f178.google.com (mail-qc0-f178.google.com [209.85.216.178]) by ietfa.amsl.com (Postfix) with ESMTP id C90C41A03E5 for ; Tue, 4 Feb 2014 03:48:52 -0800 (PST) Received: by mail-qc0-f178.google.com with SMTP id m20so13533435qcx.9 for ; Tue, 04 Feb 2014 03:48:52 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=kaGemH4nbl8TCK6G7YjtLrKIpmh6y/bCKvVMb8CY7BY=; b=CnfpyGBgLQa527rEympw710UcmsptUOZt12G6MpmVh6CTWEgxHzVrdRVwTK36dFjBu 0mcbYleYmfqSxMeFGv53SROq5HWNbjsnjlV0r6po6Lz5ocULGjV5aoM1TEDG5nogc0J7 ZkTfRMfVlyTMGW3pEHww6qjefESlfnbDOfnNweSLJOdGPfSfV9hKz6IlNlGUO6SXyHqg vK66j2Op6XYIKWEC0nGh6ugZCuG+Zg1lmlIrxXx+qbkAOi/0pe+K7BPSWl0kRTYSLKYr oqVPWDBsdYXHVM3tY41Yxm9m3NUNHQsDbIwUEn0+oU62N/8ZN9lL0tkoe/YcSavSG706 00xQ== X-Gm-Message-State: ALoCoQnSeozdzCc1TJH2sqruAjR3txvL5f6MX6pYStSC1qWCam1ci51KPXe513wZr1tt3/FCXfsb MIME-Version: 1.0 X-Received: by 10.140.27.179 with SMTP id 48mr60792540qgx.18.1391514532349; Tue, 04 Feb 2014 03:48:52 -0800 (PST) Received: by 10.140.48.75 with HTTP; Tue, 4 Feb 2014 03:48:52 -0800 (PST) In-Reply-To: <20140204.101921.724083919961589738.mbj@tail-f.com> References: <20140203.232610.166683380.mbj@tail-f.com> <20140204.101921.724083919961589738.mbj@tail-f.com> Date: Tue, 4 Feb 2014 03:48:52 -0800 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: multipart/alternative; boundary=001a11c004346698ec04f1933959 Cc: "netmod@ietf.org" Subject: Re: [netmod] charter revision - please comment on charter-ietf-netmod-06-05 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2014 11:48:56 -0000 --001a11c004346698ec04f1933959 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Feb 4, 2014 at 1:19 AM, Martin Bjorklund wrote: > Andy Bierman wrote: > > On Mon, Feb 3, 2014 at 2:26 PM, Martin Bjorklund wrote: > > > > > Andy Bierman wrote: > > > > On Mon, Feb 3, 2014 at 1:52 PM, Martin Bjorklund > wrote: > > > > > > > > > Andy Bierman wrote: > > > > > > On Mon, Feb 3, 2014 at 1:21 PM, Martin Bjorklund > > > > wrote: > > > > > > > > > > > > > Juergen Schoenwaelder > > > wrote: > > > > > > > > Hi, > > > > > > > > > > > > > > > > we (the WG chairs and Benoit) have been working on a new > charter > > > for > > > > > > > > the NETMOD working group. The current version can always be > found > > > > > > > > here. > > > > > > > > > > > > > > > > https://datatracker.ietf.org/doc/charter-ietf-netmod/ > > > > > > > > > > > > > > > > The current version is called charter-ietf-netmod-06-05 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://datatracker.ietf.org/doc/charter-ietf-netmod/withmilestones-06-05.txt > > > > > > > > > > > > > > > > Please review and feel invited to comment and ask questions. > > > > > > > > > > > > > > I think that in order to solve Y1 and Y3, we need an update to > > > YANG. > > > > > > > Since the proposed charter allows us to this, I guess the > charter > > > is > > > > > > > ok. > > > > > > > > > > > > > > Regarding Y3 (YANG conformance), I don't think it is clear what > > > > > > > problem we want to solve. In my experience, I have not seen > the > > > > > > > interoperability problems Andy's draft mentions. The draft > raises > > > > > > > some valid issues (e.g., hello message size explosion and > > > if-feature > > > > > > > with AND as only operator is too limiting), but I am not > convinced > > > > > > > that the current conformance mechanisms of YANG are not good > > > enough. > > > > > > > > > > > > > > > > > > > > > > > > > > > I do not agree that Y3 would require an update to YANG > > > > > > that would impact the yang "module" and "submodule" > > > > > > constructions. > > > > > > > > > > RFC 6020 says that a server MUST advertise the module namespace > URI to > > > > > indicate support for a module. I think your draft says that > instead > > > > > of doing that, the server can advertise a package. This changes > RFC > > > > > 6020 (yes, it does not change YANG syntax, but it sure impacts > > > > > existing clients). > > > > > > > > > > > > > No -- I was wrong about that. > > > > I think that text was in a slide at the IETF but not in the draft. > > > > There is no text that says the server does not send module URIs. > > > > > > Ok. Then I agree an update to YANG is not necessary. But then it > > > also doesn't solve the hello message size problem... :( > > > > > > > > Unless the client message has some indication > > that the client knows YANG 1.1 then the server cannot send > > the abbreviated (in the NETCONF-EX draft). > > That's what I was saying - if we want to change what's advertised, we > need to update 6020. > > If a prerequisite is that we don't update 6020, I don't think we can > much about the problems listed in your draft. > > Even if we update RFC 6020, the server has to be sure the client supports the update before sending a new . The problem of the server delaying its to wait for the client does not go away no matter what happens wit YANG 1.1. > > > > But... if all 6020-compliant module capabilities are advertised, what > > > information in the package can the client use that is not in the > > > normal module advertisment (and doesn't break 6020 rules)? > > > > > > > Some basic stuff like import-only vs. conformance. > > I think it must be clear from the YANG spec what it means to advertise > a module. If this is not clear we need to fix that in the spec. > It is clear now -- clearly broken. If a module has a container and a typedef then if the server uses the typedef it also is telling the client it implements the container. The YANG export model needs to be more flexible than that. > > > Some fancy stuff like multi-module service profiles. > > IMO we will already these features if you count all > > the vendor modules. > > > > We could do the work in phases: > > > > phase 1) address the real deficiencies with the current conformance > > phase 2) develop reusable service level conformance abstraction > mechanisms > > I think this makes sense. > > > /martin > > Andy --001a11c004346698ec04f1933959 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Tue, Feb 4, 2014 at 1:19 AM, Martin Bjorklund = <mbj@tail-f.com&= gt; wrote:
Andy Bierman <andy@yumaworks.com> wrote:
> On Mon, Feb 3, 2014 at 2:26 PM, Martin Bjorklund <mbj@tail-f.com> wrote:
>
> > Andy Bierman <andy@yumaw= orks.com> wrote:
> > > On Mon, Feb 3, 2014 at 1:52 PM, Martin Bjorklund <mbj@tail-f.com> wrote:
> > >
> > > > Andy Bierman <= andy@yumaworks.com> wrote:
> > > > > On Mon, Feb 3, 2014 at 1:21 PM, Martin Bjorklund &= lt;mbj@tail-f.com>
> > wrote:
> > > > >
> > > > > > Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
> > wrote:
> > > > > > > Hi,
> > > > > > >
> > > > > > > we (the WG chairs and Benoit) have been = working on a new charter
> > for
> > > > > > > the NETMOD working group. The current ve= rsion can always be found
> > > > > > > here.
> > > > > > >
> > > > > > > =A0 https://datatracker.ietf.or= g/doc/charter-ietf-netmod/
> > > > > > >
> > > > > > > The current version is called charter-ie= tf-netmod-06-05
> > > > > > >
> > > > > > >
> > > > > >
> > > >
> > https://datatracker.ietf.org/doc= /charter-ietf-netmod/withmilestones-06-05.txt
> > > > > > >
> > > > > > > Please review and feel invited to commen= t and ask questions.
> > > > > >
> > > > > > I think that in order to solve Y1 and Y3, we = need an update to
> > YANG.
> > > > > > Since the proposed charter allows us to this,= I guess the charter
> > is
> > > > > > ok.
> > > > > >
> > > > > > Regarding Y3 (YANG conformance), I don't = think it is clear what
> > > > > > problem we want to solve. =A0In my experience= , I have not seen the
> > > > > > interoperability problems Andy's draft me= ntions. =A0The draft raises
> > > > > > some valid issues (e.g., hello message size e= xplosion and
> > if-feature
> > > > > > with AND as only operator is too limiting), b= ut I am not convinced
> > > > > > that the current conformance mechanisms of YA= NG are not good
> > enough.
> > > > > >
> > > > > >
> > > > > >
> > > > > I do not agree that Y3 would require an update to = YANG
> > > > > that would impact the yang "module" and = "submodule"
> > > > > constructions.
> > > >
> > > > RFC 6020 says that a server MUST advertise the module n= amespace URI to
> > > > indicate support for a module. =A0I think your draft sa= ys that instead
> > > > of doing that, the server can advertise a package. =A0T= his changes RFC
> > > > 6020 (yes, it does not change YANG syntax, but it sure = impacts
> > > > existing clients).
> > > >
> > >
> > > No -- I was wrong about that.
> > > I think that text was in a slide at the IETF but not in the = draft.
> > > There is no text that says the server does not send module U= RIs.
> >
> > Ok. =A0Then I agree an update to YANG is not necessary. =A0But th= en it
> > also doesn't solve the hello message size problem... :(
> >
> >
> Unless the client <hello> message has some indication
> that the client knows YANG 1.1 then the server cannot send
> the abbreviated <hello> (in the NETCONF-EX draft).

That's what I was saying - if we want to change what's advertised, = we
need to update 6020.

If a prerequisite is that we don't update 6020, I don't think we ca= n
much about the problems listed in your draft.


Even if we update RFC 6020, the server= has to be sure the client
supports the update before sending a n= ew <hello>. =A0The problem
of the server delaying its <h= ello> to wait for the client does not
go away no matter what happens wit YANG 1.1.

= =A0

> > But... if all 6020-compliant module capabilities are advertised, = what
> > information in the package can the client use that is not in the<= br> > > normal module advertisment (and doesn't break 6020 rules)? > >
>
> Some basic stuff like import-only vs. conformance.

I think it must be clear from the YANG spec what it means to advertise
a module. =A0If this is not clear we need to fix that in the spec.

It is clear now -- clearly broken.
If= a module has a container and a typedef then if the server uses
the typedef it also is telling the client it implements the container.
The YANG export model needs to be more flexible than that.
= =A0

> Some fancy stuff like multi-module service profiles.
> IMO we will already these features if you count all
> the vendor modules.
>
> We could do the work in phases:
>
> phase 1) address the real deficiencies with the current conformance > phase 2) develop reusable service level conformance abstraction mechan= isms

I think this makes sense.


/martin


Andy<= /div>

--001a11c004346698ec04f1933959-- From mbj@tail-f.com Tue Feb 4 03:57:41 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02DA51A03F9 for ; Tue, 4 Feb 2014 03:57:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.436 X-Spam-Level: X-Spam-Status: No, score=-2.436 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i9CSUSi5wpJu for ; Tue, 4 Feb 2014 03:57:39 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id B2C181A0383 for ; Tue, 4 Feb 2014 03:57:38 -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 ED87A37C1A7; Tue, 4 Feb 2014 12:57:37 +0100 (CET) Date: Tue, 04 Feb 2014 12:57:37 +0100 (CET) Message-Id: <20140204.125737.535621476101042563.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: <20140204.101921.724083919961589738.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] charter revision - please comment on charter-ietf-netmod-06-05 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2014 11:57:41 -0000 Andy Bierman wrote: > On Tue, Feb 4, 2014 at 1:19 AM, Martin Bjorklund wrote: > > > Andy Bierman wrote: > > > On Mon, Feb 3, 2014 at 2:26 PM, Martin Bjorklund wrote: > > > > > > > Andy Bierman wrote: > > > > > On Mon, Feb 3, 2014 at 1:52 PM, Martin Bjorklund > > wrote: > > > > > > > > > > > Andy Bierman wrote: > > > > > > > On Mon, Feb 3, 2014 at 1:21 PM, Martin Bjorklund > > > > > > wrote: > > > > > > > > > > > > > > > Juergen Schoenwaelder > > > > wrote: > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > we (the WG chairs and Benoit) have been working on a new > > charter > > > > for > > > > > > > > > the NETMOD working group. The current version can always be > > found > > > > > > > > > here. > > > > > > > > > > > > > > > > > > https://datatracker.ietf.org/doc/charter-ietf-netmod/ > > > > > > > > > > > > > > > > > > The current version is called charter-ietf-netmod-06-05 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://datatracker.ietf.org/doc/charter-ietf-netmod/withmilestones-06-05.txt > > > > > > > > > > > > > > > > > > Please review and feel invited to comment and ask questions. > > > > > > > > > > > > > > > > I think that in order to solve Y1 and Y3, we need an update to > > > > YANG. > > > > > > > > Since the proposed charter allows us to this, I guess the > > charter > > > > is > > > > > > > > ok. > > > > > > > > > > > > > > > > Regarding Y3 (YANG conformance), I don't think it is clear what > > > > > > > > problem we want to solve. In my experience, I have not seen > > the > > > > > > > > interoperability problems Andy's draft mentions. The draft > > raises > > > > > > > > some valid issues (e.g., hello message size explosion and > > > > if-feature > > > > > > > > with AND as only operator is too limiting), but I am not > > convinced > > > > > > > > that the current conformance mechanisms of YANG are not good > > > > enough. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I do not agree that Y3 would require an update to YANG > > > > > > > that would impact the yang "module" and "submodule" > > > > > > > constructions. > > > > > > > > > > > > RFC 6020 says that a server MUST advertise the module namespace > > URI to > > > > > > indicate support for a module. I think your draft says that > > instead > > > > > > of doing that, the server can advertise a package. This changes > > RFC > > > > > > 6020 (yes, it does not change YANG syntax, but it sure impacts > > > > > > existing clients). > > > > > > > > > > > > > > > > No -- I was wrong about that. > > > > > I think that text was in a slide at the IETF but not in the draft. > > > > > There is no text that says the server does not send module URIs. > > > > > > > > Ok. Then I agree an update to YANG is not necessary. But then it > > > > also doesn't solve the hello message size problem... :( > > > > > > > > > > > Unless the client message has some indication > > > that the client knows YANG 1.1 then the server cannot send > > > the abbreviated (in the NETCONF-EX draft). > > > > That's what I was saying - if we want to change what's advertised, we > > need to update 6020. > > > > If a prerequisite is that we don't update 6020, I don't think we can > > much about the problems listed in your draft. > > > > > Even if we update RFC 6020, the server has to be sure the client > supports the update before sending a new . The problem > of the server delaying its to wait for the client does not > go away no matter what happens wit YANG 1.1. There might be other solutions to the compressed hello message than the one presented in the netconf ex draft. For example, the server could advertise a package, and then the package contains all modules. But this requires a change to 6020, which was my original point. > > > > But... if all 6020-compliant module capabilities are advertised, what > > > > information in the package can the client use that is not in the > > > > normal module advertisment (and doesn't break 6020 rules)? > > > > > > > > > > Some basic stuff like import-only vs. conformance. > > > > I think it must be clear from the YANG spec what it means to advertise > > a module. If this is not clear we need to fix that in the spec. > > > > It is clear now -- clearly broken. > If a module has a container and a typedef then if the server uses > the typedef it also is telling the client it implements the container. > The YANG export model needs to be more flexible than that. So you agree that the conformance draft does not help here - we need to fix 6020? /martin From mbj@tail-f.com Tue Feb 4 04:08:24 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C0121A0383 for ; Tue, 4 Feb 2014 04:08:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.436 X-Spam-Level: X-Spam-Status: No, score=-2.436 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CTNo7MrTK937 for ; Tue, 4 Feb 2014 04:08:22 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id 8ED951A01D7 for ; Tue, 4 Feb 2014 04:08:21 -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 C3F2337C1A7; Tue, 4 Feb 2014 13:08:20 +0100 (CET) Date: Tue, 04 Feb 2014 13:08:20 +0100 (CET) Message-Id: <20140204.130820.1735864434118354655.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] charter revision - please comment on charter-ietf-netmod-06-05 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2014 12:08:24 -0000 Andy Bierman wrote: > On Tue, Feb 4, 2014 at 2:19 AM, Ladislav Lhotka wrote: > > > Andy Bierman writes: > > > > > On Mon, Feb 3, 2014 at 1:21 PM, Martin Bjorklund wrote: > > > > > >> Juergen Schoenwaelder wrote: > > >> > Hi, > > >> > > > >> > we (the WG chairs and Benoit) have been working on a new charter for > > >> > the NETMOD working group. The current version can always be found > > >> > here. > > >> > > > >> > https://datatracker.ietf.org/doc/charter-ietf-netmod/ > > >> > > > >> > The current version is called charter-ietf-netmod-06-05 > > >> > > > >> > > > >> > > https://datatracker.ietf.org/doc/charter-ietf-netmod/withmilestones-06-05.txt > > >> > > > >> > Please review and feel invited to comment and ask questions. > > >> > > >> I think that in order to solve Y1 and Y3, we need an update to YANG. > > >> Since the proposed charter allows us to this, I guess the charter is > > >> ok. > > >> > > >> Regarding Y3 (YANG conformance), I don't think it is clear what > > >> problem we want to solve. In my experience, I have not seen the > > >> interoperability problems Andy's draft mentions. The draft raises > > >> some valid issues (e.g., hello message size explosion and if-feature > > >> with AND as only operator is too limiting), but I am not convinced > > >> that the current conformance mechanisms of YANG are not good enough. > > >> > > >> > > >> > > > I do not agree that Y3 would require an update to YANG > > > that would impact the yang "module" and "submodule" > > > constructions. None of the items in the charter proposal > > > are must-have features. IMO, service-oriented conformance > > > is better than the implied-mandatory + if-feature conformance > > > model we have now. > > > > > > I have never actually seen the "identityref conflict" problem that > > > the xpath functions need to address. Sure it is possible that > > > a server will have 2 modules, each with the same named > > > identity, each with the same base type, but I have never seen it actually > > > done. > > > > > > There are several known issues with YANG that actually impact usage, > > > and more XPath functions are fairly low on the list. We are not helping > > > anyone by introducing a new YANG version with 1 of 10 known bugs fixed. > > > Might as well fix all 10 if we bother with a YANG 1.1 release at all. > > > > > > IMO there are better things to work on, but a new YANG version just > > > to introduce a few XPath functions would be net harmful to > > interoperability > > > > I don't agree. There are other things in the 1.1 todo list but even the > > XPath functions are a good-enough reason. The main problem IMO are > > identities because currently they are essentially usable only if they are > > flat, i.e. a base identity and identities derived directly form it, and > > nothing else. > > > > For example, in a real Ethernet module that is modelled after Appendix A > > in the interfaces I-D, the condition > > > > when "if:type = 'ianaift:ethernetCsmacd'"; > > > > won't work for Ethernet interfaces whose type is *derived* from > > ethernetCsmacd. > > > > Combined with the limited extensibility of enumerations, this is a serious > > problem. > > > > > If it were a serious problem then we would see it showing up > in real implementations. In fact, this problem has never occurred > even once -- not in standard modules or vendor modules. This is weird logic. Of course there are no modules that tries to do a "derived-from" when expression, since there is no such thing as a "derived-from" when expression. The fact is that we now have a module for interfaces where the interface type is an identity. The next step is to define interface-type-specific modules, probably vendor-defined first. In this design proccess, we have run into the problem of not having a "derived from" function, as Lada has explained. Noone has claimed this problem to be something else than this. Call it a theoretical problem if you like. The question is if the WG thinks it is important enough to work on a solution. /martin From andy@yumaworks.com Tue Feb 4 04:16:55 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09A2C1A02B9 for ; Tue, 4 Feb 2014 04:16:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ELm2C8cHXMq7 for ; Tue, 4 Feb 2014 04:16:51 -0800 (PST) Received: from mail-qa0-f53.google.com (mail-qa0-f53.google.com [209.85.216.53]) by ietfa.amsl.com (Postfix) with ESMTP id 77E601A03A5 for ; Tue, 4 Feb 2014 04:16:51 -0800 (PST) Received: by mail-qa0-f53.google.com with SMTP id cm18so11854029qab.40 for ; Tue, 04 Feb 2014 04:16:51 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=NxnIRO9WdnOJy9kS/Sp/VHaQ2Y56del8wqbCLS0CSuY=; b=cOn7YQKdYGaqaObcyAyUvOPwBwavNf3DIHnjlfGrMo/fOebY8FivMyG8D31+VRsU61 2oXnKwX1gUBekAHOvZPcGdnq3jVtl+CbyO8sM51qRdKHWHJPtP2UK5vVDayHswQDrTL5 eKUfMiZmnfeQXTHYPytPFPW283V/HoDTr3/0HaM+BgHhJbnbBfkb7D1y8gHpPsik1twT OV0542gDMvSAkO1jVlpfI3JgxzEv6S9wzGX+TR1a73U1d3vZ2Nlk6RRebFd1GVBHTXao Ze51TUlBcAni0H206FE2WTjXLYJFm7WvxJjIZZ9iuy+qmoo3g6/43w5EXxVP9a8Q4/jU yB/w== X-Gm-Message-State: ALoCoQkdylpoU5fU88Frt0oz/OmtOQVSOU1/9hb4zPh1m/gsLi1D+O8pjGRsprxq+HJdpALNy88d MIME-Version: 1.0 X-Received: by 10.140.27.179 with SMTP id 48mr61011979qgx.18.1391516210999; Tue, 04 Feb 2014 04:16:50 -0800 (PST) Received: by 10.140.48.75 with HTTP; Tue, 4 Feb 2014 04:16:50 -0800 (PST) In-Reply-To: <20140204.125737.535621476101042563.mbj@tail-f.com> References: <20140204.101921.724083919961589738.mbj@tail-f.com> <20140204.125737.535621476101042563.mbj@tail-f.com> Date: Tue, 4 Feb 2014 04:16:50 -0800 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: multipart/alternative; boundary=001a11c0043474bc3d04f1939d58 Cc: "netmod@ietf.org" Subject: Re: [netmod] charter revision - please comment on charter-ietf-netmod-06-05 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2014 12:16:55 -0000 --001a11c0043474bc3d04f1939d58 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Feb 4, 2014 at 3:57 AM, Martin Bjorklund wrote: > Andy Bierman wrote: > > On Tue, Feb 4, 2014 at 1:19 AM, Martin Bjorklund wrote: > > > > > Andy Bierman wrote: > > > > On Mon, Feb 3, 2014 at 2:26 PM, Martin Bjorklund > wrote: > > > > > > > > > Andy Bierman wrote: > > > > > > On Mon, Feb 3, 2014 at 1:52 PM, Martin Bjorklund > > > > wrote: > > > > > > > > > > > > > Andy Bierman wrote: > > > > > > > > On Mon, Feb 3, 2014 at 1:21 PM, Martin Bjorklund < > mbj@tail-f.com > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > Juergen Schoenwaelder < > j.schoenwaelder@jacobs-university.de> > > > > > wrote: > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > > we (the WG chairs and Benoit) have been working on a new > > > charter > > > > > for > > > > > > > > > > the NETMOD working group. The current version can always > be > > > found > > > > > > > > > > here. > > > > > > > > > > > > > > > > > > > > https://datatracker.ietf.org/doc/charter-ietf-netmod/ > > > > > > > > > > > > > > > > > > > > The current version is called charter-ietf-netmod-06-05 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://datatracker.ietf.org/doc/charter-ietf-netmod/withmilestones-06-05.txt > > > > > > > > > > > > > > > > > > > > Please review and feel invited to comment and ask > questions. > > > > > > > > > > > > > > > > > > I think that in order to solve Y1 and Y3, we need an > update to > > > > > YANG. > > > > > > > > > Since the proposed charter allows us to this, I guess the > > > charter > > > > > is > > > > > > > > > ok. > > > > > > > > > > > > > > > > > > Regarding Y3 (YANG conformance), I don't think it is clear > what > > > > > > > > > problem we want to solve. In my experience, I have not > seen > > > the > > > > > > > > > interoperability problems Andy's draft mentions. The draft > > > raises > > > > > > > > > some valid issues (e.g., hello message size explosion and > > > > > if-feature > > > > > > > > > with AND as only operator is too limiting), but I am not > > > convinced > > > > > > > > > that the current conformance mechanisms of YANG are not > good > > > > > enough. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I do not agree that Y3 would require an update to YANG > > > > > > > > that would impact the yang "module" and "submodule" > > > > > > > > constructions. > > > > > > > > > > > > > > RFC 6020 says that a server MUST advertise the module namespace > > > URI to > > > > > > > indicate support for a module. I think your draft says that > > > instead > > > > > > > of doing that, the server can advertise a package. This > changes > > > RFC > > > > > > > 6020 (yes, it does not change YANG syntax, but it sure impacts > > > > > > > existing clients). > > > > > > > > > > > > > > > > > > > No -- I was wrong about that. > > > > > > I think that text was in a slide at the IETF but not in the > draft. > > > > > > There is no text that says the server does not send module URIs. > > > > > > > > > > Ok. Then I agree an update to YANG is not necessary. But then it > > > > > also doesn't solve the hello message size problem... :( > > > > > > > > > > > > > > Unless the client message has some indication > > > > that the client knows YANG 1.1 then the server cannot send > > > > the abbreviated (in the NETCONF-EX draft). > > > > > > That's what I was saying - if we want to change what's advertised, we > > > need to update 6020. > > > > > > If a prerequisite is that we don't update 6020, I don't think we can > > > much about the problems listed in your draft. > > > > > > > > Even if we update RFC 6020, the server has to be sure the client > > supports the update before sending a new . The problem > > of the server delaying its to wait for the client does not > > go away no matter what happens wit YANG 1.1. > > There might be other solutions to the compressed hello message than > the one presented in the netconf ex draft. For example, the server > could advertise a package, and then the package contains all > modules. But this requires a change to 6020, which was my original > point. > > > > > > But... if all 6020-compliant module capabilities are advertised, > what > > > > > information in the package can the client use that is not in the > > > > > normal module advertisment (and doesn't break 6020 rules)? > > > > > > > > > > > > > Some basic stuff like import-only vs. conformance. > > > > > > I think it must be clear from the YANG spec what it means to advertise > > > a module. If this is not clear we need to fix that in the spec. > > > > > > > It is clear now -- clearly broken. > > If a module has a container and a typedef then if the server uses > > the typedef it also is telling the client it implements the container. > > The YANG export model needs to be more flexible than that. > > So you agree that the conformance draft does not help here - we need > to fix 6020? > > No -- we could add data to the ietf-netconf-monitoring module to help clients clarify the module usage within the server. > > /martin > Andy --001a11c0043474bc3d04f1939d58 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Tue, Feb 4, 2014 at 3:57 AM, Martin Bjorklund = <mbj@tail-f.com&= gt; wrote:
Andy Bierman <andy@yumaworks.com> wrote:
> On Tue, Feb 4, 2014 at 1:19 AM, Martin Bjorklund <mbj@tail-f.com> wrote:
>
> > Andy Bierman <andy@yumaw= orks.com> wrote:
> > > On Mon, Feb 3, 2014 at 2:26 PM, Martin Bjorklund <mbj@tail-f.com> wrote:
> > >
> > > > Andy Bierman <= andy@yumaworks.com> wrote:
> > > > > On Mon, Feb 3, 2014 at 1:52 PM, Martin Bjorklund &= lt;mbj@tail-f.com>
> > wrote:
> > > > >
> > > > > > Andy Bierman <andy@yumaworks.com> wrote:
> > > > > > > On Mon, Feb 3, 2014 at 1:21 PM, Martin B= jorklund <mbj@tail-f.com
> > >
> > > > wrote:
> > > > > > >
> > > > > > > > Juergen Schoenwaelder <j.schoenwaelder@jacobs-uni= versity.de>
> > > > wrote:
> > > > > > > > > Hi,
> > > > > > > > >
> > > > > > > > > we (the WG chairs and Benoit) = have been working on a new
> > charter
> > > > for
> > > > > > > > > the NETMOD working group. The = current version can always be
> > found
> > > > > > > > > here.
> > > > > > > > >
> > > > > > > > > =A0 https://datatrack= er.ietf.org/doc/charter-ietf-netmod/
> > > > > > > > >
> > > > > > > > > The current version is called = charter-ietf-netmod-06-05
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > >
> > > >
> > https://datatracker.ietf.org/doc= /charter-ietf-netmod/withmilestones-06-05.txt
> > > > > > > > >
> > > > > > > > > Please review and feel invited= to comment and ask questions.
> > > > > > > >
> > > > > > > > I think that in order to solve Y1 a= nd Y3, we need an update to
> > > > YANG.
> > > > > > > > Since the proposed charter allows u= s to this, I guess the
> > charter
> > > > is
> > > > > > > > ok.
> > > > > > > >
> > > > > > > > Regarding Y3 (YANG conformance), I = don't think it is clear what
> > > > > > > > problem we want to solve. =A0In my = experience, I have not seen
> > the
> > > > > > > > interoperability problems Andy'= s draft mentions. =A0The draft
> > raises
> > > > > > > > some valid issues (e.g., hello mess= age size explosion and
> > > > if-feature
> > > > > > > > with AND as only operator is too li= miting), but I am not
> > convinced
> > > > > > > > that the current conformance mechan= isms of YANG are not good
> > > > enough.
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > I do not agree that Y3 would require an = update to YANG
> > > > > > > that would impact the yang "module&= quot; and "submodule"
> > > > > > > constructions.
> > > > > >
> > > > > > RFC 6020 says that a server MUST advertise th= e module namespace
> > URI to
> > > > > > indicate support for a module. =A0I think you= r draft says that
> > instead
> > > > > > of doing that, the server can advertise a pac= kage. =A0This changes
> > RFC
> > > > > > 6020 (yes, it does not change YANG syntax, bu= t it sure impacts
> > > > > > existing clients).
> > > > > >
> > > > >
> > > > > No -- I was wrong about that.
> > > > > I think that text was in a slide at the IETF but n= ot in the draft.
> > > > > There is no text that says the server does not sen= d module URIs.
> > > >
> > > > Ok. =A0Then I agree an update to YANG is not necessary.= =A0But then it
> > > > also doesn't solve the hello message size problem..= . :(
> > > >
> > > >
> > > Unless the client <hello> message has some indication<= br> > > > that the client knows YANG 1.1 then the server cannot send > > > the abbreviated <hello> (in the NETCONF-EX draft).
> >
> > That's what I was saying - if we want to change what's ad= vertised, we
> > need to update 6020.
> >
> > If a prerequisite is that we don't update 6020, I don't t= hink we can
> > much about the problems listed in your draft.
> >
> >
> Even if we update RFC 6020, the server has to be sure the client
> supports the update before sending a new <hello>. =A0The problem=
> of the server delaying its <hello> to wait for the client does n= ot
> go away no matter what happens wit YANG 1.1.

There might be other solutions to the compressed hello message than
the one presented in the netconf ex draft. =A0For example, the server
could advertise a package, and then the package contains all
modules. =A0But this requires a change to 6020, which was my original
point.

> > > > But... if all 6020-compliant module capabilities are ad= vertised, what
> > > > information in the package can the client use that is n= ot in the
> > > > normal module advertisment (and doesn't break 6020 = rules)?
> > > >
> > >
> > > Some basic stuff like import-only vs. conformance.
> >
> > I think it must be clear from the YANG spec what it means to adve= rtise
> > a module. =A0If this is not clear we need to fix that in the spec= .
> >
>
> It is clear now -- clearly broken.
> If a module has a container and a typedef then if the server uses
> the typedef it also is telling the client it implements the container.=
> The YANG export model needs to be more flexible than that.

So you agree that the conformance draft does not help here - we need
to fix 6020?


No -- we could add data to the ietf-netconf-monitori= ng module to help
clients clarify the module usage within the ser= ver.=A0
=A0

/martin

Andy<= /div>

--001a11c0043474bc3d04f1939d58-- From andy@yumaworks.com Tue Feb 4 04:22:22 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A9031A03A5 for ; Tue, 4 Feb 2014 04:22:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vHOh5uKaHtv3 for ; Tue, 4 Feb 2014 04:22:16 -0800 (PST) Received: from mail-qc0-f176.google.com (mail-qc0-f176.google.com [209.85.216.176]) by ietfa.amsl.com (Postfix) with ESMTP id 01A011A0383 for ; Tue, 4 Feb 2014 04:22:15 -0800 (PST) Received: by mail-qc0-f176.google.com with SMTP id e16so13399690qcx.35 for ; Tue, 04 Feb 2014 04:22:15 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=JC+WmafhOQj5RxNo4pmYdsA/BtIeTHJWHp7Jybjvvuw=; b=QCqoZoPbnYqqS2QUPjoaz6QT++xkl/BXQiKVWZUtg0YFobHRka9rjeOjKy9Bmjm8tC X4BDujDkmX/3C6qh+loiJIzNFrp3I7FjLdFwuVHfflMIoZCXtUotmk3LqJDgKbHpLQ+R eXZFxERBDgaJyeTLHBAI+1Ya2KpyQgZP+3Mm72TT8RwQmeckqd9Ge+y4YD9yagtNYuQf uX/8j405ks7fa0VHGLAun2PwqifGj4Slocwv7d5H5ezP5yz1UWI+T2fkIX+I/b6BNzin 4+VqImi2aoMeJ8D6DiMntQWAaWck8cV5Zsi0CLwvheEP84A8hVG2/0njsIuVd19WN4/o kSkg== X-Gm-Message-State: ALoCoQltq5BFg6+obiQBc3mKT8IhZqfWjOTFbNfqh93vW6ZP52Tn2I1SHobBcbXyFnn5Y3annlFd MIME-Version: 1.0 X-Received: by 10.224.136.10 with SMTP id p10mr65654503qat.16.1391516535449; Tue, 04 Feb 2014 04:22:15 -0800 (PST) Received: by 10.140.48.75 with HTTP; Tue, 4 Feb 2014 04:22:15 -0800 (PST) In-Reply-To: <20140204.130820.1735864434118354655.mbj@tail-f.com> References: <20140204.130820.1735864434118354655.mbj@tail-f.com> Date: Tue, 4 Feb 2014 04:22:15 -0800 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: multipart/alternative; boundary=001a11c2a8b0cb7a7004f193b009 Cc: "netmod@ietf.org" Subject: Re: [netmod] charter revision - please comment on charter-ietf-netmod-06-05 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2014 12:22:22 -0000 --001a11c2a8b0cb7a7004f193b009 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Feb 4, 2014 at 4:08 AM, Martin Bjorklund wrote: > Andy Bierman wrote: > > On Tue, Feb 4, 2014 at 2:19 AM, Ladislav Lhotka wrote: > > > > > Andy Bierman writes: > > > > > > > On Mon, Feb 3, 2014 at 1:21 PM, Martin Bjorklund > wrote: > > > > > > > >> Juergen Schoenwaelder wrote: > > > >> > Hi, > > > >> > > > > >> > we (the WG chairs and Benoit) have been working on a new charter > for > > > >> > the NETMOD working group. The current version can always be found > > > >> > here. > > > >> > > > > >> > https://datatracker.ietf.org/doc/charter-ietf-netmod/ > > > >> > > > > >> > The current version is called charter-ietf-netmod-06-05 > > > >> > > > > >> > > > > >> > > > > https://datatracker.ietf.org/doc/charter-ietf-netmod/withmilestones-06-05.txt > > > >> > > > > >> > Please review and feel invited to comment and ask questions. > > > >> > > > >> I think that in order to solve Y1 and Y3, we need an update to YANG. > > > >> Since the proposed charter allows us to this, I guess the charter is > > > >> ok. > > > >> > > > >> Regarding Y3 (YANG conformance), I don't think it is clear what > > > >> problem we want to solve. In my experience, I have not seen the > > > >> interoperability problems Andy's draft mentions. The draft raises > > > >> some valid issues (e.g., hello message size explosion and if-feature > > > >> with AND as only operator is too limiting), but I am not convinced > > > >> that the current conformance mechanisms of YANG are not good enough. > > > >> > > > >> > > > >> > > > > I do not agree that Y3 would require an update to YANG > > > > that would impact the yang "module" and "submodule" > > > > constructions. None of the items in the charter proposal > > > > are must-have features. IMO, service-oriented conformance > > > > is better than the implied-mandatory + if-feature conformance > > > > model we have now. > > > > > > > > I have never actually seen the "identityref conflict" problem that > > > > the xpath functions need to address. Sure it is possible that > > > > a server will have 2 modules, each with the same named > > > > identity, each with the same base type, but I have never seen it > actually > > > > done. > > > > > > > > There are several known issues with YANG that actually impact usage, > > > > and more XPath functions are fairly low on the list. We are not > helping > > > > anyone by introducing a new YANG version with 1 of 10 known bugs > fixed. > > > > Might as well fix all 10 if we bother with a YANG 1.1 release at all. > > > > > > > > IMO there are better things to work on, but a new YANG version just > > > > to introduce a few XPath functions would be net harmful to > > > interoperability > > > > > > I don't agree. There are other things in the 1.1 todo list but even the > > > XPath functions are a good-enough reason. The main problem IMO are > > > identities because currently they are essentially usable only if they > are > > > flat, i.e. a base identity and identities derived directly form it, and > > > nothing else. > > > > > > For example, in a real Ethernet module that is modelled after Appendix > A > > > in the interfaces I-D, the condition > > > > > > when "if:type = 'ianaift:ethernetCsmacd'"; > > > > > > won't work for Ethernet interfaces whose type is *derived* from > > > ethernetCsmacd. > > > > > > Combined with the limited extensibility of enumerations, this is a > serious > > > problem. > > > > > > > > If it were a serious problem then we would see it showing up > > in real implementations. In fact, this problem has never occurred > > even once -- not in standard modules or vendor modules. > > This is weird logic. Of course there are no modules that tries to do > a "derived-from" when expression, since there is no such thing as a > "derived-from" when expression. > > The fact is that we now have a module for interfaces where the > interface type is an identity. The next step is to define > interface-type-specific modules, probably vendor-defined first. In > this design proccess, we have run into the problem of not having a > "derived from" function, as Lada has explained. > > Noone has claimed this problem to be something else than this. Call > it a theoretical problem if you like. The question is if the WG > thinks it is important enough to work on a solution. > > > The need to specify the qualified name instead of just the local name is the issue. In theory, yes this has to be fixed. In reality, duplicate identities from different modules for the same base type do not exist. /martin > Andy --001a11c2a8b0cb7a7004f193b009 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Tue, Feb 4, 2014 at 4:08 AM, Martin Bjorklund = <mbj@tail-f.com&= gt; wrote:
Andy Bierman <andy@yumaworks.com> wrote:
> On Tue, Feb 4, 2014 at 2:19 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
>
> > Andy Bierman <andy@yumaw= orks.com> writes:
> >
> > > On Mon, Feb 3, 2014 at 1:21 PM, Martin Bjorklund <mbj@tail-f.com> wrote:
> > >
> > >> Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrot= e:
> > >> > Hi,
> > >> >
> > >> > we (the WG chairs and Benoit) have been working on = a new charter for
> > >> > the NETMOD working group. The current version can a= lways be found
> > >> > here.
> > >> >
> > >> > =A0 https://datatracker.ietf.org/doc/chart= er-ietf-netmod/
> > >> >
> > >> > The current version is called charter-ietf-netmod-0= 6-05
> > >> >
> > >> >
> > >>
> > https://datatracker.ietf.org/doc= /charter-ietf-netmod/withmilestones-06-05.txt
> > >> >
> > >> > Please review and feel invited to comment and ask q= uestions.
> > >>
> > >> I think that in order to solve Y1 and Y3, we need an upd= ate to YANG.
> > >> Since the proposed charter allows us to this, I guess th= e charter is
> > >> ok.
> > >>
> > >> Regarding Y3 (YANG conformance), I don't think it is= clear what
> > >> problem we want to solve. =A0In my experience, I have no= t seen the
> > >> interoperability problems Andy's draft mentions. =A0= The draft raises
> > >> some valid issues (e.g., hello message size explosion an= d if-feature
> > >> with AND as only operator is too limiting), but I am not= convinced
> > >> that the current conformance mechanisms of YANG are not = good enough.
> > >>
> > >>
> > >>
> > > I do not agree that Y3 would require an update to YANG
> > > that would impact the yang "module" and "subm= odule"
> > > constructions. =A0None of the items in the charter proposal<= br> > > > are must-have features. =A0IMO, service-oriented conformance=
> > > is better than the implied-mandatory + if-feature conformanc= e
> > > model we have now.
> > >
> > > I have never actually seen the "identityref conflict&qu= ot; problem that
> > > the xpath functions need to address. Sure it is possible tha= t
> > > a server will have 2 modules, each with the same named
> > > identity, each with the same base type, but I have never see= n it actually
> > > done.
> > >
> > > There are several known issues with YANG that actually impac= t usage,
> > > and more XPath functions are fairly low on the list. =A0We a= re not helping
> > > anyone by introducing a new YANG version with 1 of 10 known = bugs fixed.
> > > Might as well fix all 10 if we bother with a YANG 1.1 releas= e at all.
> > >
> > > IMO there are better things to work on, but a new YANG versi= on just
> > > to introduce a few XPath functions would be net harmful to > > interoperability
> >
> > I don't agree. There are other things in the 1.1 todo list bu= t even the
> > XPath functions are a good-enough reason. The main problem IMO ar= e
> > identities because currently they are essentially usable only if = they are
> > flat, i.e. a base identity and identities derived directly form i= t, and
> > nothing else.
> >
> > For example, in a real Ethernet module that is modelled after App= endix A
> > in the interfaces I-D, the condition
> >
> > when "if:type =3D 'ianaift:ethernetCsmacd'"; > >
> > won't work for Ethernet interfaces whose type is *derived* fr= om
> > ethernetCsmacd.
> >
> > Combined with the limited extensibility of enumerations, this is = a serious
> > problem.
> >
> >
> If it were a serious problem then we would see it showing up
> in real implementations. =A0In fact, this problem has never occurred > even once -- not in standard modules or vendor modules.

This is weird logic. =A0Of course there are no modules that tries to do
a "derived-from" when expression, since there is no such thing as= a
"derived-from" when expression.

The fact is that we now have a module for interfaces where the
interface type is an identity. =A0The next step is to define
interface-type-specific modules, probably vendor-defined first. =A0In
this design proccess, we have run into the problem of not having a
"derived from" function, as Lada has explained.

Noone has claimed this problem to be something else than this. =A0Call
it a theoretical problem if you like. =A0The question is if the WG
thinks it is important enough to work on a solution.



The need to specify the = qualified name instead of just the local name
is the issue. =A0In= theory, yes this has to be fixed. In reality, duplicate identities
from different modules for the same base type do not exist.
=
/martin

Andy<= /div>

--001a11c2a8b0cb7a7004f193b009-- From mbj@tail-f.com Tue Feb 4 04:30:46 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 228391A0403 for ; Tue, 4 Feb 2014 04:30:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.436 X-Spam-Level: X-Spam-Status: No, score=-2.436 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YMZtmdubL0ep for ; Tue, 4 Feb 2014 04:30:44 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id B7D001A03E5 for ; Tue, 4 Feb 2014 04:30:43 -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 50B3C37C1A7; Tue, 4 Feb 2014 13:30:42 +0100 (CET) Date: Tue, 04 Feb 2014 13:30:42 +0100 (CET) Message-Id: <20140204.133042.1347956518991043674.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: <20140204.130820.1735864434118354655.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] charter revision - please comment on charter-ietf-netmod-06-05 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2014 12:30:46 -0000 Andy Bierman wrote: > On Tue, Feb 4, 2014 at 4:08 AM, Martin Bjorklund wrote: > > > Andy Bierman wrote: > > > On Tue, Feb 4, 2014 at 2:19 AM, Ladislav Lhotka wrote: > > > > > > > Andy Bierman writes: > > > > > > > > > On Mon, Feb 3, 2014 at 1:21 PM, Martin Bjorklund > > wrote: > > > > > > > > > >> Juergen Schoenwaelder wrote: > > > > >> > Hi, > > > > >> > > > > > >> > we (the WG chairs and Benoit) have been working on a new charter > > for > > > > >> > the NETMOD working group. The current version can always be found > > > > >> > here. > > > > >> > > > > > >> > https://datatracker.ietf.org/doc/charter-ietf-netmod/ > > > > >> > > > > > >> > The current version is called charter-ietf-netmod-06-05 > > > > >> > > > > > >> > > > > > >> > > > > > > https://datatracker.ietf.org/doc/charter-ietf-netmod/withmilestones-06-05.txt > > > > >> > > > > > >> > Please review and feel invited to comment and ask questions. > > > > >> > > > > >> I think that in order to solve Y1 and Y3, we need an update to YANG. > > > > >> Since the proposed charter allows us to this, I guess the charter is > > > > >> ok. > > > > >> > > > > >> Regarding Y3 (YANG conformance), I don't think it is clear what > > > > >> problem we want to solve. In my experience, I have not seen the > > > > >> interoperability problems Andy's draft mentions. The draft raises > > > > >> some valid issues (e.g., hello message size explosion and if-feature > > > > >> with AND as only operator is too limiting), but I am not convinced > > > > >> that the current conformance mechanisms of YANG are not good enough. > > > > >> > > > > >> > > > > >> > > > > > I do not agree that Y3 would require an update to YANG > > > > > that would impact the yang "module" and "submodule" > > > > > constructions. None of the items in the charter proposal > > > > > are must-have features. IMO, service-oriented conformance > > > > > is better than the implied-mandatory + if-feature conformance > > > > > model we have now. > > > > > > > > > > I have never actually seen the "identityref conflict" problem that > > > > > the xpath functions need to address. Sure it is possible that > > > > > a server will have 2 modules, each with the same named > > > > > identity, each with the same base type, but I have never seen it > > actually > > > > > done. > > > > > > > > > > There are several known issues with YANG that actually impact usage, > > > > > and more XPath functions are fairly low on the list. We are not > > helping > > > > > anyone by introducing a new YANG version with 1 of 10 known bugs > > fixed. > > > > > Might as well fix all 10 if we bother with a YANG 1.1 release at all. > > > > > > > > > > IMO there are better things to work on, but a new YANG version just > > > > > to introduce a few XPath functions would be net harmful to > > > > interoperability > > > > > > > > I don't agree. There are other things in the 1.1 todo list but even the > > > > XPath functions are a good-enough reason. The main problem IMO are > > > > identities because currently they are essentially usable only if they > > are > > > > flat, i.e. a base identity and identities derived directly form it, and > > > > nothing else. > > > > > > > > For example, in a real Ethernet module that is modelled after Appendix > > A > > > > in the interfaces I-D, the condition > > > > > > > > when "if:type = 'ianaift:ethernetCsmacd'"; > > > > > > > > won't work for Ethernet interfaces whose type is *derived* from > > > > ethernetCsmacd. > > > > > > > > Combined with the limited extensibility of enumerations, this is a > > serious > > > > problem. > > > > > > > > > > > If it were a serious problem then we would see it showing up > > > in real implementations. In fact, this problem has never occurred > > > even once -- not in standard modules or vendor modules. > > > > This is weird logic. Of course there are no modules that tries to do > > a "derived-from" when expression, since there is no such thing as a > > "derived-from" when expression. > > > > The fact is that we now have a module for interfaces where the > > interface type is an identity. The next step is to define > > interface-type-specific modules, probably vendor-defined first. In > > this design proccess, we have run into the problem of not having a > > "derived from" function, as Lada has explained. > > > > Noone has claimed this problem to be something else than this. Call > > it a theoretical problem if you like. The question is if the WG > > thinks it is important enough to work on a solution. > > > > > > > The need to specify the qualified name instead of just the local name > is the issue. In theory, yes this has to be fixed. In reality, duplicate > identities > from different modules for the same base type do not exist. That's not the issue. Please read Lada's explanation. /martin From lhotka@nic.cz Tue Feb 4 04:31:02 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DA621A0383 for ; Tue, 4 Feb 2014 04:31:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.186 X-Spam-Level: X-Spam-Status: No, score=-1.186 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RP_MATCHES_RCVD=-0.535] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jZ8u0-Der0IA for ; Tue, 4 Feb 2014 04:31:00 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id DA3A91A03FC for ; Tue, 4 Feb 2014 04:30:59 -0800 (PST) Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id B851C13FBD3; Tue, 4 Feb 2014 13:30:58 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1391517059; bh=xI4tZXPhw2rhM0JWEzw6aT6SofU/yzjJPXaK8xvxKuc=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=d+7YWf18iTgQ5urNJmXtSjK9Rai6SKlgchjru5IrlNZbd8CNm+VgfY5LlyDBbpGQS aGD6HVMl2JiuCBrZnkwf86UzXTuK7FHde+5yw1SDqEBC5SMUw5S/RveEAcDVg6OPQn he8nEVKpHIZl9nFj3h8LTXEDdxFt86I3yB97jUxw= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Ladislav Lhotka In-Reply-To: Date: Tue, 4 Feb 2014 13:30:57 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <4978895D-0150-4DB1-A91B-A9C2F5AB0F75@nic.cz> References: <20140202135609.GA35596@elstar.local> <20140203.222129.457630286.mbj@tail-f.com> To: Andy Bierman X-Mailer: Apple Mail (2.1827) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Cc: "netmod@ietf.org" Subject: Re: [netmod] charter revision - please comment on charter-ietf-netmod-06-05 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2014 12:31:02 -0000 On 04 Feb 2014, at 12:43, Andy Bierman wrote: >=20 >=20 >=20 > On Tue, Feb 4, 2014 at 2:19 AM, Ladislav Lhotka wrote: > Andy Bierman writes: >=20 > > On Mon, Feb 3, 2014 at 1:21 PM, Martin Bjorklund = wrote: > > > >> Juergen Schoenwaelder wrote: > >> > Hi, > >> > > >> > we (the WG chairs and Benoit) have been working on a new charter = for > >> > the NETMOD working group. The current version can always be found > >> > here. > >> > > >> > https://datatracker.ietf.org/doc/charter-ietf-netmod/ > >> > > >> > The current version is called charter-ietf-netmod-06-05 > >> > > >> > > >> = https://datatracker.ietf.org/doc/charter-ietf-netmod/withmilestones-06-05.= txt > >> > > >> > Please review and feel invited to comment and ask questions. > >> > >> I think that in order to solve Y1 and Y3, we need an update to = YANG. > >> Since the proposed charter allows us to this, I guess the charter = is > >> ok. > >> > >> Regarding Y3 (YANG conformance), I don't think it is clear what > >> problem we want to solve. In my experience, I have not seen the > >> interoperability problems Andy's draft mentions. The draft raises > >> some valid issues (e.g., hello message size explosion and = if-feature > >> with AND as only operator is too limiting), but I am not convinced > >> that the current conformance mechanisms of YANG are not good = enough. > >> > >> > >> > > I do not agree that Y3 would require an update to YANG > > that would impact the yang "module" and "submodule" > > constructions. None of the items in the charter proposal > > are must-have features. IMO, service-oriented conformance > > is better than the implied-mandatory + if-feature conformance > > model we have now. > > > > I have never actually seen the "identityref conflict" problem that > > the xpath functions need to address. Sure it is possible that > > a server will have 2 modules, each with the same named > > identity, each with the same base type, but I have never seen it = actually > > done. > > > > There are several known issues with YANG that actually impact usage, > > and more XPath functions are fairly low on the list. We are not = helping > > anyone by introducing a new YANG version with 1 of 10 known bugs = fixed. > > Might as well fix all 10 if we bother with a YANG 1.1 release at = all. > > > > IMO there are better things to work on, but a new YANG version just > > to introduce a few XPath functions would be net harmful to = interoperability >=20 > I don't agree. There are other things in the 1.1 todo list but even = the XPath functions are a good-enough reason. The main problem IMO are = identities because currently they are essentially usable only if they = are flat, i.e. a base identity and identities derived directly form it, = and nothing else. >=20 > For example, in a real Ethernet module that is modelled after Appendix = A in the interfaces I-D, the condition >=20 > when "if:type =3D 'ianaift:ethernetCsmacd'"; >=20 > won't work for Ethernet interfaces whose type is *derived* from = ethernetCsmacd. >=20 > Combined with the limited extensibility of enumerations, this is a = serious problem. >=20 >=20 > If it were a serious problem then we would see it showing up > in real implementations. In fact, this problem has never occurred > even once -- not in standard modules or vendor modules. I have just run into it. I am developing a module for the NetIDE project = - it is supposed to capture network topology and behaviour. In the = topology part, I need to distinguish between networks and end-hosts at = the base level, but at other levels end-hosts are further divided into = hosts, routers, switches etc. So the desired hierarchy of identities is node network end-system host router switch And it is impossible to use =93when=94 for distinguishing between = =93network=94 and =93end-system=94 because end hosts are configured with = the leaf identities. =20 =20 > The local names have to be for the same base. If not, the tool > knows (because the leaf includes the base identity type). > In theory this XPath cannot possibly work. In reality it works OK. Hey, you already have these XPath extensions in Yuma, right? I don=92t = want to get into a situation like =93This module was optimized for = software XY=94. Lada=20 >=20 >=20 > Lada >=20 > > > > > > /martin > >> > >> > > Andy >=20 > Andy >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From jonathan@hansfords.net Tue Feb 4 04:53:45 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E9061A0383 for ; Tue, 4 Feb 2014 04:53:45 -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=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gbg_xgXB9G_4 for ; Tue, 4 Feb 2014 04:53:41 -0800 (PST) Received: from avasout03.plus.net (avasout03.plus.net [84.93.230.244]) by ietfa.amsl.com (Postfix) with ESMTP id 2B9491A036D for ; Tue, 4 Feb 2014 04:53:40 -0800 (PST) Received: from webmail.plus.net ([84.93.228.147]) by avasout03 with smtp id NCte1n00E3BT6uC01Ctekn; Tue, 04 Feb 2014 12:53:39 +0000 X-CM-Score: 0.00 X-CNFS-Analysis: v=2.1 cv=WPfxXxcR c=1 sm=1 tr=0 a=jSQgp9IWXRf89EXR5FPwJg==:117 a=657E4hAeR8dYZ1rsg01OlA==:17 a=0Bzu9jTXAAAA:8 a=dYCPD3cKDi0A:10 a=bk6C-FOLwXYA:10 a=0B8HqoTn75oA:10 a=eDuwVpe5h8AA:10 a=6bkCdLdQAAAA:8 a=f0uUZFObAAAA:8 a=xOktEEvlm3cA:10 a=xskcdSivAAAA:8 a=u07AKapRAAAA:8 a=48vgC7mUAAAA:8 a=8mxGs0WRWmKDI2-a9pIA:9 a=K7GP3XcuSYNT_Lc9:21 a=hLFWo9eUSYeGAv9j:21 a=QEXdDO2ut3YA:10 a=ChEcuLpljosA:10 a=XqebBV1NYWwA:10 a=zeshHG33Dl4A:10 a=bvD8pEsyJsYArnT099gA:9 a=S_ql90JndZVO-q6r:21 a=howL0ZWD-tHSYsM_:21 a=2a64PuloUS9NNq_a:21 a=_W_S_7VecoQA:10 X-AUTH: hansfords+us:2500 Received: from host-212-159-131-152.static.as13285.net ([212.159.131.152]) by webmail.plus.net with HTTP (HTTP/1.1 POST); Tue, 04 Feb 2014 12:53:38 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_97e9d73c001ea083e98a9b32aa3fac22" Date: Tue, 04 Feb 2014 12:53:38 +0000 From: Jonathan Hansford To: In-Reply-To: References: <20140202135609.GA35596@elstar.local> <20140203.222129.457630286.mbj@tail-f.com> Message-ID: X-Sender: Jonathan@hansfords.net User-Agent: Roundcube Webmail/0.7.4 X-Originating-IP: [212.159.131.152] Subject: Re: [netmod] charter revision - please comment on charter-ietf-netmod-06-05 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2014 12:53:45 -0000 --=_97e9d73c001ea083e98a9b32aa3fac22 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=UTF-8 On 2014-02-04 11:43, Andy Bierman wrote: > On Tue, Feb 4, 2014 at 2:19 AM, Ladislav Lhotka wrote: > >> Andy Bierman writes: >> >> > On Mon, Feb 3, 2014 at 1:21 PM, Martin Bjorklund wrote: >> > >> >> Juergen Schoenwaelder wrote: >> >> > Hi, >> >> > >> >> > we (the WG chairs and Benoit) have been working on a new charter for >> >> > the NETMOD working group. The current version can always be found >> >> > here. >> >> > >> >> > https://datatracker.ietf.org/doc/charter-ietf-netmod/ [4] >> >> > >> >> > The current version is called charter-ietf-netmod-06-05 >> >> > >> >> > >> >> https://datatracker.ietf.org/doc/charter-ietf-netmod/withmilestones-06-05.txt [5] >> >> > >> >> > Please review and feel invited to comment and ask questions. >> >> >> >> I think that in order to solve Y1 and Y3, we need an update to YANG. >> >> Since the proposed charter allows us to this, I guess the charter is >> >> ok. >> >> >> >> Regarding Y3 (YANG conformance), I don't think it is clear what >> >> problem we want to solve. In my experience, I have not seen the >> >> interoperability problems Andy's draft mentions. The draft raises >> >> some valid issues (e.g., hello message size explosion and if-feature >> >> with AND as only operator is too limiting), but I am not convinced >> >> that the current conformance mechanisms of YANG are not good enough. >> >> >> >> >> >> >> > I do not agree that Y3 would require an update to YANG >> > that would impact the yang "module" and "submodule" >> > constructions. None of the items in the charter proposal >> > are must-have features. IMO, service-oriented conformance >> > is better than the implied-mandatory + if-feature conformance >> > model we have now. >> > >> > I have never actually seen the "identityref conflict" problem that >> > the xpath functions need to address. Sure it is possible that >> > a server will have 2 modules, each with the same named >> > identity, each with the same base type, but I have never seen it actually >> > done. >> > >> > There are several known issues with YANG that actually impact usage, >> > and more XPath functions are fairly low on the list. We are not helping >> > anyone by introducing a new YANG version with 1 of 10 known bugs fixed. >> > Might as well fix all 10 if we bother with a YANG 1.1 release at all. >> > >> > IMO there are better things to work on, but a new YANG version just >> > to introduce a few XPath functions would be net harmful to interoperability >> >> I don't agree. There are other things in the 1.1 todo list but even the XPath functions are a good-enough reason. The main problem IMO are identities because currently they are essentially usable only if they are flat, i.e. a base identity and identities derived directly form it, and nothing else. >> >> For example, in a real Ethernet module that is modelled after Appendix A in the interfaces I-D, the condition >> >> when "if:type = 'ianaift:ethernetCsmacd'"; >> >> won't work for Ethernet interfaces whose type is *derived* from ethernetCsmacd. >> >> Combined with the limited extensibility of enumerations, this is a serious problem. > > If it were a serious problem then we would see it showing up > in real implementations. In fact, this problem has never occurred > even once -- not in standard modules or vendor modules. > The local names have to be for the same base. If not, the tool > knows (because the leaf includes the base identity type). > In theory this XPath cannot possibly work. In reality it works OK. For someone who is still trying to get his company to migrate to YANG and has therefore still not had the opportunity to use it in anger, that last sentence doesn't inspire confidence. For any who are new to implementing YANG, being advised that something that "cannot possibly work ... in reality works OK" just engenders a sense of uncertainty, not just about this but whether there are other areas of YANG where uncertainty lurks. >> Lada >> >> > >> > >> > /martin >> >> >> >> >> > Andy > > Andy Links: ------ [1] mailto:andy@yumaworks.com [2] mailto:mbj@tail-f.com [3] mailto:j.schoenwaelder@jacobs-university.de [4] https://datatracker.ietf.org/doc/charter-ietf-netmod/ [5] https://datatracker.ietf.org/doc/charter-ietf-netmod/withmilestones-06-05.txt [6] mailto:lhotka@nic.cz --=_97e9d73c001ea083e98a9b32aa3fac22 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8

 

On 2014-02-04 11:43, Andy Bierman wrote:




On Tue, Feb 4, 2014 at 2:19 AM, Ladislav Lhotka = <lhotka@nic.cz> wro= te:
Andy Bierman <andy@yumaworks.com> writes:

> O= n Mon, Feb 3, 2014 at 1:21 PM, Martin Bjorklund <mbj@tail-f.com> wrote:
>
>> Juergen = Schoenwaelder <j= =2Eschoenwaelder@jacobs-university.de> wrote:
>> > Hi= ,
>> >
>> > we (the WG chairs and Benoit) hav= e been working on a new charter for
>> > the NETMOD working = group. The current version can always be found
>> > here. >> >
>> >   https://datatracker.ietf.org/doc/char= ter-ietf-netmod/
>> >
>> > The current ve= rsion is called charter-ietf-netmod-06-05
>> >
>>= ; >
>> https://datatracker.ietf.org/doc/chart= er-ietf-netmod/withmilestones-06-05.txt
>> >
>&= gt; > Please review and feel invited to comment and ask questions.
= >>
>> I think that in order to solve Y1 and Y3, we need = an update to YANG.
>> Since the proposed charter allows us to t= his, I guess the charter is
>> ok.
>>
>>= ; Regarding Y3 (YANG conformance), I don't think it is clear what
>= ;> problem we want to solve.  In my experience, I have not seen the=
>> interoperability problems Andy's draft mentions.  The = draft raises
>> some valid issues (e.g., hello message size exp= losion and if-feature
>> with AND as only operator is too limit= ing), but I am not convinced
>> that the current conformance me= chanisms of YANG are not good enough.
>>
>>
&= gt;>
> I do not agree that Y3 would require an update to YANG > that would impact the yang "module" and "submodule"
> co= nstructions.  None of the items in the charter proposal
> are= must-have features.  IMO, service-oriented conformance
> is = better than the implied-mandatory + if-feature conformance
> model= we have now.
>
> I have never actually seen the "identit= yref conflict" problem that
> the xpath functions need to address= =2E Sure it is possible that
> a server will have 2 modules, each = with the same named
> identity, each with the same base type, but = I have never seen it actually
> done.
>
> There = are several known issues with YANG that actually impact usage,
> a= nd more XPath functions are fairly low on the list.  We are not helpin= g
> anyone by introducing a new YANG version with 1 of 10 known bu= gs fixed.
> Might as well fix all 10 if we bother with a YANG 1.1 = release at all.
>
> IMO there are better things to work o= n, but a new YANG version just
> to introduce a few XPath function= s would be net harmful to interoperability

I don't agree. There= are other things in the 1.1 todo list but even the XPath functions are a g= ood-enough reason. The main problem IMO are identities because currently th= ey are essentially usable only if they are flat, i.e. a base identity and i= dentities derived directly form it, and nothing else.

For examp= le, in a real Ethernet module that is modelled after Appendix A in the= interfaces I-D, the condition

when "if:type =3D 'ianaift:ether= netCsmacd'";

won't work for Ethernet interfaces whose type is *= derived* from ethernetCsmacd.

Combined with the limited extensi= bility of enumerations, this is a serious problem.

If it were a serious problem then we would see it showing up
in real implementations.  In fact, this problem has never occurre= d
even once -- not in standard modules or vendor modules.
The local names have to be for the same base.  If not, the tool
knows (because the leaf includes the base identity type).
In theory this XPath cannot possibly work.  In reality it works O= K.
For someone who is still trying to get his company to migrate to YANG = and has therefore still not had the opportunity to use it in anger, that la= st sentence doesn't inspire confidence. For any who are new to implementing= YANG, being advised that something that "cannot possibly work ... in reali= ty works OK" just engenders a sense of uncertainty, not just about this but= whether there are other areas of YANG where uncertainty lurks.
Lada

>
><= br /> > /martin
>>
>>
> Andy
Andy
--=_97e9d73c001ea083e98a9b32aa3fac22-- From andy@yumaworks.com Tue Feb 4 05:28:54 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD7D31A0430 for ; Tue, 4 Feb 2014 05:28:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_47=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0RbZKgfQhOlQ for ; Tue, 4 Feb 2014 05:28:51 -0800 (PST) Received: from mail-qc0-f177.google.com (mail-qc0-f177.google.com [209.85.216.177]) by ietfa.amsl.com (Postfix) with ESMTP id 91B3B1A0416 for ; Tue, 4 Feb 2014 05:28:51 -0800 (PST) Received: by mail-qc0-f177.google.com with SMTP id i8so13317424qcq.36 for ; Tue, 04 Feb 2014 05:28:51 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=I1QceUlwSgCPZhlJcjXFnqLWNWJrpKGeCQYfh0VWCXs=; b=aXd6Q7hAA/WGilAmpNIUvFSP4WWCVjQQRDIoKbbqEJzVrobF3JsMAXlnAgTJ16lE8D Czud8oLyWY+OByayDecfAlNZIiupl55BSOjRiimS1WKWj2OFS1YTxNsBIE2XWjzexsio DJc3TNodGMjI46Yt1Z/N98ngdo12/eOSqcHJtbECi0Nf2YkeK/a4Orv2+s+a9VZl/viq zbUffeD2k8FZxFb0Zg401JlUx1bw+Ke/2w3EnsR6r07oXAuzg5b2olXX/t6tvQmF8RKv tVCduSSfxvXvTY54fHyxzXmMrW1hTYF2cd/ZJWvuZEl978hYhCN/9Wznzn38Sko/s0Bg Z2yA== X-Gm-Message-State: ALoCoQnOGLBKDcYd5il5EyLMj17u/z6if00pE54VdKg9JwCLH/M1aogipebVTpMwdXZM2hhwrSYQ MIME-Version: 1.0 X-Received: by 10.140.27.179 with SMTP id 48mr61581639qgx.18.1391520531027; Tue, 04 Feb 2014 05:28:51 -0800 (PST) Received: by 10.140.48.75 with HTTP; Tue, 4 Feb 2014 05:28:50 -0800 (PST) In-Reply-To: <4978895D-0150-4DB1-A91B-A9C2F5AB0F75@nic.cz> References: <20140202135609.GA35596@elstar.local> <20140203.222129.457630286.mbj@tail-f.com> <4978895D-0150-4DB1-A91B-A9C2F5AB0F75@nic.cz> Date: Tue, 4 Feb 2014 05:28:50 -0800 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=001a11c00434f33f6004f1949edb Cc: "netmod@ietf.org" Subject: Re: [netmod] charter revision - please comment on charter-ietf-netmod-06-05 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2014 13:28:55 -0000 --001a11c00434f33f6004f1949edb Content-Type: text/plain; charset=ISO-8859-1 On Tue, Feb 4, 2014 at 4:30 AM, Ladislav Lhotka wrote: > > On 04 Feb 2014, at 12:43, Andy Bierman wrote: > > > > > > > > > On Tue, Feb 4, 2014 at 2:19 AM, Ladislav Lhotka wrote: > > Andy Bierman writes: > > > > > On Mon, Feb 3, 2014 at 1:21 PM, Martin Bjorklund > wrote: > > > > > >> Juergen Schoenwaelder wrote: > > >> > Hi, > > >> > > > >> > we (the WG chairs and Benoit) have been working on a new charter for > > >> > the NETMOD working group. The current version can always be found > > >> > here. > > >> > > > >> > https://datatracker.ietf.org/doc/charter-ietf-netmod/ > > >> > > > >> > The current version is called charter-ietf-netmod-06-05 > > >> > > > >> > > > >> > https://datatracker.ietf.org/doc/charter-ietf-netmod/withmilestones-06-05.txt > > >> > > > >> > Please review and feel invited to comment and ask questions. > > >> > > >> I think that in order to solve Y1 and Y3, we need an update to YANG. > > >> Since the proposed charter allows us to this, I guess the charter is > > >> ok. > > >> > > >> Regarding Y3 (YANG conformance), I don't think it is clear what > > >> problem we want to solve. In my experience, I have not seen the > > >> interoperability problems Andy's draft mentions. The draft raises > > >> some valid issues (e.g., hello message size explosion and if-feature > > >> with AND as only operator is too limiting), but I am not convinced > > >> that the current conformance mechanisms of YANG are not good enough. > > >> > > >> > > >> > > > I do not agree that Y3 would require an update to YANG > > > that would impact the yang "module" and "submodule" > > > constructions. None of the items in the charter proposal > > > are must-have features. IMO, service-oriented conformance > > > is better than the implied-mandatory + if-feature conformance > > > model we have now. > > > > > > I have never actually seen the "identityref conflict" problem that > > > the xpath functions need to address. Sure it is possible that > > > a server will have 2 modules, each with the same named > > > identity, each with the same base type, but I have never seen it > actually > > > done. > > > > > > There are several known issues with YANG that actually impact usage, > > > and more XPath functions are fairly low on the list. We are not > helping > > > anyone by introducing a new YANG version with 1 of 10 known bugs fixed. > > > Might as well fix all 10 if we bother with a YANG 1.1 release at all. > > > > > > IMO there are better things to work on, but a new YANG version just > > > to introduce a few XPath functions would be net harmful to > interoperability > > > > I don't agree. There are other things in the 1.1 todo list but even the > XPath functions are a good-enough reason. The main problem IMO are > identities because currently they are essentially usable only if they are > flat, i.e. a base identity and identities derived directly form it, and > nothing else. > > > > For example, in a real Ethernet module that is modelled after Appendix A > in the interfaces I-D, the condition > > > > when "if:type = 'ianaift:ethernetCsmacd'"; > > > > won't work for Ethernet interfaces whose type is *derived* from > ethernetCsmacd. > > > > Combined with the limited extensibility of enumerations, this is a > serious problem. > > > > > > If it were a serious problem then we would see it showing up > > in real implementations. In fact, this problem has never occurred > > even once -- not in standard modules or vendor modules. > > I have just run into it. I am developing a module for the NetIDE project - > it is supposed to capture network topology and behaviour. In the topology > part, I need to distinguish between networks and end-hosts at the base > level, but at other levels end-hosts are further divided into hosts, > routers, switches etc. > So the desired hierarchy of identities is > > node > network > end-system > host > router > switch > > And it is impossible to use "when" for distinguishing between "network" > and "end-system" because end hosts are configured with the leaf identities. > > The issue comes down to custom XPath work when "ident-leaf = 'network'"; The Yuma* code knows this string (network) is really a QName and not a string. So if the when-stmt had a prefix, it would be handled correctly: when "ident-leaf = 'acme:network'"; We agree standard XPath tools do not know this string is really a QName. In practice, there are not multiple related identities with the same local name (e.g., example:network and acme:network are both valid identities for this leaf). Since no off-the-shelf XPath tools support this new "derived-from" function, this is still an academic solution. New code is needed in any case. I am not against fixing this issue, but it is not important enough by itself to justify a new YANG version. > > The local names have to be for the same base. If not, the tool > > knows (because the leaf includes the base identity type). > > In theory this XPath cannot possibly work. In reality it works OK. > > Hey, you already have these XPath extensions in Yuma, right? I don't want > to get into a situation like "This module was optimized for software XY". > > Once we start adding "yang-version 1.1;" to YANG modules, designers will be making the choice to not support old tools at all. Will we have 1.0 modules attempting to import 1.1 modules? Vice versa? How do both language versions co-exist in the same client or server? The operational impact of a new language version roll-out is going to be severe. Lada > > > > > > > Lada > > > > > > > > > > > /martin > > >> > > >> > > > Andy > > > > Andy > > > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > --001a11c00434f33f6004f1949edb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Tue, Feb 4, 2014 at 4:30 AM, Ladislav Lhotka &= lt;lhotka@nic.cz>= wrote:

On 04 Feb 2014, at 12:43, Andy Bierman <andy@yumaworks.com> wrote:

>
>
>
> On Tue, Feb 4, 2014 at 2:19 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
> Andy Bierman <andy@yumaworks.= com> writes:
>
> > On Mon, Feb 3, 2014 at 1:21 PM, Martin Bjorklund <mbj@tail-f.com> wrote:
> >
> >> Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote: > >> > Hi,
> >> >
> >> > we (the WG chairs and Benoit) have been working on a new= charter for
> >> > the NETMOD working group. The current version can always= be found
> >> > here.
> >> >
> >> >   https://datatracker.ietf.org/doc/charter= -ietf-netmod/
> >> >
> >> > The current version is called charter-ietf-netmod-06-05<= br> > >> >
> >> >
> >> https://datatracker.ietf.org= /doc/charter-ietf-netmod/withmilestones-06-05.txt
> >> >
> >> > Please review and feel invited to comment and ask questi= ons.
> >>
> >> I think that in order to solve Y1 and Y3, we need an update t= o YANG.
> >> Since the proposed charter allows us to this, I guess the cha= rter is
> >> ok.
> >>
> >> Regarding Y3 (YANG conformance), I don't think it is clea= r what
> >> problem we want to solve.  In my experience, I have not = seen the
> >> interoperability problems Andy's draft mentions.  Th= e draft raises
> >> some valid issues (e.g., hello message size explosion and if-= feature
> >> with AND as only operator is too limiting), but I am not conv= inced
> >> that the current conformance mechanisms of YANG are not good = enough.
> >>
> >>
> >>
> > I do not agree that Y3 would require an update to YANG
> > that would impact the yang "module" and "submodule= "
> > constructions.  None of the items in the charter proposal > > are must-have features.  IMO, service-oriented conformance > > is better than the implied-mandatory + if-feature conformance
> > model we have now.
> >
> > I have never actually seen the "identityref conflict" p= roblem that
> > the xpath functions need to address. Sure it is possible that
> > a server will have 2 modules, each with the same named
> > identity, each with the same base type, but I have never seen it = actually
> > done.
> >
> > There are several known issues with YANG that actually impact usa= ge,
> > and more XPath functions are fairly low on the list.  We are= not helping
> > anyone by introducing a new YANG version with 1 of 10 known bugs = fixed.
> > Might as well fix all 10 if we bother with a YANG 1.1 release at = all.
> >
> > IMO there are better things to work on, but a new YANG version ju= st
> > to introduce a few XPath functions would be net harmful to intero= perability
>
> I don't agree. There are other things in the 1.1 todo list but eve= n the XPath functions are a good-enough reason. The main problem IMO are id= entities because currently they are essentially usable only if they are fla= t, i.e. a base identity and identities derived directly form it, and nothin= g else.
>
> For example, in a real Ethernet module that is modelled after Appendix= A in the interfaces I-D, the condition
>
> when "if:type =3D 'ianaift:ethernetCsmacd'";
>
> won't work for Ethernet interfaces whose type is *derived* from et= hernetCsmacd.
>
> Combined with the limited extensibility of enumerations, this is a ser= ious problem.
>
>
> If it were a serious problem then we would see it showing up
> in real implementations.  In fact, this problem has never occurre= d
> even once -- not in standard modules or vendor modules.

I have just run into it. I am developing a module for the NetIDE project - = it is supposed to capture network topology and behaviour. In the topology p= art, I need to distinguish between networks and end-hosts at the base level= , but at other levels end-hosts are further divided into hosts, routers, sw= itches etc.
So the desired hierarchy of identities is

node
  network
  end-system
    host
    router
    switch

And it is impossible to use “when” for distinguishing between &= ldquo;network” and “end-system” because end hosts are con= figured with the leaf identities.



The issue comes down to= custom XPath work

   when "ident-l= eaf =3D 'network'";

The Yuma* code kn= ows this string (network) is really a QName and not a string.
So if the when-stmt had a prefix, it would be handled correctly:
=

  when "ident-leaf =3D 'acme:network'= ";

We agree standard XPath tools do not know = this string is really a QName.
In practice, there are not multiple related identities with the same l= ocal
name (e.g., example:network and acme:network are both valid<= /div>
identities for this leaf).

Since no off-= the-shelf XPath tools support this new "derived-from" function,
this is still an academic solution. New code is needed in any case.

I am not against fixing this issue, but it is not im= portant enough by itself
to justify a new YANG version.





> The local names have to be for the same base.  If not, the tool > knows (because the leaf includes the base identity type).
> In theory this XPath cannot possibly work.  In reality it works O= K.

Hey, you already have these XPath extensions in Yuma, right? I don’t = want to get into a situation like “This module was optimized for soft= ware XY”.


Once we start adding "yang-versio= n 1.1;" to YANG modules, designers will be making the choice
to not support old tools at all. Will we have 1.0 modules attempting to im= port 1.1 modules? Vice versa?
How do both language versions co-exist in the same client or server? &= nbsp;The operational impact
of a new language version roll-out is= going to be severe.


Lada

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

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





--001a11c00434f33f6004f1949edb-- From lhotka@nic.cz Tue Feb 4 05:48:52 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2ABE71A0430 for ; Tue, 4 Feb 2014 05:48:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.586 X-Spam-Level: X-Spam-Status: No, score=-0.586 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, J_CHICKENPOX_47=0.6, RP_MATCHES_RCVD=-0.535] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30w_ssMSKMo6 for ; Tue, 4 Feb 2014 05:48: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 4D3411A0443 for ; Tue, 4 Feb 2014 05:48:50 -0800 (PST) Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 262BA13FCB2; Tue, 4 Feb 2014 14:48:49 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1391521729; bh=eljTViZk55mOc933kETsC0KTeGFFb2P7ISVpd37w9Qs=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=Dx+lHU4n2rovgnq8e30e7DNMqzgzf2lAQS6pZbsvQjBUPNLj9hXOXUNXShiU+zgY/ I+B0CTWr0EWp+sRy3ZR7rTUXkwm7/efXubQLzK+s4Fl/AXBHRnnMbA4dh+OIqXJh9M kN3vK3zwWTUTG8riLS94o8u3qVmcNHz9eVnpYIMo= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Ladislav Lhotka In-Reply-To: Date: Tue, 4 Feb 2014 14:48:48 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <749A7AF5-9CED-484F-AC90-677CE4ED3EF2@nic.cz> References: <20140202135609.GA35596@elstar.local> <20140203.222129.457630286.mbj@tail-f.com> <4978895D-0150-4DB1-A91B-A9C2F5AB0F75@nic.cz> To: Andy Bierman X-Mailer: Apple Mail (2.1827) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Cc: "netmod@ietf.org" Subject: Re: [netmod] charter revision - please comment on charter-ietf-netmod-06-05 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2014 13:48:52 -0000 On 04 Feb 2014, at 14:28, Andy Bierman wrote: > node > network > end-system > host > router > switch >=20 > And it is impossible to use =93when=94 for distinguishing between = =93network=94 and =93end-system=94 because end hosts are configured with = the leaf identities. >=20 >=20 >=20 > The issue comes down to custom XPath work >=20 > when "ident-leaf =3D 'network'"; >=20 > The Yuma* code knows this string (network) is really a QName and not a = string. > So if the when-stmt had a prefix, it would be handled correctly: >=20 > when "ident-leaf =3D 'acme:network=92"; But it is not about strings versus QNames! The problem is that the = parent augment is supposed to be applied to nodes whose type is = *derived* from network, for example =93acme:router=94. This is where the = derived-from() function is needed. >=20 > We agree standard XPath tools do not know this string is really a = QName. > In practice, there are not multiple related identities with the same = local > name (e.g., example:network and acme:network are both valid > identities for this leaf). >=20 > Since no off-the-shelf XPath tools support this new "derived-from" = function, > this is still an academic solution. New code is needed in any case. >=20 > I am not against fixing this issue, but it is not important enough by = itself > to justify a new YANG version. >=20 >=20 >=20 >=20 >=20 > > The local names have to be for the same base. If not, the tool > > knows (because the leaf includes the base identity type). > > In theory this XPath cannot possibly work. In reality it works OK. >=20 > Hey, you already have these XPath extensions in Yuma, right? I don=92t = want to get into a situation like =93This module was optimized for = software XY=94. >=20 >=20 > Once we start adding "yang-version 1.1;" to YANG modules, designers = will be making the choice > to not support old tools at all. Will we have 1.0 modules attempting = to import 1.1 modules? Vice versa? > How do both language versions co-exist in the same client or server? = The operational impact > of a new language version roll-out is going to be severe. It seems you are not against fixing things under the hood, you just = don=92t want to admit it officially by bumping the version number - = presumably because then even managers can get the message that YANG may = not be as stable as it is claimed. My concern is that this tactic will lead to various ugly hacks and = hidden incompatibilities. As much as I like YANG, developing a new language does have some costs. = We could hardly expect to get everything right at the first attempt. Lada -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From andy@yumaworks.com Tue Feb 4 06:09:33 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A71B01A011C for ; Tue, 4 Feb 2014 06:09:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_47=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IdX8pozRgX89 for ; Tue, 4 Feb 2014 06:09:30 -0800 (PST) Received: from mail-qa0-f46.google.com (mail-qa0-f46.google.com [209.85.216.46]) by ietfa.amsl.com (Postfix) with ESMTP id 685A61A011A for ; Tue, 4 Feb 2014 06:09:30 -0800 (PST) Received: by mail-qa0-f46.google.com with SMTP id ii20so12130610qab.33 for ; Tue, 04 Feb 2014 06:09:30 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=bVyhKTBY1sRmZ4ZODil0zZ2JwDGk7jLVMrQgshu+ssE=; b=WINaUvCRng4d7un+Ur07elyZAfqNDnQDx8YlEX2jJV+2dTm3yBwvESZ+RLQMGBIGGI 6PJ5+JwCDowDVHWLYoGBk6etegD0vsijXDph0TnMmECSS17IoFzAHr0DdWUtJ++bs5Qo uWLWK1HsJkDha2bPCDHxLg/xeQUtNnPXkoVnDh/kE9y9t8NG1xkL5z5QrWH3obwAfCF5 SJWIIuSzfmLunpsW2g/kWwXFd6nrdIgApWLe2ftEYjcIwHo5onJE3rgT67DFo36tAqPC V0tjgci10s8hMllarSN40lac7ZGA7HfmHIgS2O6NwlnXXukhe/EtNyK0YBL+njHXnXLg gxBg== X-Gm-Message-State: ALoCoQnZSOMtMriEbYqrT3FnSr+gTy8CBH2HtCEWSsQYlQ03Dhsivg/68khA/AgoclirYeAPREdc MIME-Version: 1.0 X-Received: by 10.140.36.107 with SMTP id o98mr62620694qgo.25.1391522969959; Tue, 04 Feb 2014 06:09:29 -0800 (PST) Received: by 10.140.48.75 with HTTP; Tue, 4 Feb 2014 06:09:29 -0800 (PST) In-Reply-To: <749A7AF5-9CED-484F-AC90-677CE4ED3EF2@nic.cz> References: <20140202135609.GA35596@elstar.local> <20140203.222129.457630286.mbj@tail-f.com> <4978895D-0150-4DB1-A91B-A9C2F5AB0F75@nic.cz> <749A7AF5-9CED-484F-AC90-677CE4ED3EF2@nic.cz> Date: Tue, 4 Feb 2014 06:09:29 -0800 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=001a11c154b652502a04f19530e2 Cc: "netmod@ietf.org" Subject: Re: [netmod] charter revision - please comment on charter-ietf-netmod-06-05 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2014 14:09:33 -0000 --001a11c154b652502a04f19530e2 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Feb 4, 2014 at 5:48 AM, Ladislav Lhotka wrote: > > On 04 Feb 2014, at 14:28, Andy Bierman wrote: > > > node > > network > > end-system > > host > > router > > switch > > > > And it is impossible to use "when" for distinguishing between "network" > and "end-system" because end hosts are configured with the leaf identities. > > > > > > > > The issue comes down to custom XPath work > > > > when "ident-leaf = 'network'"; > > > > The Yuma* code knows this string (network) is really a QName and not a > string. > > So if the when-stmt had a prefix, it would be handled correctly: > > > > when "ident-leaf = 'acme:network'"; > > But it is not about strings versus QNames! The problem is that the parent > augment is supposed to be applied to nodes whose type is *derived* from > network, for example "acme:router". This is where the derived-from() > function is needed. > > OK -- this seems like a very minor feature. Originally the identyref is just for comparing the same base identity types. The ability to compare against sub-trees in the identity hierarchy is a new feature. > > > We agree standard XPath tools do not know this string is really a QName. > > In practice, there are not multiple related identities with the same > local > > name (e.g., example:network and acme:network are both valid > > identities for this leaf). > > > > Since no off-the-shelf XPath tools support this new "derived-from" > function, > > this is still an academic solution. New code is needed in any case. > > > > I am not against fixing this issue, but it is not important enough by > itself > > to justify a new YANG version. > > > > > > > > > > > > > The local names have to be for the same base. If not, the tool > > > knows (because the leaf includes the base identity type). > > > In theory this XPath cannot possibly work. In reality it works OK. > > > > Hey, you already have these XPath extensions in Yuma, right? I don't > want to get into a situation like "This module was optimized for software > XY". > > > > > > Once we start adding "yang-version 1.1;" to YANG modules, designers will > be making the choice > > to not support old tools at all. Will we have 1.0 modules attempting to > import 1.1 modules? Vice versa? > > How do both language versions co-exist in the same client or server? > The operational impact > > of a new language version roll-out is going to be severe. > > It seems you are not against fixing things under the hood, you just don't > want to admit it officially by bumping the version number - presumably > because then even managers can get the message that YANG may not be as > stable as it is claimed. > > My concern is that this tactic will lead to various ugly hacks and hidden > incompatibilities. > > As much as I like YANG, developing a new language does have some costs. We > could hardly expect to get everything right at the first attempt. > > The hacks will come when developers comment out the "yang-version 1.1;" because they cannot ignore the module and they cannot upgrade all their tools at once either. The hacks will come when developers make ad-hoc choices converting 1.1 modules back to 1.0 so they can be usable by their old tools. I accept that we have to bump the version number to make changes that break YANG 1.0 assumptions. I also realize just how expensive that change will be to deployment. We went through this already in SNMP-land. > Lada > Andy --001a11c154b652502a04f19530e2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Tue, Feb 4, 2014 at 5:48 AM, Ladislav Lhotka &= lt;lhotka@nic.cz>= wrote:

On 04 Feb 2014, at 14:28, Andy Bierman <andy@yumaworks.com> wrote:

> node
>   network
>   end-system
>     host
>     router
>     switch
>
> And it is impossible to use “when” for distinguishing betw= een “network” and “end-system” because end hosts ar= e configured with the leaf identities.
>
>
>
> The issue comes down to custom XPath work
>
>    when "ident-leaf =3D 'network'";
>
> The Yuma* code knows this string (network) is really a QName and not a= string.
> So if the when-stmt had a prefix, it would be handled correctly:
>
>   when "ident-leaf =3D 'acme:network’";

But it is not about strings versus QNames! The problem is that the parent a= ugment is supposed to be applied to nodes whose type is *derived* from netw= ork, for example “acme:router”. This is where the derived-from(= ) function is needed.


OK -- this seems like a very minor fea= ture.
Originally the identyref is just for comparing the same bas= e
identity types.  The ability to compare against sub-trees = in the
identity hierarchy is a new feature.


>
> We agree standard XPath tools do not know this string is really a QNam= e.
> In practice, there are not multiple related identities with the same l= ocal
> name (e.g., example:network and acme:network are both valid
> identities for this leaf).
>
> Since no off-the-shelf XPath tools support this new "derived-from= " function,
> this is still an academic solution. New code is needed in any case. >
> I am not against fixing this issue, but it is not important enough by = itself
> to justify a new YANG version.
>
>
>
>
>
> > The local names have to be for the same base.  If not, the t= ool
> > knows (because the leaf includes the base identity type).
> > In theory this XPath cannot possibly work.  In reality it wo= rks OK.
>
> Hey, you already have these XPath extensions in Yuma, right? I don&rsq= uo;t want to get into a situation like “This module was optimized for= software XY”.
>
>
> Once we start adding "yang-version 1.1;" to YANG modules, de= signers will be making the choice
> to not support old tools at all. Will we have 1.0 modules attempting t= o import 1.1 modules? Vice versa?
> How do both language versions co-exist in the same client or server? &= nbsp;The operational impact
> of a new language version roll-out is going to be severe.

It seems you are not against fixing things under the hood, you just don&rsq= uo;t want to admit it officially by bumping the version number - presumably= because then even managers can get the message that YANG may not be as sta= ble as it is claimed.

My concern is that this tactic will lead to various ugly hacks and hidden i= ncompatibilities.

As much as I like YANG, developing a new language does have some costs. We = could hardly expect to get everything right at the first attempt.



The hacks will come whe= n developers comment out the "yang-version 1.1;"
becaus= e they cannot ignore the module and they cannot upgrade
all their= tools at once either. The hacks will come when developers
make ad-hoc choices converting 1.1 modules back to 1.0 so they
can be usable by their old tools.

I accept that= we have to bump the version number to make
changes that break YA= NG 1.0 assumptions.  I also realize
just how expensive that change will be to deployment.  We went th= rough
this already in SNMP-land.

 <= br>
Lada

Andy
 
<= /div>
--001a11c154b652502a04f19530e2-- From mbj@tail-f.com Tue Feb 4 06:18:22 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65F1C1A0131 for ; Tue, 4 Feb 2014 06:18:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.436 X-Spam-Level: X-Spam-Status: No, score=-2.436 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wazRtjEYfa_C for ; Tue, 4 Feb 2014 06:18:20 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id 59ABF1A00EC for ; Tue, 4 Feb 2014 06:18: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 720B737C1B2; Tue, 4 Feb 2014 15:18:19 +0100 (CET) Date: Tue, 04 Feb 2014 15:18:19 +0100 (CET) Message-Id: <20140204.151819.253563509746634457.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: <749A7AF5-9CED-484F-AC90-677CE4ED3EF2@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] charter revision - please comment on charter-ietf-netmod-06-05 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2014 14:18:22 -0000 Andy Bierman wrote: > On Tue, Feb 4, 2014 at 5:48 AM, Ladislav Lhotka wrote: > > > > > On 04 Feb 2014, at 14:28, Andy Bierman wrote: > > > > > node > > > network > > > end-system > > > host > > > router > > > switch > > > > > > And it is impossible to use "when" for distinguishing between "network" > > and "end-system" because end hosts are configured with the leaf identities. > > > > > > > > > > > > The issue comes down to custom XPath work > > > > > > when "ident-leaf = 'network'"; > > > > > > The Yuma* code knows this string (network) is really a QName and not a > > string. > > > So if the when-stmt had a prefix, it would be handled correctly: > > > > > > when "ident-leaf = 'acme:network'"; > > > > But it is not about strings versus QNames! The problem is that the parent > > augment is supposed to be applied to nodes whose type is *derived* from > > network, for example "acme:router". This is where the derived-from() > > function is needed. > > > > > OK -- this seems like a very minor feature. > Originally the identyref is just for comparing the same base > identity types. The ability to compare against sub-trees in the > identity hierarchy is a new feature. No, not a new feature. identityref accepts any identity derived from the base. We got that part right. It's the corresponding XPath test we missed. /martin From andy@yumaworks.com Tue Feb 4 06:37:38 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25AD11A00EC for ; Tue, 4 Feb 2014 06:37:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vVZinb8OJ0YZ for ; Tue, 4 Feb 2014 06:37:34 -0800 (PST) Received: from mail-qa0-f45.google.com (mail-qa0-f45.google.com [209.85.216.45]) by ietfa.amsl.com (Postfix) with ESMTP id AFD8E1A00E2 for ; Tue, 4 Feb 2014 06:37:34 -0800 (PST) Received: by mail-qa0-f45.google.com with SMTP id ii20so12185418qab.18 for ; Tue, 04 Feb 2014 06:37:34 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=IU+fCTv6xjY7E4UoeI170v1ypYripHAKqkTFe4OUkJQ=; b=V0dR1I/UytfBfpJX8Y8FGVCXz+H9sIkvOUtsGQeSvBIcaNwAcItM/R6xi87a9QbhMa LwIzD5AI22YRPgsSwN3RVa+Nz28ouocqvROxxiYA6Y9qPzFH6kqiaXff8QmZ0Wuyvq3L CuoivM3MVkNeZV7950c1qRofqVCrpzQuVrBg4cVx7/7jUZt0dVcFCWwcpFpZKrWY4/wx epIr41LwklEK6I83OprgIf7hnCysIuKWiRFjXTntoj0paDdJCHeXAi2AvwHJ6EfDwtic Brr9MSyXCEIqSQw854jx3yYxBfFpXaY4IMz8zFBt34DRK1UIPXPpropP4Hm0FPi9HpHy SJTQ== X-Gm-Message-State: ALoCoQlnIXuI6+5lYfOgCWwX5+y5ctBV8+17ax8YCXM3D7UrSInM/Qq6M2DPeEpKopQO7lj9464m MIME-Version: 1.0 X-Received: by 10.224.49.69 with SMTP id u5mr34801569qaf.88.1391524654177; Tue, 04 Feb 2014 06:37:34 -0800 (PST) Received: by 10.140.48.75 with HTTP; Tue, 4 Feb 2014 06:37:34 -0800 (PST) In-Reply-To: References: <20140202135609.GA35596@elstar.local> <20140203.222129.457630286.mbj@tail-f.com> Date: Tue, 4 Feb 2014 06:37:34 -0800 Message-ID: From: Andy Bierman To: Jonathan Hansford Content-Type: multipart/alternative; boundary=001a11c2f5a8b56ffb04f19594a5 Cc: "netmod@ietf.org" Subject: Re: [netmod] charter revision - please comment on charter-ietf-netmod-06-05 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2014 14:37:38 -0000 --001a11c2f5a8b56ffb04f19594a5 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Feb 4, 2014 at 4:53 AM, Jonathan Hansford wrote: > > > On 2014-02-04 11:43, Andy Bierman wrote: > > > > > On Tue, Feb 4, 2014 at 2:19 AM, Ladislav Lhotka wrote: > >> Andy Bierman writes: >> >> > On Mon, Feb 3, 2014 at 1:21 PM, Martin Bjorklund >> wrote: >> > >> >> Juergen Schoenwaelder wrote: >> >> > Hi, >> >> > >> >> > we (the WG chairs and Benoit) have been working on a new charter for >> >> > the NETMOD working group. The current version can always be found >> >> > here. >> >> > >> >> > https://datatracker.ietf.org/doc/charter-ietf-netmod/ >> >> > >> >> > The current version is called charter-ietf-netmod-06-05 >> >> > >> >> > >> >> >> https://datatracker.ietf.org/doc/charter-ietf-netmod/withmilestones-06-05.txt >> >> > >> >> > Please review and feel invited to comment and ask questions. >> >> >> >> I think that in order to solve Y1 and Y3, we need an update to YANG. >> >> Since the proposed charter allows us to this, I guess the charter is >> >> ok. >> >> >> >> Regarding Y3 (YANG conformance), I don't think it is clear what >> >> problem we want to solve. In my experience, I have not seen the >> >> interoperability problems Andy's draft mentions. The draft raises >> >> some valid issues (e.g., hello message size explosion and if-feature >> >> with AND as only operator is too limiting), but I am not convinced >> >> that the current conformance mechanisms of YANG are not good enough. >> >> >> >> >> >> >> > I do not agree that Y3 would require an update to YANG >> > that would impact the yang "module" and "submodule" >> > constructions. None of the items in the charter proposal >> > are must-have features. IMO, service-oriented conformance >> > is better than the implied-mandatory + if-feature conformance >> > model we have now. >> > >> > I have never actually seen the "identityref conflict" problem that >> > the xpath functions need to address. Sure it is possible that >> > a server will have 2 modules, each with the same named >> > identity, each with the same base type, but I have never seen it >> actually >> > done. >> > >> > There are several known issues with YANG that actually impact usage, >> > and more XPath functions are fairly low on the list. We are not helping >> > anyone by introducing a new YANG version with 1 of 10 known bugs fixed. >> > Might as well fix all 10 if we bother with a YANG 1.1 release at all. >> > >> > IMO there are better things to work on, but a new YANG version just >> > to introduce a few XPath functions would be net harmful to >> interoperability >> >> I don't agree. There are other things in the 1.1 todo list but even the >> XPath functions are a good-enough reason. The main problem IMO are >> identities because currently they are essentially usable only if they are >> flat, i.e. a base identity and identities derived directly form it, and >> nothing else. >> >> For example, in a real Ethernet module that is modelled after Appendix A >> in the interfaces I-D, the condition >> >> when "if:type = 'ianaift:ethernetCsmacd'"; >> >> won't work for Ethernet interfaces whose type is *derived* from >> ethernetCsmacd. >> >> Combined with the limited extensibility of enumerations, this is a >> serious problem. >> >> If it were a serious problem then we would see it showing up > in real implementations. In fact, this problem has never occurred > even once -- not in standard modules or vendor modules. > The local names have to be for the same base. If not, the tool > knows (because the leaf includes the base identity type). > In theory this XPath cannot possibly work. In reality it works OK. > > For someone who is still trying to get his company to migrate to YANG > and has therefore still not had the opportunity to use it in anger, that > last sentence doesn't inspire confidence. For any who are new to > implementing YANG, being advised that something that "cannot possibly work > ... in reality works OK" just engenders a sense of uncertainty, not just > about this but whether there are other areas of YANG where uncertainty > lurks. > This is the conflict: module A { identity foo-base; identity foo1 { base foo-base; } } module B { import A { prefix a; ] identify foo1 { base a:foo-base; } } module C { import A { prefix a; } leaf ident-leaf { type identityref { base a:foo-base; } } leaf X { when "../ident-leaf = 'foo1'"; type string; } My previous point is the the duplication (e.g. foo1 in 2 modules) is extremely rare. When the ident-leaf is referenced in XPath, it is a string, not a QName. If the server advertises A, B, and C, then there is ambiguity for the identity "foo1". In fact the example for X is illegal because no prefix for an identityref means the local module, and module C does not define any "foo1" identity. when "../ident-leaf = 'a:foo1' or ../ident-leaf = 'b:foo1'"; This is not OK because it requires the XPath parser to know these strings are really identity values. Lada >> >> > >> > >> > /martin >> >> >> >> >> > Andy > > Andy > > > Andy --001a11c2f5a8b56ffb04f19594a5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Tue, Feb 4, 2014 at 4:53 AM, Jonathan Hansford <Jonathan@h= ansfords.net> wrote:

=A0

On 2014-02-04 11:43, Andy Bierman wrote:




On Tue, Feb 4, 2014 at 2:19 AM, Ladislav Lhotka = <lhotka@nic.cz<= /a>> wrote:
Andy Bierman <andy@yumaworks.com> writes:

> On Mon, Feb 3, 2014 at 1:21 PM, Martin Bjorklund <mbj@tail-f.com> wrote:
&= gt;
>> Juergen Schoenwaelder <j.schoenwaelder@jacobs-university= .de> wrote:
>> > Hi,
>> >
>> > we (the WG chairs an= d Benoit) have been working on a new charter for
>> > the NETM= OD working group. The current version can always be found
>> >= here.
>> >
>> > =A0 https://datatracker.ietf.org/= doc/charter-ietf-netmod/
>> >
>> > The curren= t version is called charter-ietf-netmod-06-05
>> >
>> >
>> https://datatracker.ietf.org/doc/charter-ietf-netmod/withmilestones-06-= 05.txt
>> >
>> > Please review and feel invited to comment = and ask questions.
>>
>> I think that in order to solve= Y1 and Y3, we need an update to YANG.
>> Since the proposed char= ter allows us to this, I guess the charter is
>> ok.
>>
>> Regarding Y3 (YANG conformance), I = don't think it is clear what
>> problem we want to solve. =A0= In my experience, I have not seen the
>> interoperability problem= s Andy's draft mentions. =A0The draft raises
>> some valid issues (e.g., hello message size explosion and if-feat= ure
>> with AND as only operator is too limiting), but I am not c= onvinced
>> that the current conformance mechanisms of YANG are n= ot good enough.
>>
>>
>>
> I do not agree that Y3 would r= equire an update to YANG
> that would impact the yang "module&q= uot; and "submodule"
> constructions. =A0None of the items= in the charter proposal
> are must-have features. =A0IMO, service-oriented conformance
>= is better than the implied-mandatory + if-feature conformance
> mod= el we have now.
>
> I have never actually seen the "iden= tityref conflict" problem that
> the xpath functions need to address. Sure it is possible that
>= ; a server will have 2 modules, each with the same named
> identity,= each with the same base type, but I have never seen it actually
> d= one.
>
> There are several known issues with YANG that actually impac= t usage,
> and more XPath functions are fairly low on the list. =A0W= e are not helping
> anyone by introducing a new YANG version with 1 = of 10 known bugs fixed.
> Might as well fix all 10 if we bother with a YANG 1.1 release at all.=
>
> IMO there are better things to work on, but a new YANG v= ersion just
> to introduce a few XPath functions would be net harmfu= l to interoperability

I don't agree. There are other things in the 1.1 todo list but eve= n the XPath functions are a good-enough reason. The main problem IMO are id= entities because currently they are essentially usable only if they are fla= t, i.e. a base identity and identities derived directly form it, and nothin= g else.

For example, in a real Ethernet module that is modelled after Appendix= =A0A in the interfaces I-D, the condition

when "if:type =3D &#= 39;ianaift:ethernetCsmacd'";

won't work for Ethernet i= nterfaces whose type is *derived* from ethernetCsmacd.

Combined with the limited extensibility of enumerations, this is a ser= ious problem.

If it were a serious problem then we would see it showing up
in real implementations. =A0In fact, this problem has never occurred
even once -- not in standard modules or vendor modules.
The local names have to be for the same base. =A0If not, the tool
knows (because the leaf includes the base identity type).
In theory this XPath cannot possibly work. =A0In reality it works OK.<= /div>
For someone who is still trying to get his company to migrate to YANG = and has therefore still not had the opportunity to use it in anger, that la= st sentence doesn't inspire confidence. For any who are new to implemen= ting YANG, being advised that something that "cannot possibly work ...= in reality works OK" just engenders a sense of uncertainty, not just = about this but whether there are other areas of YANG where uncertainty lurk= s.


Thi= s is the conflict:

module A {
=A0 identi= ty foo-base;
=A0 identity foo1 {
=A0 =A0 base foo-base;=
=A0 }
}

module B {
=A0 = =A0import A { prefix a; ]
=A0 =A0identify foo1 { base a:foo-base;= }
}

module C {
=A0 import A {= prefix a; }
=A0 leaf ident-leaf {
=A0 =A0 =A0type identityref { base a:f= oo-base; }
=A0 }
=A0 leaf X {
=A0 =A0 =A0when= "../ident-leaf =3D 'foo1'";
=A0 =A0 =A0type st= ring;
}


My previous point is the the duplic= ation (e.g. foo1 in 2 modules) is extremely
rare.

When the ident-leaf is referenced in XPath, it is a string,= not a QName.
If the server advertises A, B, and C, then there is ambiguity for
the identity "foo1". =A0In fact the example for X is illega= l because
no prefix for an identityref means the local module, an= d module C
does not define any "foo1" identity.

=A0 =A0when "../ident-leaf =3D 'a:foo1' or ../ident-leaf =3D= 'b:foo1'";

This is not OK because it= requires the XPath parser to know
these strings are really identity values.

Lada

>
>
> /martin
>> >>
> Andy
Andy


Andy
=A0
--001a11c2f5a8b56ffb04f19594a5-- From lhotka@nic.cz Tue Feb 4 06:39:42 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A3241A00E2 for ; Tue, 4 Feb 2014 06:39:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.886 X-Spam-Level: X-Spam-Status: No, score=-0.886 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.535] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U9009uBc9e5R for ; Tue, 4 Feb 2014 06:39:41 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id DD3D21A0100 for ; Tue, 4 Feb 2014 06:39:40 -0800 (PST) Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 0B69313F721; Tue, 4 Feb 2014 15:39:39 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1391524780; bh=NhHBNdWmB3CDCQKJ61d4W8wwfC6Oi/3y+vaGZi7XZQM=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=nQEqZh1vWI6HHD3e4HsrFKr0Uq05KJNxRcGHkkHbeFSgkUskx1zZ3IjucGr7b/HXR rFV5TiH9dXalpCRtpzwj8djYy68zOjcsMlr2PS7b1kRSCxz/ory8RCmdTyoc9ry3B3 QUqrKdtSP+SeP/eFQRBrTt1l1QXb95yfJyUlSarc= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Ladislav Lhotka In-Reply-To: <20140204.151819.253563509746634457.mbj@tail-f.com> Date: Tue, 4 Feb 2014 15:39:39 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <749A7AF5-9CED-484F-AC90-677CE4ED3EF2@nic.cz> <20140204.151819.253563509746634457.mbj@tail-f.com> To: =?windows-1252?Q?Martin_Bj=F6rklund?= X-Mailer: Apple Mail (2.1827) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] charter revision - please comment on charter-ietf-netmod-06-05 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2014 14:39:42 -0000 On 04 Feb 2014, at 15:18, Martin Bjorklund wrote: > Andy Bierman wrote: >> On Tue, Feb 4, 2014 at 5:48 AM, Ladislav Lhotka = wrote: >>=20 >>>=20 >>> On 04 Feb 2014, at 14:28, Andy Bierman wrote: >>>=20 >>>> node >>>> network >>>> end-system >>>> host >>>> router >>>> switch >>>>=20 >>>> And it is impossible to use "when" for distinguishing between = "network" >>> and "end-system" because end hosts are configured with the leaf = identities. >>>>=20 >>>>=20 >>>>=20 >>>> The issue comes down to custom XPath work >>>>=20 >>>> when "ident-leaf =3D 'network'"; >>>>=20 >>>> The Yuma* code knows this string (network) is really a QName and = not a >>> string. >>>> So if the when-stmt had a prefix, it would be handled correctly: >>>>=20 >>>> when "ident-leaf =3D 'acme:network'"; >>>=20 >>> But it is not about strings versus QNames! The problem is that the = parent >>> augment is supposed to be applied to nodes whose type is *derived* = from >>> network, for example "acme:router". This is where the derived-from() >>> function is needed. >>>=20 >>>=20 >> OK -- this seems like a very minor feature. >> Originally the identyref is just for comparing the same base >> identity types. The ability to compare against sub-trees in the >> identity hierarchy is a new feature. >=20 > No, not a new feature. identityref accepts any identity derived from > the base. We got that part right. It's the corresponding XPath test > we missed. Yes. If I remember correctly, identities were introduced at the Herndon = interim meeting back in 2008, and haven=92t changed in any way since = then. Lada >=20 >=20 > /martin -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From lhotka@nic.cz Tue Feb 4 06:53:06 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E0C81A00EC for ; Tue, 4 Feb 2014 06:53:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.186 X-Spam-Level: X-Spam-Status: No, score=-1.186 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RP_MATCHES_RCVD=-0.535] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WxhqKpxP5ArU for ; Tue, 4 Feb 2014 06:53:04 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 5DB4E1A00EE for ; Tue, 4 Feb 2014 06:53:04 -0800 (PST) Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 2DADA13F721; Tue, 4 Feb 2014 15:53:03 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1391525583; bh=J/ME15ttNGVyNrE1KTXndNmGUSFT1d4mBL6QbhFevT0=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=QIqUfkzbEUN/818fBCwdwAeWUWJgWK9dbU9N/QDwKYJBp6a7dN1JlsBHJMNuWgYr8 OnyJDfS7pMRWCzYpx8oYISWw3AA/KiiPHae+lMZAcalxa143BJHkZXAH0EdhnZcGo8 RZGMqvpGDziOvxuc8Obxoq6N3qHJQ059clz/dI4M= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Ladislav Lhotka In-Reply-To: Date: Tue, 4 Feb 2014 15:53:02 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <47ACB5CD-E8C8-471E-B6FA-1C1A9E331ECC@nic.cz> References: <20140202135609.GA35596@elstar.local> <20140203.222129.457630286.mbj@tail-f.com> To: Andy Bierman X-Mailer: Apple Mail (2.1827) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Cc: "netmod@ietf.org" Subject: Re: [netmod] charter revision - please comment on charter-ietf-netmod-06-05 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2014 14:53:06 -0000 On 04 Feb 2014, at 15:37, Andy Bierman wrote: >=20 >=20 >=20 > On Tue, Feb 4, 2014 at 4:53 AM, Jonathan Hansford = wrote: > =20 > On 2014-02-04 11:43, Andy Bierman wrote: >=20 >>=20 >>=20 >>=20 >> On Tue, Feb 4, 2014 at 2:19 AM, Ladislav Lhotka = wrote: >> Andy Bierman writes: >>=20 >> > On Mon, Feb 3, 2014 at 1:21 PM, Martin Bjorklund = wrote: >> > >> >> Juergen Schoenwaelder = wrote: >> >> > Hi, >> >> > >> >> > we (the WG chairs and Benoit) have been working on a new charter = for >> >> > the NETMOD working group. The current version can always be = found >> >> > here. >> >> > >> >> > https://datatracker.ietf.org/doc/charter-ietf-netmod/ >> >> > >> >> > The current version is called charter-ietf-netmod-06-05 >> >> > >> >> > >> >> = https://datatracker.ietf.org/doc/charter-ietf-netmod/withmilestones-06-05.= txt >> >> > >> >> > Please review and feel invited to comment and ask questions. >> >> >> >> I think that in order to solve Y1 and Y3, we need an update to = YANG. >> >> Since the proposed charter allows us to this, I guess the charter = is >> >> ok. >> >> >> >> Regarding Y3 (YANG conformance), I don't think it is clear what >> >> problem we want to solve. In my experience, I have not seen the >> >> interoperability problems Andy's draft mentions. The draft raises >> >> some valid issues (e.g., hello message size explosion and = if-feature >> >> with AND as only operator is too limiting), but I am not convinced >> >> that the current conformance mechanisms of YANG are not good = enough. >> >> >> >> >> >> >> > I do not agree that Y3 would require an update to YANG >> > that would impact the yang "module" and "submodule" >> > constructions. None of the items in the charter proposal >> > are must-have features. IMO, service-oriented conformance >> > is better than the implied-mandatory + if-feature conformance >> > model we have now. >> > >> > I have never actually seen the "identityref conflict" problem that >> > the xpath functions need to address. Sure it is possible that >> > a server will have 2 modules, each with the same named >> > identity, each with the same base type, but I have never seen it = actually >> > done. >> > >> > There are several known issues with YANG that actually impact = usage, >> > and more XPath functions are fairly low on the list. We are not = helping >> > anyone by introducing a new YANG version with 1 of 10 known bugs = fixed. >> > Might as well fix all 10 if we bother with a YANG 1.1 release at = all. >> > >> > IMO there are better things to work on, but a new YANG version just >> > to introduce a few XPath functions would be net harmful to = interoperability >>=20 >> I don't agree. There are other things in the 1.1 todo list but even = the XPath functions are a good-enough reason. The main problem IMO are = identities because currently they are essentially usable only if they = are flat, i.e. a base identity and identities derived directly form it, = and nothing else. >>=20 >> For example, in a real Ethernet module that is modelled after = Appendix A in the interfaces I-D, the condition >>=20 >> when "if:type =3D 'ianaift:ethernetCsmacd'"; >>=20 >> won't work for Ethernet interfaces whose type is *derived* from = ethernetCsmacd. >>=20 >> Combined with the limited extensibility of enumerations, this is a = serious problem. >>=20 >> If it were a serious problem then we would see it showing up >> in real implementations. In fact, this problem has never occurred >> even once -- not in standard modules or vendor modules. >> The local names have to be for the same base. If not, the tool >> knows (because the leaf includes the base identity type). >> In theory this XPath cannot possibly work. In reality it works OK. > For someone who is still trying to get his company to migrate to YANG = and has therefore still not had the opportunity to use it in anger, that = last sentence doesn't inspire confidence. For any who are new to = implementing YANG, being advised that something that "cannot possibly = work ... in reality works OK" just engenders a sense of uncertainty, not = just about this but whether there are other areas of YANG where = uncertainty lurks. >=20 >=20 > This is the conflict: >=20 > module A { > identity foo-base; > identity foo1 { > base foo-base; > } > } >=20 > module B { > import A { prefix a; ] > identify foo1 { base a:foo-base; } > } >=20 > module C { > import A { prefix a; } > leaf ident-leaf { > type identityref { base a:foo-base; } > } > leaf X { > when "../ident-leaf =3D 'foo1'"; > type string; > } >=20 >=20 > My previous point is the the duplication (e.g. foo1 in 2 modules) is = extremely > rare. >=20 > When the ident-leaf is referenced in XPath, it is a string, not a = QName. > If the server advertises A, B, and C, then there is ambiguity for > the identity "foo1". In fact the example for X is illegal because > no prefix for an identityref means the local module, and module C > does not define any "foo1" identity. >=20 > when "../ident-leaf =3D 'a:foo1' or ../ident-leaf =3D 'b:foo1'"; >=20 > This is not OK because it requires the XPath parser to know > these strings are really identity values. A standard XPath processor cannot know it by definition. And this is = still only a part of the story - I think the use of identityrefs in = =93when=94 expressions is only possible if both identities-as-qnames and = the derivation relation are properly supported.=20 Lada >=20 >=20 >> Lada >>=20 >> > >> > >> > /martin >> >> >> >> >> > Andy >> Andy >=20 >=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 Feb 4 07:28:02 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A27781A010A for ; Tue, 4 Feb 2014 07:28:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jfM8mihIp6P0 for ; Tue, 4 Feb 2014 07:27:58 -0800 (PST) Received: from mail-qa0-f53.google.com (mail-qa0-f53.google.com [209.85.216.53]) by ietfa.amsl.com (Postfix) with ESMTP id 817B61A00E4 for ; Tue, 4 Feb 2014 07:27:58 -0800 (PST) Received: by mail-qa0-f53.google.com with SMTP id cm18so12151665qab.26 for ; Tue, 04 Feb 2014 07:27:58 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=1sWOLsfJOaGOzqjcyDxlQ3TYifaf/XhVH8nQdcKKy/M=; b=HDGMiOna6iV2pXftmSsafsYuWVcDQkAhA+iYkdHiV84g2A/GQ48yifqev3DFdaG/hr uOx94d2RqZSiImCH+rrDMAEF3z/Zo5RkEYC/ePcdx2jLTq4BjTFqL0eCOupt+IADhv9D lEDRlAlAiFpmwn/lrTgqK47xYWog3hM0CzK5hxWHwpt/3WIy7d4kw9SrDxl4jplL8Vy7 BEbP3m7IbPAiw8C3S0R3pDVE8ebd9aHnL2zbjQCIcTTArt/GCRl2bvHNZWAT0Xszx3Fc O5gvbgKP1TaRw/63majuT1BrUNdcVSI54h2VelEwbn1OI0zyUQqHx6K7jXSSmlVDOc67 HcUg== X-Gm-Message-State: ALoCoQm9iBiUJB/SkOEJTeUKXXcGW6MUKKM6X91z3KWEd4ijLzQ2M4xPrqslWV06QUpx93YfqmD5 MIME-Version: 1.0 X-Received: by 10.140.87.9 with SMTP id q9mr23909031qgd.94.1391527678053; Tue, 04 Feb 2014 07:27:58 -0800 (PST) Received: by 10.140.48.75 with HTTP; Tue, 4 Feb 2014 07:27:57 -0800 (PST) In-Reply-To: <47ACB5CD-E8C8-471E-B6FA-1C1A9E331ECC@nic.cz> References: <20140202135609.GA35596@elstar.local> <20140203.222129.457630286.mbj@tail-f.com> <47ACB5CD-E8C8-471E-B6FA-1C1A9E331ECC@nic.cz> Date: Tue, 4 Feb 2014 07:27:57 -0800 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=001a113a359cf2218404f19648c5 Cc: "netmod@ietf.org" Subject: Re: [netmod] charter revision - please comment on charter-ietf-netmod-06-05 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2014 15:28:02 -0000 --001a113a359cf2218404f19648c5 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Feb 4, 2014 at 6:53 AM, Ladislav Lhotka wrote: > > On 04 Feb 2014, at 15:37, Andy Bierman wrote: > > > > > > > > > On Tue, Feb 4, 2014 at 4:53 AM, Jonathan Hansford < > Jonathan@hansfords.net> wrote: > > > > On 2014-02-04 11:43, Andy Bierman wrote: > > > >> > >> > >> > >> On Tue, Feb 4, 2014 at 2:19 AM, Ladislav Lhotka wrote: > >> Andy Bierman writes: > >> > >> > On Mon, Feb 3, 2014 at 1:21 PM, Martin Bjorklund > wrote: > >> > > >> >> Juergen Schoenwaelder wrote: > >> >> > Hi, > >> >> > > >> >> > we (the WG chairs and Benoit) have been working on a new charter > for > >> >> > the NETMOD working group. The current version can always be found > >> >> > here. > >> >> > > >> >> > https://datatracker.ietf.org/doc/charter-ietf-netmod/ > >> >> > > >> >> > The current version is called charter-ietf-netmod-06-05 > >> >> > > >> >> > > >> >> > https://datatracker.ietf.org/doc/charter-ietf-netmod/withmilestones-06-05.txt > >> >> > > >> >> > Please review and feel invited to comment and ask questions. > >> >> > >> >> I think that in order to solve Y1 and Y3, we need an update to YANG. > >> >> Since the proposed charter allows us to this, I guess the charter is > >> >> ok. > >> >> > >> >> Regarding Y3 (YANG conformance), I don't think it is clear what > >> >> problem we want to solve. In my experience, I have not seen the > >> >> interoperability problems Andy's draft mentions. The draft raises > >> >> some valid issues (e.g., hello message size explosion and if-feature > >> >> with AND as only operator is too limiting), but I am not convinced > >> >> that the current conformance mechanisms of YANG are not good enough. > >> >> > >> >> > >> >> > >> > I do not agree that Y3 would require an update to YANG > >> > that would impact the yang "module" and "submodule" > >> > constructions. None of the items in the charter proposal > >> > are must-have features. IMO, service-oriented conformance > >> > is better than the implied-mandatory + if-feature conformance > >> > model we have now. > >> > > >> > I have never actually seen the "identityref conflict" problem that > >> > the xpath functions need to address. Sure it is possible that > >> > a server will have 2 modules, each with the same named > >> > identity, each with the same base type, but I have never seen it > actually > >> > done. > >> > > >> > There are several known issues with YANG that actually impact usage, > >> > and more XPath functions are fairly low on the list. We are not > helping > >> > anyone by introducing a new YANG version with 1 of 10 known bugs > fixed. > >> > Might as well fix all 10 if we bother with a YANG 1.1 release at all. > >> > > >> > IMO there are better things to work on, but a new YANG version just > >> > to introduce a few XPath functions would be net harmful to > interoperability > >> > >> I don't agree. There are other things in the 1.1 todo list but even the > XPath functions are a good-enough reason. The main problem IMO are > identities because currently they are essentially usable only if they are > flat, i.e. a base identity and identities derived directly form it, and > nothing else. > >> > >> For example, in a real Ethernet module that is modelled after Appendix > A in the interfaces I-D, the condition > >> > >> when "if:type = 'ianaift:ethernetCsmacd'"; > >> > >> won't work for Ethernet interfaces whose type is *derived* from > ethernetCsmacd. > >> > >> Combined with the limited extensibility of enumerations, this is a > serious problem. > >> > >> If it were a serious problem then we would see it showing up > >> in real implementations. In fact, this problem has never occurred > >> even once -- not in standard modules or vendor modules. > >> The local names have to be for the same base. If not, the tool > >> knows (because the leaf includes the base identity type). > >> In theory this XPath cannot possibly work. In reality it works OK. > > For someone who is still trying to get his company to migrate to YANG > and has therefore still not had the opportunity to use it in anger, that > last sentence doesn't inspire confidence. For any who are new to > implementing YANG, being advised that something that "cannot possibly work > ... in reality works OK" just engenders a sense of uncertainty, not just > about this but whether there are other areas of YANG where uncertainty > lurks. > > > > > > This is the conflict: > > > > module A { > > identity foo-base; > > identity foo1 { > > base foo-base; > > } > > } > > > > module B { > > import A { prefix a; ] > > identify foo1 { base a:foo-base; } > > } > > > > module C { > > import A { prefix a; } > > leaf ident-leaf { > > type identityref { base a:foo-base; } > > } > > leaf X { > > when "../ident-leaf = 'foo1'"; > > type string; > > } > > > > > > My previous point is the the duplication (e.g. foo1 in 2 modules) is > extremely > > rare. > > > > When the ident-leaf is referenced in XPath, it is a string, not a QName. > > If the server advertises A, B, and C, then there is ambiguity for > > the identity "foo1". In fact the example for X is illegal because > > no prefix for an identityref means the local module, and module C > > does not define any "foo1" identity. > > > > when "../ident-leaf = 'a:foo1' or ../ident-leaf = 'b:foo1'"; > > > > This is not OK because it requires the XPath parser to know > > these strings are really identity values. > > A standard XPath processor cannot know it by definition. And this is still > only a part of the story - I think the use of identityrefs in "when" > expressions is only possible if both identities-as-qnames and the > derivation relation are properly supported. > > We are drifting into the implementation details. I already agreed we should do a real maintenance update so many YANG corner-cases will finally get solved. We already have our own XPath within YANG modules. We have plenty of text declaring how YANG types are treated in XPath. As Martin said, we did not decree how identityref values SHALL be handled in YANG must/when statements. This was an oversight. (Along with many others). We could decree that identityref is a special string that no XPath parser knows about or we could create a brand new XPath function no XPath parser knows about. Either way we are making rules only for YANG statements, not all XPath. This is a confusing problem because we are highjacking QNames here. There are not real nodes in any XML document for identities They are just registration OIDs. (We had the same problem in SNMP trying to mix the 2). Lada > > Andy --001a113a359cf2218404f19648c5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Tue, Feb 4, 2014 at 6:53 AM, Ladislav Lhotka &= lt;lhotka@nic.cz>= wrote:

On 04 Feb 2014, at 15:37, Andy Bierman <andy@yumaworks.com> wrote:

>
>
>
> On Tue, Feb 4, 2014 at 4:53 AM, Jonathan Hansford <Jonathan@hansfords.net> wrote:
>
> On 2014-02-04 11:43, Andy Bierman wrote:
>
>>
>>
>>
>> On Tue, Feb 4, 2014 at 2:19 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
>> Andy Bierman <andy@yumawo= rks.com> writes:
>>
>> > On Mon, Feb 3, 2014 at 1:21 PM, Martin Bjorklund <mbj@tail-f.com> wrote:
>> >
>> >> Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote= :
>> >> > Hi,
>> >> >
>> >> > we (the WG chairs and Benoit) have been working on a= new charter for
>> >> > the NETMOD working group. The current version can al= ways be found
>> >> > here.
>> >> >
>> >> >   https://datatracker.ietf.org/doc/cha= rter-ietf-netmod/
>> >> >
>> >> > The current version is called charter-ietf-netmod-06= -05
>> >> >
>> >> >
>> >> https://datatracker.ietf= .org/doc/charter-ietf-netmod/withmilestones-06-05.txt
>> >> >
>> >> > Please review and feel invited to comment and ask qu= estions.
>> >>
>> >> I think that in order to solve Y1 and Y3, we need an upda= te to YANG.
>> >> Since the proposed charter allows us to this, I guess the= charter is
>> >> ok.
>> >>
>> >> Regarding Y3 (YANG conformance), I don't think it is = clear what
>> >> problem we want to solve.  In my experience, I have = not seen the
>> >> interoperability problems Andy's draft mentions. &nbs= p;The draft raises
>> >> some valid issues (e.g., hello message size explosion and= if-feature
>> >> with AND as only operator is too limiting), but I am not = convinced
>> >> that the current conformance mechanisms of YANG are not g= ood enough.
>> >>
>> >>
>> >>
>> > I do not agree that Y3 would require an update to YANG
>> > that would impact the yang "module" and "submo= dule"
>> > constructions.  None of the items in the charter proposa= l
>> > are must-have features.  IMO, service-oriented conforman= ce
>> > is better than the implied-mandatory + if-feature conformance=
>> > model we have now.
>> >
>> > I have never actually seen the "identityref conflict&quo= t; problem that
>> > the xpath functions need to address. Sure it is possible that=
>> > a server will have 2 modules, each with the same named
>> > identity, each with the same base type, but I have never seen= it actually
>> > done.
>> >
>> > There are several known issues with YANG that actually impact= usage,
>> > and more XPath functions are fairly low on the list.  We= are not helping
>> > anyone by introducing a new YANG version with 1 of 10 known b= ugs fixed.
>> > Might as well fix all 10 if we bother with a YANG 1.1 release= at all.
>> >
>> > IMO there are better things to work on, but a new YANG versio= n just
>> > to introduce a few XPath functions would be net harmful to in= teroperability
>>
>> I don't agree. There are other things in the 1.1 todo list but= even the XPath functions are a good-enough reason. The main problem IMO ar= e identities because currently they are essentially usable only if they are= flat, i.e. a base identity and identities derived directly form it, and no= thing else.
>>
>> For example, in a real Ethernet module that is modelled after Appe= ndix A in the interfaces I-D, the condition
>>
>> when "if:type =3D 'ianaift:ethernetCsmacd'";
>>
>> won't work for Ethernet interfaces whose type is *derived* fro= m ethernetCsmacd.
>>
>> Combined with the limited extensibility of enumerations, this is a= serious problem.
>>
>> If it were a serious problem then we would see it showing up
>> in real implementations.  In fact, this problem has never occ= urred
>> even once -- not in standard modules or vendor modules.
>> The local names have to be for the same base.  If not, the to= ol
>> knows (because the leaf includes the base identity type).
>> In theory this XPath cannot possibly work.  In reality it wor= ks OK.
> For someone who is still trying to get his company to migrate to YANG = and has therefore still not had the opportunity to use it in anger, that la= st sentence doesn't inspire confidence. For any who are new to implemen= ting YANG, being advised that something that "cannot possibly work ...= in reality works OK" just engenders a sense of uncertainty, not just = about this but whether there are other areas of YANG where uncertainty lurk= s.
>
>
> This is the conflict:
>
> module A {
>   identity foo-base;
>   identity foo1 {
>     base foo-base;
>   }
> }
>
> module B {
>    import A { prefix a; ]
>    identify foo1 { base a:foo-base; }
> }
>
> module C {
>   import A { prefix a; }
>   leaf ident-leaf {
>      type identityref { base a:foo-base; }
>   }
>   leaf X {
>      when "../ident-leaf =3D 'foo1'";=
>      type string;
> }
>
>
> My previous point is the the duplication (e.g. foo1 in 2 modules) is e= xtremely
> rare.
>
> When the ident-leaf is referenced in XPath, it is a string, not a QNam= e.
> If the server advertises A, B, and C, then there is ambiguity for
> the identity "foo1".  In fact the example for X is ille= gal because
> no prefix for an identityref means the local module, and module C
> does not define any "foo1" identity.
>
>    when "../ident-leaf =3D 'a:foo1' or ../ident= -leaf =3D 'b:foo1'";
>
> This is not OK because it requires the XPath parser to know
> these strings are really identity values.

A standard XPath processor cannot know it by definition. And this is still = only a part of the story - I think the use of identityrefs in “when&r= dquo; expressions is only possible if both identities-as-qnames and the der= ivation relation are properly supported.


We are drifting into the implementatio= n details.
I already agreed we should do a real maintenance updat= e
so many YANG corner-cases will finally get solved.

We already have our own XPath within YANG modules.
We have plenty of text declaring how YANG types are treated
in X= Path.  As Martin said, we did not decree how identityref
val= ues SHALL be handled in YANG must/when statements.
This was an oversight. (Along with many others).

<= div>We could decree that identityref is a special string that no
= XPath parser knows about or we could create a brand new
XPath fun= ction no XPath parser knows about.  Either way we
are making rules only for YANG statements, not all XPath.
This is a confusing problem because we are highjacking QNames<= /div>
here. There are not real nodes in any XML document for identities=
They are just registration OIDs.  (We had the same problem in
SNMP trying to mix the 2).


<= br>
Lada


Andy
 
--001a113a359cf2218404f19648c5-- From lhotka@nic.cz Tue Feb 4 08:07:37 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4D4C1A011C for ; Tue, 4 Feb 2014 08:07:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.186 X-Spam-Level: X-Spam-Status: No, score=-1.186 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RP_MATCHES_RCVD=-0.535] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s7M5K6AoNGCp for ; Tue, 4 Feb 2014 08:07:35 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 33D091A0100 for ; Tue, 4 Feb 2014 08:07:35 -0800 (PST) Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 9BB6713F721; Tue, 4 Feb 2014 17:07:33 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1391530053; bh=4RX9+9qbuO6nQLBP19M859XkuPN5Rg4chagoci3mUsI=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=qj+Z6JhsSHydwofS+xKwwybI/jZagRo1ch8AF0UPzeVSDrBRRyDs0ukA3eg80QOpQ oQAQdUvPfoXU1Cli0eBMQbFDn1tRmgBk4FkkxWFj6tstNMKsnLSV9WLDlznySeHrDw bmj4l0UNiO3jG3f40fYoSf5Y4Zkl4pvVeLA1BhMA= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Ladislav Lhotka In-Reply-To: Date: Tue, 4 Feb 2014 17:07:32 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <7FA7433D-04AB-4356-A2BA-1A5847FED096@nic.cz> References: <20140202135609.GA35596@elstar.local> <20140203.222129.457630286.mbj@tail-f.com> <47ACB5CD-E8C8-471E-B6FA-1C1A9E331ECC@nic.cz> To: Andy Bierman X-Mailer: Apple Mail (2.1827) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Cc: "netmod@ietf.org" Subject: Re: [netmod] charter revision - please comment on charter-ietf-netmod-06-05 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2014 16:07:38 -0000 On 04 Feb 2014, at 16:27, Andy Bierman wrote: >=20 >=20 >=20 > On Tue, Feb 4, 2014 at 6:53 AM, Ladislav Lhotka wrote: >=20 > On 04 Feb 2014, at 15:37, Andy Bierman wrote: >=20 > > > > > > > > On Tue, Feb 4, 2014 at 4:53 AM, Jonathan Hansford = wrote: > > > > On 2014-02-04 11:43, Andy Bierman wrote: > > > >> > >> > >> > >> On Tue, Feb 4, 2014 at 2:19 AM, Ladislav Lhotka = wrote: > >> Andy Bierman writes: > >> > >> > On Mon, Feb 3, 2014 at 1:21 PM, Martin Bjorklund = wrote: > >> > > >> >> Juergen Schoenwaelder = wrote: > >> >> > Hi, > >> >> > > >> >> > we (the WG chairs and Benoit) have been working on a new = charter for > >> >> > the NETMOD working group. The current version can always be = found > >> >> > here. > >> >> > > >> >> > https://datatracker.ietf.org/doc/charter-ietf-netmod/ > >> >> > > >> >> > The current version is called charter-ietf-netmod-06-05 > >> >> > > >> >> > > >> >> = https://datatracker.ietf.org/doc/charter-ietf-netmod/withmilestones-06-05.= txt > >> >> > > >> >> > Please review and feel invited to comment and ask questions. > >> >> > >> >> I think that in order to solve Y1 and Y3, we need an update to = YANG. > >> >> Since the proposed charter allows us to this, I guess the = charter is > >> >> ok. > >> >> > >> >> Regarding Y3 (YANG conformance), I don't think it is clear what > >> >> problem we want to solve. In my experience, I have not seen the > >> >> interoperability problems Andy's draft mentions. The draft = raises > >> >> some valid issues (e.g., hello message size explosion and = if-feature > >> >> with AND as only operator is too limiting), but I am not = convinced > >> >> that the current conformance mechanisms of YANG are not good = enough. > >> >> > >> >> > >> >> > >> > I do not agree that Y3 would require an update to YANG > >> > that would impact the yang "module" and "submodule" > >> > constructions. None of the items in the charter proposal > >> > are must-have features. IMO, service-oriented conformance > >> > is better than the implied-mandatory + if-feature conformance > >> > model we have now. > >> > > >> > I have never actually seen the "identityref conflict" problem = that > >> > the xpath functions need to address. Sure it is possible that > >> > a server will have 2 modules, each with the same named > >> > identity, each with the same base type, but I have never seen it = actually > >> > done. > >> > > >> > There are several known issues with YANG that actually impact = usage, > >> > and more XPath functions are fairly low on the list. We are not = helping > >> > anyone by introducing a new YANG version with 1 of 10 known bugs = fixed. > >> > Might as well fix all 10 if we bother with a YANG 1.1 release at = all. > >> > > >> > IMO there are better things to work on, but a new YANG version = just > >> > to introduce a few XPath functions would be net harmful to = interoperability > >> > >> I don't agree. There are other things in the 1.1 todo list but even = the XPath functions are a good-enough reason. The main problem IMO are = identities because currently they are essentially usable only if they = are flat, i.e. a base identity and identities derived directly form it, = and nothing else. > >> > >> For example, in a real Ethernet module that is modelled after = Appendix A in the interfaces I-D, the condition > >> > >> when "if:type =3D 'ianaift:ethernetCsmacd'"; > >> > >> won't work for Ethernet interfaces whose type is *derived* from = ethernetCsmacd. > >> > >> Combined with the limited extensibility of enumerations, this is a = serious problem. > >> > >> If it were a serious problem then we would see it showing up > >> in real implementations. In fact, this problem has never occurred > >> even once -- not in standard modules or vendor modules. > >> The local names have to be for the same base. If not, the tool > >> knows (because the leaf includes the base identity type). > >> In theory this XPath cannot possibly work. In reality it works OK. > > For someone who is still trying to get his company to migrate to = YANG and has therefore still not had the opportunity to use it in anger, = that last sentence doesn't inspire confidence. For any who are new to = implementing YANG, being advised that something that "cannot possibly = work ... in reality works OK" just engenders a sense of uncertainty, not = just about this but whether there are other areas of YANG where = uncertainty lurks. > > > > > > This is the conflict: > > > > module A { > > identity foo-base; > > identity foo1 { > > base foo-base; > > } > > } > > > > module B { > > import A { prefix a; ] > > identify foo1 { base a:foo-base; } > > } > > > > module C { > > import A { prefix a; } > > leaf ident-leaf { > > type identityref { base a:foo-base; } > > } > > leaf X { > > when "../ident-leaf =3D 'foo1'"; > > type string; > > } > > > > > > My previous point is the the duplication (e.g. foo1 in 2 modules) is = extremely > > rare. > > > > When the ident-leaf is referenced in XPath, it is a string, not a = QName. > > If the server advertises A, B, and C, then there is ambiguity for > > the identity "foo1". In fact the example for X is illegal because > > no prefix for an identityref means the local module, and module C > > does not define any "foo1" identity. > > > > when "../ident-leaf =3D 'a:foo1' or ../ident-leaf =3D 'b:foo1'"; > > > > This is not OK because it requires the XPath parser to know > > these strings are really identity values. >=20 > A standard XPath processor cannot know it by definition. And this is = still only a part of the story - I think the use of identityrefs in = =93when=94 expressions is only possible if both identities-as-qnames and = the derivation relation are properly supported. >=20 >=20 > We are drifting into the implementation details. > I already agreed we should do a real maintenance update > so many YANG corner-cases will finally get solved. >=20 > We already have our own XPath within YANG modules. > We have plenty of text declaring how YANG types are treated > in XPath. As Martin said, we did not decree how identityref Plenty? I am aware of three things: 1. The default namespace a la XPath 2.0 (sec. 6.4.1), 2. XPath comparisons are done on the canonical form (sec. 7.5.3), 3. The current() function. Other than that, it should be standard XPath 1.0. > values SHALL be handled in YANG must/when statements. > This was an oversight. (Along with many others). >=20 > We could decree that identityref is a special string that no > XPath parser knows about or we could create a brand new > XPath function no XPath parser knows about. Either way we XPath 1 spec permits the latter but not the former. And XPath/XSLT = processors can often be extended to support additional functions.=20 > are making rules only for YANG statements, not all XPath. >=20 > This is a confusing problem because we are highjacking QNames > here. There are not real nodes in any XML document for identities This is nothing unusual: http://www.w3.org/2001/tag/doc/qnameids Lada > They are just registration OIDs. (We had the same problem in > SNMP trying to mix the 2). >=20 >=20 >=20 > Lada >=20 >=20 > Andy > =20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From andy@yumaworks.com Tue Feb 4 08:46:21 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 767941A0120 for ; Tue, 4 Feb 2014 08:46:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ec-ior56wN2t for ; Tue, 4 Feb 2014 08:46:17 -0800 (PST) Received: from mail-qa0-f42.google.com (mail-qa0-f42.google.com [209.85.216.42]) by ietfa.amsl.com (Postfix) with ESMTP id DF2B01A0163 for ; Tue, 4 Feb 2014 08:46:15 -0800 (PST) Received: by mail-qa0-f42.google.com with SMTP id k4so12886015qaq.29 for ; Tue, 04 Feb 2014 08:46:15 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=5NRVBkjLtbFCVi9nEh4U34fXCzbUPvxAb5HjS5RIFZw=; b=bLQ7m1rkqwQ7ATUNH5x55PWlpATyBRUz2BwWGrDhkpHlydavEYXPqn2/gfJCBnRb43 NmqCb0JpgA8yOGE6Z2S8wTpuVzPiI9ecseEtaLxO2nEz7JDeDnobRMm5JIkqkId33M8L w/xfsXq4IAWg1w1ge8xEGPDykAoGy+wa5s9ZK4eUxGqqCpvKmKMjzYRyK5iVCeJGIcA2 yXsE5/hDtB+Nl5XuBidOIe5oos3OzLvIQXut7h5yQcQStWNDLOkY2bar9bGhV2sulFqe fTeGbE2fREDdAtn0TlvPLQW3cClaXNKIaejEmrJz1pcQESCIAAOFFyvulRKA5h6j/bmi ktJw== X-Gm-Message-State: ALoCoQkdu+mkxkXN4yR1/5bSJI7OQeA0dyuPZYvhOZGrgX+CzAwMXq6pZfo6ltqkEAzMAv6cq83m MIME-Version: 1.0 X-Received: by 10.140.85.179 with SMTP id n48mr62951039qgd.91.1391532375367; Tue, 04 Feb 2014 08:46:15 -0800 (PST) Received: by 10.140.48.75 with HTTP; Tue, 4 Feb 2014 08:46:15 -0800 (PST) In-Reply-To: <7FA7433D-04AB-4356-A2BA-1A5847FED096@nic.cz> References: <20140202135609.GA35596@elstar.local> <20140203.222129.457630286.mbj@tail-f.com> <47ACB5CD-E8C8-471E-B6FA-1C1A9E331ECC@nic.cz> <7FA7433D-04AB-4356-A2BA-1A5847FED096@nic.cz> Date: Tue, 4 Feb 2014 08:46:15 -0800 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=001a11c133deed743e04f197608c Cc: "netmod@ietf.org" Subject: Re: [netmod] charter revision - please comment on charter-ietf-netmod-06-05 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2014 16:46:21 -0000 --001a11c133deed743e04f197608c Content-Type: text/plain; charset=ISO-8859-1 On Tue, Feb 4, 2014 at 8:07 AM, Ladislav Lhotka wrote: > > On 04 Feb 2014, at 16:27, Andy Bierman wrote: > > > > > > > > > On Tue, Feb 4, 2014 at 6:53 AM, Ladislav Lhotka wrote: > > > > On 04 Feb 2014, at 15:37, Andy Bierman wrote: > > > > > > > > > > > > > > On Tue, Feb 4, 2014 at 4:53 AM, Jonathan Hansford < > Jonathan@hansfords.net> wrote: > > > > > > On 2014-02-04 11:43, Andy Bierman wrote: > > > > > >> > > >> > > >> > > >> On Tue, Feb 4, 2014 at 2:19 AM, Ladislav Lhotka > wrote: > > >> Andy Bierman writes: > > >> > > >> > On Mon, Feb 3, 2014 at 1:21 PM, Martin Bjorklund > wrote: > > >> > > > >> >> Juergen Schoenwaelder > wrote: > > >> >> > Hi, > > >> >> > > > >> >> > we (the WG chairs and Benoit) have been working on a new charter > for > > >> >> > the NETMOD working group. The current version can always be found > > >> >> > here. > > >> >> > > > >> >> > https://datatracker.ietf.org/doc/charter-ietf-netmod/ > > >> >> > > > >> >> > The current version is called charter-ietf-netmod-06-05 > > >> >> > > > >> >> > > > >> >> > https://datatracker.ietf.org/doc/charter-ietf-netmod/withmilestones-06-05.txt > > >> >> > > > >> >> > Please review and feel invited to comment and ask questions. > > >> >> > > >> >> I think that in order to solve Y1 and Y3, we need an update to > YANG. > > >> >> Since the proposed charter allows us to this, I guess the charter > is > > >> >> ok. > > >> >> > > >> >> Regarding Y3 (YANG conformance), I don't think it is clear what > > >> >> problem we want to solve. In my experience, I have not seen the > > >> >> interoperability problems Andy's draft mentions. The draft raises > > >> >> some valid issues (e.g., hello message size explosion and > if-feature > > >> >> with AND as only operator is too limiting), but I am not convinced > > >> >> that the current conformance mechanisms of YANG are not good > enough. > > >> >> > > >> >> > > >> >> > > >> > I do not agree that Y3 would require an update to YANG > > >> > that would impact the yang "module" and "submodule" > > >> > constructions. None of the items in the charter proposal > > >> > are must-have features. IMO, service-oriented conformance > > >> > is better than the implied-mandatory + if-feature conformance > > >> > model we have now. > > >> > > > >> > I have never actually seen the "identityref conflict" problem that > > >> > the xpath functions need to address. Sure it is possible that > > >> > a server will have 2 modules, each with the same named > > >> > identity, each with the same base type, but I have never seen it > actually > > >> > done. > > >> > > > >> > There are several known issues with YANG that actually impact usage, > > >> > and more XPath functions are fairly low on the list. We are not > helping > > >> > anyone by introducing a new YANG version with 1 of 10 known bugs > fixed. > > >> > Might as well fix all 10 if we bother with a YANG 1.1 release at > all. > > >> > > > >> > IMO there are better things to work on, but a new YANG version just > > >> > to introduce a few XPath functions would be net harmful to > interoperability > > >> > > >> I don't agree. There are other things in the 1.1 todo list but even > the XPath functions are a good-enough reason. The main problem IMO are > identities because currently they are essentially usable only if they are > flat, i.e. a base identity and identities derived directly form it, and > nothing else. > > >> > > >> For example, in a real Ethernet module that is modelled after > Appendix A in the interfaces I-D, the condition > > >> > > >> when "if:type = 'ianaift:ethernetCsmacd'"; > > >> > > >> won't work for Ethernet interfaces whose type is *derived* from > ethernetCsmacd. > > >> > > >> Combined with the limited extensibility of enumerations, this is a > serious problem. > > >> > > >> If it were a serious problem then we would see it showing up > > >> in real implementations. In fact, this problem has never occurred > > >> even once -- not in standard modules or vendor modules. > > >> The local names have to be for the same base. If not, the tool > > >> knows (because the leaf includes the base identity type). > > >> In theory this XPath cannot possibly work. In reality it works OK. > > > For someone who is still trying to get his company to migrate to YANG > and has therefore still not had the opportunity to use it in anger, that > last sentence doesn't inspire confidence. For any who are new to > implementing YANG, being advised that something that "cannot possibly work > ... in reality works OK" just engenders a sense of uncertainty, not just > about this but whether there are other areas of YANG where uncertainty > lurks. > > > > > > > > > This is the conflict: > > > > > > module A { > > > identity foo-base; > > > identity foo1 { > > > base foo-base; > > > } > > > } > > > > > > module B { > > > import A { prefix a; ] > > > identify foo1 { base a:foo-base; } > > > } > > > > > > module C { > > > import A { prefix a; } > > > leaf ident-leaf { > > > type identityref { base a:foo-base; } > > > } > > > leaf X { > > > when "../ident-leaf = 'foo1'"; > > > type string; > > > } > > > > > > > > > My previous point is the the duplication (e.g. foo1 in 2 modules) is > extremely > > > rare. > > > > > > When the ident-leaf is referenced in XPath, it is a string, not a > QName. > > > If the server advertises A, B, and C, then there is ambiguity for > > > the identity "foo1". In fact the example for X is illegal because > > > no prefix for an identityref means the local module, and module C > > > does not define any "foo1" identity. > > > > > > when "../ident-leaf = 'a:foo1' or ../ident-leaf = 'b:foo1'"; > > > > > > This is not OK because it requires the XPath parser to know > > > these strings are really identity values. > > > > A standard XPath processor cannot know it by definition. And this is > still only a part of the story - I think the use of identityrefs in "when" > expressions is only possible if both identities-as-qnames and the > derivation relation are properly supported. > > > > > > We are drifting into the implementation details. > > I already agreed we should do a real maintenance update > > so many YANG corner-cases will finally get solved. > > > > We already have our own XPath within YANG modules. > > We have plenty of text declaring how YANG types are treated > > in XPath. As Martin said, we did not decree how identityref > > Plenty? I am aware of three things: > > 1. The default namespace a la XPath 2.0 (sec. 6.4.1), > > 2. XPath comparisons are done on the canonical form (sec. 7.5.3), > > 3. The current() function. > > What about the prefix mappings to imports and missing prefix mapping to the current module? That requires special code to handle. Other than that, it should be standard XPath 1.0. > > > values SHALL be handled in YANG must/when statements. > > This was an oversight. (Along with many others). > > > > We could decree that identityref is a special string that no > > XPath parser knows about or we could create a brand new > > XPath function no XPath parser knows about. Either way we > > XPath 1 spec permits the latter but not the former. And XPath/XSLT > processors can often be extended to support additional functions. > > > are making rules only for YANG statements, not all XPath. > > > > This is a confusing problem because we are highjacking QNames > > here. There are not real nodes in any XML document for identities > > This is nothing unusual: > > http://www.w3.org/2001/tag/doc/qnameids This does not seem to use QNames on the right hand side of the expressions. I agree XPath functions are the correct way to add custom features to an XPath parser. > > > Lada > Andy > > > They are just registration OIDs. (We had the same problem in > > SNMP trying to mix the 2). > > > > > > > > Lada > > > > > > Andy > > > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > --001a11c133deed743e04f197608c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Tue, Feb 4, 2014 at 8:07 AM, Ladislav Lhotka &= lt;lhotka@nic.cz>= wrote:

On 04 Feb 2014, at 16:27, Andy Bierman <andy@yumaworks.com> wrote:

>
>
>
> On Tue, Feb 4, 2014 at 6:53 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
>
> On 04 Feb 2014, at 15:37, Andy Bierman <andy@yumaworks.com> wrote:
>
> >
> >
> >
> > On Tue, Feb 4, 2014 at 4:53 AM, Jonathan Hansford <Jonathan@hansfords.net> wrote:
> >
> > On 2014-02-04 11:43, Andy Bierman wrote:
> >
> >>
> >>
> >>
> >> On Tue, Feb 4, 2014 at 2:19 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
> >> Andy Bierman <andy@y= umaworks.com> writes:
> >>
> >> > On Mon, Feb 3, 2014 at 1:21 PM, Martin Bjorklund <mbj@tail-f.com> wrote:
> >> >
> >> >> Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> = wrote:
> >> >> > Hi,
> >> >> >
> >> >> > we (the WG chairs and Benoit) have been working= on a new charter for
> >> >> > the NETMOD working group. The current version c= an always be found
> >> >> > here.
> >> >> >
> >> >> >   https://datatracker.ietf.org/do= c/charter-ietf-netmod/
> >> >> >
> >> >> > The current version is called charter-ietf-netm= od-06-05
> >> >> >
> >> >> >
> >> >> https://datatracker= .ietf.org/doc/charter-ietf-netmod/withmilestones-06-05.txt
> >> >> >
> >> >> > Please review and feel invited to comment and a= sk questions.
> >> >>
> >> >> I think that in order to solve Y1 and Y3, we need an= update to YANG.
> >> >> Since the proposed charter allows us to this, I gues= s the charter is
> >> >> ok.
> >> >>
> >> >> Regarding Y3 (YANG conformance), I don't think i= t is clear what
> >> >> problem we want to solve.  In my experience, I = have not seen the
> >> >> interoperability problems Andy's draft mentions.=  The draft raises
> >> >> some valid issues (e.g., hello message size explosio= n and if-feature
> >> >> with AND as only operator is too limiting), but I am= not convinced
> >> >> that the current conformance mechanisms of YANG are = not good enough.
> >> >>
> >> >>
> >> >>
> >> > I do not agree that Y3 would require an update to YANG > >> > that would impact the yang "module" and "= submodule"
> >> > constructions.  None of the items in the charter pr= oposal
> >> > are must-have features.  IMO, service-oriented conf= ormance
> >> > is better than the implied-mandatory + if-feature confor= mance
> >> > model we have now.
> >> >
> >> > I have never actually seen the "identityref conflic= t" problem that
> >> > the xpath functions need to address. Sure it is possible= that
> >> > a server will have 2 modules, each with the same named > >> > identity, each with the same base type, but I have never= seen it actually
> >> > done.
> >> >
> >> > There are several known issues with YANG that actually i= mpact usage,
> >> > and more XPath functions are fairly low on the list. &nb= sp;We are not helping
> >> > anyone by introducing a new YANG version with 1 of 10 kn= own bugs fixed.
> >> > Might as well fix all 10 if we bother with a YANG 1.1 re= lease at all.
> >> >
> >> > IMO there are better things to work on, but a new YANG v= ersion just
> >> > to introduce a few XPath functions would be net harmful = to interoperability
> >>
> >> I don't agree. There are other things in the 1.1 todo lis= t but even the XPath functions are a good-enough reason. The main problem I= MO are identities because currently they are essentially usable only if the= y are flat, i.e. a base identity and identities derived directly form it, a= nd nothing else.
> >>
> >> For example, in a real Ethernet module that is modelled after= Appendix A in the interfaces I-D, the condition
> >>
> >> when "if:type =3D 'ianaift:ethernetCsmacd'"= ;
> >>
> >> won't work for Ethernet interfaces whose type is *derived= * from ethernetCsmacd.
> >>
> >> Combined with the limited extensibility of enumerations, this= is a serious problem.
> >>
> >> If it were a serious problem then we would see it showing up<= br> > >> in real implementations.  In fact, this problem has neve= r occurred
> >> even once -- not in standard modules or vendor modules.
> >> The local names have to be for the same base.  If not, t= he tool
> >> knows (because the leaf includes the base identity type).
> >> In theory this XPath cannot possibly work.  In reality i= t works OK.
> > For someone who is still trying to get his company to migrate to = YANG and has therefore still not had the opportunity to use it in anger, th= at last sentence doesn't inspire confidence. For any who are new to imp= lementing YANG, being advised that something that "cannot possibly wor= k ... in reality works OK" just engenders a sense of uncertainty, not = just about this but whether there are other areas of YANG where uncertainty= lurks.
> >
> >
> > This is the conflict:
> >
> > module A {
> >   identity foo-base;
> >   identity foo1 {
> >     base foo-base;
> >   }
> > }
> >
> > module B {
> >    import A { prefix a; ]
> >    identify foo1 { base a:foo-base; }
> > }
> >
> > module C {
> >   import A { prefix a; }
> >   leaf ident-leaf {
> >      type identityref { base a:foo-base; }
> >   }
> >   leaf X {
> >      when "../ident-leaf =3D 'foo1'&q= uot;;
> >      type string;
> > }
> >
> >
> > My previous point is the the duplication (e.g. foo1 in 2 modules)= is extremely
> > rare.
> >
> > When the ident-leaf is referenced in XPath, it is a string, not a= QName.
> > If the server advertises A, B, and C, then there is ambiguity for=
> > the identity "foo1".  In fact the example for X is= illegal because
> > no prefix for an identityref means the local module, and module C=
> > does not define any "foo1" identity.
> >
> >    when "../ident-leaf =3D 'a:foo1' or ../= ident-leaf =3D 'b:foo1'";
> >
> > This is not OK because it requires the XPath parser to know
> > these strings are really identity values.
>
> A standard XPath processor cannot know it by definition. And this is s= till only a part of the story - I think the use of identityrefs in “w= hen” expressions is only possible if both identities-as-qnames and th= e derivation relation are properly supported.
>
>
> We are drifting into the implementation details.
> I already agreed we should do a real maintenance update
> so many YANG corner-cases will finally get solved.
>
> We already have our own XPath within YANG modules.
> We have plenty of text declaring how YANG types are treated
> in XPath.  As Martin said, we did not decree how identityref

Plenty? I am aware of three things:

1. The default namespace a la XPath 2.0 (sec. 6.4.1),

2. XPath comparisons are done on the canonical form (sec. 7.5.3),

3. The current() function.


What about the prefix mappings to impo= rts and missing prefix mapping
to the current module?  That = requires special code to handle.


Other than that, it should be standard XPath 1.0.

> values SHALL be handled in YANG must/when statements.
> This was an oversight. (Along with many others).
>
> We could decree that identityref is a special string that no
> XPath parser knows about or we could create a brand new
> XPath function no XPath parser knows about.  Either way we

XPath 1 spec permits the latter but not the former. And XPath/XSLT processo= rs can often be extended to support additional functions.

> are making rules only for YANG statements, not all XPath.
>
> This is a confusing problem because we are highjacking QNames
> here. There are not real nodes in any XML document for identities

This is nothing unusual:

http:= //www.w3.org/2001/tag/doc/qnameids

This= does not seem to use QNames on the right hand side of the expressions.
I agree XPath functions are the correct way to add custom features to<= /div>
an XPath parser.

 


Lada


Andy

=
 

> They are just registration OIDs.  (We had the same problem in
> SNMP trying to mix the 2).
>
>
>
> Lada
>
>
> Andy
>

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





--001a11c133deed743e04f197608c-- From alex@cisco.com Tue Feb 4 11:18:24 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8D841A01E4 for ; Tue, 4 Feb 2014 11:18:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.736 X-Spam-Level: X-Spam-Status: No, score=-14.736 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SCbbuDNy5o14 for ; Tue, 4 Feb 2014 11:18:19 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 785F91A01C6 for ; Tue, 4 Feb 2014 11:18:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1913; q=dns/txt; s=iport; t=1391541499; x=1392751099; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=B9FMTbzDVSeAowBWOSYw6pj9QJFIqJNRq5L8l+owvkE=; b=UjlDqT3YPTKA6d6vddTWOHC/T1XUbN9cbhcFhW8lOOYo/FD2STbssOCO 5BureJN/lmC36h/EVj/kTIVPMyIAF9t+nT9Gp5gucPWFilHR5xSeFj4zz ONQq7vjfUZwDA8sHQMF5Ftn/FyBL2pmvvw7/MYbW9Lk+AoQQ8i58/9Xg0 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ak0FAIA88VKtJV2Y/2dsb2JhbABWA4MMOFe9S0+BDhZ0giUBAQEDAQEBAWsLBQcCAgIBCBABBAEBAQodBxsMCxQJCAIEAQ0FCId1CA3NdhcEjkAhEAcGC4MTgRQEiRGhO4Mtgio X-IronPort-AV: E=Sophos;i="4.95,781,1384300800"; d="scan'208";a="301829945" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-6.cisco.com with ESMTP; 04 Feb 2014 19:18:19 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s14JII6u030607 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 4 Feb 2014 19:18:18 GMT Received: from xmb-rcd-x05.cisco.com ([169.254.15.164]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0123.003; Tue, 4 Feb 2014 13:18:18 -0600 From: "Alexander Clemm (alex)" To: Ladislav Lhotka , =?iso-8859-1?Q?J=FCrgen_Sch=F6nw=E4lder?= Thread-Topic: [netmod] charter revision - please comment on charter-ietf-netmod-06-05 Thread-Index: AQHPIZA2VDChrJzfIk2G4ALubAswUpqleAlA Date: Tue, 4 Feb 2014 19:18:18 +0000 Message-ID: References: <20140202135609.GA35596@elstar.local> <20140204094258.GA42890@elstar.local> <99860237-B703-43F1-A511-AD87760B9872@nic.cz> In-Reply-To: <99860237-B703-43F1-A511-AD87760B9872@nic.cz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.154.205.170] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "netmod@ietf.org" Subject: Re: [netmod] charter revision - please comment on charter-ietf-netmod-06-05 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2014 19:18:24 -0000 I also agree that the WG should be flexible to take on new data models with= out having to recharter. The current wording does not seem to express this= clearly; I had the same question as Lada and think some clarification woul= d be good. --- Alex -----Original Message----- From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Ladislav Lhotka Sent: Tuesday, February 04, 2014 2:02 AM To: J=FCrgen Sch=F6nw=E4lder Cc: netmod@ietf.org Subject: Re: [netmod] charter revision - please comment on charter-ietf-net= mod-06-05 On 04 Feb 2014, at 10:42, Juergen Schoenwaelder wrote: > On Tue, Feb 04, 2014 at 10:33:11AM +0100, Ladislav Lhotka wrote: >>=20 >> 2. Is it intentional that no specific new data models are mentioned, exc= ept the stateless packet filter example? A few items are already on the tab= le. >>=20 >=20 > The idea was to let the charter be flexible such that the WG can take=20 > on data models without having to recharter. From what has been OK, it this is possible, then it's fine. Lada > proposed, the stateless packet filter work seems to be a relatively=20 > clear cut case. The topology work interacts with the information=20 > model work submitted by the same authors to I2RS so it seems we need=20 > to figure out where this work will be entertained. The other proposals=20 > do not really seem to be mature enough to work on them at this point=20 > in time. >=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 _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From tnadeau@lucidvision.com Tue Feb 4 11:23:33 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 555C81A0187 for ; Tue, 4 Feb 2014 11:23:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EP2lxyCUXcFA for ; Tue, 4 Feb 2014 11:23:27 -0800 (PST) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 15EAD1A01D4 for ; Tue, 4 Feb 2014 11:23:27 -0800 (PST) Received: from [10.36.0.205] (sccc-66-78-236-243.smartcity.com [66.78.236.243]) by lucidvision.com (Postfix) with ESMTP id 5C85626DC53B for ; Tue, 4 Feb 2014 14:23:26 -0500 (EST) From: Thomas Nadeau Content-Type: multipart/signed; boundary="Apple-Mail=_0B321543-C21E-4247-AF6C-26DB79226CF2"; protocol="application/pgp-signature"; micalg=pgp-sha512 Message-Id: <8A4CB85C-08AA-4851-B5BA-056F86970B2B@lucidvision.com> Date: Tue, 4 Feb 2014 11:23:25 -0800 To: netmod@ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) X-Mailer: Apple Mail (2.1827) Subject: [netmod] Change of Affilliation X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2014 19:23:33 -0000 --Apple-Mail=_0B321543-C21E-4247-AF6C-26DB79226CF2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Dear NetMod Participants - As of Monday, I am now affiliated with (employed by) Brocade = Communications. I am no longer affiliated with Juniper Networks. As = always, I can be reached at tnadeau@lucidvision.com for EMAN business. = If you wish to communicate with me at Brocade, feel free to email = tnadeau@brocade.com. --Tom --Apple-Mail=_0B321543-C21E-4247-AF6C-26DB79226CF2 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJS8T4tAAoJEPcO+I7eiUJZrK0QAKRdHw+4xIZ0q7HVaM0DBiIg 0WOdyb7Kx89mePbyI4RvGYo+H4tJwI4DFdhSiA8QaPIQl2dExHSu9vb3kMYNv9EY UJrspR9B7WqhX0c1Yr959vCioZey6Nj4yp5N3W5HtW0rYQwDjQN61jTWyjmVPSOL k4t6Zx0wxp6uor4SBtzxEJ8opq/zuqp2SUlU491j/jJbFQv2P52Ucfetmj385m6g +raYR7fQ4j1aG/1KzVQSaDLgG2V1KxO1Nr4iPf/c/c1Oyff4KSMP2YZV7kjeSfZA +3Q/zwZCOuIEclu1/n/WvxJ0tMZ1Z2COLih+4Kt9XXvDUxfNt5mk1FtOzk5Qqwzo ehRCXZOyfvINk9Qr/+rtWzmR34H23v7mg+NVgzt8E+GcUWvcfX93fcqXIQrbyaV6 QOEM+gsaKviOBatpmWuT7QIrIK0OHEoFFYiJ3bXfRZ4QUoNS0BLfjvi7w9yQhDte otCA9SpGIpYP4TAv9pxhX/oNAZamjTjd1oar2OhjNGs2fgDOgDLJW8RUocfDvZhU urWmNyXtl2uCFPHg0y+Qwi3QAK557VyePoL25lDF9LMnmfxqaJnsG6cw9UY2JO3+ n2vhDv9NdLrEtZZ7PHJwvhHFVcrUF3uZ2leO9/ETIfuM53iJyVOC7vC/yFY4R4zS Y2Jl2zBA5f+8TvuXFiAf =rSAB -----END PGP SIGNATURE----- --Apple-Mail=_0B321543-C21E-4247-AF6C-26DB79226CF2-- From tnadeau@lucidvision.com Tue Feb 4 11:27:59 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6D391A0187 for ; Tue, 4 Feb 2014 11:27:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id icaGpGzf4_bd for ; Tue, 4 Feb 2014 11:27:58 -0800 (PST) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 4A4A81A0167 for ; Tue, 4 Feb 2014 11:27:58 -0800 (PST) Received: from [10.36.0.205] (sccc-66-78-236-243.smartcity.com [66.78.236.243]) by lucidvision.com (Postfix) with ESMTP id 83CDE26DC5AB for ; Tue, 4 Feb 2014 14:27:57 -0500 (EST) From: Thomas Nadeau Content-Type: multipart/signed; boundary="Apple-Mail=_64BCAAED-254E-4F9B-8F22-8FA61E8F6538"; protocol="application/pgp-signature"; micalg=pgp-sha512 Message-Id: <45C524DD-4A5C-45D8-9809-CC60615D6F08@lucidvision.com> Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) Date: Tue, 4 Feb 2014 11:27:55 -0800 References: <8A4CB85C-08AA-4851-B5BA-056F86970B2B@lucidvision.com> To: netmod@ietf.org In-Reply-To: <8A4CB85C-08AA-4851-B5BA-056F86970B2B@lucidvision.com> X-Mailer: Apple Mail (2.1827) Subject: Re: [netmod] Change of Affilliation X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2014 19:27:59 -0000 --Apple-Mail=_64BCAAED-254E-4F9B-8F22-8FA61E8F6538 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Typo: I meant NetMod Business below. *) --Tom >=20 > Dear NetMod Participants - >=20 > As of Monday, I am now affiliated with (employed by) Brocade = Communications. I am no longer affiliated with Juniper Networks. As = always, I can be reached at tnadeau@lucidvision.com for EMAN business. = If you wish to communicate with me at Brocade, feel free to email = tnadeau@brocade.com. >=20 > --Tom >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod --Apple-Mail=_64BCAAED-254E-4F9B-8F22-8FA61E8F6538 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJS8T87AAoJEPcO+I7eiUJZaDoQAKTHeZHpbgMatanvlNONxXeK snoOt0zRgomeba65MFGxdx2jAcS9zRqaaJcnnYkQEHX2NQuz51d55kWf6Jfl3KRq ztpVElwyrc8QWeX2ewgDw+ULhehl1k8NDUHfvCcHCOhZaOKabKAJaJkc3YGuSfyq Wt8iR+JZJl52HMJ1iFLvs0B5+k80R4a82A9TercJv8W4R9vjtn+8YfV4GZT8Dbjv 2QwMy8RoRPX75MBbg/PEKgbLwlIT2TLvSmOxT0z+q5wlPCNqqt+J8ylynHb6L/f/ 2yswwFRBXrxnODKk/blA5KAGhU3sA6HZ/BQ5rvS40J3tlIinkU1GPwh6II+EBAm8 ce0vpRFGoMt4SnqBUj2ZANKi0xqOiHX/iNYv2ZE0CUhP+XV7wShYOLiGzpaN9cpz TKH7i5BrKx1644D4aoOrRrCkGCTxOVSGr136J9Yzf9GvqW1MFWgC1I4ZNPqvv/ES USNeDRCg/mtpsIPQCCw7isYD/iB3yK7vzfq+WQnEG/siSqqaz4i5yVY9iKLJULc/ p09kZf2Z4CWBq3LpijEuu9YZu/x677SptRJnqQWSi+kdteTTcpVbCXBOsmGV0uMH lMwVRhWMF/Md9wB3qfGdhMaYMmEVRT2AvP0TkjB6GATYKhci9KkUxwzZlzipo8je EhEy1F3yRVsk/MzbLOzp =fzsV -----END PGP SIGNATURE----- --Apple-Mail=_64BCAAED-254E-4F9B-8F22-8FA61E8F6538-- From alex@cisco.com Tue Feb 4 11:29:50 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C3C81A0187 for ; Tue, 4 Feb 2014 11:29:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.035 X-Spam-Level: X-Spam-Status: No, score=-10.035 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0rlLbDJ57B3L for ; Tue, 4 Feb 2014 11:29:48 -0800 (PST) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) by ietfa.amsl.com (Postfix) with ESMTP id 0E0D21A0167 for ; Tue, 4 Feb 2014 11:29:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7812; q=dns/txt; s=iport; t=1391542187; x=1392751787; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=sPaZzlRjAswNrc7f0KtPc6NNb5QeIlxuglnMcOU9rsU=; b=Zn4NP+0q3QIDl3xtCNJjoVGZ7LmJOe2kDrfYjFl+sIxFce4MaQ/fXQWf FXbdpvBNq0YWD93vpGOG6qleqn+an3tEg2gQtb4TZyNxHn0hDnky8sxMl ngmgJf5c9PBZMleef7AES1GdPafr/MA7SZUdXIsJTX4pwdCGZnNtkR+2n 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlMFAJo+8VKtJXG+/2dsb2JhbABQCYJIRDhXvhqBDhZ0giYBAQQtTBACAQgiJDIlAgQBDQ2Hfc4HF44aAycxB4MkgRQEqkyDLYFoAh4GHA X-IronPort-AV: E=Sophos;i="4.95,781,1384300800"; d="scan'208,217";a="17908129" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by alln-iport-1.cisco.com with ESMTP; 04 Feb 2014 19:29:47 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id s14JTl5M022052 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 4 Feb 2014 19:29:47 GMT Received: from xmb-rcd-x05.cisco.com ([169.254.15.164]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.03.0123.003; Tue, 4 Feb 2014 13:29:47 -0600 From: "Alexander Clemm (alex)" To: Andy Bierman , Ladislav Lhotka Thread-Topic: [netmod] charter revision - please comment on charter-ietf-netmod-06-05 Thread-Index: AQHPISiEenbquMMuIkK7IMRkA3Ti2JqlR1AAgAAXgYCAAByoUA== Date: Tue, 4 Feb 2014 19:29:46 +0000 Message-ID: References: <20140202135609.GA35596@elstar.local> <20140203.222129.457630286.mbj@tail-f.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.154.205.170] Content-Type: multipart/alternative; boundary="_000_DBC595ED2346914F9F81D17DD5C32B5718684268xmbrcdx05ciscoc_" MIME-Version: 1.0 Cc: "netmod@ietf.org" Subject: Re: [netmod] charter revision - please comment on charter-ietf-netmod-06-05 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2014 19:29:50 -0000 --_000_DBC595ED2346914F9F81D17DD5C32B5718684268xmbrcdx05ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable We have internally run into the issue where the fact that we could not arti= culate a condition that validated if an identityref referred an identity wi= th a certain base identity was a limitation. If you make use of identity h= ierarchies several levels deep, this is a valid issue that can occur. --- Alex ... > I have never actually seen the "identityref conflict" problem that > the xpath functions need to address. Sure it is possible that > a server will have 2 modules, each with the same named > identity, each with the same base type, but I have never seen it actually > done. > > There are several known issues with YANG that actually impact usage, > and more XPath functions are fairly low on the list. We are not helping > anyone by introducing a new YANG version with 1 of 10 known bugs fixed. > Might as well fix all 10 if we bother with a YANG 1.1 release at all. > > IMO there are better things to work on, but a new YANG version just > to introduce a few XPath functions would be net harmful to interoperabili= ty I don't agree. There are other things in the 1.1 todo list but even the XPa= th functions are a good-enough reason. The main problem IMO are identities = because currently they are essentially usable only if they are flat, i.e. a= base identity and identities derived directly form it, and nothing else. For example, in a real Ethernet module that is modelled after Appendix A in= the interfaces I-D, the condition when "if:type =3D 'ianaift:ethernetCsmacd'"; won't work for Ethernet interfaces whose type is *derived* from ethernetCsm= acd. Combined with the limited extensibility of enumerations, this is a serious = problem. If it were a serious problem then we would see it showing up in real implementations. In fact, this problem has never occurred even once -- not in standard modules or vendor modules. The local names have to be for the same base. If not, the tool knows (because the leaf includes the base identity type). In theory this XPath cannot possibly work. In reality it works OK. --_000_DBC595ED2346914F9F81D17DD5C32B5718684268xmbrcdx05ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

We have internally run in= to the issue where the fact that we could not articulate a condition that v= alidated if an identityref referred an identity with a certain base identity was a limitation.  If you make use of identity hierarch= ies several levels deep, this is a valid issue that can occur. 

--- Alex

 <= /p>

 <= /p>

...
> I have never actually seen the "identityref conflict" proble= m that
> the xpath functions need to address. Sure it is possible that
> a server will have 2 modules, each with the same named
> identity, each with the same base type, but I have never seen it actua= lly
> done.
>
> There are several known issues with YANG that actually impact usage, > and more XPath functions are fairly low on the list.  We are not = helping
> anyone by introducing a new YANG version with 1 of 10 known bugs fixed= .
> Might as well fix all 10 if we bother with a YANG 1.1 release at all.<= br> >
> IMO there are better things to work on, but a new YANG version just > to introduce a few XPath functions would be net harmful to interoperab= ility

I don't agree. There are other things in the 1.1 todo list but even the XPa= th functions are a good-enough reason. The main problem IMO are identities = because currently they are essentially usable only if they are flat, i.e. a= base identity and identities derived directly form it, and nothing else.

For example, in a real Ethernet module that is modelled after Appendix = ;A in the interfaces I-D, the condition

when "if:type =3D 'ianaift:ethernetCsmacd'";

won't work for Ethernet interfaces whose type is *derived* from ethernetCsm= acd.

Combined with the limited extensibility of enumerations, this is a serious = problem.

 

If it were a serious problem then we would see it sh= owing up

in real implementations.  In fact, this problem= has never occurred

even once -- not in standard modules or vendor modul= es.

The local names have to be for the same base.  = If not, the tool

knows (because the leaf includes the base identity t= ype).

In theory this XPath cannot possibly work.  In = reality it works OK.

 

 

--_000_DBC595ED2346914F9F81D17DD5C32B5718684268xmbrcdx05ciscoc_-- From yiya@cisco.com Wed Feb 5 11:05:33 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE11A1A00FA for ; Wed, 5 Feb 2014 11:05:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.036 X-Spam-Level: X-Spam-Status: No, score=-15.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B748nswk6r34 for ; Wed, 5 Feb 2014 11:05:32 -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 DA7CB1A001A for ; Wed, 5 Feb 2014 11:05:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1885; q=dns/txt; s=iport; t=1391627131; x=1392836731; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=EVyWil1os0TWUU/gb71SQOGiERPONOKj18rDh9FeFxI=; b=elg8Ft2qG2I9izEZpHpAcDprz/fKE2Tvbe9hhN3rG7x7VVReIacJ7I8v AtaC3TRxr+KphXPZBq1S9jrCPIzcouLdFB8AqlUcn6QC7fg5uQJYfrdDq /gqtlCS19HUEAgzTx9wl1GXcJ6QUC9xU48OoBf5pzn/uHCOnpsZn8V8tb s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AucFAH+K8lKtJXG9/2dsb2JhbABZgww4UQa9fU+BEBZ0giYBAQQBAQE3NBsCAQgwBhAnCyUCBBMJh3wIBc8DF458GIQgBJRCg2mBMpBvgy2CKg X-IronPort-AV: E=Sophos;i="4.95,788,1384300800"; d="scan'208";a="302124251" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-3.cisco.com with ESMTP; 05 Feb 2014 19:05:31 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id s15J5URu004154 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 5 Feb 2014 19:05:30 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.170]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.03.0123.003; Wed, 5 Feb 2014 13:05:30 -0600 From: "Yi Yang (yiya)" To: "netmod@ietf.org" Thread-Topic: [netmod] I-D Action: draft-ietf-netmod-system-mgmt-11.txt Thread-Index: AQHPFdgzGMRqtUVbW0GBh5oYMEh3NpqnL4wA Date: Wed, 5 Feb 2014 19:05:30 +0000 Message-ID: References: <20140120120649.30508.62952.idtracker@ietfa.amsl.com> In-Reply-To: <20140120120649.30508.62952.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [64.102.95.107] Content-Type: text/plain; charset="us-ascii" Content-ID: <977250F2CBCCC14B817469DAB5E5ED6E@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [netmod] I-D Action: draft-ietf-netmod-system-mgmt-11.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2014 19:05:34 -0000 I have a quick question on authentication method. If the system supports SSH public key authentication only, but not local user password, how user-authentication-order should be set? Yi On 1/20/14 7:06 AM, "internet-drafts@ietf.org" wrote: > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > This draft is a work item of the NETCONF Data Modeling Language Working >Group of the IETF. > > Title : A YANG Data Model for System Management > Authors : Andy Bierman > Martin Bjorklund > Filename : draft-ietf-netmod-system-mgmt-11.txt > Pages : 39 > Date : 2014-01-20 > >Abstract: > This document defines a YANG data model for the configuration and > identification of some common system properties within a device > containing a NETCONF server. This includes data node definitions for > system identification, time-of-day management, user management, DNS > resolver configuration, and some protocol operations for system > management. > > >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-11 > >A diff from the previous version is available at: >http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netmod-system-mgmt-11 > > >Please note that it may take a couple of minutes from the time of >submission >until the htmlized version and diff are available at tools.ietf.org. > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >_______________________________________________ >netmod mailing list >netmod@ietf.org >https://www.ietf.org/mailman/listinfo/netmod From jasmbhat@cisco.com Wed Feb 5 20:38:43 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 994B31A0364 for ; Wed, 5 Feb 2014 20:38:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.036 X-Spam-Level: X-Spam-Status: No, score=-10.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LE78JJJ9qvWB for ; Wed, 5 Feb 2014 20:38:41 -0800 (PST) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) by ietfa.amsl.com (Postfix) with ESMTP id AC7B71A029D for ; Wed, 5 Feb 2014 20:38:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2760; q=dns/txt; s=iport; t=1391661521; x=1392871121; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=3vb3rVtt4phV2fsbJLeanaa853wmCCRh2FEKkJPUqeY=; b=QD85415M7vXOnJ3e7/dhi2CbnVJVzExdw1QF4pejuhZFLiqNVD9WwkH0 IrLBXgykCtkJhO2ivkkyjk96SYF6VKxfekhUbrMBMfV5WnpNhLo35inXp uF5LqAjPKKGXuVLjoPfivLyulY91jusK6xc2eT8Ps+RVaIgD7INuFwGdP s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAHcR81KtJXHB/2dsb2JhbABZgww4vm9PgQcWdIIlAQEBAwEBAQFrCwULAgEIGB0RJwslAgQOBYd9CA3OWBMEjkIzB4MkgRQEmCuSIYMtgWok X-IronPort-AV: E=Sophos;i="4.95,791,1384300800"; d="scan'208";a="18353868" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by alln-iport-1.cisco.com with ESMTP; 06 Feb 2014 04:38:40 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id s164cesW012883 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 6 Feb 2014 04:38:40 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.60]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.03.0123.003; Wed, 5 Feb 2014 22:38:40 -0600 From: "Jasmeet Bhatia (jasmbhat)" To: Ladislav Lhotka Thread-Topic: [netmod] Issue with Choice Statement inside a List Statement Thread-Index: AQHPIYkQnckL/80LzE+53/ALMwSP85qlNFgAgAJzMn8= Date: Thu, 6 Feb 2014 04:38:39 +0000 Message-ID: <1B039343-9F5F-4AAD-A2D2-CA49052D7339@cisco.com> References: ,<5F29237C-B533-495E-A126-F0CDAD248E1B@nic.cz> In-Reply-To: <5F29237C-B533-495E-A126-F0CDAD248E1B@nic.cz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "netmod@ietf.org" Subject: Re: [netmod] Issue with Choice Statement inside a List Statement X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Feb 2014 04:38:43 -0000 Thanks ...that helps! Sent from Jasmeet's iPhone > On Feb 4, 2014, at 1:14 AM, "Ladislav Lhotka" wrote: >=20 >=20 >> On 04 Feb 2014, at 10:10, Ladislav Lhotka wrote: >>=20 >> Hi, >>=20 >> "Jasmeet Bhatia (jasmbhat)" writes: >>=20 >>> I am having issues defining a "choice" scenario inside a list statement= . I can't find any examples on how to do this either. The pyang validator i= s giving me "error: the key "id" does not reference an existing leaf". Basi= cally I am trying to create a list where a list of "YangCar" can contain ei= ther a "YangFordCar" or a "YangHondaCar". The key "id" of the YangCar list = can't seem to find the reference to the leaf id used for the yang car. How = do I resolve this? >>>=20 >>> container YangPersonList { >>> list YangPerson { >>> key id; >>> uses YangPerson; >>> container YangCarList { >>> list YangCar { >>> //The following id >>> key id; >>> choice YangCar { >>> case YangFordCar { >>> container YangFordCar{ >>=20 >> The key leaf has to be a child of the list node, so either remove this c= ontainer (and the one in the other case) or move the definition of "id" out= of the choice. >=20 > Actually only the latter works here because =93id=94 cannot be defined tw= ice in both cases. >=20 > Lada >=20 >>=20 >> Lada >>=20 >>> uses YangFordCar; >>> } >>> } >>> case YangHondaCar { >>> container YangHondaCar{ >>> uses YangHondaCar; >>> } >>> } >>> } >>> } >>> } >>> } >>> } >>>=20 >>>=20 >>> grouping YangCar { >>> reference >>> "com.cisco.xmp.model.test.containment.YangCar"; >>> leaf id { >>> mandatory true; >>> type int64; >>> } >>>=20 >>> // Non-containment Associations >>> } >>> grouping YangHondaCar { >>> reference >>> "com.cisco.xmp.model.test.containment.YangHondaCar"; >>> uses YangCar; >>> // Non-containment Associations >>> } >>> grouping YangFordCar { >>> reference >>> "com.cisco.xmp.model.test.containment.YangFordCar"; >>> uses YangCar; >>> // Non-containment Associations >>> } >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >>=20 >> --=20 >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C >> _______________________________________________ >> 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 From j.schoenwaelder@jacobs-university.de Thu Feb 6 02:39:23 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA81C1A00C4 for ; Thu, 6 Feb 2014 02:39:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.785 X-Spam-Level: X-Spam-Status: No, score=-2.785 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.535] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KTw3UotRtpmU for ; Thu, 6 Feb 2014 02:39:22 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 1BC001A00BC for ; Thu, 6 Feb 2014 02:39:22 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id E10C220137; Thu, 6 Feb 2014 11:39:20 +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 uUI7OyUia6Ji; Thu, 6 Feb 2014 11:39:20 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3CDD82012D; Thu, 6 Feb 2014 11:39:20 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id E60EF2B12B2F; Thu, 6 Feb 2014 11:39:17 +0100 (CET) Date: Thu, 6 Feb 2014 11:39:17 +0100 From: Juergen Schoenwaelder To: "Yi Yang (yiya)" Message-ID: <20140206103915.GB49052@elstar.local> Mail-Followup-To: "Yi Yang (yiya)" , "netmod@ietf.org" References: <20140120120649.30508.62952.idtracker@ietfa.amsl.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] I-D Action: draft-ietf-netmod-system-mgmt-11.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Feb 2014 10:39:23 -0000 On Wed, Feb 05, 2014 at 07:05:30PM +0000, Yi Yang (yiya) wrote: > I have a quick question on authentication method. > > If the system supports SSH public key authentication only, but not local > user password, how user-authentication-order should be set? I think this is fair question to ask. Martin and Andy, are we missing an identity for this case? /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 Thu Feb 6 03:59:18 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2F9A1A0385 for ; Thu, 6 Feb 2014 03:59:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.436 X-Spam-Level: X-Spam-Status: No, score=-2.436 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J6XLwayosqG8 for ; Thu, 6 Feb 2014 03:59:17 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id DA0AC1A00E6 for ; Thu, 6 Feb 2014 03:59:16 -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 BE5CE240C5E3; Thu, 6 Feb 2014 12:59:14 +0100 (CET) Date: Thu, 06 Feb 2014 12:59:14 +0100 (CET) Message-Id: <20140206.125914.1253292680765952579.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20140206103915.GB49052@elstar.local> References: <20140120120649.30508.62952.idtracker@ietfa.amsl.com> <20140206103915.GB49052@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] I-D Action: draft-ietf-netmod-system-mgmt-11.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Feb 2014 11:59:18 -0000 Juergen Schoenwaelder wrote: > On Wed, Feb 05, 2014 at 07:05:30PM +0000, Yi Yang (yiya) wrote: > > I have a quick question on authentication method. > > > > If the system supports SSH public key authentication only, but not local > > user password, how user-authentication-order should be set? > > I think this is fair question to ask. Martin and Andy, are we missing > an identity for this case? The local-users feature handles SSH keys as well, see 3.5.1. As explained in 3.5.1, ssh public key authentication is requested by the client, so the authentication-order on the server doesn't really apply. /martin From j.schoenwaelder@jacobs-university.de Thu Feb 6 05:45:26 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8852B1A00FE for ; Thu, 6 Feb 2014 05:45:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.785 X-Spam-Level: X-Spam-Status: No, score=-2.785 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.535] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SvQtqpsLnXn7 for ; Thu, 6 Feb 2014 05:45:24 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id E180E1A00F2 for ; Thu, 6 Feb 2014 05:45:23 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9970F20197; Thu, 6 Feb 2014 14:45:22 +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 4zUZkoRuurXi; Thu, 6 Feb 2014 14:45:22 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id DC79F20190; Thu, 6 Feb 2014 14:45:20 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 039282B131EB; Thu, 6 Feb 2014 14:45:18 +0100 (CET) Date: Thu, 6 Feb 2014 14:45:18 +0100 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20140206134518.GD49118@elstar.local> Mail-Followup-To: Martin Bjorklund , yiya@cisco.com, netmod@ietf.org References: <20140120120649.30508.62952.idtracker@ietfa.amsl.com> <20140206103915.GB49052@elstar.local> <20140206.125914.1253292680765952579.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140206.125914.1253292680765952579.mbj@tail-f.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] I-D Action: draft-ietf-netmod-system-mgmt-11.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Feb 2014 13:45:26 -0000 On Thu, Feb 06, 2014 at 12:59:14PM +0100, Martin Bjorklund wrote: > Juergen Schoenwaelder wrote: > > On Wed, Feb 05, 2014 at 07:05:30PM +0000, Yi Yang (yiya) wrote: > > > I have a quick question on authentication method. > > > > > > If the system supports SSH public key authentication only, but not local > > > user password, how user-authentication-order should be set? > > > > I think this is fair question to ask. Martin and Andy, are we missing > > an identity for this case? > > The local-users feature handles SSH keys as well, see 3.5.1. As > explained in 3.5.1, ssh public key authentication is requested by the > client, so the authentication-order on the server doesn't really > apply. > Martin, we are talking about the case where you disable password and key-interactive authentication on the server side. This is actually how I run the machines I am reponsible for (so I can sleep well despite all the SSH login scanners out there). /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 Thu Feb 6 06:05:29 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8253D1A012B for ; Thu, 6 Feb 2014 06:05:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.436 X-Spam-Level: X-Spam-Status: No, score=-2.436 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VaZOiNeINAnX for ; Thu, 6 Feb 2014 06:05:27 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id 44A671A012E for ; Thu, 6 Feb 2014 06:05:27 -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 D510E37C1CE; Thu, 6 Feb 2014 15:05:24 +0100 (CET) Date: Thu, 06 Feb 2014 15:05:24 +0100 (CET) Message-Id: <20140206.150524.1309921502695133115.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20140206134518.GD49118@elstar.local> References: <20140206103915.GB49052@elstar.local> <20140206.125914.1253292680765952579.mbj@tail-f.com> <20140206134518.GD49118@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] I-D Action: draft-ietf-netmod-system-mgmt-11.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Feb 2014 14:05:29 -0000 Juergen Schoenwaelder wrote: > On Thu, Feb 06, 2014 at 12:59:14PM +0100, Martin Bjorklund wrote: > > Juergen Schoenwaelder wrote: > > > On Wed, Feb 05, 2014 at 07:05:30PM +0000, Yi Yang (yiya) wrote: > > > > I have a quick question on authentication method. > > > > > > > > If the system supports SSH public key authentication only, but not local > > > > user password, how user-authentication-order should be set? > > > > > > I think this is fair question to ask. Martin and Andy, are we missing > > > an identity for this case? > > > > The local-users feature handles SSH keys as well, see 3.5.1. As > > explained in 3.5.1, ssh public key authentication is requested by the > > client, so the authentication-order on the server doesn't really > > apply. > > > > Martin, > > we are talking about the case where you disable password and > key-interactive authentication on the server side. This is actually > how I run the machines I am reponsible for (so I can sleep well > despite all the SSH login scanners out there). Ok, but it doesn't make much sense to control this with user-authentication-order. The reason for this is that it is unclear what this means: user-authentication-order: radius, ssh-key First radius, then ssh-key? It doesn't make much sense. Actually, this can be achieved today if you set user-authentication-order to the empty list. /martin From j.schoenwaelder@jacobs-university.de Thu Feb 6 07:25:10 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E7EB1A03D5 for ; Thu, 6 Feb 2014 07:25:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.785 X-Spam-Level: X-Spam-Status: No, score=-2.785 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.535] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2c4AyxkG3-on for ; Thu, 6 Feb 2014 07:25: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 513971A03D0 for ; Thu, 6 Feb 2014 07:25:08 -0800 (PST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0EFD22011B; Thu, 6 Feb 2014 16:25:07 +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 y3qRK2VGzWEf; Thu, 6 Feb 2014 16:25: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 67D092011A; Thu, 6 Feb 2014 16:25:06 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 595492B13712; Thu, 6 Feb 2014 16:25:05 +0100 (CET) Date: Thu, 6 Feb 2014 16:25:05 +0100 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20140206152505.GC49691@elstar.local> Mail-Followup-To: Martin Bjorklund , yiya@cisco.com, netmod@ietf.org References: <20140206103915.GB49052@elstar.local> <20140206.125914.1253292680765952579.mbj@tail-f.com> <20140206134518.GD49118@elstar.local> <20140206.150524.1309921502695133115.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140206.150524.1309921502695133115.mbj@tail-f.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] I-D Action: draft-ietf-netmod-system-mgmt-11.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Feb 2014 15:25:11 -0000 On Thu, Feb 06, 2014 at 03:05:24PM +0100, Martin Bjorklund wrote: > Juergen Schoenwaelder wrote: > > On Thu, Feb 06, 2014 at 12:59:14PM +0100, Martin Bjorklund wrote: > > > Juergen Schoenwaelder wrote: > > > > On Wed, Feb 05, 2014 at 07:05:30PM +0000, Yi Yang (yiya) wrote: > > > > > I have a quick question on authentication method. > > > > > > > > > > If the system supports SSH public key authentication only, but not local > > > > > user password, how user-authentication-order should be set? > > > > > > > > I think this is fair question to ask. Martin and Andy, are we missing > > > > an identity for this case? > > > > > > The local-users feature handles SSH keys as well, see 3.5.1. As > > > explained in 3.5.1, ssh public key authentication is requested by the > > > client, so the authentication-order on the server doesn't really > > > apply. > > > > > > > Martin, > > > > we are talking about the case where you disable password and > > key-interactive authentication on the server side. This is actually > > how I run the machines I am reponsible for (so I can sleep well > > despite all the SSH login scanners out there). > > Ok, but it doesn't make much sense to control this with > user-authentication-order. The reason for this is that it is unclear > what this means: > > user-authentication-order: radius, ssh-key > > First radius, then ssh-key? It doesn't make much sense. > > Actually, this can be achieved today if you set > user-authentication-order to the empty list. OK, fine with me (after reading the text again). I guess the confusion comes from 'user-authentication-order' which is really 'user-password-authentication-order' (and no, I do not suggest this longish name). But perhaps this can be clarified? Eg. by stating explicitly: An empty user-authentication-order list still allows authentication of users using mechanisms that do not involve a password. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From yiya@cisco.com Thu Feb 6 11:45:33 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E4E01A03CA for ; Thu, 6 Feb 2014 11:45:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.036 X-Spam-Level: X-Spam-Status: No, score=-10.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BZSZ_EnLEvLJ for ; Thu, 6 Feb 2014 11:45:32 -0800 (PST) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) by ietfa.amsl.com (Postfix) with ESMTP id 119F41A03F3 for ; Thu, 6 Feb 2014 11:45:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1913; q=dns/txt; s=iport; t=1391715931; x=1392925531; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=83llOrOeAjV+y2NdCIXlKwvv5Q6cVsblpMpkVViy4+Q=; b=kQsetY9C9fGERV1clUb7+LLm87lEAJhHyep6yqWfe8XgsDMIypD/qtX8 8QIy24qNvb1I3QYELTnSEbw+AN6Zr6A5h6FRIuQGmhaQsLc7S0e+zpYwc P5cZaYnF2qohQM1Mph6rkafakt7fHBhfWVUdUbpSlSBXMT6Tf0I+uIaPG g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFANPl81KtJV2d/2dsb2JhbABQCYMMgQ++c4ENFnSCJQEBAQQ6PxACAQgOAggWAQEGEDIlAgQBDQWIBc0NF44fWwcSAQWEIAEDlEKDaZIhgy2BagcXIg X-IronPort-AV: E=Sophos;i="4.95,795,1384300800"; d="scan'208";a="18547663" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-4.cisco.com with ESMTP; 06 Feb 2014 19:45:29 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s16JjTEx015003 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 6 Feb 2014 19:45:29 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.170]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.03.0123.003; Thu, 6 Feb 2014 13:45:29 -0600 From: "Yi Yang (yiya)" To: Martin Bjorklund , "j.schoenwaelder@jacobs-university.de" Thread-Topic: [netmod] I-D Action: draft-ietf-netmod-system-mgmt-11.txt Thread-Index: AQHPFdgzGMRqtUVbW0GBh5oYMEh3NpqnL4wAgAFYt4CAABZXAIAAHaIAgAAFngCAAAsxAA== Date: Thu, 6 Feb 2014 19:45:28 +0000 Message-ID: References: <20140206103915.GB49052@elstar.local> <20140206.125914.1253292680765952579.mbj@tail-f.com> <20140206134518.GD49118@elstar.local> <20140206.150524.1309921502695133115.mbj@tail-f.com> In-Reply-To: <20140206.150524.1309921502695133115.mbj@tail-f.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [64.102.95.107] Content-Type: text/plain; charset="us-ascii" Content-ID: <43A5DB5DC5059A49AC87468E9A171104@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "netmod@ietf.org" Subject: Re: [netmod] I-D Action: draft-ietf-netmod-system-mgmt-11.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Feb 2014 19:45:33 -0000 Hi Martin, One issue is for "feature local-users", as specified in section 3.5.1 and 3.5.2, it indicates support of public-key-based AND password-based authentication for local users. But what if only public-key-based is supported, or vice versa? How would client discover it? Yi On 2/6/14 9:05 AM, "Martin Bjorklund" wrote: >Juergen Schoenwaelder wrote: >> On Thu, Feb 06, 2014 at 12:59:14PM +0100, Martin Bjorklund wrote: >> > Juergen Schoenwaelder wrote: >> > > On Wed, Feb 05, 2014 at 07:05:30PM +0000, Yi Yang (yiya) wrote: >> > > > I have a quick question on authentication method. >> > > >=20 >> > > > If the system supports SSH public key authentication only, but >>not local >> > > > user password, how user-authentication-order should be set? >> > > =20 >> > > I think this is fair question to ask. Martin and Andy, are we >>missing >> > > an identity for this case? >> >=20 >> > The local-users feature handles SSH keys as well, see 3.5.1. As >> > explained in 3.5.1, ssh public key authentication is requested by the >> > client, so the authentication-order on the server doesn't really >> > apply. >> >=20 >>=20 >> Martin, >>=20 >> we are talking about the case where you disable password and >> key-interactive authentication on the server side. This is actually >> how I run the machines I am reponsible for (so I can sleep well >> despite all the SSH login scanners out there). > >Ok, but it doesn't make much sense to control this with >user-authentication-order. The reason for this is that it is unclear >what this means: > > user-authentication-order: radius, ssh-key > >First radius, then ssh-key? It doesn't make much sense. > >Actually, this can be achieved today if you set >user-authentication-order to the empty list. > > >/martin From yiya@cisco.com Thu Feb 6 11:50:35 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 559B11A045C for ; Thu, 6 Feb 2014 11:50:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.036 X-Spam-Level: X-Spam-Status: No, score=-10.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F5lJfA5UAL3N for ; Thu, 6 Feb 2014 11:50:33 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) by ietfa.amsl.com (Postfix) with ESMTP id 687DE1A044E for ; Thu, 6 Feb 2014 11:50:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2761; q=dns/txt; s=iport; t=1391716232; x=1392925832; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=P2hMIkpS7fg1TR3lEJTGjL0fIl97LmMat68KBjKIpfs=; b=Z7GDveoO9EgB3V0bStfgj0rmxhNf1GKWqyLcbQ1AieI29sLGnzTHKMtV e05GotvIVbf2S29b8hCqOrcnMOEwYQ6aT8G3OxuXD9KRsk2eK+TafJ8bH xUfSRsypcFE0AJqm2+qANogx8Ns10nDkXOA8Ohzu4aFZ7JxeN+uEDSNoD E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAOrm81KtJV2c/2dsb2JhbABQBgODDDhXvnOBDRZ0giUBAQEEOj8OAgIBCA4CCBYBAQYQGxclAgQBDQWIBc0OFwSOG0sQBxEBAQWEIASUQoNpkiGDLYFqBxci X-IronPort-AV: E=Sophos;i="4.95,795,1384300800"; d="scan'208";a="18541783" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-3.cisco.com with ESMTP; 06 Feb 2014 19:50:32 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s16JoWA5001290 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 6 Feb 2014 19:50:32 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.170]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.03.0123.003; Thu, 6 Feb 2014 13:50:31 -0600 From: "Yi Yang (yiya)" To: Juergen Schoenwaelder , "Martin Bjorklund" Thread-Topic: [netmod] I-D Action: draft-ietf-netmod-system-mgmt-11.txt Thread-Index: AQHPFdgzGMRqtUVbW0GBh5oYMEh3NpqnL4wAgAFYt4CAABZXAIAAHaIAgAAFngCAABZDgP//9lYA Date: Thu, 6 Feb 2014 19:50:31 +0000 Message-ID: References: <20140206103915.GB49052@elstar.local> <20140206.125914.1253292680765952579.mbj@tail-f.com> <20140206134518.GD49118@elstar.local> <20140206.150524.1309921502695133115.mbj@tail-f.com> <20140206152505.GC49691@elstar.local> In-Reply-To: <20140206152505.GC49691@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [64.102.95.107] Content-Type: text/plain; charset="us-ascii" Content-ID: <0E3F7B366BBD3C4FA9A9C4E8B67823F0@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "netmod@ietf.org" Subject: Re: [netmod] I-D Action: draft-ietf-netmod-system-mgmt-11.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Feb 2014 19:50:35 -0000 Please see my comments inline with [yi]: On 2/6/14 10:25 AM, "Juergen Schoenwaelder" wrote: >On Thu, Feb 06, 2014 at 03:05:24PM +0100, Martin Bjorklund wrote: >> Juergen Schoenwaelder wrote: >> > On Thu, Feb 06, 2014 at 12:59:14PM +0100, Martin Bjorklund wrote: >> > > Juergen Schoenwaelder wrote: >> > > > On Wed, Feb 05, 2014 at 07:05:30PM +0000, Yi Yang (yiya) wrote: >> > > > > I have a quick question on authentication method. >> > > > >=20 >> > > > > If the system supports SSH public key authentication only, but >>not local >> > > > > user password, how user-authentication-order should be set? >> > > > =20 >> > > > I think this is fair question to ask. Martin and Andy, are we >>missing >> > > > an identity for this case? >> > >=20 >> > > The local-users feature handles SSH keys as well, see 3.5.1. As >> > > explained in 3.5.1, ssh public key authentication is requested by >>the >> > > client, so the authentication-order on the server doesn't really >> > > apply. >> > >=20 >> >=20 >> > Martin, >> >=20 >> > we are talking about the case where you disable password and >> > key-interactive authentication on the server side. This is actually >> > how I run the machines I am reponsible for (so I can sleep well >> > despite all the SSH login scanners out there). >>=20 >> Ok, but it doesn't make much sense to control this with >> user-authentication-order. The reason for this is that it is unclear >> what this means: >>=20 >> user-authentication-order: radius, ssh-key >>=20 >> First radius, then ssh-key? It doesn't make much sense. >>=20 >> Actually, this can be achieved today if you set >> user-authentication-order to the empty list. > >OK, fine with me (after reading the text again). > >I guess the confusion comes from 'user-authentication-order' which is >really 'user-password-authentication-order' (and no, I do not suggest >this longish name). [yi]: How about "password-authentication-order" or simply "password-order"? >But perhaps this can be clarified? Eg. by stating explicitly: > > An empty user-authentication-order list still allows > authentication of users using mechanisms that do not involve a > password. [yi]: Only when public-key based approach is supported. In other words, if public-key based approach is not supported, an empty "*-authentication-order" list should not be allowed. Yi > >/js > >--=20 >Juergen Schoenwaelder Jacobs University Bremen gGmbH >Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany >Fax: +49 421 200 3103 From mbj@tail-f.com Thu Feb 6 12:58:27 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40AB21A0475 for ; Thu, 6 Feb 2014 12:58:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.436 X-Spam-Level: X-Spam-Status: No, score=-2.436 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ufoH3RMYE1g for ; Thu, 6 Feb 2014 12:58:26 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id C22301A0503 for ; Thu, 6 Feb 2014 12:58:25 -0800 (PST) Received: from localhost (unknown [193.12.32.88]) by mail.tail-f.com (Postfix) with ESMTPSA id B387537C1D8; Thu, 6 Feb 2014 21:58:23 +0100 (CET) Date: Thu, 06 Feb 2014 21:58:22 +0100 (CET) Message-Id: <20140206.215822.456617131.mbj@tail-f.com> To: yiya@cisco.com From: Martin Bjorklund In-Reply-To: References: <20140206134518.GD49118@elstar.local> <20140206.150524.1309921502695133115.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] I-D Action: draft-ietf-netmod-system-mgmt-11.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Feb 2014 20:58:27 -0000 Hi, "Yi Yang (yiya)" wrote: > Hi Martin, > > One issue is for "feature local-users", as specified in section 3.5.1 and > 3.5.2, it indicates support of public-key-based AND password-based > authentication for local users. But what if only public-key-based is > supported, or vice versa? How would client discover it? public-key is mandatory to support according to RFC 4252, so it makes sense to not have a special feature for it. I don't think it's common with systems that don't support passwords; of course the operator can choose to not use them, as already haas been stated. /martin From yiya@cisco.com Thu Feb 6 13:16:30 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DBCA1A0516 for ; Thu, 6 Feb 2014 13:16:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.036 X-Spam-Level: X-Spam-Status: No, score=-15.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ikGIVDC5rtF for ; Thu, 6 Feb 2014 13:16:29 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 54AD91A0514 for ; Thu, 6 Feb 2014 13:16:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=879; q=dns/txt; s=iport; t=1391721388; x=1392930988; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=qCOIpWrgvOl0E1RoEpyfncOdMIQf+PwTaSCKOhU4Jp8=; b=NNX9VPBRQeUvwjE5Dlk6UutkGjJTXpzKXV6cqU3Tc4hOqk6Q5QMNFiNO NDV8tsM+mCeJ+fbK0O5wx7m1JbgMFFao3QdqWVll4OM+6Dez4+4josWoP ZDd+gzsopb5Pf9w0+E24CjayrZWpwsMrGd6t1RvPzUcnIlAytlI6DeTgH c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAF7781KtJV2Y/2dsb2JhbABZgwyBD756gQ4WdIIlAQEBBHkQAgEIDgoYFjIlAgQOBYgFzQ4XjnoHGIQgAQOJEYsxg2mSIYMtgio X-IronPort-AV: E=Sophos;i="4.95,795,1384300800"; d="scan'208";a="302220482" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-1.cisco.com with ESMTP; 06 Feb 2014 21:16:13 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s16LGDET020593 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 6 Feb 2014 21:16:13 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.170]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.03.0123.003; Thu, 6 Feb 2014 15:16:13 -0600 From: "Yi Yang (yiya)" To: Martin Bjorklund Thread-Topic: [netmod] I-D Action: draft-ietf-netmod-system-mgmt-11.txt Thread-Index: AQHPFdgzGMRqtUVbW0GBh5oYMEh3NpqnL4wAgAFYt4CAABZXAIAAHaIAgAAFngCAAAsxAIAAaDAA//+xKgA= Date: Thu, 6 Feb 2014 21:16:12 +0000 Message-ID: References: <20140206134518.GD49118@elstar.local> <20140206.150524.1309921502695133115.mbj@tail-f.com> <20140206.215822.456617131.mbj@tail-f.com> In-Reply-To: <20140206.215822.456617131.mbj@tail-f.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [64.102.95.107] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "netmod@ietf.org" Subject: Re: [netmod] I-D Action: draft-ietf-netmod-system-mgmt-11.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Feb 2014 21:16:30 -0000 Hi Martin, Now I see why we don=B9t need something explicitly for public-key. And "user-authentication-order" is really for password-based only. Yi On 2/6/14 3:58 PM, "Martin Bjorklund" wrote: >Hi, > >"Yi Yang (yiya)" wrote: >> Hi Martin, >>=20 >> One issue is for "feature local-users", as specified in section 3.5.1 >>and >> 3.5.2, it indicates support of public-key-based AND password-based >> authentication for local users. But what if only public-key-based is >> supported, or vice versa? How would client discover it? > >public-key is mandatory to support according to RFC 4252, so it makes >sense to not have a special feature for it. > >I don't think it's common with systems that don't support passwords; >of course the operator can choose to not use them, as already haas >been stated. > > >/martin From mbj@tail-f.com Thu Feb 6 23:20:33 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03E991A05BD for ; Thu, 6 Feb 2014 23:20:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.436 X-Spam-Level: X-Spam-Status: No, score=-2.436 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ofW3eZxSWQA for ; Thu, 6 Feb 2014 23:20:31 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id BA53A1A05BC for ; Thu, 6 Feb 2014 23:20:31 -0800 (PST) Received: from localhost (unknown [193.12.32.88]) by mail.tail-f.com (Postfix) with ESMTPSA id 203DC37C1DF; Fri, 7 Feb 2014 08:20:29 +0100 (CET) Date: Fri, 07 Feb 2014 08:20:27 +0100 (CET) Message-Id: <20140207.082027.500339530.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20140206152505.GC49691@elstar.local> References: <20140206134518.GD49118@elstar.local> <20140206.150524.1309921502695133115.mbj@tail-f.com> <20140206152505.GC49691@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] I-D Action: draft-ietf-netmod-system-mgmt-11.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2014 07:20:33 -0000 Juergen Schoenwaelder wrote: > But perhaps this can be clarified? Eg. by stating explicitly: > > An empty user-authentication-order list still allows > authentication of users using mechanisms that do not involve a > password. This is fine. I have added this clarification. /martin From tnadeau@lucidvision.com Sat Feb 8 18:20:22 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB9751A0636 for ; Sat, 8 Feb 2014 18:20:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NoJZMoqo-Mv5 for ; Sat, 8 Feb 2014 18:20:19 -0800 (PST) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 593EA1A0674 for ; Sat, 8 Feb 2014 18:20:19 -0800 (PST) Received: from [192.168.1.122] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id AF0F126E3FA2 for ; Sat, 8 Feb 2014 21:20:19 -0500 (EST) From: Thomas Nadeau Content-Type: multipart/signed; boundary="Apple-Mail=_29FB1F6D-EC11-4124-87EF-E6DF0F27D950"; protocol="application/pgp-signature"; micalg=pgp-sha512 Message-Id: Date: Sat, 8 Feb 2014 21:20:19 -0500 To: netmod@ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) X-Mailer: Apple Mail (2.1827) Subject: [netmod] IETF Draft Submission Deadline X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Feb 2014 02:20:22 -0000 --Apple-Mail=_29FB1F6D-EC11-4124-87EF-E6DF0F27D950 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii FYI the draft submission deadline for this IETF falls on a = Friday instead of Monday.=20 > 2014-02-14 (Friday): Internet Draft submission cut-off (for all > drafts, including -00) by UTC 23:59, upload using IETF ID > Submission Tool. --Apple-Mail=_29FB1F6D-EC11-4124-87EF-E6DF0F27D950 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJS9uXjAAoJEPcO+I7eiUJZ0YAQAJ0KBDut3Bgqw/3sDbPeO7OQ GYOS15F8T6kxGUI5mH24Wh+/pku2JWhBf5L6qzLqFn07sG+gnfHgQy0SbXAemd58 7GWNlpikEBCK2zz5N9Ie8vm9y2tuQvbz5YnFsfh6aMiX/5ksveMe+3Rn+nnrnHVM Tcmn2GvoEsgF0nXxE2ceNVjQNcbJImMQzkKop4XOhskfPqzkpwZ22nzFHUPwJ9E0 nz/ACtPXMRL+0ZnEMW1hppSSugu3JF9g/icJap0UR3CmYw1jK9h04mye7VDq1/7C KmG1wb3jvc8Yk5vkjhVE4qebKWUeIxi3p5szLbEl/lEwG5NS/0d7P2Wv0qb37Yoj eIm5HyLKQ7f0o9EY9eKoL7TGDGfn730hf5xWD6NPKrzhsMqpwqkISD0zldBxXkKh qTdgHqnOMaImLG6EohgV9rm9sZwsnJ7J04PdODxIJh37qTK4qOEwpkxeY7Qm57ra tpXiE1UaehiYZMxzhXHxja3jcUa21nnDTkOdic+gW23uR7alQ6YHDWybIyIdZ+5Y /afQ5KICxFTcg/aN/HtsydJ789v23KHmMnLKldY+zV16yqga6Jwl06t6JqR/jqN8 4CIPAT8luBb8IpZZSw2H9rMkY8/sWshX5Brc+rhyHpWdDd3+q5YexJA8CzHW2JJ3 TdXd6wktsCdYGBMNQcxT =btYE -----END PGP SIGNATURE----- --Apple-Mail=_29FB1F6D-EC11-4124-87EF-E6DF0F27D950-- From internet-drafts@ietf.org Mon Feb 10 10:03:04 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 515B51A07EB; Mon, 10 Feb 2014 10:03:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kKDBrv3GIV6g; Mon, 10 Feb 2014 10:03:02 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D166E1A0326; Mon, 10 Feb 2014 10:03:02 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140210180302.15147.79374.idtracker@ietfa.amsl.com> Date: Mon, 10 Feb 2014 10:03:02 -0800 Cc: netmod@ietf.org Subject: [netmod] I-D Action: draft-ietf-netmod-snmp-cfg-04.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 18:03:04 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the NETCONF Data Modeling Language Working Group of the IETF. Title : A YANG Data Model for SNMP Configuration Authors : Martin Bjorklund Juergen Schoenwaelder Filename : draft-ietf-netmod-snmp-cfg-04.txt Pages : 85 Date : 2014-02-10 Abstract: This document defines a collection of YANG definitions for configuring SNMP engines. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-snmp-cfg/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-netmod-snmp-cfg-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-snmp-cfg-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From mbj@tail-f.com Mon Feb 10 10:07:00 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0FA21A0565 for ; Mon, 10 Feb 2014 10:07:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kp2FQtFSvTj2 for ; Mon, 10 Feb 2014 10:06:58 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id 7B2591A0407 for ; Mon, 10 Feb 2014 10:06:58 -0800 (PST) Received: from localhost (unknown [193.12.32.88]) by mail.tail-f.com (Postfix) with ESMTPSA id AB84837C192 for ; Mon, 10 Feb 2014 19:06:57 +0100 (CET) Date: Mon, 10 Feb 2014 19:06:57 +0100 (CET) Message-Id: <20140210.190657.524019739.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: Multipart/Mixed; boundary="--Next_Part(Mon_Feb_10_19_06_57_2014_823)--" Content-Transfer-Encoding: 7bit Subject: [netmod] Fw: I-D Action: draft-ietf-netmod-snmp-cfg-04.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 18:07:00 -0000 ----Next_Part(Mon_Feb_10_19_06_57_2014_823)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, We have posted a new version of the snmp-cfg draft, addressing the comments received during the WGLC. Specifically, we introduced an explicit target-params list (representing snmpTargetParamsTable). The inline params are replaced with a reference to a target-parmas. We also added test describing how an implementation should handle the spin locks. + some other clarifications and bug fixes. /martin & juergen ----Next_Part(Mon_Feb_10_19_06_57_2014_823)-- Content-Type: Message/Rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on roci X-Spam-Level: X-Spam-Status: No, score=-101.9 required=5.0 tests=BAYES_00,SPF_PASS, T_DKIM_INVALID,T_RP_MATCHES_RCVD,USER_IN_WHITELIST autolearn=ham version=3.3.2 X-Original-To: mbj@tail-f.com Delivered-To: mbj@tail-f.com Received: from mail.ietf.org (mail.ietf.org [4.31.198.44]) by mail.tail-f.com (Postfix) with ESMTP id 9D0F037C192; Mon, 10 Feb 2014 19:03:37 +0100 (CET) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 400641A07EC; Mon, 10 Feb 2014 10:03:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1392055389; bh=2NjIk+2NIjOkAklhdRnUsCRRUUp+uv5XFb8CxkqF94A=; h=MIME-Version:From:To:Message-ID:Date:Cc:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=c5nZDQ4Hj0Zu6yPe2RIurVVIe/t151442t4fMyJ/ahIizzNYHqQgbOIRsfTwcyM1Z cAhhyc5S8apwOoEvTneoRuYdJ1VGi533Z+x4qefYNdpOrx/CyqpFWMmoiaigYgPShd ituDwPBnbG9X9qyUwD/AiOrJ3nmZWsRF7mfAhfv0= X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 515B51A07EB; Mon, 10 Feb 2014 10:03:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kKDBrv3GIV6g; Mon, 10 Feb 2014 10:03:02 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D166E1A0326; Mon, 10 Feb 2014 10:03:02 -0800 (PST) MIME-Version: 1.0 From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140210180302.15147.79374.idtracker@ietfa.amsl.com> Date: Mon, 10 Feb 2014 10:03:02 -0800 Cc: netmod@ietf.org Subject: [netmod] I-D Action: draft-ietf-netmod-snmp-cfg-04.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: netmod-bounces@ietf.org Sender: "netmod" X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.2 int cnt prob spamicity histogram 0.00 104 0.014816 0.014139 ################################################ 0.10 5 0.114625 0.019404 ### 0.20 0 0.000000 0.019404 0.30 0 0.000000 0.019404 0.40 0 0.000000 0.019404 0.50 0 0.000000 0.019404 0.60 0 0.000000 0.019404 0.70 0 0.000000 0.019404 0.80 0 0.000000 0.019404 0.90 1 0.911269 0.039540 # A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the NETCONF Data Modeling Language Working Group of the IETF. Title : A YANG Data Model for SNMP Configuration Authors : Martin Bjorklund Juergen Schoenwaelder Filename : draft-ietf-netmod-snmp-cfg-04.txt Pages : 85 Date : 2014-02-10 Abstract: This document defines a collection of YANG definitions for configuring SNMP engines. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-snmp-cfg/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-netmod-snmp-cfg-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-snmp-cfg-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod ----Next_Part(Mon_Feb_10_19_06_57_2014_823)---- From yiya@cisco.com Tue Feb 11 08:38:38 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC8051A0639 for ; Tue, 11 Feb 2014 08:38:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.049 X-Spam-Level: X-Spam-Status: No, score=-15.049 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SJmxC0u0EA4j for ; Tue, 11 Feb 2014 08:38:35 -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 3987C1A0609 for ; Tue, 11 Feb 2014 08:38:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1528; q=dns/txt; s=iport; t=1392136715; x=1393346315; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=DFq2xhvB15n7ju20dAovKrWnMAmBhqIej+G47yTEU7c=; b=TbLHYgs/i+yC2+lEqXfvFEY2fzHyjgc5BmUa/GcnjA3ZJtA3hCcRZUJB B1eeoJvk1MU6+mCRDco7+RYWM2PK8mVoPiikDsjYSVBDVj9ngDYSAPvuU xsqcEN8OsMhKX+QLj6AlDuXPJQCQSONRpSBEDUL+BQEsaL0/HGyxi1WLa A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4FAARR+lKtJV2c/2dsb2JhbABagww4V741T4ESFnSCJgEBBAEBATc0GwIBCDYFCycLFBECBBOIBQ3JLRePAIQ4BJgqgTKQboFvgT6CKg X-IronPort-AV: E=Sophos;i="4.95,826,1384300800"; d="scan'208";a="303298146" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-7.cisco.com with ESMTP; 11 Feb 2014 16:38:34 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s1BGcYV1004125 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 11 Feb 2014 16:38:34 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.170]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.03.0123.003; Tue, 11 Feb 2014 10:38:34 -0600 From: "Yi Yang (yiya)" To: "netmod@ietf.org" Thread-Topic: [netmod] Last Call: (A YANG Data Model for IP Management) to Proposed Standard Thread-Index: AQHPDUdbZoENIh7sd0yMOVPSgbGH65qwhZyA Date: Tue, 11 Feb 2014 16:38:33 +0000 Message-ID: References: <20140109142947.16194.98784.idtracker@ietfa.amsl.com> In-Reply-To: <20140109142947.16194.98784.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [64.102.95.112] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [netmod] Last Call: (A YANG Data Model for IP Management) to Proposed Standard X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2014 16:38:39 -0000 One thing confuse me is the title of the draft -- when I first read it, I thought this is about overall IP configuration, including router, interface and etc. But it turns out this is really for interface only. Can we change the name of the draft to something more specific? Yi On 1/9/14 9:29 AM, "The IESG" wrote: > >The IESG has received a request from the NETCONF Data Modeling Language >WG (netmod) to consider the following document: >- 'A YANG Data Model for IP Management' > as Proposed Standard > >The IESG plans to make a decision in the next few weeks, and solicits >final comments on this action. Please send substantive comments to the >ietf@ietf.org mailing lists by 2014-01-23. Exceptionally, comments may be >sent to iesg@ietf.org instead. In either case, please retain the >beginning of the Subject line to allow automated sorting. > >Abstract > > > This document defines a YANG data model for management of IP > implementations. The data model includes configuration data and > state data. > > > > >The file can be obtained via >http://datatracker.ietf.org/doc/draft-ietf-netmod-ip-cfg/ > >IESG discussion can be tracked via >http://datatracker.ietf.org/doc/draft-ietf-netmod-ip-cfg/ballot/ > > >No IPR declarations have been submitted directly on this I-D. > > >_______________________________________________ >netmod mailing list >netmod@ietf.org >https://www.ietf.org/mailman/listinfo/netmod From j.schoenwaelder@jacobs-university.de Tue Feb 11 09:56:26 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C988B1A06CA for ; Tue, 11 Feb 2014 09:56:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.798 X-Spam-Level: X-Spam-Status: No, score=-2.798 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fFkKDvBHm6qe for ; Tue, 11 Feb 2014 09:56:24 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 5ABA51A06D0 for ; Tue, 11 Feb 2014 09:56:22 -0800 (PST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9F60B20035; Tue, 11 Feb 2014 18:56:21 +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 fPaHciMTrNr6; Tue, 11 Feb 2014 18:56:21 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1B5C620034; Tue, 11 Feb 2014 18:56:21 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 3BB6F2B434DE; Tue, 11 Feb 2014 18:56:19 +0100 (CET) Date: Tue, 11 Feb 2014 18:56:18 +0100 From: Juergen Schoenwaelder To: "Yi Yang (yiya)" Message-ID: <20140211175618.GA78562@elstar.local> Mail-Followup-To: "Yi Yang (yiya)" , "netmod@ietf.org" References: <20140109142947.16194.98784.idtracker@ietfa.amsl.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] Last Call: (A YANG Data Model for IP Management) to Proposed Standard X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2014 17:56:27 -0000 On Tue, Feb 11, 2014 at 04:38:33PM +0000, Yi Yang (yiya) wrote: > One thing confuse me is the title of the draft -- when I first read it, I > thought this is about overall IP configuration, including router, > interface and etc. But it turns out this is really for interface only. Can > we change the name of the draft to something more specific? > What do you mean with "router interface and etc."? What do you think is missing? Note that this document has passed WG last call and IETF last call ended on 2014-01-23. Note also that there is draft-ietf-netmod-routing-cfg-13 providing a core routing abstraction to be augmented with routing protocol specific extensions. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From yiya@cisco.com Tue Feb 11 10:21:32 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E43A1A0689 for ; Tue, 11 Feb 2014 10:21:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.049 X-Spam-Level: X-Spam-Status: No, score=-15.049 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O1R4oPMdVep3 for ; Tue, 11 Feb 2014 10:21:25 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id D83CF1A06CE for ; Tue, 11 Feb 2014 10:21:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1467; q=dns/txt; s=iport; t=1392142884; x=1393352484; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=IbQL3nVxokJub/676e9K7pbbIUpcP0veSPCarvPSsPc=; b=OC7WMA46grhTpK6xbrODT9AUN87GET5tTg0FSNcN+Juu6Qof1upSJQbf GQlFTIeGN6HPSbq71oJl3pFiMYNWB2RXpB+hi53Sa1mv+r/BYrcOzl3XO lWU4e1Pjkxfo5soXUXi4FNhveS2HS31PH+4/35YZ3Mrxjx82pnYZeQoKI 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah0FAMhp+lKtJXG//2dsb2JhbABXA4MMOFe/BIEUFnSCJQEBAQQ6Pw4CAgEIDgIIHgULGxclAgQOBYgFyFYXBI4eRxAHEYQnBJgqkiCBb4E+gWlB X-IronPort-AV: E=Sophos;i="4.95,826,1384300800"; d="scan'208";a="303341313" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-5.cisco.com with ESMTP; 11 Feb 2014 18:21:24 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id s1BILOd7014951 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 11 Feb 2014 18:21:24 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.170]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.03.0123.003; Tue, 11 Feb 2014 12:21:23 -0600 From: "Yi Yang (yiya)" To: Juergen Schoenwaelder Thread-Topic: [netmod] Last Call: (A YANG Data Model for IP Management) to Proposed Standard Thread-Index: AQHPDUdbZoENIh7sd0yMOVPSgbGH65qwhZyAgABpiwD//7MvAA== Date: Tue, 11 Feb 2014 18:21:23 +0000 Message-ID: References: <20140109142947.16194.98784.idtracker@ietfa.amsl.com> <20140211175618.GA78562@elstar.local> In-Reply-To: <20140211175618.GA78562@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [64.102.95.112] Content-Type: text/plain; charset="us-ascii" Content-ID: <6BA0C7613AE3B54B84586FF9E194ED43@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "netmod@ietf.org" Subject: Re: [netmod] Last Call: (A YANG Data Model for IP Management) to Proposed Standard X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2014 18:21:32 -0000 Hi Juergen, There are certain IP related management tasks are per host, not necessarily per interface. For example, enable/disable/rate-limit icmp, or enable DHCP on a router -- such tasks probably are more system-mgmt related.=20 My concern is really about the title itself -- IMO, something like A YANG Data Model for Interface IP Management, or A YANG Data Model for IP Management of Interfaces, is more appropriate. Yi On 2/11/14 12:56 PM, "Juergen Schoenwaelder" wrote: >On Tue, Feb 11, 2014 at 04:38:33PM +0000, Yi Yang (yiya) wrote: >> One thing confuse me is the title of the draft -- when I first read it, >>I >> thought this is about overall IP configuration, including router, >> interface and etc. But it turns out this is really for interface only. >>Can >> we change the name of the draft to something more specific? >>=20 > >What do you mean with "router interface and etc."? What do you think >is missing? Note that this document has passed WG last call and IETF >last call ended on 2014-01-23. Note also that there is >draft-ietf-netmod-routing-cfg-13 providing a core routing abstraction >to be augmented with routing protocol specific extensions. > >/js > >--=20 >Juergen Schoenwaelder Jacobs University Bremen gGmbH >Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany >Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Tue Feb 11 10:59:14 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 709571A06E3 for ; Tue, 11 Feb 2014 10:59:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.798 X-Spam-Level: X-Spam-Status: No, score=-2.798 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 975pPSBYeZjS for ; Tue, 11 Feb 2014 10:59: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 CEE961A067E for ; Tue, 11 Feb 2014 10:59:10 -0800 (PST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 18AA92004B; Tue, 11 Feb 2014 19:59:10 +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 Hb1cWkObfHSM; Tue, 11 Feb 2014 19:59:09 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A489420064; Tue, 11 Feb 2014 19:59:09 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id E508C2B436C6; Tue, 11 Feb 2014 19:59:07 +0100 (CET) Date: Tue, 11 Feb 2014 19:59:07 +0100 From: Juergen Schoenwaelder To: "Yi Yang (yiya)" Message-ID: <20140211185907.GA78702@elstar.local> Mail-Followup-To: "Yi Yang (yiya)" , "netmod@ietf.org" References: <20140109142947.16194.98784.idtracker@ietfa.amsl.com> <20140211175618.GA78562@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] Last Call: (A YANG Data Model for IP Management) to Proposed Standard X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2014 18:59:15 -0000 On Tue, Feb 11, 2014 at 06:21:23PM +0000, Yi Yang (yiya) wrote: > Hi Juergen, > > There are certain IP related management tasks are per host, not > necessarily per interface. For example, enable/disable/rate-limit icmp, or > enable DHCP on a router -- such tasks probably are more system-mgmt > related. > > My concern is really about the title itself -- IMO, something like A YANG > Data Model for Interface IP Management, or A YANG Data Model for IP > Management of Interfaces, is more appropriate. > I do not find any of the proposals better. Both "Interface IP Management" and "IP Management of Interfaces" seem to be more confusing than what we have. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From andy@yumaworks.com Tue Feb 11 11:01:04 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FB461A06F1 for ; Tue, 11 Feb 2014 11:01:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fk_4EJwJD1nu for ; Tue, 11 Feb 2014 11:00:59 -0800 (PST) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id 048DF1A06E5 for ; Tue, 11 Feb 2014 11:00:58 -0800 (PST) Received: by mail-qa0-f51.google.com with SMTP id f11so12228968qae.24 for ; Tue, 11 Feb 2014 11:00:58 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=XsDDiq3fWn2MdAyKR44d4097b0h9ccuuAmRUtEzJEVo=; b=aks+NmL0YjnKTlO3BmEmEjDVlWkdRPnWqP17KOa4ncMczf4SPbqEZeOdIN3r66ejPi 21PQwPFQQdbX02pfPoR1KV5n5KDo93HEhYNFxtV4cylI2Bz0L2kDAnQFfwWLH1MnUm3T CrZEMRIUBriV4iWClwyzmOAYUoSJAUQmPh3k2f5DSdH+urJGgy84lVUa5nzYsbVVEEZf BpwNRRb7aUWsxu3Kn6GCJBTf9K2OdrbR1VXv6EoUnZXivweMG46bDrEiF6ur00YxqQL1 jiZfbfACeU5soIj5HxeXaJghuERMMXVjEvn2NDmt9HiWwrycACkF2m9NXAXF6fUkBmdp Hpzw== X-Gm-Message-State: ALoCoQkmxwmdUgCh4HQYwAVKlo49NXowWiBWx4LIkrb/WO59I0tAvTbsPrLZhg1gUXEMzN1dLFnZ MIME-Version: 1.0 X-Received: by 10.140.87.9 with SMTP id q9mr55960384qgd.94.1392145258262; Tue, 11 Feb 2014 11:00:58 -0800 (PST) Received: by 10.140.98.130 with HTTP; Tue, 11 Feb 2014 11:00:58 -0800 (PST) In-Reply-To: References: <20140109142947.16194.98784.idtracker@ietfa.amsl.com> <20140211175618.GA78562@elstar.local> Date: Tue, 11 Feb 2014 11:00:58 -0800 Message-ID: From: Andy Bierman To: "Yi Yang (yiya)" Content-Type: multipart/alternative; boundary=001a113a359c98470004f2261313 Cc: "netmod@ietf.org" Subject: Re: [netmod] Last Call: (A YANG Data Model for IP Management) to Proposed Standard X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2014 19:01:05 -0000 --001a113a359c98470004f2261313 Content-Type: text/plain; charset=ISO-8859-1 Hi, I think the title is close enough, especially since it is already past WGLC. The 2nd sentence in the introduction is clear enough: The data model covers configuration of per-interface IPv4 and IPv6 parameters, and mappings of IP addresses to link-layer addresses. Global parameters may get added later to this RFC. Andy On Tue, Feb 11, 2014 at 10:21 AM, Yi Yang (yiya) wrote: > Hi Juergen, > > There are certain IP related management tasks are per host, not > necessarily per interface. For example, enable/disable/rate-limit icmp, or > enable DHCP on a router -- such tasks probably are more system-mgmt > related. > > My concern is really about the title itself -- IMO, something like A YANG > Data Model for Interface IP Management, or A YANG Data Model for IP > Management of Interfaces, is more appropriate. > > Yi > > > On 2/11/14 12:56 PM, "Juergen Schoenwaelder" > wrote: > > >On Tue, Feb 11, 2014 at 04:38:33PM +0000, Yi Yang (yiya) wrote: > >> One thing confuse me is the title of the draft -- when I first read it, > >>I > >> thought this is about overall IP configuration, including router, > >> interface and etc. But it turns out this is really for interface only. > >>Can > >> we change the name of the draft to something more specific? > >> > > > >What do you mean with "router interface and etc."? What do you think > >is missing? Note that this document has passed WG last call and IETF > >last call ended on 2014-01-23. Note also that there is > >draft-ietf-netmod-routing-cfg-13 providing a core routing abstraction > >to be augmented with routing protocol specific extensions. > > > >/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 > --001a113a359c98470004f2261313 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

I think the title is close enough, = especially since it is already past WGLC.
The 2nd sentence in the= introduction is clear enough:

   The data model covers configuration of per-interface IPv4 and IPv6
   parameters, and mappings of IP addresses to link-layer addresses.
=

Globa= l parameters may get added later to this RFC.


<= br>
Andy

On Tue, F= eb 11, 2014 at 10:21 AM, Yi Yang (yiya) <yiya@cisco.com> wrote:=
Hi Juergen,

There are certain IP related management tasks are per host, not
necessarily per interface. For example, enable/disable/rate-limit icmp, or<= br> enable DHCP on a router -- such tasks probably are more system-mgmt
related.

My concern is really about the title itself -- IMO, something like A YANG Data Model for Interface IP Management, or A YANG Data Model for IP
Management of Interfaces, is more appropriate.

Yi


On 2/11/14 12:56 PM, "Juergen Schoenwaelder"
<j.schoenwaelder= @jacobs-university.de> wrote:

>On Tue, Feb 11, 2014 at 04:38:33PM +0000, Yi Yang (yiya) wrote:
>> One thing confuse me is the title of the draft -- when I first rea= d it,
>>I
>> thought this is about overall IP configuration, including router,<= br> >> interface and etc. But it turns out this is really for interface o= nly.
>>Can
>> we change the name of the draft to something more specific?
>>
>
>What do you mean with "router interface and etc."? What do yo= u think
>is missing? Note that this document has passed WG last call and IETF >last call ended on 2014-01-23. Note also that there is
>draft-ietf-netmod-routing-cfg-13 providing a core routing abstraction >to be augmented with routing protocol specific extensions.
>
>/js
>
>--
>Juergen Schoenwaelder =A0 =A0 =A0 =A0 =A0 Jacobs University Bremen gGmb= H
>Phone: +49 421 200 3587 =A0 =A0 =A0 =A0 Campus Ring 1, 28759 Bremen, Ge= rmany
>Fax: =A0 +49 421 200 3103 =A0 =A0 =A0 =A0 <http://www.jacobs-university.de/&= gt;

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

--001a113a359c98470004f2261313-- From mehmet.ersue@nsn.com Wed Feb 12 15:46:23 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC4841A0031 for ; Wed, 12 Feb 2014 15:46:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0JPmEkB6IKdh for ; Wed, 12 Feb 2014 15:46:19 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id EA60F1A001F for ; Wed, 12 Feb 2014 15:46:18 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id s1CNkF7l015218 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 13 Feb 2014 00:46:15 +0100 Received: from DEMUHTC004.nsn-intra.net ([10.159.42.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s1CNkF1k009788 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 13 Feb 2014 00:46:15 +0100 Received: from DEMUHTC011.nsn-intra.net (10.159.42.42) by DEMUHTC004.nsn-intra.net (10.159.42.35) with Microsoft SMTP Server (TLS) id 14.3.123.3; Thu, 13 Feb 2014 00:46:14 +0100 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.200]) by DEMUHTC011.nsn-intra.net ([10.159.42.42]) with mapi id 14.03.0123.003; Thu, 13 Feb 2014 00:46:14 +0100 From: "Ersue, Mehmet (NSN - DE/Munich)" To: ext Andy Bierman , Ambika Tripathy Thread-Topic: [Netconf] Practical use of extension. Thread-Index: AQHPKAqJACHZGNxgeEST3WakrxH9qZqxtfEAgAADSQCAAAFyAIAAjcZQ Date: Wed, 12 Feb 2014 23:46:13 +0000 Message-ID: References: <20140212155922.GB81507@elstar.local> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.99] Content-Type: multipart/alternative; boundary="_000_E4DE949E6CE3E34993A2FF8AE79131F8283DD4DEMUMBX005nsnintr_" MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 13655 X-purgate-ID: 151667::1392248775-000025D0-F1D203AC/0-0/0-0 Cc: "netmod@ietf.org" Subject: Re: [netmod] [Netconf] Practical use of extension. X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2014 23:46:23 -0000 --_000_E4DE949E6CE3E34993A2FF8AE79131F8283DD4DEMUMBX005nsnintr_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RFC 6095 defines some also some YANG extensions, which might be useful for = object oriented modeling. PS: I would suggest to move the discussion on YANG extensions to Netmod mai= llist. Cheers, Mehmet From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of ext Andy Bierm= an Sent: Wednesday, February 12, 2014 5:16 PM To: Ambika Tripathy Cc: Netconf Subject: Re: [Netconf] Practical use of extension. Hi, Since these external statements are outside of the YANG language, there is no definition in YANG for the syntax and semantics of external statements. Extensions are very useful within tool implementations to tag YANG definitions with additional metadata, in order to automate various functionality. Andy On Wed, Feb 12, 2014 at 8:11 AM, Ambika Tripathy > wrote: Hi Juergen, Thanks for your quick response. Section: 7.17, in page 98 of the rfc 6020 "The substatements of an extensio= n are defined by the extension, using some mechanism outside the scope of this specification. " Which is more confusing. What does it mean and what is the practical use of it in a YANG datastore?= do you have some other example. br, Ambika On Wed, Feb 12, 2014 at 9:29 PM, Juergen Schoenwaelder > wrote: On Wed, Feb 12, 2014 at 09:23:07PM +0530, Ambika Tripathy wrote: > Hi, > > I am going though YANG and Open DayLight implementation using YANG files = in > MD_SAL. > > I have one fundamental doubt to understand how extension is working. > > Could you please explain with some practical example using some yang > datastore concepts, how to use extension keyword in YANG and its usages. I suggest to read RFC 6020 section 7.17. In a nutshell, the extension statement allows to add a new statement to the YANG language. > Practically, I am referring > http://tools.ietf.org/id/draft-clemm-netmod-mount-01.txt and its extensio= n > defined in mound module and use in Appendix A. This may not be a good example to study. That document may be confusing the YANG extension statement (which adds keywords to the YANG reportoire) with runtime additions to a data store. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 -- Ambika Prasad Tripathy Cell @+91 9437547730/8553070866 Alt email: ambika_tripathy@yahoo.com ambika.tripathy@gmail.com skype:ambika_nethawk _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf --_000_E4DE949E6CE3E34993A2FF8AE79131F8283DD4DEMUMBX005nsnintr_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

RFC 6095 defines some als= o some YANG extensions, which might be useful for object oriented modeling.=

 <= /p>

PS: I would suggest to mo= ve the discussion on YANG extensions to Netmod maillist.<= /p>

 <= /p>

Cheers,
Mehmet

 <= /p>

From: Netconf = [mailto:netconf-bounces@ietf.org] On Behalf Of ext Andy Bierman
Sent: Wednesday, February 12, 2014 5:16 PM
To: Ambika Tripathy
Cc: Netconf
Subject: Re: [Netconf] Practical use of extension.=

 

Hi,

 

Since these external statements are outside of the Y= ANG language,

there is no definition in YANG for the syntax and se= mantics of

external statements.

 

Extensions are very useful within tool implementatio= ns to tag YANG

definitions with additional metadata, in order to au= tomate various

functionality.

 

 

Andy

 

 

On Wed, Feb 12, 2014 at 8:11 AM, Ambika Tripathy <= ;ambika.trip= athy@gmail.com> wrote:

Hi Juergen,

 

Thanks for your quick response.

 

Section: 7.17, in page 98 of the rfc 6020 "The = substatements of an extension

   are defined by the exten=
sion, using some mechanism outside the scope 

   of this specification. " Whic= h is more confusing.

 

What does it mean and  what is the practical us= e of it in a YANG datastore? do you have some other example.

 

br,

Ambika

 

 

 

On Wed, Feb 12, 2014 at 9:29 PM, Juergen Schoenwaeld= er <j.schoenwaelder@jacobs-university.de> wrote:

On Wed, Feb 12, 2014 = at 09:23:07PM +0530, Ambika Tripathy wrote:
> Hi,
>
> I am going though YANG and Open DayLight implementation using YANG fil= es in
> MD_SAL.
>
> I have one fundamental doubt to understand how extension is working. >
> Could you please explain with some practical example using some yang > datastore concepts, how to use extension keyword in YANG and its usage= s.

I suggest to read RFC 6020 section 7.17. In a nutshe= ll, the extension
statement allows to add a new statement to the YANG language.


> Practically, I am referring
> http://tools.ietf.org/id/draft-clemm-netmod-mount-01.txt and its extens= ion
> defined in mound module and use in Appendix A.

This may not be a good example to study. That docume= nt may be
confusing the YANG extension statement (which adds keywords to the
YANG reportoire) with runtime additions to a data store.

/js

--
Juergen Schoenwaelder         &n= bsp; Jacobs University Bremen gGmbH
Phone: +49 421 200 3587       &nb= sp; Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103      = ;   <http://www.jacobs-university.de/>



 

--

Ambika Prasad Tripathy=

Cell @+91 94375477= 30/8553070866

skype:ambika_nethawk


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

 

--_000_E4DE949E6CE3E34993A2FF8AE79131F8283DD4DEMUMBX005nsnintr_-- From nobody Thu Feb 13 10:33:30 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34E1A1A039F; Thu, 13 Feb 2014 10:33:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dEB7anUrnY77; Thu, 13 Feb 2014 10:33:25 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BA9F51A03B5; Thu, 13 Feb 2014 10:33:25 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140213183325.16175.99400.idtracker@ietfa.amsl.com> Date: Thu, 13 Feb 2014 10:33:25 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/Po1gizjuvQ5Tpa1awuzmJBtrNt4 Cc: netmod@ietf.org Subject: [netmod] I-D Action: draft-ietf-netmod-ip-cfg-13.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 18:33:27 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the NETCONF Data Modeling Language Working Group of the IETF. Title : A YANG Data Model for IP Management Author : Martin Bjorklund Filename : draft-ietf-netmod-ip-cfg-13.txt Pages : 32 Date : 2014-02-13 Abstract: This document defines a YANG data model for management of IP implementations. The data model includes configuration data and state data. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-ip-cfg/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-netmod-ip-cfg-13 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-ip-cfg-13 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Feb 13 10:37:47 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1B7F1A03C0; Thu, 13 Feb 2014 10:37:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eZqt5fNxwCe4; Thu, 13 Feb 2014 10:37:43 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 075651A0350; Thu, 13 Feb 2014 10:37:43 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140213183742.22640.14381.idtracker@ietfa.amsl.com> Date: Thu, 13 Feb 2014 10:37:42 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/3AcMCx3LhtA1H_53Jd1kJW0bYF0 Cc: netmod@ietf.org Subject: [netmod] I-D Action: draft-ietf-netmod-system-mgmt-12.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 18:37:45 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the NETCONF Data Modeling Language Working Group of the IETF. Title : A YANG Data Model for System Management Authors : Andy Bierman Martin Bjorklund Filename : draft-ietf-netmod-system-mgmt-12.txt Pages : 39 Date : 2014-02-13 Abstract: This document defines a YANG data model for the configuration and identification of some common system properties within a device containing a NETCONF server. This includes data node definitions for system identification, time-of-day management, user management, DNS resolver configuration, and some protocol operations for system management. 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-12 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-system-mgmt-12 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Feb 13 10:40:03 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFA771A03B3 for ; Thu, 13 Feb 2014 10:40:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t1GLQfHJLFei for ; Thu, 13 Feb 2014 10:39:58 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id 554B11A0383 for ; Thu, 13 Feb 2014 10:39:58 -0800 (PST) Received: from localhost (unknown [193.12.32.88]) by mail.tail-f.com (Postfix) with ESMTPSA id 580A537C20C for ; Thu, 13 Feb 2014 19:39:56 +0100 (CET) Date: Thu, 13 Feb 2014 19:39:55 +0100 (CET) Message-Id: <20140213.193955.368668169.mbj@tail-f.com> To: netmod@ietf.org From: Martin Bjorklund X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Mixed; boundary="--Next_Part(Thu_Feb_13_19_39_55_2014_279)--" Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/mxcp8JWgvo_-XbVRrTCl8ajingQ Subject: [netmod] Fw: I-D Action: draft-ietf-netmod-system-mgmt-12.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 18:40:01 -0000 ----Next_Part(Thu_Feb_13_19_39_55_2014_279)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, This version addresses the IETF LC comments we got. Specifically, it defines the timezone-name as a string instead of an enum. /martin ----Next_Part(Thu_Feb_13_19_39_55_2014_279)-- Content-Type: Message/Rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on roci X-Spam-Level: X-Spam-Status: No, score=-101.9 required=5.0 tests=BAYES_00,SPF_PASS, T_DKIM_INVALID,T_RP_MATCHES_RCVD,USER_IN_WHITELIST autolearn=ham version=3.3.2 X-Original-To: mbj@tail-f.com Delivered-To: mbj@tail-f.com Received: from mail.ietf.org (mail.ietf.org [4.31.198.44]) by mail.tail-f.com (Postfix) with ESMTP id A74A637C210; Thu, 13 Feb 2014 19:37:47 +0100 (CET) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F2661A03C0; Thu, 13 Feb 2014 10:37:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1392316667; bh=3siiw9WVcDOGZlC0NGd1W8X7jMajfaalE/77vkL8Kiw=; h=MIME-Version:From:To:Message-ID:Date:Cc:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=vd82C3VEZT67HDMe8bLOEL6Asxd5AX+kEkL7xLKizYHkbv76FvpPfhfSBCfA4mEqd V/Td8efH1zKHfMKBUgQBBQluDrgbzzY0DbVImcRQoNpp5wCBhiNdVC6+6AkOrTn+N0 8wfUCxVRG1Vbcri8XM8Ib2GS2gFCr6bAq3cWZ44w= X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1B7F1A03C0; Thu, 13 Feb 2014 10:37:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eZqt5fNxwCe4; Thu, 13 Feb 2014 10:37:43 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 075651A0350; Thu, 13 Feb 2014 10:37:43 -0800 (PST) MIME-Version: 1.0 From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140213183742.22640.14381.idtracker@ietfa.amsl.com> Date: Thu, 13 Feb 2014 10:37:42 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/3AcMCx3LhtA1H_53Jd1kJW0bYF0 Cc: netmod@ietf.org Subject: [netmod] I-D Action: draft-ietf-netmod-system-mgmt-12.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: netmod-bounces@ietf.org Sender: "netmod" X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.2 int cnt prob spamicity histogram 0.00 112 0.017149 0.015994 ################################################ 0.10 8 0.115568 0.023649 #### 0.20 0 0.000000 0.023649 0.30 0 0.000000 0.023649 0.40 0 0.000000 0.023649 0.50 0 0.000000 0.023649 0.60 0 0.000000 0.023649 0.70 0 0.000000 0.023649 0.80 0 0.000000 0.023649 0.90 1 0.904129 0.041215 # A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the NETCONF Data Modeling Language Working Group of the IETF. Title : A YANG Data Model for System Management Authors : Andy Bierman Martin Bjorklund Filename : draft-ietf-netmod-system-mgmt-12.txt Pages : 39 Date : 2014-02-13 Abstract: This document defines a YANG data model for the configuration and identification of some common system properties within a device containing a NETCONF server. This includes data node definitions for system identification, time-of-day management, user management, DNS resolver configuration, and some protocol operations for system management. 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-12 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-system-mgmt-12 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod ----Next_Part(Thu_Feb_13_19_39_55_2014_279)---- From nobody Thu Feb 13 11:08:22 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 865AA1A0415 for ; Thu, 13 Feb 2014 11:08:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8NoZuezeKZhf for ; Thu, 13 Feb 2014 11:08:17 -0800 (PST) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 2E1B11A034A for ; Thu, 13 Feb 2014 11:08:17 -0800 (PST) Received: from [192.168.1.122] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id CAF5F26EEB5D for ; Thu, 13 Feb 2014 14:08:15 -0500 (EST) From: Thomas Nadeau Content-Type: multipart/signed; boundary="Apple-Mail=_F08B97D3-B426-4C2C-8174-DCF32DDD91FE"; protocol="application/pgp-signature"; micalg=pgp-sha512 Message-Id: <1F03A8FA-25DD-43DF-AC77-C2F11F159275@lucidvision.com> Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) Date: Thu, 13 Feb 2014 14:08:14 -0500 References: <2A72C094-7CBC-474B-8413-8F60842142C8@lucidvision.com> To: netmod@ietf.org In-Reply-To: X-Mailer: Apple Mail (2.1827) Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/-sx7xIeUXJlofZAdumXwqqGl0Js Subject: Re: [netmod] consensus all: timezone-location and draft-ietf-netmod-iana-timezones-03 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 19:08:19 -0000 --Apple-Mail=_F08B97D3-B426-4C2C-8174-DCF32DDD91FE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi all, Apologies for not following up on this until now. I started my = new gig about a week ago and have been going full tilt. Anyways, I'd = like to make a final consensus call on this matter so that we can move = the draft forward.=20 After some decent discussion around the matter at hand, there = appears to be sufficient consensus to move forward with the proposal = below. I also see that Martin just posted an updated that aligns with = this, so I think we are all set to move forward. --Tom >=20 > I would like to call consensus on this matter. I've received = %100 supporting comments for the proposal from the WG with no one not = liking the proposal. The only comments received were from Martin and = Benoit with regard to enhancing the description around the timezone-name = typedef. Document editors, please take those two comments into account = and make the changes necessary. You might want to propose the text on = the list before publishing as it should be a fairly minor change, but = just to make sure it covers the comments received. >=20 > --Tom >=20 >=20 >>=20 >> Netmod WG: >>=20 >> The working group chairs have considered the discussion = concerning=20 >> the timezone-location leaf in draft-ietf-netmod-system-mgmt-10 and >> draft-ietf-netmod-iana-timezones-03. In particular, we would like >> like to call consensus on the matter regarding that surfaced during >> the IETF last call with regard to the the practicability of = maintaining a=20 >> YANG module with an enumeration of timezone names. We believe there = is >> consensus in the working group to move forward with the following=20 >> resolution: >>=20 >> - The YANG module in draft-ietf-netmod-system-mgmt-11 gets >> extended to introduce a new typedef for timezone names, e.g. >> something that looks like: >>=20 >> typedef timezone-name { >> type string; >> description >> "A timezone name as used by the Time Zone Database, sometimes >> referred to as the 'Olson Database'."; >> reference >> "RFC 6557: Procedures for Maintaining the Time Zone Database"; >> } >>=20 >> The timezone-location leaf will be changed to use this type, >> the import of iana-timezones will be removed and the references >> to I-D.ietf-netmod-iana-timezones will be removed. >>=20 >> - The draft-ietf-netmod-iana-timezones-00 document will be pulled >> back and work on this draft will stop. The I-D is declared dead. >>=20 >> - Since there is nothing to do for IANA, there will be no IANA = request=20 >> needed in this regard for draft-ietf-netmod-system-mgmt-11.=20 >>=20 >> We note that further alternatives can be added to the timezone >> choice in the future should the two mechanisms currently in place >> turn out to be insufficient in practice. >>=20 >> We would like to give the WG sufficient time to raise any = additional concerns or=20 >> issues with regard to this issue and our path for resolving the issue = at hand, and so we=20 >> will accept comments/discussion on this matter until 8AM EDT on = Tuesday, January 28, 2014. >> As Juergen has been closely involved with the matter, I will = adjudicate any issues >> arising from this comment period. >>=20 >> Thanks, >>=20 >> Tom >>=20 >>=20 >>=20 >>=20 >=20 --Apple-Mail=_F08B97D3-B426-4C2C-8174-DCF32DDD91FE Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIbBAEBCgAGBQJS/RgeAAoJEPcO+I7eiUJZYwAP91cS898bpPpsapXA+9mbAbza pvYrGAvcYGO7rmaVfXiWy5JK31wRReBzkAGjSMz2rPcrNkDz8zed9Zs/0wWt0rQv 8kyT0CUQXKP6JpWovGtba/d6GeZfqaf8mZREuDtpZge6Ug/HN5OqBWRfA7WSZ2D6 QS5fKGwUqE6cQ27bstCZvV41A1Zpn29T9Tw2yA/uPgtDLqjsICWe/M3JKVjNz7yO ZqxIoy/Fd0rsCTqOZaunS2zpQS85VAbQl7EHmid7Ay1aewFTW72qKG2ltkKTVwn4 n26LU2bTEiTUpZiyRDBXHU7wR3hr3O7gPbRCdaSyfeJrz7KTvB4RDC+m8/ls6nJr 92j3qDkumt1R7YSFxDVdBRiMDGhN1nyLE8HXh/4lFdEfzsGy2wpcVmFWplCnHwBk iwNCKRGWPtCC8Jg1SCy5Vck5Win5ap5+En7lnSzhKPdJ5ivYTzJN2RdNMV50khS+ 6qcY7HX5QPvjTPJERQdvb+RpTD7ksnGR24ENJtIZzAoT+7fYeLMGYPmkW3AKiA/L xKs5YD09Huc2y8XRZhbNEC+Tua3qJbrACh/i2sVHsSsU1XIhqgV51F7Nh14WQEYk G6NYwUyorDA5MP+Ic/DdeGS2OVZmGwbQPrxp/E8V919tR4YR2GH5eJYs7/t5DUa3 H4uD/GxG0jgQXu58wJY= =AKVd -----END PGP SIGNATURE----- --Apple-Mail=_F08B97D3-B426-4C2C-8174-DCF32DDD91FE-- From nobody Thu Feb 13 17:41:39 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 638191A0058 for ; Thu, 13 Feb 2014 17:41:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mwft1n8qK_9k for ; Thu, 13 Feb 2014 17:41:36 -0800 (PST) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 1A7721A0016 for ; Thu, 13 Feb 2014 17:41:36 -0800 (PST) Received: from [192.168.1.122] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id BC46826EFBCA for ; Thu, 13 Feb 2014 20:41:34 -0500 (EST) From: Thomas Nadeau Content-Type: multipart/signed; boundary="Apple-Mail=_982EBBE2-5143-4F26-A98F-E7D5ABC595BF"; protocol="application/pgp-signature"; micalg=pgp-sha512 Date: Thu, 13 Feb 2014 20:41:34 -0500 References: <52FD65DD.4090609@cisco.com> To: netmod@ietf.org Message-Id: <876DDDF4-C991-4C03-81C3-81417F48FE0A@lucidvision.com> Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) X-Mailer: Apple Mail (2.1827) Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/qf0nwO4U9Q8t-XmdxPQCAEDOBek Subject: [netmod] Fwd: [OPS-AREA] configuration: writable MIB modules versus NETCONF/YANG modules X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 01:41:38 -0000 --Apple-Mail=_982EBBE2-5143-4F26-A98F-E7D5ABC595BF Content-Type: multipart/alternative; boundary="Apple-Mail=_908FE5E4-BCDD-4949-A4E5-4361DC975A11" --Apple-Mail=_908FE5E4-BCDD-4949-A4E5-4361DC975A11 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 FYI in case you are not on the ops dir list... --Tom Begin forwarded message: > From: Benoit Claise > Subject: [OPS-AREA] configuration: writable MIB modules versus = NETCONF/YANG modules > Date: February 13, 2014 at 7:39:57 PM EST > To: "ops-area@ietf.org" >=20 > Dear all, >=20 > We occasionally see read-write MIB module proposals within the IETF. > However, the write capabilities of those MIB modules are rarely = implemented. >=20 > While discussing this issue with the MIB doctors, we arrive to the = conclusion that it's now time to set the direction for future MIB = developments within the IETF. Basically, let's not specify read-write = MIB modules unless we have a good reason. Read-only MIB modules are = still fine though, as SNMP is clearly used for monitoring purposes. >=20 > Here is the statement we came up with: > The OPS area recommends the use of NETCONF/YANG standards for = configuration. IETF working groups are therefore encouraged to use the = NETCONF/YANG standards for configuration, specifically in new charters. = SNMP MIB modules modifying persistent configuration state should only be = produced by working groups in cases of clear utility=20 > and consensus to use SNMP write operations for configuration. > Ideally, this should become an IESG statement. > Your feedback is most welcome. >=20 > Regards, the MIB doctors & Benoit >=20 > _______________________________________________ > OPS-AREA mailing list > OPS-AREA@ietf.org > https://www.ietf.org/mailman/listinfo/ops-area --Apple-Mail=_908FE5E4-BCDD-4949-A4E5-4361DC975A11 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1

FYI in case you are not on the = ops dir list...

= --Tom


Begin forwarded = message:

From: = Benoit Claise <bclaise@cisco.com>
Subject: [OPS-AREA] configuration: writable = MIB modules versus NETCONF/YANG modules
Date: February 13, 2014 at 7:39:57 PM = EST
To: = "ops-area@ietf.org" <ops-area@ietf.org>

=20 =20
Dear all,

We occasionally see read-write MIB module proposals within the = IETF.
However, the write capabilities of those MIB modules are rarely implemented.

While discussing this issue with the MIB doctors, we arrive to the conclusion that it's now time to set the direction for future MIB developments within the IETF. Basically, let's not specify read-write MIB modules unless we have a good reason. Read-only MIB modules are still fine though, as SNMP is clearly used for monitoring purposes.

Here is the statement we came up with:
The OPS area recommends the use of NETCONF/YANG standards for configuration. IETF working groups are therefore encouraged to use the NETCONF/YANG standards for configuration, specifically in new charters. SNMP MIB modules modifying persistent configuration state should only be produced by working groups in cases of clear utility
and consensus to use SNMP write operations for configuration.
Ideally, this should become an IESG statement.
Your feedback is most welcome.

Regards, the MIB doctors & Benoit

_______________________________________________
OPS-AREA mailing = list
OPS-AREA@ietf.org
https://www.iet= f.org/mailman/listinfo/ops-area

= --Apple-Mail=_908FE5E4-BCDD-4949-A4E5-4361DC975A11-- --Apple-Mail=_982EBBE2-5143-4F26-A98F-E7D5ABC595BF Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJS/XROAAoJEPcO+I7eiUJZcyoP/0163BpKhm4FrNLaVbi78Eb7 BAo2wG5zQfs1I1biODZNO8LjKlSsqfUEVz/4pDl39WWTSy1ZcYe+us1yQ97RSwb8 GnEHsO1LPPtFjsHIWS/Wpy3vpMym+XRjy8pQaIRewtlzAaYskYYoPss/0xSVhx36 BUr3bqul0pk8hDJxnf6P58Di4Wgw2ZC0LfMLEqZelfXmIRruGEPWcdzBfIh3eSya r9P448TUAOtArRsBidH71ox+TsjGpLlWPX98Vx8y78edxPEBrfclBk/79Ewf8Sju f12HM0EgPXf3bnfCbtibdwVuEzzRSvDukc9fhivbTT4G5XZSrEzZPaDaJPGMeA48 IbqTTAIXo69uWK3G1vp52/yysefRWvGQdK+ro62VlC/OWn2E8mgvLg1/AfZenhno fuWTTiEKxiZgv10h2i8v0tKyMw35gZXnJcb43QX9skuSt+T4Nomk21bqa9cz1Hb4 ljwTWqDfqXelKjJGqTXdqNxY14squmVsli5g8kI6cp5UqaEO4io747lPbEkAoz33 ItRJfScDQf+XgIbX4T6QD5VvnynOxcetG7UcpqpSz7HB/ApyxNqsxhzqJPRzN0+s o4Cc0ROc0vBrvp/A2M0IkAsdGspCEeoxsWKAmQQ5H/DdF+u/cACLRaUellrG/qPo P8h/l5nvh0BdTcKofou4 =A76f -----END PGP SIGNATURE----- --Apple-Mail=_982EBBE2-5143-4F26-A98F-E7D5ABC595BF-- From nobody Fri Feb 14 13:18:15 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4713B1A042C for ; Fri, 14 Feb 2014 13:18:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nkuyiN7EksFg for ; Fri, 14 Feb 2014 13:18:09 -0800 (PST) Received: from mail-qc0-f171.google.com (mail-qc0-f171.google.com [209.85.216.171]) by ietfa.amsl.com (Postfix) with ESMTP id A94781A03DD for ; Fri, 14 Feb 2014 13:18:09 -0800 (PST) Received: by mail-qc0-f171.google.com with SMTP id n7so20949799qcx.16 for ; Fri, 14 Feb 2014 13:18:08 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=ELxa1hw9K0C7aC4FijHWdLzZSreeOiuMBFH8RHmayC4=; b=M0AF4zRHGh5tpDivugHGT7ji4DJsjQvA03CPe27xlZaLhtRcu9BKKfbMvB8KLeP6kv IlFEtj+arPo01sERUQYiobPiEA8hwVcjlPvxk3+LhnfN/vXzPF7EN8lrWtvLzDZE0Y7O bVdzoYvgc4TG4hfGKK9RiYtfQHcEVxSZq5F9JXhe9/lNHWYhxv54HDdkWMw0JCFfrU8p ch3HmmtY9sP0o62mNoL3dTzO7xCBfcbJnvMpNvfJENvVyJeMRkQOZl9iQuH/RRkmtrfD y2xoFTciqkJL41HT7LAkcOcOuDY7lUqpIX5DyKsfVUR8kVawera3xD1xbUZrnEZfFtv7 ztqA== X-Gm-Message-State: ALoCoQmSu8IfnBSyFeghijlpjCpJOvUBN+xei0Qq2tMwDXF+coIfDf49Cqx7TVm0K5Gsg8F418Y8 MIME-Version: 1.0 X-Received: by 10.140.36.107 with SMTP id o98mr16155877qgo.25.1392412687979; Fri, 14 Feb 2014 13:18:07 -0800 (PST) Received: by 10.140.98.130 with HTTP; Fri, 14 Feb 2014 13:18:07 -0800 (PST) In-Reply-To: <20140214210449.5780.58107.idtracker@ietfa.amsl.com> References: <20140214210449.5780.58107.idtracker@ietfa.amsl.com> Date: Fri, 14 Feb 2014 13:18:07 -0800 Message-ID: From: Andy Bierman To: "netmod@ietf.org" Content-Type: multipart/alternative; boundary=001a11c154b6a5eaf004f26457fe Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/QA5zAVQJGQ6mSofFuNaSg9fKtTM Subject: [netmod] Fwd: I-D Action: draft-bierman-netmod-rfc6087bis-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 21:18:12 -0000 --001a11c154b6a5eaf004f26457fe Content-Type: text/plain; charset=ISO-8859-1 FYI, I have posted an update to the YANG Guidelines RFC. See section 8 for the specific changes. I would like the WG to discuss this draft on the mailing list, to determine if we should keep obsolete guidelines or update the guidelines RFC to reflect best current practices. If any guidelines are incorrect or missing, then please bring up these issues on the mailing list. There are relatively few changes made, so I am hoping the NETMOD charter can include this update to RFC 6087. Andy ---------- Forwarded message ---------- From: Date: Fri, Feb 14, 2014 at 1:04 PM Subject: I-D Action: draft-bierman-netmod-rfc6087bis-00.txt To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Guidelines for Authors and Reviewers of YANG Data Model Documents Author : Andy Bierman Filename : draft-bierman-netmod-rfc6087bis-00.txt Pages : 32 Date : 2014-02-14 Abstract: This memo provides guidelines for authors and reviewers of Standards Track specifications containing YANG data model modules. Applicable portions may be used as a basis for reviews of other YANG data model documents. Recommendations and procedures are defined, which are intended to increase interoperability and usability of Network Configuration Protocol (NETCONF) implementations that utilize YANG data model modules. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-bierman-netmod-rfc6087bis/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-bierman-netmod-rfc6087bis-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ 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 --001a11c154b6a5eaf004f26457fe Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
FYI,

I have posted an update to the YAN= G Guidelines RFC.
See section 8 for the specific changes.

I would like the WG to discuss this draft on the mailing = list,
to determine if we should keep obsolete guidelines or update
the guidelines RFC to reflect best current practices.

=
If any guidelines are incorrect or missing, then please
bring up these issues on the mailing list.

There a= re relatively few changes made, so I am hoping
the NETMOD charter= can include this update to RFC 6087.


Andy

---------- Forwarded mes= sage ----------
From: <internet-drafts@ietf.org= >
Date: Fri, Feb 14, 2014 at 1:04 PM
Subject: I-D Action: draft-bierman-ne= tmod-rfc6087bis-00.txt
To: i-d-= announce@ietf.org



A New Internet-Draft is available from the on-line Internet-Drafts director= ies.


=A0 =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : Guidelines for Authors and Revi= ewers of YANG Data Model Documents
=A0 =A0 =A0 =A0 Author =A0 =A0 =A0 =A0 =A0: Andy Bierman
=A0 =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-bierman-netmod-rfc6087bis-0= 0.txt
=A0 =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 32
=A0 =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2014-02-14

Abstract:
=A0 =A0This memo provides guidelines for authors and reviewers of Standards=
=A0 =A0Track specifications containing YANG data model modules. =A0Applicab= le
=A0 =A0portions may be used as a basis for reviews of other YANG data model=
=A0 =A0documents. =A0Recommendations and procedures are defined, which are<= br> =A0 =A0intended to increase interoperability and usability of Network
=A0 =A0Configuration Protocol (NETCONF) implementations that utilize YANG =A0 =A0data model modules.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-bierman-netmod-= rfc6087bis/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-bierman-netmod-rfc6087bis= -00


Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

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

_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d= -announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or = ftp://ftp.ietf.org/ietf/1shadow-sites.txt

--001a11c154b6a5eaf004f26457fe-- From nobody Fri Feb 14 15:38:29 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1B361A050F for ; Fri, 14 Feb 2014 15:38:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.048 X-Spam-Level: X-Spam-Status: No, score=-15.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lYw3tQtFiA6E for ; Fri, 14 Feb 2014 15:38:24 -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 518611A0509 for ; Fri, 14 Feb 2014 15:38:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3594; q=dns/txt; s=iport; t=1392421104; x=1393630704; h=from:to:cc:subject:date:message-id:mime-version; bh=hs1bd+TVfU5WY1I43ASZtwPEdpL0OvWFoJQ4avAD1MA=; b=jeEIp+cJXH4P5WkyFlR3QERvTfyJ6Ogh0Z8Gc1/PVb2bzpFpLmJFVrKS YMk+VR6uKjkmddfuRkb0A+z+BvrVjiLaMZC3QRYRdcseMrtkDjGGoYLqG smpRaJAbFJzZnG/zLDT0NQLF2BmDYA6WkzjVpUGi3bqzTmkUNlOxBUqDS Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhwFADio/lKtJV2Y/2dsb2JhbABZgkREOFW8coEYFgF0g38BBC1MEgEMHlYmAQQODYd8DcBRF45hMYMqgRMEmUaQZIMrgio X-IronPort-AV: E=Sophos;i="4.95,848,1384300800"; d="scan'208,217";a="301195083" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-9.cisco.com with ESMTP; 14 Feb 2014 23:38:23 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s1ENcMJh030145 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 14 Feb 2014 23:38:22 GMT Received: from xmb-rcd-x05.cisco.com ([169.254.15.164]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.03.0123.003; Fri, 14 Feb 2014 17:38:21 -0600 From: "Alexander Clemm (alex)" To: "netmod@ietf.org" Thread-Topic: draft-huang-netmod-acl (Stateless Packet Filter Configuration) Thread-Index: Ac8p3MNd9/3j+HV/QOKxnW25dyL46A== Date: Fri, 14 Feb 2014 23:38:21 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.154.212.13] Content-Type: multipart/alternative; boundary="_000_DBC595ED2346914F9F81D17DD5C32B5718690611xmbrcdx05ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/TUO9WUsBRkW3v3gakbDjsw3zz28 Subject: [netmod] draft-huang-netmod-acl (Stateless Packet Filter Configuration) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 23:38:26 -0000 --_000_DBC595ED2346914F9F81D17DD5C32B5718690611xmbrcdx05ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Netmod Working Group, we are happy to see that stateless packet filter configuration is likely pa= rt of the newly revised charter. We have not posted an update to the current draft (http://tools.ietf.org/ht= ml/draft-huang-netmod-acl-03), as we think that the current draft addresses= all comments that were previously raised by the working group. However, t= here has not been discussion on this subject recently. If you have additio= nal comments, let's discuss them, otherwise we would like to see the docume= nt take the "next step". Thank you and kind regards --- Alex (on behalf of Lisa, Andy) --_000_DBC595ED2346914F9F81D17DD5C32B5718690611xmbrcdx05ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello Netmod Working Group,

 

we are happy to see that stateless packet filter con= figuration is likely part of the newly revised charter. 

 

We have not posted an update to the current draft (h= ttp://tools.ietf.org/html/draft-huang-netmod-acl-03), as we think that the = current draft addresses all comments that were previously raised by the wor= king group.  However, there has not been discussion on this subject recently.  If you have additional com= ments, let’s discuss them, otherwise we would like to see the documen= t take the “next step”. 

 

Thank you and kind regards

--- Alex (on behalf of Lisa, Andy)

--_000_DBC595ED2346914F9F81D17DD5C32B5718690611xmbrcdx05ciscoc_-- From nobody Mon Feb 17 07:26:42 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC4211A0211 for ; Mon, 17 Feb 2014 07:26:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.403 X-Spam-Level: X-Spam-Status: No, score=-6.403 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.793, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yY1xjDVdQMNm for ; Mon, 17 Feb 2014 07:26:37 -0800 (PST) Received: from aer-iport-4.cisco.com (unknown [173.38.203.54]) by ietfa.amsl.com (Postfix) with ESMTP id 16BFC1A020C for ; Mon, 17 Feb 2014 07:26:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6551; q=dns/txt; s=iport; t=1392650792; x=1393860392; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=L1QmgNccr1Z6/lNvzOgvVJr/b4DwG8y0ZFxtE7a2Jbo=; b=SSbVKyXth5pQjMh9MgSzGKk+NX+JN4cTKIFrCtc0+bsjv2QfLstN2uYg YNrOxBQJpGEsR7en+FtcCrj0wCPK5nDrMVGcb070vDiw1bly/U9jNIPGk RoafcJ4zQIX0yygoRNU6nY8m06g3+HpDAbQQnm5mriL2o3JTl1xpwQaBQ U=; X-IronPort-AV: E=Sophos;i="4.95,861,1384300800"; d="scan'208,217";a="562348" Received: from ams-core-4.cisco.com ([144.254.72.77]) by aer-iport-4.cisco.com with ESMTP; 17 Feb 2014 15:26:31 +0000 Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s1HFQTs2028943; Mon, 17 Feb 2014 15:26:29 GMT Message-ID: <53022A25.4060305@cisco.com> Date: Mon, 17 Feb 2014 15:26:29 +0000 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "Alexander Clemm (alex)" , Ladislav Lhotka , =?ISO-8859-1?Q?J=FCrgen_Sch=F6nw=E4lder?= References: <20140202135609.GA35596@elstar.local> <20140204094258.GA42890@elstar.local> <99860237-B703-43F1-A511-AD87760B9872@nic.cz> In-Reply-To: Content-Type: multipart/alternative; boundary="------------060306030403030303010601" Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/Vt6QNY_eJLkc2aX6-Sjz8qtJBIA Cc: "netmod@ietf.org" Subject: Re: [netmod] charter revision - please comment on charter-ietf-netmod-06-05 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2014 15:26:39 -0000 This is a multi-part message in MIME format. --------------060306030403030303010601 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Hi Alex, > I also agree that the WG should be flexible to take on new data models without having to recharter. The current wording does not seem to express this clearly; I had the same question as Lada and think some clarification would be good. I believe that this is covered by: ... and developing data models that are considered core building blocks and that do not fall into charters of other active IETF working groups (for example a data model for stateless packet filters). Regards, Benoit > --- Alex > > -----Original Message----- > From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Ladislav Lhotka > Sent: Tuesday, February 04, 2014 2:02 AM > To: Jürgen Schönwälder > Cc: netmod@ietf.org > Subject: Re: [netmod] charter revision - please comment on charter-ietf-netmod-06-05 > > > On 04 Feb 2014, at 10:42, Juergen Schoenwaelder wrote: > >> On Tue, Feb 04, 2014 at 10:33:11AM +0100, Ladislav Lhotka wrote: >>> 2. Is it intentional that no specific new data models are mentioned, except the stateless packet filter example? A few items are already on the table. >>> >> The idea was to let the charter be flexible such that the WG can take >> on data models without having to recharter. From what has been > OK, it this is possible, then it's fine. > > Lada > >> proposed, the stateless packet filter work seems to be a relatively >> clear cut case. The topology work interacts with the information >> model work submitted by the same authors to I2RS so it seems we need >> to figure out where this work will be entertained. The other proposals >> do not really seem to be mature enough to work on them at this point >> in time. >> >> /js >> >> -- >> Juergen Schoenwaelder Jacobs University Bremen gGmbH >> Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany >> Fax: +49 421 200 3103 > -- > 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 > . > --------------060306030403030303010601 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Hi Alex,
I also agree that the WG should be flexible to take on new data models without having to recharter.  The current wording does not seem to express this clearly; I had the same question as Lada and think some clarification would be good.
I believe that this is covered by:
... and developing data
models that are considered core building blocks and that do not
fall into charters of other active IETF working groups (for example
a data model for stateless packet filters).
Regards, Benoit

    

      
--- Alex

-----Original Message-----
From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Ladislav Lhotka
Sent: Tuesday, February 04, 2014 2:02 AM
To: Jürgen Schönwälder
Cc: netmod@ietf.org
Subject: Re: [netmod] charter revision - please comment on charter-ietf-netmod-06-05


On 04 Feb 2014, at 10:42, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:



      

        
On Tue, Feb 04, 2014 at 10:33:11AM +0100, Ladislav Lhotka wrote:


        

          
2. Is it intentional that no specific new data models are mentioned, except the stateless packet filter example? A few items are already on the table.



        

        
The idea was to let the charter be flexible such that the WG can take 
on data models without having to recharter. From what has been


      

      
OK, it this is possible, then it's fine.

Lada



      

        
proposed, the stateless packet filter work seems to be a relatively 
clear cut case.  The topology work interacts with the information 
model work submitted by the same authors to I2RS so it seems we need 
to figure out where this work will be entertained. The other proposals 
do not really seem to be mature enough to work on them at this point 
in time.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>


      

      
--
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
.



    

    

  


--------------060306030403030303010601--


From nobody Tue Feb 18 13:08:13 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 944A91A053D for ; Tue, 18 Feb 2014 13:08:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.048
X-Spam-Level: 
X-Spam-Status: No, score=-10.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZL_ZmCQ9Sfoc for ; Tue, 18 Feb 2014 13:08:09 -0800 (PST)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) by ietfa.amsl.com (Postfix) with ESMTP id 00C0C1A0228 for ; Tue, 18 Feb 2014 13:08:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2083; q=dns/txt; s=iport; t=1392757686; x=1393967286; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=LRL6YkprKTy4gDILft6QF5N3SgD5k3cDgnKcMH+3Dtk=; b=Fmn1HlhEQFsdBVMnnkYK4XZ8VWF+BCx8i4AZyW8kwFfVNHXxrQUQbFJ5 zB4ze88Vf+QSJw7Gdmjie9vG9FZ5QtUICtl69UKCRw4W7QNpdQg2qHlmM k9ycho8SKVvqHRwBE+GjSkCbcFk33n7P2dFuHjsMj6mz/lLR9pkbEMccP o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Am8FAPjKA1OQ/khN/2dsb2JhbABZgwY4iTa3C0+BIBZ0giYBAQQBAQFrChELBAEJExYPCQMCAQIBFTAGAQwGAgEBiAENyzsTBI5rhDgEmDCGR4tdgy47
X-IronPort-AV: E=Sophos;i="4.97,503,1389744000"; d="scan'208,217";a="4754337"
Received: from ams-core-4.cisco.com ([144.254.72.77]) by aer-iport-2.cisco.com with ESMTP; 18 Feb 2014 21:08:05 +0000
Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s1IL84Dr027160; Tue, 18 Feb 2014 21:08:04 GMT
Message-ID: <5303CBB4.3070707@cisco.com>
Date: Tue, 18 Feb 2014 22:08:04 +0100
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: Martin Bjorklund , netmod@ietf.org
References: <20140213.193955.368668169.mbj@tail-f.com>
In-Reply-To: <20140213.193955.368668169.mbj@tail-f.com>
Content-Type: multipart/alternative; boundary="------------020902040702040706070104"
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/ZQhT5qzM5NEjkBQKBDaEXUr2HZo
Subject: Re: [netmod] Fw:  I-D Action: draft-ietf-netmod-system-mgmt-12.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 18 Feb 2014 21:08:11 -0000

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

Hi Martin, Andy,

1.

   import iana-timezones {
        prefix ianatz;
      }

Should be removed

2.
I propose to mark draft-ietf-netmod-iana-timezones-03 as dead?


Regards, Benoit
> Hi,
>
> This version addresses the IETF LC comments we got.  Specifically, it
> defines the timezone-name as a string instead of an enum.
>
>
> /martin
>
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


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


  
    
  
  
    
Hi Martin, Andy,

      

      1.

      
  import iana-timezones {
       prefix ianatz;
     }

      Should be removed

      

      2.

      I propose to mark draft-ietf-netmod-iana-timezones-03 as dead?

      

      

      Regards, Benoit

    

    

      
Hi,

This version addresses the IETF LC comments we got.  Specifically, it
defines the timezone-name as a string instead of an enum.


/martin



      

      

      

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


    

    

  


--------------020902040702040706070104--


From nobody Tue Feb 18 13:18:18 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD8FC1A0254 for ; Tue, 18 Feb 2014 13:18:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.449
X-Spam-Level: 
X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oey9OKWJ8CDQ for ; Tue, 18 Feb 2014 13:18:14 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id E91F31A0220 for ; Tue, 18 Feb 2014 13:18:13 -0800 (PST)
Received: from localhost (unknown [193.12.32.88]) by mail.tail-f.com (Postfix) with ESMTPSA id 40ED837C232; Tue, 18 Feb 2014 22:18:10 +0100 (CET)
Date: Tue, 18 Feb 2014 22:18:09 +0100 (CET)
Message-Id: <20140218.221809.448208778.mbj@tail-f.com>
To: bclaise@cisco.com
From: Martin Bjorklund 
In-Reply-To: <5303CBB4.3070707@cisco.com>
References: <20140213.193955.368668169.mbj@tail-f.com> <5303CBB4.3070707@cisco.com>
X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/DLH6RUhBN4cSAfR20xEvpE_glzM
Cc: netmod@ietf.org
Subject: Re: [netmod] Fw: I-D Action: draft-ietf-netmod-system-mgmt-12.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 18 Feb 2014 21:18:15 -0000

Benoit Claise  wrote:
> Hi Martin, Andy,
> 
> 1.
> 
>   import iana-timezones {
>        prefix ianatz;
>      }
> 
> Should be removed

Hmpf.  When will I learn to run "make validate" before I post a
draft...

> 2.
> I propose to mark draft-ietf-netmod-iana-timezones-03 as dead?

Yes.


/martin


From nobody Tue Feb 18 14:20:51 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 315F41A0414 for ; Tue, 18 Feb 2014 14:20:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.703
X-Spam-Level: 
X-Spam-Status: No, score=-6.703 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, BODY_URI_ONLY=0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.793, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FhuIlq8F3SYP for ; Tue, 18 Feb 2014 14:20:49 -0800 (PST)
Received: from aer-iport-3.cisco.com (unknown [173.38.203.53]) by ietfa.amsl.com (Postfix) with ESMTP id 1E2111A0407 for ; Tue, 18 Feb 2014 14:20:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17; q=dns/txt; s=iport; t=1392762046; x=1393971646; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=/arwFErP0t6d5869rZT3o0Px8DsJ6PsqfbDRb8UlZTk=; b=awXsLOZZGVQn6k5i1DwN09iYJ73+jOnPp7LfxW+wb5L1YM64byY2h0kj WLt68krrI4btc+BXGfN+0zb5yhJM4zrpJWOGdOp9UMYjhftku17WLLbRt DwurY/mHbCTyILdxflzBrhlWnKAqTvJHCCADqELST2waktC3H1Y4ynX75 U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgcFAFDcA1OQ/khR/2dsb2JhbABZgwbCbxZ0gkUfQD0WGAMCAQIBSw0IAQGIAZt/r1wXkyMBA5gwhkeLXYMuOw
X-IronPort-AV: E=Sophos;i="4.97,503,1389744000";  d="scan'208";a="670162"
Received: from ams-core-1.cisco.com ([144.254.72.81]) by aer-iport-3.cisco.com with ESMTP; 18 Feb 2014 22:20:45 +0000
Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s1IMKjbO007949 for ; Tue, 18 Feb 2014 22:20:45 GMT
Message-ID: <5303DCBD.6080404@cisco.com>
Date: Tue, 18 Feb 2014 23:20:45 +0100
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: NETMOD Working Group 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/2daBi8ee9BSckrbUQqFlJD8B5dM
Subject: [netmod] draft-ietf-netmod-iana-timezones-03 has been marked Dead
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 18 Feb 2014 22:20:50 -0000

Regards, Benoit


From nobody Tue Feb 18 14:49:46 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3C3B1A04E5; Tue, 18 Feb 2014 14:49:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.89
X-Spam-Level: 
X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_TVD_MIME_NO_HEADERS=0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rP8sYf0g5wHS; Tue, 18 Feb 2014 14:49:43 -0800 (PST)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1115D1A02CE; Tue, 18 Feb 2014 14:49:43 -0800 (PST)
MIME-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
From: Internet-Drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 5.0.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20140218224942.16642.55931.idtracker@ietfa.amsl.com>
Date: Tue, 18 Feb 2014 14:49:42 -0800
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/PK8FCBc0tzzDSZCsTwN1nbp4P2g
Cc: netmod@ietf.org
Subject: [netmod] I-D ACTION:draft-ietf-netmod-system-mgmt-13.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 18 Feb 2014 22:49:45 -0000

--NextPart

A new Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the NETCONF Data Modeling Language Working Group of the IETF.

    Title         : A YANG Data Model for System Management
    Author(s)     : A. Bierman, et al
    Filename      : draft-ietf-netmod-system-mgmt
    Pages         : 39 
    Date          : 2014-02-18 
    
   This document defines a YANG data model for the configuration and
   identification of some common system properties within a device
   containing a NETCONF server.  This includes data node definitions for
   system identification, time-of-day management, user management, DNS
   resolver configuration, and some protocol operations for system
   management.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-netmod-system-mgmt-13.txt

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

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body; name="draft-ietf-netmod-system-mgmt";
 site="ftp.ietf.org"; access-type="anon-ftp";
 directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2014-02-18144942.I-D@ietf.org>


--NextPart--


From nobody Tue Feb 18 15:06:56 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CD751A040A for ; Tue, 18 Feb 2014 15:06:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.704
X-Spam-Level: 
X-Spam-Status: No, score=-6.704 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.793, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XSOlaot269we for ; Tue, 18 Feb 2014 15:06:53 -0800 (PST)
Received: from aer-iport-4.cisco.com (unknown [173.38.203.54]) by ietfa.amsl.com (Postfix) with ESMTP id 2A4FF1A0406 for ; Tue, 18 Feb 2014 15:06:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=151; q=dns/txt; s=iport; t=1392764810; x=1393974410; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=dsBzcdWQNTMZaxmdUhkZCv24ibaRqOhJjXIrOkdP/qM=; b=U/Mg/FG/fYCQRAkENXLK4hA5gJwZs6dgozY9Otd8f5VJdPtA3s/i34/Q YucM1DkmzSl74HTF3xkAe7xGEDf3Cl0uHWqTlNnGBLEPjp16VYRY/DcAW qG6xFd/539FHZxvjrt8fLkxioBj9dQEba2F4MEm9WKpD5sqRmJoz03sG2 E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgcFANrmA1OQ/khN/2dsb2JhbABZgwbCcBZ0gmR9NAJMDQgBAYgBnA2wTReTIwSYMIZHi12DLjs
X-IronPort-AV: E=Sophos;i="4.97,503,1389744000";  d="scan'208";a="672122"
Received: from ams-core-4.cisco.com ([144.254.72.77]) by aer-iport-4.cisco.com with ESMTP; 18 Feb 2014 23:06:49 +0000
Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s1IN6noI032077 for ; Tue, 18 Feb 2014 23:06:49 GMT
Message-ID: <5303E789.90908@cisco.com>
Date: Wed, 19 Feb 2014 00:06:49 +0100
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: NETMOD Working Group 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/lBHl0Z100l9P3bGWU19pPFtStZ8
Subject: [netmod] draft-ietf-netmod-system-mgmt-13 on the IESG telechat
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 18 Feb 2014 23:06:54 -0000

Dear all,

draft-ietf-netmod-system-mgmt-13 is on the IESG telechat, on March 20th.
Thanks to all for progressing the TZ issue.

Regards, Benoit


From nobody Thu Feb 20 05:41:43 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A91EB1A0172 for ; Thu, 20 Feb 2014 05:41:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.548] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cBLDRwXxBBlC for ; Thu, 20 Feb 2014 05:41:39 -0800 (PST)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) by ietfa.amsl.com (Postfix) with ESMTP id 9783B1A0162 for ; Thu, 20 Feb 2014 05:41:39 -0800 (PST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id A700CED4; Thu, 20 Feb 2014 14:41:35 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id MzuYRkAD_F8g; Thu, 20 Feb 2014 14:41:33 +0100 (CET)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by atlas3.jacobs-university.de (Postfix) with ESMTP; Thu, 20 Feb 2014 14:41:33 +0100 (CET)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9B0D220026; Thu, 20 Feb 2014 14:41:33 +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 erACxX-d4Jcj; Thu, 20 Feb 2014 14:41: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 F13AD20015; Thu, 20 Feb 2014 14:41:32 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id ABC892B5FDEC; Thu, 20 Feb 2014 14:41:30 +0100 (CET)
Date: Thu, 20 Feb 2014 14:41:30 +0100
From: Juergen Schoenwaelder 
To: Martin Bjorklund 
Message-ID: <20140220134130.GA19665@elstar.local>
Mail-Followup-To: Martin Bjorklund , netmod@ietf.org
References: <20140110133016.24678.42711.idtracker@ietfa.amsl.com> <32377793-C511-4F40-9C55-5E6A6B27969E@nic.cz> <20140111.133634.462426147.mbj@tail-f.com> <12A63CCF-69CE-4D43-A3EC-F420635B5237@nic.cz>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <12A63CCF-69CE-4D43-A3EC-F420635B5237@nic.cz>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/SpbjBGq2D_0mVIWM4EL2gPyXKmA
Cc: netmod@ietf.org
Subject: Re: [netmod] Fwd: I-D Action: draft-ietf-netmod-routing-cfg-13.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 20 Feb 2014 13:41:41 -0000

Martin,

do you think your concerns have been addressed by Ladislav's
answer?

/js

On Sat, Jan 11, 2014 at 02:31:08PM +0100, Ladislav Lhotka wrote:
> 
> On 11 Jan 2014, at 13:36, Martin Bjorklund  wrote:
> 
> > Hi,
> > 
> > Ladislav Lhotka  wrote:
> >> Hi,
> >> 
> >> changes in this revision mainly resulted from Martin’s review, I believe all
> >> his comments were addressed.
> > 
> > I have reviewed this version, and I think all my comments are
> > addressed.  Thank you!
> 
> Good, thanks!
> 
> > 
> > I have one question about a change that I believe was not discussed on
> > the list:
> > 
> >   o Remove "when" statement for IPv6 router interface operational	
> >     state - it was dependent on a config value that may not be	
> >     present.	
> > 		
> > I do not think is correct.  If the ipv6 container exists, the
> > 'enabled' leaf has the default value of 'true', and default values are
> > taken into account when XPath expressions are evaluated.  But maybe I
> > misunderstood the problem?
> 
> If it is a system-controlled interface, there may be no entry for it in /if:interfaces/if:interface, and the default then doesn’t apply.
> 
> > 
> > 
> > 
> > I noticed one thing that may or may not be intentional.  The grouping
> > "outgoing-interface" has a leaf with a leafref, where the path uses
> > non-prefixed identifiers.  If this grouping is ever used from another
> > module, it means that that module must have the same data hierarchy
> > (/routing-state/...) as this module.  These identifiers should
> > probably use prefixes.
> 
> That grouping is actually intended only for local use. Modules for routing protocols might also define outgoing-interface but they should use relative path so as to limit the choice only to interfaces assigned to the ancestor routing instance. It is done so already for the “static†protocol.
> 
> Maybe the “outgoing-interface†grouping could be made local by moving it under “routing-state†but that seems detrimental to the module organization - the definition of the grouping would be harder to find.
> 
> Lada 
> 
> > 
> > 
> > 
> > /martin
> 
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
> 
> 
> 
> 
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

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


From nobody Thu Feb 20 05:51:39 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB7B01A0171 for ; Thu, 20 Feb 2014 05:51:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.449
X-Spam-Level: 
X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gg5bEaMi8Yso for ; Thu, 20 Feb 2014 05:51:34 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id 1102C1A0165 for ; Thu, 20 Feb 2014 05:51: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 E10BA37C23F; Thu, 20 Feb 2014 14:51:29 +0100 (CET)
Date: Thu, 20 Feb 2014 14:51:29 +0100 (CET)
Message-Id: <20140220.145129.73716044088019744.mbj@tail-f.com>
To: j.schoenwaelder@jacobs-university.de
From: Martin Bjorklund 
In-Reply-To: <20140220134130.GA19665@elstar.local>
References: <20140111.133634.462426147.mbj@tail-f.com> <12A63CCF-69CE-4D43-A3EC-F420635B5237@nic.cz> <20140220134130.GA19665@elstar.local>
X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=utf-8
Content-Transfer-Encoding: base64
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/vkGDFargItQQluyxPbx3D0o2MCM
Cc: netmod@ietf.org
Subject: Re: [netmod] Fwd: I-D Action: draft-ietf-netmod-routing-cfg-13.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 20 Feb 2014 13:51:38 -0000

SnVlcmdlbiBTY2hvZW53YWVsZGVyIDxqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHku
ZGU+IHdyb3RlOg0KPiBNYXJ0aW4sDQo+IA0KPiBkbyB5b3UgdGhpbmsgeW91ciBjb25jZXJucyBo
YXZlIGJlZW4gYWRkcmVzc2VkIGJ5IExhZGlzbGF2J3MNCj4gYW5zd2VyPw0KDQpTZWUgaW5saW5l
Lg0KDQo+IE9uIFNhdCwgSmFuIDExLCAyMDE0IGF0IDAyOjMxOjA4UE0gKzAxMDAsIExhZGlzbGF2
IExob3RrYSB3cm90ZToNCj4gPiANCj4gPiBPbiAxMSBKYW4gMjAxNCwgYXQgMTM6MzYsIE1hcnRp
biBCam9ya2x1bmQgPG1iakB0YWlsLWYuY29tPiB3cm90ZToNCj4gPiANCj4gPiA+IEhpLA0KPiA+
ID4gDQo+ID4gPiBMYWRpc2xhdiBMaG90a2EgPGxob3RrYUBuaWMuY3o+IHdyb3RlOg0KPiA+ID4+
IEhpLA0KPiA+ID4+IA0KPiA+ID4+IGNoYW5nZXMgaW4gdGhpcyByZXZpc2lvbiBtYWlubHkgcmVz
dWx0ZWQgZnJvbSBNYXJ0aW7igJlzIHJldmlldywgSQ0KPiA+ID4+IGJlbGlldmUgYWxsDQo+ID4g
Pj4gaGlzIGNvbW1lbnRzIHdlcmUgYWRkcmVzc2VkLg0KPiA+ID4gDQo+ID4gPiBJIGhhdmUgcmV2
aWV3ZWQgdGhpcyB2ZXJzaW9uLCBhbmQgSSB0aGluayBhbGwgbXkgY29tbWVudHMgYXJlDQo+ID4g
PiBhZGRyZXNzZWQuICBUaGFuayB5b3UhDQo+ID4gDQo+ID4gR29vZCwgdGhhbmtzIQ0KPiA+IA0K
PiA+ID4gDQo+ID4gPiBJIGhhdmUgb25lIHF1ZXN0aW9uIGFib3V0IGEgY2hhbmdlIHRoYXQgSSBi
ZWxpZXZlIHdhcyBub3QgZGlzY3Vzc2VkIG9uDQo+ID4gPiB0aGUgbGlzdDoNCj4gPiA+IA0KPiA+
ID4gICBvIFJlbW92ZSAid2hlbiIgc3RhdGVtZW50IGZvciBJUHY2IHJvdXRlciBpbnRlcmZhY2Ug
b3BlcmF0aW9uYWwJDQo+ID4gPiAgICAgc3RhdGUgLSBpdCB3YXMgZGVwZW5kZW50IG9uIGEgY29u
ZmlnIHZhbHVlIHRoYXQgbWF5IG5vdCBiZQkNCj4gPiA+ICAgICBwcmVzZW50LgkNCj4gPiA+IAkJ
DQo+ID4gPiBJIGRvIG5vdCB0aGluayBpcyBjb3JyZWN0LiAgSWYgdGhlIGlwdjYgY29udGFpbmVy
IGV4aXN0cywgdGhlDQo+ID4gPiAnZW5hYmxlZCcgbGVhZiBoYXMgdGhlIGRlZmF1bHQgdmFsdWUg
b2YgJ3RydWUnLCBhbmQgZGVmYXVsdCB2YWx1ZXMgYXJlDQo+ID4gPiB0YWtlbiBpbnRvIGFjY291
bnQgd2hlbiBYUGF0aCBleHByZXNzaW9ucyBhcmUgZXZhbHVhdGVkLiAgQnV0IG1heWJlIEkNCj4g
PiA+IG1pc3VuZGVyc3Rvb2QgdGhlIHByb2JsZW0/DQo+ID4gDQo+ID4gSWYgaXQgaXMgYSBzeXN0
ZW0tY29udHJvbGxlZCBpbnRlcmZhY2UsIHRoZXJlIG1heSBiZSBubyBlbnRyeSBmb3IgaXQNCj4g
PiBpbiAvaWY6aW50ZXJmYWNlcy9pZjppbnRlcmZhY2UsIGFuZCB0aGUgZGVmYXVsdCB0aGVuIGRv
ZXNu4oCZdCBhcHBseS4NCg0KT2shDQoNCj4gPiA+IEkgbm90aWNlZCBvbmUgdGhpbmcgdGhhdCBt
YXkgb3IgbWF5IG5vdCBiZSBpbnRlbnRpb25hbC4gIFRoZSBncm91cGluZw0KPiA+ID4gIm91dGdv
aW5nLWludGVyZmFjZSIgaGFzIGEgbGVhZiB3aXRoIGEgbGVhZnJlZiwgd2hlcmUgdGhlIHBhdGgg
dXNlcw0KPiA+ID4gbm9uLXByZWZpeGVkIGlkZW50aWZpZXJzLiAgSWYgdGhpcyBncm91cGluZyBp
cyBldmVyIHVzZWQgZnJvbSBhbm90aGVyDQo+ID4gPiBtb2R1bGUsIGl0IG1lYW5zIHRoYXQgdGhh
dCBtb2R1bGUgbXVzdCBoYXZlIHRoZSBzYW1lIGRhdGEgaGllcmFyY2h5DQo+ID4gPiAoL3JvdXRp
bmctc3RhdGUvLi4uKSBhcyB0aGlzIG1vZHVsZS4gIFRoZXNlIGlkZW50aWZpZXJzIHNob3VsZA0K
PiA+ID4gcHJvYmFibHkgdXNlIHByZWZpeGVzLg0KPiA+IA0KPiA+IFRoYXQgZ3JvdXBpbmcgaXMg
YWN0dWFsbHkgaW50ZW5kZWQgb25seSBmb3IgbG9jYWwgdXNlLiBNb2R1bGVzIGZvcg0KPiA+IHJv
dXRpbmcgcHJvdG9jb2xzIG1pZ2h0IGFsc28gZGVmaW5lIG91dGdvaW5nLWludGVyZmFjZSBidXQg
dGhleSBzaG91bGQNCj4gPiB1c2UgcmVsYXRpdmUgcGF0aCBzbyBhcyB0byBsaW1pdCB0aGUgY2hv
aWNlIG9ubHkgdG8gaW50ZXJmYWNlcw0KPiA+IGFzc2lnbmVkIHRvIHRoZSBhbmNlc3RvciByb3V0
aW5nIGluc3RhbmNlLiBJdCBpcyBkb25lIHNvIGFscmVhZHkgZm9yDQo+ID4gdGhlIOKAnHN0YXRp
Y+KAnSBwcm90b2NvbC4NCj4gPiANCj4gPiBNYXliZSB0aGUg4oCcb3V0Z29pbmctaW50ZXJmYWNl
4oCdIGdyb3VwaW5nIGNvdWxkIGJlIG1hZGUgbG9jYWwgYnkgbW92aW5nDQo+ID4gaXQgdW5kZXIg
4oCccm91dGluZy1zdGF0ZeKAnSBidXQgdGhhdCBzZWVtcyBkZXRyaW1lbnRhbCB0byB0aGUgbW9k
dWxlDQo+ID4gb3JnYW5pemF0aW9uIC0gdGhlIGRlZmluaXRpb24gb2YgdGhlIGdyb3VwaW5nIHdv
dWxkIGJlIGhhcmRlciB0byBmaW5kLg0KDQpJIHRoaW5rIGl0IHdvdWxkIGJlIGJldHRlciB0byBt
YWtlIGl0IGxvY2FsIHRvICJyb3V0aW5nLXN0YXRlIi4gIEFzIGl0DQppcyBub3csIGl0IGlzIGRl
ZmluZWQgaW4gdGhlIG1pZGRsZSBvZiBhIGJ1bmNoIG9mIHJldXNhYmxlIGdyb3VwaW5ncywNCndo
ZW4gaW4gZmFjdCB0aGlzIG9uZSBpcyBub3QgaW50ZW5kZWQgdG8gYmUgcmV1c2FibGUuDQoNCg0K
L21hcnRpbg0K


From nobody Thu Feb 20 11:39:01 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D41A1A01D7 for ; Thu, 20 Feb 2014 11:38:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level: 
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JqyyAAzVjFml for ; Thu, 20 Feb 2014 11:38:57 -0800 (PST)
Received: from mail-qc0-f174.google.com (mail-qc0-f174.google.com [209.85.216.174]) by ietfa.amsl.com (Postfix) with ESMTP id 4229D1A015F for ; Thu, 20 Feb 2014 11:38:57 -0800 (PST)
Received: by mail-qc0-f174.google.com with SMTP id x13so3881144qcv.19 for ; Thu, 20 Feb 2014 11:38:53 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=ABm/3UvVTmRbShZtavZ2m9Atab0DO2sseNTQCYU7glY=; b=dItX68cCqVTLMDK7BFFXCs6IrU9GUk23nf9EraXMHRoVE6bjbPTlps7cGxCsKfbiln /TYjSxrOgGc81PXNWEeon9VXnJUgdjcaZLVz6r7ztLelexOF/gb0aFdIqCY9PTUMQAxN oTbmraFyZajC3QqJ/uPqrSWAlfrExRmwxZFc9DY662mXrskgF1F02a7a8fNXHVCTx96K /4R8N+jm2iuXsJuwydmOc45EgxLZj+LqvToE3v4SyHaO/Zar69HVl8HsGjtdG/EV+7vw QNzvt0vnATg579bblbo2TPtYPvhC58PwJW9XGGpoBYNjFuCq2HB9jkCjB7LYEGxInN0i 4DQQ==
X-Gm-Message-State: ALoCoQn9bTQ1ZmN/8ylzsibmGXPL/9Hq+JMwDaSxJLj/TiEFSyUOL4oXdRzRwtv7eoCOevgPjUoH
MIME-Version: 1.0
X-Received: by 10.140.87.9 with SMTP id q9mr3841172qgd.94.1392925133235; Thu, 20 Feb 2014 11:38:53 -0800 (PST)
Received: by 10.140.98.130 with HTTP; Thu, 20 Feb 2014 11:38:53 -0800 (PST)
Date: Thu, 20 Feb 2014 11:38:53 -0800
Message-ID: 
From: Andy Bierman 
To: "netmod@ietf.org" 
Content-Type: multipart/alternative; boundary=001a113a359cc4300204f2dba71e
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/TYkxz_foixhxukYEwK3xzQYN4ms
Subject: [netmod] another XPath question
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 20 Feb 2014 19:38:59 -0000

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

Hi,

Here is some YANG text from 7.19.5:

   o  If the context node represents RPC input parameters, the tree is
      the RPC XML instance document.  The XPath root node has the
      element representing the RPC operation being defined as the only
      child.


This seems to say the docroot is the  node (right?)


  rpc foo {
     input {
       leaf type { type int8; }
       container num8-stuff {
           when "/nc:rpc/acme:foo/acme:input/acme:type = 8";
            ...
       }
     }
  }

Is this how an absolute expr for rpc-input would look?
Or does the tree start with acme:foo and not netconf:rpc?
The text is confusing.


thanks,
Andy

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


Hi,

Here is some YANG text from 7.19.5:=


   o  If the context node represents RPC input par=
ameters, the tree is
      the RPC XML instance document.  The XPath root node has the
      element representing the RPC operation being defined as the only
      child.

This seems to say the docroot is the <rpc> node=
 (right?)


=A0 rpc foo {
=A0 =A0 =A0input {
=
=A0 =A0 =A0 =A0leaf type { type int8; }
=A0 =A0 =A0 =A0container =
num8-stuff {

=A0 =A0 =A0 =A0 =A0 =A0when "/nc:rpc/acme:foo/acme:input/acme:type =3D=
 8";
=A0 =A0 =A0 =A0 =A0 =A0 ...
=A0 =A0 =A0 =A0}<=
/div>
=A0 =A0 =A0}
=A0 }

Is this how=
 an absolute expr for rpc-input would look?


Or does the tree start with acme:foo and not netconf:rpc?
Th=
e text is confusing.


thanks,
<=
div>Andy



=A0 =A0 


--001a113a359cc4300204f2dba71e--


From nobody Thu Feb 20 12:00:57 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47BB21A029D for ; Thu, 20 Feb 2014 12:00:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.449
X-Spam-Level: 
X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0EKL-dPJHa9S for ; Thu, 20 Feb 2014 12:00:54 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id B33D41A028D for ; Thu, 20 Feb 2014 12:00:50 -0800 (PST)
Received: from localhost (unknown [193.12.32.88]) by mail.tail-f.com (Postfix) with ESMTPSA id 5A27037C247; Thu, 20 Feb 2014 21:00:46 +0100 (CET)
Date: Thu, 20 Feb 2014 21:00:45 +0100 (CET)
Message-Id: <20140220.210045.46705294.mbj@tail-f.com>
To: andy@yumaworks.com
From: Martin Bjorklund 
In-Reply-To: 
References: 
X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/kLk1AiCVKcG8a6NNUPOp2s8_6Os
Cc: netmod@ietf.org
Subject: Re: [netmod] another XPath question
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 20 Feb 2014 20:00:56 -0000

Andy Bierman  wrote:
> Hi,
> 
> Here is some YANG text from 7.19.5:
> 
>    o  If the context node represents RPC input parameters, the tree is
>       the RPC XML instance document.  The XPath root node has the
>       element representing the RPC operation being defined as the only
>       child.
> 
> 
> This seems to say the docroot is the  node (right?)

No, it doesn't say the "rpc" element, it says the element representing
the RPC operation being defined.  In this, case which RPC is being
defined?  "foo".

The RPC XML instance looks like this:

  
    
      ...
      ...
    
  

So the expression, starting from the operation being defined, would be:

  when "/acme:foo/acme:type = 8";


/martin


> 
> 
>   rpc foo {
>      input {
>        leaf type { type int8; }
>        container num8-stuff {
>            when "/nc:rpc/acme:foo/acme:input/acme:type = 8";
>             ...
>        }
>      }
>   }
> 
> Is this how an absolute expr for rpc-input would look?
> Or does the tree start with acme:foo and not netconf:rpc?
> The text is confusing.
> 
> 
> thanks,
> Andy


From nobody Thu Feb 20 12:13:02 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3BE51A02C2 for ; Thu, 20 Feb 2014 12:13:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level: 
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 39xwnU5px6Pv for ; Thu, 20 Feb 2014 12:12:59 -0800 (PST)
Received: from mail-pa0-f51.google.com (mail-pa0-f51.google.com [209.85.220.51]) by ietfa.amsl.com (Postfix) with ESMTP id A7D851A02CB for ; Thu, 20 Feb 2014 12:12:59 -0800 (PST)
Received: by mail-pa0-f51.google.com with SMTP id ld10so2408999pab.38 for ; Thu, 20 Feb 2014 12:12:56 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=t5VH9PzsbDhocaEO3/IxbbZ72CCqEW1T2q+zPCtvCGM=; b=jh4YqWRmURCPXtsXnYCpBM75AgU7G7BsWdrygRUpa8H8JWoXxDfm+UpSNnOPixTVaP 4U1JDLLMfnttI8lL0bQR8DKMITlS+VhqunwfXmzq+ulWtJxyTwybgOhwDJ49GYuckjFj FOd9JZXg2NMzmy55Hh1HmLfdQo+fuOs6A1hzHtoCO95mMZXKYwMo2lrx0She1esDP7Bq cn0GNARFkSxaGq2hAqiO7Y3U/rYFR07VRmPBef9bdpV+Yu27ExDkTonV7w1J+lDGV1Lv 4JsLWCGG4ODmU2zaOvA/xw2mD7H2Q33RA/1Gy8Za+wZy0birYdmIoTIm7SK2ggkOmhhW jC1w==
X-Gm-Message-State: ALoCoQlQ0FKCnSWwhVhbGK1aQsvub6kjBDspkHosryuC1D17mS6Fu8pbHXyFotul5/idqP4SdqzB
MIME-Version: 1.0
X-Received: by 10.66.149.231 with SMTP id ud7mr4500643pab.8.1392927176156; Thu, 20 Feb 2014 12:12:56 -0800 (PST)
Received: by 10.70.21.68 with HTTP; Thu, 20 Feb 2014 12:12:56 -0800 (PST)
In-Reply-To: 
References: 
Date: Thu, 20 Feb 2014 12:12:56 -0800
Message-ID: 
From: Andy Bierman 
To: "netmod@ietf.org" 
Content-Type: multipart/alternative; boundary=047d7b6d95d08880ec04f2dc21ae
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/933bJWBzWgjICp_AukJTWnCv3AQ
Subject: Re: [netmod] another XPath question
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 20 Feb 2014 20:13:02 -0000

--047d7b6d95d08880ec04f2dc21ae
Content-Type: text/plain; charset=ISO-8859-1

On Thu, Feb 20, 2014 at 11:38 AM, Andy Bierman  wrote:

> Hi,
>
> Here is some YANG text from 7.19.5:
>
>    o  If the context node represents RPC input parameters, the tree is
>       the RPC XML instance document.  The XPath root node has the
>       element representing the RPC operation being defined as the only
>       child.
>
>
> This seems to say the docroot is the  node (right?)
>
>
>   rpc foo {
>      input {
>        leaf type { type int8; }
>        container num8-stuff {
>            when "/nc:rpc/acme:foo/acme:input/acme:type = 8";
>             ...
>        }
>      }
>   }
>
> Is this how an absolute expr for rpc-input would look?
> Or does the tree start with acme:foo and not netconf:rpc?
> The text is confusing.
>
>

The intent of the first sentence is to say that only the 
message (input parameters only) are in the tree.
I think sentence 2 should say "rpc" statement instead of "RPC operation".
It seems to say  the tree is /acme:foo is a node that has to be named:

              when "/acme:foo/acme:input/acme:type = 8";


IMO the  node should be the document root for must/when
expressions for rpc input parameters.

           when "/acme:type = 8";

So what is the correct version of this when-stmt?



> thanks,
> Andy
>
>
>
>
>

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





On Thu, Feb 20, 2014 at 11:38 AM, Andy Bierman &l=
t;andy@yumaworks.co=
m> wrote:


Hi,

Here is some YANG =
text from 7.19.5:



   o  If the context node represents RPC input parameters, the tree is
      the RPC XML instance document.  The XPath root node has the
      element representing the RPC operation being defined as the only
      child.

This seems to say the docroot is the <rpc> node=
 (right?)


=A0 rpc foo {
=A0 =A0 =A0input {
=
=A0 =A0 =A0 =A0leaf type { type int8; }
=A0 =A0 =A0 =A0container =
num8-stuff {


=A0 =A0 =A0 =A0 =A0 =A0when "/nc:rpc/acme:foo/acme:input/acme:type =3D=
 8";
=A0 =A0 =A0 =A0 =A0 =A0 ...
=A0 =A0 =A0 =A0}<=
/div>
=A0 =A0 =A0}
=A0 }

Is this how=
 an absolute expr for rpc-input would look?



Or does the tree start with acme:foo and not netconf:rpc?
Th=
e text is confusing.


=


The intent of the first sentence is to say that only th=
e <rpc>


message (input parameters only) are in the tree.
I think sen=
tence 2 should say "rpc" statement instead of "RPC operation=
".
It seems to say =A0the tree is /acme:foo is a node that h=
as to be named:



=A0 =A0 =A0 =A0 =A0 =A0 =A0 when "/acme:foo/acme:i=
nput/acme:type =3D 8";


IMO the=
 <input> node should be the document root for must/when
exp=
ressions for rpc input parameters.



=A0 =A0 =A0 =A0 =A0 =A0when "/acme:type =3D 8"=
;;

So what is the correct version of this when=
-stmt?





thanks,
Andy



=A0 =A0 





--047d7b6d95d08880ec04f2dc21ae--


From nobody Thu Feb 20 12:40:33 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB2521A02DD for ; Thu, 20 Feb 2014 12:40:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.449
X-Spam-Level: 
X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mzxdZv2X5kGI for ; Thu, 20 Feb 2014 12:40:30 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id 179641A02D7 for ; Thu, 20 Feb 2014 12:40:30 -0800 (PST)
Received: from localhost (unknown [193.12.32.88]) by mail.tail-f.com (Postfix) with ESMTPSA id AED7937C246; Thu, 20 Feb 2014 21:40:25 +0100 (CET)
Date: Thu, 20 Feb 2014 21:40:25 +0100 (CET)
Message-Id: <20140220.214025.454388534.mbj@tail-f.com>
To: andy@yumaworks.com
From: Martin Bjorklund 
In-Reply-To: 
References:  
X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/FNOalFpJ2EHlDDxqmsmPEmKTOUU
Cc: netmod@ietf.org
Subject: Re: [netmod] another XPath question
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 20 Feb 2014 20:40:32 -0000

Andy Bierman  wrote:
> On Thu, Feb 20, 2014 at 11:38 AM, Andy Bierman  wrote:
> 
> > Hi,
> >
> > Here is some YANG text from 7.19.5:
> >
> >    o  If the context node represents RPC input parameters, the tree is
> >       the RPC XML instance document.  The XPath root node has the
> >       element representing the RPC operation being defined as the only
> >       child.
> >
> >
> > This seems to say the docroot is the  node (right?)
> >
> >
> >   rpc foo {
> >      input {
> >        leaf type { type int8; }
> >        container num8-stuff {
> >            when "/nc:rpc/acme:foo/acme:input/acme:type = 8";
> >             ...
> >        }
> >      }
> >   }
> >
> > Is this how an absolute expr for rpc-input would look?
> > Or does the tree start with acme:foo and not netconf:rpc?
> > The text is confusing.
> >
> >
> 
> The intent of the first sentence is to say that only the 
> message (input parameters only) are in the tree.
> I think sentence 2 should say "rpc" statement instead of "RPC operation".
> It seems to say  the tree is /acme:foo is a node that has to be named:
> 
>               when "/acme:foo/acme:input/acme:type = 8";

Why do you think "input" should be there?  The text says:

   the tree is the RPC XML instance document

there is no "input" element here.

Now the question is which node is the top-level node.

The XML looks like this:

  
    
      ...
      ...
    
  

The text says:

  The XPath root node has the element representing the RPC operation
  being defined as the only child.


Is this really unclear?  How could this text be interpreted to mean
that the root node has multiple children, one for each input
parameter?


/martin



> 
> 
> IMO the  node should be the document root for must/when
> expressions for rpc input parameters.
> 
>            when "/acme:type = 8";
> 
> So what is the correct version of this when-stmt?
> 
> 
> 
> > thanks,
> > Andy
> >
> >
> >
> >
> >


From nobody Fri Feb 21 01:44:40 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B2511A002D for ; Fri, 21 Feb 2014 01:44:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.448
X-Spam-Level: 
X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NjzzSrdU4_L4 for ; Fri, 21 Feb 2014 01:44:35 -0800 (PST)
Received: from gate.mg-soft.si (gate.mg-soft.si [212.30.73.66]) by ietfa.amsl.com (Postfix) with ESMTP id 7CE371A0058 for ; Fri, 21 Feb 2014 01:44:35 -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 s1L9iTXd028621; Fri, 21 Feb 2014 10:44:30 +0100
Message-ID: <53071FFC.9060202@mg-soft.com>
Date: Fri, 21 Feb 2014 10:44:28 +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:   <20140220.214025.454388534.mbj@tail-f.com>
In-Reply-To: <20140220.214025.454388534.mbj@tail-f.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/zJTgWxAR15Ri9JgWVT0LCqXbm0c
Cc: netmod@ietf.org
Subject: Re: [netmod] another XPath question
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 21 Feb 2014 09:44:39 -0000

Dne 20.2.2014 21:40, piše Martin Bjorklund:
> Andy Bierman  wrote:
>> On Thu, Feb 20, 2014 at 11:38 AM, Andy Bierman  wrote:
>>
>>> Hi,
>>>
>>> Here is some YANG text from 7.19.5:
>>>
>>>     o  If the context node represents RPC input parameters, the tree is
>>>        the RPC XML instance document.  The XPath root node has the
>>>        element representing the RPC operation being defined as the only
>>>        child.
>>>
>>>
>>> This seems to say the docroot is the  node (right?)
>>>
>>>
>>>    rpc foo {
>>>       input {
>>>         leaf type { type int8; }
>>>         container num8-stuff {
>>>             when "/nc:rpc/acme:foo/acme:input/acme:type = 8";
>>>              ...
>>>         }
>>>       }
>>>    }
>>>
>>> Is this how an absolute expr for rpc-input would look?
>>> Or does the tree start with acme:foo and not netconf:rpc?
>>> The text is confusing.
>>>
>>>
>> The intent of the first sentence is to say that only the 
>> message (input parameters only) are in the tree.
>> I think sentence 2 should say "rpc" statement instead of "RPC operation".
>> It seems to say  the tree is /acme:foo is a node that has to be named:
>>
>>                when "/acme:foo/acme:input/acme:type = 8";
> Why do you think "input" should be there?  The text says:
>
>     the tree is the RPC XML instance document
>
> there is no "input" element here.
>
> Now the question is which node is the top-level node.
>
> The XML looks like this:
>
>    
>      
>        ...
>        ...
>      
>    
>
> The text says:
>
>    The XPath root node has the element representing the RPC operation
>    being defined as the only child.
>
>
> Is this really unclear?  How could this text be interpreted to mean
> that the root node has multiple children, one for each input
> parameter?

I do not think the text is confusing and is correct. I've recently 
implemented functionality related to the text in question and understood 
it as Martin explained.

Whenever XPath (must/when) is involved, you should think with data tree 
in mind, not schema node tree (only nodes that may be instantiated can 
be referred to in a must/when argument, root node being the only 
exception, I believe).

Also, "document root" (the invisible _root node_ of any XML document) 
and "document element" (_root element_, first element - "the only child" 
in text) are two terms that are never to be confused as per XPath spec. 
You refer to the root node with ("/") and to the root element with 
("/*") in XPath. In case of when statement and RPC input parameters, 
document root is the same as that of the RPC XML instance document and 
 is the root element, which in turn may have child data nodes, 
defined using the input statement in YANG.

Problems like this are why I'd like a clearer separation between schema 
and instance documents in YANG. It should be absolutely impossible to 
confuse data nodes with schema nodes throughout the entire RFC6020.

Jernej

>
> /martin
>
>
>
>>
>> IMO the  node should be the document root for must/when
>> expressions for rpc input parameters.
>>
>>             when "/acme:type = 8";
>>
>> So what is the correct version of this when-stmt?
>>
>>
>>
>>> thanks,
>>> Andy
>>>
>>>
>>>
>>>
>>>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


From nobody Fri Feb 21 01:48:51 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A93961A0452 for ; Fri, 21 Feb 2014 01:48:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.448
X-Spam-Level: 
X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4SCaQ2yz8x9h for ; Fri, 21 Feb 2014 01:48:47 -0800 (PST)
Received: from gate.mg-soft.si (gate.mg-soft.si [212.30.73.66]) by ietfa.amsl.com (Postfix) with ESMTP id 200551A002D for ; Fri, 21 Feb 2014 01:48:46 -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 s1L9mgph028662; Fri, 21 Feb 2014 10:48:42 +0100
Message-ID: <530720F9.1050806@mg-soft.com>
Date: Fri, 21 Feb 2014 10:48:41 +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: Jernej Tuljak 
References:   <20140220.214025.454388534.mbj@tail-f.com> <53071FFC.9060202@mg-soft.com>
In-Reply-To: <53071FFC.9060202@mg-soft.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/1hY9aI-yYnFUNXPtYKEvvxYAjoc
Cc: netmod@ietf.org
Subject: Re: [netmod] another XPath question
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 21 Feb 2014 09:48:49 -0000

Dne 21.2.2014 10:44, piše Jernej Tuljak:
> Dne 20.2.2014 21:40, piše Martin Bjorklund:
>> Andy Bierman  wrote:
>>> On Thu, Feb 20, 2014 at 11:38 AM, Andy Bierman  
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>> Here is some YANG text from 7.19.5:
>>>>
>>>>     o  If the context node represents RPC input parameters, the 
>>>> tree is
>>>>        the RPC XML instance document.  The XPath root node has the
>>>>        element representing the RPC operation being defined as the 
>>>> only
>>>>        child.
>>>>
>>>>
>>>> This seems to say the docroot is the  node (right?)
>>>>
>>>>
>>>>    rpc foo {
>>>>       input {
>>>>         leaf type { type int8; }
>>>>         container num8-stuff {
>>>>             when "/nc:rpc/acme:foo/acme:input/acme:type = 8";
>>>>              ...
>>>>         }
>>>>       }
>>>>    }
>>>>
>>>> Is this how an absolute expr for rpc-input would look?
>>>> Or does the tree start with acme:foo and not netconf:rpc?
>>>> The text is confusing.
>>>>
>>>>
>>> The intent of the first sentence is to say that only the 
>>> message (input parameters only) are in the tree.
>>> I think sentence 2 should say "rpc" statement instead of "RPC 
>>> operation".
>>> It seems to say  the tree is /acme:foo is a node that has to be named:
>>>
>>>                when "/acme:foo/acme:input/acme:type = 8";
>> Why do you think "input" should be there?  The text says:
>>
>>     the tree is the RPC XML instance document
>>
>> there is no "input" element here.
>>
>> Now the question is which node is the top-level node.
>>
>> The XML looks like this:
>>
>>    
>>      
>>        ...
>>        ...
>>      
>>    
>>
>> The text says:
>>
>>    The XPath root node has the element representing the RPC operation
>>    being defined as the only child.
>>
>>
>> Is this really unclear?  How could this text be interpreted to mean
>> that the root node has multiple children, one for each input
>> parameter?
>
> I do not think the text is confusing and is correct. I've recently 
> implemented functionality related to the text in question and 
> understood it as Martin explained.
>
> Whenever XPath (must/when) is involved, you should think with data 
> tree in mind, not schema node tree (only nodes that may be 
> instantiated can be referred to in a must/when argument, root node 
> being the only exception, I believe).
>
> Also, "document root" (the invisible _root node_ of any XML document) 
> and "document element" (_root element_, first element - "the only 
> child" in text) are two terms that are never to be confused as per 
> XPath spec. You refer to the root node with ("/") and to the root 
> element with ("/*") in XPath. In case of when statement and RPC input 
> parameters, document root is the same as that of the RPC XML instance 
> document and  is the root element, which in turn may have child 
> data nodes, defined using the input statement in YANG.

Forgot about the rpc statement, but it doesn't matter. Children are 
defined with rpc + input statement in YANG.

Jernej

>
> Problems like this are why I'd like a clearer separation between 
> schema and instance documents in YANG. It should be absolutely 
> impossible to confuse data nodes with schema nodes throughout the 
> entire RFC6020.
>
> Jernej
>
>>
>> /martin
>>
>>
>>
>>>
>>> IMO the  node should be the document root for must/when
>>> expressions for rpc input parameters.
>>>
>>>             when "/acme:type = 8";
>>>
>>> So what is the correct version of this when-stmt?
>>>
>>>
>>>
>>>> thanks,
>>>> Andy
>>>>
>>>>
>>>>
>>>>
>>>>
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


From nobody Fri Feb 21 02:15:34 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B33F1A0085 for ; Fri, 21 Feb 2014 02:15:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.899
X-Spam-Level: 
X-Spam-Status: No, score=-0.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.548] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rte5KEnNSi3k for ; Fri, 21 Feb 2014 02:15: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 06B641A0073 for ; Fri, 21 Feb 2014 02:15:30 -0800 (PST)
Received: from [172.29.2.104] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 733251409C0; Fri, 21 Feb 2014 11:15:25 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1392977725; bh=6yBb48als7SzQO2qqvW+/UM3ShkiEf7evlbSgUnDpbc=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=tbukmBCzQijwgSCrXLjlVv8lI6YDs7FD5lkrPs477FtR49JcmdXxiej6/P6gyvbDZ BJOqhfunvO+vT+XC13Njy5Zv/WoXt7ZAoC+pmExRbceDlJ0Zi3WL4icNkAOhL8HPdK KzNlbrq5LfD4Zd1dfylNjtQ/oQGDI4nVV75NeFs0=
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Ladislav Lhotka 
In-Reply-To: <20140220.145129.73716044088019744.mbj@tail-f.com>
Date: Fri, 21 Feb 2014 11:15:26 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <657A1870-B234-4489-8F0E-A85559843C16@nic.cz>
References: <20140111.133634.462426147.mbj@tail-f.com> <12A63CCF-69CE-4D43-A3EC-F420635B5237@nic.cz> <20140220134130.GA19665@elstar.local> <20140220.145129.73716044088019744.mbj@tail-f.com>
To: =?windows-1252?Q?Martin_Bj=F6rklund?= 
X-Mailer: Apple Mail (2.1827)
X-Virus-Scanned: clamav-milter 0.97.8 at mail
X-Virus-Status: Clean
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/iuj2uk9RMGL51K3N_SCGx61Nla0
Cc: netmod@ietf.org
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-routing-cfg-13.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 21 Feb 2014 10:15:33 -0000

=85

On 20 Feb 2014, at 14:51, Martin Bjorklund  wrote:

>>>> I noticed one thing that may or may not be intentional.  The =
grouping
>>>> "outgoing-interface" has a leaf with a leafref, where the path uses
>>>> non-prefixed identifiers.  If this grouping is ever used from =
another
>>>> module, it means that that module must have the same data hierarchy
>>>> (/routing-state/...) as this module.  These identifiers should
>>>> probably use prefixes.
>>>=20
>>> That grouping is actually intended only for local use. Modules for
>>> routing protocols might also define outgoing-interface but they =
should
>>> use relative path so as to limit the choice only to interfaces
>>> assigned to the ancestor routing instance. It is done so already for
>>> the =93static=94 protocol.
>>>=20
>>> Maybe the =93outgoing-interface=94 grouping could be made local by =
moving
>>> it under =93routing-state=94 but that seems detrimental to the =
module
>>> organization - the definition of the grouping would be harder to =
find.
>=20
> I think it would be better to make it local to "routing-state".  As it
> is now, it is defined in the middle of a bunch of reusable groupings,
> when in fact this one is not intended to be reusable.

That would mean the "next-hop-content=94 has to be moved under =
=93routing-state=94 as well, because it uses =93outgoing-interface=94, =
and that would make the definition of =93routing-state=94 really clumsy.

How about adding =93rt=94 prefixes to all parts of that =93path=94 =
argument instead?

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 nobody Fri Feb 21 02:42:36 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F26781A04E9 for ; Fri, 21 Feb 2014 02:42:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.899
X-Spam-Level: 
X-Spam-Status: No, score=-0.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.548] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lJRn1JkpH0TG for ; Fri, 21 Feb 2014 02:42:33 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 08D171A0088 for ; Fri, 21 Feb 2014 02:42:33 -0800 (PST)
Received: from [172.29.2.104] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 94989140152; Fri, 21 Feb 2014 11:42:28 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1392979348; bh=/vZqbnS3VuK34BT6dbKQGsrSa9S0ChVebOzoZA//nS8=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=XWr8KmPRKIuJVBa2tMRfcm4jq/3jiyeScaxJYPxTV2nn8z7p7okXMwrDcUQ93Xdep Ei93sBfY7dWazoYm+k9ruEqic08pKi3Vl8zgNfrsZPvpLwDvarO31Xpkh80yJ3bxWL 3oZC7HZSRhzKsFxN/YYl0rvsSPbrk1EmCBxsqG60=
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Ladislav Lhotka 
In-Reply-To: <20140220.214025.454388534.mbj@tail-f.com>
Date: Fri, 21 Feb 2014 11:42:29 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:   <20140220.214025.454388534.mbj@tail-f.com>
To: =?windows-1252?Q?Martin_Bj=F6rklund?= 
X-Mailer: Apple Mail (2.1827)
X-Virus-Scanned: clamav-milter 0.97.8 at mail
X-Virus-Status: Clean
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/x75AIlGnwiyNFq-FvPHvqW-dSeE
Cc: netmod@ietf.org
Subject: Re: [netmod] another XPath question
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 21 Feb 2014 10:42:35 -0000

On 20 Feb 2014, at 21:40, Martin Bjorklund  wrote:

> Andy Bierman  wrote:
>> On Thu, Feb 20, 2014 at 11:38 AM, Andy Bierman  =
wrote:
>>=20
>>> Hi,
>>>=20
>>> Here is some YANG text from 7.19.5:
>>>=20
>>>   o  If the context node represents RPC input parameters, the tree =
is
>>>      the RPC XML instance document.  The XPath root node has the
>>>      element representing the RPC operation being defined as the =
only
>>>      child.
>>>=20
>>>=20
>>> This seems to say the docroot is the  node (right?)
>>>=20
>>>=20
>>>  rpc foo {
>>>     input {
>>>       leaf type { type int8; }
>>>       container num8-stuff {
>>>           when "/nc:rpc/acme:foo/acme:input/acme:type =3D 8";
>>>            ...
>>>       }
>>>     }
>>>  }
>>>=20
>>> Is this how an absolute expr for rpc-input would look?
>>> Or does the tree start with acme:foo and not netconf:rpc?
>>> The text is confusing.
>>>=20
>>>=20
>>=20
>> The intent of the first sentence is to say that only the 
>> message (input parameters only) are in the tree.
>> I think sentence 2 should say "rpc" statement instead of "RPC =
operation".
>> It seems to say  the tree is /acme:foo is a node that has to be =
named:
>>=20
>>              when "/acme:foo/acme:input/acme:type =3D 8";
>=20
> Why do you think "input" should be there?  The text says:
>=20
>   the tree is the RPC XML instance document
>=20
> there is no "input" element here.
>=20
> Now the question is which node is the top-level node.
>=20
> The XML looks like this:
>=20
>  
>    
>      ...
>      ...
>    
>  
>=20
> The text says:
>=20
>  The XPath root node has the element representing the RPC operation
>  being defined as the only child.
>=20
>=20
> Is this really unclear?  How could this text be interpreted to mean
> that the root node has multiple children, one for each input
> parameter?

I think it is pretty clear. The mapping to Schematron in pyang prepends =
=93$root=93 to every absolute XPath expression, and the =93root=94 =
variable is defined as =93/nc:rpc=94 if the target document is an RPC =
request, or "/nc:rpc-reply" if it is an RPC reply.

Lada

>=20
>=20
> /martin
>=20
>=20
>=20
>>=20
>>=20
>> IMO the  node should be the document root for must/when
>> expressions for rpc input parameters.
>>=20
>>           when "/acme:type =3D 8";
>>=20
>> So what is the correct version of this when-stmt?
>>=20
>>=20
>>=20
>>> thanks,
>>> Andy
>>>=20
>>>=20
>>>=20
>>>=20
>>>=20
>=20
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

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





From nobody Fri Feb 21 02:55:39 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9192C1A0505 for ; Fri, 21 Feb 2014 02:55:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.449
X-Spam-Level: 
X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y7jpx1Xn0FhG for ; Fri, 21 Feb 2014 02:55:36 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id CB6771A009A for ; Fri, 21 Feb 2014 02:55:35 -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 18BB637C246; Fri, 21 Feb 2014 11:55:31 +0100 (CET)
Date: Fri, 21 Feb 2014 11:55:30 +0100 (CET)
Message-Id: <20140221.115530.1307683991448285595.mbj@tail-f.com>
To: lhotka@nic.cz
From: Martin Bjorklund 
In-Reply-To: <657A1870-B234-4489-8F0E-A85559843C16@nic.cz>
References: <20140220134130.GA19665@elstar.local> <20140220.145129.73716044088019744.mbj@tail-f.com> <657A1870-B234-4489-8F0E-A85559843C16@nic.cz>
X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=utf-8
Content-Transfer-Encoding: base64
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/TCd9BKZZWvS3lojbr0mhHIoWQDg
Cc: netmod@ietf.org
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-routing-cfg-13.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 21 Feb 2014 10:55:37 -0000

TGFkaXNsYXYgTGhvdGthIDxsaG90a2FAbmljLmN6PiB3cm90ZToNCj4g4oCmDQo+IA0KPiBPbiAy
MCBGZWIgMjAxNCwgYXQgMTQ6NTEsIE1hcnRpbiBCam9ya2x1bmQgPG1iakB0YWlsLWYuY29tPiB3
cm90ZToNCj4gDQo+ID4+Pj4gSSBub3RpY2VkIG9uZSB0aGluZyB0aGF0IG1heSBvciBtYXkgbm90
IGJlIGludGVudGlvbmFsLiAgVGhlIGdyb3VwaW5nDQo+ID4+Pj4gIm91dGdvaW5nLWludGVyZmFj
ZSIgaGFzIGEgbGVhZiB3aXRoIGEgbGVhZnJlZiwgd2hlcmUgdGhlIHBhdGggdXNlcw0KPiA+Pj4+
IG5vbi1wcmVmaXhlZCBpZGVudGlmaWVycy4gIElmIHRoaXMgZ3JvdXBpbmcgaXMgZXZlciB1c2Vk
IGZyb20gYW5vdGhlcg0KPiA+Pj4+IG1vZHVsZSwgaXQgbWVhbnMgdGhhdCB0aGF0IG1vZHVsZSBt
dXN0IGhhdmUgdGhlIHNhbWUgZGF0YSBoaWVyYXJjaHkNCj4gPj4+PiAoL3JvdXRpbmctc3RhdGUv
Li4uKSBhcyB0aGlzIG1vZHVsZS4gIFRoZXNlIGlkZW50aWZpZXJzIHNob3VsZA0KPiA+Pj4+IHBy
b2JhYmx5IHVzZSBwcmVmaXhlcy4NCj4gPj4+IA0KPiA+Pj4gVGhhdCBncm91cGluZyBpcyBhY3R1
YWxseSBpbnRlbmRlZCBvbmx5IGZvciBsb2NhbCB1c2UuIE1vZHVsZXMgZm9yDQo+ID4+PiByb3V0
aW5nIHByb3RvY29scyBtaWdodCBhbHNvIGRlZmluZSBvdXRnb2luZy1pbnRlcmZhY2UgYnV0IHRo
ZXkgc2hvdWxkDQo+ID4+PiB1c2UgcmVsYXRpdmUgcGF0aCBzbyBhcyB0byBsaW1pdCB0aGUgY2hv
aWNlIG9ubHkgdG8gaW50ZXJmYWNlcw0KPiA+Pj4gYXNzaWduZWQgdG8gdGhlIGFuY2VzdG9yIHJv
dXRpbmcgaW5zdGFuY2UuIEl0IGlzIGRvbmUgc28gYWxyZWFkeSBmb3INCj4gPj4+IHRoZSDigJxz
dGF0aWPigJ0gcHJvdG9jb2wuDQo+ID4+PiANCj4gPj4+IE1heWJlIHRoZSDigJxvdXRnb2luZy1p
bnRlcmZhY2XigJ0gZ3JvdXBpbmcgY291bGQgYmUgbWFkZSBsb2NhbCBieSBtb3ZpbmcNCj4gPj4+
IGl0IHVuZGVyIOKAnHJvdXRpbmctc3RhdGXigJ0gYnV0IHRoYXQgc2VlbXMgZGV0cmltZW50YWwg
dG8gdGhlIG1vZHVsZQ0KPiA+Pj4gb3JnYW5pemF0aW9uIC0gdGhlIGRlZmluaXRpb24gb2YgdGhl
IGdyb3VwaW5nIHdvdWxkIGJlIGhhcmRlciB0byBmaW5kLg0KPiA+IA0KPiA+IEkgdGhpbmsgaXQg
d291bGQgYmUgYmV0dGVyIHRvIG1ha2UgaXQgbG9jYWwgdG8gInJvdXRpbmctc3RhdGUiLiAgQXMg
aXQNCj4gPiBpcyBub3csIGl0IGlzIGRlZmluZWQgaW4gdGhlIG1pZGRsZSBvZiBhIGJ1bmNoIG9m
IHJldXNhYmxlIGdyb3VwaW5ncywNCj4gPiB3aGVuIGluIGZhY3QgdGhpcyBvbmUgaXMgbm90IGlu
dGVuZGVkIHRvIGJlIHJldXNhYmxlLg0KPiANCj4gVGhhdCB3b3VsZCBtZWFuIHRoZSAibmV4dC1o
b3AtY29udGVudOKAnSBoYXMgdG8gYmUgbW92ZWQgdW5kZXINCj4g4oCccm91dGluZy1zdGF0ZeKA
nSBhcyB3ZWxsLCBiZWNhdXNlIGl0IHVzZXMg4oCcb3V0Z29pbmctaW50ZXJmYWNl4oCdLCBhbmQN
Cj4gdGhhdCB3b3VsZCBtYWtlIHRoZSBkZWZpbml0aW9uIG9mIOKAnHJvdXRpbmctc3RhdGXigJ0g
cmVhbGx5IGNsdW1zeS4NCj4gDQo+IEhvdyBhYm91dCBhZGRpbmcg4oCccnTigJ0gcHJlZml4ZXMg
dG8gYWxsIHBhcnRzIG9mIHRoYXQg4oCccGF0aOKAnSBhcmd1bWVudCBpbnN0ZWFkPw0KDQpPayBm
b3IgbWUuDQoNCg0KL21hcnRpbg0K


From nobody Fri Feb 21 03:07:30 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDC371A0097 for ; Fri, 21 Feb 2014 03:07:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.899
X-Spam-Level: 
X-Spam-Status: No, score=-0.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.548] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RxZvgGt4AbCr for ; Fri, 21 Feb 2014 03:07:28 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 3E5791A00A2 for ; Fri, 21 Feb 2014 03:07:28 -0800 (PST)
Received: from [172.29.2.104] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 9705A140859; Fri, 21 Feb 2014 12:07:23 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1392980843; bh=MeO5TdsFj2MF76R3O/qtZL3q2+zfegJNu9VPT3fsAmQ=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=EAmGpXzaEPGw3e0iljOvm8lZcs1imdHyGDX87bfiQMQtJzk5r5CJPRNlZE9ZjteCu BvhWhxBIfdf9kwGf3GUG6IfAzNSACBGTsT8CbXrj2T8rY/3ByXCZP0fTpwqysCgWVM V9WrM6yE0tZygCVhRzEVTqjuhHEOvl+E4T8qFzCQ=
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Ladislav Lhotka 
In-Reply-To: <20140221.115530.1307683991448285595.mbj@tail-f.com>
Date: Fri, 21 Feb 2014 12:07:25 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <20140220134130.GA19665@elstar.local> <20140220.145129.73716044088019744.mbj@tail-f.com> <657A1870-B234-4489-8F0E-A85559843C16@nic.cz> <20140221.115530.1307683991448285595.mbj@tail-f.com>
To: =?windows-1252?Q?Martin_Bj=F6rklund?= 
X-Mailer: Apple Mail (2.1827)
X-Virus-Scanned: clamav-milter 0.97.8 at mail
X-Virus-Status: Clean
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/C5aVaoT7tNBRWzXW0S0qIpu5_GY
Cc: netmod@ietf.org
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-routing-cfg-13.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 21 Feb 2014 11:07:30 -0000

On 21 Feb 2014, at 11:55, Martin Bjorklund  wrote:

> Ladislav Lhotka  wrote:
>> =85
>>=20
>> On 20 Feb 2014, at 14:51, Martin Bjorklund  wrote:
>>=20
>>>>>> I noticed one thing that may or may not be intentional.  The =
grouping
>>>>>> "outgoing-interface" has a leaf with a leafref, where the path =
uses
>>>>>> non-prefixed identifiers.  If this grouping is ever used from =
another
>>>>>> module, it means that that module must have the same data =
hierarchy
>>>>>> (/routing-state/...) as this module.  These identifiers should
>>>>>> probably use prefixes.
>>>>>=20
>>>>> That grouping is actually intended only for local use. Modules for
>>>>> routing protocols might also define outgoing-interface but they =
should
>>>>> use relative path so as to limit the choice only to interfaces
>>>>> assigned to the ancestor routing instance. It is done so already =
for
>>>>> the =93static=94 protocol.
>>>>>=20
>>>>> Maybe the =93outgoing-interface=94 grouping could be made local by =
moving
>>>>> it under =93routing-state=94 but that seems detrimental to the =
module
>>>>> organization - the definition of the grouping would be harder to =
find.
>>>=20
>>> I think it would be better to make it local to "routing-state".  As =
it
>>> is now, it is defined in the middle of a bunch of reusable =
groupings,
>>> when in fact this one is not intended to be reusable.
>>=20
>> That would mean the "next-hop-content=94 has to be moved under
>> =93routing-state=94 as well, because it uses =93outgoing-interface=94, =
and
>> that would make the definition of =93routing-state=94 really clumsy.
>>=20
>> How about adding =93rt=94 prefixes to all parts of that =93path=94 =
argument instead?
>=20
> Ok for me.

So if nobody is opposed, I will post a new revision with this change =
only.

Lada

>=20
>=20
> /martin

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





From nobody Fri Feb 21 03:39:09 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ADC11A00CF for ; Fri, 21 Feb 2014 03:39:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.548] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2I6-zeHhtRVj for ; Fri, 21 Feb 2014 03:39:06 -0800 (PST)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) by ietfa.amsl.com (Postfix) with ESMTP id E11AC1A0072 for ; Fri, 21 Feb 2014 03:39:05 -0800 (PST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id B5B0DF68; Fri, 21 Feb 2014 12:39:01 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id qoUaC3KijA8m; Fri, 21 Feb 2014 12:39:01 +0100 (CET)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by atlas3.jacobs-university.de (Postfix) with ESMTP; Fri, 21 Feb 2014 12:39:00 +0100 (CET)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id EEB1F20026; Fri, 21 Feb 2014 12:39:00 +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 kXuuUHzJIpcx; Fri, 21 Feb 2014 12:39:00 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 203FC20015; Fri, 21 Feb 2014 12:39:00 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id A83242B6F603; Fri, 21 Feb 2014 12:38:57 +0100 (CET)
Date: Fri, 21 Feb 2014 12:38:56 +0100
From: Juergen Schoenwaelder 
To: Ladislav Lhotka 
Message-ID: <20140221113854.GA92023@elstar.local>
Mail-Followup-To: Ladislav Lhotka , Martin =?iso-8859-1?Q?Bj=F6rklund?= , netmod@ietf.org
References: <20140220134130.GA19665@elstar.local> <20140220.145129.73716044088019744.mbj@tail-f.com> <657A1870-B234-4489-8F0E-A85559843C16@nic.cz> <20140221.115530.1307683991448285595.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)
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/QGBoD09oFPdQHCzYNZ9aUYEA1nw
Cc: netmod@ietf.org
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-routing-cfg-13.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 21 Feb 2014 11:39:08 -0000

On Fri, Feb 21, 2014 at 12:07:25PM +0100, Ladislav Lhotka wrote:
> 
> So if nobody is opposed, I will post a new revision with this change only.
> 

You can't since I-D submission is blocked right now.

Please keep this comment/change for the processing of IETF last call
comments. My plan is to send the document to Benoit so that he can
initiate the process to start the IETF last call.

I just wanted to make sure we have resolved this. My understanding
is that no further issues are pending on this document.

/js

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


From nobody Fri Feb 21 04:12:24 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA0421A0540 for ; Fri, 21 Feb 2014 04:12:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.899
X-Spam-Level: 
X-Spam-Status: No, score=-0.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.548] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4CUOlVQDZJI5 for ; Fri, 21 Feb 2014 04:12:21 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id CB1B01A053A for ; Fri, 21 Feb 2014 04:12:20 -0800 (PST)
Received: from [172.29.2.104] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 43471140152; Fri, 21 Feb 2014 13:12:16 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1392984736; bh=uGiQ77L5o7lOrzKf+ooTJAW55h0uiZbMFZBR+aI40mU=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=IANq316ajS/dbNLhcLN5acWCzjM9aG1pB3qpcQPoZXksTaMEFGsDHFX/VQKiIDoNC Clvf48X1L1Zma8llk8m09l4FE/oWUVr4CsoZ2vGJIsPb7y9+66goIetOD/8QGeoHQG UQX0xgWqIoA2OWGncUvJZAu+24QOehY4r0O56Hpg=
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Ladislav Lhotka 
In-Reply-To: <20140221113854.GA92023@elstar.local>
Date: Fri, 21 Feb 2014 13:12:17 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <8F1D6B21-7C03-4D15-92AF-B581527538E6@nic.cz>
References: <20140220134130.GA19665@elstar.local> <20140220.145129.73716044088019744.mbj@tail-f.com> <657A1870-B234-4489-8F0E-A85559843C16@nic.cz> <20140221.115530.1307683991448285595.mbj@tail-f.com>  <20140221113854.GA92023@elstar.local>
To: =?windows-1252?Q?J=FCrgen_Sch=F6nw=E4lder?= 
X-Mailer: Apple Mail (2.1827)
X-Virus-Scanned: clamav-milter 0.97.8 at mail
X-Virus-Status: Clean
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/ewfZkIAhyAKxhNEyFl-01rYbSDg
Cc: netmod@ietf.org
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-routing-cfg-13.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 21 Feb 2014 12:12:23 -0000

On 21 Feb 2014, at 12:38, Juergen Schoenwaelder =
 wrote:

> On Fri, Feb 21, 2014 at 12:07:25PM +0100, Ladislav Lhotka wrote:
>>=20
>> So if nobody is opposed, I will post a new revision with this change =
only.
>>=20
>=20
> You can't since I-D submission is blocked right now.
>=20
> Please keep this comment/change for the processing of IETF last call
> comments. My plan is to send the document to Benoit so that he can
> initiate the process to start the IETF last call.

OK, I=92ve already changed it in the SVN so it won=92t get lost.

>=20
> I just wanted to make sure we have resolved this. My understanding
> is that no further issues are pending on this document.

Yes, I am not aware of any.

Thanks, Lada

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

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





From nobody Fri Feb 21 08:53:30 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4168F1A04D5 for ; Fri, 21 Feb 2014 08:53:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level: 
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zt6VZqp9x6dn for ; Fri, 21 Feb 2014 08:53:26 -0800 (PST)
Received: from mail-qg0-f43.google.com (mail-qg0-f43.google.com [209.85.192.43]) by ietfa.amsl.com (Postfix) with ESMTP id 9D5EE1A0506 for ; Fri, 21 Feb 2014 08:53:26 -0800 (PST)
Received: by mail-qg0-f43.google.com with SMTP id f51so8192064qge.2 for ; Fri, 21 Feb 2014 08:53:22 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=9LaSR64L5K3MZAXVzQGxbWPFK0E+PsHvL3b0WghKH8E=; b=J7G/8DPGnKN44f2+i/DpuX+ppDXNaa9cLOCEFbxLzcb6cpwYnkGe5kKfjYvv4FXGK6 du4FQGtvyfrNz9O9GEFINLJFC0uZpC/ZizhODDvqFNGPymTqhjQRyO51cno2+Qtds20t zLuPTF0El9GwRXI8UB0IURn1zRSEOWQIYHpmRG6/exxrwiFeY8Q0JR+dbs73gOljrZNf EoxkXgJIhOyvNy3DnlnOa2XxJfEx7/Fr1MvxqLz3WSYi9V5oXY1Of/ifTWrbNc5iHW2y 69W0OjUGNKLk31Hn7JYC1U3ymBeaey1QqVAQk3and5o+3ODTAsg76l/kYdW7Cyku/kap cAEQ==
X-Gm-Message-State: ALoCoQlUqKaror0NprwPZdm9DdpVUz3CQyUv+EXptm6pj4WXRBuqQqgkVi9ZEiMjzvKFD8zAQSzf
MIME-Version: 1.0
X-Received: by 10.229.139.199 with SMTP id f7mr11487349qcu.2.1393001602420; Fri, 21 Feb 2014 08:53:22 -0800 (PST)
Received: by 10.140.98.130 with HTTP; Fri, 21 Feb 2014 08:53:22 -0800 (PST)
In-Reply-To: <20140220.214025.454388534.mbj@tail-f.com>
References:   <20140220.214025.454388534.mbj@tail-f.com>
Date: Fri, 21 Feb 2014 08:53:22 -0800
Message-ID: 
From: Andy Bierman 
To: Martin Bjorklund 
Content-Type: multipart/alternative; boundary=001a11c3e454af60ed04f2ed7590
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/7Wm-vUb3Ccz8pa0lTngDPtz127k
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] another XPath question
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 21 Feb 2014 16:53:28 -0000

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

On Thu, Feb 20, 2014 at 12:40 PM, Martin Bjorklund  wrote:

> Andy Bierman  wrote:
> > On Thu, Feb 20, 2014 at 11:38 AM, Andy Bierman 
> wrote:
> >
> > > Hi,
> > >
> > > Here is some YANG text from 7.19.5:
> > >
> > >    o  If the context node represents RPC input parameters, the tree is
> > >       the RPC XML instance document.  The XPath root node has the
> > >       element representing the RPC operation being defined as the only
> > >       child.
> > >
> > >
> > > This seems to say the docroot is the  node (right?)
> > >
> > >
> > >   rpc foo {
> > >      input {
> > >        leaf type { type int8; }
> > >        container num8-stuff {
> > >            when "/nc:rpc/acme:foo/acme:input/acme:type = 8";
> > >             ...
> > >        }
> > >      }
> > >   }
> > >
> > > Is this how an absolute expr for rpc-input would look?
> > > Or does the tree start with acme:foo and not netconf:rpc?
> > > The text is confusing.
> > >
> > >
> >
> > The intent of the first sentence is to say that only the 
> > message (input parameters only) are in the tree.
> > I think sentence 2 should say "rpc" statement instead of "RPC operation".
> > It seems to say  the tree is /acme:foo is a node that has to be named:
> >
> >               when "/acme:foo/acme:input/acme:type = 8";
>
> Why do you think "input" should be there?  The text says:
>

That was a mistake.
The text is clear enough.
It would be nice to add an example of a must or when statement
within the rpc-input, rpc-output, and notification statements.


>    the tree is the RPC XML instance document
>
> there is no "input" element here.
>
> Now the question is which node is the top-level node.
>
> The XML looks like this:
>
>   
>     
>       ...
>       ...
>     
>   
>
> The text says:
>
>   The XPath root node has the element representing the RPC operation
>   being defined as the only child.
>
>
> Is this really unclear?  How could this text be interpreted to mean
> that the root node has multiple children, one for each input
> parameter?
>

I don't think I said that.
It is confusing because it seems to mix YANG statement (RPC
operation being defined) with the  message structure.


>
>
> /martin
>
>
Andy

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





On Thu, Feb 20, 2014 at 12:40 PM, Martin Bjorklund <mbj@tail-f.com> wrote:


Andy Bierman <andy@yumaworks.com> wrote:

> On Thu, Feb 20, 2014 at 11:38 AM, Andy Bierman <andy@yumaworks.com> wrote:

>

> > Hi,

> >

> > Here is some YANG text from 7.19.5:

> >

> > =A0 =A0o =A0If the context node represents RPC input parameters, =
the tree is

> > =A0 =A0 =A0 the RPC XML instance document. =A0The XPath root node=
 has the

> > =A0 =A0 =A0 element representing the RPC operation being defined =
as the only

> > =A0 =A0 =A0 child.

> >

> >

> > This seems to say the docroot is the <rpc> node (right?)
> >

> >

> > =A0 rpc foo {

> > =A0 =A0 =A0input {

> > =A0 =A0 =A0 =A0leaf type { type int8; }

> > =A0 =A0 =A0 =A0container num8-stuff {

> > =A0 =A0 =A0 =A0 =A0 =A0when "/nc:rpc/acme:foo/acme:input/acm=
e:type =3D 8";

> > =A0 =A0 =A0 =A0 =A0 =A0 ...

> > =A0 =A0 =A0 =A0}

> > =A0 =A0 =A0}

> > =A0 }

> >

> > Is this how an absolute expr for rpc-input would look?

> > Or does the tree start with acme:foo and not netconf:rpc?

> > The text is confusing.

> >

> >

>

> The intent of the first sentence is to say that only the <rpc>
> message (input parameters only) are in the tree.

> I think sentence 2 should say "rpc" statement instead of &qu=
ot;RPC operation".

> It seems to say =A0the tree is /acme:foo is a node that has to be name=
d:

>

> =A0 =A0 =A0 =A0 =A0 =A0 =A0 when "/acme:foo/acme:input/acme:type =
=3D 8";



Why do you think "input" should be there? =A0The text says:

That was a mistake.
The text is cl=
ear enough.
It would be nice to add an example of a must or when =
statement


within the rpc-input, rpc-output, and notification statements.




=A0 =A0the tree is the RPC XML instance document



there is no "input" element here.



Now the question is which node is the top-level node.



The XML looks like this:



=A0 <rpc message-id...>

=A0 =A0 <foo xmlns...>

=A0 =A0 =A0 <type>...</type>

=A0 =A0 =A0 <num8-stuff>...</num8-stuff>

=A0 =A0 </foo>

=A0 </rpc>



The text says:



=A0 The XPath root node has the element representing the RPC operation

=A0 being defined as the only child.





Is this really unclear? =A0How could this text be interpreted to mean

that the root node has multiple children, one for each input

parameter?

I don't think I said tha=
t.
It is confusing because it seems to mix YANG statement (RPC
operation being defined) with the <rpc> message structure.

=A0





/martin



Andy

<=
/div>

--001a11c3e454af60ed04f2ed7590--


From nobody Mon Feb 24 00:57:29 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E01411A0834 for ; Mon, 24 Feb 2014 00:57:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.603
X-Spam-Level: 
X-Spam-Status: No, score=0.603 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.547] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S4tMDkNytjCf for ; Mon, 24 Feb 2014 00:57:20 -0800 (PST)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) by ietfa.amsl.com (Postfix) with ESMTP id 27A241A03AB for ; Mon, 24 Feb 2014 00:57:20 -0800 (PST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 646056CC for ; Mon, 24 Feb 2014 09:57:19 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id wUNx336Tvu-D for ; Mon, 24 Feb 2014 09:57:18 +0100 (CET)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by atlas3.jacobs-university.de (Postfix) with ESMTP for ; Mon, 24 Feb 2014 09:57:18 +0100 (CET)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 57AFD20028; Mon, 24 Feb 2014 09:57:18 +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 563GjBbeyzR1; Mon, 24 Feb 2014 09:57:17 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C583C20015; Mon, 24 Feb 2014 09:57:17 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id C82092B73F15; Mon, 24 Feb 2014 07:44:49 +0100 (CET)
Date: Mon, 24 Feb 2014 07:44:49 +0100
From: Juergen Schoenwaelder 
To: netmod@ietf.org
Message-ID: <20140224064449.GA99281@elstar.local>
Mail-Followup-To: netmod@ietf.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/CwHBJen7-7PlqH8j4gbajZogPHc
Subject: [netmod] draft agenda for the London meeting posted
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 24 Feb 2014 08:57:24 -0000

Hi,

I have uploaded a draft agenda. Please lets us know about any
suggested changes. Note that we give preference to items that have
seen some exposure and discussion on the mailing list.

http://www.ietf.org/proceedings/89/agenda/agenda-89-netmod

/js

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


From nobody Mon Feb 24 14:50:03 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBA851A01B7 for ; Mon, 24 Feb 2014 14:50:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.047
X-Spam-Level: 
X-Spam-Status: No, score=-15.047 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QLbwd88EYbbY for ; Mon, 24 Feb 2014 14:49:58 -0800 (PST)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 372B41A0223 for ; Mon, 24 Feb 2014 14:49:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6343; q=dns/txt; s=iport; t=1393282198; x=1394491798; h=from:to:cc:subject:date:message-id:mime-version; bh=J8LrYCQXNKuuPuHS8tV1MzKkfRMHDIlQCWSgnNAW8wY=; b=PgDFgx9DdwwLd6haKDkPvYCoUVW4xaKsFEpLwu06oWzmihNN6BnzwPjN nyzs5ujZl+UFA5Q0rw2MB/adhBuw2BRG4DpigFMxJu0YLLfTSjHoHIA1i cSRGJPTp1HZbsabLokMFX+jp5m7XdoXv2UK1w3szzBgL9BN5vhS4jyDqj E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ArUFALTLC1OtJXG+/2dsb2JhbABZgkJEO1e4VYhYgSAWdIIlAQEBBC1MEgEIEAEEAQELVh0JAQQOBQiHfQ3FfxeOMzGDK4EUBJlmkHWDLYIq
X-IronPort-AV: E=Sophos;i="4.97,537,1389744000";  d="scan'208,217";a="306299578"
Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-4.cisco.com with ESMTP; 24 Feb 2014 22:49:57 +0000
Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id s1OMnvI8022055 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 24 Feb 2014 22:49:57 GMT
Received: from xmb-rcd-x05.cisco.com ([169.254.15.217]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.03.0123.003; Mon, 24 Feb 2014 16:49:56 -0600
From: "Alexander Clemm (alex)" 
To: "netmod@ietf.org" 
Thread-Topic: draft-huang-netmod-acl (Stateless Packet Filter Configuration)
Thread-Index: Ac8p3MNd9/3j+HV/QOKxnW25dyL46AH1O15g
Date: Mon, 24 Feb 2014 22:49:55 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.154.205.170]
Content-Type: multipart/alternative; boundary="_000_DBC595ED2346914F9F81D17DD5C32B57186B5B92xmbrcdx05ciscoc_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/F5AB5HlM_KfJlHlsYiKkJudcBbg
Subject: Re: [netmod] draft-huang-netmod-acl (Stateless Packet Filter Configuration)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 24 Feb 2014 22:50:01 -0000

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

Hello NETMOD working group,

we addressed the comments from the Working Group on earlier versions and we=
 did not receive any new comments on the current version, so we consider th=
e document done.  We would like to request to move it to last call.  Please=
 advise in case there is anything else we need to do.

Thank you and kind regards
--- Alex


From: Alexander Clemm (alex)
Sent: Friday, February 14, 2014 3:38 PM
To: netmod@ietf.org
Cc: Juergen Schoenwaelder (j.schoenwaelder@jacobs-university.de); tnadeau@l=
ucidvision.com; Benoit Claise (bclaise); Andy Bierman (andy@yumaworks.com);=
 Lisa Huang (yihuan)
Subject: draft-huang-netmod-acl (Stateless Packet Filter Configuration)

Hello Netmod Working Group,

we are happy to see that stateless packet filter configuration is likely pa=
rt of the newly revised charter.

We have not posted an update to the current draft (http://tools.ietf.org/ht=
ml/draft-huang-netmod-acl-03), as we think that the current draft addresses=
 all comments that were previously raised by the working group.  However, t=
here has not been discussion on this subject recently.  If you have additio=
nal comments, let's discuss them, otherwise we would like to see the docume=
nt take the "next step".

Thank you and kind regards
--- Alex (on behalf of Lisa, Andy)

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











Hello NETMOD working g=
roup,


 


we addressed the comme=
nts from the Working Group on earlier versions and we did not receive any n=
ew comments on the current version, so we consider the document done. =
 We would like to request to move it to last
 call.  Please advise in case there is anything else we need to do.


 


Thank you and kind reg=
ards


--- Alex


 


 






From: Alexande=
r Clemm (alex)


Sent: Friday, February 14, 2014 3:38 PM

To: netmod@ietf.org

Cc: Juergen Schoenwaelder (j.schoenwaelder@jacobs-university.de); tn=
adeau@lucidvision.com; Benoit Claise (bclaise); Andy Bierman (andy@yumawork=
s.com); Lisa Huang (yihuan)

Subject: draft-huang-netmod-acl (Stateless Packet Filter Configurati=
on)






 


Hello Netmod Working Group,


 


we are happy to see that stateless packet filter con=
figuration is likely part of the newly revised charter. 



 


We have not posted an update to the current draft (<=
a href=3D"http://tools.ietf.org/html/draft-huang-netmod-acl-03">http://tool=
s.ietf.org/html/draft-huang-netmod-acl-03), as we think that the curren=
t draft addresses all comments that
 were previously raised by the working group.  However, there has not =
been discussion on this subject recently.  If you have additional comm=
ents, let’s discuss them, otherwise we would like to see the document=
 take the “next step”. 



 


Thank you and kind regards


--- Alex (on behalf of Lisa, Andy)






--_000_DBC595ED2346914F9F81D17DD5C32B57186B5B92xmbrcdx05ciscoc_--


From nobody Mon Feb 24 15:23:10 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC6B71A0334 for ; Mon, 24 Feb 2014 15:23:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.603
X-Spam-Level: 
X-Spam-Status: No, score=0.603 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.547] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kEW0e2Ak16pQ for ; Mon, 24 Feb 2014 15:23:06 -0800 (PST)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) by ietfa.amsl.com (Postfix) with ESMTP id 01F5D1A0320 for ; Mon, 24 Feb 2014 15:23:05 -0800 (PST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 976E2F7D; Tue, 25 Feb 2014 00:23:04 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id RpzDkuxtTI6a; Tue, 25 Feb 2014 00:23:02 +0100 (CET)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by atlas3.jacobs-university.de (Postfix) with ESMTP; Tue, 25 Feb 2014 00:23:02 +0100 (CET)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id CBAB820028; Tue, 25 Feb 2014 00:23:02 +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 JFldP7Y4WlG4; Tue, 25 Feb 2014 00:23:02 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id E1DC120015; Tue, 25 Feb 2014 00:23:01 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id 138F72B766C5; Tue, 25 Feb 2014 00:22:59 +0100 (CET)
Date: Tue, 25 Feb 2014 00:22:59 +0100
From: Juergen Schoenwaelder 
To: "Alexander Clemm (alex)" 
Message-ID: <20140224232259.GB1879@elstar.local>
Mail-Followup-To: "Alexander Clemm (alex)" , "netmod@ietf.org" , "tnadeau@lucidvision.com" , "Benoit Claise (bclaise)" , "Andy Bierman (andy@yumaworks.com)" , "Lisa Huang (yihuan)" 
References: 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/ba31Rpfy8EvVhv7Hc9Ue9JdiXj4
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] draft-huang-netmod-acl (Stateless Packet Filter Configuration)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 24 Feb 2014 23:23:09 -0000

On Mon, Feb 24, 2014 at 10:49:55PM +0000, Alexander Clemm (alex) wrote:
> Hello NETMOD working group,
> 
> we addressed the comments from the Working Group on earlier versions and we did not receive any new comments on the current version, so we consider the document done.  We would like to request to move it to last call.  Please advise in case there is anything else we need to do.
> 

Alex,

please note that this document right now still has the status of an
individual submission and as such we can't last call it (at least not
in the sense of a WG last call). The normal IETF procedure is that
documents first become WG items (if they fall into the charter of a WG
and the WG adopts a document as a WG document) and one they are stable
WG documents, they go to WG last call. Also note that silence may
indicate there are no open issues but it may also indicate that nobody
bothered to review a document.

>From a quick look at the document, it seems there are leafs without
description clauses etc. which is quite uncommon for IETF data
models. I am also not sure whether you cover IPv4 and IPv6 on equal
footing. (For example, masks are a rather unknown concept in IPv6,
IGMP really is an IPv4 mechanism - so why is it under case ipv6-pfe,
why do you cover ARP but not the ND IPv6 equivalent.) It is unclear
why port filters are limited to TCP, UDP and SCTP - there is as well
DCCP and this may need to be future proofed. Type definitions should
have a canonical representation. There are also more general issues
like module naming conventions etc. that are not followd yet. There is
an empty security considerations section, no IANA considerations
section, a reference section that is amazingly short (given the number
of [normative] references embodied in the YANG modules). And finally,
there are some TODOs in the text that I assume the authors are aware
of.

All this is fine for an individual submission. But a WG product needs
to have many more of these things worked out.

/js

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


From nobody Mon Feb 24 15:36:36 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 885641A02CC for ; Mon, 24 Feb 2014 15:36:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level: 
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.547] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uvaJkmSQZZs9 for ; Mon, 24 Feb 2014 15:36:27 -0800 (PST)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) by ietfa.amsl.com (Postfix) with ESMTP id 923EB1A0223 for ; Mon, 24 Feb 2014 15:36:27 -0800 (PST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 75D2FE5A; Tue, 25 Feb 2014 00:36:26 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id KsF6Qfs6l1bR; Tue, 25 Feb 2014 00:36:22 +0100 (CET)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by atlas3.jacobs-university.de (Postfix) with ESMTP; Tue, 25 Feb 2014 00:36:22 +0100 (CET)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5D98F20015; Tue, 25 Feb 2014 00:36:22 +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 V2UBEUbBY-9E; Tue, 25 Feb 2014 00:36:22 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 04BDB20027; Tue, 25 Feb 2014 00:36:20 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id 0C5342B76826; Tue, 25 Feb 2014 00:36:17 +0100 (CET)
Date: Tue, 25 Feb 2014 00:36:17 +0100
From: Juergen Schoenwaelder 
To: "Alexander Clemm (alex)" , "netmod@ietf.org" , "tnadeau@lucidvision.com" , "Benoit Claise (bclaise)" , "Andy Bierman (andy@yumaworks.com)" , "Lisa Huang (yihuan)" 
Message-ID: <20140224233617.GA1984@elstar.local>
Mail-Followup-To: "Alexander Clemm (alex)" , "netmod@ietf.org" , "tnadeau@lucidvision.com" , "Benoit Claise (bclaise)" , "Andy Bierman (andy@yumaworks.com)" , "Lisa Huang (yihuan)" 
References:  <20140224232259.GB1879@elstar.local>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20140224232259.GB1879@elstar.local>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/Tb4W0XHfvnXGopg6Ghj7CjP4U4Y
Subject: Re: [netmod] draft-huang-netmod-acl (Stateless Packet Filter Configuration)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 24 Feb 2014 23:36:32 -0000

On Tue, Feb 25, 2014 at 12:22:59AM +0100, Juergen Schoenwaelder wrote:
> On Mon, Feb 24, 2014 at 10:49:55PM +0000, Alexander Clemm (alex) wrote:
> > Hello NETMOD working group,
> > 
> > we addressed the comments from the Working Group on earlier versions and we did not receive any new comments on the current version, so we consider the document done.  We would like to request to move it to last call.  Please advise in case there is anything else we need to do.
> > 
> 

One more thing before I go to sleep: The leaf tcp-flag-operation
specifies behaviour in the description clause that goes beyond YANG
rules - you can't simply stick more information into an enum by
appending magic strings to the enum name.

/js

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


From nobody Mon Feb 24 15:51:54 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1A0E1A0307 for ; Mon, 24 Feb 2014 15:51:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.048
X-Spam-Level: 
X-Spam-Status: No, score=-15.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VO64bZlCiSfx for ; Mon, 24 Feb 2014 15:51:50 -0800 (PST)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id A387B1A01D5 for ; Mon, 24 Feb 2014 15:51:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2934; q=dns/txt; s=iport; t=1393285910; x=1394495510; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=FOP40EtTR2GooFiHHOixV4VhH+x7tYL7PPM68QKofa0=; b=BDa4Or67Zq6lESt5P4D/iY7ElqiT2/ArqudDhdWqDNrSGSJd+x+I6wEF g3jU0zyvamYcZqFZTeuAIvO+dvbisQPZfaYFh/276ZFljM9OGu/omcNYD oe3F2jVq7ogKwP5puoBMmR4pJ2xK1onDClKzDzDus8CT435gUKg0sdTng 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgQFAKLaC1OtJV2c/2dsb2JhbABWA4MGO1fBNIEaFnSCJQEBAQQ6PwwCAgIBCA4CAQQBAQEKFAkHGxcUCQgBAQQOBQiHfcYdFwSOCCchEAcGC4MTgRQEqluDLYFoQg
X-IronPort-AV: E=Sophos;i="4.97,537,1389744000"; d="scan'208";a="306037295"
Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-1.cisco.com with ESMTP; 24 Feb 2014 23:51:49 +0000
Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s1ONpnNX008026 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 24 Feb 2014 23:51:49 GMT
Received: from xmb-rcd-x05.cisco.com ([169.254.15.217]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.03.0123.003; Mon, 24 Feb 2014 17:51:49 -0600
From: "Alexander Clemm (alex)" 
To: Juergen Schoenwaelder 
Thread-Topic: draft-huang-netmod-acl (Stateless Packet Filter Configuration)
Thread-Index: Ac8p3MNd9/3j+HV/QOKxnW25dyL46AH1O15gAA39J4AAC7b04A==
Date: Mon, 24 Feb 2014 23:51:49 +0000
Message-ID: 
References:  <20140224232259.GB1879@elstar.local>
In-Reply-To: <20140224232259.GB1879@elstar.local>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.154.205.170]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/fidFHLRY4hz1IY78uHc6XjHA2_g
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] draft-huang-netmod-acl (Stateless Packet Filter Configuration)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 24 Feb 2014 23:51:52 -0000

Hi Juergen,
Thank you for your response.  Clearly, we need some guidance from you and t=
he working group. =20
Looking forward to the discussion at the working group meeting.  Andy will =
present as neither Lisa nor I will be there in person.
--- Alex

-----Original Message-----
From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]=20
Sent: Monday, February 24, 2014 3:23 PM
To: Alexander Clemm (alex)
Cc: netmod@ietf.org; tnadeau@lucidvision.com; Benoit Claise (bclaise); Andy=
 Bierman (andy@yumaworks.com); Lisa Huang (yihuan)
Subject: Re: draft-huang-netmod-acl (Stateless Packet Filter Configuration)

On Mon, Feb 24, 2014 at 10:49:55PM +0000, Alexander Clemm (alex) wrote:
> Hello NETMOD working group,
>=20
> we addressed the comments from the Working Group on earlier versions and =
we did not receive any new comments on the current version, so we consider =
the document done.  We would like to request to move it to last call.  Plea=
se advise in case there is anything else we need to do.
>=20

Alex,

please note that this document right now still has the status of an individ=
ual submission and as such we can't last call it (at least not in the sense=
 of a WG last call). The normal IETF procedure is that documents first beco=
me WG items (if they fall into the charter of a WG and the WG adopts a docu=
ment as a WG document) and one they are stable WG documents, they go to WG =
last call. Also note that silence may indicate there are no open issues but=
 it may also indicate that nobody bothered to review a document.

>From a quick look at the document, it seems there are leafs without descrip=
tion clauses etc. which is quite uncommon for IETF data models. I am also n=
ot sure whether you cover IPv4 and IPv6 on equal footing. (For example, mas=
ks are a rather unknown concept in IPv6, IGMP really is an IPv4 mechanism -=
 so why is it under case ipv6-pfe, why do you cover ARP but not the ND IPv6=
 equivalent.) It is unclear why port filters are limited to TCP, UDP and SC=
TP - there is as well DCCP and this may need to be future proofed. Type def=
initions should have a canonical representation. There are also more genera=
l issues like module naming conventions etc. that are not followd yet. Ther=
e is an empty security considerations section, no IANA considerations secti=
on, a reference section that is amazingly short (given the number of [norma=
tive] references embodied in the YANG modules). And finally, there are some=
 TODOs in the text that I assume the authors are aware of.

All this is fine for an individual submission. But a WG product needs to ha=
ve many more of these things worked out.

/js

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


From nobody Mon Feb 24 18:59:19 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 430761A03D6 for ; Mon, 24 Feb 2014 18:59:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.048
X-Spam-Level: 
X-Spam-Status: No, score=-10.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T0clh_xmb830 for ; Mon, 24 Feb 2014 18:59:15 -0800 (PST)
Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) by ietfa.amsl.com (Postfix) with ESMTP id 742781A03E7 for ; Mon, 24 Feb 2014 18:59:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=979; q=dns/txt; s=iport; t=1393297151; x=1394506751; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=lKeF+3lRXS9yfUqOaE02CTCt+VIFAdpsm6S4T7Ju55M=; b=X8TL01OJr3+rfduKtWm1eydkaJrzhE2/DcBz2HnCDotReHG3cBAiQrYV Z45LaJW1JpvN8VzhX9ivIfSyTqCi0JGr+ZLakcole/kyS4IjFeiBaAxfG 2NNk7vYF+H8c0Mvj3kFLP5LBlABo0ZigGSU6EDbrKAbT61vIRtSf1jmPP E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgEFAI0GDFOtJV2a/2dsb2JhbABZgwY7V8JnFnSCJQEBAQQBAQFrHQEIbQsbAQYFBBOIBQ2Wcq9fEwSTIwSYNJIngy2CKg
X-IronPort-AV: E=Sophos;i="4.97,538,1389744000"; d="scan'208";a="22906089"
Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-4.cisco.com with ESMTP; 25 Feb 2014 02:59:10 +0000
Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s1P2xAWY020857 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 25 Feb 2014 02:59:10 GMT
Received: from xmb-aln-x11.cisco.com ([169.254.6.164]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0123.003; Mon, 24 Feb 2014 20:59:10 -0600
From: "Yi Yang (yiya)" 
To: "netmod@ietf.org" 
Thread-Topic: [i2rs] draft-clemm-i2rs-yang-network-topo-00: router-type for ospf
Thread-Index: AQHPMdWNAyg4nKTj9kKz5/y8X+zEJA==
Date: Tue, 25 Feb 2014 02:59:09 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.3.9.131030
x-originating-ip: [10.116.75.11]
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <35708C84974D8E45B4A7C1756B64E130@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/CrJlNF7gFfaVa0-XXWEeWHHINOc
Subject: [netmod] FW: [i2rs] draft-clemm-i2rs-yang-network-topo-00: router-type for ospf
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 25 Feb 2014 02:59:17 -0000

As the draft was originally posted on netmod WG=8A

Yi

On 2/24/14 9:56 PM, "Yi Yang (yiya)"  wrote:

>In the OSPF data model, router-type is specified as choice, which is
>inconsistent to RFC2328, which specifies that an ASBR could be an internal
>router (or ABR) simultaneously. In addition, a missing router-type is
>backbone router. One way to fix this is as following:
>
>container ospf-node-attributes {
>    container router-type {
>        leaf abr {
>            type empty;
>        }
>        leaf asbr {
>            type empty;
>        }
>        leaf internal {
>            must "boolean(../abr)=3D'false'"
>                // an internal router will never be abr
>            type empty;
>        }
>        leaf backbone {
>            type empty;
>        }
>        ...
>
>
>Yi
>
>_______________________________________________
>i2rs mailing list
>i2rs@ietf.org
>https://www.ietf.org/mailman/listinfo/i2rs


From nobody Tue Feb 25 04:59:30 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24DF61A036B for ; Tue, 25 Feb 2014 04:19:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zfbp6oGAplHu for ; Tue, 25 Feb 2014 04:19:10 -0800 (PST)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 26AC61A06C7 for ; Tue, 25 Feb 2014 04:19:08 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
To: netmod@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 5.0.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20140225121908.25505.78014.idtracker@ietfa.amsl.com>
Date: Tue, 25 Feb 2014 04:19:08 -0800
From: IETF Secretariat 
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/uqKte0PTj0E1xiCHH7f6f1ukfvs
X-Mailman-Approved-At: Tue, 25 Feb 2014 04:59:28 -0800
Subject: [netmod] Milestones changed for netmod WG
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 25 Feb 2014 12:19:11 -0000

Changed milestone "Submit Routing data model to the IESG (proposed
standard)", added draft-ietf-netmod-routing-cfg to milestone.

URL: http://datatracker.ietf.org/wg/netmod/charter/


From nobody Tue Feb 25 04:59:33 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 976891A03EB for ; Tue, 25 Feb 2014 04:56:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2vxRRPuevKLt for ; Tue, 25 Feb 2014 04:56:50 -0800 (PST)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4562A1A06E0 for ; Tue, 25 Feb 2014 04:56:50 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
To: netmod@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 5.0.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20140225125650.26054.81555.idtracker@ietfa.amsl.com>
Date: Tue, 25 Feb 2014 04:56:50 -0800
From: IETF Secretariat 
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/N1nJlUN3W60hsCKx9KxHy8hRMY8
X-Mailman-Approved-At: Tue, 25 Feb 2014 04:59:29 -0800
Subject: [netmod] Milestones changed for netmod WG
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 25 Feb 2014 12:56:51 -0000

Changed milestone "Submit Data model for configuring SNMP engines to
the IESG (proposed standard)", added draft-ietf-netmod-snmp-cfg to
milestone.

URL: http://datatracker.ietf.org/wg/netmod/charter/


From nobody Tue Feb 25 04:59:35 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B58FB1A0089 for ; Tue, 25 Feb 2014 04:57:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zhv0pqzFULr9 for ; Tue, 25 Feb 2014 04:57:19 -0800 (PST)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E5761A03F2 for ; Tue, 25 Feb 2014 04:57:19 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
To: netmod@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 5.0.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20140225125719.28051.13492.idtracker@ietfa.amsl.com>
Date: Tue, 25 Feb 2014 04:57:19 -0800
From: IETF Secretariat 
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/s8TKgMDRuNXdKJYAn3R0cl1_UMk
X-Mailman-Approved-At: Tue, 25 Feb 2014 04:59:29 -0800
Subject: [netmod] Milestones changed for netmod WG
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 25 Feb 2014 12:57:20 -0000

Changed milestone "Submit SMIv2 to YANG translation to the IESG
(proposed standard)", resolved as "Done".

Changed milestone "Submit first working group draft of Data model for
configuring SNMP engines", resolved as "Done".

URL: http://datatracker.ietf.org/wg/netmod/charter/


From nobody Tue Feb 25 04:59:37 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA4CD1A0089 for ; Tue, 25 Feb 2014 04:58:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xQ20h7--4Zbf for ; Tue, 25 Feb 2014 04:58:23 -0800 (PST)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CB0751A0443 for ; Tue, 25 Feb 2014 04:58:22 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
To: netmod@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 5.0.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20140225125822.17909.43081.idtracker@ietfa.amsl.com>
Date: Tue, 25 Feb 2014 04:58:22 -0800
From: IETF Secretariat 
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/c_CmKVhvTYBmq50HATiMe7lXOCc
X-Mailman-Approved-At: Tue, 25 Feb 2014 04:59:29 -0800
Subject: [netmod] Milestones changed for netmod WG
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 25 Feb 2014 12:58:25 -0000

Changed milestone "Submit Interface data model to the IESG (proposed
standard)", added draft-ietf-netmod-interfaces-cfg,
draft-ietf-netmod-ip-cfg to milestone.

Changed milestone "Submit System data model to the IESG (proposed
standard)", added draft-ietf-netmod-system-mgmt to milestone.

URL: http://datatracker.ietf.org/wg/netmod/charter/


From nobody Tue Feb 25 07:46:16 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C1FB1A07B1 for ; Tue, 25 Feb 2014 07:46:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.447
X-Spam-Level: 
X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HTcmUnRDmwJ3 for ; Tue, 25 Feb 2014 07:46:07 -0800 (PST)
Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 1C3B11A07B2 for ; Tue, 25 Feb 2014 07:46:07 -0800 (PST)
Received: from [192.168.1.122] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id 042BD2706231 for ; Tue, 25 Feb 2014 10:46:05 -0500 (EST)
From: Thomas Nadeau 
Content-Type: multipart/signed; boundary="Apple-Mail=_3E146907-F772-4659-8FFA-F6F79F7CDE0A"; protocol="application/pgp-signature"; micalg=pgp-sha512
Message-Id: 
Date: Tue, 25 Feb 2014 10:46:05 -0500
To: netmod@ietf.org
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
X-Mailer: Apple Mail (2.1827)
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/gC6ZhUTuJzGlpqPvHQzUiYhjawA
Subject: [netmod] implementations of draft-ietf-netmod-snmp-cfg
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 25 Feb 2014 15:46:10 -0000

--Apple-Mail=_3E146907-F772-4659-8FFA-F6F79F7CDE0A
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=us-ascii


	I would like to poll for any implementations of draft-ietf-netmod-snmp-cfg. 
Please either post to the list, or contact me privately if you would like to
keep the information confidential. 

	--Tom (NETMOD co-chair)



--Apple-Mail=_3E146907-F772-4659-8FFA-F6F79F7CDE0A
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJTDLq9AAoJEPcO+I7eiUJZk+IQAIdfpSOSXFKV3kyIodWLmOqz
Z2qL657cn4Fl+krl5VG0xq99XGj6Y/xLSdNt7yMB2ugu9xbA7oOQT7m3PggHlUda
6fmYy7UR8TLVRYVaKRtkvB9Tu0e1Sr7qE4A6BwyrPYRVeCSmOMyJ7v8Umoq/2Ggj
6RCryEIo8+af4NRREiNvKky1rg5/kKDpqY0KZZPCzTljt8QAmilDowA6VPZjP6qr
2ft7U9emtLMRMO9wKyQKN1WoJEwSdOS/29/dddiKXlo5ItSECyzBzHELRXo5D4pi
qNP2xkK4caFRFw5sEwvMlHm8hGPWsr2BijUGLl5IBQHBs7QL+/VtpO3TWXf7w+gt
7X4Jia+hqr4VPg7ufZ8WucfyZtEZBLimURoxyxrPrlnTBW6KQWSBSrQ8qoXQh9aD
KJlzg5gPrS24Eo1q6p7Kj0R9yl13XBEa+fpU0BRSauObzjU2GSOmoTCMP4CyNi/r
Bj0TILtqh9oyHIkPOljeJ2vhya1IER9MyDEDiXSFyx1TfqlTHhRWlIqVTl+DdghG
8glfbG4fmT5dPHZMNLswMlh638dLFdYpzi2D4ABesjUe1zAop5gwuwchXKNRfmYm
kKDukgnh3SHMeXk8oRGK9lTjAfi1roagS5xyreuRsAovXywbmur3LhOD4KgDPBk9
lY617/3W2zzbrKwWZtCJ
=Jkes
-----END PGP SIGNATURE-----

--Apple-Mail=_3E146907-F772-4659-8FFA-F6F79F7CDE0A--


From nobody Tue Feb 25 07:50:52 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 878711A00E8 for ; Tue, 25 Feb 2014 07:50:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.447
X-Spam-Level: 
X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BYr3FeviArK3 for ; Tue, 25 Feb 2014 07:50:49 -0800 (PST)
Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id DB5CD1A00DF for ; Tue, 25 Feb 2014 07:50:48 -0800 (PST)
Received: from [192.168.1.122] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id BA126270627A for ; Tue, 25 Feb 2014 10:50:47 -0500 (EST)
From: Thomas Nadeau 
Content-Type: multipart/signed; boundary="Apple-Mail=_0B6D7ECB-9E22-4020-8004-E48FDC2DF9E4"; protocol="application/pgp-signature"; micalg=pgp-sha512
Message-Id: <353A5983-B1C7-4ECA-AC95-C674EAE4F54C@lucidvision.com>
Date: Tue, 25 Feb 2014 10:50:46 -0500
To: netmod@ietf.org
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
X-Mailer: Apple Mail (2.1827)
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/QiWfB_34eIbHUvpj_wWxh2A3kqo
Subject: [netmod] IPR Poll for draft-ietf-netmod-snmp-cfg-04
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 25 Feb 2014 15:50:50 -0000

--Apple-Mail=_0B6D7ECB-9E22-4020-8004-E48FDC2DF9E4
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii


	Netmod WG:

	This mail starts the IPR poll on draft-ietf-netmod-snmp-cfg-04.

	Are you aware of any IPR that applies to =
draft-ietf-netmod-snmp-cfg-04?
If so, has this IPR been disclosed in compliance with IETF IPR rules =
(see RFCs
3979, 4879, 3669 and 5378 for more details).

	If you are listed as a document author or contributor please =
respond to this
email explicitly regardless of whether or not you are aware of any =
relevant IPR.
*The response needs to be sent to the EMAN wg mailing list.* The =
document
will not advance to the next stage until a response has been received =
from *each
author and contributor*.

	If you are on the NETMOD WG email list but are not listed as an =
author or
contributor, then please explicitly respond only if you are aware of any =
IPR that
has not yet been disclosed in conformance with IETF rules.

	Thank you,

	Tom and Juergen, NETMOD WG Chairs


--Apple-Mail=_0B6D7ECB-9E22-4020-8004-E48FDC2DF9E4
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJTDLvWAAoJEPcO+I7eiUJZiDwP/jluk9lLghWYH2CBgwCepYLw
j0wZ6l0cSBGXgCb2Ej++sfV7IUv5cae9AwfnLDHInYN0Vl1LLnU4dD9et1Tf+MYT
hwIgiO5xDKpWiAO43iJsh4OgXLXwshXWL1rYVfQp+ywiV7xV24L44yL22g7/sFMM
usXFtzkaenn4FYs5gXcckQF8uBTIhF3764roNEe1qV3Emo8V3MLWUy25CmWCfWCJ
Gr6Za6WwrwhtvjkXTXSplNAmvgAs69QmKeB0hlCx0i8eLZnIk8mGwLbZevQbQS0z
2rKBvnulMNGYylSfjA3mOQnOOExKmqbbR22h25m6J+zY8tbRSu/9izU1VZj1ylHE
mGjVA9ADp+XHcrpQW+qP3Hx7ItBpLLTGqkN+guxxqKRZhcBGnn1AdNwfuIOPIimH
mG3K1pWl0upJNSLbUF5C7d3Aalnv+Er/JtIw7GTIY0Wh7mB6EDw9FR9DV/C+mvdR
wqnMsLMdNXtEAz0/396OV+diKjViUxixCPSGF9TFa+Z0FBbmNm6C457WqHVaJoQ/
Q20VVSNc2m+whEVW/LmPSDtwG6ISTUuQeSqyxmNG1dw/zH4RTSKo2GTvbnlvRZHj
wb1vIgOL6oqFsZfyx6Dx7IMXR1sF6DduUJGsvCzF2NM6K2diF/dd0eUncjVF+hny
fVyciDuBH8lBQzvV260k
=BOL5
-----END PGP SIGNATURE-----

--Apple-Mail=_0B6D7ECB-9E22-4020-8004-E48FDC2DF9E4--


From nobody Tue Feb 25 07:56:58 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2FA81A00DF for ; Tue, 25 Feb 2014 07:56:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.198
X-Spam-Level: 
X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.547] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r9NAbfB7H8-s for ; Tue, 25 Feb 2014 07:56:54 -0800 (PST)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) by ietfa.amsl.com (Postfix) with ESMTP id C26A21A00C9 for ; Tue, 25 Feb 2014 07:56:54 -0800 (PST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 128F8F99; Tue, 25 Feb 2014 16:56:53 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id Ol6X-5pPDDYV; Tue, 25 Feb 2014 16:56:52 +0100 (CET)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by atlas3.jacobs-university.de (Postfix) with ESMTP; Tue, 25 Feb 2014 16:56:51 +0100 (CET)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id EE43B20026; Tue, 25 Feb 2014 16:56:51 +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 zfIA_SnXoNhm; Tue, 25 Feb 2014 16:56:51 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7E34620015; Tue, 25 Feb 2014 16:56:51 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id 25FD12B79EB2; Tue, 25 Feb 2014 16:56:48 +0100 (CET)
Date: Tue, 25 Feb 2014 16:56:48 +0100
From: Juergen Schoenwaelder 
To: Thomas Nadeau 
Message-ID: <20140225155648.GB4168@elstar.local>
Mail-Followup-To: Thomas Nadeau , netmod@ietf.org
References: <353A5983-B1C7-4ECA-AC95-C674EAE4F54C@lucidvision.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <353A5983-B1C7-4ECA-AC95-C674EAE4F54C@lucidvision.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/G99SCzRjBjDXVNedSqgJmYT7AQU
Cc: netmod@ietf.org
Subject: Re: [netmod] IPR Poll for draft-ietf-netmod-snmp-cfg-04
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 25 Feb 2014 15:56:57 -0000

On Tue, Feb 25, 2014 at 10:50:46AM -0500, Thomas Nadeau wrote:
> 
> 	If you are listed as a document author or contributor please respond to this
> email explicitly regardless of whether or not you are aware of any relevant IPR.
> *The response needs to be sent to the EMAN wg mailing list.* The document
> will not advance to the next stage until a response has been received from *each
> author and contributor*.
> 

I am not aware of IPR claims against this document.

/js

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


From nobody Tue Feb 25 08:04:56 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E45581A013C for ; Tue, 25 Feb 2014 08:04:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.548
X-Spam-Level: 
X-Spam-Status: No, score=-0.548 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RP_MATCHES_RCVD=-0.547] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nGx0KraL3F1c for ; Tue, 25 Feb 2014 08:04:53 -0800 (PST)
Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 701F81A0139 for ; Tue, 25 Feb 2014 08:04:53 -0800 (PST)
Received: from [192.168.1.122] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id 7A22D270631D for ; Tue, 25 Feb 2014 11:04:52 -0500 (EST)
From: Thomas Nadeau 
Content-Type: multipart/signed; boundary="Apple-Mail=_AEE7F33F-C68E-4CD8-8D31-9C47E8DE3130"; protocol="application/pgp-signature"; micalg=pgp-sha512
Message-Id: <6F7DCE60-3B7D-4365-B0C4-4A7BEE3CA947@lucidvision.com>
Date: Tue, 25 Feb 2014 11:04:51 -0500
To: netmod@ietf.org
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
X-Mailer: Apple Mail (2.1827)
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/4C9rGBaqZhRoe-ZpRCmaymArBo0
Subject: [netmod] draft-ietf-netmod-snmp-cfg
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 25 Feb 2014 16:04:55 -0000

--Apple-Mail=_AEE7F33F-C68E-4CD8-8D31-9C47E8DE3130
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=us-ascii


	EMAN WG,

	FYI I took over shepherding this document for David. 
I understand there was a WG last call that lead to a number of comments. 
The authors believe they have addressed the comments in the latest
update. I would like to ask the WG one last time to verify the 
changes made between versions -03 and -04. If you feel that the 
WG last comments have not been addressed to your liking, please
comment on the list by Friday, February 28, 9AM EDT.

	--Tom (as NETMOD Co-chair)





--Apple-Mail=_AEE7F33F-C68E-4CD8-8D31-9C47E8DE3130
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJTDL8jAAoJEPcO+I7eiUJZgHAQAI5Fuq2RAqs3n+NHaYbnoN7T
E2vWBVXCjyh4oJdPFLy+85ZJ6u+OSmKHwVZFh9oDAKUajyxBpenfAUZj0marND5L
CwOkw783M77srpLKVBJPybB6pTLu5chlns+fad279xRs78jI9sf3RhKV6KnATFxn
zGdX19Tw2fVrCzSiVYVF8BOLnr0NiHfTPVjFSqcljqhNu8tk5M1q7YFOoeUPBA8T
4FR1cXwioyLL0Bz7zQusdJ6JECW5XR+zQmiwv1pwLksu3N9P4pREM8e5wr1iroxU
xq3b5WBU2Mr316lNgbixm9cvrvj6GBGEeLkis787Wq1mEu6y2JdaS27cdVf3WEg4
sabElx8O3tO5B/4vxfI+o951kH8lhc72y2ciYSVRvs1IL4/XgjfUKI6JBGYgn2VP
1r6umruGze0gjwmypgZ1SJTk/oq6JMwgxiI8m0o42XgJ9TjUB6tZUpqganATbkmY
lN1GSvNK4e5Tlwqp+MAro0wdRk6gDx7j+WQBmJu08XMA1jWz5Zd3NJuCeW2+XEEf
YHn+SQAj4nbdFSE4RnpL6ygbzmnUpGLDojN6fwirjV/EhjwFgBXJxwsuACWMmQep
FBi137nriiFd+5J5w+54qwx750867aie4TktT8hHK2ey02/czyKO4gIYtiI9V6Uc
YH9OJYrHOTcHFViTW3UL
=l3oA
-----END PGP SIGNATURE-----

--Apple-Mail=_AEE7F33F-C68E-4CD8-8D31-9C47E8DE3130--


From nobody Tue Feb 25 09:04:59 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 368491A01DB for ; Tue, 25 Feb 2014 09:04:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.448
X-Spam-Level: 
X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FLyO6nzq8-51 for ; Tue, 25 Feb 2014 09:04:54 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id A29071A0735 for ; Tue, 25 Feb 2014 09:04:54 -0800 (PST)
Received: from localhost (host-90-236-97-95.mobileonline.telia.com [90.236.97.95]) by mail.tail-f.com (Postfix) with ESMTPSA id 4232737C27A; Tue, 25 Feb 2014 18:04:52 +0100 (CET)
Date: Tue, 25 Feb 2014 18:04:50 +0100 (CET)
Message-Id: <20140225.180450.277764133.mbj@tail-f.com>
To: tnadeau@lucidvision.com
From: Martin Bjorklund 
In-Reply-To: 
References: 
X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/FeqSrCp6HN4uQG7e6P1PFmuy3UM
Cc: netmod@ietf.org
Subject: Re: [netmod] implementations of draft-ietf-netmod-snmp-cfg
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 25 Feb 2014 17:04:56 -0000

Hi,

Thomas Nadeau  wrote:
> 
> 	I would like to poll for any implementations of
> 	draft-ietf-netmod-snmp-cfg.
> Please either post to the list, or contact me privately if you would
> like to
> keep the information confidential. 

We have an implementation of an early version of this data model, and
we plan to update the implementation to match the current version.  I
see no problems in doing so.


/martin


From nobody Tue Feb 25 09:06:47 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4221F1A0815 for ; Tue, 25 Feb 2014 09:06:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.448
X-Spam-Level: 
X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2-PLQhPxc-xt for ; Tue, 25 Feb 2014 09:06:44 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id 0C8BB1A0822 for ; Tue, 25 Feb 2014 09:06:44 -0800 (PST)
Received: from localhost (host-90-236-97-95.mobileonline.telia.com [90.236.97.95]) by mail.tail-f.com (Postfix) with ESMTPSA id A42A837C278; Tue, 25 Feb 2014 18:06:41 +0100 (CET)
Date: Tue, 25 Feb 2014 18:06:40 +0100 (CET)
Message-Id: <20140225.180640.435787464.mbj@tail-f.com>
To: tnadeau@lucidvision.com
From: Martin Bjorklund 
In-Reply-To: <353A5983-B1C7-4ECA-AC95-C674EAE4F54C@lucidvision.com>
References: <353A5983-B1C7-4ECA-AC95-C674EAE4F54C@lucidvision.com>
X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/VY0rN81Cmle4MShVidOXD7mTqGI
Cc: netmod@ietf.org
Subject: Re: [netmod] IPR Poll for draft-ietf-netmod-snmp-cfg-04
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 25 Feb 2014 17:06:45 -0000

Thomas Nadeau  wrote:
> 
> 	Netmod WG:
> 
> 	This mail starts the IPR poll on draft-ietf-netmod-snmp-cfg-04.
> 
> 	Are you aware of any IPR that applies to
> 	draft-ietf-netmod-snmp-cfg-04?
> If so, has this IPR been disclosed in compliance with IETF IPR rules
> (see RFCs
> 3979, 4879, 3669 and 5378 for more details).
> 
> 	If you are listed as a document author or contributor please respond
> 	to this
> email explicitly regardless of whether or not you are aware of any
> relevant IPR.
> *The response needs to be sent to the EMAN wg mailing list.

(s/EMAN/NETMOD/)

I am not aware of any IPR that applies to this document.


/martin


From nobody Tue Feb 25 10:47:06 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF7491A0199 for ; Tue, 25 Feb 2014 10:47:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.447
X-Spam-Level: 
X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cq6HLTbf4uFG for ; Tue, 25 Feb 2014 10:46:57 -0800 (PST)
Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 383BF1A0127 for ; Tue, 25 Feb 2014 10:46:57 -0800 (PST)
Received: from [192.168.1.122] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id 203292706979; Tue, 25 Feb 2014 13:46:56 -0500 (EST)
Content-Type: multipart/signed; boundary="Apple-Mail=_1315063B-3480-42D3-A015-6328A9F52A4A"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Thomas Nadeau 
In-Reply-To: <20140225.180640.435787464.mbj@tail-f.com>
Date: Tue, 25 Feb 2014 13:46:54 -0500
Message-Id: <9A830EE7-FAAB-4832-A848-71F1FDB65752@lucidvision.com>
References: <353A5983-B1C7-4ECA-AC95-C674EAE4F54C@lucidvision.com> <20140225.180640.435787464.mbj@tail-f.com>
To: Martin Bjorklund 
X-Mailer: Apple Mail (2.1827)
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/FpSTaW9wV6FvN6ynOBI8ryivdqA
Cc: netmod@ietf.org
Subject: Re: [netmod] IPR Poll for draft-ietf-netmod-snmp-cfg-04
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 25 Feb 2014 18:47:01 -0000

--Apple-Mail=_1315063B-3480-42D3-A015-6328A9F52A4A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii


	Sorry folks, please replace EMAN w/ NETMOD! I was doing some =
work for EMAN in parallel. *)

	--Tom


On Feb 25, 2014:12:06 PM, at 12:06 PM, Martin Bjorklund  =
wrote:

> Thomas Nadeau  wrote:
>>=20
>> 	Netmod WG:
>>=20
>> 	This mail starts the IPR poll on draft-ietf-netmod-snmp-cfg-04.
>>=20
>> 	Are you aware of any IPR that applies to
>> 	draft-ietf-netmod-snmp-cfg-04?
>> If so, has this IPR been disclosed in compliance with IETF IPR rules
>> (see RFCs
>> 3979, 4879, 3669 and 5378 for more details).
>>=20
>> 	If you are listed as a document author or contributor please =
respond
>> 	to this
>> email explicitly regardless of whether or not you are aware of any
>> relevant IPR.
>> *The response needs to be sent to the EMAN wg mailing list.
>=20
> (s/EMAN/NETMOD/)
>=20
> I am not aware of any IPR that applies to this document.
>=20
>=20
> /martin
>=20


--Apple-Mail=_1315063B-3480-42D3-A015-6328A9F52A4A
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJTDOUeAAoJEPcO+I7eiUJZxwEP/0fCvIxMU3ByjOcLdu4h7N4U
vKEhKhwSR/0S3+hr/HouXts09o1YltKMF9X2EoROkgjZ6AjYT3NAlvh6BjzTDoO9
KFMR/rB5mhM0te1VyvhkSilarMRWjWhjKDdabcpbR2hXsce5YxyvpAUsZ8O3RisI
kH/DFXEfYdqyQpGkS3rHtOwrUkwfxiuV4n9isiGl2ztMNlfQWnaKDNf9sZ9qzsEy
fkBSTd3kF+G9NKsvP8ylcYGpNkGxQ4uj6ngYj18sVWdXsONfSm2SYU5LDBjKfYd8
q1y4H8JscruuHCUAnpuKVHXav7v65dAUWBAoGLjZf4gzzvbu9SPshcdg5NPzbe4S
QzododerOa31thaQhxc8AAaD/NwLy7xD3BX+TyYMf9fuCMDXwKr5WBg8LtTqFH6c
Ih1+CXBw4fklLwYnGCr2wX4WFK9CrbZK4D0oO2gDJl0cLEQoQ9uG0nTNxlhzPpbU
W3rccU98q3IPL+Z6FxBZTuatWPY4uC9sz2beHWOFNSE4bJpYRTYaNsruOsolsSSA
pIRUc6CygmaUzu09tp3XGQ8ud3ykKHG81/J+MtsELdNN4Rw/7aXOtNY2oJvvxmXy
jD29yqGOYTURcEMsiYAMH7GYKwmxuqA7d7bmngKh9ZsCtmEdgOjtnrlT9NO+TJvm
NNLPOfe9XsiZExNqgkkb
=KbZo
-----END PGP SIGNATURE-----

--Apple-Mail=_1315063B-3480-42D3-A015-6328A9F52A4A--


From nobody Wed Feb 26 11:11:58 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD87C1A07F8 for ; Wed, 26 Feb 2014 11:11:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.347
X-Spam-Level: 
X-Spam-Status: No, score=-7.347 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bqbJxIMty4Pz for ; Wed, 26 Feb 2014 11:11:46 -0800 (PST)
Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) by ietfa.amsl.com (Postfix) with ESMTP id 8A0241A080D for ; Wed, 26 Feb 2014 11:10:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=25386; q=dns/txt; s=iport; t=1393441848; x=1394651448; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=BBXQOxQBq3tioI2K9r8bb48brvITmpt9OpUzcuuVQHs=; b=lhJEDctyeHC1ekZsBo/L+guT3j5OtYTVfM8u+3sIqYYhYk0Ky74uA9dN H7U/AyccMJJpTiwyqGgBRZNfnx+y1+zpeh+vl1A3yuCQFJQ0aOX51JGuM ZxEE1vXfwR/ZFKmvequQOKQp/fAEZ7cE2272DxSCTRz/9L6bQKrbQA48I g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhoFABM7DlOtJXG9/2dsb2JhbABagkJEgRLAcYEaFnSCLg5XFBIBCA4CKAc5FBEBAQQBDQUbh17JQheNfFgHAoQ1BJg2kiiDLYFoQg
X-IronPort-AV: E=Sophos; i="4.97,549,1389744000"; d="scan'208,217"; a="23411392"
Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by alln-iport-6.cisco.com with ESMTP; 26 Feb 2014 19:10:47 +0000
Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id s1QJAlat003979 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 26 Feb 2014 19:10:47 GMT
Received: from xmb-aln-x03.cisco.com ([169.254.6.138]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.03.0123.003; Wed, 26 Feb 2014 13:10:47 -0600
From: "Lisa Huang (yihuan)" 
To: Juergen Schoenwaelder , "Alexander Clemm (alex)" 
Thread-Topic: draft-huang-netmod-acl (Stateless Packet Filter Configuration)
Thread-Index: Ac8p3MNd9/3j+HV/QOKxnW25dyL46AH1O15gAA39J4AASwJiAA==
Date: Wed, 26 Feb 2014 19:10:47 +0000
Message-ID: 
In-Reply-To: <20140224232259.GB1879@elstar.local>
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.96.170]
Content-Type: multipart/alternative; boundary="_000_CF33681E1094EByihuanciscocom_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/IVOK_5TTIBpND_YOiMXZykrpPbw
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] draft-huang-netmod-acl (Stateless Packet Filter Configuration)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 26 Feb 2014 19:11:55 -0000

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

Juergen,

Thank you for your feed back. Responded in line. Sorry, it took me a little=
 while to reply to your comments. Thanks,

Lisa

On 2/24/14 3:22 PM, "Juergen Schoenwaelder" > wrote:


>From a quick look at the document, it seems there are leafs without
description clauses etc. which is quite uncommon for IETF data
models.
I will add descriptions to all leaves. Leaves without description are=
 self-explained from the name. I will add them since this is required. Than=
ks for pointing it out.

I am also not sure whether you cover IPv4 and IPv6 on equal
footing.
 I studied both IPv4 and IPv6 and tried to model as much as I can. Pe=
er review is definite important to help to complete it. ACL clearly is a co=
mplex module. We have covered a lot of leaves, but we are sure we have not =
cover all. The structure of this module allows easy augmenting if more need=
 to be added. I appreciate anyone who comments when an important parts is m=
issing or anything is wrong.

(For example, masks are a rather unknown concept in IPv6,
IGMP really is an IPv4 mechanism
- so why is it under case ipv6-pfe,
 I will research more and make corresponding change. Thank you for po=
inting it out.

why do you cover ARP but not the ND IPv6 equivalent.)
 Could you elaborate what is "ND IPv6"? ARP is one of the ACL that wi=
dely used in network systems. The IP, Mac, ARP Stateless Packet Filt(SPF, A=
CL) modules are modules that are just starting points of SPF. Have them in =
the draft is to show how instance SPF module can augments the top SPF modul=
e. We did not meant to cover all SPF related module but try to give the mos=
t popular used instance SPF yang module enough contents. I am open to ideas=
 if there is a necessary to separate instance modules from the top SPF modu=
le to different I-D so it will be clearer that we did not intent to cover a=
ll ACLs.

It is unclear
why port filters are limited to TCP, UDP and SCTP - there is as well
DCCP and this may need to be future proofed.
That is a good point. The system I looked at so far does not has port=
 filter implemented for DCCP. I was trying to balance how much new requirem=
ent to add to current system if I have port as filter for DCCP vs what make=
 sense. We had discussions with implementation teams from different company=
. Most system plan to use YANG as model and develop tools to auto generate =
code for implementation. They expect the model defination as specific as po=
ssible. If you know systems that have port filter for DCCP, please let me k=
now.

As you mentioned, this may need to be future proofed. I have thought to use=
 "feature" on port, but feature does not serve the purpose. Another solutio=
n is to ask implementation to write Conformance Specification from Andy's d=
raft. My first concern is conformance I-D is still a draft. My other concer=
n is, a lot of times, capability becomes implementation trash can to dump a=
ny feature that has not implemented.  Let me know if you have other suggest=
ions. I copied the port below if anyone has any comments.

 choice src-ports {
           when "protocol =3D '6' or protocol =3D '17' or " +
                "protocol =3D '132'";

            description
              "Apply only when the protocol is TCP,
              UDP or SCTP.";

            case port-number-range {
                description
                    "Port group includes all ports between port-lower
                    and port-upper (including those)";
                leaf src-port-lower {
                    type inet:port-number;
                    description "Lower Port number.";
                    mandatory true;
                }
                leaf src-port-upper {
                    type inet:port-number;
                    description "Upper Port number.";
                    mandatory true;
                    must "../src-port-lower <=3D ../src-port-upper";
                }
            }
            case port-number {
                description
                    "Port group includes all ports that are greater
                    than, greater or equal, less than, less or equal,
                    or not equal the port, per the indicated
                    comparator.  It is possible for the port group
                    to be empty (for example, in case a port group
                    that is less than the minimum port number is
                    specified).";
                leaf src-comparator {
                    type spf:spf-comparator;
                    mandatory true;
                }
                leaf src-port {
                    type inet:port-number;
                    description "Port number.";
                    mandatory true;
                }
            }
            case port-group-ref {
                if-feature spf:port-groups;
                leaf src-port-group-name {
                    type spf:port-group-ref;
                    mandatory true;
                    description
                        "Reference a port group by the Port
                        Group name.";
                }
            }
        }  // choice src-ports



Type definitions should
have a canonical representation.
Could you elaborate this?

There are also more general issues
like module naming conventions etc. that are not followd yet.
 Could you be specific? We did spend some energy to follow naming con=
vention, but we may miss some. Appreciate more detail comments.

There is
an empty security considerations section, no IANA considerations
section, a reference section that is amazingly short (given the number
of [normative] references embodied in the YANG modules).
I am still new to I-D writing. Could you give more guidance about wha=
t IANA should cover? I do have a lot of reference in modules. Should I list=
 all of them in IANA section? Appreciate if you could pointing me to I-A wr=
iting guild line so I could cross check all sections. I will also ask two o=
ther co-author, Andy and Alex, as they definitely have more experience than=
 me.

And finally,
there are some TODOs in the text that I assume the authors are aware
of.
 That is my editing mistake. I will remove them.

All this is fine for an individual submission. But a WG product needs
to have many more of these things worked out.

One more thing before I go to sleep: The leaf tcp-flag-operation
specifies behaviour in the description clause that goes beyond YANG
rules - you can't simply stick more information into an enum by
appending magic strings to the enum name.
Good point. I think YANG language does not have a way to module an op=
eration related leaf(let me know if I am wrong). In this module, the purpos=
e of having a leaf with tcp-flag-operation is to allow the system configure=
 this leaf. It is similar to a leaf of permit-deny action in ACL. The syste=
m which implements the modules has to interoperate the configuration and ac=
t based the configuration on the system. What would you suggest for if this=
 is not the right way? I copied the leave below if anyone is interested to =
give more comments.

leaf tcp-flag-operation {
            when "boolean(../tcp-flag-value)" ;
            description
                "TCP flag Match option.
                A match occurs if the TCP
                datagram has certain TCP flags
                set or not set. You use the
                match-any keyword to allow a match
                to occur if any of the specified
                TCP flags are present, or you can
                use the match-all keyword to allow
                a match to occur only if all of
                the specified TCP flags are
                present. You must follow the
                match-any and match-all keywords
                with the + or - keyword and the
                flag-name argument to match on
                one or more TCP flags. ";
            default match-any;
            type enumeration {
                enum match-any {
                    description "match any";
                }
                enum match-all {
                    description "match all";
                }
            }
        }







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







Juergen,







Thank you for your feed back. Responded in line. Sorry, it took me a l=
ittle while to reply to your comments. Thanks,







Lisa







On 2/24/14 3:22 PM, "Juergen Schoenwaelder" <j.schoenwaelder@jacobs-universi=
ty.de> wrote:














From a quick look at the document, it seems there are leafs without

description clauses etc. which is quite uncommon for IETF data


models. 




<Lisa>I will add descriptions to all leaves. Leaves without desc=
ription are self-explained from the name. I will add them since this is req=
uired. Thanks for pointing it out.









I am also not sure whether you cover IPv4 and IPv6 on equal


footing. 






<Lisa> I studied both IPv4 and IPv6 and tried to model as much a=
s I can. Peer review is definite important to help to complete it. ACL clea=
rly is a complex module. We have covered a lot of leaves, but we are sure w=
e have not cover all. The structure of
 this module allows easy augmenting if more need to be added. I apprec=
iate anyone who comments when an important parts is missing or anything is =
wrong. 











(For example, masks are a rather unknown concept in IPv6,


IGMP really is an IPv4 mechanism






- so why is it under case ipv6-pfe,




<Lisa> I will research more and make corresponding change. Thank=
 you for pointing it out.









why do you cover ARP but not the ND IPv6 equivalent.)




<Lisa> Could you elaborate what is "ND IPv6"? ARP is o=
ne of the ACL that widely used in network systems. The IP, Mac, ARP Statele=
ss Packet Filt(SPF, ACL) modules are modules that are just starting points =
of SPF. Have them in the draft is to show how instance
 SPF module can augments the top SPF module. We did not meant to cover all =
SPF related module but try to give the most popular used instance SPF yang =
module enough contents. I am open to ideas if there is a necessary to separ=
ate instance modules from the top
 SPF module to different I-D so it will be clearer that we did not intent t=
o cover all ACLs.









It is unclear


why port filters are limited to TCP, UDP and SCTP - there is as well

DCCP and this may need to be future proofed. 




<Lisa>That is a good point. The system I looked at so far does n=
ot has port filter implemented for DCCP. I was trying to balance how much n=
ew requirement to add to current system if I have port as filter for DCCP v=
s what make sense. We had discussions
 with implementation teams from different company. Most system plan to use =
YANG as model and develop tools to auto generate code for implementation. T=
hey expect the model defination as specific as possible. If you know s=
ystems that have port filter for DCCP,
 please let me know.







As you mentioned, this may need to be future proofed. I have thought t=
o use "feature" on port, but feature does not serve the purpose. =
Another solution is to ask implementation to write Conformance Specificatio=
n from Andy's draft. My first concern is conformance
 I-D is still a draft. My other concern is, a lot of times, capability beco=
mes implementation trash can to dump any feature that has not implemented. =
 Let me know if you have other suggestions. I copied the port below if=
 anyone has any comments.







 choice src-ports {


           when "protocol =3D '6' o=
r protocol =3D '17' or " +


                "protocol=
 =3D '132'";







            description 


              "Apply only when=
 the protocol is TCP, 


              UDP or SCTP.";






            case port-number-range {&nbs=
p;


                description

                    =
"Port group includes all ports between port-lower 


                    =
and port-upper (including those)";


                leaf src-port-=
lower {


                    =
type inet:port-number;


                    =
description "Lower Port number.";


                    =
mandatory true; 


                }


                leaf src-port-=
upper {


                    =
type inet:port-number;


                    =
description "Upper Port number.";


                    =
mandatory true; 


                    =
must "../src-port-lower <=3D ../src-port-upper";


                }


            }


            case port-number {


                description&nb=
sp;


                    =
"Port group includes all ports that are greater 


                    =
than, greater or equal, less than, less or equal, 


                    =
or not equal the port, per the indicated 


                    =
comparator.  It is possible for the port group 


                    =
to be empty (for example, in case a port group 


                    =
that is less than the minimum port number is 


                    =
specified).";


                leaf src-compa=
rator {


                    =
type spf:spf-comparator;


                    =
mandatory true;                

                }


                leaf src-port =
{


                    =
type inet:port-number;


                    =
description "Port number.";


                    =
mandatory true; 


                }


            }


            case port-group-ref {


                if-feature spf=
:port-groups;


                leaf src-port-=
group-name {


                    =
type spf:port-group-ref;


                    =
mandatory true;


                    =
description 


                    =
    "Reference a port group by the Port 


                    =
    Group name.";


                }


            }


        }  // choice src-ports



















Type definitions should


have a canonical representation. 




<Lisa>Could you elaborate this?









There are also more general issues


like module naming conventions etc. that are not followd yet. 




<Lisa> Could you be specific? We did spend some energy to follow=
 naming convention, but we may miss some. Appreciate more detail comments.<=
/div>








There is


an empty security considerations section, no IANA considerations


section, a reference section that is amazingly short (given the number=



of [normative] references embodied in the YANG modules). 




<Lisa>I am still new to I-D writing. Could you give more guidanc=
e about what IANA should cover? I do have a lot of reference in modules. Sh=
ould I list all of them in IANA section? Appreciate if you could pointing m=
e to I-A writing guild line so I could
 cross check all sections. I will also ask two other co-author, Andy and Al=
ex, as they definitely have more experience than me.









And finally,


there are some TODOs in the text that I assume the authors are aware

of.




<Lisa> That is my editing mistake. I will remove them.









All this is fine for an individual submission. But a WG product needs<=
/div>

to have many more of these things worked out.











One more thing before I go to sleep: The leaf tcp-flag-operation


specifies behaviour in the description clause that goes beyond YANG

rules - you can't simply stick more information into an enum by


appending magic strings to the enum name.


<Lisa>Good point. I think YANG language does not have a way to m=
odule an operation related leaf(let me know if I am wrong). In this module,=
 the purpose of having a leaf with tcp-flag-operation is to allow the syste=
m configure this leaf. It is similar to
 a leaf of permit-deny action in ACL. The system which implements the modul=
es has to interoperate the configuration and act based the configuration on=
 the system. What would you suggest for if this is not the right way? I cop=
ied the leave below if anyone is
 interested to give more comments.











leaf tcp-flag-operation {  


            when "boolean(../tcp-fl=
ag-value)" ;


            description 


                "TCP flag=
 Match option.


                A match occurs=
 if the TCP 


                datagram has c=
ertain TCP flags 


                set or not set=
. You use the 


                match-any keyw=
ord to allow a match 


                to occur if an=
y of the specified 


                TCP flags are =
present, or you can 


                use the match-=
all keyword to allow 


                a match to occ=
ur only if all of 


                the specified =
TCP flags are 


                present. You m=
ust follow the 


                match-any and =
match-all keywords 


                with the +=
 or - keyword and the 


                flag-name argu=
ment to match on 


                one or more TC=
P flags. "; 


            default match-any;


            type enumeration {


                enum match-any=
 {


                    =
description "match any";


                }


                enum match-all=
 {


                    =
description "match all";


                }


            }


        }












































--_000_CF33681E1094EByihuanciscocom_--


From nobody Wed Feb 26 14:13:54 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F1171A07F8 for ; Wed, 26 Feb 2014 14:13:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level: 
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.547] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MoAQIYVsp8U1 for ; Wed, 26 Feb 2014 14:13:47 -0800 (PST)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) by ietfa.amsl.com (Postfix) with ESMTP id 78D9E1A0800 for ; Wed, 26 Feb 2014 14:13:34 -0800 (PST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id A2C4D1553; Wed, 26 Feb 2014 23:13:32 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id gghhVZ6EyBkW; Wed, 26 Feb 2014 23:13:30 +0100 (CET)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by atlas3.jacobs-university.de (Postfix) with ESMTP; Wed, 26 Feb 2014 23:13:30 +0100 (CET)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7980920054; Wed, 26 Feb 2014 23:13:30 +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 1D6DGLZrDUyR; Wed, 26 Feb 2014 23:13:29 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C8E7C20048; Wed, 26 Feb 2014 23:13:28 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id BB14A2B7DBB4; Wed, 26 Feb 2014 23:13:26 +0100 (CET)
Date: Wed, 26 Feb 2014 23:13:25 +0100
From: Juergen Schoenwaelder 
To: "Lisa Huang (yihuan)" 
Message-ID: <20140226221325.GA7838@elstar.local>
Mail-Followup-To: "Lisa Huang (yihuan)" , "netmod@ietf.org" 
References: <20140224232259.GB1879@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)
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/V7etrgJTpnGa2WAfIVuQnmKXVA8
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] draft-huang-netmod-acl (Stateless Packet Filter Configuration)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 26 Feb 2014 22:13:52 -0000

On Wed, Feb 26, 2014 at 07:10:47PM +0000, Lisa Huang (yihuan) wrote:

> why do you cover ARP but not the ND IPv6 equivalent.)
>  Could you elaborate what is "ND IPv6"? 

The equivalent of ARP for IPv6 is Neighbor Discovery (ND).

> It is unclear
> why port filters are limited to TCP, UDP and SCTP - there is as well
> DCCP and this may need to be future proofed.
> That is a good point. The system I looked at so far does not has port filter implemented for DCCP. I was trying to balance how much new requirement to add to current system if I have port as filter for DCCP vs what make sense. We had discussions with implementation teams from different company. Most system plan to use YANG as model and develop tools to auto generate code for implementation. They expect the model defination as specific as possible. If you know systems that have port filter for DCCP, please let me know.

Linux iptables for example.

> As you mentioned, this may need to be future proofed. I have thought to use "feature" on port, but feature does not serve the purpose. Another solution is to ask implementation to write Conformance Specification from Andy's draft. My first concern is conformance I-D is still a draft. My other concern is, a lot of times, capability becomes implementation trash can to dump any feature that has not implemented.  Let me know if you have other suggestions. 

I can't follow you....

I copied the port below if anyone has any comments.
> 
>  choice src-ports {
>            when "protocol = '6' or protocol = '17' or " +
>                 "protocol = '132'";

What I meant is that hard wiring protocol numbers in a when expression
(like above) causes problems once the next protocol comes along. (I am
also not sure relying on protocol numbers is a good thing in terms of
readability of the resulting config but this is a different question.)
 
> Type definitions should
> have a canonical representation.
> Could you elaborate this?

It is often OK to accept multiple representations as input but we like
to have a single representation to be canonical so that it is easy to
compare and process config snippets. See section 9.1 or RFC 6020.

> There are also more general issues
> like module naming conventions etc. that are not followd yet.
>  Could you be specific? We did spend some energy to follow naming convention, but we may miss some. Appreciate more detail comments.

I suggest you study RFC 6087 and the documents this RFC refers to.

> There is
> an empty security considerations section, no IANA considerations
> section, a reference section that is amazingly short (given the number
> of [normative] references embodied in the YANG modules).
> I am still new to I-D writing. Could you give more guidance about what IANA should cover? I do have a lot of reference in modules. Should I list all of them in IANA section? Appreciate if you could pointing me to I-A writing guild line so I could cross check all sections. I will also ask two other co-author, Andy and Alex, as they definitely have more experience than me.

Again, I suggest reading RFC 6087 and the documents this RFC refers
to.

> One more thing before I go to sleep: The leaf tcp-flag-operation
> specifies behaviour in the description clause that goes beyond YANG
> rules - you can't simply stick more information into an enum by
> appending magic strings to the enum name.
> Good point. I think YANG language does not have a way to module an operation related leaf(let me know if I am wrong). In this module, the purpose of having a leaf with tcp-flag-operation is to allow the system configure this leaf. It is similar to a leaf of permit-deny action in ACL. The system which implements the modules has to interoperate the configuration and act based the configuration on the system. What would you suggest for if this is not the right way? I copied the leave below if anyone is interested to give more comments.
> 
> leaf tcp-flag-operation {
>             when "boolean(../tcp-flag-value)" ;
>             description
>                 "TCP flag Match option.
>                 A match occurs if the TCP
>                 datagram has certain TCP flags
>                 set or not set. You use the
>                 match-any keyword to allow a match
>                 to occur if any of the specified
>                 TCP flags are present, or you can
>                 use the match-all keyword to allow
>                 a match to occur only if all of
>                 the specified TCP flags are
>                 present. You must follow the
>                 match-any and match-all keywords
>                 with the + or - keyword and the
>                 flag-name argument to match on
>                 one or more TCP flags. ";
>             default match-any;
>             type enumeration {
>                 enum match-any {
>                     description "match any";
>                 }
>                 enum match-all {
>                     description "match all";
>                 }
>             }
>         }

I do not really understand what you are trying to achieve here but I
am optimistic that YANG will have a way to do what you need. I have
not really reviewed the document in detail - I only took a quick look
to find out how mature this document is. I believe it is a starting
point but it still has to go a long way to get solid.

/js

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


From nobody Wed Feb 26 15:29:16 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1E0A1A06E8 for ; Wed, 26 Feb 2014 15:29:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.048
X-Spam-Level: 
X-Spam-Status: No, score=-10.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id amoLr4aasgcd for ; Wed, 26 Feb 2014 15:29:04 -0800 (PST)
Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) by ietfa.amsl.com (Postfix) with ESMTP id AD4A61A0883 for ; Wed, 26 Feb 2014 15:29:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7681; q=dns/txt; s=iport; t=1393457342; x=1394666942; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=Ptx5lpt6DUCgiv6D2eJDKI4SGaS4Kx6ZRmAkv0xZe3M=; b=H+FoLPI68WKpVcEpCsLvqwYhphr5ODWy7/phGIXeOXXl1J34lRNhYdrg gazXiWTXCWTiQYIk0FDeDL4/6QK+AVMRSNky/SUMmiE6dRnj49ZKGuN1q LS0UKULdkhIXtTpzRhuiVxConVXdIv1ea7JlTRzQerz+Ge4AxxQaFw/LC 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhsFAON3DlOtJV2d/2dsb2JhbABXA4MGO1fAf4EWFnSCJwEBAQMBDiwrFA4EAQgOAggeKxclAQEEDgUbh1YIyWsXBI14LRsQBwIPhCYEmDaSKIMtgWhC
X-IronPort-AV: E=Sophos;i="4.97,550,1389744000"; d="scan'208";a="23483721"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-2.cisco.com with ESMTP; 26 Feb 2014 23:28:59 +0000
Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s1QNSxC5010565 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 26 Feb 2014 23:28:59 GMT
Received: from xmb-aln-x03.cisco.com ([169.254.6.138]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.03.0123.003; Wed, 26 Feb 2014 17:28:59 -0600
From: "Lisa Huang (yihuan)" 
To: Juergen Schoenwaelder 
Thread-Topic: draft-huang-netmod-acl (Stateless Packet Filter Configuration)
Thread-Index: Ac8p3MNd9/3j+HV/QOKxnW25dyL46AH1O15gAA39J4AASwJiAAAXJNqA//+O/oA=
Date: Wed, 26 Feb 2014 23:28:58 +0000
Message-ID: 
In-Reply-To: <20140226221325.GA7838@elstar.local>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.2.3.120616
x-originating-ip: [10.154.204.196]
Content-Type: text/plain; charset="us-ascii"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/6SQJHrBHbEXTsPBZ5d7BPUYvyFA
Cc: "Mihyar Baroudi \(mbaroudi\)" , "netmod@ietf.org" 
Subject: Re: [netmod] draft-huang-netmod-acl (Stateless Packet Filter Configuration)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 26 Feb 2014 23:29:10 -0000

On 2/26/14 2:13 PM, "Juergen Schoenwaelder"
 wrote:

>On Wed, Feb 26, 2014 at 07:10:47PM +0000, Lisa Huang (yihuan) wrote:
>
>> why do you cover ARP but not the ND IPv6 equivalent.)
>>  Could you elaborate what is "ND IPv6"?
>
>The equivalent of ARP for IPv6 is Neighbor Discovery (ND).
If you are talking about ICMPV6 Neighbor Discovery, it is covered in IP
module with two leaves: icmp-type, and icmp-code. If there is a need to
make ND as a standalone module, I, or anyone else, could add it later.

leaf icmp-type {
            type c-types:icmp-type;
            description
                "ICMP message type number.
                Apply only when the protocol is icmp";
        }
       =20
        leaf icmp-code {
            when "boolean(../icmp-type) ";
            type c-types:icmp-code;
            description
            "ICMP subtype for a given icmp type.";
        }



>
>> It is unclear
>> why port filters are limited to TCP, UDP and SCTP - there is as well
>> DCCP and this may need to be future proofed.
>> That is a good point. The system I looked at so far does not has
>>port filter implemented for DCCP. I was trying to balance how much new
>>requirement to add to current system if I have port as filter for DCCP
>>vs what make sense. We had discussions with implementation teams from
>>different company. Most system plan to use YANG as model and develop
>>tools to auto generate code for implementation. They expect the model
>>defination as specific as possible. If you know systems that have port
>>filter for DCCP, please let me know.
>
>Linux iptables for example.
I will take this into consideration.
>
>> As you mentioned, this may need to be future proofed. I have thought to
>>use "feature" on port, but feature does not serve the purpose. Another
>>solution is to ask implementation to write Conformance Specification
>>from Andy's draft. My first concern is conformance I-D is still a draft.
>>My other concern is, a lot of times, capability becomes implementation
>>trash can to dump any feature that has not implemented.  Let me know if
>>you have other suggestions.
>
>I can't follow you....
>
>I copied the port below if anyone has any comments.
>>=20
>>  choice src-ports {
>>            when "protocol =3D '6' or protocol =3D '17' or " +
>>                 "protocol =3D '132'";
>
>What I meant is that hard wiring protocol numbers in a when expression
>(like above) causes problems once the next protocol comes along. (I am
>also not sure relying on protocol numbers is a good thing in terms of
>readability of the resulting config but this is a different question.)
Agree the protocol number does not help the readability. More information
is in the description. I can match the number and protocol name in
description as well.

For TCP, UDP and SCTP protocol, port is a mandatory leaf as most likely
the system does not want to block packet for all TCP, UDP, SCTP for all
ports. For DCCP, port should be optional which is opposite. Is it a normal
case that a system want to permit DCCP on one port verse deny DCCP on
another port?=20


>=20
>> Type definitions should
>> have a canonical representation.
>> Could you elaborate this?
>
>It is often OK to accept multiple representations as input but we like
>to have a single representation to be canonical so that it is easy to
>compare and process config snippets. See section 9.1 or RFC 6020.
>
>> There are also more general issues
>> like module naming conventions etc. that are not followd yet.
>>  Could you be specific? We did spend some energy to follow naming
>>convention, but we may miss some. Appreciate more detail comments.
>
>I suggest you study RFC 6087 and the documents this RFC refers to.
I will look more into RFC 6087. Thanks for the pointer.
>
>> There is
>> an empty security considerations section, no IANA considerations
>> section, a reference section that is amazingly short (given the number
>> of [normative] references embodied in the YANG modules).
>> I am still new to I-D writing. Could you give more guidance about
>>what IANA should cover? I do have a lot of reference in modules. Should
>>I list all of them in IANA section? Appreciate if you could pointing me
>>to I-A writing guild line so I could cross check all sections. I will
>>also ask two other co-author, Andy and Alex, as they definitely have
>>more experience than me.
>
>Again, I suggest reading RFC 6087 and the documents this RFC refers
>to.
Will do. Thanks.
>
>> One more thing before I go to sleep: The leaf tcp-flag-operation
>> specifies behaviour in the description clause that goes beyond YANG
>> rules - you can't simply stick more information into an enum by
>> appending magic strings to the enum name.
>> Good point. I think YANG language does not have a way to module
>>an operation related leaf(let me know if I am wrong). In this module,
>>the purpose of having a leaf with tcp-flag-operation is to allow the
>>system configure this leaf. It is similar to a leaf of permit-deny
>>action in ACL. The system which implements the modules has to
>>interoperate the configuration and act based the configuration on the
>>system. What would you suggest for if this is not the right way? I
>>copied the leave below if anyone is interested to give more comments.
>>=20
>> leaf tcp-flag-operation {
>>             when "boolean(../tcp-flag-value)" ;
>>             description
>>                 "TCP flag Match option.
>>                 A match occurs if the TCP
>>                 datagram has certain TCP flags
>>                 set or not set. You use the
>>                 match-any keyword to allow a match
>>                 to occur if any of the specified
>>                 TCP flags are present, or you can
>>                 use the match-all keyword to allow
>>                 a match to occur only if all of
>>                 the specified TCP flags are
>>                 present. You must follow the
>>                 match-any and match-all keywords
>>                 with the + or - keyword and the
>>                 flag-name argument to match on
>>                 one or more TCP flags. ";
>>             default match-any;
>>             type enumeration {
>>                 enum match-any {
>>                     description "match any";
>>                 }
>>                 enum match-all {
>>                     description "match all";
>>                 }
>>             }
>>         }
>
>I do not really understand what you are trying to achieve here
This is a use case for TCP flag-checking mechanism using ACL. For example,
the following instance will allow TCP packets only if the TCP flags ACL
and SYN are set and the FIN flag is not set.
<...>
   ack syn 
  ack syn fin
  match-all


The example is also in I-D.



>but I
>am optimistic that YANG will have a way to do what you need. I have
>not really reviewed the document in detail - I only took a quick look
>to find out how mature this document is. I believe it is a starting
>point but it still has to go a long way to get solid.
=20
Clearly, this is a good start.
>
>/js
>
>--=20
>Juergen Schoenwaelder           Jacobs University Bremen gGmbH
>Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
>Fax:   +49 421 200 3103         

Thanks,

Lisa
>


From nobody Fri Feb 28 08:41:03 2014
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7C221A00D1 for ; Fri, 28 Feb 2014 08:40:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.001
X-Spam-Level: 
X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cT_Fwb42qWxO for ; Fri, 28 Feb 2014 08:40:57 -0800 (PST)
Received: from mail19k.g19.rapidsite.net (mail19k.g19.rapidsite.net [204.202.242.122]) by ietfa.amsl.com (Postfix) with ESMTP id 836481A0165 for ; Fri, 28 Feb 2014 08:40:57 -0800 (PST)
Received: from mxmtaout07.va1.mxservers.net (208.55.215.114) by mail19k.g19.rapidsite.net (RS ver 1.0.95vs) with SMTP id 4-039585654 for ; Fri, 28 Feb 2014 11:40:55 -0500 (EST)
Received: from unknown [161.58.75.15] (EHLO mmm1913.dulles19-verio.com) by mxmtaout07.va1.mxservers.net(mxl_mta-6.15.0-3) with ESMTP id 61cb0135.0.1676900.00-497.3033395.mxmtaout07.va1.mxservers.net (envelope-from );  Fri, 28 Feb 2014 11:40:55 -0500 (EST)
X-MXL-Hash: 5310bc173878feab-12389d77f07fa4b23d5cba77c706ca30391f81c7
Received: (qmail 41928 invoked from network); 28 Feb 2014 16:40:54 -0000
Received: from unknown (HELO ?192.168.0.21?) (blukovic@135.23.154.141) by  with ESMTPA; 28 Feb 2014 16:40:54 -0000
Message-ID: <5310BC18.1000004@ndt-inc.com>
Date: Fri, 28 Feb 2014 11:40:56 -0500
From: B Lukovic 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: netmod@ietf.org
References: 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------080501020604060506000107"
X-Spam: [F=0.2000000000; CM=0.500; MH=0.500(2014022813); S=0.200(2010122901)]
X-MAIL-FROM: 
X-SOURCE-IP: [161.58.75.15]
X-AnalysisOut: [v=2.0 cv=Wa+7nTdX c=1 sm=1 a=IcBn81/O6j4k4bHiM4CBQw==:17 a]
X-AnalysisOut: [=jl2ymW9NZSsA:10 a=a9g_6vPqjQcA:10 a=63bDUHjCYPkA:10 a=BLc]
X-AnalysisOut: [eEmwcHowA:10 a=A1sffi52AAAA:8 a=UebAHIHlYiUA:10 a=48vgC7mU]
X-AnalysisOut: [AAAA:8 a=p2TZLaQbWF_AeWHMrXwA:9 a=wPNLvfGTeEIA:10 a=rKrVYe]
X-AnalysisOut: [Pj7rwA:10 a=lZB815dzVvQA:10 a=T0ZuanxOAAAA:8 a=w0CoLKxn1M0]
X-AnalysisOut: [7q0rSikEA:9 a=_W_S_7VecoQA:10 a=MI0vDV_QZjYA:10 a=9TbY8iwb]
X-AnalysisOut: [aUqx57dg:21]
X-SF-Loop: 1
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/J8xXv1dx0djsm8Rcq5y5v-vO9d0
Subject: Re: [netmod] implementations of draft-ietf-netmod-snmp-cfg
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 28 Feb 2014 16:41:00 -0000

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

NuDesign Technologies is implementing netmod-snmp-cgf.
We will update implementation to match the latest version of draft.

     Borislav


On 2/25/2014 10:46 AM, Thomas Nadeau wrote:
> 	I would like to poll for any implementations of draft-ietf-netmod-snmp-cfg.
> Please either post to the list, or contact me privately if you would like to
> keep the information confidential.
>
> 	--Tom (NETMOD co-chair)
>
>
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


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


  
    
  
  
    NuDesign Technologies is implementing netmod-snmp-cgf.
    

    We will update implementation to match the latest version of draft.
    

    

        Borislav

    

    

    
On 2/25/2014 10:46 AM, Thomas Nadeau
      wrote:

    

    

      
	I would like to poll for any implementations of draft-ietf-netmod-snmp-cfg. 
Please either post to the list, or contact me privately if you would like to
keep the information confidential. 

	--Tom (NETMOD co-chair)




      

      

      

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


    

    

  


--------------080501020604060506000107--