From equinox@spaceboyz.net Sun Nov 3 10:43:12 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8962211E82D7 for ; Sun, 3 Nov 2013 10:43:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ECGkeyodNMTV for ; Sun, 3 Nov 2013 10:43:11 -0800 (PST) Received: from spaceboyz.net (spaceboyz.net [IPv6:2001:8d8:870:1000::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E8F711E82DF for ; Sun, 3 Nov 2013 10:43:07 -0800 (PST) Received: from equinox by spaceboyz.net with local (Exim 4.80.1) (envelope-from ) id 1Vd2db-0004Bl-QK; Sun, 03 Nov 2013 19:43:03 +0100 Date: Sun, 3 Nov 2013 19:43:03 +0100 From: David Lamparter To: netmod@ietf.org Message-ID: <20131103184303.GF21375@spaceboyz.net> 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) Sender: Subject: Re: [netmod] changes in the routing model X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Nov 2013 19:04:10 -0000 On Thu, Oct 24, 2013 at 02:38:12PM +0200, Ladislav Lhotka wrote: > o Feature "user-defined-routing-tables" changed into "advanced- > router". > > I didn't want to introduce more features, I think the distinction between a basic and advanced router should be sufficient. I disagree that this distinction is sufficient - or it might be in the wrong place. There is a very large class of devices that support ECMP, but not multiple RIBs. Members of this class are most medium-level "L3 switches", and a good number of software forwarders (e.g. firewalls.) Features aren't high-cost, are they? If you want to not make this a feature, having simple devices constrain it to a single entry list might be an option too. -David [will raise this on the mic for discussion if needed] PS: I've read the entirety of it & the draft otherwise looks good to me. Content review only, didn't look at language or formal correctness. > o Made nexthop into a choice in order to allow for nexthop-list > (I2RS requirement). > > o Added nexthop-list with entries having priorities (backup) and > weights (load balancing). > > The last two changes implement multipath routes that are crucial for I2RS. Both are bound to the feature "advanced-router", so simple devices needn't bother with it. From lhotka@nic.cz Sun Nov 3 14:50:57 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30D5A21F9C55 for ; Sun, 3 Nov 2013 14:50:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MmIZKqvjTUT1 for ; Sun, 3 Nov 2013 14:50:56 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 5F79711E823C for ; Sun, 3 Nov 2013 14:50:56 -0800 (PST) Received: from [172.16.35.77] (unknown [64.114.24.114]) by mail.nic.cz (Postfix) with ESMTPSA id 1D2AB13F64C; Sun, 3 Nov 2013 23:50:53 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1383519055; bh=bGynHKY6LNbhJDqWL4rynGqWafQlgHVz2ogFR1N3fus=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=M5nG2VcrrAf5TIWlRDMqiN1EgfJVew5m3xvF2epS6+XIBRfkkL425qO64PT9KEpzW NiJqqngtNI0Y12amMwcgk47GnOHI2wAtW/jIAWHWPeqLCq8k1oYpn0KFhPWNG6vzuU J25jRiiCorg6sU/zBm9OGkXG61xdX2ERut5Y39Zk= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) From: Ladislav Lhotka In-Reply-To: <20131103184303.GF21375@spaceboyz.net> Date: Sun, 3 Nov 2013 14:50:50 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <837A5B6C-05CD-4C02-B519-B5D21BB6C7E0@nic.cz> References: <20131103184303.GF21375@spaceboyz.net> To: David Lamparter X-Mailer: Apple Mail (2.1816) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] changes in the routing model X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Nov 2013 22:50:57 -0000 On 03 Nov 2013, at 10:43, David Lamparter wrote: > On Thu, Oct 24, 2013 at 02:38:12PM +0200, Ladislav Lhotka wrote: >> o Feature "user-defined-routing-tables" changed into "advanced- >> router". >>=20 >> I didn't want to introduce more features, I think the distinction = between a basic and advanced router should be sufficient. >=20 > I disagree that this distinction is sufficient - or it might be in the > wrong place. There is a very large class of devices that support = ECMP, > but not multiple RIBs. Members of this class are most medium-level = "L3 > switches", and a good number of software forwarders (e.g. firewalls.) OK, if it is so, we can make it into distinct features. >=20 > Features aren't high-cost, are they? No, not really. >=20 > If you want to not make this a feature, having simple devices = constrain > it to a single entry list might be an option too. >=20 >=20 > -David >=20 > [will raise this on the mic for discussion if needed] I will add it as an open issue to my presentation. >=20 > PS: I've read the entirety of it & the draft otherwise looks good to = me. > Content review only, didn't look at language or formal correctness. Thanks! Cheers, Lada >=20 >> o Made nexthop into a choice in order to allow for nexthop-list >> (I2RS requirement). >>=20 >> o Added nexthop-list with entries having priorities (backup) and >> weights (load balancing). >>=20 >> The last two changes implement multipath routes that are crucial for = I2RS. Both are bound to the feature "advanced-router", so simple devices = needn't bother with it. > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From david.kessens@gmail.com Sun Nov 3 18:20:33 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC83C11E8260 for ; Sun, 3 Nov 2013 18:20:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RKUl6bsa278a for ; Sun, 3 Nov 2013 18:20:33 -0800 (PST) Received: from mail-la0-x231.google.com (mail-la0-x231.google.com [IPv6:2a00:1450:4010:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 2460421E8088 for ; Sun, 3 Nov 2013 18:20:32 -0800 (PST) Received: by mail-la0-f49.google.com with SMTP id ev20so3147919lab.8 for ; Sun, 03 Nov 2013 18:20:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=Y9iSxQmoaWUP2jyRcVvZcifFKDPTjV6nvuOSmRhNvog=; b=ESsCpa9oTnTs8fa8uwH+F8pMMeEXnXPjZvFlAJwRp9sxDnZIVrpTpG3epXSy+SJpji k0XotO2gdGsgzMM0Kp70xvQ7VF1znGQv2xkOYRDVLb3JsOGvttirIwF8gisKCbDisTme k8HNT2wuMnfpd1ieJ55K+Myrbcz6StOprzjwZpr/lIzsVx2HJPD9wOsf71slyZORRu/N iHBQUIR/npCbHFtRbF66+3jpUERuVZDFVI5pgsxqF3Jd9i5RUTe6fp55CN6EYmEpoCdk IF4PLDdj9QpnKDF+VYnJVspfGiE9JiYqf3fE56cHErKac8ivfVswSSXAJUChkeWrPEj0 tGlw== MIME-Version: 1.0 X-Received: by 10.112.77.169 with SMTP id t9mr2894130lbw.3.1383531632113; Sun, 03 Nov 2013 18:20:32 -0800 (PST) Received: by 10.152.170.170 with HTTP; Sun, 3 Nov 2013 18:20:32 -0800 (PST) Date: Sun, 3 Nov 2013 18:20:32 -0800 Message-ID: From: David Kessens To: netmod@ietf.org Content-Type: multipart/alternative; boundary=001a11c3ecfa77bde004ea508f00 Subject: [netmod] Last chance for review: draft-ietf-netmod-ip-cfg & draft-ietf-netmod-ip-cfg X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 02:20:34 -0000 --001a11c3ecfa77bde004ea508f00 Content-Type: text/plain; charset=ISO-8859-1 Hi, As the document shepherd for: draft-ietf-netmod-interfaces-cfg-12 and draft-ietf-netmod-ip-cfg-11 I have requested our Area Director Benoit whether he can take up the document for final IESG review. I have done a final review and I have not found any changes that are more than minor/already has consensus since our last calls. Since Benoit will be busy during this week, you will have until the end of this week if there is anything that escaped our attention that you believe needs more discussion. Thanks, David Kessens --- --001a11c3ecfa77bde004ea508f00 Content-Type: text/html; charset=ISO-8859-1

Hi,

As the document shepherd for:

draft-ietf-netmod-interfaces-cfg-12
and
draft-ietf-netmod-ip-cfg-11

I have requested our Area Director Benoit whether he can take up the document for final IESG review.

I have done a final review and I have not found any changes that are more than minor/already has consensus since our last calls.

Since Benoit will be busy during this week, you will have until the end of this week if there is anything that escaped our attention that you believe needs more discussion.

Thanks,

David Kessens
---
--001a11c3ecfa77bde004ea508f00-- From lhotka@nic.cz Mon Nov 4 15:48:45 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BD1C11E8248 for ; Mon, 4 Nov 2013 15:48:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.095 X-Spam-Level: X-Spam-Status: No, score=-1.095 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_EQ_CZ=0.904, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vru7J1LcGdVb for ; Mon, 4 Nov 2013 15:48:39 -0800 (PST) Received: from trail.lhotka.name (nat-5.bravonet.cz [77.48.224.5]) by ietfa.amsl.com (Postfix) with ESMTP id C437411E8243 for ; Mon, 4 Nov 2013 15:48:36 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 33198540238 for ; Tue, 5 Nov 2013 00:48:34 +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 AYykYNaZ5KdJ for ; Tue, 5 Nov 2013 00:48:29 +0100 (CET) Received: from localhost (dhcp-a49d.meeting.ietf.org [31.133.164.157]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id DB75E540023 for ; Tue, 5 Nov 2013 00:48:24 +0100 (CET) From: Ladislav Lhotka To: netmod@ietf.org User-Agent: Notmuch/0.15.2 (http://notmuchmail.org) Emacs/23.4.1 (x86_64-apple-darwin12.3.0) Mail-Followup-To: netmod@ietf.org Date: Mon, 04 Nov 2013 15:48:21 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: [netmod] derived-from X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 23:48:45 -0000 Hi, considering possible uses of the proposed XPath function yangxp:derived-fro= m, I am leaning towards a conclusion that the irreflexibity property of ide= ntity derivation (stated explicitly in erratum #3470 to RFC 6020) is highly= problematic. An example using the routing module: assume somebody develops a new route f= iltering framework "foo" and defines a new identity =E2=80=9Cfoo=E2=80=9D f= or it (its base identity is =E2=80=9Croute-filter=E2=80=9D). The definition= of config data then should go like this: augment "/rt:routing/rt:route-filters/rt:route-filter" { when "..."; ... } Now, the question is what the XPath expression in "when" should be, in orde= r to make the new data nodes valid only for route filters of type "foo" or = any identity derived from foo: - If it is "rt:type =3D 'foo:foo'", then it won't work for route filters th= at are derived from "foo", and, moreover, we still have the problem with XP= ath string comparison. - If it is "derived-from(type,"foo","foo") then it won't work even for "foo= ", because of irreflexivity. IMO, identities would be much more useful if the derivation relation had th= ese properties: 1. partial ordering =3D reflexive, anti-symmetric and transitive; 2. multiple inheritance, i.e. an identity definition can specify one or mor= e bases. This seems like another item in YANG 2.0 wishlist. Lada --=20 Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From alex@cisco.com Tue Nov 5 09:45:34 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7424C21F99FD for ; Tue, 5 Nov 2013 09:45:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F-Vi9CQL-BNB for ; Tue, 5 Nov 2013 09:45:29 -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 09A9C11E81C5 for ; Tue, 5 Nov 2013 09:44:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20454; q=dns/txt; s=iport; t=1383673487; x=1384883087; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=bw9ZIrN9IEFxWl6aIlvBSvWCz+zjpGxj0gSi6umGOVo=; b=KwXLQYrE2qJv50k9fnCZJhrjfCK+7qoHI5PSw27ISXGvjA/RODK91eKw XXKHkHl8/siH+6TNnsu4aWNnHs9godYuH2k+hunxQQhVOuKY48eBDel+U npZlxnxBoEIm9vMsJU/uC5qwWz3rtXnVsY+4d4diNRc5DXSllt3yzmI0I Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AscGAD0teVKtJXG+/2dsb2JhbABZgkNEOFOtDYloiEOBLBZ0giUBAQEELUoSAgEIEQMBAQELFgcHMhQJCAIEARIIARKHZg2+bY8oIBcBBoMagQ8DmTmQWoFogT6CKg X-IronPort-AV: E=Sophos;i="4.93,640,1378857600"; d="scan'208,217";a="278003066" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-9.cisco.com with ESMTP; 05 Nov 2013 17:44:46 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id rA5HihRu030126 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 5 Nov 2013 17:44:43 GMT Received: from xmb-rcd-x05.cisco.com ([169.254.15.100]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0123.003; Tue, 5 Nov 2013 11:44:42 -0600 From: "Alexander Clemm (alex)" To: Andy Bierman , "netmod@ietf.org" Thread-Topic: [netmod] Fwd: New Version Notification for draft-bierman-netmod-yang-conformance-00.txt Thread-Index: AQHOs0NnhNMbE8GMkkKQPiYc95dczpoXLosg Date: Tue, 5 Nov 2013 17:44:42 +0000 Message-ID: References: <20130917010924.30052.13344.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.253.19] Content-Type: multipart/alternative; boundary="_000_DBC595ED2346914F9F81D17DD5C32B571860226Exmbrcdx05ciscoc_" MIME-Version: 1.0 Subject: Re: [netmod] Fwd: New Version Notification for draft-bierman-netmod-yang-conformance-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 17:45:34 -0000 --_000_DBC595ED2346914F9F81D17DD5C32B571860226Exmbrcdx05ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I think this draft addresses important issues. I do have a few comments/questions. Those have mainly to do with the mixin= g between packages and profiles, which, as currently stated, I find somewha= t confusing, in particular how a profile can have a "require-package" subst= atement, and how profiles in turn are defined inside packages. This blurs t= he lines between them and makes the distinction less clear. Adding to my = confusion is the fact that it is stated in one place that a package can con= tain zero or more profiles, yet section 3.4 states that only one profile pe= r package can be active at any one time. So, how do I know which is active= , why are they exclusive (this seems to unnecessarily complicate matters), = wasn't the package supposed to clarify which modules/features/capabilities = have actually been implemented? It would seem that: - A profile is basically a "unit of conformance" that needs to be = implemented together to meet the needs of some categories of use case. - The same server can implement and support multiple profiles conc= urrently, irrespective of which packages those profiles happen to have been= defined in. - A profile can probably "include" other profiles. A package would then basically be just a "module" containing profile defini= tions. What is the unit of conformance? Presumably, the profile, not the = package. If a profile can "include" other profiles, profiles should be abl= e to refer to those other profiles. This includes potentially modules in o= ther packages and is probably the reason for the require-package substateme= nt, but it is not clear from the spec (and, if only a single profile from t= hat package is needed, leads to requiring "too much"). Separate issue re: packages, I am not sure what purpose the "category" stat= ement serves. Is this merely another "label" attached to a package without= further meaning? How does it help with conformance statements? Thanks --- Alex From: netmod-bounces@ietf.org [mailto:netmod-bounces@ietf.org] On Behalf Of= Andy Bierman Sent: Monday, September 16, 2013 6:15 PM To: netmod@ietf.org Subject: [netmod] Fwd: New Version Notification for draft-bierman-netmod-ya= ng-conformance-00.txt Hi, I raised issues with YANG conformance mechanisms in the past but the issue was tabled until somebody proposed a solution. I would like to un-table the issue and have the NETMOD WG address the YANG conformance issues raised in the draft. thanks, Andy ---------- Forwarded message ---------- From: > Date: Mon, Sep 16, 2013 at 6:09 PM Subject: New Version Notification for draft-bierman-netmod-yang-conformance= -00.txt To: Andy Bierman > A new version of I-D, draft-bierman-netmod-yang-conformance-00.txt has been successfully submitted by Andy Bierman and posted to the IETF repository. Filename: draft-bierman-netmod-yang-conformance Revision: 00 Title: YANG Conformance Specification Creation date: 2013-09-16 Group: Individual Submission Number of pages: 38 URL: http://www.ietf.org/internet-drafts/draft-bierman-netmod-y= ang-conformance-00.txt Status: http://datatracker.ietf.org/doc/draft-bierman-netmod-yang-= conformance Htmlized: http://tools.ietf.org/html/draft-bierman-netmod-yang-confo= rmance-00 Abstract: This document describes conformance specification and advertisement mechanisms for NETCONF servers implementing YANG data model modules. 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. The IETF Secretariat --_000_DBC595ED2346914F9F81D17DD5C32B571860226Exmbrcdx05ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 <= /p>

I think this draft addres= ses important issues.

 <= /p>

I do have a few comments/= questions.  Those have mainly to do with the mixing between packages a= nd profiles, which, as currently stated, I find somewhat confusing, in particular how a profile can have a “require-package” subst= atement, and how profiles in turn are defined inside packages. This blurs t= he lines between them and makes the distinction less clear.   Add= ing to my confusion is the fact that it is stated in one place that a package can contain zero or more profiles, yet section 3.4 st= ates that only one profile per package can be active at any one time.  = ;So, how do I know which is active, why are they exclusive (this seems to u= nnecessarily complicate matters), wasn’t the package supposed to clarify which modules/features/capabilities have a= ctually been implemented? 

 <= /p>

It would seem that:<= /o:p>

- =          A profile is basi= cally a “unit of conformance” that needs to be implemented toge= ther to meet the needs of some categories of use case. 

- =          The same server c= an implement and support multiple profiles concurrently, irrespective of wh= ich packages those profiles happen to have been defined in.

- =          A profile can pro= bably “include” other profiles. 

 

A package would then basi= cally be just a “module” containing profile definitions.  = What is the unit of conformance?  Presumably, the profile, not the pac= kage.  If a profile can “include” other profiles, profiles should be = able to refer to those other profiles.  This includes potentially modu= les in other packages and is probably the reason for the require-package su= bstatement, but it is not clear from the spec (and, if only a single profile from that package is needed, leads to requiring &= #8220;too much”).    

 <= /p>

Separate issue re: packag= es, I am not sure what purpose the “category” statement serves.=   Is this merely another “label” attached to a package wit= hout further meaning?  How does it help with conformance statements? 

 <= /p>

Thanks<= /p>

--- Alex

 <= /p>

From: netmod-b= ounces@ietf.org [mailto:netmod-bounces@ietf.org] On Behalf Of Andy Bierman
Sent: Monday, September 16, 2013 6:15 PM
To: netmod@ietf.org
Subject: [netmod] Fwd: New Version Notification for draft-bierman-ne= tmod-yang-conformance-00.txt

 

Hi,

 

I raised issues with YANG conformance mechanisms in = the past

but the issue was tabled until somebody proposed a s= olution.

I would like to un-table the issue and have the NETM= OD WG address the

YANG conformance issues raised in the draft.

 

 

thanks,

Andy

 

---------- Forwarded = message ----------
From: <internet-drafts@ietf.= org>
Date: Mon, Sep 16, 2013 at 6:09 PM
Subject: New Version Notification for draft-bierman-netmod-yang-conformance= -00.txt
To: Andy Bierman <andy@yumaworks.c= om>



A new version of I-D, draft-bierman-netmod-yang-conformance-00.txt
has been successfully submitted by Andy Bierman and posted to the
IETF repository.

Filename:        draft-bierman-netmod-yang-conformance<= br> Revision:        00
Title:           YANG Conformance Specification Creation date:   2013-09-16
Group:           Individual Submission
Number of pages: 38
URL:             http://www.ietf.org/internet-drafts/draft-bierman-netmod-yang-conformance-0= 0.txt
Status:          http://d= atatracker.ietf.org/doc/draft-bierman-netmod-yang-conformance
Htmlized:        http://tools.ie= tf.org/html/draft-bierman-netmod-yang-conformance-00


Abstract:
   This document describes conformance specification and advertis= ement
   mechanisms for NETCONF servers implementing YANG data model mo= dules.




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.

The IETF Secretariat

 

--_000_DBC595ED2346914F9F81D17DD5C32B571860226Exmbrcdx05ciscoc_-- From andy@yumaworks.com Tue Nov 5 10:01:07 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C150221F9A43 for ; Tue, 5 Nov 2013 10:01:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.829 X-Spam-Level: X-Spam-Status: No, score=-2.829 tagged_above=-999 required=5 tests=[AWL=0.147, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uPXsBExLXrXo for ; Tue, 5 Nov 2013 10:00:59 -0800 (PST) Received: from mail-qe0-f53.google.com (mail-qe0-f53.google.com [209.85.128.53]) by ietfa.amsl.com (Postfix) with ESMTP id 0762C21F99BD for ; Tue, 5 Nov 2013 10:00:01 -0800 (PST) Received: by mail-qe0-f53.google.com with SMTP id cy11so5158435qeb.40 for ; Tue, 05 Nov 2013 09:59:46 -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=GBVRrqU0oN1mQMfcHmkMt9+My8QQ2oYiQJkP+17KH8g=; b=TFINHz8WM0raZpJzE86a9fetuhwexlyt/on/LdThvv/4p4K6uShLULV7Bg8qZuTt1U 8ky0e0kmgtIuYBhWsFlYj74fZgJjA5V5nDfzRYOdPYwSyR97IyzoEmuV2NJeNdD8Imz7 nHgiQzuIVJxVrFTlMFzaFcOzb9eHveBOU/h5eGiNX4TZkb2ead7ahozZQFhW8XDueZCA 2KS8oFPf/A2WmpmoLdzKmoLkTKUBeB/OF/9HL6/n8i9d1MxjxKw1SrwUc9XQ8zs92V3P DzCKHg03xhvFl+3d/X3jSur/3WyXFUAlASbKPx80c+Acm72jtdyTuFTNLyKRcc0+ljC/ yXlg== X-Gm-Message-State: ALoCoQkEg7Aw+UzEkIEeJ/rwtqJ+Tog/r4Tpbqnoz7LlyFl3E7t/1Q+ZbkaU0a20DsdJ1EorvgO0 MIME-Version: 1.0 X-Received: by 10.49.71.131 with SMTP id v3mr11879518qeu.85.1383674386495; Tue, 05 Nov 2013 09:59:46 -0800 (PST) Received: by 10.140.100.203 with HTTP; Tue, 5 Nov 2013 09:59:46 -0800 (PST) In-Reply-To: References: <20130917010924.30052.13344.idtracker@ietfa.amsl.com> Date: Tue, 5 Nov 2013 09:59:46 -0800 Message-ID: From: Andy Bierman To: "Alexander Clemm (alex)" Content-Type: multipart/alternative; boundary=047d7b5d59724ad15204ea71cca8 Cc: "netmod@ietf.org" Subject: Re: [netmod] Fwd: New Version Notification for draft-bierman-netmod-yang-conformance-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 18:01:07 -0000 --047d7b5d59724ad15204ea71cca8 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Tue, Nov 5, 2013 at 9:44 AM, Alexander Clemm (alex) wrot= e: > Hi, > > > > I think this draft addresses important issues. > > > > I do have a few comments/questions. Those have mainly to do with the > mixing between packages and profiles, which, as currently stated, I find > somewhat confusing, in particular how a profile can have a > =93require-package=94 substatement, and how profiles in turn are defined = inside > packages. This blurs the lines between them and makes the distinction les= s > clear. Adding to my confusion is the fact that it is stated in one plac= e > that a package can contain zero or more profiles, yet section 3.4 states > that only one profile per package can be active at any one time. So, how > do I know which is active, why are they exclusive (this seems to > unnecessarily complicate matters), wasn=92t the package supposed to clari= fy > which modules/features/capabilities have actually been implemented? > > > The profile name is included in the :package capability defined in sec. 6. It would seem that: > > - A profile is basically a =93unit of conformance=94 that needs = to > be implemented together to meet the needs of some categories of use case. > yes -- conformance to a use-case may not align perfectly with 1 YANG module= . A package could cover 1 module, N modules, or even just 1 object. - The same server can implement and support multiple profiles > concurrently, irrespective of which packages those profiles happen to hav= e > been defined in. > this is an open issue. I started simple saying just 1 profile is active. Multiple profiles or switching between them is a possibility. - A profile can probably =93include=94 other profiles. > > > yes -- see include-profile statement in sec. 4.5 A package would then basically be just a =93module=94 containing profile > definitions. What is the unit of conformance? Presumably, the profile, > not the package. If a profile can =93include=94 other profiles, profiles > should be able to refer to those other profiles. This includes potential= ly > modules in other packages and is probably the reason for the > require-package substatement, but it is not clear from the spec (and, if > only a single profile from that package is needed, leads to requiring =93= too > much=94). > > > > Separate issue re: packages, I am not sure what purpose the =93category= =94 > statement serves. Is this merely another =93label=94 attached to a packa= ge > without further meaning? How does it help with conformance statements? > > > this is administrative classification. It could be useful but requires some effort to create a classification system. Searching all the YANG modules for keywords seems crude. One of the hardest parts of writing a new module is integrating it well with existing modules. Assuming everything under the same XML subtree is everything available related to some feature is not reliable. Thanks > > --- Alex > Andy > > > *From:* netmod-bounces@ietf.org [mailto:netmod-bounces@ietf.org] *On > Behalf Of *Andy Bierman > *Sent:* Monday, September 16, 2013 6:15 PM > *To:* netmod@ietf.org > *Subject:* [netmod] Fwd: New Version Notification for > draft-bierman-netmod-yang-conformance-00.txt > > > > Hi, > > > > I raised issues with YANG conformance mechanisms in the past > > but the issue was tabled until somebody proposed a solution. > > I would like to un-table the issue and have the NETMOD WG address the > > YANG conformance issues raised in the draft. > > > > > > thanks, > > Andy > > > > ---------- Forwarded message ---------- > From: > Date: Mon, Sep 16, 2013 at 6:09 PM > Subject: New Version Notification for > draft-bierman-netmod-yang-conformance-00.txt > To: Andy Bierman > > > > A new version of I-D, draft-bierman-netmod-yang-conformance-00.txt > has been successfully submitted by Andy Bierman and posted to the > IETF repository. > > Filename: draft-bierman-netmod-yang-conformance > Revision: 00 > Title: YANG Conformance Specification > Creation date: 2013-09-16 > Group: Individual Submission > Number of pages: 38 > URL: > http://www.ietf.org/internet-drafts/draft-bierman-netmod-yang-conformance= -00.txt > Status: > http://datatracker.ietf.org/doc/draft-bierman-netmod-yang-conformance > Htmlized: > http://tools.ietf.org/html/draft-bierman-netmod-yang-conformance-00 > > > Abstract: > This document describes conformance specification and advertisement > mechanisms for NETCONF servers implementing YANG data model modules. > > > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > > --047d7b5d59724ad15204ea71cca8 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable



On Tue, Nov 5, 2013 at 9:44 AM, Alexander Clemm (alex) <alex@cisco.co= m> wrote:

Hi,<= /p>

=A0<= /p>

I think this draft addres= ses important issues.

=A0<= /p>

I do have a few comments/= questions.=A0 Those have mainly to do with the mixing between packages and = profiles, which, as currently stated, I find somewhat confusing, in particular how a profile can have a =93require-package=94 substatement,= and how profiles in turn are defined inside packages. This blurs the lines= between them and makes the distinction less clear.=A0 =A0Adding to my conf= usion is the fact that it is stated in one place that a package can contain zero or more profiles, yet section 3.4 st= ates that only one profile per package can be active at any one time. =A0So= , how do I know which is active, why are they exclusive (this seems to unne= cessarily complicate matters), wasn=92t the package supposed to clarify which modules/features/capabilities have a= ctually been implemented?=A0

=A0


The profile name is included in th= e :package capability defined in sec. 6.

It would seem that:

-=A0=A0=A0=A0=A0=A0=A0=A0=A0 A profile is basical= ly a =93unit of conformance=94 that needs to be implemented together to mee= t the needs of some categories of use case.=A0


yes -- conformance to a use-ca= se may not align perfectly with 1 YANG module.
A package could co= ver 1 module, N modules, or even just 1 object.


-=A0=A0=A0=A0=A0=A0=A0=A0=A0 The same server can = implement and support multiple profiles concurrently, irrespective of which= packages those profiles happen to have been defined in.


this is an open= issue. =A0I started simple saying just 1 profile is active.
Mult= iple profiles or switching between them is a possibility.

-=A0=A0=A0=A0=A0=A0=A0=A0=A0 A profile can probab= ly =93include=94 other profiles.=A0

=A0



yes -- see include-profile statement in =A0sec. 4.5

A package would then basi= cally be just a =93module=94 containing profile definitions.=A0 What is the= unit of conformance?=A0 Presumably, the profile, not the package.=A0 If a profile can =93include=94 other profiles, profiles should be able to = refer to those other profiles.=A0 This includes potentially modules in othe= r packages and is probably the reason for the require-package substatement,= but it is not clear from the spec (and, if only a single profile from that package is needed, leads to requiring = =93too much=94).=A0 =A0=A0

=A0<= /p>

Separate issue re: packag= es, I am not sure what purpose the =93category=94 statement serves.=A0 Is t= his merely another =93label=94 attached to a package without further meaning?=A0 How does it help with conformance statements?=A0

=A0


this is administrative classificat= ion.
It could be useful but requires some effort to create a classification= system.
Searching all the YANG modules for keywords seems crude.= =A0One of the
hardest parts of writing a new module is integrati= ng it well with existing modules.
Assuming everything under the same XML subtree is everything available=
related to some feature is not reliable.


Thanks

--- Alex

=

Andy

=A0

=A0<= /p>

From: netmod-bounces@ietf.o= rg [mailto:netmod-bounces@ietf.org] On Behalf Of Andy Bierman
Sent: Monday, September 16, 2013 6:15 PM
To: netmod@ietf= .org
Subject: [netmod] Fwd: New Version Notification for draft-bierman-ne= tmod-yang-conformance-00.txt

=A0

Hi,

=A0

I raised issues with YANG conformance mechanisms in = the past

but the issue was tabled until somebody proposed a s= olution.

I would like to un-table the issue and have the NETM= OD WG address the

YANG conformance issues raised in the draft.<= u>

=A0

=A0

thanks,

Andy

=A0

---------- Forwarded = message ----------
From: <int= ernet-drafts@ietf.org>
Date: Mon, Sep 16, 2013 at 6:09 PM
Subject: New Version Notification for draft-bierman-netmod-yang-conformance= -00.txt
To: Andy Bierman <andy@yumaworks.com>



A new version of I-D, draft-bierman-netmod-yang-conformance-00.txt
has been successfully submitted by Andy Bierman and posted to the
IETF repository.

Filename: =A0 =A0 =A0 =A0draft-bierman-netmod-yang-conformance
Revision: =A0 =A0 =A0 =A000
Title: =A0 =A0 =A0 =A0 =A0 YANG Conformance Specification
Creation date: =A0 2013-09-16
Group: =A0 =A0 =A0 =A0 =A0 Individual Submission
Number of pages: 38
URL: =A0 =A0 =A0 =A0 =A0 =A0 http://www.ietf.org/internet-drafts/draft-bierman-netmod-yang-conformance-0= 0.txt
Status: =A0 =A0 =A0 =A0 =A0http://datatracker.ietf= .org/doc/draft-bierman-netmod-yang-conformance
Htmlized: =A0 =A0 =A0 =A0http://tools.ietf.org/html/= draft-bierman-netmod-yang-conformance-00


Abstract:
=A0 =A0This document describes conformance specification and advertisement<= br> =A0 =A0mechanisms for NETCONF servers implementing YANG data model modules.=




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.

The IETF Secretariat

=A0


--047d7b5d59724ad15204ea71cca8-- From alex@cisco.com Tue Nov 5 10:12:51 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCF1F11E81F3 for ; Tue, 5 Nov 2013 10:12:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.998 X-Spam-Level: X-Spam-Status: No, score=-9.998 tagged_above=-999 required=5 tests=[AWL=0.599, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gs5-ktPVoXA3 for ; Tue, 5 Nov 2013 10:12:46 -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 5423C11E8118 for ; Tue, 5 Nov 2013 10:12:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=27542; q=dns/txt; s=iport; t=1383675162; x=1384884762; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=w4I7E91kdrgzWwsDtqv6prl7XwJj/4d11mMwq5flhvo=; b=Uv4yegS/wOV7VzYqAchEQfwuGlfyhZhzjNnbIXlNDYGtINxVVFTEthgY fiMYtyDV1nuJ+/sYw0Lc4xwcdk9QY+qNFQyuaC6vae4q/LOtFjVdEWJP7 6GoYF2vmX9fUjNdJBKouN/8XL9qkc9UTdU3ZuQN/xkrgkKeKnq0uL4HzJ 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AscGANAzeVKtJV2d/2dsb2JhbABZgkNEOFOtDYloiEOBLBZ0giUBAQEELUoCEAIBCBEDAQEBCxYHBzIUCQgCBA4FCAESh2YNvnKPKCARBgEGA4MXgQ8DmTmQWoFogT6CKg X-IronPort-AV: E=Sophos;i="4.93,640,1378857600"; d="scan'208,217";a="281031369" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-6.cisco.com with ESMTP; 05 Nov 2013 18:12:31 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id rA5ICVOl013785 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 5 Nov 2013 18:12:31 GMT Received: from xmb-rcd-x05.cisco.com ([169.254.15.100]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0123.003; Tue, 5 Nov 2013 12:12:30 -0600 From: "Alexander Clemm (alex)" To: Andy Bierman Thread-Topic: [netmod] Fwd: New Version Notification for draft-bierman-netmod-yang-conformance-00.txt Thread-Index: AQHO2lDR7XT+KPVjVE+Cy9D66n1l35oW7X/g Date: Tue, 5 Nov 2013 18:12:30 +0000 Message-ID: References: <20130917010924.30052.13344.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.253.19] Content-Type: multipart/alternative; boundary="_000_DBC595ED2346914F9F81D17DD5C32B571860234Exmbrcdx05ciscoc_" MIME-Version: 1.0 Cc: "netmod@ietf.org" Subject: Re: [netmod] Fwd: New Version Notification for draft-bierman-netmod-yang-conformance-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 18:12:51 -0000 --_000_DBC595ED2346914F9F81D17DD5C32B571860234Exmbrcdx05ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Andy, Thank you. I think if the mixing between packages and profiles is dropped, specificall= y the inclusion of packages inside profiles, things may become a bit easier= to use and have more straightforward semantics. It also avoids the issue = of including more of a package than is really required, the same issue list= ed as an issue with current imports which extend to the entire module even = when only some small parts are really needed. The statement in section 3.4 "Only one profile per package can be active on= a server at a time" should probably be rethought. You state in your respo= nse that "Multiple profiles or switching between them is a possibility" - s= houldn't it simply be "multiple profiles"; since we are talking about confo= rmance, I am also not sure why a server would want to be able to dynamicall= y switch between different conformances; conformance presumably refers to a= static capability of the server as a whole. --- Alex From: Andy Bierman [mailto:andy@yumaworks.com] Sent: Tuesday, November 05, 2013 10:00 AM To: Alexander Clemm (alex) Cc: netmod@ietf.org Subject: Re: [netmod] Fwd: New Version Notification for draft-bierman-netmo= d-yang-conformance-00.txt On Tue, Nov 5, 2013 at 9:44 AM, Alexander Clemm (alex) > wrote: Hi, I think this draft addresses important issues. I do have a few comments/questions. Those have mainly to do with the mixin= g between packages and profiles, which, as currently stated, I find somewha= t confusing, in particular how a profile can have a "require-package" subst= atement, and how profiles in turn are defined inside packages. This blurs t= he lines between them and makes the distinction less clear. Adding to my = confusion is the fact that it is stated in one place that a package can con= tain zero or more profiles, yet section 3.4 states that only one profile pe= r package can be active at any one time. So, how do I know which is active= , why are they exclusive (this seems to unnecessarily complicate matters), = wasn't the package supposed to clarify which modules/features/capabilities = have actually been implemented? The profile name is included in the :package capability defined in sec. 6. It would seem that: - A profile is basically a "unit of conformance" that needs to be = implemented together to meet the needs of some categories of use case. yes -- conformance to a use-case may not align perfectly with 1 YANG module= . A package could cover 1 module, N modules, or even just 1 object. - The same server can implement and support multiple profiles conc= urrently, irrespective of which packages those profiles happen to have been= defined in. this is an open issue. I started simple saying just 1 profile is active. Multiple profiles or switching between them is a possibility. - A profile can probably "include" other profiles. yes -- see include-profile statement in sec. 4.5 A package would then basically be just a "module" containing profile defini= tions. What is the unit of conformance? Presumably, the profile, not the = package. If a profile can "include" other profiles, profiles should be abl= e to refer to those other profiles. This includes potentially modules in o= ther packages and is probably the reason for the require-package substateme= nt, but it is not clear from the spec (and, if only a single profile from t= hat package is needed, leads to requiring "too much"). Separate issue re: packages, I am not sure what purpose the "category" stat= ement serves. Is this merely another "label" attached to a package without= further meaning? How does it help with conformance statements? this is administrative classification. It could be useful but requires some effort to create a classification syst= em. Searching all the YANG modules for keywords seems crude. One of the hardest parts of writing a new module is integrating it well with existing = modules. Assuming everything under the same XML subtree is everything available related to some feature is not reliable. Thanks --- Alex Andy From: netmod-bounces@ietf.org [mailto:netmo= d-bounces@ietf.org] On Behalf Of Andy Bierm= an Sent: Monday, September 16, 2013 6:15 PM To: netmod@ietf.org Subject: [netmod] Fwd: New Version Notification for draft-bierman-netmod-ya= ng-conformance-00.txt Hi, I raised issues with YANG conformance mechanisms in the past but the issue was tabled until somebody proposed a solution. I would like to un-table the issue and have the NETMOD WG address the YANG conformance issues raised in the draft. thanks, Andy ---------- Forwarded message ---------- From: > Date: Mon, Sep 16, 2013 at 6:09 PM Subject: New Version Notification for draft-bierman-netmod-yang-conformance= -00.txt To: Andy Bierman > A new version of I-D, draft-bierman-netmod-yang-conformance-00.txt has been successfully submitted by Andy Bierman and posted to the IETF repository. Filename: draft-bierman-netmod-yang-conformance Revision: 00 Title: YANG Conformance Specification Creation date: 2013-09-16 Group: Individual Submission Number of pages: 38 URL: http://www.ietf.org/internet-drafts/draft-bierman-netmod-y= ang-conformance-00.txt Status: http://datatracker.ietf.org/doc/draft-bierman-netmod-yang-= conformance Htmlized: http://tools.ietf.org/html/draft-bierman-netmod-yang-confo= rmance-00 Abstract: This document describes conformance specification and advertisement mechanisms for NETCONF servers implementing YANG data model modules. 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. The IETF Secretariat --_000_DBC595ED2346914F9F81D17DD5C32B571860234Exmbrcdx05ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello Andy,

 <= /p>

Thank you.

 <= /p>

I think if the mixing bet= ween packages and profiles is dropped, specifically the inclusion of packag= es inside profiles, things may become a bit easier to use and have more straightforward semantics.  It also avoids the issue of= including more of a package than is really required, the same issue listed= as an issue with current imports which extend to the entire module even wh= en only some small parts are really needed. 

 <= /p>

The statement in section = 3.4 “Only one profile per package can be active on a server at a time= ” should probably be rethought.  You state in your response that “Multiple profiles or switching between them is a possibility= ” – shouldn’t it simply be = 220;multiple profiles”; since we are talking about conformance, I am = also not sure why a server would want to be able to dynamically switch between different con= formances; conformance presumably refers to a static capability of the serv= er as a whole. 

 <= /p>

--- Alex

 <= /p>

From: Andy Bie= rman [mailto:andy@yumaworks.com]
Sent: Tuesday, November 05, 2013 10:00 AM
To: Alexander Clemm (alex)
Cc: netmod@ietf.org
Subject: Re: [netmod] Fwd: New Version Notification for draft-bierma= n-netmod-yang-conformance-00.txt

 

 

 

On Tue, Nov 5, 2013 at 9:44 AM, Alexander Clemm (ale= x) <alex@cisco.com> wrote:

Hi,

 

I think this draft addresses important = issues.

 

I do have a few comments/questions.&nbs= p; Those have mainly to do with the mixing between packages and profiles, which, as currently stated, I find somewhat confusing, in partic= ular how a profile can have a “require-package” substatement, a= nd how profiles in turn are defined inside packages. This blurs the lines b= etween them and makes the distinction less clear.   Adding to my confusion is the fact that it is stated in one place th= at a package can contain zero or more profiles, yet section 3.4 states that= only one profile per package can be active at any one time.  So, how = do I know which is active, why are they exclusive (this seems to unnecessarily complicate matters), wasn’t the package= supposed to clarify which modules/features/capabilities have actually been= implemented? 

 

 

The profile name is included in the :package capabil= ity defined in sec. 6.

 

It would seem that:

-          A profile is basically a “unit of c= onformance” that needs to be implemented together to meet the needs o= f some categories of use case. 

 

yes -- conformance to a use-case may not align perfe= ctly with 1 YANG module.

A package could cover 1 module, N modules, or even j= ust 1 object.

 

 

-          The same server can implement and support= multiple profiles concurrently, irrespective of which packages those profi= les happen to have been defined in.

 

this is an open issue.  I started simple saying= just 1 profile is active.

Multiple profiles or switching between them is a pos= sibility.

 

-          A profile can probably “includeR= 21; other profiles. 

 

 

 

yes -- see include-profile statement in  sec. 4= .5

 

A package would then basically be just = a “module” containing profile definitions.  What is the un= it of conformance?  Presumably, the profile, not the package.  If a= profile can “include” other profiles, profiles should be able = to refer to those other profiles.  This includes potentially modules i= n other packages and is probably the reason for the require-package substatement, but it is not clear from the spec (and, if only a single pro= file from that package is needed, leads to requiring “too much”= ).    

 

Separate issue re: packages, I am not s= ure what purpose the “category” statement serves.  Is this merely another “label” attached to a package without further m= eaning?  How does it help with conformance statements? 

 

 

this is administrative classification.

It could be useful but requires some effort to creat= e a classification system.

Searching all the YANG modules for keywords seems cr= ude.  One of the

hardest parts of writing a new module is integrating= it well with existing modules.

Assuming everything under the same XML subtree is ev= erything available

related to some feature is not reliable.<= /p>

 

 

Thanks

--- Alex

 

Andy

 

 

 

From: netmod-bounces= @ietf.org [mailto:netmod-bounces@ietf.org] On Behalf Of Andy Bierman
Sent: Monday, September 16, 2013 6:15 PM
To: netmod@ietf= .org
Subject: [netmod] Fwd: New Version Notification for draft-bierman-ne= tmod-yang-conformance-00.txt

 

Hi,

 

I raised issues with YANG conformance mechanisms in the past<= /o:p>

but the issue was tabled until somebody proposed a solution.<= /o:p>

I would like to un-table the issue and have the NETMOD WG address = the

YANG conformance issues raised in the draft.

 

 

thanks,

Andy

 

---------- Forwarded message ----------
From: <int= ernet-drafts@ietf.org>
Date: Mon, Sep 16, 2013 at 6:09 PM
Subject: New Version Notification for draft-bierman-netmod-yang-conformance= -00.txt
To: Andy Bierman <andy@yumaworks.com>



A new version of I-D, draft-bierman-netmod-yang-conformance-00.txt
has been successfully submitted by Andy Bierman and posted to the
IETF repository.

Filename:        draft-bierman-netmod-yang-conformance<= br> Revision:        00
Title:           YANG Conformance Specification Creation date:   2013-09-16
Group:           Individual Submission
Number of pages: 38
URL:             http://www.ietf.org/internet-drafts/draft-bierman-netmod-yang-conformance-0= 0.txt
Status:          http://d= atatracker.ietf.org/doc/draft-bierman-netmod-yang-conformance
Htmlized:        http://tools.ie= tf.org/html/draft-bierman-netmod-yang-conformance-00


Abstract:
   This document describes conformance specification and advertis= ement
   mechanisms for NETCONF servers implementing YANG data model mo= dules.




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.

The IETF Secretariat

 

 

--_000_DBC595ED2346914F9F81D17DD5C32B571860234Exmbrcdx05ciscoc_-- From mbj@tail-f.com Tue Nov 5 10:44:23 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 211DC11E81D2 for ; Tue, 5 Nov 2013 10:44:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.746 X-Spam-Level: X-Spam-Status: No, score=-1.746 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5gwKIIk7YJRA for ; Tue, 5 Nov 2013 10:44:12 -0800 (PST) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 4AB1611E8121 for ; Tue, 5 Nov 2013 10:43:58 -0800 (PST) Received: from localhost (dhcp-a398.meeting.ietf.org [31.133.163.152]) by mail.tail-f.com (Postfix) with ESMTPSA id 8F14A1200054; Tue, 5 Nov 2013 19:43:47 +0100 (CET) Date: Tue, 05 Nov 2013 10:43:38 -0800 (PST) Message-Id: <20131105.104338.346453015.mbj@tail-f.com> To: david.kessens@gmail.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] Last chance for review: draft-ietf-netmod-ip-cfg & draft-ietf-netmod-ip-cfg X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 18:44:23 -0000 Hi, David Kessens wrote: > Since Benoit will be busy during this week, you will have until the > end of > this week if there is anything that escaped our attention that you > believe > needs more discussion. I think the latest discussion about the interface type in draft-ietf-netmod-interfaces-cfg-12 ended in a consensus to change the type from an enum to an identity. (the mail thread was actually called "I-D Action: draft-ietf-netmod-ip-cfg-10.txt"). (Lada already changed the enums in the routing draft to identites) To be very concrete, here are the proposed changes: o Remove the document draft-ietf-netmod-iana-if-type-07 - it is not needed anymore. o Change the leaf type from OLD: leaf type { type ianaift:iana-if-type; to NEW: leaf type { type identityref { base interface-type; } o Define the base identity, and define an identity for loopback interfaces: identity interface-type { description "Base identity from which specific interface types are derived."; } identity loopback { base if:interface-type; description "This interface type represents a loopback interface."; } o Update the examples to reflect this. /martin From lhotka@nic.cz Tue Nov 5 10:52:40 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40F6821E81E1 for ; Tue, 5 Nov 2013 10:52:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id McubhAeiXIZO for ; Tue, 5 Nov 2013 10:52:39 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 9090711E8220 for ; Tue, 5 Nov 2013 10:51:36 -0800 (PST) Received: from wireless-v6.meeting.ietf.org (unknown [IPv6:2001:67c:370:160:d031:d73f:eddd:dec8]) by mail.nic.cz (Postfix) with ESMTPSA id 6F0FD13FA60; Tue, 5 Nov 2013 19:51:19 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1383677480; bh=xj9poq61yyZ0lh3NsSOZVizG4+T6yVLZr+AIsWXzOgs=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=p1Vgv7hvF7l7+kxvKFDBdgkJ2D9j6Nyhb5/KatJY7y681DdCB8PAvpZxlh/9yfXVC C3DGBr1V2wZM0nIRF1OsuMON6AHEljZ7jhuobV2bkDgnYU3E8cUY2iQvVa0g9UN21s JcL8dzsLkLQUlL5t9s5LgomQd65vRcJAlF9vBFho= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) From: Ladislav Lhotka In-Reply-To: <20131105.104338.346453015.mbj@tail-f.com> Date: Tue, 5 Nov 2013 10:51:16 -0800 Content-Transfer-Encoding: 7bit Message-Id: <6114585D-F31B-46E2-985E-D6ACF781995E@nic.cz> References: <20131105.104338.346453015.mbj@tail-f.com> To: =?iso-8859-1?Q?Martin_Bj=F6rklund?= X-Mailer: Apple Mail (2.1816) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] Last chance for review: draft-ietf-netmod-ip-cfg & draft-ietf-netmod-ip-cfg X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 18:52:40 -0000 On 05 Nov 2013, at 10:43, Martin Bjorklund wrote: > Hi, > > David Kessens wrote: >> Since Benoit will be busy during this week, you will have until the >> end of >> this week if there is anything that escaped our attention that you >> believe >> needs more discussion. > > I think the latest discussion about the interface type in > draft-ietf-netmod-interfaces-cfg-12 ended in a consensus to change the > type from an enum to an identity. (the mail thread was actually > called "I-D Action: draft-ietf-netmod-ip-cfg-10.txt"). > > (Lada already changed the enums in the routing draft to identites) > > To be very concrete, here are the proposed changes: > > o Remove the document draft-ietf-netmod-iana-if-type-07 - it is not > needed anymore. > > o Change the leaf type from OLD: > > leaf type { > type ianaift:iana-if-type; > > to NEW: > > leaf type { > type identityref { > base interface-type; > } > > o Define the base identity, and define an identity for loopback > interfaces: > > identity interface-type { > description > "Base identity from which specific interface types are > derived."; > } > > identity loopback { > base if:interface-type; > description > "This interface type represents a loopback interface."; > } > > > o Update the examples to reflect this. I fully support these changes. Lada > > > /martin > > > > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From andy@yumaworks.com Tue Nov 5 10:55:33 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BCE121E809F for ; Tue, 5 Nov 2013 10:55:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.832 X-Spam-Level: X-Spam-Status: No, score=-2.832 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k1CqvXpkCcvG for ; Tue, 5 Nov 2013 10:55:29 -0800 (PST) Received: from mail-qc0-f182.google.com (mail-qc0-f182.google.com [209.85.216.182]) by ietfa.amsl.com (Postfix) with ESMTP id AFB7C21E8097 for ; Tue, 5 Nov 2013 10:55:26 -0800 (PST) Received: by mail-qc0-f182.google.com with SMTP id n7so5081034qcx.13 for ; Tue, 05 Nov 2013 10:55:26 -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=RmnWaeonW6gBgMRzDImQREgwbxqGsRsCzt9qeuFLhAo=; b=glIHiIRerVNKXbF2TIhbCWTf3h+G/4WdsSpra6QXWXBinLiJPB2853OeTeSbq+FLpS uHEjwabBSohBpIMfITAutEQZnt98z+87YrC9FLjWl9rOD5bNSGqwKLSQOVdUSvO4V85x zC0UlyC2SvVzNNqwOZk5Ftq2RY8ZLVHGR26m5tJXplp1UzuDGZd889/qCw2FG0Cs/9mY EJ6IopNXdaPviIIC3dadFV9LNeyNWrYbMtH9o5LdeKnmLdx6pAnm+0y52lOWe+ghfWYn 8mGSOza6y5fDt305EfSewQFWUU99M8f3oU9/RUm50eWfFU+vVi1BAgHMcGdVpCTex/RY engw== X-Gm-Message-State: ALoCoQkLMd12IQwe3Nl+uF8RIBv4RcfsDCSRXBS4YYyH9o09ocSfVnwLF3yKnZUDB+QEe5pGxG61 MIME-Version: 1.0 X-Received: by 10.49.29.70 with SMTP id i6mr11715107qeh.89.1383677726000; Tue, 05 Nov 2013 10:55:26 -0800 (PST) Received: by 10.140.100.203 with HTTP; Tue, 5 Nov 2013 10:55:25 -0800 (PST) In-Reply-To: <20131105.104338.346453015.mbj@tail-f.com> References: <20131105.104338.346453015.mbj@tail-f.com> Date: Tue, 5 Nov 2013 10:55:25 -0800 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: multipart/alternative; boundary=047d7bea3d0257a17d04ea729336 Cc: "netmod@ietf.org" Subject: Re: [netmod] Last chance for review: draft-ietf-netmod-ip-cfg & draft-ietf-netmod-ip-cfg X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 18:55:34 -0000 --047d7bea3d0257a17d04ea729336 Content-Type: text/plain; charset=ISO-8859-1 Hi, My concern over identityref has been that vendors will make up their own identities and even the enumerations that are currently useful will become proprietary. The proposal on the list was that the standard enums would of course be replaced with standard identities. Now the proposal is to only standardize 'loopback' and vendors will make up the rest on their own. I do not think it is realistic that enum --> identity standardization will happen in an ad-hoc fashion. If this WG does not do it now, then it is not going to happen. Waiting years for the identities will only make things worse as vendor identities get deployed and become legacy baggage. I think the enum draft needs to be rewritten to use identities. Andy On Tue, Nov 5, 2013 at 10:43 AM, Martin Bjorklund wrote: > Hi, > > David Kessens wrote: > > Since Benoit will be busy during this week, you will have until the > > end of > > this week if there is anything that escaped our attention that you > > believe > > needs more discussion. > > I think the latest discussion about the interface type in > draft-ietf-netmod-interfaces-cfg-12 ended in a consensus to change the > type from an enum to an identity. (the mail thread was actually > called "I-D Action: draft-ietf-netmod-ip-cfg-10.txt"). > > (Lada already changed the enums in the routing draft to identites) > > To be very concrete, here are the proposed changes: > > o Remove the document draft-ietf-netmod-iana-if-type-07 - it is not > needed anymore. > > o Change the leaf type from OLD: > > leaf type { > type ianaift:iana-if-type; > > to NEW: > > leaf type { > type identityref { > base interface-type; > } > > o Define the base identity, and define an identity for loopback > interfaces: > > identity interface-type { > description > "Base identity from which specific interface types are > derived."; > } > > identity loopback { > base if:interface-type; > description > "This interface type represents a loopback interface."; > } > > > o Update the examples to reflect this. > > > /martin > > > > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --047d7bea3d0257a17d04ea729336 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

My concern over identityref has bee= n that vendors will make up their
own identities and even the enu= merations that are currently useful
will become proprietary.

The proposal on the list was that the standard enums wo= uld of course be
replaced with standard identities. Now the propo= sal is to only
standardize 'loopback' and vendors will ma= ke up the rest on their own.
I do not think it is realistic that enum --> identity standardizati= on will
happen in an ad-hoc fashion. =A0If this WG does not do it= now, then it
is not going to happen. =A0Waiting years for the id= entities will only make things worse
as vendor identities get deployed and become legacy baggage.
I think the enum draft needs to be rewritten to use identities.
=
Andy


On Tue, Nov 5, 2013 at 10:43 AM, Martin Bjor= klund <mbj@tail-f.com> wrote:
Hi,

David Kessens <david.kessens@= gmail.com> wrote:
> Since Benoit will be busy during this week, you will have until the > end of
> this week if there is anything that escaped our attention that you
> believe
> needs more discussion.

I think the latest discussion about the interface type in
draft-ietf-netmod-interfaces-cfg-12 ended in a consensus to change the
type from an enum to an identity. =A0(the mail thread was actually
called "I-D Action: draft-ietf-netmod-ip-cfg-10.txt").

(Lada already changed the enums in the routing draft to identites)

To be very concrete, here are the proposed changes:

o =A0Remove the document draft-ietf-netmod-iana-if-type-07 - it is not
=A0 =A0needed anymore.

o =A0Change the leaf type from OLD:

=A0 =A0 =A0 leaf type {
=A0 =A0 =A0 =A0 type ianaift:iana-if-type;

=A0 =A0to NEW:

=A0 =A0 =A0 leaf type {
=A0 =A0 =A0 =A0 type identityref {
=A0 =A0 =A0 =A0 =A0 base interface-type;
=A0 =A0 =A0 =A0 }

o =A0Define the base identity, and define an identity for loopback
=A0 =A0interfaces:

=A0 identity interface-type {
=A0 =A0 description
=A0 =A0 =A0 "Base identity from which specific interface types are
=A0 =A0 =A0 =A0derived.";
=A0 }

=A0 identity loopback {
=A0 =A0 base if:interface-type;
=A0 =A0 description
=A0 =A0 =A0 "This interface type represents a loopback interface."= ;;
=A0 }


o =A0Update the examples to reflect this.


/martin






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

--047d7bea3d0257a17d04ea729336-- From lhotka@nic.cz Tue Nov 5 11:08:38 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 204EC11E813B for ; Tue, 5 Nov 2013 11:08:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.85 X-Spam-Level: X-Spam-Status: No, score=-1.85 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WBNSNEi57PP6 for ; Tue, 5 Nov 2013 11:08:37 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 18CFD11E8110 for ; Tue, 5 Nov 2013 11:08:36 -0800 (PST) Received: from wireless-v6.meeting.ietf.org (unknown [IPv6:2001:67c:370:160:d031:d73f:eddd:dec8]) by mail.nic.cz (Postfix) with ESMTPSA id E352913FA60; Tue, 5 Nov 2013 20:08:33 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1383678515; bh=S3usR6JC6B0pF2YrfX+dwCY4xv9ExgnCRPohIikmwP8=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=hNrS4YazrwcVrd7wadSTl9jM8syCwsb80UPDk+d9lIUuHPhxW6DVd8aobFXHR3B9e i+uFtdq5NxgCOnVuMo+ITyXhRLzYf6ECYDDPJJQPOvEc8bCDIyZA8unse7UiDIjMp/ 1wBrRvDcLqbK3HESQiMhK2ZR+yjYOQQfi0cxlYOE= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) From: Ladislav Lhotka In-Reply-To: Date: Tue, 5 Nov 2013 11:08:31 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20131105.104338.346453015.mbj@tail-f.com> To: Andy Bierman X-Mailer: Apple Mail (2.1816) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Cc: "netmod@ietf.org" Subject: Re: [netmod] Last chance for review: draft-ietf-netmod-ip-cfg & draft-ietf-netmod-ip-cfg X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 19:08:38 -0000 On 05 Nov 2013, at 10:55, Andy Bierman wrote: > Hi, >=20 > My concern over identityref has been that vendors will make up their > own identities and even the enumerations that are currently useful > will become proprietary. >=20 > The proposal on the list was that the standard enums would of course = be > replaced with standard identities. Now the proposal is to only > standardize 'loopback' and vendors will make up the rest on their own. > I do not think it is realistic that enum --> identity standardization = will > happen in an ad-hoc fashion. If this WG does not do it now, then it > is not going to happen. Waiting years for the identities will only = make things worse > as vendor identities get deployed and become legacy baggage. > I think the enum draft needs to be rewritten to use identities. I think it would be helpful to treat identities not as a way for = classifying the universe, but rather in a very practical YANGish way: it = is a tag that is mainly useful for conditional inclusion of certain data = definitions based on interface type or other identityref. Then it also = makes a very good sense to bundle the corresponding identity with said = data definitions. If there is a high quality YANG module that vendors want to adopt, why = should they have a problem with using the standard identity - or making = their own identity derived from the standard one? And if there is no = good standard model, vendors will write their proprietary models anyway, = and standardized interface type identities won=92t help. Lada >=20 > Andy >=20 >=20 >=20 > On Tue, Nov 5, 2013 at 10:43 AM, Martin Bjorklund = wrote: > Hi, >=20 > David Kessens wrote: > > Since Benoit will be busy during this week, you will have until the > > end of > > this week if there is anything that escaped our attention that you > > believe > > needs more discussion. >=20 > I think the latest discussion about the interface type in > draft-ietf-netmod-interfaces-cfg-12 ended in a consensus to change the > type from an enum to an identity. (the mail thread was actually > called "I-D Action: draft-ietf-netmod-ip-cfg-10.txt"). >=20 > (Lada already changed the enums in the routing draft to identites) >=20 > To be very concrete, here are the proposed changes: >=20 > o Remove the document draft-ietf-netmod-iana-if-type-07 - it is not > needed anymore. >=20 > o Change the leaf type from OLD: >=20 > leaf type { > type ianaift:iana-if-type; >=20 > to NEW: >=20 > leaf type { > type identityref { > base interface-type; > } >=20 > o Define the base identity, and define an identity for loopback > interfaces: >=20 > identity interface-type { > description > "Base identity from which specific interface types are > derived."; > } >=20 > identity loopback { > base if:interface-type; > description > "This interface type represents a loopback interface."; > } >=20 >=20 > o Update the examples to reflect this. >=20 >=20 > /martin >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From andy@yumaworks.com Tue Nov 5 11:16:23 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B196E11E80E2 for ; Tue, 5 Nov 2013 11:16:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.534 X-Spam-Level: X-Spam-Status: No, score=-2.534 tagged_above=-999 required=5 tests=[AWL=-0.158, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kRe20QKNv5Ff for ; Tue, 5 Nov 2013 11:16:17 -0800 (PST) Received: from mail-qe0-f53.google.com (mail-qe0-f53.google.com [209.85.128.53]) by ietfa.amsl.com (Postfix) with ESMTP id 66A3211E81C4 for ; Tue, 5 Nov 2013 11:16:17 -0800 (PST) Received: by mail-qe0-f53.google.com with SMTP id cy11so5275802qeb.26 for ; Tue, 05 Nov 2013 11:16: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=/i2VFhtVxr5lA/+3BZ8dpNQzTke3djlNYdk7USpQTiQ=; b=UUzJETkdr2Stm3Lgr78nX4b4yaY9P7FEO+LoIiCM0iBS/z89Gvppyfukh1F05/QMoY nq2xPmKdyd1APN9+yyBTiILAPrI/gTKVGHrJQw+4peihdYpXT8IdHsK+g7ylQq1Z9Ke+ FQL+x0/l/OFsfU4EKwLhWQ4RAxafkm9YaVGingKyfXZDfJttgleX/kxDHMD21m7ZjNd9 tw4lJx+FnnHpUvZJMlQU5uWuaCWmRFucTEsSX1tJjqaU+1z6CZHMhxO8HO8Frf4DfjqU dUI7hWUJYGU8cpTYjevCzovEy7h5uz+xoPUkUOXDsdpx+OGp4fHBBzaZXDuHvUC2lSEP lNNw== X-Gm-Message-State: ALoCoQkSmoCRIGTmu1WxOcTZaawH6eqE348BPwkcwPOieESH45OZnrotqbydMYUpWPjwDOCNPFW8 MIME-Version: 1.0 X-Received: by 10.49.49.104 with SMTP id t8mr28671415qen.45.1383678975759; Tue, 05 Nov 2013 11:16:15 -0800 (PST) Received: by 10.140.100.203 with HTTP; Tue, 5 Nov 2013 11:16:15 -0800 (PST) In-Reply-To: References: <20131105.104338.346453015.mbj@tail-f.com> Date: Tue, 5 Nov 2013 11:16:15 -0800 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=047d7b6d9bbad56bf004ea72dd86 Cc: "netmod@ietf.org" Subject: Re: [netmod] Last chance for review: draft-ietf-netmod-ip-cfg & draft-ietf-netmod-ip-cfg X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 19:16:23 -0000 --047d7b6d9bbad56bf004ea72dd86 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Tue, Nov 5, 2013 at 11:08 AM, Ladislav Lhotka wrote: > > On 05 Nov 2013, at 10:55, Andy Bierman wrote: > > > Hi, > > > > My concern over identityref has been that vendors will make up their > > own identities and even the enumerations that are currently useful > > will become proprietary. > > > > The proposal on the list was that the standard enums would of course be > > replaced with standard identities. Now the proposal is to only > > standardize 'loopback' and vendors will make up the rest on their own. > > I do not think it is realistic that enum --> identity standardization > will > > happen in an ad-hoc fashion. If this WG does not do it now, then it > > is not going to happen. Waiting years for the identities will only mak= e > things worse > > as vendor identities get deployed and become legacy baggage. > > I think the enum draft needs to be rewritten to use identities. > > I think it would be helpful to treat identities not as a way for > classifying the universe, but rather in a very practical YANGish way: it = is > a tag that is mainly useful for conditional inclusion of certain data > definitions based on interface type or other identityref. Then it also > makes a very good sense to bundle the corresponding identity with said da= ta > definitions. > > then throw out if-type and call it something else. I do not agree with this view of this leaf. > If there is a high quality YANG module that vendors want to adopt, why > should they have a problem with using the standard identity - or making > their own identity derived from the standard one? And if there is no good > standard model, vendors will write their proprietary models anyway, and > standardized interface type identities won=92t help. > > There is no problem using the standard identity most appropriate to the interface type. This assumes there actually is a standard list of interface types. That was your original proposal. Now that has changed and vendors will have no standard list to choose from. I am strongly opposed to this new proposal to only standardize the base identity + loopback. Lada > > Andy > > > > Andy > > > > > > > > On Tue, Nov 5, 2013 at 10:43 AM, Martin Bjorklund > wrote: > > Hi, > > > > David Kessens wrote: > > > Since Benoit will be busy during this week, you will have until the > > > end of > > > this week if there is anything that escaped our attention that you > > > believe > > > needs more discussion. > > > > I think the latest discussion about the interface type in > > draft-ietf-netmod-interfaces-cfg-12 ended in a consensus to change the > > type from an enum to an identity. (the mail thread was actually > > called "I-D Action: draft-ietf-netmod-ip-cfg-10.txt"). > > > > (Lada already changed the enums in the routing draft to identites) > > > > To be very concrete, here are the proposed changes: > > > > o Remove the document draft-ietf-netmod-iana-if-type-07 - it is not > > needed anymore. > > > > o Change the leaf type from OLD: > > > > leaf type { > > type ianaift:iana-if-type; > > > > to NEW: > > > > leaf type { > > type identityref { > > base interface-type; > > } > > > > o Define the base identity, and define an identity for loopback > > interfaces: > > > > identity interface-type { > > description > > "Base identity from which specific interface types are > > derived."; > > } > > > > identity loopback { > > base if:interface-type; > > description > > "This interface type represents a loopback interface."; > > } > > > > > > o Update the examples to reflect this. > > > > > > /martin > > > > > > > > > > > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > --047d7b6d9bbad56bf004ea72dd86 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable



On Tue, Nov 5, 2013 at 11:08 AM, Ladislav Lhotka = <lhotka@nic.cz>= ; wrote:

On 05 Nov 2013, at 10:55, Andy Bierman <andy@yumaworks.com> wrote:

> Hi,
>
> My concern over identityref has been that vendors will make up their > own identities and even the enumerations that are currently useful
> will become proprietary.
>
> The proposal on the list was that the standard enums would of course b= e
> replaced with standard identities. Now the proposal is to only
> standardize 'loopback' and vendors will make up the rest on th= eir own.
> I do not think it is realistic that enum --> identity standardizati= on will
> happen in an ad-hoc fashion. =A0If this WG does not do it now, then it=
> is not going to happen. =A0Waiting years for the identities will only = make things worse
> as vendor identities get deployed and become legacy baggage.
> I think the enum draft needs to be rewritten to use identities.

I think it would be helpful to treat identities not as a way for classifyin= g the universe, but rather in a very practical YANGish way: it is a tag tha= t is mainly useful for conditional inclusion of certain data definitions ba= sed on interface type or other identityref. Then it also makes a very good = sense to bundle the corresponding identity with said data definitions.


then throw out if-type and call it som= ething else.
I do not agree with this view of this leaf.
=A0
If there is a high quality YANG module that vendors want to adopt, why shou= ld they have a problem with using the standard identity - or making their o= wn identity derived from the standard one? And if there is no good standard= model, vendors will write their proprietary models anyway, and standardize= d interface type identities won=92t help.


There is no problem using the standard= identity most appropriate to the interface type.
This assumes th= ere actually is a standard list of interface types. =A0That was your origin= al
proposal. =A0Now that has changed and vendors will have no standard = =A0list to choose from.
I am strongly opposed to this new proposa= l to only standardize the base identity + loopback.

Lada


Andy
=A0
>
> Andy
>
>
>
> On Tue, Nov 5, 2013 at 10:43 AM, Martin Bjorklund <mbj@tail-f.com> wrote:
> Hi,
>
> David Kessens <david.kes= sens@gmail.com> wrote:
> > Since Benoit will be busy during this week, you will have until t= he
> > end of
> > this week if there is anything that escaped our attention that yo= u
> > believe
> > needs more discussion.
>
> I think the latest discussion about the interface type in
> draft-ietf-netmod-interfaces-cfg-12 ended in a consensus to change the=
> type from an enum to an identity. =A0(the mail thread was actually
> called "I-D Action: draft-ietf-netmod-ip-cfg-10.txt").
>
> (Lada already changed the enums in the routing draft to identites)
>
> To be very concrete, here are the proposed changes:
>
> o =A0Remove the document draft-ietf-netmod-iana-if-type-07 - it is not=
> =A0 =A0needed anymore.
>
> o =A0Change the leaf type from OLD:
>
> =A0 =A0 =A0 leaf type {
> =A0 =A0 =A0 =A0 type ianaift:iana-if-type;
>
> =A0 =A0to NEW:
>
> =A0 =A0 =A0 leaf type {
> =A0 =A0 =A0 =A0 type identityref {
> =A0 =A0 =A0 =A0 =A0 base interface-type;
> =A0 =A0 =A0 =A0 }
>
> o =A0Define the base identity, and define an identity for loopback
> =A0 =A0interfaces:
>
> =A0 identity interface-type {
> =A0 =A0 description
> =A0 =A0 =A0 "Base identity from which specific interface types ar= e
> =A0 =A0 =A0 =A0derived.";
> =A0 }
>
> =A0 identity loopback {
> =A0 =A0 base if:interface-type;
> =A0 =A0 description
> =A0 =A0 =A0 "This interface type represents a loopback interface.= ";
> =A0 }
>
>
> o =A0Update the examples to reflect this.
>
>
> /martin
>
>
>
>
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

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





--047d7b6d9bbad56bf004ea72dd86-- From j.schoenwaelder@jacobs-university.de Tue Nov 5 11:23:19 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 051C021E811A for ; Tue, 5 Nov 2013 11:23:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.182 X-Spam-Level: X-Spam-Status: No, score=-103.182 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ohi5No5oMtu for ; Tue, 5 Nov 2013 11:23:13 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id ABAA321E80FA for ; Tue, 5 Nov 2013 11:23:03 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 593D420090; Tue, 5 Nov 2013 20:23: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 7SDv57BRpIaK; Tue, 5 Nov 2013 20:23: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 B6D5920088; Tue, 5 Nov 2013 20:22:59 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id D005D292CFE4; Tue, 5 Nov 2013 20:22:54 +0100 (CET) Date: Tue, 5 Nov 2013 20:22:54 +0100 From: Juergen Schoenwaelder To: "Lange, Jeffrey K (GE Energy Management)" Message-ID: <20131105192254.GA81506@elstar.local> Mail-Followup-To: "Lange, Jeffrey K (GE Energy Management)" , "netmod@ietf.org" References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "netmod@ietf.org" Subject: Re: [netmod] link-layer-address vs phys-address X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 19:23:19 -0000 On Fri, Oct 11, 2013 at 12:58:24PM +0000, Lange, Jeffrey K (GE Energy Management) wrote: > The ietf-ip module uses the name link-layer-address for all nodes of type phys-address. Yet the ietf-interfaces module uses: > > /interfaces-state/interface/phys-address > > Should this also be changed to link-layer-address so that the naming is consistent across modules? > The IP layer people like to call the think IP runs over a link and hence the term link-layer address makes sense from an IP viewpoint. But note that there are other interface stacks out there and they do often have different terminology. Hence, a different name like phys-address (which matches the name used for decades in the IF-MIB) is actually defendable since interfaces are really generic. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From mbj@tail-f.com Tue Nov 5 13:37:26 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D86B11E8156 for ; Tue, 5 Nov 2013 13:37:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V2iTtAcjZcJ1 for ; Tue, 5 Nov 2013 13:37:20 -0800 (PST) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id D4AF811E8125 for ; Tue, 5 Nov 2013 13:37:04 -0800 (PST) Received: from localhost (dhcp-91f1.meeting.ietf.org [31.133.145.241]) by mail.tail-f.com (Postfix) with ESMTPSA id 14F6B1200054; Tue, 5 Nov 2013 22:37:02 +0100 (CET) Date: Tue, 05 Nov 2013 13:37:00 -0800 (PST) Message-Id: <20131105.133700.288191076.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: <20131105.104338.346453015.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] Last chance for review: draft-ietf-netmod-ip-cfg & draft-ietf-netmod-ip-cfg X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 21:37:26 -0000 Hi, Andy Bierman wrote: > Hi, > > My concern over identityref has been that vendors will make up their > own identities and even the enumerations that are currently useful > will become proprietary. > > The proposal on the list was that the standard enums would of course > be > replaced with standard identities. Now the proposal is to only > standardize 'loopback' and vendors will make up the rest on their own. > I do not think it is realistic that enum --> identity standardization > will > happen in an ad-hoc fashion. If this WG does not do it now, then it > is not going to happen. Waiting years for the identities will only > make > things worse > as vendor identities get deployed and become legacy baggage. Even if we make identities of the iana ifType registry, there are no standard configuration modules for these types. So vendors will make them, until something gets standardized. We can't do much about it, unless we wait until we have modelled everything before publishing... So I don't think there's much value in having these standard identities w/o accompanying modules. OTOH, I can accept this (i.e., create identities from the iana registry) as a way to move forward. /martin From lhotka@nic.cz Tue Nov 5 13:51:20 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE1E221F9FCE for ; Tue, 5 Nov 2013 13:51:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.962 X-Spam-Level: X-Spam-Status: No, score=-1.962 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uQmOKybFtA0g for ; Tue, 5 Nov 2013 13:51:20 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 41AF321F9E26 for ; Tue, 5 Nov 2013 13:51:08 -0800 (PST) Received: from wireless-v6.meeting.ietf.org (unknown [IPv6:2001:67c:370:160:f162:d4af:598f:9dee]) by mail.nic.cz (Postfix) with ESMTPSA id E1EDA13F6A3; Tue, 5 Nov 2013 22:51:05 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1383688267; bh=fwe6tfYkSFd0GdqpNXcHHM68JYf17TPXvfV1Rc20KMQ=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=J+UYEvt583gqRJDwDqOR2X6Diws87K2uXc0MYCTDeZpc0zcQC0RTaPYw+gSdG/gka B86M5wQAacfDU0fvUfMMkjVJ20VbyDG7faqwIdGyZ9TMkW6EF6OP0TYgHupUc/Uf6G Rh5X7CGGyjjignIa2dmsG0TRuKomnNuUO5b4jMig= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) From: Ladislav Lhotka In-Reply-To: Date: Tue, 5 Nov 2013 13:51:03 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <533A474E-664A-4F25-A7B1-9F8BA970244D@nic.cz> References: <20131105.104338.346453015.mbj@tail-f.com> To: Andy Bierman X-Mailer: Apple Mail (2.1816) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Cc: "netmod@ietf.org" Subject: Re: [netmod] Last chance for review: draft-ietf-netmod-ip-cfg & draft-ietf-netmod-ip-cfg X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 21:51:20 -0000 On 05 Nov 2013, at 11:16, Andy Bierman wrote: >=20 >=20 >=20 > On Tue, Nov 5, 2013 at 11:08 AM, Ladislav Lhotka = wrote: >=20 > On 05 Nov 2013, at 10:55, Andy Bierman wrote: >=20 > > Hi, > > > > My concern over identityref has been that vendors will make up their > > own identities and even the enumerations that are currently useful > > will become proprietary. > > > > The proposal on the list was that the standard enums would of course = be > > replaced with standard identities. Now the proposal is to only > > standardize 'loopback' and vendors will make up the rest on their = own. > > I do not think it is realistic that enum --> identity = standardization will > > happen in an ad-hoc fashion. If this WG does not do it now, then it > > is not going to happen. Waiting years for the identities will only = make things worse > > as vendor identities get deployed and become legacy baggage. > > I think the enum draft needs to be rewritten to use identities. >=20 > I think it would be helpful to treat identities not as a way for = classifying the universe, but rather in a very practical YANGish way: it = is a tag that is mainly useful for conditional inclusion of certain data = definitions based on interface type or other identityref. Then it also = makes a very good sense to bundle the corresponding identity with said = data definitions. >=20 >=20 > then throw out if-type and call it something else. > I do not agree with this view of this leaf. > =20 > If there is a high quality YANG module that vendors want to adopt, why = should they have a problem with using the standard identity - or making = their own identity derived from the standard one? And if there is no = good standard model, vendors will write their proprietary models anyway, = and standardized interface type identities won=92t help. >=20 >=20 > There is no problem using the standard identity most appropriate to = the interface type. > This assumes there actually is a standard list of interface types. = That was your original > proposal. Now that has changed and vendors will have no standard = list to choose from. > I am strongly opposed to this new proposal to only standardize the = base identity + loopback. Can you describe a scenario you are worried about? Vendors can do = whatever they want, but their proprietary identities will remain in = their private modules and namespaces, and will not pollute any global = registry - because there will be no such thing in the first place. If there is (ever) a useful set of standard modules for real-world = interfaces, the same modules can also define a decent hierarchy of = identities in a step-by-step fashion. Lada =20 >=20 > Lada >=20 >=20 > Andy > =20 > > > > Andy > > > > > > > > On Tue, Nov 5, 2013 at 10:43 AM, Martin Bjorklund = wrote: > > Hi, > > > > David Kessens wrote: > > > Since Benoit will be busy during this week, you will have until = the > > > end of > > > this week if there is anything that escaped our attention that you > > > believe > > > needs more discussion. > > > > I think the latest discussion about the interface type in > > draft-ietf-netmod-interfaces-cfg-12 ended in a consensus to change = the > > type from an enum to an identity. (the mail thread was actually > > called "I-D Action: draft-ietf-netmod-ip-cfg-10.txt"). > > > > (Lada already changed the enums in the routing draft to identites) > > > > To be very concrete, here are the proposed changes: > > > > o Remove the document draft-ietf-netmod-iana-if-type-07 - it is not > > needed anymore. > > > > o Change the leaf type from OLD: > > > > leaf type { > > type ianaift:iana-if-type; > > > > to NEW: > > > > leaf type { > > type identityref { > > base interface-type; > > } > > > > o Define the base identity, and define an identity for loopback > > interfaces: > > > > identity interface-type { > > description > > "Base identity from which specific interface types are > > derived."; > > } > > > > identity loopback { > > base if:interface-type; > > description > > "This interface type represents a loopback interface."; > > } > > > > > > o Update the examples to reflect this. > > > > > > /martin > > > > > > > > > > > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod >=20 > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C >=20 >=20 >=20 >=20 >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From lhotka@nic.cz Tue Nov 5 14:03:32 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 307FE21E8097 for ; Tue, 5 Nov 2013 14:03:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.82 X-Spam-Level: X-Spam-Status: No, score=-1.82 tagged_above=-999 required=5 tests=[AWL=-0.120, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id McjLc79oWvft for ; Tue, 5 Nov 2013 14:03: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 B230D21E8182 for ; Tue, 5 Nov 2013 14:03:24 -0800 (PST) Received: from wireless-v6.meeting.ietf.org (unknown [IPv6:2001:67c:370:160:f162:d4af:598f:9dee]) by mail.nic.cz (Postfix) with ESMTPSA id 792D113F6A3; Tue, 5 Nov 2013 23:03:22 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1383689003; bh=3HWAQKwxcCIyaMAvL+UCXmSVsI6n38kRd3fzP2Y+GWM=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=hZUhz1DrPtvE2bkRNL+EmKcO1dR+F12+28JzLBd1M2/v1IkAsh+mkGOs8wGZKo6zL 7ufYgm59qqToeoIfnqe4p0XhF+s6A3SbyvLu93Q80Ea2hNrcSllzpXLJHEQFV5wGXp Or/2czdDkKklDvdLaOSsbM1S4YJ/7bn8JteT+T8g= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) From: Ladislav Lhotka In-Reply-To: <20131105.133700.288191076.mbj@tail-f.com> Date: Tue, 5 Nov 2013 14:03:19 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <93D2BC3A-7172-4384-A001-A96A3F9B9E49@nic.cz> References: <20131105.104338.346453015.mbj@tail-f.com> <20131105.133700.288191076.mbj@tail-f.com> To: =?windows-1252?Q?Martin_Bj=F6rklund?= X-Mailer: Apple Mail (2.1816) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] Last chance for review: draft-ietf-netmod-ip-cfg & draft-ietf-netmod-ip-cfg X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 22:03:32 -0000 On 05 Nov 2013, at 13:37, Martin Bjorklund wrote: > Hi, >=20 > Andy Bierman wrote: >> Hi, >>=20 >> My concern over identityref has been that vendors will make up their >> own identities and even the enumerations that are currently useful >> will become proprietary. >>=20 >> The proposal on the list was that the standard enums would of course >> be >> replaced with standard identities. Now the proposal is to only >> standardize 'loopback' and vendors will make up the rest on their = own. >> I do not think it is realistic that enum --> identity standardization >> will >> happen in an ad-hoc fashion. If this WG does not do it now, then it >> is not going to happen. Waiting years for the identities will only >> make >> things worse >> as vendor identities get deployed and become legacy baggage. >=20 > Even if we make identities of the iana ifType registry, there are no > standard configuration modules for these types. So vendors will make > them, until something gets standardized. We can't do much about it, > unless we wait until we have modelled everything before publishing... >=20 > So I don't think there's much value in having these standard > identities w/o accompanying modules. >=20 > OTOH, I can accept this (i.e., create identities from the iana > registry) as a way to move forward. Yes, as long as they won=92t be somehow mandatory to use. Lada >=20 >=20 > /martin > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From andy@yumaworks.com Tue Nov 5 14:10:18 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10A0921F9EB8 for ; Tue, 5 Nov 2013 14:10:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.531 X-Spam-Level: X-Spam-Status: No, score=-2.531 tagged_above=-999 required=5 tests=[AWL=-0.155, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l7ULcmSChVKv for ; Tue, 5 Nov 2013 14:10:00 -0800 (PST) Received: from mail-qe0-f51.google.com (mail-qe0-f51.google.com [209.85.128.51]) by ietfa.amsl.com (Postfix) with ESMTP id D072711E8160 for ; Tue, 5 Nov 2013 14:09:43 -0800 (PST) Received: by mail-qe0-f51.google.com with SMTP id q19so5489096qeb.38 for ; Tue, 05 Nov 2013 14:09:31 -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=wRcFY38OxqiWOI+r1cBC3W2b7fz45iZeL8zuqoiyIHg=; b=mY7TRgqX1QawppPPAoqOKwX9dID6rCQEFgexZZUACutxa9ikl82WQEJq/T5m2mHYtQ 8LgDp1gXw9VO5e3V4sYxQUMzx8aOjfZPxwpkq8Xu+26QitqJ5WLtDZOkjgjaqSWydOCg ppLxRk/5HZtg1b+V6FhE8AxT+GbsncDwD7fKbEs52xwQ4iLRlA4YIVphuiGgQFfmF2Lp 45l4gwonnFWal+5EzgVQidj8SXI2dmMWx15l0hYULEesadv8AdtsMZVPtw7YaJEXs9Du 0fwBZyCo+BLewxOwYWpdbkZfZ/XbxrcunDjFN6HIdCU+/K7VfMahmDoEzpuK7DLcJW3O cQgQ== X-Gm-Message-State: ALoCoQk1kjwLkm7xq7VBH0/vcjX/uwJJ+KYWmZV1i2oWAeXtBZ8OYCGNKofGRpo3VCXPqJx/EBEE MIME-Version: 1.0 X-Received: by 10.49.49.104 with SMTP id t8mr29911462qen.45.1383689371270; Tue, 05 Nov 2013 14:09:31 -0800 (PST) Received: by 10.140.100.203 with HTTP; Tue, 5 Nov 2013 14:09:31 -0800 (PST) In-Reply-To: <533A474E-664A-4F25-A7B1-9F8BA970244D@nic.cz> References: <20131105.104338.346453015.mbj@tail-f.com> <533A474E-664A-4F25-A7B1-9F8BA970244D@nic.cz> Date: Tue, 5 Nov 2013 14:09:31 -0800 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=047d7b6d9bba74694504ea754907 Cc: "netmod@ietf.org" Subject: Re: [netmod] Last chance for review: draft-ietf-netmod-ip-cfg & draft-ietf-netmod-ip-cfg X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 22:10:18 -0000 --047d7b6d9bba74694504ea754907 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Tue, Nov 5, 2013 at 1:51 PM, Ladislav Lhotka wrote: > > On 05 Nov 2013, at 11:16, Andy Bierman wrote: > > > > > > > > > On Tue, Nov 5, 2013 at 11:08 AM, Ladislav Lhotka wrote: > > > > On 05 Nov 2013, at 10:55, Andy Bierman wrote: > > > > > Hi, > > > > > > My concern over identityref has been that vendors will make up their > > > own identities and even the enumerations that are currently useful > > > will become proprietary. > > > > > > The proposal on the list was that the standard enums would of course = be > > > replaced with standard identities. Now the proposal is to only > > > standardize 'loopback' and vendors will make up the rest on their own= . > > > I do not think it is realistic that enum --> identity standardization > will > > > happen in an ad-hoc fashion. If this WG does not do it now, then it > > > is not going to happen. Waiting years for the identities will only > make things worse > > > as vendor identities get deployed and become legacy baggage. > > > I think the enum draft needs to be rewritten to use identities. > > > > I think it would be helpful to treat identities not as a way for > classifying the universe, but rather in a very practical YANGish way: it = is > a tag that is mainly useful for conditional inclusion of certain data > definitions based on interface type or other identityref. Then it also > makes a very good sense to bundle the corresponding identity with said da= ta > definitions. > > > > > > then throw out if-type and call it something else. > > I do not agree with this view of this leaf. > > > > If there is a high quality YANG module that vendors want to adopt, why > should they have a problem with using the standard identity - or making > their own identity derived from the standard one? And if there is no good > standard model, vendors will write their proprietary models anyway, and > standardized interface type identities won=92t help. > > > The standard registry you propose only has 1 entry -- loopback. I find it hard to believe this is the only enum from ifType that is used in real products. > > > There is no problem using the standard identity most appropriate to the > interface type. > > This assumes there actually is a standard list of interface types. Tha= t > was your original > > proposal. Now that has changed and vendors will have no standard list > to choose from. > > I am strongly opposed to this new proposal to only standardize the base > identity + loopback. > > Can you describe a scenario you are worried about? Vendors can do whateve= r > they want, but their proprietary identities will remain in their private > modules and namespaces, and will not pollute any global registry - becaus= e > there will be no such thing in the first place. > > The scenario is obvious -- the standard registry you propose is empty. Vendors have no standard values to choose from so they have to use their own proprietary values. > If there is (ever) a useful set of standard modules for real-world > interfaces, the same modules can also define a decent hierarchy of > identities in a step-by-step fashion. > No they can't. There are not going to be WGs formed to create YANG identities for each interface type any time soon, if ever. The main use-case given in the draft for the existence of this leaf is so other data can sparse-augment the interfaces table (e.g. augment when "if-type =3D foo"). The current set of enumerations may contains cruft, there may be extra classification objects needed (e.g. tunnels). So what. That is still better than nothing. Vendors still use their own identities for some interface types if the standard identities are insufficient. WGs can define new identities over time as needed as well. > Lada > > > > > Lada > > > > > Andy > > Andy > > > > > > > > Andy > > > > > > > > > > > > On Tue, Nov 5, 2013 at 10:43 AM, Martin Bjorklund > wrote: > > > Hi, > > > > > > David Kessens wrote: > > > > Since Benoit will be busy during this week, you will have until the > > > > end of > > > > this week if there is anything that escaped our attention that you > > > > believe > > > > needs more discussion. > > > > > > I think the latest discussion about the interface type in > > > draft-ietf-netmod-interfaces-cfg-12 ended in a consensus to change th= e > > > type from an enum to an identity. (the mail thread was actually > > > called "I-D Action: draft-ietf-netmod-ip-cfg-10.txt"). > > > > > > (Lada already changed the enums in the routing draft to identites) > > > > > > To be very concrete, here are the proposed changes: > > > > > > o Remove the document draft-ietf-netmod-iana-if-type-07 - it is not > > > needed anymore. > > > > > > o Change the leaf type from OLD: > > > > > > leaf type { > > > type ianaift:iana-if-type; > > > > > > to NEW: > > > > > > leaf type { > > > type identityref { > > > base interface-type; > > > } > > > > > > o Define the base identity, and define an identity for loopback > > > interfaces: > > > > > > identity interface-type { > > > description > > > "Base identity from which specific interface types are > > > derived."; > > > } > > > > > > identity loopback { > > > base if:interface-type; > > > description > > > "This interface type represents a loopback interface."; > > > } > > > > > > > > > o Update the examples to reflect this. > > > > > > > > > /martin > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > netmod mailing list > > > netmod@ietf.org > > > https://www.ietf.org/mailman/listinfo/netmod > > > > > > _______________________________________________ > > > netmod mailing list > > > netmod@ietf.org > > > https://www.ietf.org/mailman/listinfo/netmod > > > > -- > > Ladislav Lhotka, CZ.NIC Labs > > PGP Key ID: E74E8C0C > > > > > > > > > > > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > --047d7b6d9bba74694504ea754907 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable



On Tue, Nov 5, 2013 at 1:51 PM, Ladislav Lhotka &= lt;lhotka@nic.cz>= wrote:

On 05 Nov 2013, at 11:16, Andy Bierman <andy@yumaworks.com> wrote:

>
>
>
> On Tue, Nov 5, 2013 at 11:08 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
>
> On 05 Nov 2013, at 10:55, Andy Bierman <andy@yumaworks.com> wrote:
>
> > Hi,
> >
> > My concern over identityref has been that vendors will make up th= eir
> > own identities and even the enumerations that are currently usefu= l
> > will become proprietary.
> >
> > The proposal on the list was that the standard enums would of cou= rse be
> > replaced with standard identities. Now the proposal is to only > > standardize 'loopback' and vendors will make up the rest = on their own.
> > I do not think it is realistic that enum --> identity standard= ization will
> > happen in an ad-hoc fashion. =A0If this WG does not do it now, th= en it
> > is not going to happen. =A0Waiting years for the identities will = only make things worse
> > as vendor identities get deployed and become legacy baggage.
> > I think the enum draft needs to be rewritten to use identities. >
> I think it would be helpful to treat identities not as a way for class= ifying the universe, but rather in a very practical YANGish way: it is a ta= g that is mainly useful for conditional inclusion of certain data definitio= ns based on interface type or other identityref. Then it also makes a very = good sense to bundle the corresponding identity with said data definitions.=
>
>
> then throw out if-type and call it something else.
> I do not agree with this view of this leaf.
>
> If there is a high quality YANG module that vendors want to adopt, why= should they have a problem with using the standard identity - or making th= eir own identity derived from the standard one? And if there is no good sta= ndard model, vendors will write their proprietary models anyway, and standa= rdized interface type identities won=92t help.
>

The standard registry you propose = only =A0has 1 entry -- loopback.
I find it hard to believe this i= s the only enum from ifType that
is used in real products.

>
> There is no problem using the standard identity most appropriate to th= e interface type.
> This assumes there actually is a standard list of interface types. =A0= That was your original
> proposal. =A0Now that has changed and vendors will have no standard = =A0list to choose from.
> I am strongly opposed to this new proposal to only standardize the bas= e identity + loopback.

Can you describe a scenario you are worried about? Vendors can do whatever = they want, but their proprietary identities will remain in their private mo= dules and namespaces, and will not pollute any global registry - because th= ere will be no such thing in the first place.


The scenario is obvious -- the standar= d registry you propose is empty.
Vendors have no standard values = to choose from so they have to
use their own proprietary values.<= /div>

=A0
If there is (ever) a useful set of standard modules for real-world interfac= es, the same modules can also define a decent hierarchy of identities in a = step-by-step fashion.

No they can't= . =A0There are not going to be WGs formed to create YANG identities for
each interface type any time soon, if ever. The main use-case given in= the draft for the
existence of this leaf is so other data can sp= arse-augment the interfaces table
(e.g. augment when "if-typ= e =3D foo").=A0

The current set of enumerations may contains cruft, the= re may be extra classification
objects needed (e.g. tunnels). =A0= So what. That is still better than nothing. =A0Vendors still use
their own identities for some interface types if the standard identities ar= e insufficient.
WGs can define new identities over time as needed= as well.

=A0
Lada

>
> Lada
>
>


Andy
=A0<= /div>
> Andy
>
> >
> > Andy
> >
> >
> >
> > On Tue, Nov 5, 2013 at 10:43 AM, Martin Bjorklund <mbj@tail-f.com> wrote:
> > Hi,
> >
> > David Kessens <davi= d.kessens@gmail.com> wrote:
> > > Since Benoit will be busy during this week, you will have un= til the
> > > end of
> > > this week if there is anything that escaped our attention th= at you
> > > believe
> > > needs more discussion.
> >
> > I think the latest discussion about the interface type in
> > draft-ietf-netmod-interfaces-cfg-12 ended in a consensus to chang= e the
> > type from an enum to an identity. =A0(the mail thread was actuall= y
> > called "I-D Action: draft-ietf-netmod-ip-cfg-10.txt").<= br> > >
> > (Lada already changed the enums in the routing draft to identites= )
> >
> > To be very concrete, here are the proposed changes:
> >
> > o =A0Remove the document draft-ietf-netmod-iana-if-type-07 - it i= s not
> > =A0 =A0needed anymore.
> >
> > o =A0Change the leaf type from OLD:
> >
> > =A0 =A0 =A0 leaf type {
> > =A0 =A0 =A0 =A0 type ianaift:iana-if-type;
> >
> > =A0 =A0to NEW:
> >
> > =A0 =A0 =A0 leaf type {
> > =A0 =A0 =A0 =A0 type identityref {
> > =A0 =A0 =A0 =A0 =A0 base interface-type;
> > =A0 =A0 =A0 =A0 }
> >
> > o =A0Define the base identity, and define an identity for loopbac= k
> > =A0 =A0interfaces:
> >
> > =A0 identity interface-type {
> > =A0 =A0 description
> > =A0 =A0 =A0 "Base identity from which specific interface typ= es are
> > =A0 =A0 =A0 =A0derived.";
> > =A0 }
> >
> > =A0 identity loopback {
> > =A0 =A0 base if:interface-type;
> > =A0 =A0 description
> > =A0 =A0 =A0 "This interface type represents a loopback inter= face.";
> > =A0 }
> >
> >
> > o =A0Update the examples to reflect this.
> >
> >
> > /martin
> >
> >
> >
> >
> >
> >
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> >
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
>
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>
>
>
>
>

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





--047d7b6d9bba74694504ea754907-- From andy@yumaworks.com Tue Nov 5 14:23:24 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2200A11E81E1 for ; Tue, 5 Nov 2013 14:23:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.529 X-Spam-Level: X-Spam-Status: No, score=-2.529 tagged_above=-999 required=5 tests=[AWL=-0.153, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kwlyEraZ9J0v for ; Tue, 5 Nov 2013 14:23:17 -0800 (PST) Received: from mail-qe0-f42.google.com (mail-qe0-f42.google.com [209.85.128.42]) by ietfa.amsl.com (Postfix) with ESMTP id D290C11E8203 for ; Tue, 5 Nov 2013 14:23:14 -0800 (PST) Received: by mail-qe0-f42.google.com with SMTP id gc15so5512702qeb.29 for ; Tue, 05 Nov 2013 14:23:12 -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=KWhvG7ZowapDcCdZuwDbPCyv1vZJGoC5L1+O8I+RXFU=; b=IL/NmSDUB/OKLxEiqgI+TzI3PEvNGZixghsP+6Y9abldCwJqK1RTysfEPqUxDlq3jW J+zujT9dgyvhjslI+SkziFRZcLpQe39OG+An/0KzBX9kj+vWwfN1saeKs5c1rCCPdaEZ QcpXqA/P+BzY8InsWXjBEVCb2lUc02moXMUn4SfoR9PlxiH1WXNwWTdEIn+eLYFtAtRB PZ62nK7D+aDgj+Z/iyo7GX4M5Y8QqGG8EcektHMxg2q3mrQ5a6gDPHig5rKC8My/Uyii +DHtbHlyzsojAQ1w1JOnQ1orWWg0keD9iMA3GMA0amTsS9C/4q5nciwxb7IVPha3XNm0 9q+Q== X-Gm-Message-State: ALoCoQkqHimvB4sFttCNeZ91HggikrrGTyZ/ZkdKssu0DnzuQMFNeRgt3/PfZs4uH9DEqeF2Hq2X MIME-Version: 1.0 X-Received: by 10.224.131.133 with SMTP id x5mr1220606qas.70.1383690192577; Tue, 05 Nov 2013 14:23:12 -0800 (PST) Received: by 10.140.100.203 with HTTP; Tue, 5 Nov 2013 14:23:12 -0800 (PST) In-Reply-To: <93D2BC3A-7172-4384-A001-A96A3F9B9E49@nic.cz> References: <20131105.104338.346453015.mbj@tail-f.com> <20131105.133700.288191076.mbj@tail-f.com> <93D2BC3A-7172-4384-A001-A96A3F9B9E49@nic.cz> Date: Tue, 5 Nov 2013 14:23:12 -0800 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=001a11c2d386687a6004ea757a24 Cc: "netmod@ietf.org" Subject: Re: [netmod] Last chance for review: draft-ietf-netmod-ip-cfg & draft-ietf-netmod-ip-cfg X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 22:23:24 -0000 --001a11c2d386687a6004ea757a24 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Tue, Nov 5, 2013 at 2:03 PM, Ladislav Lhotka wrote: > > On 05 Nov 2013, at 13:37, Martin Bjorklund wrote: > > > Hi, > > > > Andy Bierman wrote: > >> Hi, > >> > >> My concern over identityref has been that vendors will make up their > >> own identities and even the enumerations that are currently useful > >> will become proprietary. > >> > >> The proposal on the list was that the standard enums would of course > >> be > >> replaced with standard identities. Now the proposal is to only > >> standardize 'loopback' and vendors will make up the rest on their own. > >> I do not think it is realistic that enum --> identity standardization > >> will > >> happen in an ad-hoc fashion. If this WG does not do it now, then it > >> is not going to happen. Waiting years for the identities will only > >> make > >> things worse > >> as vendor identities get deployed and become legacy baggage. > > > > Even if we make identities of the iana ifType registry, there are no > > standard configuration modules for these types. So vendors will make > > them, until something gets standardized. We can't do much about it, > > unless we wait until we have modelled everything before publishing... > > > > So I don't think there's much value in having these standard > > identities w/o accompanying modules. > > > > OTOH, I can accept this (i.e., create identities from the iana > > registry) as a way to move forward. > > Yes, as long as they won=92t be somehow mandatory to use. > > Agreed. SHOULD use most appropriate value . MAY use an alternate value if no appropriate standard value available. (MAY use 'other' as well?) Lada > Andy > > > > > > > > /martin > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > --001a11c2d386687a6004ea757a24 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable



On Tue, Nov 5, 2013 at 2:03 PM, Ladislav Lhotka &= lt;lhotka@nic.cz>= wrote:

On 05 Nov 2013, at 13:37, Martin Bjorklund <mbj@tail-f.com> wrote:

> Hi,
>
> Andy Bierman <andy@yumaworks.= com> wrote:
>> Hi,
>>
>> My concern over identityref has been that vendors will make up the= ir
>> own identities and even the enumerations that are currently useful=
>> will become proprietary.
>>
>> The proposal on the list was that the standard enums would of cour= se
>> be
>> replaced with standard identities. Now the proposal is to only
>> standardize 'loopback' and vendors will make up the rest o= n their own.
>> I do not think it is realistic that enum --> identity standardi= zation
>> will
>> happen in an ad-hoc fashion. =A0If this WG does not do it now, the= n it
>> is not going to happen. =A0Waiting years for the identities will o= nly
>> make
>> things worse
>> as vendor identities get deployed and become legacy baggage.
>
> Even if we make identities of the iana ifType registry, there are no > standard configuration modules for these types. =A0So vendors will mak= e
> them, until something gets standardized. =A0We can't do much about= it,
> unless we wait until we have modelled everything before publishing...<= br> >
> So I don't think there's much value in having these standard > identities w/o accompanying modules.
>
> OTOH, I can accept this (i.e., create identities from the iana
> registry) as a way to move forward.

Yes, as long as they won=92t be somehow mandatory to use.


Agreed. SHOULD use most appropriate va= lue .=A0
MAY use an alternate value if no appropriate standard va= lue available.
(MAY use 'other' as well?)



Lada

Andy
=A0


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

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





--001a11c2d386687a6004ea757a24-- From lhotka@nic.cz Tue Nov 5 14:33:49 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 582EF11E80E3 for ; Tue, 5 Nov 2013 14:33:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cjBgEZCGxVSq for ; Tue, 5 Nov 2013 14:33:48 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 2E05C11E81D6 for ; Tue, 5 Nov 2013 14:33:48 -0800 (PST) Received: from [172.16.33.134] (unknown [64.114.24.114]) by mail.nic.cz (Postfix) with ESMTPSA id 4E59B13F6A3; Tue, 5 Nov 2013 23:33:38 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1383690827; bh=rnbYT5oRMI0kWSfD2+kXJ4PLa3K5enLKHBcm1mwqNnM=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=kdv4BicsIwKDGH8kzddmibXaooeJ1xE/kZkgacVuWopoqiRJ9izzCcCfYQcYmj32B ZwOqM+lzTPx8aXvghdMNCldsQCB/nYMlWNdotYy0jL6koAYfqcBUBKpneweFC19TUK Iibnep1XbotAGRdyvmJU2YLTQFHNKTLL9ANYbyXE= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) From: Ladislav Lhotka In-Reply-To: Date: Tue, 5 Nov 2013 14:33:35 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20131105.104338.346453015.mbj@tail-f.com> <20131105.133700.288191076.mbj@tail-f.com> <93D2BC3A-7172-4384-A001-A96A3F9B9E49@nic.cz> To: Andy Bierman X-Mailer: Apple Mail (2.1816) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Cc: "netmod@ietf.org" Subject: Re: [netmod] Last chance for review: draft-ietf-netmod-ip-cfg & draft-ietf-netmod-ip-cfg X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 22:33:49 -0000 On 05 Nov 2013, at 14:23, Andy Bierman wrote: >=20 >=20 >=20 > On Tue, Nov 5, 2013 at 2:03 PM, Ladislav Lhotka wrote: >=20 > On 05 Nov 2013, at 13:37, Martin Bjorklund wrote: >=20 > > Hi, > > > > Andy Bierman wrote: > >> Hi, > >> > >> My concern over identityref has been that vendors will make up = their > >> own identities and even the enumerations that are currently useful > >> will become proprietary. > >> > >> The proposal on the list was that the standard enums would of = course > >> be > >> replaced with standard identities. Now the proposal is to only > >> standardize 'loopback' and vendors will make up the rest on their = own. > >> I do not think it is realistic that enum --> identity = standardization > >> will > >> happen in an ad-hoc fashion. If this WG does not do it now, then = it > >> is not going to happen. Waiting years for the identities will only > >> make > >> things worse > >> as vendor identities get deployed and become legacy baggage. > > > > Even if we make identities of the iana ifType registry, there are no > > standard configuration modules for these types. So vendors will = make > > them, until something gets standardized. We can't do much about it, > > unless we wait until we have modelled everything before = publishing... > > > > So I don't think there's much value in having these standard > > identities w/o accompanying modules. > > > > OTOH, I can accept this (i.e., create identities from the iana > > registry) as a way to move forward. >=20 > Yes, as long as they won=92t be somehow mandatory to use. >=20 >=20 > Agreed. SHOULD use most appropriate value .=20 > MAY use an alternate value if no appropriate standard value available. > (MAY use 'other' as well?) The perspective of having =93ethernetCsmacd=94 as the base identity for = all Ethernet interfaces makes me seriously sick. Lada >=20 >=20 >=20 > Lada >=20 > Andy > =20 >=20 >=20 > > > > > > /martin > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod >=20 > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C >=20 >=20 >=20 >=20 >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From mbj@tail-f.com Tue Nov 5 14:41:59 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 185F811E81A7 for ; Tue, 5 Nov 2013 14:41:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.946 X-Spam-Level: X-Spam-Status: No, score=-1.946 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y1orEMclOEhk for ; Tue, 5 Nov 2013 14:41:39 -0800 (PST) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 3B3DC11E8174 for ; Tue, 5 Nov 2013 14:41:39 -0800 (PST) Received: from localhost (dhcp-91f1.meeting.ietf.org [31.133.145.241]) by mail.tail-f.com (Postfix) with ESMTPSA id 9DC0F12000A5; Tue, 5 Nov 2013 23:41:37 +0100 (CET) Date: Tue, 05 Nov 2013 14:41:36 -0800 (PST) Message-Id: <20131105.144136.229513423.mbj@tail-f.com> To: lhotka@nic.cz 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] changes in the routing model X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 22:41:59 -0000 Hi, I have some comments on the recent changes: Ladislav Lhotka wrote: > o Introduced uint64 keys for state lists: routing-instance, rib, > route, nexthop. > > The idea is that an I2RS client creates an entry (e.g. a route) and > gets back a unique numeric handle that can be used later for referring > to that entry. Modelling these handles as keys of operational state > lists then seems quite natural. Based on the above, I understand that the route and nexthop lists have integer keys (they are actually uint32 in the model). But why do the 'routing-instance' and 'rib' need to have uint64 id as key in operational state? This just seems to make configuration complex - the user must find some numerical id in the operstate, then give the rib a name, and write the numerical id. Couldn't the name be key in both config and state, and if a numerical id is needed in oper state it could be a normal (unique) leaf? If the current design is kept, what is the 'id' of a user-controlled entry? I assume it is not needed, and if so this should be made clear in the description. ----------- s/A routing instance together with its operational status is/ A routing instance together with its operational state is/ ----------- In 5.4.1: Every routing instance MUST implement exactly one instance of the "direct" pseudo-protocol type. The name of this instance MUST also be "direct". Why does this name have to be "direct"? I think this should be explained, b/c now if seems arbitrary. ------------ Editorial nit: your yin2yang script adds (or doesn't strip) empty lines in some cases: description "Return the current number of routes in a RIB. If the RIB with 'id' equal to 'rib-id' doesn't exist, then this operation SHALL fail with error-tag 'data-missing' and error-app-tag 'rib-not-found'. "; /martin From lhotka@nic.cz Tue Nov 5 15:54:45 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B83B11E8125 for ; Tue, 5 Nov 2013 15:54:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.849 X-Spam-Level: X-Spam-Status: No, score=-1.849 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u4fp0k1Yycip for ; Tue, 5 Nov 2013 15:54:44 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 6815811E80F7 for ; Tue, 5 Nov 2013 15:54:44 -0800 (PST) Received: from [172.16.33.134] (unknown [64.114.24.114]) by mail.nic.cz (Postfix) with ESMTPSA id 3182013FA60; Wed, 6 Nov 2013 00:54:41 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1383695683; bh=/G9mxlhuAaZQrZ0QXuSmEMdOIh2t36B8t6Q6Kn6zHPQ=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=ALpI2bLnTMCI4JOSW9NY786QN4hasOMQ+se+WVScAKFY57pyATctGl2MfPElm1Q3K gvcd/wF1mMxVGEcP2SIzNC7d9khjp4W4G6vGsW0t/GfgVZLdEo2zpXPMP6/sZp2rM7 qvNd5OcFx0H6rcScxnbeJyjhzmG/904wTQDYXBsw= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) From: Ladislav Lhotka In-Reply-To: <20131105.144136.229513423.mbj@tail-f.com> Date: Tue, 5 Nov 2013 15:54:35 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <38157C1E-B041-45F9-94F2-1886BB66F31E@nic.cz> References: <20131105.144136.229513423.mbj@tail-f.com> To: =?windows-1252?Q?Martin_Bj=F6rklund?= X-Mailer: Apple Mail (2.1816) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] changes in the routing model X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 23:54:45 -0000 On 05 Nov 2013, at 14:41, Martin Bjorklund wrote: > Hi, >=20 > I have some comments on the recent changes: >=20 > Ladislav Lhotka wrote: >> o Introduced uint64 keys for state lists: routing-instance, rib, >> route, nexthop. >>=20 >> The idea is that an I2RS client creates an entry (e.g. a route) and >> gets back a unique numeric handle that can be used later for = referring >> to that entry. Modelling these handles as keys of operational state >> lists then seems quite natural. >=20 > Based on the above, I understand that the route and nexthop lists have > integer keys (they are actually uint32 in the model). But why do the Actually they are all uint64. I2RS guys insisted on numeric handles = because they will be sent back and forth in their messages. > 'routing-instance' and 'rib' need to have uint64 id as key in > operational state? This just seems to make configuration complex - > the user must find some numerical id in the operstate, then give the > rib a name, and write the numerical id. Couldn't the name be key in > both config and state, and if a numerical id is needed in oper state > it could be a normal (unique) leaf? I think it is better to have distinct keys in config and state lists. = The keys of system-controlled entries in operational state need not be = persistent, and should they change after reboot, they couldn=92t be = updated in config if they are keys there as well. Note that a = system-controlled entry (from the NECONF POV) can also be injected by an = I2RS agent. The user also has to care only about uniqueness of keys that he himself = assigned to config entries. =20 >=20 > If the current design is kept, what is the 'id' of a user-controlled > entry? I assume it is not needed, and if so this should be made clear > in the description. The user creates the entry in config with an arbitrary name, and if the = system accepts the entry, it will assign it a unique =93id", and both = =93name" and =93id" appears in operational state. Lada >=20 >=20 > ----------- >=20 >=20 > s/A routing instance together with its operational status is/ > A routing instance together with its operational state is/ >=20 >=20 > ----------- >=20 > In 5.4.1: >=20 > Every routing instance MUST implement exactly one instance of the > "direct" pseudo-protocol type. The name of this instance MUST also > be "direct". >=20 > Why does this name have to be "direct"? I think this should be > explained, b/c now if seems arbitrary. >=20 >=20 > ------------ >=20 > Editorial nit: your yin2yang script adds (or doesn't strip) empty > lines in some cases: >=20 > description > "Return the current number of routes in a RIB. >=20 > If the RIB with 'id' equal to 'rib-id' doesn't exist, then > this operation SHALL fail with error-tag 'data-missing' and > error-app-tag 'rib-not-found'. > "; >=20 >=20 > /martin -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From david.kessens@gmail.com Tue Nov 5 16:04:10 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 568E111E815E for ; Tue, 5 Nov 2013 16:04:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zz2G8NaxPWvy for ; Tue, 5 Nov 2013 16:04:09 -0800 (PST) Received: from mail-la0-x230.google.com (mail-la0-x230.google.com [IPv6:2a00:1450:4010:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id F173E11E8125 for ; Tue, 5 Nov 2013 16:04:08 -0800 (PST) Received: by mail-la0-f48.google.com with SMTP id ec20so3279793lab.35 for ; Tue, 05 Nov 2013 16:04:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=w8E+xAdjCLuydgdXZHAngONQq/bJ6zkFBo15yzLofAw=; b=gizwWN7qmGCQSWl3Hto7F9tjIlWNUCPQI+QEyjEoSmdXfVU4kpL2NJiPIWV+Fwx3t+ uPC8ixxptwDbmAEGsd+0l948BlP5848Q0C98dN1ZQKHn3qltim0yW6JfhqPZicsbHbXC hCLjWEIwKXR0lijPUvoQaOd3QK/ASZUCE0pOh8D3Uf9ePW0NBhuww6MWIxxq3xfxZ/wP 7gDWuXY3wbGyVF59+55mtnerNx83/8B1oyNYuxnS4rjjsuNKmK3bUDfZgGn56eKwbr6B 6oWdkDDxbRzgYA40pb+WfBib0cTFfHjOEqRKH5yTtBxafgbbto/dE4RYqVni76fVD9Se oc+A== MIME-Version: 1.0 X-Received: by 10.152.88.3 with SMTP id bc3mr179827lab.4.1383696247842; Tue, 05 Nov 2013 16:04:07 -0800 (PST) Received: by 10.152.170.170 with HTTP; Tue, 5 Nov 2013 16:04:07 -0800 (PST) In-Reply-To: <20131105.104338.346453015.mbj@tail-f.com> References: <20131105.104338.346453015.mbj@tail-f.com> Date: Tue, 5 Nov 2013 16:04:07 -0800 Message-ID: From: David Kessens To: andy@yumaworks.com Content-Type: multipart/alternative; boundary=001a11c355dc546b9904ea76e313 Cc: netmod@ietf.org Subject: Re: [netmod] Last chance for review: draft-ietf-netmod-ip-cfg & draft-ietf-netmod-ip-cfg X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 00:04:10 -0000 --001a11c355dc546b9904ea76e313 Content-Type: text/plain; charset=ISO-8859-1 All, Andy, It is really getting time to get these documents published. The goal is "good enough". The goal is not perfection. We now have one concrete proposal for change from Martin. We can either adopt it or stay with the original. At this point disagreeing is not good enough, we need an alternative with text that can be disscussed, or make it clear that you prefer the current version without changes. David Kessens --- On Tue, Nov 5, 2013 at 10:43 AM, Martin Bjorklund wrote: > Hi, > > David Kessens wrote: > > Since Benoit will be busy during this week, you will have until the > > end of > > this week if there is anything that escaped our attention that you > > believe > > needs more discussion. > > I think the latest discussion about the interface type in > draft-ietf-netmod-interfaces-cfg-12 ended in a consensus to change the > type from an enum to an identity. (the mail thread was actually > called "I-D Action: draft-ietf-netmod-ip-cfg-10.txt"). > > (Lada already changed the enums in the routing draft to identites) > > To be very concrete, here are the proposed changes: > > o Remove the document draft-ietf-netmod-iana-if-type-07 - it is not > needed anymore. > > o Change the leaf type from OLD: > > leaf type { > type ianaift:iana-if-type; > > to NEW: > > leaf type { > type identityref { > base interface-type; > } > > o Define the base identity, and define an identity for loopback > interfaces: > > identity interface-type { > description > "Base identity from which specific interface types are > derived."; > } > > identity loopback { > base if:interface-type; > description > "This interface type represents a loopback interface."; > } > > > o Update the examples to reflect this. > > > /martin > > > > > > > -- David Kessens --- --001a11c355dc546b9904ea76e313 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
All, Andy,

It is really getting time to get these documents published. The goal is &qu= ot;good enough". The goal is not perfection.

We now have one concrete proposal for change from Martin.

We c= an either adopt it or stay with the original.

At this po= int disagreeing is not good enough, we need an alternative with text that c= an be disscussed, or make it clear that you prefer the current version with= out changes.

David Kessens
---




On Tue, Nov 5, 201= 3 at 10:43 AM, Martin Bjorklund <mbj@tail-f.com> wrote:
Hi,

David Kessens <david.kessens@= gmail.com> wrote:
> Since Benoit will be busy during this week, you will have until the > end of
> this week if there is anything that escaped our attention that you
> believe
> needs more discussion.

I think the latest discussion about the interface type in
draft-ietf-netmod-interfaces-cfg-12 ended in a consensus to change the
type from an enum to an identity. =A0(the mail thread was actually
called "I-D Action: draft-ietf-netmod-ip-cfg-10.txt").

(Lada already changed the enums in the routing draft to identites)

To be very concrete, here are the proposed changes:

o =A0Remove the document draft-ietf-netmod-iana-if-type-07 - it is not
=A0 =A0needed anymore.

o =A0Change the leaf type from OLD:

=A0 =A0 =A0 leaf type {
=A0 =A0 =A0 =A0 type ianaift:iana-if-type;

=A0 =A0to NEW:

=A0 =A0 =A0 leaf type {
=A0 =A0 =A0 =A0 type identityref {
=A0 =A0 =A0 =A0 =A0 base interface-type;
=A0 =A0 =A0 =A0 }

o =A0Define the base identity, and define an identity for loopback
=A0 =A0interfaces:

=A0 identity interface-type {
=A0 =A0 description
=A0 =A0 =A0 "Base identity from which specific interface types are
=A0 =A0 =A0 =A0derived.";
=A0 }

=A0 identity loopback {
=A0 =A0 base if:interface-type;
=A0 =A0 description
=A0 =A0 =A0 "This interface type represents a loopback interface."= ;;
=A0 }


o =A0Update the examples to reflect this.


/martin









--

David Kessens
---
--001a11c355dc546b9904ea76e313-- From andy@yumaworks.com Tue Nov 5 16:29:02 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1604B11E818C for ; Tue, 5 Nov 2013 16:29:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.826 X-Spam-Level: X-Spam-Status: No, score=-2.826 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xp6SdbXVHbtQ for ; Tue, 5 Nov 2013 16:28:57 -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 C139511E8163 for ; Tue, 5 Nov 2013 16:28:56 -0800 (PST) Received: by mail-qc0-f177.google.com with SMTP id u18so5280206qcx.22 for ; Tue, 05 Nov 2013 16:28: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:cc:content-type; bh=PoHbXv7D/BBDUubF4ZXpNG64cdI/fyCoR0OvqZRPFB4=; b=SHIXteUpR/xAggCicdojmLctKYUS/+H+54wXbKpvg0lFkGXs+YbQJLLhDV8srrUFMw XuLObt21YpXvmfFzrLu4Mcv4sEJ9KPAV+g5eiSnD4St30uXdnGxWFB/SxkchDTqWZHY/ G8h58vMB1WxLlzE5Jhb2wrgcYS4prbnsGJR8daIvv6sRr2tD+W24fcfjKebaxQ9MO/fb lluyXhMHO7fe6BEt0PEm1Wcz6az78gXzEhV0xJU56Sn5kuLX6Vt82ZFvBD+UFhzs9/B6 JrmBkCffZfisvAKVzucXn/HWFUX+1dx/CJqrh5NrCTlHyWDiPEURDZeNUMtCq2YDteyp CQfQ== X-Gm-Message-State: ALoCoQlvk54ROnix+Ih9GMj6hocVbH6lH0yeHSAgKXacmB9LncuWLcqDZAgJVPl8lPE8XbMahSoE MIME-Version: 1.0 X-Received: by 10.224.127.193 with SMTP id h1mr2062250qas.82.1383697736209; Tue, 05 Nov 2013 16:28:56 -0800 (PST) Received: by 10.140.100.203 with HTTP; Tue, 5 Nov 2013 16:28:56 -0800 (PST) In-Reply-To: References: <20131105.104338.346453015.mbj@tail-f.com> Date: Tue, 5 Nov 2013 16:28:56 -0800 Message-ID: From: Andy Bierman To: David Kessens Content-Type: multipart/alternative; boundary=001a1132ebe20b305904ea773cd5 Cc: "netmod@ietf.org" Subject: Re: [netmod] Last chance for review: draft-ietf-netmod-ip-cfg & draft-ietf-netmod-ip-cfg X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 00:29:02 -0000 --001a1132ebe20b305904ea773cd5 Content-Type: text/plain; charset=ISO-8859-1 Hi, The concrete proposal I agreed to on the list was to change the if-type enums to identities. If you want me to do the emacs search-and-replace to convert the enums to identities I can do that. I am not suggesting that the values in the registry be re-engineered at all. The new proposal to remove all standard interface types except 'loopback' is not acceptable. Andy On Tue, Nov 5, 2013 at 4:04 PM, David Kessens wrote: > All, Andy, > > It is really getting time to get these documents published. The goal is > "good enough". The goal is not perfection. > > We now have one concrete proposal for change from Martin. > > We can either adopt it or stay with the original. > > At this point disagreeing is not good enough, we need an alternative with > text that can be disscussed, or make it clear that you prefer the current > version without changes. > > David Kessens > --- > > > > > On Tue, Nov 5, 2013 at 10:43 AM, Martin Bjorklund wrote: > >> Hi, >> >> David Kessens wrote: >> > Since Benoit will be busy during this week, you will have until the >> > end of >> > this week if there is anything that escaped our attention that you >> > believe >> > needs more discussion. >> >> I think the latest discussion about the interface type in >> draft-ietf-netmod-interfaces-cfg-12 ended in a consensus to change the >> type from an enum to an identity. (the mail thread was actually >> called "I-D Action: draft-ietf-netmod-ip-cfg-10.txt"). >> >> (Lada already changed the enums in the routing draft to identites) >> >> To be very concrete, here are the proposed changes: >> >> o Remove the document draft-ietf-netmod-iana-if-type-07 - it is not >> needed anymore. >> >> o Change the leaf type from OLD: >> >> leaf type { >> type ianaift:iana-if-type; >> >> to NEW: >> >> leaf type { >> type identityref { >> base interface-type; >> } >> >> o Define the base identity, and define an identity for loopback >> interfaces: >> >> identity interface-type { >> description >> "Base identity from which specific interface types are >> derived."; >> } >> >> identity loopback { >> base if:interface-type; >> description >> "This interface type represents a loopback interface."; >> } >> >> >> o Update the examples to reflect this. >> >> >> /martin >> >> >> >> >> >> >> > > > -- > > David Kessens > --- > --001a1132ebe20b305904ea773cd5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

The concrete proposal I agreed to on the list was to change the
= if-type enums to identities. =A0If you want me to do the emacs search-and-r= eplace
to convert the enums to identities I can do that. =A0I am not suggest= ing
that the values in the registry be re-engineered at all.

The new proposal to remove all standard interface types except 'loopbac= k' is not acceptable.


Andy


On Tue, Nov 5, 2013 at 4:04 PM, David Kessens <david.kessens@gmail.com> wrote:
All, An= dy,

It is really getting time to get these documents published. The goal is &qu= ot;good enough". The goal is not perfection.

We now have one concrete proposal for change from Martin.

We c= an either adopt it or stay with the original.

At this po= int disagreeing is not good enough, we need an alternative with text that c= an be disscussed, or make it clear that you prefer the current version with= out changes.

David Kessens
---




On Tue, Nov 5, 201= 3 at 10:43 AM, Martin Bjorklund <mbj@tail-f.com> wrote:
Hi,

David Kessens <david.kessens@gmail.com> wrote:
> Since Benoit will be busy during this week, you will have until the > end of
> this week if there is anything that escaped our attention that you
> believe
> needs more discussion.

I think the latest discussion about the interface type in
draft-ietf-netmod-interfaces-cfg-12 ended in a consensus to change the
type from an enum to an identity. =A0(the mail thread was actually
called "I-D Action: draft-ietf-netmod-ip-cfg-10.txt").

(Lada already changed the enums in the routing draft to identites)

To be very concrete, here are the proposed changes:

o =A0Remove the document draft-ietf-netmod-iana-if-type-07 - it is not
=A0 =A0needed anymore.

o =A0Change the leaf type from OLD:

=A0 =A0 =A0 leaf type {
=A0 =A0 =A0 =A0 type ianaift:iana-if-type;

=A0 =A0to NEW:

=A0 =A0 =A0 leaf type {
=A0 =A0 =A0 =A0 type identityref {
=A0 =A0 =A0 =A0 =A0 base interface-type;
=A0 =A0 =A0 =A0 }

o =A0Define the base identity, and define an identity for loopback
=A0 =A0interfaces:

=A0 identity interface-type {
=A0 =A0 description
=A0 =A0 =A0 "Base identity from which specific interface types are
=A0 =A0 =A0 =A0derived.";
=A0 }

=A0 identity loopback {
=A0 =A0 base if:interface-type;
=A0 =A0 description
=A0 =A0 =A0 "This interface type represents a loopback interface."= ;;
=A0 }


o =A0Update the examples to reflect this.


/martin









--

David Kessens
---

--001a1132ebe20b305904ea773cd5-- From internet-drafts@ietf.org Tue Nov 5 16:31:00 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1F5D11E81D0; Tue, 5 Nov 2013 16:31:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.57 X-Spam-Level: X-Spam-Status: No, score=-102.57 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nar-zxgGcK7S; Tue, 5 Nov 2013 16:30:59 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C855F21F9EA2; Tue, 5 Nov 2013 16:30:56 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.82 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131106003056.29508.47493.idtracker@ietfa.amsl.com> Date: Tue, 05 Nov 2013 16:30:56 -0800 Cc: netmod@ietf.org Subject: [netmod] I-D Action: draft-ietf-netmod-snmp-cfg-03.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 00:31:01 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the NETCONF Data Modeling Language Working Gr= oup of the IETF. Title : A YANG Data Model for SNMP Configuration Author(s) : Martin Bjorklund Juergen Schoenwaelder Filename : draft-ietf-netmod-snmp-cfg-03.txt Pages : 84 Date : 2013-11-05 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-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netmod-snmp-cfg-03 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 lhotka@nic.cz Tue Nov 5 16:35:53 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB0B121F9C05 for ; Tue, 5 Nov 2013 16:35:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.547 X-Spam-Level: X-Spam-Status: No, score=-1.547 tagged_above=-999 required=5 tests=[AWL=0.452, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9vQ+ZRV3zTPL for ; Tue, 5 Nov 2013 16:35:53 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id C75ED21E80E2 for ; Tue, 5 Nov 2013 16:35:35 -0800 (PST) Received: from dhcp-a49d.meeting.ietf.org (dhcp-a49d.meeting.ietf.org [31.133.164.157]) by mail.nic.cz (Postfix) with ESMTPSA id 7E5E013FA60; Wed, 6 Nov 2013 01:35:31 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1383698133; bh=mozZcyqan9RuhM4qHxZAR0AsMPMjUtwSF4K+BsRvkWo=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=ruzwoLEL/Vhe8T6WZMh2UNVkY6/XKpwRTB1IVXAUagB7kqn9Irha2iLR5vMMSol6j 7OB1A9LXzsoKrCgFas2lQgSxJaQZJiAF1pfaVSih7vvwNJ/LP3glVfWsCCbcS6XwGo VG3jSc9aFc2u/JS6TV6sQOXl5G1VdMHL6oa5PhSI= Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) From: Ladislav Lhotka In-Reply-To: Date: Tue, 5 Nov 2013 16:35:27 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <00C11A98-1758-48A4-8182-38E0F8F31C79@nic.cz> References: <20131105.104338.346453015.mbj@tail-f.com> To: Andy Bierman X-Mailer: Apple Mail (2.1816) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Cc: "netmod@ietf.org" Subject: Re: [netmod] Last chance for review: draft-ietf-netmod-ip-cfg & draft-ietf-netmod-ip-cfg X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 00:35:53 -0000 On 05 Nov 2013, at 16:28, Andy Bierman wrote: > Hi, >=20 > The concrete proposal I agreed to on the list was to change the > if-type enums to identities. If you want me to do the emacs = search-and-replace > to convert the enums to identities I can do that. I am not suggesting > that the values in the registry be re-engineered at all. It is not that simple - I assume you want to keep these identities = synchronised with the IANA enumeration, right? Lada >=20 > The new proposal to remove all standard interface types except = 'loopback' is not acceptable. >=20 >=20 > Andy >=20 >=20 > On Tue, Nov 5, 2013 at 4:04 PM, David Kessens = wrote: > All, Andy, >=20 > It is really getting time to get these documents published. The goal = is "good enough". The goal is not perfection.=20 >=20 > We now have one concrete proposal for change from Martin. >=20 > We can either adopt it or stay with the original. >=20 > At this point disagreeing is not good enough, we need an alternative = with text that can be disscussed, or make it clear that you prefer the = current version without changes. >=20 > David Kessens > --- >=20 >=20 >=20 >=20 > On Tue, Nov 5, 2013 at 10:43 AM, Martin Bjorklund = wrote: > Hi, >=20 > David Kessens wrote: > > Since Benoit will be busy during this week, you will have until the > > end of > > this week if there is anything that escaped our attention that you > > believe > > needs more discussion. >=20 > I think the latest discussion about the interface type in > draft-ietf-netmod-interfaces-cfg-12 ended in a consensus to change the > type from an enum to an identity. (the mail thread was actually > called "I-D Action: draft-ietf-netmod-ip-cfg-10.txt"). >=20 > (Lada already changed the enums in the routing draft to identites) >=20 > To be very concrete, here are the proposed changes: >=20 > o Remove the document draft-ietf-netmod-iana-if-type-07 - it is not > needed anymore. >=20 > o Change the leaf type from OLD: >=20 > leaf type { > type ianaift:iana-if-type; >=20 > to NEW: >=20 > leaf type { > type identityref { > base interface-type; > } >=20 > o Define the base identity, and define an identity for loopback > interfaces: >=20 > identity interface-type { > description > "Base identity from which specific interface types are > derived."; > } >=20 > identity loopback { > base if:interface-type; > description > "This interface type represents a loopback interface."; > } >=20 >=20 > o Update the examples to reflect this. >=20 >=20 > /martin >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > --=20 >=20 > David Kessens > --- >=20 > _______________________________________________ > 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 Nov 5 16:42:10 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57ACB11E818C for ; Tue, 5 Nov 2013 16:42:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.971 X-Spam-Level: X-Spam-Status: No, score=-1.971 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hv0lsGOiIgno for ; Tue, 5 Nov 2013 16:42:04 -0800 (PST) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 113DB11E8174 for ; Tue, 5 Nov 2013 16:42:02 -0800 (PST) Received: from localhost (dhcp-a398.meeting.ietf.org [31.133.163.152]) by mail.tail-f.com (Postfix) with ESMTPSA id 02E1112000A5; Wed, 6 Nov 2013 01:41:59 +0100 (CET) Date: Tue, 05 Nov 2013 16:41:56 -0800 (PST) Message-Id: <20131105.164156.397349935.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: <00C11A98-1758-48A4-8182-38E0F8F31C79@nic.cz> References: <00C11A98-1758-48A4-8182-38E0F8F31C79@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] Last chance for review: draft-ietf-netmod-ip-cfg & draft-ietf-netmod-ip-cfg X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 00:42:10 -0000 Ladislav Lhotka wrote: > > On 05 Nov 2013, at 16:28, Andy Bierman wrote: > > > Hi, > > > > The concrete proposal I agreed to on the list was to change the > > if-type enums to identities. If you want me to do the emacs > > search-and-replace > > to convert the enums to identities I can do that. I am not suggesting > > that the values in the registry be re-engineered at all. > > It is not that simple - I assume you want to keep these identities > synchronised with the IANA enumeration, right? I understand the edits Andy wants, and the IANA draft already instructs IANA to keep the YANG module in sync with the registry. So I think what Andy suggests is easy to do (in the documents). /martin From andy@yumaworks.com Tue Nov 5 16:42:50 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64E2C11E81E9 for ; Tue, 5 Nov 2013 16:42:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.529 X-Spam-Level: X-Spam-Status: No, score=-2.529 tagged_above=-999 required=5 tests=[AWL=-0.153, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5UZtqeBHD10i for ; Tue, 5 Nov 2013 16:42:46 -0800 (PST) Received: from mail-qa0-f52.google.com (mail-qa0-f52.google.com [209.85.216.52]) by ietfa.amsl.com (Postfix) with ESMTP id 3DFC211E81E1 for ; Tue, 5 Nov 2013 16:42:44 -0800 (PST) Received: by mail-qa0-f52.google.com with SMTP id ii20so1039850qab.18 for ; Tue, 05 Nov 2013 16:42:43 -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=CEDGYroVT4z3zoxv0Wfq+dKg2NRpA95nVl/fiLGL5BE=; b=k3UqxpYNipSAe2CKNZ09OJ68FQWDDn/fQnILBQgi/bDeeoOqlKUMpIALlbwVZhbW16 WwQdTNhhxGMB7Q0dBlHsBrwahnYyf/mevVYRmWm2AmgiZDyyKmF4zK+X1t746MilVDhl CXOWCax2EzzicYhu3sCdikGllFYxEOZScLWbz6qOKdMnXii+rlWn13/3ROfgaXE5/Qnf FrMg3NlXe4ezSoynUVCU5VXk29xWRKAHqaw5pL7wwsu37yMSTDd+wBCjGFJ2kKAbTpT8 crw12uTTGNB97r4l5ZpuOqbk5WAVnjIQYq8pZCCx9nqT+i5goCdSC528R7QPpIQDdvPu YONw== X-Gm-Message-State: ALoCoQlvnOfOsUlFDDt0khM3EqOJCrsKxUJeJvUxqIOXef6VL8It0uQ3MwQc+FkI+OSXwD3RGIac MIME-Version: 1.0 X-Received: by 10.224.111.197 with SMTP id t5mr1971597qap.49.1383698563641; Tue, 05 Nov 2013 16:42:43 -0800 (PST) Received: by 10.140.100.203 with HTTP; Tue, 5 Nov 2013 16:42:43 -0800 (PST) In-Reply-To: <00C11A98-1758-48A4-8182-38E0F8F31C79@nic.cz> References: <20131105.104338.346453015.mbj@tail-f.com> <00C11A98-1758-48A4-8182-38E0F8F31C79@nic.cz> Date: Tue, 5 Nov 2013 16:42:43 -0800 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=001a11c28df25cbfbc04ea776d5c Cc: "netmod@ietf.org" Subject: Re: [netmod] Last chance for review: draft-ietf-netmod-ip-cfg & draft-ietf-netmod-ip-cfg X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 00:42:50 -0000 --001a11c28df25cbfbc04ea776d5c Content-Type: text/plain; charset=ISO-8859-1 On Tue, Nov 5, 2013 at 4:35 PM, Ladislav Lhotka wrote: > > On 05 Nov 2013, at 16:28, Andy Bierman wrote: > > > Hi, > > > > The concrete proposal I agreed to on the list was to change the > > if-type enums to identities. If you want me to do the emacs > search-and-replace > > to convert the enums to identities I can do that. I am not suggesting > > that the values in the registry be re-engineered at all. > > It is not that simple - I assume you want to keep these identities > synchronised with the IANA enumeration, right? > > This issue was obviously part of the problem space whether the type was enumeration or identity. The RFC can be updated every couple years as needed. The IANA registry is the normative list, not this YANG module. > Lada > Andy > > > > > The new proposal to remove all standard interface types except > 'loopback' is not acceptable. > > > > > > Andy > > > > > > On Tue, Nov 5, 2013 at 4:04 PM, David Kessens > wrote: > > All, Andy, > > > > It is really getting time to get these documents published. The goal is > "good enough". The goal is not perfection. > > > > We now have one concrete proposal for change from Martin. > > > > We can either adopt it or stay with the original. > > > > At this point disagreeing is not good enough, we need an alternative > with text that can be disscussed, or make it clear that you prefer the > current version without changes. > > > > David Kessens > > --- > > > > > > > > > > On Tue, Nov 5, 2013 at 10:43 AM, Martin Bjorklund > wrote: > > Hi, > > > > David Kessens wrote: > > > Since Benoit will be busy during this week, you will have until the > > > end of > > > this week if there is anything that escaped our attention that you > > > believe > > > needs more discussion. > > > > I think the latest discussion about the interface type in > > draft-ietf-netmod-interfaces-cfg-12 ended in a consensus to change the > > type from an enum to an identity. (the mail thread was actually > > called "I-D Action: draft-ietf-netmod-ip-cfg-10.txt"). > > > > (Lada already changed the enums in the routing draft to identites) > > > > To be very concrete, here are the proposed changes: > > > > o Remove the document draft-ietf-netmod-iana-if-type-07 - it is not > > needed anymore. > > > > o Change the leaf type from OLD: > > > > leaf type { > > type ianaift:iana-if-type; > > > > to NEW: > > > > leaf type { > > type identityref { > > base interface-type; > > } > > > > o Define the base identity, and define an identity for loopback > > interfaces: > > > > identity interface-type { > > description > > "Base identity from which specific interface types are > > derived."; > > } > > > > identity loopback { > > base if:interface-type; > > description > > "This interface type represents a loopback interface."; > > } > > > > > > o Update the examples to reflect this. > > > > > > /martin > > > > > > > > > > > > > > > > > > > > -- > > > > David Kessens > > --- > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > --001a11c28df25cbfbc04ea776d5c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Tue, Nov 5, 2013 at 4:35 PM, Ladislav Lhotka &= lt;lhotka@nic.cz>= wrote:

On 05 Nov 2013, at 16:28, Andy Bierman <andy@yumaworks.com> wrote:

> Hi,
>
> The concrete proposal I agreed to on the list was to change the
> if-type enums to identities. =A0If you want me to do the emacs search-= and-replace
> to convert the enums to identities I can do that. =A0I am not suggesti= ng
> that the values in the registry be re-engineered at all.

It is not that simple - I assume you want to keep these identities synchron= ised with the IANA enumeration, right?


This issue was obviously part of the p= roblem space whether the type
was enumeration or identity. =A0The= RFC can be updated every couple years
as needed. The IANA regist= ry is the normative list, not this YANG module.

=A0
Lada

Andy
=A0

>
> The new proposal to remove all standard interface types except 'lo= opback' is not acceptable.
>
>
> Andy
>
>
> On Tue, Nov 5, 2013 at 4:04 PM, David Kessens <david.kessens@gmail.com> wrote:
> All, Andy,
>
> It is really getting time to get these documents published. The goal i= s "good enough". The goal is not perfection.
>
> We now have one concrete proposal for change from Martin.
>
> We can either adopt it or stay with the original.
>
> At this point disagreeing is not good enough, we need an alternative w= ith text that can be disscussed, or make it clear that you prefer the curre= nt version without changes.
>
> David Kessens
> ---
>
>
>
>
> On Tue, Nov 5, 2013 at 10:43 AM, Martin Bjorklund <mbj@tail-f.com> wrote:
> Hi,
>
> David Kessens <david.kes= sens@gmail.com> wrote:
> > Since Benoit will be busy during this week, you will have until t= he
> > end of
> > this week if there is anything that escaped our attention that yo= u
> > believe
> > needs more discussion.
>
> I think the latest discussion about the interface type in
> draft-ietf-netmod-interfaces-cfg-12 ended in a consensus to change the=
> type from an enum to an identity. =A0(the mail thread was actually
> called "I-D Action: draft-ietf-netmod-ip-cfg-10.txt").
>
> (Lada already changed the enums in the routing draft to identites)
>
> To be very concrete, here are the proposed changes:
>
> o =A0Remove the document draft-ietf-netmod-iana-if-type-07 - it is not=
> =A0 =A0needed anymore.
>
> o =A0Change the leaf type from OLD:
>
> =A0 =A0 =A0 leaf type {
> =A0 =A0 =A0 =A0 type ianaift:iana-if-type;
>
> =A0 =A0to NEW:
>
> =A0 =A0 =A0 leaf type {
> =A0 =A0 =A0 =A0 type identityref {
> =A0 =A0 =A0 =A0 =A0 base interface-type;
> =A0 =A0 =A0 =A0 }
>
> o =A0Define the base identity, and define an identity for loopback
> =A0 =A0interfaces:
>
> =A0 identity interface-type {
> =A0 =A0 description
> =A0 =A0 =A0 "Base identity from which specific interface types ar= e
> =A0 =A0 =A0 =A0derived.";
> =A0 }
>
> =A0 identity loopback {
> =A0 =A0 base if:interface-type;
> =A0 =A0 description
> =A0 =A0 =A0 "This interface type represents a loopback interface.= ";
> =A0 }
>
>
> o =A0Update the examples to reflect this.
>
>
> /martin
>
>
>
>
>
>
>
>
>
> --
>
> David Kessens
> ---
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

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





--001a11c28df25cbfbc04ea776d5c-- From mbj@tail-f.com Tue Nov 5 16:49:34 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC78021E808F for ; Tue, 5 Nov 2013 16:49:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.11 X-Spam-Level: X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[AWL=-0.817, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, MIME_BASE64_TEXT=1.753] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vVLkV7wvbN0i for ; Tue, 5 Nov 2013 16:49:29 -0800 (PST) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id E7E4D11E8163 for ; Tue, 5 Nov 2013 16:49:28 -0800 (PST) Received: from localhost (dhcp-a398.meeting.ietf.org [31.133.163.152]) by mail.tail-f.com (Postfix) with ESMTPSA id 8EE5512000A5; Wed, 6 Nov 2013 01:49:27 +0100 (CET) Date: Tue, 05 Nov 2013 16:49:25 -0800 (PST) Message-Id: <20131105.164925.309135527.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: <38157C1E-B041-45F9-94F2-1886BB66F31E@nic.cz> References: <20131105.144136.229513423.mbj@tail-f.com> <38157C1E-B041-45F9-94F2-1886BB66F31E@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=iso-8859-7 Content-Transfer-Encoding: base64 Cc: netmod@ietf.org Subject: Re: [netmod] changes in the routing model X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 00:49:34 -0000 TGFkaXNsYXYgTGhvdGthIDxsaG90a2FAbmljLmN6PiB3cm90ZToNCj4gDQo+IE9uIDA1IE5vdiAy MDEzLCBhdCAxNDo0MSwgTWFydGluIEJqb3JrbHVuZCA8bWJqQHRhaWwtZi5jb20+IHdyb3RlOg0K PiANCj4gPiBIaSwNCj4gPiANCj4gPiBJIGhhdmUgc29tZSBjb21tZW50cyBvbiB0aGUgcmVjZW50 IGNoYW5nZXM6DQo+ID4gDQo+ID4gTGFkaXNsYXYgTGhvdGthIDxsaG90a2FAbmljLmN6PiB3cm90 ZToNCj4gPj4gICBvICBJbnRyb2R1Y2VkIHVpbnQ2NCBrZXlzIGZvciBzdGF0ZSBsaXN0czogcm91 dGluZy1pbnN0YW5jZSwgcmliLA0KPiA+PiAgICAgIHJvdXRlLCBuZXh0aG9wLg0KPiA+PiANCj4g Pj4gVGhlIGlkZWEgaXMgdGhhdCBhbiBJMlJTIGNsaWVudCBjcmVhdGVzIGFuIGVudHJ5IChlLmcu IGEgcm91dGUpIGFuZA0KPiA+PiBnZXRzIGJhY2sgYSB1bmlxdWUgbnVtZXJpYyBoYW5kbGUgdGhh dCBjYW4gYmUgdXNlZCBsYXRlciBmb3IgcmVmZXJyaW5nDQo+ID4+IHRvIHRoYXQgZW50cnkuIE1v ZGVsbGluZyB0aGVzZSBoYW5kbGVzIGFzIGtleXMgb2Ygb3BlcmF0aW9uYWwgc3RhdGUNCj4gPj4g bGlzdHMgdGhlbiBzZWVtcyBxdWl0ZSBuYXR1cmFsLg0KPiA+IA0KPiA+IEJhc2VkIG9uIHRoZSBh Ym92ZSwgSSB1bmRlcnN0YW5kIHRoYXQgdGhlIHJvdXRlIGFuZCBuZXh0aG9wIGxpc3RzIGhhdmUN Cj4gPiBpbnRlZ2VyIGtleXMgKHRoZXkgYXJlIGFjdHVhbGx5IHVpbnQzMiBpbiB0aGUgbW9kZWwp LiAgQnV0IHdoeSBkbyB0aGUNCj4gDQo+IEFjdHVhbGx5IHRoZXkgYXJlIGFsbCB1aW50NjQuDQoN ClNvbWUgYXJlIHVpbnQzMiBpbiB0aGUgZHJhZnQuDQoNCj4gSTJSUyBndXlzIGluc2lzdGVkIG9u IG51bWVyaWMgaGFuZGxlcw0KPiBiZWNhdXNlIHRoZXkgd2lsbCBiZSBzZW50IGJhY2sgYW5kIGZv cnRoIGluIHRoZWlyIG1lc3NhZ2VzLg0KDQpUaGlzIGRvZXNuJ3QgaW1wbHkgdGhhdCB0aGV5IGhh dmUgdG8gYmUga2V5cy4NCg0KPiA+ICdyb3V0aW5nLWluc3RhbmNlJyBhbmQgJ3JpYicgbmVlZCB0 byBoYXZlIHVpbnQ2NCBpZCBhcyBrZXkgaW4NCj4gPiBvcGVyYXRpb25hbCBzdGF0ZT8gIFRoaXMg anVzdCBzZWVtcyB0byBtYWtlIGNvbmZpZ3VyYXRpb24gY29tcGxleCAtDQo+ID4gdGhlIHVzZXIg bXVzdCBmaW5kIHNvbWUgbnVtZXJpY2FsIGlkIGluIHRoZSBvcGVyc3RhdGUsIHRoZW4gZ2l2ZSB0 aGUNCj4gPiByaWIgYSBuYW1lLCBhbmQgd3JpdGUgdGhlIG51bWVyaWNhbCBpZC4gIENvdWxkbid0 IHRoZSBuYW1lIGJlIGtleSBpbg0KPiA+IGJvdGggY29uZmlnIGFuZCBzdGF0ZSwgYW5kIGlmIGEg bnVtZXJpY2FsIGlkIGlzIG5lZWRlZCBpbiBvcGVyIHN0YXRlDQo+ID4gaXQgY291bGQgYmUgYSBu b3JtYWwgKHVuaXF1ZSkgbGVhZj8NCj4gDQo+IEkgdGhpbmsgaXQgaXMgYmV0dGVyIHRvIGhhdmUg ZGlzdGluY3Qga2V5cyBpbiBjb25maWcgYW5kIHN0YXRlDQo+IGxpc3RzLiBUaGUga2V5cyBvZiBz eXN0ZW0tY29udHJvbGxlZCBlbnRyaWVzIGluIG9wZXJhdGlvbmFsIHN0YXRlIG5lZWQNCj4gbm90 IGJlIHBlcnNpc3RlbnQsIGFuZCBzaG91bGQgdGhleSBjaGFuZ2UgYWZ0ZXIgcmVib290LCB0aGV5 IGNvdWxkbqJ0DQo+IGJlIHVwZGF0ZWQgaW4gY29uZmlnIGlmIHRoZXkgYXJlIGtleXMgdGhlcmUg YXMgd2VsbC4gTm90ZSB0aGF0IGENCj4gc3lzdGVtLWNvbnRyb2xsZWQgZW50cnkgKGZyb20gdGhl IE5FQ09ORiBQT1YpIGNhbiBhbHNvIGJlIGluamVjdGVkIGJ5DQo+IGFuIEkyUlMgYWdlbnQuDQoN CklmIHRoZSBpZCBjaGFuZ2VzIGFmdGVyIGEgcmVib290LCBpdCBtZWFucyB0aGUgY29uZmlnIGFm dGVyIGEgcmVib290DQptaWdodCBsZWFkIHRvIHN1cnByaXNpbmcgcmVzdWx0cy4gIFN1cHBvc2Ug dGhlcmUgYXJlIG9wZXIgZW50cmllcyB3aXRoDQppZCAxIGFuZCAyLCBhbmQgd2UgY29uZmlnIHRo b3NlIGJ5IGludmVudGluZyBuYW1lcyBhbmQgdXNlIHRoZW0gaW4gdGhlDQpjb25maWcuICBBZnRl ciBhIHJlYm9vdCwgdGhlIG9sZCBlbnRyeSAxIGlzIG5vdyAyLCBhbmQgdGhlIG9sZCAyIGlzIDEu DQpUaGUgc3lzdGVtIGFwcGxpZXMgdGhlIGNvbmZpZywgYnV0IGl0IHdpbGwgYmUgZm9yIHRoZSB3 cm9uZyBlbnRyaWVzLg0KDQpXaXRoIHBlcnNpc3RlbnQgbmFtZXMsIHRoZSBpZCBjYW4gY2hhbmdl IGFmdGVyIGEgcmVib290Lg0KDQoNCi9tYXJ0aW4NCg== From lhotka@nic.cz Tue Nov 5 17:00:48 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F122021F93BF for ; Tue, 5 Nov 2013 17:00:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.8 X-Spam-Level: X-Spam-Status: No, score=-1.8 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y1-BB855M7xF for ; Tue, 5 Nov 2013 17:00:48 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 598D021E80C9 for ; Tue, 5 Nov 2013 17:00:44 -0800 (PST) Received: from wireless-v6.meeting.ietf.org (unknown [IPv6:2001:67c:370:160:7c48:22d2:65b:fc75]) by mail.nic.cz (Postfix) with ESMTPSA id DEC071400FE; Wed, 6 Nov 2013 02:00:33 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1383699635; bh=y4ZeQmy+0DpxMGafkbVPvRk0jZoQaWf/Ds+QINwTOjE=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=ZiKEciHT1cz6QhDeymO4yLbcB7SvNR5nRSLWFbYEMjx+WOyWoQ1dWge9g3RaUE5eJ tblhbNmWheU/vk9RQtxQZd/mbC9hUDdcWItnZdn3MnlRhmvmUrvcKdImKmGlMLXSz9 5W9qYAmi1trRotrNl0QfhGgyfUmXV8ZIJfy9UuQw= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) From: Ladislav Lhotka In-Reply-To: <20131105.164156.397349935.mbj@tail-f.com> Date: Tue, 5 Nov 2013 17:00:30 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <00C11A98-1758-48A4-8182-38E0F8F31C79@nic.cz> <20131105.164156.397349935.mbj@tail-f.com> To: =?iso-8859-1?Q?Martin_Bj=F6rklund?= X-Mailer: Apple Mail (2.1816) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] Last chance for review: draft-ietf-netmod-ip-cfg & draft-ietf-netmod-ip-cfg X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 01:00:49 -0000 On 05 Nov 2013, at 16:41, Martin Bjorklund wrote: > Ladislav Lhotka wrote: >>=20 >> On 05 Nov 2013, at 16:28, Andy Bierman wrote: >>=20 >>> Hi, >>>=20 >>> The concrete proposal I agreed to on the list was to change the >>> if-type enums to identities. If you want me to do the emacs >>> search-and-replace >>> to convert the enums to identities I can do that. I am not = suggesting >>> that the values in the registry be re-engineered at all. >>=20 >> It is not that simple - I assume you want to keep these identities >> synchronised with the IANA enumeration, right? >=20 > I understand the edits Andy wants, and the IANA draft already > instructs IANA to keep the YANG module in sync with the registry. So > I think what Andy suggests is easy to do (in the documents). Two questions: 1. If somebody introduces a new ifType identity in a YANG module, is he = also required to register it with IANA? 2. What if somebody wants to make use of a hierarchy of identities, i. = e. derive a new identity from an existing base? The IANA registry is = flat, so mapping a tree structure to it may not be possible. Lada =20 >=20 >=20 > /martin -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From mbj@tail-f.com Tue Nov 5 17:05:04 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F67221F9D56 for ; Tue, 5 Nov 2013 17:05:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.85 X-Spam-Level: X-Spam-Status: No, score=-1.85 tagged_above=-999 required=5 tests=[AWL=0.196, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2oXRsq2pzr2o for ; Tue, 5 Nov 2013 17:04:58 -0800 (PST) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 76A9C21F9CBF for ; Tue, 5 Nov 2013 17:04:58 -0800 (PST) Received: from localhost (dhcp-a398.meeting.ietf.org [31.133.163.152]) by mail.tail-f.com (Postfix) with ESMTPSA id B411B1200054; Wed, 6 Nov 2013 02:04:56 +0100 (CET) Date: Tue, 05 Nov 2013 17:04:55 -0800 (PST) Message-Id: <20131105.170455.362432186.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: References: <00C11A98-1758-48A4-8182-38E0F8F31C79@nic.cz> <20131105.164156.397349935.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] Last chance for review: draft-ietf-netmod-ip-cfg & draft-ietf-netmod-ip-cfg X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 01:05:04 -0000 Ladislav Lhotka wrote: > > On 05 Nov 2013, at 16:41, Martin Bjorklund wrote: > > > Ladislav Lhotka wrote: > >> > >> On 05 Nov 2013, at 16:28, Andy Bierman wrote: > >> > >>> Hi, > >>> > >>> The concrete proposal I agreed to on the list was to change the > >>> if-type enums to identities. If you want me to do the emacs > >>> search-and-replace > >>> to convert the enums to identities I can do that. I am not suggesting > >>> that the values in the registry be re-engineered at all. > >> > >> It is not that simple - I assume you want to keep these identities > >> synchronised with the IANA enumeration, right? > > > > I understand the edits Andy wants, and the IANA draft already > > instructs IANA to keep the YANG module in sync with the registry. So > > I think what Andy suggests is easy to do (in the documents). > > Two questions: > > 1. If somebody introduces a new ifType identity in a YANG module, is > he also required to register it with IANA? No! > 2. What if somebody wants to make use of a hierarchy of identities, > i. e. derive a new identity from an existing base? The IANA registry > is flat, so mapping a tree structure to it may not be possible. Correct. If you want to make a hierarchy, go ahead and do that. The IANA types are separate. /martin From andy@yumaworks.com Tue Nov 5 17:15:14 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09B0F11E81F8 for ; Tue, 5 Nov 2013 17:15:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.526 X-Spam-Level: X-Spam-Status: No, score=-2.526 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mWT2VuL9FBni for ; Tue, 5 Nov 2013 17:15:09 -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 C580F11E8205 for ; Tue, 5 Nov 2013 17:15:08 -0800 (PST) Received: by mail-qc0-f174.google.com with SMTP id v1so5269528qcw.5 for ; Tue, 05 Nov 2013 17:15: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:cc:content-type; bh=ld3uAZOF8vTtI5Nc7dknRqg4RZtEz/F7l0hKx1h5GOg=; b=DlqrSML2HRhajHfma3KMUeUIwiJ3U3P/oHE5n1fLqyhb+7gaCKu0z2P4pjEMXDxHxm MP1VaO8mPe1+N3qLWfCdtqPWJ5yaslDmckUV2EASnux4VAVCSb81zHn72wJmbJc1L/e/ rWKdz1j8zbeutSXwbaS0IJtOX353Kr0kuLvxF561LL9zUw7L5aTvU5o9BPqhgG5A7epm 8BzGxw7IV50ss2szijfLFvoRmzYrr9dpx0W+Ap4AhpQTUFpwgnJIhz8dqI25U4/p4gpw d8tjP9N/HV1ESiEgKTf3FslAh78Vls2KC2VuQuD9SoRYVDYtLQw+NV+6LyWJXNdaDObV ZoHg== X-Gm-Message-State: ALoCoQnPZz3Jfrt6qI6Ji6c5NoGkkcalr+c63CcFYgIj/q1R8SFrEhKov5CZwuLmZPpuK8HmsfQa MIME-Version: 1.0 X-Received: by 10.49.71.131 with SMTP id v3mr687187qeu.85.1383700508141; Tue, 05 Nov 2013 17:15:08 -0800 (PST) Received: by 10.140.100.203 with HTTP; Tue, 5 Nov 2013 17:15:08 -0800 (PST) In-Reply-To: References: <00C11A98-1758-48A4-8182-38E0F8F31C79@nic.cz> <20131105.164156.397349935.mbj@tail-f.com> Date: Tue, 5 Nov 2013 17:15:08 -0800 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=047d7b5d597243872904ea77e1b2 Cc: "netmod@ietf.org" Subject: Re: [netmod] Last chance for review: draft-ietf-netmod-ip-cfg & draft-ietf-netmod-ip-cfg X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 01:15:14 -0000 --047d7b5d597243872904ea77e1b2 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Nov 5, 2013 at 5:00 PM, Ladislav Lhotka wrote: > > On 05 Nov 2013, at 16:41, Martin Bjorklund wrote: > > > Ladislav Lhotka wrote: > >> > >> On 05 Nov 2013, at 16:28, Andy Bierman wrote: > >> > >>> Hi, > >>> > >>> The concrete proposal I agreed to on the list was to change the > >>> if-type enums to identities. If you want me to do the emacs > >>> search-and-replace > >>> to convert the enums to identities I can do that. I am not suggesting > >>> that the values in the registry be re-engineered at all. > >> > >> It is not that simple - I assume you want to keep these identities > >> synchronised with the IANA enumeration, right? > > > > I understand the edits Andy wants, and the IANA draft already > > instructs IANA to keep the YANG module in sync with the registry. So > > I think what Andy suggests is easy to do (in the documents). > > Two questions: > > 1. If somebody introduces a new ifType identity in a YANG module, is he > also required to register it with IANA? > > IMO they should not do that. It is not an IANA type unless they register it with IANA. That process is not changing I hope. > 2. What if somebody wants to make use of a hierarchy of identities, i. e. > derive a new identity from an existing base? The IANA registry is flat, so > mapping a tree structure to it may not be possible. > > Nobody is trying to change the SMIv2 data type. The base-stmt in a YANG identity is not coupled in any way to the IANA registry. I don't agree that creating a tree structure is that important. It may be more elegant, but real apps are going to hard-wire code to match up to identities. Finding a "close enough" interface type doesn't seem very worthwhile as a fallback design approach. Andy > Lada > > > > > > > /martin > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > --047d7b5d597243872904ea77e1b2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Tue, Nov 5, 2013 at 5:00 PM, Ladislav Lhotka &= lt;lhotka@nic.cz>= wrote:

On 05 Nov 2013, at 16:41, Martin Bjorklund <mbj@tail-f.com> wrote:

> Ladislav Lhotka <lhotka@nic.cz= > wrote:
>>
>> On 05 Nov 2013, at 16:28, Andy Bierman <andy@yumaworks.com> wrote:
>>
>>> Hi,
>>>
>>> The concrete proposal I agreed to on the list was to change th= e
>>> if-type enums to identities. =A0If you want me to do the emacs=
>>> search-and-replace
>>> to convert the enums to identities I can do that. =A0I am not = suggesting
>>> that the values in the registry be re-engineered at all.
>>
>> It is not that simple - I assume you want to keep these identities=
>> synchronised with the IANA enumeration, right?
>
> I understand the edits Andy wants, and the IANA draft already
> instructs IANA to keep the YANG module in sync with the registry. =A0S= o
> I think what Andy suggests is easy to do (in the documents).

Two questions:

1. If somebody introduces a new ifType identity in a YANG module, is he als= o required to register it with IANA?


IMO they should not do that.
It is not an IANA type unless they register it with IANA.
That p= rocess is not changing I hope.
=A0
2. What if somebody wants to make use of a hierarchy of identities, i. e. d= erive a new identity from an existing base? The IANA registry is flat, so m= apping a tree structure to it may not be possible.


Nobody is trying to change the SMIv2 d= ata type. =A0The base-stmt in
a YANG identity is not coupled in a= ny way to the IANA registry.
I don't agree that creating a tr= ee structure is that important.
It may be more elegant, but real apps are going to hard-wire code
to match up to identities. =A0Finding a "close enough" inte= rface type
doesn't seem very worthwhile as a fallback design = approach.


Andy

=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex"> Lada

>
>
> /martin

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





--047d7b5d597243872904ea77e1b2-- From andy@yumaworks.com Tue Nov 5 17:27:03 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84EE011E818C for ; Tue, 5 Nov 2013 17:27:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.824 X-Spam-Level: X-Spam-Status: No, score=-2.824 tagged_above=-999 required=5 tests=[AWL=0.152, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dhiVMMBHE3sk for ; Tue, 5 Nov 2013 17:26:58 -0800 (PST) Received: from mail-qc0-f170.google.com (mail-qc0-f170.google.com [209.85.216.170]) by ietfa.amsl.com (Postfix) with ESMTP id 34E7A11E811A for ; Tue, 5 Nov 2013 17:26:58 -0800 (PST) Received: by mail-qc0-f170.google.com with SMTP id n9so5462490qcw.1 for ; Tue, 05 Nov 2013 17:26:57 -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=sIhUDu8bZF4dexRqBxY3pb1HeQQLib6Xk4/ShogqZJs=; b=HoWWefKEYh9ovm0pJQDD8wYQyaM2CgnIXeukDjSzCIZcKQjBjSIa9Yj/HQgwk5JzPJ v7XPS3eQyegRIFIyslpPvekQTbrFF/WK93FsPLv+93BJomuxTbtJOxp4OQDza9YcwDVV BvUKLPHLIHB54UrjN7VzS5T5xKk3om8F1cEDxgTtJugMujJKBl4MiSqGhQI7KpGZ9EGN s0a62p0ZvtrXU3iRyC0bImMh21XmCKKpSJTv2fRXsxZAlzuHs38NUxRRMXJH12lfy9ng Wqpd86Qzw0FpJ9CDis3Y55ipPjDsfMiFhsAfu4v3cAaT7xtYjpCFpG4AhQSCCqSTx7Vr 7c9A== X-Gm-Message-State: ALoCoQmPioiRvWZXrHxrU10pV1O0ectYMmJ2Segxj1xBCk6hKmNPVP8w1NKcL+kQfLQuj8HK4pfP MIME-Version: 1.0 X-Received: by 10.224.127.193 with SMTP id h1mr2417597qas.82.1383701217645; Tue, 05 Nov 2013 17:26:57 -0800 (PST) Received: by 10.140.100.203 with HTTP; Tue, 5 Nov 2013 17:26:57 -0800 (PST) In-Reply-To: <20131105.170455.362432186.mbj@tail-f.com> References: <00C11A98-1758-48A4-8182-38E0F8F31C79@nic.cz> <20131105.164156.397349935.mbj@tail-f.com> <20131105.170455.362432186.mbj@tail-f.com> Date: Tue, 5 Nov 2013 17:26:57 -0800 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: multipart/alternative; boundary=001a1132ebe28db01e04ea780bec Cc: "netmod@ietf.org" Subject: Re: [netmod] Last chance for review: draft-ietf-netmod-ip-cfg & draft-ietf-netmod-ip-cfg X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 01:27:03 -0000 --001a1132ebe28db01e04ea780bec Content-Type: text/plain; charset=ISO-8859-1 On Tue, Nov 5, 2013 at 5:04 PM, Martin Bjorklund wrote: > Ladislav Lhotka wrote: > > > > On 05 Nov 2013, at 16:41, Martin Bjorklund wrote: > > > > > Ladislav Lhotka wrote: > > >> > > >> On 05 Nov 2013, at 16:28, Andy Bierman wrote: > > >> > > >>> Hi, > > >>> > > >>> The concrete proposal I agreed to on the list was to change the > > >>> if-type enums to identities. If you want me to do the emacs > > >>> search-and-replace > > >>> to convert the enums to identities I can do that. I am not > suggesting > > >>> that the values in the registry be re-engineered at all. > > >> > > >> It is not that simple - I assume you want to keep these identities > > >> synchronised with the IANA enumeration, right? > > > > > > I understand the edits Andy wants, and the IANA draft already > > > instructs IANA to keep the YANG module in sync with the registry. So > > > I think what Andy suggests is easy to do (in the documents). > > > > Two questions: > > > > 1. If somebody introduces a new ifType identity in a YANG module, is > > he also required to register it with IANA? > > No! > This implies that a WG is going to create new interface types that will not be supportable in SNMP and that NETCONF is going to diverge from the IANA registry and create its own. This implies that the IANA considerations section of the RFC defining the new if-type identity is not going to request IANA to allocate a new ifType enumeration at the same time the RFC is published. Why would we want to do that? Andy > > > 2. What if somebody wants to make use of a hierarchy of identities, > > i. e. derive a new identity from an existing base? The IANA registry > > is flat, so mapping a tree structure to it may not be possible. > > Correct. If you want to make a hierarchy, go ahead and do that. The > IANA types are separate. > > > /martin > --001a1132ebe28db01e04ea780bec Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Tue, Nov 5, 2013 at 5:04 PM, Martin Bjorklund = <mbj@tail-f.com&= gt; wrote:
Ladislav Lhotka <lhotka@nic.cz> wrote:
>
> On 05 Nov 2013, at 16:41, Martin Bjorklund <mbj@tail-f.com> wrote:
>
> > Ladislav Lhotka <lhotka@nic.c= z> wrote:
> >>
> >> On 05 Nov 2013, at 16:28, Andy Bierman <andy@yumaworks.com> wrote:
> >>
> >>> Hi,
> >>>
> >>> The concrete proposal I agreed to on the list was to chan= ge the
> >>> if-type enums to identities. =A0If you want me to do the = emacs
> >>> search-and-replace
> >>> to convert the enums to identities I can do that. =A0I am= not suggesting
> >>> that the values in the registry be re-engineered at all.<= br> > >>
> >> It is not that simple - I assume you want to keep these ident= ities
> >> synchronised with the IANA enumeration, right?
> >
> > I understand the edits Andy wants, and the IANA draft already
> > instructs IANA to keep the YANG module in sync with the registry.= =A0So
> > I think what Andy suggests is easy to do (in the documents).
>
> Two questions:
>
> 1. If somebody introduces a new ifType identity in a YANG module, is > he also required to register it with IANA?

No!


This implies that a = WG is going to create new interface types that will
not be suppor= table in SNMP and that NETCONF is going to diverge
from the IANA = registry and create its own.

This implies that the IANA considerations section of th= e RFC defining
the new if-type identity is not going to request I= ANA to allocate
a new ifType enumeration at the same time the RFC= is published.
Why would we want to do that?


= Andy

=A0

> 2. What if somebody wants to make use of a hierarchy of identities, > i. e. derive a new identity from an existing base? The IANA registry > is flat, so mapping a tree structure to it may not be possible.

Correct. =A0If you want to make a hierarchy, go ahead and do that. =A0The IANA types are separate.


/martin

--001a1132ebe28db01e04ea780bec-- From lhotka@nic.cz Tue Nov 5 17:38:13 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A8A721F9DA0 for ; Tue, 5 Nov 2013 17:38:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.936 X-Spam-Level: X-Spam-Status: No, score=-1.936 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KvUF1MwE1dVO for ; Tue, 5 Nov 2013 17:38:12 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 9E39A11E8199 for ; Tue, 5 Nov 2013 17:36:33 -0800 (PST) Received: from wireless-v6.meeting.ietf.org (unknown [IPv6:2001:67c:370:160:7c48:22d2:65b:fc75]) by mail.nic.cz (Postfix) with ESMTPSA id F26DF13FA60; Wed, 6 Nov 2013 02:36:30 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1383701792; bh=0GNpFQC47vOKf368AIrHvdVnbuP2fonXYqh5jRmGFdY=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=q9/I7T561TgiKf7LqKAtJ/6Fvn33o56pvGFcNJk3qG6dLw7qVvrHZIpAcAlOCfVoC DMO+wD4tVLqlh7DnyyKzN/r5dAaT01ehLNdiCm+fVnAPVmyxMVuf46FEoWI/AW+z0k uoTDkOnJbYcngt1HoTBjlfsGbhUA9ri56amYqGOI= Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) From: Ladislav Lhotka In-Reply-To: Date: Tue, 5 Nov 2013 17:36:28 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <46A96A11-675A-4D8B-A1DC-A394D03CA575@nic.cz> References: <00C11A98-1758-48A4-8182-38E0F8F31C79@nic.cz> <20131105.164156.397349935.mbj@tail-f.com> To: Andy Bierman X-Mailer: Apple Mail (2.1816) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Cc: "netmod@ietf.org" Subject: Re: [netmod] Last chance for review: draft-ietf-netmod-ip-cfg & draft-ietf-netmod-ip-cfg X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 01:38:13 -0000 On 05 Nov 2013, at 17:15, Andy Bierman wrote: >=20 >=20 >=20 > On Tue, Nov 5, 2013 at 5:00 PM, Ladislav Lhotka wrote: >=20 > On 05 Nov 2013, at 16:41, Martin Bjorklund wrote: >=20 > > Ladislav Lhotka wrote: > >> > >> On 05 Nov 2013, at 16:28, Andy Bierman wrote: > >> > >>> Hi, > >>> > >>> The concrete proposal I agreed to on the list was to change the > >>> if-type enums to identities. If you want me to do the emacs > >>> search-and-replace > >>> to convert the enums to identities I can do that. I am not = suggesting > >>> that the values in the registry be re-engineered at all. > >> > >> It is not that simple - I assume you want to keep these identities > >> synchronised with the IANA enumeration, right? > > > > I understand the edits Andy wants, and the IANA draft already > > instructs IANA to keep the YANG module in sync with the registry. = So > > I think what Andy suggests is easy to do (in the documents). >=20 > Two questions: >=20 > 1. If somebody introduces a new ifType identity in a YANG module, is = he also required to register it with IANA? >=20 >=20 > IMO they should not do that. > It is not an IANA type unless they register it with IANA. > That process is not changing I hope. > =20 > 2. What if somebody wants to make use of a hierarchy of identities, i. = e. derive a new identity from an existing base? The IANA registry is = flat, so mapping a tree structure to it may not be possible. >=20 >=20 > Nobody is trying to change the SMIv2 data type. The base-stmt in > a YANG identity is not coupled in any way to the IANA registry. > I don't agree that creating a tree structure is that important. > It may be more elegant, but real apps are going to hard-wire code > to match up to identities. Finding a "close enough" interface type > doesn't seem very worthwhile as a fallback design approach. The hierarchy is important for the data model. In instance data, the = identity value will always be a single QName. Lada >=20 >=20 > Andy >=20 > =20 > Lada >=20 > > > > > > /martin >=20 > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C >=20 >=20 >=20 >=20 >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From mbj@tail-f.com Tue Nov 5 17:38:47 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E29021E81BE for ; Tue, 5 Nov 2013 17:38:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.878 X-Spam-Level: X-Spam-Status: No, score=-1.878 tagged_above=-999 required=5 tests=[AWL=0.168, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D6b6IlBKkvbD for ; Tue, 5 Nov 2013 17:38:28 -0800 (PST) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 98B2921E815D for ; Tue, 5 Nov 2013 17:36:51 -0800 (PST) Received: from localhost (dhcp-a398.meeting.ietf.org [31.133.163.152]) by mail.tail-f.com (Postfix) with ESMTPSA id B632D1200054; Wed, 6 Nov 2013 02:36:49 +0100 (CET) Date: Tue, 05 Nov 2013 17:36:48 -0800 (PST) Message-Id: <20131105.173648.452159171.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: <20131105.170455.362432186.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] Last chance for review: draft-ietf-netmod-ip-cfg & draft-ietf-netmod-ip-cfg X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 01:38:47 -0000 Andy Bierman wrote: > On Tue, Nov 5, 2013 at 5:04 PM, Martin Bjorklund > wrote: > > > Ladislav Lhotka wrote: > > > > > > On 05 Nov 2013, at 16:41, Martin Bjorklund wrote: > > > > > > > Ladislav Lhotka wrote: > > > >> > > > >> On 05 Nov 2013, at 16:28, Andy Bierman wrote: > > > >> > > > >>> Hi, > > > >>> > > > >>> The concrete proposal I agreed to on the list was to change the > > > >>> if-type enums to identities. If you want me to do the emacs > > > >>> search-and-replace > > > >>> to convert the enums to identities I can do that. I am not > > suggesting > > > >>> that the values in the registry be re-engineered at all. > > > >> > > > >> It is not that simple - I assume you want to keep these identities > > > >> synchronised with the IANA enumeration, right? > > > > > > > > I understand the edits Andy wants, and the IANA draft already > > > > instructs IANA to keep the YANG module in sync with the registry. So > > > > I think what Andy suggests is easy to do (in the documents). > > > > > > Two questions: > > > > > > 1. If somebody introduces a new ifType identity in a YANG module, is > > > he also required to register it with IANA? > > > > No! > > > > > This implies that a WG is going to create new interface types that > will > not be supportable in SNMP and that NETCONF is going to diverge > from the IANA registry and create its own. Not necessarily. > This implies that the IANA considerations section of the RFC defining > the new if-type identity is not going to request IANA to allocate > a new ifType enumeration at the same time the RFC is published. > Why would we want to do that? Maybe there's already an IANA type that can be used for monitoring. If a new IANA type is needed, then of course the WG will request a new type. /martin From david.kessens@gmail.com Tue Nov 5 17:44:57 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 347D521F9D9A for ; Tue, 5 Nov 2013 17:44:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 458lD7Y01AUB for ; Tue, 5 Nov 2013 17:44:55 -0800 (PST) Received: from mail-la0-x22c.google.com (mail-la0-x22c.google.com [IPv6:2a00:1450:4010:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 8D6D021F9E76 for ; Tue, 5 Nov 2013 17:44:03 -0800 (PST) Received: by mail-la0-f44.google.com with SMTP id er20so2774653lab.17 for ; Tue, 05 Nov 2013 17:44:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=69Asg7YR3VbtMCMi3FGLk+Mmx+vWvt2q20Uue4uAPr8=; b=THGW2bmt1iTRanllRI3VR5ujmm99/8HTG8XA7wjz/IVLIFwvzZW0yWNcLXb+VX31vk dYkMLhXaCswnRNTkUMZkAZU6D1R24XdcpG37SdxggJcd0cdwiuoLXt1xj3eVaCBjLalh g0xOyKUG4r3I9PpQqk7Q6rRhjgc/dqL9orPDhoUh3JQdgSmAtisYxCEn78aTDs5GgRpF TXoWb6wkpK5Of4X6vaM9CKjJjjoBNTtBfpbaQPNjVVNz6vV5iIYGBvpMui4sWVAkMn/H Vnck5CZ/EnUT4FDbbU4Rn1dpAthRA3dHes4OliuInnFG+KMDKAxoXCeOAkGXq/dkBfJN vBYg== MIME-Version: 1.0 X-Received: by 10.112.29.147 with SMTP id k19mr761144lbh.9.1383702242409; Tue, 05 Nov 2013 17:44:02 -0800 (PST) Received: by 10.152.170.170 with HTTP; Tue, 5 Nov 2013 17:44:02 -0800 (PST) In-Reply-To: <20131105.164156.397349935.mbj@tail-f.com> References: <00C11A98-1758-48A4-8182-38E0F8F31C79@nic.cz> <20131105.164156.397349935.mbj@tail-f.com> Date: Tue, 5 Nov 2013 17:44:02 -0800 Message-ID: From: David Kessens To: Martin Bjorklund Content-Type: multipart/alternative; boundary=001a1133aa86a2436804ea7848f9 Cc: netmod@ietf.org Subject: Re: [netmod] Last chance for review: draft-ietf-netmod-ip-cfg & draft-ietf-netmod-ip-cfg X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 01:44:57 -0000 --001a1133aa86a2436804ea7848f9 Content-Type: text/plain; charset=ISO-8859-1 But you side step the question whether you can live with Andy's proposal or not. We really need to bring this to closure. As the document shepherd/working group co-chair, I cannot move this document to the next stage if we don't know where people stand. David Kessens --- On Tue, Nov 5, 2013 at 4:41 PM, Martin Bjorklund wrote: > Ladislav Lhotka wrote: > > > > On 05 Nov 2013, at 16:28, Andy Bierman wrote: > > > > > Hi, > > > > > > The concrete proposal I agreed to on the list was to change the > > > if-type enums to identities. If you want me to do the emacs > > > search-and-replace > > > to convert the enums to identities I can do that. I am not suggesting > > > that the values in the registry be re-engineered at all. > > > > It is not that simple - I assume you want to keep these identities > > synchronised with the IANA enumeration, right? > > I understand the edits Andy wants, and the IANA draft already > instructs IANA to keep the YANG module in sync with the registry. So > I think what Andy suggests is easy to do (in the documents). > > > /martin > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > -- David Kessens --- --001a1133aa86a2436804ea7848f9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
But you side step the question whether you = can live with Andy's proposal or not.

We really need to br= ing this to closure.

As the document shepherd/working group co= -chair, I cannot move this document to the next stage if we don't know = where people stand.

David Kessens
---

On Tue, Nov 5, 2013 at 4:41 PM, Martin Bjorklun= d <mbj@tail-f.com> wrote:
Ladislav Lhotka <lhotka@nic.cz> wrote:
>
> On 05 Nov 2013, at 16:28, Andy Bierman <andy@yumaworks.com> wrote:
>
> > Hi,
> >
> > The concrete proposal I agreed to on the list was to change the > > if-type enums to identities. =A0If you want me to do the emacs > > search-and-replace
> > to convert the enums to identities I can do that. =A0I am not sug= gesting
> > that the values in the registry be re-engineered at all.
>
> It is not that simple - I assume you want to keep these identities
> synchronised with the IANA enumeration, right?

I understand the edits Andy wants, and the IANA draft already
instructs IANA to keep the YANG module in sync with the registry. =A0So
I think what Andy suggests is easy to do (in the documents).


/martin
_____________________= __________________________
netmod mailing list
netmod@ietf.org
= https://www.ietf.org/mailman/listinfo/netmod



--

David Kessens
---
--001a1133aa86a2436804ea7848f9-- From andy@yumaworks.com Tue Nov 5 17:45:31 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE3FC11E81EB for ; Tue, 5 Nov 2013 17:45:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.526 X-Spam-Level: X-Spam-Status: No, score=-2.526 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zhl+cOiL6HDy for ; Tue, 5 Nov 2013 17:45:25 -0800 (PST) Received: from mail-qe0-f45.google.com (mail-qe0-f45.google.com [209.85.128.45]) by ietfa.amsl.com (Postfix) with ESMTP id ABDCB11E81B2 for ; Tue, 5 Nov 2013 17:44:24 -0800 (PST) Received: by mail-qe0-f45.google.com with SMTP id 8so5634592qea.4 for ; Tue, 05 Nov 2013 17:44:24 -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=WASjeZFSU1faAxqxMyzV+mSnXHpw6M5zuV8BDvfLBOc=; b=ZEDdWLiMj5AuELUIV7SpNd0/8V+145bwZc1urmsURbkF41gLdwApS0LzWZkKNwyqhP Xd1w/LnW+3e5O6ZfryCWiqPX4G6lYbKECbpnBY4O7qqtt5lWVj6lVlRL87+LRcbQAOTw s1QPdMmidxROOwCEDJRnRU58+FMwD4AFmd7L+z6aCJSjiVnRZKFeQAw4tmhHVp6fxo83 KNGCGAL3que5Mjcms44TMK5Jg2s9O4EnZnbZ+uR6kh72YsmAdt8XU3B06IEBYr34jgSy BO/1RkpA15V/QJA0urIJmll45BHgHeGZUDdFRkyzqMnSjHTRLnnxUaUwxPAearHJ92mZ c92A== X-Gm-Message-State: ALoCoQlzDkOT5dW3EYcrnwUATg4Oq3sLM2Dw9Ub1RFxMSmqyCSAEY7eItnGm7q7ydcSPXoiqXntK MIME-Version: 1.0 X-Received: by 10.49.49.104 with SMTP id t8mr940781qen.45.1383702263982; Tue, 05 Nov 2013 17:44:23 -0800 (PST) Received: by 10.140.100.203 with HTTP; Tue, 5 Nov 2013 17:44:23 -0800 (PST) In-Reply-To: <46A96A11-675A-4D8B-A1DC-A394D03CA575@nic.cz> References: <00C11A98-1758-48A4-8182-38E0F8F31C79@nic.cz> <20131105.164156.397349935.mbj@tail-f.com> <46A96A11-675A-4D8B-A1DC-A394D03CA575@nic.cz> Date: Tue, 5 Nov 2013 17:44:23 -0800 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=047d7b6d9bbaeb891404ea784972 Cc: "netmod@ietf.org" Subject: Re: [netmod] Last chance for review: draft-ietf-netmod-ip-cfg & draft-ietf-netmod-ip-cfg X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 01:45:31 -0000 --047d7b6d9bbaeb891404ea784972 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Nov 5, 2013 at 5:36 PM, Ladislav Lhotka wrote: > > On 05 Nov 2013, at 17:15, Andy Bierman wrote: > > > > > > > > > On Tue, Nov 5, 2013 at 5:00 PM, Ladislav Lhotka wrote: > > > > On 05 Nov 2013, at 16:41, Martin Bjorklund wrote: > > > > > Ladislav Lhotka wrote: > > >> > > >> On 05 Nov 2013, at 16:28, Andy Bierman wrote: > > >> > > >>> Hi, > > >>> > > >>> The concrete proposal I agreed to on the list was to change the > > >>> if-type enums to identities. If you want me to do the emacs > > >>> search-and-replace > > >>> to convert the enums to identities I can do that. I am not > suggesting > > >>> that the values in the registry be re-engineered at all. > > >> > > >> It is not that simple - I assume you want to keep these identities > > >> synchronised with the IANA enumeration, right? > > > > > > I understand the edits Andy wants, and the IANA draft already > > > instructs IANA to keep the YANG module in sync with the registry. So > > > I think what Andy suggests is easy to do (in the documents). > > > > Two questions: > > > > 1. If somebody introduces a new ifType identity in a YANG module, is he > also required to register it with IANA? > > > > > > IMO they should not do that. > > It is not an IANA type unless they register it with IANA. > > That process is not changing I hope. > > > > 2. What if somebody wants to make use of a hierarchy of identities, i. > e. derive a new identity from an existing base? The IANA registry is flat, > so mapping a tree structure to it may not be possible. > > > > > > Nobody is trying to change the SMIv2 data type. The base-stmt in > > a YANG identity is not coupled in any way to the IANA registry. > > I don't agree that creating a tree structure is that important. > > It may be more elegant, but real apps are going to hard-wire code > > to match up to identities. Finding a "close enough" interface type > > doesn't seem very worthwhile as a fallback design approach. > > The hierarchy is important for the data model. In instance data, the > identity value will always be a single QName. > > It is not important for the data model. The identity provides a unique value whether the base is interface-type or whether it is something derived from interface-type. The important feature here is that identities allow any naming authority to extend the value set. That is why enumerations are being replaced. Lada > > Andy > > > > > > Andy > > > > > > Lada > > > > > > > > > > > /martin > > > > -- > > Ladislav Lhotka, CZ.NIC Labs > > PGP Key ID: E74E8C0C > > > > > > > > > > > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > --047d7b6d9bbaeb891404ea784972 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Tue, Nov 5, 2013 at 5:36 PM, Ladislav Lhotka &= lt;lhotka@nic.cz>= wrote:

On 05 Nov 2013, at 17:15, Andy Bierman <andy@yumaworks.com> wrote:

>
>
>
> On Tue, Nov 5, 2013 at 5:00 PM, Ladislav Lhotka <lhotka@nic.cz> wrote:
>
> On 05 Nov 2013, at 16:41, Martin Bjorklund <mbj@tail-f.com> wrote:
>
> > Ladislav Lhotka <lhotka@nic.c= z> wrote:
> >>
> >> On 05 Nov 2013, at 16:28, Andy Bierman <andy@yumaworks.com> wrote:
> >>
> >>> Hi,
> >>>
> >>> The concrete proposal I agreed to on the list was to chan= ge the
> >>> if-type enums to identities. =A0If you want me to do the = emacs
> >>> search-and-replace
> >>> to convert the enums to identities I can do that. =A0I am= not suggesting
> >>> that the values in the registry be re-engineered at all.<= br> > >>
> >> It is not that simple - I assume you want to keep these ident= ities
> >> synchronised with the IANA enumeration, right?
> >
> > I understand the edits Andy wants, and the IANA draft already
> > instructs IANA to keep the YANG module in sync with the registry.= =A0So
> > I think what Andy suggests is easy to do (in the documents).
>
> Two questions:
>
> 1. If somebody introduces a new ifType identity in a YANG module, is h= e also required to register it with IANA?
>
>
> IMO they should not do that.
> It is not an IANA type unless they register it with IANA.
> That process is not changing I hope.
>
> 2. What if somebody wants to make use of a hierarchy of identities, i.= e. derive a new identity from an existing base? The IANA registry is flat,= so mapping a tree structure to it may not be possible.
>
>
> Nobody is trying to change the SMIv2 data type. =A0The base-stmt in > a YANG identity is not coupled in any way to the IANA registry.
> I don't agree that creating a tree structure is that important. > It may be more elegant, but real apps are going to hard-wire code
> to match up to identities. =A0Finding a "close enough" inter= face type
> doesn't seem very worthwhile as a fallback design approach.

The hierarchy is important for the data model. In instance data, the identi= ty value will always be a single QName.


It is not important for the data model= .
The identity provides a unique value whether the base is interf= ace-type
or whether it is something derived from interface-type.<= /div>
The important feature here is that identities allow any naming authori= ty
to extend the value set. =A0That is why enumerations are being= replaced.


>
>
> Andy
>
>
> Lada
>
> >
> >
> > /martin
>
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>
>
>
>
>

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





--047d7b6d9bbaeb891404ea784972-- From mbj@tail-f.com Tue Nov 5 17:53:32 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C09921E8113 for ; Tue, 5 Nov 2013 17:53:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[AWL=0.147, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hvPFmtqcmQqM for ; Tue, 5 Nov 2013 17:53:22 -0800 (PST) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 6EB2A21E8106 for ; Tue, 5 Nov 2013 17:52:46 -0800 (PST) Received: from localhost (dhcp-a398.meeting.ietf.org [31.133.163.152]) by mail.tail-f.com (Postfix) with ESMTPSA id A652C1200054; Wed, 6 Nov 2013 02:52:44 +0100 (CET) Date: Tue, 05 Nov 2013 17:52:42 -0800 (PST) Message-Id: <20131105.175242.170038953.mbj@tail-f.com> To: david.kessens@gmail.com From: Martin Bjorklund In-Reply-To: References: <00C11A98-1758-48A4-8182-38E0F8F31C79@nic.cz> <20131105.164156.397349935.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] Last chance for review: draft-ietf-netmod-ip-cfg & draft-ietf-netmod-ip-cfg X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 01:53:32 -0000 David Kessens wrote: > But you side step the question whether you can live with Andy's > proposal or > not. Sorry, I thought I made it clear that I can live with Andy's proposal. /martin From lhotka@nic.cz Tue Nov 5 17:53:54 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A234521F9C81 for ; Tue, 5 Nov 2013 17:53:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.944 X-Spam-Level: X-Spam-Status: No, score=-1.944 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a-tWXm+lyGte for ; Tue, 5 Nov 2013 17:53:53 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id EA63611E820B for ; Tue, 5 Nov 2013 17:53:17 -0800 (PST) Received: from wireless-v6.meeting.ietf.org (unknown [IPv6:2001:67c:370:160:7c48:22d2:65b:fc75]) by mail.nic.cz (Postfix) with ESMTPSA id B2B9613FA60; Wed, 6 Nov 2013 02:53:11 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1383702793; bh=GZ4nyIqIi7fArdpIl4yQPQZY++sD/LUsiq7ozgYixHM=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=TIqFlj/R04XueuP3MUt+P4wSFU5M1ZhKnwUXsH3hfRDUAr3e5yeaoida76wl2Txd1 zQPpxUfop7UMPxmTZPoPsllnuCg/kIBZcyeE7lwiA9J1sFrhp+k6wwuT3AnY33PKdf fIQvaNaxwDqLuJiSQxz8rPp3dGRjv0ddr2fTEcdc= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) From: Ladislav Lhotka In-Reply-To: Date: Tue, 5 Nov 2013 17:53:09 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <00C11A98-1758-48A4-8182-38E0F8F31C79@nic.cz> <20131105.164156.397349935.mbj@tail-f.com> <46A96A11-675A-4D8B-A1DC-A394D03CA575@nic.cz> To: Andy Bierman X-Mailer: Apple Mail (2.1816) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Cc: "netmod@ietf.org" Subject: Re: [netmod] Last chance for review: draft-ietf-netmod-ip-cfg & draft-ietf-netmod-ip-cfg X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 01:53:54 -0000 On 05 Nov 2013, at 17:44, Andy Bierman wrote: >=20 >=20 >=20 > On Tue, Nov 5, 2013 at 5:36 PM, Ladislav Lhotka wrote: >=20 > On 05 Nov 2013, at 17:15, Andy Bierman wrote: >=20 > > > > > > > > On Tue, Nov 5, 2013 at 5:00 PM, Ladislav Lhotka = wrote: > > > > On 05 Nov 2013, at 16:41, Martin Bjorklund wrote: > > > > > Ladislav Lhotka wrote: > > >> > > >> On 05 Nov 2013, at 16:28, Andy Bierman = wrote: > > >> > > >>> Hi, > > >>> > > >>> The concrete proposal I agreed to on the list was to change the > > >>> if-type enums to identities. If you want me to do the emacs > > >>> search-and-replace > > >>> to convert the enums to identities I can do that. I am not = suggesting > > >>> that the values in the registry be re-engineered at all. > > >> > > >> It is not that simple - I assume you want to keep these = identities > > >> synchronised with the IANA enumeration, right? > > > > > > I understand the edits Andy wants, and the IANA draft already > > > instructs IANA to keep the YANG module in sync with the registry. = So > > > I think what Andy suggests is easy to do (in the documents). > > > > Two questions: > > > > 1. If somebody introduces a new ifType identity in a YANG module, is = he also required to register it with IANA? > > > > > > IMO they should not do that. > > It is not an IANA type unless they register it with IANA. > > That process is not changing I hope. > > > > 2. What if somebody wants to make use of a hierarchy of identities, = i. e. derive a new identity from an existing base? The IANA registry is = flat, so mapping a tree structure to it may not be possible. > > > > > > Nobody is trying to change the SMIv2 data type. The base-stmt in > > a YANG identity is not coupled in any way to the IANA registry. > > I don't agree that creating a tree structure is that important. > > It may be more elegant, but real apps are going to hard-wire code > > to match up to identities. Finding a "close enough" interface type > > doesn't seem very worthwhile as a fallback design approach. >=20 > The hierarchy is important for the data model. In instance data, the = identity value will always be a single QName. >=20 >=20 > It is not important for the data model. > The identity provides a unique value whether the base is = interface-type > or whether it is something derived from interface-type. > The important feature here is that identities allow any naming = authority > to extend the value set. That is why enumerations are being replaced. This is only one reason. The other is that a hierarchy of identities can = be effectively used for defining common parts of the data model only = once and then use it for all interface types that are derived from the = =93abstract=94 type. In my view, this kind of inheritance will be heavily used, and then the = relationship with SNMP ifType will be lost anyway.=20 Lada >=20 >=20 > Lada >=20 >=20 > Andy >=20 > =20 > > > > > > Andy > > > > > > Lada > > > > > > > > > > > /martin > > > > -- > > Ladislav Lhotka, CZ.NIC Labs > > PGP Key ID: E74E8C0C > > > > > > > > > > >=20 > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C >=20 >=20 >=20 >=20 >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From jernej.tuljak@mg-soft.si Wed Nov 6 02:09:42 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4834211E81F0 for ; Wed, 6 Nov 2013 02:09:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, J_CHICKENPOX_64=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IRrR7GI0-j7U for ; Wed, 6 Nov 2013 02:09:38 -0800 (PST) Received: from gate.mg-soft.si (gate.mg-soft.si [212.30.73.66]) by ietfa.amsl.com (Postfix) with ESMTP id CB76311E8126 for ; Wed, 6 Nov 2013 02:09:37 -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 rA6A9aBS024147; Wed, 6 Nov 2013 11:09:36 +0100 Message-ID: <527A155C.6010605@mg-soft.com> Date: Wed, 06 Nov 2013 11:09:32 +0100 From: Jernej Tuljak User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Ladislav Lhotka References: <20131025.170154.518459007.mbj@tail-f.com> <0840D035-DF82-4436-85DC-8DA59D414BB7@nic.cz> <20131025.192445.290343408.mbj@tail-f.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] Fw: New Version Notification for draft-bjorklund-netmod-yang-xpath-extensions-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 10:09:42 -0000 Dne 25.10.2013 21:06, piše Ladislav Lhotka: > On 25 Oct 2013, at 19:24, Martin Bjorklund wrote: > >> Ladislav Lhotka wrote: >>> On 25 Oct 2013, at 17:01, Martin Bjorklund wrote: >>> >>>> Ladislav Lhotka wrote: >>>>> If the server doesn't advertise the "ietf-yang-xpath-extensions" module, can >>>>> other advertized modules still use new XPath functions in "must" and "when", >>>>> if >>>>> they import that module? >>>> Yes. Note that all XPath expressions are conceptual. If a server >>>> claims that it implements a module that uses such an xpath function, >>>> it must implement the contraint somehow. It doesn't have to use an >>>> XPath evaluator; it can be implemented in code - just like ane >>>> constraints defined in description statements. >>> Yes, but one has to be careful with revisions - sec. 10 in RFC 6020 allows new >>> extensions in an updated module, but I think in this case it could be dangerous >>> because the server cannot easily ignore unknown functions appearing in XPath >>> expressions. >> You typcially do not just load a new module into a server; it needs >> some instrumentation to be useful. So a new revison that uses some >> new XPath functions or not needs an implemention effort in the >> server. >> >> But maybe I misunderstood your concern? > Sec. 6.3.1 says: > > If a YANG compiler does not support a particular extension, which appears in a YANG module as an unknown-statement (see Section 12), the entire unknown-statement MAY be ignored by the compiler. > > So my point here is that while ignoring extensions is easy because they are self-contained, it is not the case for extensions in XPath expressions. But maybe it is not an issue. > > Lada > It is an issue. I share Ladislav's concerns and add my own. I do not think YANG extensions should be used for extending the value space of an existing YANG statement's argument (not this way). Extensions should only be allowed to extend YANG statement structure, thus providing new YANG statements with special meaning, which may or may not be utilized in YANG client code. The purpose of the "extension" statement is to define a keyword (7.17.). A must/when statement argument is a string, not a keyword. 7.17. also never mentions extensions being used/utilized in any way other than as _YANG statements_. In my view, importing a module that contains an extension's definition is not enough to "use/utilize" an extension. A YANG unknown statement is also required. While I agree that additional XPath functions would greatly benefit YANG language, I do not like the way this draft introduces them for usage. I think that the proper way of introducing them would be to simply create yangxp:must and yangxp:when extensions, alternatives to RFC6020 statements, which would allow extended XPath syntax in their arguments. IMO, all extensions should be self-contained, meaning no side-effects. Extending (augmenting actually) arbitrary statement arguments is a side-effect - you have to change valid YANG syntax into something else in order to use it. And use of an unsupported extension should under no circumstances result in compiler error, but it clearly does with this draft (unknown XPath function). You seem to be saying that as a modeler, I can now supposedly declare support for an extension by simply importing a module and using a specific character sequence inside a standard YANG statement argument (string), yet I'm not even at liberty to make a decision about that. That is an implementor's job, later in the development cycle. An actual problematic modeling use case: 1. you are using a YANG development IDE and have just defined ietf-yang-xpath-extensions module 2. you create a new module that imports ietf-yang-xpath-extensions 3. you create a must statement which uses an extended XPath function from ietf-yang-xpath-extensions 4. you expect the IDE's compiler to be quiet about the unknown function? I'd say no. It should raise hell because the offending must statement is clearly not YANG, nor is it an extension. Note that this case is applicable to any extension that would presume it is okay to distort an existing statement's argument value space. I could, for example, augment a revision statement's argument with some extra chars, and then expect compilers to keep quiet. I could also make namespace statement's argument not comply to URI syntax and expect it to be okay. Semantically, there's no difference between doing either of those and what this draft is attempting to do. That is, legalizing _deviations of standard YANG syntax_ in a way that is undefined from a RFC6020 compiler's perspective. Forget server instrumentation code. This is a language problem and has nothing to do with implementors or server-side. Are you allowing YANG description statements, children of an extension definition statement, to govern argument syntax of existing standard YANG statements, by them merely being present somewhere in the module chain? That is the real question here and I'd like to see RFC6020 text that allows this to be considered as something that is actually plausible. XPath expressions in YANG may be conceptual but are currently well defined. I urge you to keep them as such. What the current draft is doing requires YANG 2.0, IMHO. The must statement in section 2.1 of the draft is not YANG, since it's argument does not comply to RFC6020 requirements. It doesn't matter if there's another document, which claims it is. Jernej >> >> /martin > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From andy@yumaworks.com Wed Nov 6 06:33:56 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A5EC11E8165 for ; Wed, 6 Nov 2013 06:33:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.391 X-Spam-Level: X-Spam-Status: No, score=-1.391 tagged_above=-999 required=5 tests=[AWL=-1.281, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t3728nyds04A for ; Wed, 6 Nov 2013 06:33:52 -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 AA24611E8195 for ; Wed, 6 Nov 2013 06:33:51 -0800 (PST) Received: by mail-qa0-f46.google.com with SMTP id j7so2182282qaq.19 for ; Wed, 06 Nov 2013 06:33:49 -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=4NQoiIxx+IGKRQyCSqJW17fGtdmfIOeG0g6XMgUV1aY=; b=XqCD3/r+WS04fj779PjwVUU/jj3VTuofgpK0cv09OGdd2+ztqSTEL40iAaspt0bKR7 z9Q6kH1lk2P8i3unZv3GxFIWSkHsfBJ9H9Qsc2lbnFVC9ep+MJU+yrRNHokX+l5yvmXl bgr39/hNNcWKc/BqpUSeJg0c/xoKRBQG+2j1Xhv4HSETjWPf7glreFgE2j1Wfu/RPOLJ zlrAW5Si3iWyYa8mZZa6qP5wauM2IIpHRw0HssvLv+vpGeH/3QUc1BM6UqK2kvEOx5We 7OH9a7IjIKTwutkAxtXf8P5wOcWeGrGKT6rm2/96K7rfpm9xBhO1htUITHABvP60EVvO G4AQ== X-Gm-Message-State: ALoCoQn90r+2DxrGJLgavgeq0Hh98FKxz2NeH5VNQV7sHDywe/+10H1lkKmJZrFJvPhbd/YSJJ+c MIME-Version: 1.0 X-Received: by 10.49.71.131 with SMTP id v3mr4678171qeu.85.1383748429599; Wed, 06 Nov 2013 06:33:49 -0800 (PST) Received: by 10.140.100.203 with HTTP; Wed, 6 Nov 2013 06:33:49 -0800 (PST) In-Reply-To: <527A155C.6010605@mg-soft.com> References: <20131025.170154.518459007.mbj@tail-f.com> <0840D035-DF82-4436-85DC-8DA59D414BB7@nic.cz> <20131025.192445.290343408.mbj@tail-f.com> <527A155C.6010605@mg-soft.com> Date: Wed, 6 Nov 2013 06:33:49 -0800 Message-ID: From: Andy Bierman To: Jernej Tuljak Content-Type: multipart/alternative; boundary=047d7b5d59729aec5b04ea83092e Cc: "netmod@ietf.org" Subject: Re: [netmod] Fw: New Version Notification for draft-bjorklund-netmod-yang-xpath-extensions-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 14:33:56 -0000 --047d7b5d59729aec5b04ea83092e Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable On Wed, Nov 6, 2013 at 2:09 AM, Jernej Tuljak wro= te: > Dne 25.10.2013 21:06, pi=B9e Ladislav Lhotka: > >> On 25 Oct 2013, at 19:24, Martin Bjorklund wrote: >> >> Ladislav Lhotka wrote: >>> >>>> On 25 Oct 2013, at 17:01, Martin Bjorklund wrote: >>>> >>>> Ladislav Lhotka wrote: >>>>> >>>>>> If the server doesn't advertise the "ietf-yang-xpath-extensions" >>>>>> module, can >>>>>> other advertized modules still use new XPath functions in "must" and >>>>>> "when", >>>>>> if >>>>>> they import that module? >>>>>> >>>>> Yes. Note that all XPath expressions are conceptual. If a server >>>>> claims that it implements a module that uses such an xpath function, >>>>> it must implement the contraint somehow. It doesn't have to use an >>>>> XPath evaluator; it can be implemented in code - just like ane >>>>> constraints defined in description statements. >>>>> >>>> Yes, but one has to be careful with revisions - sec. 10 in RFC 6020 >>>> allows new >>>> extensions in an updated module, but I think in this case it could be >>>> dangerous >>>> because the server cannot easily ignore unknown functions appearing in >>>> XPath >>>> expressions. >>>> >>> You typcially do not just load a new module into a server; it needs >>> some instrumentation to be useful. So a new revison that uses some >>> new XPath functions or not needs an implemention effort in the >>> server. >>> >>> But maybe I misunderstood your concern? >>> >> Sec. 6.3.1 says: >> >> If a YANG compiler does not support a particular extension, which appear= s >> in a YANG module as an unknown-statement (see Section 12), the entire >> unknown-statement MAY be ignored by the compiler. >> >> So my point here is that while ignoring extensions is easy because they >> are self-contained, it is not the case for extensions in XPath expressio= ns. >> But maybe it is not an issue. >> >> Lada >> >> > It is an issue. I share Ladislav's concerns and add my own. I do not thin= k > YANG extensions should be used for extending the value space of an existi= ng > YANG statement's argument (not this way). Extensions should only be allow= ed > to extend YANG statement structure, thus providing new YANG statements wi= th > special meaning, which may or may not be utilized in YANG client code. Th= e > purpose of the "extension" statement is to define a keyword (7.17.). A > must/when statement argument is a string, not a keyword. 7.17. also never > mentions extensions being used/utilized in any way other than as _YANG > statements_. In my view, importing a module that contains an extension's > definition is not enough to "use/utilize" an extension. A YANG unknown > statement is also required. > > While I agree that additional XPath functions would greatly benefit YANG > language, I do not like the way this draft introduces them for usage. I > think that the proper way of introducing them would be to simply create > yangxp:must and yangxp:when extensions, alternatives to RFC6020 statement= s, > which would allow extended XPath syntax in their arguments. > > IMO, all extensions should be self-contained, meaning no side-effects. > Extending (augmenting actually) arbitrary statement arguments is a > side-effect - you have to change valid YANG syntax into something else in > order to use it. And use of an unsupported extension should under no > circumstances result in compiler error, but it clearly does with this dra= ft > (unknown XPath function). > > You seem to be saying that as a modeler, I can now supposedly declare > support for an extension by simply importing a module and using a specifi= c > character sequence inside a standard YANG statement argument (string), ye= t > I'm not even at liberty to make a decision about that. That is an > implementor's job, later in the development cycle. > > An actual problematic modeling use case: > 1. you are using a YANG development IDE and have just defined > ietf-yang-xpath-extensions module > 2. you create a new module that imports ietf-yang-xpath-extensions > 3. you create a must statement which uses an extended XPath function from > ietf-yang-xpath-extensions > 4. you expect the IDE's compiler to be quiet about the unknown function? > > I'd say no. It should raise hell because the offending must statement is > clearly not YANG, nor is it an extension. Note that this case is applicab= le > to any extension that would presume it is okay to distort an existing > statement's argument value space. I could, for example, augment a revisio= n > statement's argument with some extra chars, and then expect compilers to > keep quiet. I could also make namespace statement's argument not comply t= o > URI syntax and expect it to be okay. Semantically, there's no difference > between doing either of those and what this draft is attempting to do. Th= at > is, legalizing _deviations of standard YANG syntax_ in a way that is > undefined from a RFC6020 compiler's perspective. Forget server > instrumentation code. This is a language problem and has nothing to do wi= th > implementors or server-side. Are you allowing YANG description statements= , > children of an extension definition statement, to govern argument syntax = of > existing standard YANG statements, by them merely being present somewhere > in the module chain? That is the real question here and I'd like to see > RFC6020 text that allows this to be considered as something that is > actually plausible. > > Can you verify that this is a real problem in specific tool chains? AFAIK, yangdump is the only offline validation tool that completely checks must/when statements. SInce XPath in groupings has a few corner-cases that would fool the compiler, full validation of XPath can only occur on "cooked" YANG (all uses/refine/deviations resolved). Even if yangdump found an unknown function it would be a warning not an error. >From my interpretation of XPath 1.0, the function library and variable set could be injected at run-time, so the yuma code allows for that. Servers can be smart enough to deal with this new extension, even with automation tools. It requires a significant development effort, but it's just another internal callback API loaded with the server instrumentation library for the YANG module. I agree this use of a YANG extension pushes the limits and could appear to violate the rule about MAY skip over unknown statements, but I think Martin's solution is the best way to add this feature to YANG 1.0. A few of us have laundry lists of improvements we would like to add to YANG. We could easily spend 3 years working on YANG 2.0. IMO we need to get some content out there. We need other WGs developing YANG modules (like ACL, topology). Jernej > > >>> /martin >>> >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C >> >> >> 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 > --047d7b5d59729aec5b04ea83092e Content-Type: text/html; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable



On Wed, Nov 6, 2013 at 2:09 AM, Jernej Tuljak <= ;jernej.tulja= k@mg-soft.si> wrote:
Dne 25.10.2013 21:06, pi=B9e Ladislav Lhotka:
On 25 Oct 2013, at 19:24, Martin Bjorklund <mbj@tail-f.com> wrote:

Ladislav Lhotka <lhot= ka@nic.cz> wrote:
On 25 Oct 2013, at 17:01, Martin Bjorklund <mbj@tail-f.com> wrote:

Ladislav Lhotka <lhot= ka@nic.cz> wrote:
If the server doesn't advertise the "ietf-yang-xpath-extensions&qu= ot; module, can
other advertized modules still use new XPath functions in "must" = and "when",
if
they import that module?
Yes. =A0Note that all XPath expressions are conceptual. =A0If a server
claims that it implements a module that uses such an xpath function,
it must implement the contraint somehow. =A0It doesn't have to use an XPath evaluator; it can be implemented in code - just like ane
constraints defined in description statements.
Yes, but one has to be careful with revisions - sec. 10 in RFC 6020 allows = new
extensions in an updated module, but I think in this case it could be dange= rous
because the server cannot easily ignore unknown functions appearing in XPat= h
expressions.
You typcially do not just load a new module into a server; it needs
some instrumentation to be useful. =A0So a new revison that uses some
new XPath functions or not needs an implemention effort in the
server.

But maybe I misunderstood your concern?
Sec. 6.3.1 says:

If a YANG compiler does not support a particular extension, which appears i= n a YANG module as an unknown-statement (see Section 12), the entire unknow= n-statement MAY be ignored by the compiler.

So my point here is that while ignoring extensions is easy because they are= self-contained, it is not the case for extensions in XPath expressions. Bu= t maybe it is not an issue.

Lada


It is an issue. I share Ladislav's concerns and add my own. I do not th= ink YANG extensions should be used for extending the value space of an exis= ting YANG statement's argument (not this way). Extensions should only b= e allowed to extend YANG statement structure, thus providing new YANG state= ments with special meaning, which may or may not be utilized in YANG client= code. The purpose of the "extension" statement is to define a ke= yword (7.17.). A must/when statement argument is a string, not a keyword. 7= .17. also never mentions extensions being used/utilized in any way other th= an as _YANG statements_. In my view, importing a module that contains an ex= tension's definition is not enough to "use/utilize" an extens= ion. A YANG unknown statement is also required.

While I agree that additional XPath functions would greatly benefit YANG la= nguage, I do not like the way this draft introduces them for usage. I think= that the proper way of introducing them would be to simply create yangxp:m= ust and yangxp:when extensions, alternatives to RFC6020 statements, which w= ould allow extended XPath syntax in their arguments.

IMO, all extensions should be self-contained, meaning no side-effects. Exte= nding (augmenting actually) arbitrary statement arguments is a side-effect = - you have to change valid YANG syntax into something else in order to use = it. And use of an unsupported extension should under no circumstances resul= t in compiler error, but it clearly does with this draft (unknown XPath fun= ction).

You seem to be saying that as a modeler, I can now supposedly declare suppo= rt for an extension by simply importing a module and using a specific chara= cter sequence inside a standard YANG statement argument (string), yet I'= ;m not even at liberty to make a decision about that. That is an implemento= r's job, later in the development cycle.

An actual problematic modeling use case:
1. you are using a YANG development IDE and have just defined ietf-yang-xpa= th-extensions module
2. you create a new module that imports ietf-yang-xpath-extensions
3. you create a must statement which uses an extended XPath function from i= etf-yang-xpath-extensions
4. you expect the IDE's compiler to be quiet about the unknown function= ?

I'd say no. It should raise hell because the offending must statement i= s clearly not YANG, nor is it an extension. Note that this case is applicab= le to any extension that would presume it is okay to distort an existing st= atement's argument value space. I could, for example, augment a revisio= n statement's argument with some extra chars, and then expect compilers= to keep quiet. I could also make namespace statement's argument not co= mply to URI syntax and expect it to be okay. Semantically, there's no d= ifference between doing either of those and what this draft is attempting t= o do. That is, legalizing _deviations of standard YANG syntax_ in a way tha= t is undefined from a RFC6020 compiler's perspective. Forget server ins= trumentation code. This is a language problem and has nothing to do with im= plementors or server-side. Are you allowing YANG description statements, ch= ildren of an extension definition statement, to govern argument syntax of e= xisting standard YANG statements, by them merely being present somewhere in= the module chain? That is the real question here and I'd like to see R= FC6020 text that allows this to be considered as something that is actually= plausible.



Can you verify that thi= s is a real problem in specific tool chains?
AFAIK, yangdump is t= he only offline validation tool that completely checks must/when
statements. SInce XPath in groupings has a few corner-cases that would fool= the compiler,
full validation of XPath can only occur on "c= ooked" YANG (all uses/refine/deviations resolved).
Even if y= angdump found an unknown function it would be a warning not an error.

From my interpretation of XPath 1.0, the function libra= ry and variable set could be
injected at run-time, so the yuma co= de allows for that.
Servers can be smart enough to deal with this= new extension, even with automation tools.
It requires a significant development effort, but it's just anothe= r internal callback API
loaded with the server instrumentation li= brary for the YANG module.

I agree this use of a Y= ANG extension pushes the limits and could appear to violate
the rule about MAY skip over unknown statements, but I think Martin= 9;s solution
is the best way to add this feature to YANG 1.0. =A0= A few of us have laundry lists
of improvements we would like to a= dd to YANG. =A0We could easily spend 3 years working
on YANG 2.0. IMO we need to get some content out there. =A0We need
other WGs developing YANG modules (like ACL, topology).

Jernej


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




Andy
=
=A0


_______________________________________________
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

--047d7b5d59729aec5b04ea83092e-- From lhotka@nic.cz Wed Nov 6 07:14:00 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5779721F9AA2 for ; Wed, 6 Nov 2013 07:14:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.497 X-Spam-Level: X-Spam-Status: No, score=-1.497 tagged_above=-999 required=5 tests=[AWL=-0.402, BAYES_00=-2.599, HOST_EQ_CZ=0.904, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JHdKwHE+SVcT for ; Wed, 6 Nov 2013 07:13:55 -0800 (PST) Received: from trail.lhotka.name (nat-5.bravonet.cz [77.48.224.5]) by ietfa.amsl.com (Postfix) with ESMTP id 90D9211E8198 for ; Wed, 6 Nov 2013 07:13:55 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 357885402A2 for ; Wed, 6 Nov 2013 16:13:54 +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 FYpU9XakmWcq for ; Wed, 6 Nov 2013 16:13:50 +0100 (CET) Received: from localhost (unknown [64.114.24.114]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id E1B5154012B for ; Wed, 6 Nov 2013 16:13:45 +0100 (CET) From: Ladislav Lhotka To: netmod@ietf.org In-Reply-To: References: <00C11A98-1758-48A4-8182-38E0F8F31C79@nic.cz> <20131105.164156.397349935.mbj@tail-f.com> User-Agent: Notmuch/0.15.2 (http://notmuchmail.org) Emacs/23.4.1 (x86_64-apple-darwin12.3.0) Mail-Followup-To: netmod@ietf.org Date: Wed, 06 Nov 2013 07:13:43 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [netmod] Last chance for review: draft-ietf-netmod-ip-cfg & draft-ietf-netmod-ip-cfg X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 15:14:00 -0000 Hi, one idea, maybe - would it help to add a leaf like this? leaf if-type { if-feature if-mib; type ianaift:iana-if-type; } The document "draft-ietf-netmod-iana-if-type" could then remain unchanged, and the keys of the interface list would be incrementally defined identities, along the lines of Martin's original proposal. Lada David Kessens writes: > But you side step the question whether you can live with Andy's proposal or > not. > > We really need to bring this to closure. > > As the document shepherd/working group co-chair, I cannot move this > document to the next stage if we don't know where people stand. > > David Kessens > --- > > > On Tue, Nov 5, 2013 at 4:41 PM, Martin Bjorklund wrote: > >> Ladislav Lhotka wrote: >> > >> > On 05 Nov 2013, at 16:28, Andy Bierman wrote: >> > >> > > Hi, >> > > >> > > The concrete proposal I agreed to on the list was to change the >> > > if-type enums to identities. If you want me to do the emacs >> > > search-and-replace >> > > to convert the enums to identities I can do that. I am not suggesting >> > > that the values in the registry be re-engineered at all. >> > >> > It is not that simple - I assume you want to keep these identities >> > synchronised with the IANA enumeration, right? >> >> I understand the edits Andy wants, and the IANA draft already >> instructs IANA to keep the YANG module in sync with the registry. So >> I think what Andy suggests is easy to do (in the documents). >> >> >> /martin >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >> > > > > -- > > David Kessens > --- -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From jeffrey.K.lange@ge.com Wed Nov 6 07:17:06 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67F7321F9F80 for ; Wed, 6 Nov 2013 07:17:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.736 X-Spam-Level: X-Spam-Status: No, score=-5.736 tagged_above=-999 required=5 tests=[AWL=0.263, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UgcbP8ogatSD for ; Wed, 6 Nov 2013 07:16:52 -0800 (PST) Received: from exprod5og112.obsmtp.com (exprod5og112.obsmtp.com [64.18.0.24]) by ietfa.amsl.com (Postfix) with ESMTP id 321C421F9E9F for ; Wed, 6 Nov 2013 07:16:52 -0800 (PST) Received: from alpmlip10.e2k.ad.ge.com ([12.43.191.1]) (using TLSv1) by exprod5ob112.postini.com ([64.18.4.12]) with SMTP ID DSNKUnpdY/SuQEyLcwLpwX+XEKKJng2fPrxj@postini.com; Wed, 06 Nov 2013 07:16:52 PST Received: from unknown (HELO ALPMBHT01.e2k.ad.ge.com) ([3.159.19.194]) by alpmlip10.e2k.ad.ge.com with ESMTP/TLS/AES128-SHA; 06 Nov 2013 10:16:51 -0500 Received: from CINURCNA11.e2k.ad.ge.com (3.159.212.128) by ALPMBHT01.e2k.ad.ge.com (3.159.19.194) with Microsoft SMTP Server (TLS) id 14.3.146.0; Wed, 6 Nov 2013 10:16:51 -0500 Received: from CINURCNA15.e2k.ad.ge.com ([169.254.3.12]) by CINURCNA11.e2k.ad.ge.com ([169.254.5.157]) with mapi id 14.03.0146.000; Wed, 6 Nov 2013 10:16:50 -0500 From: "Lange, Jeffrey K (GE Energy Management)" To: Ladislav Lhotka , "netmod@ietf.org" Thread-Topic: [netmod] Last chance for review: draft-ietf-netmod-ip-cfg & draft-ietf-netmod-ip-cfg Thread-Index: AQHO2pHbXyvGmj1TTECc6xOHVg5KlZoYpD2A//+svcA= Date: Wed, 6 Nov 2013 15:16:50 +0000 Message-ID: References: <00C11A98-1758-48A4-8182-38E0F8F31C79@nic.cz> <20131105.164156.397349935.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: [3.159.212.187] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [netmod] Last chance for review: draft-ietf-netmod-ip-cfg & draft-ietf-netmod-ip-cfg X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 15:17:06 -0000 > -----Original Message----- > From: netmod-bounces@ietf.org [mailto:netmod-bounces@ietf.org] On Behalf > Of Ladislav Lhotka > Sent: Wednesday, November 06, 2013 10:14 AM > To: netmod@ietf.org > Subject: Re: [netmod] Last chance for review: draft-ietf-netmod-ip-cfg & > draft-ietf-netmod-ip-cfg >=20 > Hi, >=20 > one idea, maybe - would it help to add a leaf like this? >=20 > leaf if-type { > if-feature if-mib; > type ianaift:iana-if-type; > } >=20 > The document "draft-ietf-netmod-iana-if-type" could then remain unchanged= , > and the keys of the interface list would be incrementally defined > identities, along the lines of Martin's original proposal. >=20 Assuming this is part of the interfaces-state tree I really like this idea. -Jeff > Lada >=20 > David Kessens writes: >=20 > > But you side step the question whether you can live with Andy's proposa= l > or > > not. > > > > We really need to bring this to closure. > > > > As the document shepherd/working group co-chair, I cannot move this > > document to the next stage if we don't know where people stand. > > > > David Kessens > > --- > > > > > > On Tue, Nov 5, 2013 at 4:41 PM, Martin Bjorklund wrote= : > > > >> Ladislav Lhotka wrote: > >> > > >> > On 05 Nov 2013, at 16:28, Andy Bierman wrote: > >> > > >> > > Hi, > >> > > > >> > > The concrete proposal I agreed to on the list was to change the > >> > > if-type enums to identities. If you want me to do the emacs > >> > > search-and-replace > >> > > to convert the enums to identities I can do that. I am not > suggesting > >> > > that the values in the registry be re-engineered at all. > >> > > >> > It is not that simple - I assume you want to keep these identities > >> > synchronised with the IANA enumeration, right? > >> > >> I understand the edits Andy wants, and the IANA draft already > >> instructs IANA to keep the YANG module in sync with the registry. So > >> I think what Andy suggests is easy to do (in the documents). > >> > >> > >> /martin > >> _______________________________________________ > >> netmod mailing list > >> netmod@ietf.org > >> https://www.ietf.org/mailman/listinfo/netmod > >> > > > > > > > > -- > > > > David Kessens > > --- >=20 > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From andy@yumaworks.com Wed Nov 6 07:55:34 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EA5221E812F for ; Wed, 6 Nov 2013 07:55:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.504 X-Spam-Level: X-Spam-Status: No, score=-2.504 tagged_above=-999 required=5 tests=[AWL=-0.128, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AwKnN4aW7WE8 for ; Wed, 6 Nov 2013 07:55:30 -0800 (PST) Received: from mail-qa0-f43.google.com (mail-qa0-f43.google.com [209.85.216.43]) by ietfa.amsl.com (Postfix) with ESMTP id D6F8021E811D for ; Wed, 6 Nov 2013 07:55:29 -0800 (PST) Received: by mail-qa0-f43.google.com with SMTP id cm18so2303874qab.9 for ; Wed, 06 Nov 2013 07:55:29 -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=AURYzXBBPZoRIb9RhA5mDslpx4dQJn/7RwEhPBVaYNI=; b=krcypR4N/eld5QtFcUaE5GfSYorh7gMus6z17z2PvX9ZoQaktUAdBcvzkyI8XHVYNX AqviZj8/qc6tTbEWc2mZMpU9NfQkv8g6zOSbpLEYwhGEjwVnUnyI8FUh+nzAWlFdJeVz WPvvAOCcH0aomag17hWFSIQgoLfd4q7C7GtV/K1ei2o/ZNRXM7i33Ksl0a7VnRNYnmoV GKBOS/XhFPkOu6kCIYBj7RJ65QAVrnINjmIPgKAFCwBIcMm1oJsAvRHR8JsuMHw+CJSc hYuDflu0s2Xq3QOyKqDRcK7DTQ3eTFbmVLMZL15BDfZr45SyaukTlSV1oIh8rtHAOkyZ DM3g== X-Gm-Message-State: ALoCoQnBFKZSm8u93BZDVKP9N8peUxLe5G/oN1xW9Q5O53vJrulecJH9dMK+wKLZunlB5t2OszTH MIME-Version: 1.0 X-Received: by 10.224.114.196 with SMTP id f4mr6829569qaq.96.1383753329282; Wed, 06 Nov 2013 07:55:29 -0800 (PST) Received: by 10.140.100.203 with HTTP; Wed, 6 Nov 2013 07:55:29 -0800 (PST) In-Reply-To: References: <00C11A98-1758-48A4-8182-38E0F8F31C79@nic.cz> <20131105.164156.397349935.mbj@tail-f.com> Date: Wed, 6 Nov 2013 07:55:29 -0800 Message-ID: From: Andy Bierman To: "netmod@ietf.org" Content-Type: multipart/alternative; boundary=047d7bdca7f4a626aa04ea842d05 Subject: Re: [netmod] Last chance for review: draft-ietf-netmod-ip-cfg & draft-ietf-netmod-ip-cfg X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 15:55:34 -0000 --047d7bdca7f4a626aa04ea842d05 Content-Type: text/plain; charset=ISO-8859-1 Hi, This does not really address the problem because this leaf would not be available unless the if-mib feature was supported, or the fact that there are not going to be any standard YANG modules defining identities. An empty set of identities is effectively a proprietary solution. I do not see any standards value for 3rd party application developers if interface types are all proprietary. There is no reason that the current enums could not populate the set of identities from the start. It can be improved over time. IMO there is no value in creating a tree of identifiers. A hierarchical classification system for interface types is not in the charter. Andy On Wed, Nov 6, 2013 at 7:13 AM, Ladislav Lhotka wrote: > Hi, > > one idea, maybe - would it help to add a leaf like this? > > leaf if-type { > if-feature if-mib; > type ianaift:iana-if-type; > } > > The document "draft-ietf-netmod-iana-if-type" could then remain unchanged, > and the keys of the interface list would be incrementally defined > identities, along the lines of Martin's original proposal. > > Lada > > David Kessens writes: > > > But you side step the question whether you can live with Andy's proposal > or > > not. > > > > We really need to bring this to closure. > > > > As the document shepherd/working group co-chair, I cannot move this > > document to the next stage if we don't know where people stand. > > > > David Kessens > > --- > > > > > > On Tue, Nov 5, 2013 at 4:41 PM, Martin Bjorklund wrote: > > > >> Ladislav Lhotka wrote: > >> > > >> > On 05 Nov 2013, at 16:28, Andy Bierman wrote: > >> > > >> > > Hi, > >> > > > >> > > The concrete proposal I agreed to on the list was to change the > >> > > if-type enums to identities. If you want me to do the emacs > >> > > search-and-replace > >> > > to convert the enums to identities I can do that. I am not > suggesting > >> > > that the values in the registry be re-engineered at all. > >> > > >> > It is not that simple - I assume you want to keep these identities > >> > synchronised with the IANA enumeration, right? > >> > >> I understand the edits Andy wants, and the IANA draft already > >> instructs IANA to keep the YANG module in sync with the registry. So > >> I think what Andy suggests is easy to do (in the documents). > >> > >> > >> /martin > >> _______________________________________________ > >> netmod mailing list > >> netmod@ietf.org > >> https://www.ietf.org/mailman/listinfo/netmod > >> > > > > > > > > -- > > > > David Kessens > > --- > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --047d7bdca7f4a626aa04ea842d05 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

This does not really address the pr= oblem because this leaf would not
be available unless the if-mib = feature was supported, or the fact that
there are not going to be= any standard YANG modules defining identities.

An empty set of identities is effectively a proprietary= solution.
I do not see any standards value for 3rd party applica= tion developers
if interface types are all proprietary.

There is no reason that the current enums could not pop= ulate the
set of identities from the start. =A0It can be improved= over time.
IMO there is no value in creating a tree of identifie= rs. =A0A hierarchical
classification system for interface types is not in the charter.
=


Andy


=
On Wed, Nov 6, 2= 013 at 7:13 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
Hi,

one idea, maybe - would it help to add a leaf like this?

leaf if-type {
=A0 if-feature if-mib;
=A0 type ianaift:iana-if-type;
}

The document "draft-ietf-netmod-iana-if-type" could then remain u= nchanged, and the keys of the interface list would be incrementally defined= identities, along the lines of Martin's original proposal.

Lada

David Kessens <david.kessens@= gmail.com> writes:

> But you side step the question whether you can live with Andy's pr= oposal or
> not.
>
> We really need to bring this to closure.
>
> As the document shepherd/working group co-chair, I cannot move this > document to the next stage if we don't know where people stand. >
> David Kessens
> ---
>
>
> On Tue, Nov 5, 2013 at 4:41 PM, Martin Bjorklund <mbj@tail-f.com> wrote:
>
>> Ladislav Lhotka <lhotka@nic.cz= > wrote:
>> >
>> > On 05 Nov 2013, at 16:28, Andy Bierman <andy@yumaworks.com> wrote:
>> >
>> > > Hi,
>> > >
>> > > The concrete proposal I agreed to on the list was to cha= nge the
>> > > if-type enums to identities. =A0If you want me to do the= emacs
>> > > search-and-replace
>> > > to convert the enums to identities I can do that. =A0I a= m not suggesting
>> > > that the values in the registry be re-engineered at all.=
>> >
>> > It is not that simple - I assume you want to keep these ident= ities
>> > synchronised with the IANA enumeration, right?
>>
>> I understand the edits Andy wants, and the IANA draft already
>> instructs IANA to keep the YANG module in sync with the registry. = =A0So
>> I think what Andy suggests is easy to do (in the documents).
>>
>>
>> /martin
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>>
>
>
>
> --
>
> David Kessens
> ---

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

--047d7bdca7f4a626aa04ea842d05-- From mbj@tail-f.com Wed Nov 6 08:40:10 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE97421E8134 for ; Wed, 6 Nov 2013 08:40:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.915 X-Spam-Level: X-Spam-Status: No, score=-1.915 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uzhwC9B1wsrD for ; Wed, 6 Nov 2013 08:40:05 -0800 (PST) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id EE3CC21E8133 for ; Wed, 6 Nov 2013 08:40:04 -0800 (PST) Received: from localhost (dhcp-90fa.meeting.ietf.org [31.133.144.250]) by mail.tail-f.com (Postfix) with ESMTPSA id 152A21200453; Wed, 6 Nov 2013 17:40:02 +0100 (CET) Date: Wed, 06 Nov 2013 08:39:57 -0800 (PST) Message-Id: <20131106.083957.438880938.mbj@tail-f.com> To: jernej.tuljak@mg-soft.si From: Martin Bjorklund In-Reply-To: <527A155C.6010605@mg-soft.com> References: <20131025.192445.290343408.mbj@tail-f.com> <527A155C.6010605@mg-soft.com> X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-15 Content-Transfer-Encoding: quoted-printable Cc: netmod@ietf.org Subject: Re: [netmod] Fw: New Version Notification for draft-bjorklund-netmod-yang-xpath-extensions-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 16:40:11 -0000 Hi, Jernej Tuljak wrote: > Dne 25.10.2013 21:06, pi=A8e Ladislav Lhotka: > > On 25 Oct 2013, at 19:24, Martin Bjorklund wrote: > > > >> Ladislav Lhotka wrote: > >>> On 25 Oct 2013, at 17:01, Martin Bjorklund wrote= : > >>> > >>>> Ladislav Lhotka wrote: > >>>>> If the server doesn't advertise the "ietf-yang-xpath-extensions= " > >>>>> module, can > >>>>> other advertized modules still use new XPath functions in "must= " and > >>>>> "when", > >>>>> if > >>>>> they import that module? > >>>> Yes. Note that all XPath expressions are conceptual. If a serv= er > >>>> claims that it implements a module that uses such an xpath funct= ion, > >>>> it must implement the contraint somehow. It doesn't have to use= an > >>>> XPath evaluator; it can be implemented in code - just like ane > >>>> constraints defined in description statements. > >>> Yes, but one has to be careful with revisions - sec. 10 in RFC 60= 20 > >>> allows new > >>> extensions in an updated module, but I think in this case it coul= d be > >>> dangerous > >>> because the server cannot easily ignore unknown functions appeari= ng in > >>> XPath > >>> expressions. > >> You typcially do not just load a new module into a server; it need= s > >> some instrumentation to be useful. So a new revison that uses som= e > >> new XPath functions or not needs an implemention effort in the > >> server. > >> > >> But maybe I misunderstood your concern? > > Sec. 6.3.1 says: > > > > If a YANG compiler does not support a particular extension, which > > appears in a YANG module as an unknown-statement (see Section 12), = the > > entire unknown-statement MAY be ignored by the compiler. > > > > So my point here is that while ignoring extensions is easy because > > they are self-contained, it is not the case for extensions in XPath= > > expressions. But maybe it is not an issue. > > > > Lada > > > = > It is an issue. I share Ladislav's concerns and add my own. I do not > think YANG extensions should be used for extending the value space of= > an existing YANG statement's argument (not this way). Please note that this draft updates 6020, see section "XPath Evaluation Context". Without this section you are right - extensions cannot arbitrarily make changes like this. This is why a new RFC is needed. /martin From mbj@tail-f.com Wed Nov 6 08:55:34 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B9CF21E815B for ; Wed, 6 Nov 2013 08:55:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.928 X-Spam-Level: X-Spam-Status: No, score=-1.928 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7AQejb5VQ5bR for ; Wed, 6 Nov 2013 08:55:28 -0800 (PST) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id A0D1E21E8082 for ; Wed, 6 Nov 2013 08:55:28 -0800 (PST) Received: from localhost (dhcp-90fa.meeting.ietf.org [31.133.144.250]) by mail.tail-f.com (Postfix) with ESMTPSA id 773621200054; Wed, 6 Nov 2013 17:55:26 +0100 (CET) Date: Wed, 06 Nov 2013 08:55:24 -0800 (PST) Message-Id: <20131106.085524.146028830.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: References: <20131105.164156.397349935.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] Last chance for review: draft-ietf-netmod-ip-cfg & draft-ietf-netmod-ip-cfg X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 16:55:34 -0000 Hi, Ladislav Lhotka wrote: > Hi, > > one idea, maybe - would it help to add a leaf like this? > > leaf if-type { > if-feature if-mib; > type ianaift:iana-if-type; > } If this is in config I think it would be worse. You don't want the user to have to figure out two values to fill in. And if it is in oper state only it doesn't address Andy's concern. So I prefer Andy's solution over this. /martin From jeffrey.K.lange@ge.com Wed Nov 6 09:04:57 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFA8311E820E for ; Wed, 6 Nov 2013 09:04:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.052 X-Spam-Level: X-Spam-Status: No, score=-6.052 tagged_above=-999 required=5 tests=[AWL=0.547, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wp6k07jV78YR for ; Wed, 6 Nov 2013 09:04:51 -0800 (PST) Received: from exprod5og105.obsmtp.com (exprod5og105.obsmtp.com [64.18.0.180]) by ietfa.amsl.com (Postfix) with ESMTP id D44C211E81FF for ; Wed, 6 Nov 2013 09:04:50 -0800 (PST) Received: from cinmlip14.e2k.ad.ge.com ([165.156.4.1]) (using TLSv1) by exprod5ob105.postini.com ([64.18.4.12]) with SMTP ID DSNKUnp2sgMtLDH9gNhp4cmOZPpNiKnIcs1F@postini.com; Wed, 06 Nov 2013 09:04:50 PST Received: from unknown (HELO CINMBHT04.e2k.ad.ge.com) ([3.159.212.197]) by cinmlip14.e2k.ad.ge.com with ESMTP/TLS/AES128-SHA; 06 Nov 2013 12:04:47 -0500 Received: from CINURCNA16.e2k.ad.ge.com (3.159.212.153) by CINMBHT04.e2k.ad.ge.com (3.159.212.197) with Microsoft SMTP Server (TLS) id 14.3.146.0; Wed, 6 Nov 2013 12:04:47 -0500 Received: from CINURCNA15.e2k.ad.ge.com ([169.254.3.12]) by CINURCNA16.e2k.ad.ge.com ([169.254.4.207]) with mapi id 14.03.0146.000; Wed, 6 Nov 2013 12:04:47 -0500 From: "Lange, Jeffrey K (GE Energy Management)" To: Martin Bjorklund , "lhotka@nic.cz" Thread-Topic: [netmod] Last chance for review: draft-ietf-netmod-ip-cfg & draft-ietf-netmod-ip-cfg Thread-Index: AQHO2xEPgHXRdZMee0u6XdKtQ0JNi5oYbdqg Date: Wed, 6 Nov 2013 17:04:46 +0000 Message-ID: References: <20131105.164156.397349935.mbj@tail-f.com> <20131106.085524.146028830.mbj@tail-f.com> In-Reply-To: <20131106.085524.146028830.mbj@tail-f.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [3.159.212.187] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "netmod@ietf.org" Subject: Re: [netmod] Last chance for review: draft-ietf-netmod-ip-cfg & draft-ietf-netmod-ip-cfg X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 17:04:57 -0000 > -----Original Message----- > From: netmod-bounces@ietf.org [mailto:netmod-bounces@ietf.org] On Behalf > Of Martin Bjorklund > Sent: Wednesday, November 06, 2013 11:55 AM > To: lhotka@nic.cz > Cc: netmod@ietf.org > Subject: Re: [netmod] Last chance for review: draft-ietf-netmod-ip-cfg & > draft-ietf-netmod-ip-cfg >=20 > Hi, >=20 > Ladislav Lhotka wrote: > > Hi, > > > > one idea, maybe - would it help to add a leaf like this? > > > > leaf if-type { > > if-feature if-mib; > > type ianaift:iana-if-type; > > } >=20 > If this is in config I think it would be worse. You don't want the > user to have to figure out two values to fill in. >=20 > And if it is in oper state only it doesn't address Andy's concern. >=20 If the concern is that there is no "standard" way to retrieve the interface= type that is compatible with SNMP, then I think this does address that. If= you do not implement the if-mib feature, you are already saying that you d= on't care about compatibility with the SNMP defined types. -Jeff > So I prefer Andy's solution over this. >=20 >=20 > /martin > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From mbj@tail-f.com Wed Nov 6 09:09:09 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0A7A21F9EAF for ; Wed, 6 Nov 2013 09:09:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.939 X-Spam-Level: X-Spam-Status: No, score=-1.939 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CYtZZ5hvDzSQ for ; Wed, 6 Nov 2013 09:09:03 -0800 (PST) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id B32EB11E820E for ; Wed, 6 Nov 2013 09:09:02 -0800 (PST) Received: from localhost (dhcp-90fa.meeting.ietf.org [31.133.144.250]) by mail.tail-f.com (Postfix) with ESMTPSA id 47EA41200054; Wed, 6 Nov 2013 18:09:01 +0100 (CET) Date: Wed, 06 Nov 2013 09:08:59 -0800 (PST) Message-Id: <20131106.090859.304162439.mbj@tail-f.com> To: jeffrey.K.lange@ge.com From: Martin Bjorklund In-Reply-To: References: <20131106.085524.146028830.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] Last chance for review: draft-ietf-netmod-ip-cfg & draft-ietf-netmod-ip-cfg X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 17:09:09 -0000 "Lange, Jeffrey K (GE Energy Management)" wrote: > > > > -----Original Message----- > > From: netmod-bounces@ietf.org [mailto:netmod-bounces@ietf.org] On > > Behalf > > Of Martin Bjorklund > > Sent: Wednesday, November 06, 2013 11:55 AM > > To: lhotka@nic.cz > > Cc: netmod@ietf.org > > Subject: Re: [netmod] Last chance for review: draft-ietf-netmod-ip-cfg > > & > > draft-ietf-netmod-ip-cfg > > > > Hi, > > > > Ladislav Lhotka wrote: > > > Hi, > > > > > > one idea, maybe - would it help to add a leaf like this? > > > > > > leaf if-type { > > > if-feature if-mib; > > > type ianaift:iana-if-type; > > > } > > > > If this is in config I think it would be worse. You don't want the > > user to have to figure out two values to fill in. > > > > And if it is in oper state only it doesn't address Andy's concern. > > > > If the concern is that there is no "standard" way to retrieve the > interface type that is compatible with SNMP, then I think this does > address that. It does, but that's not the concern. The concern is that since we have set of standard types already, vendors that can and want to should be able to use them w/o defining their own identities. Vendors that cannot use the standard identities (for one or more interfaces), define their own identities. /martin From andy@yumaworks.com Wed Nov 6 09:19:19 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB42F21E812A for ; Wed, 6 Nov 2013 09:19:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.802 X-Spam-Level: X-Spam-Status: No, score=-2.802 tagged_above=-999 required=5 tests=[AWL=0.174, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MjZYTGXdssU6 for ; Wed, 6 Nov 2013 09:19:15 -0800 (PST) Received: from mail-qc0-f181.google.com (mail-qc0-f181.google.com [209.85.216.181]) by ietfa.amsl.com (Postfix) with ESMTP id 6606E11E8112 for ; Wed, 6 Nov 2013 09:19:15 -0800 (PST) Received: by mail-qc0-f181.google.com with SMTP id w4so6065889qcr.40 for ; Wed, 06 Nov 2013 09:19:14 -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=mfT7JDYuNCxozVtX0IxiVE9a2/vfZWq2FOqM8XrgdSc=; b=e8SJmbhvSM9I9kwn81m/qgRu7dpuMA2JT1nGtg6OtVQysxUwQFdUReOx4ANLznVRkr pzEJBfZv0uteeX0Bxs3S5gJfhRiIEReEOIsljU/e3STo5waAHYXEcjvzp4trHHTRyp9O YODY/bhJHiAA610nhRbbRbwrJF8BNAk2TxqmTxHfPxc4uBJ+VzC1j+SQPTGK52Vc2kSh nE3omPSwmTycoMWXq2lQsIELP97iDFdPHvYYOrVFoiEG77C9WVuLMNNjHxC3jBG6tjBq zPbV8oBG+9IQBrmTJ3BBfpa65BEM8iZiUpljYU4OfaGfMdw+cxem75W4B3lEAVL6zL8v qU1Q== X-Gm-Message-State: ALoCoQlTfds17XqxKZgW/Z3cOSF+SOrD3FpX86wU0gs/0m/kLQvQsus54MnJf4AhaeJTUvnnssZS MIME-Version: 1.0 X-Received: by 10.224.114.196 with SMTP id f4mr7430733qaq.96.1383758354622; Wed, 06 Nov 2013 09:19:14 -0800 (PST) Received: by 10.140.100.203 with HTTP; Wed, 6 Nov 2013 09:19:14 -0800 (PST) In-Reply-To: References: <20131105.164156.397349935.mbj@tail-f.com> <20131106.085524.146028830.mbj@tail-f.com> Date: Wed, 6 Nov 2013 09:19:14 -0800 Message-ID: From: Andy Bierman To: "Lange, Jeffrey K (GE Energy Management)" Content-Type: multipart/alternative; boundary=047d7bdca7f42ec5b504ea8559a8 Cc: "netmod@ietf.org" Subject: Re: [netmod] Last chance for review: draft-ietf-netmod-ip-cfg & draft-ietf-netmod-ip-cfg X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 17:19:19 -0000 --047d7bdca7f42ec5b504ea8559a8 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Nov 6, 2013 at 9:04 AM, Lange, Jeffrey K (GE Energy Management) < jeffrey.K.lange@ge.com> wrote: > > > > -----Original Message----- > > From: netmod-bounces@ietf.org [mailto:netmod-bounces@ietf.org] On Behalf > > Of Martin Bjorklund > > Sent: Wednesday, November 06, 2013 11:55 AM > > To: lhotka@nic.cz > > Cc: netmod@ietf.org > > Subject: Re: [netmod] Last chance for review: draft-ietf-netmod-ip-cfg & > > draft-ietf-netmod-ip-cfg > > > > Hi, > > > > Ladislav Lhotka wrote: > > > Hi, > > > > > > one idea, maybe - would it help to add a leaf like this? > > > > > > leaf if-type { > > > if-feature if-mib; > > > type ianaift:iana-if-type; > > > } > > > > If this is in config I think it would be worse. You don't want the > > user to have to figure out two values to fill in. > > > > And if it is in oper state only it doesn't address Andy's concern. > > > > If the concern is that there is no "standard" way to retrieve the > interface type that is compatible with SNMP, then I think this does address > that. If you do not implement the if-mib feature, you are already saying > that you don't care about compatibility with the SNMP defined types. > > The concern is that standard interface types are being thrown out by NETCONF in favor of a proprietary classification system. Standard identifiers are needed for interoperable management of network interfaces. It has nothing to do with SNMP at all. The original problem that you stated was the set of enums was insufficient and identities would allow the gaps to be filled with new interface types (defined outside IANA). This problem does not logically lead to a solution that starts with an empty registry. That creates new problems which are not even related to your initial concern. > -Jeff > Andy > > > So I prefer Andy's solution over this. > > > > > > /martin > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --047d7bdca7f42ec5b504ea8559a8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Wed, Nov 6, 2013 at 9:04 AM, Lange, Jeffrey K (GE Energy Managem= ent) <jeffrey.K.lange@ge.com> wrote:


> -----Original Message-----
> From: netmod-bounces@ietf.o= rg [mailto:netmod-bounces@ie= tf.org] On Behalf
> Of Martin Bjorklund
> Sent: Wednesday, November 06, 2013 11:55 AM
> To: lhotka@nic.cz
> Cc: netmod@ietf.org
> Subject: Re: [netmod] Last chance for review: draft-ietf-netmod-ip-cfg= &
> draft-ietf-netmod-ip-cfg
>
> Hi,
>
> Ladislav Lhotka <lhotka@nic.cz= > wrote:
> > Hi,
> >
> > one idea, maybe - would it help to add a leaf like this?
> >
> > leaf if-type {
> > =A0 if-feature if-mib;
> > =A0 type ianaift:iana-if-type;
> > }
>
> If this is in config I think it would be worse. =A0You don't want = the
> user to have to figure out two values to fill in.
>
> And if it is in oper state only it doesn't address Andy's conc= ern.
>

If the concern is that there is no "standard" way to retrieve the= interface type that is compatible with SNMP, then I think this does addres= s that. If you do not implement the if-mib feature, you are already saying = that you don't care about compatibility with the SNMP defined types.

The concern is that standard interface= types are being thrown out by NETCONF in favor
of a proprietary = classification system. =A0Standard identifiers are needed for interoperable= management
of network interfaces. =A0It has =A0nothing to do with SNMP at all.

The original problem that you stated was the set of = enums was insufficient and identities would
allow the gaps to be = filled with new interface types (defined outside IANA). =A0This problem doe= s
not logically lead to a solution that starts with an empty registry. = =A0That creates new problems
which are not even related to your i= nitial concern.


=A0
-Jeff

Andy

=A0=

> So I prefer Andy's solution over this.
>
>
> /martin
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
netmod@ietf.org
= https://www.ietf.org/mailman/listinfo/netmod

--047d7bdca7f42ec5b504ea8559a8-- From lhotka@nic.cz Wed Nov 6 11:31:49 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1292511E81C7 for ; Wed, 6 Nov 2013 11:31:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.321 X-Spam-Level: X-Spam-Status: No, score=-1.321 tagged_above=-999 required=5 tests=[AWL=-0.226, BAYES_00=-2.599, HOST_EQ_CZ=0.904, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5lsli0hMn-Rw for ; Wed, 6 Nov 2013 11:31:31 -0800 (PST) Received: from trail.lhotka.name (nat-5.bravonet.cz [77.48.224.5]) by ietfa.amsl.com (Postfix) with ESMTP id 1F6AA21E80C3 for ; Wed, 6 Nov 2013 11:31:27 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id F340C5402A2; Wed, 6 Nov 2013 20:31:25 +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 c2BCoKf7o2K6; Wed, 6 Nov 2013 20:31:21 +0100 (CET) Received: from localhost (dhcp-a49d.meeting.ietf.org [31.133.164.157]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 97E3D54012B; Wed, 6 Nov 2013 20:31:15 +0100 (CET) From: Ladislav Lhotka To: Andy Bierman , Jernej Tuljak In-Reply-To: References: <20131025.170154.518459007.mbj@tail-f.com> <0840D035-DF82-4436-85DC-8DA59D414BB7@nic.cz> <20131025.192445.290343408.mbj@tail-f.com> <527A155C.6010605@mg-soft.com> User-Agent: Notmuch/0.15.2 (http://notmuchmail.org) Emacs/23.4.1 (x86_64-apple-darwin12.3.0) Mail-Followup-To: Andy Bierman , Jernej Tuljak , "netmod\@ietf.org" Date: Wed, 06 Nov 2013 11:31:12 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "netmod@ietf.org" Subject: Re: [netmod] Fw: New Version Notification for draft-bjorklund-netmod-yang-xpath-extensions-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 19:31:49 -0000 Andy Bierman writes: > > Can you verify that this is a real problem in specific tool chains? > AFAIK, yangdump is the only offline validation tool that completely checks > must/when DSDL mapping, as implemented in pyang, does it, too. > statements. SInce XPath in groupings has a few corner-cases that would fool > the compiler, > full validation of XPath can only occur on "cooked" YANG (all > uses/refine/deviations resolved). > Even if yangdump found an unknown function it would be a warning not an > error. > > From my interpretation of XPath 1.0, the function library and variable set > could be > injected at run-time, so the yuma code allows for that. No, this is not possible, and RFC 6020 is very clear in this sense. Some tools do allow for extensions, and support some like EXSLT. While it is possible to write an extension to xsltproc, it is not the version that people have installed on their computers. So this discussion also shows the division line between YANG tools that are home-baked, and those that use standard XML tools. Lada > Servers can be smart enough to deal with this new extension, even with > automation tools. > It requires a significant development effort, but it's just another > internal callback API > loaded with the server instrumentation library for the YANG module. > > I agree this use of a YANG extension pushes the limits and could appear to > violate > the rule about MAY skip over unknown statements, but I think Martin's > solution > is the best way to add this feature to YANG 1.0. A few of us have laundry > lists > of improvements we would like to add to YANG. We could easily spend 3 > years working > on YANG 2.0. IMO we need to get some content out there. We need > other WGs developing YANG modules (like ACL, topology). > > > Jernej >> >> >>>> /martin >>>> >>> -- >>> Ladislav Lhotka, CZ.NIC Labs >>> PGP Key ID: E74E8C0C >>> >>> >>> > > 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 >> -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From mbj@tail-f.com Wed Nov 6 11:36:40 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A2DB21F9C53 for ; Wed, 6 Nov 2013 11:36:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.948 X-Spam-Level: X-Spam-Status: No, score=-1.948 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I0DojHVI6A7c for ; Wed, 6 Nov 2013 11:36:34 -0800 (PST) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id B853121F9D11 for ; Wed, 6 Nov 2013 11:36:33 -0800 (PST) Received: from localhost (dhcp-a2ae.meeting.ietf.org [31.133.162.174]) by mail.tail-f.com (Postfix) with ESMTPSA id 3B07F1200054; Wed, 6 Nov 2013 20:36:30 +0100 (CET) Date: Wed, 06 Nov 2013 11:36:28 -0800 (PST) Message-Id: <20131106.113628.386256580.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: References: <527A155C.6010605@mg-soft.com> X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] Fw: New Version Notification for draft-bjorklund-netmod-yang-xpath-extensions-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 19:36:40 -0000 Hi, Ladislav Lhotka wrote: > So this > discussion also shows the division line between YANG tools that are > home-baked, and those that use standard XML tools. XPath clearly allows custom functions. We should not limit ourselves just b/c there exist some tools that don't support this. /martin From lhotka@nic.cz Wed Nov 6 13:34:39 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBC7221E80A6 for ; Wed, 6 Nov 2013 13:34:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iOMQLV8awy2u for ; Wed, 6 Nov 2013 13:34:39 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 07A5B21E805F for ; Wed, 6 Nov 2013 13:34:39 -0800 (PST) Received: from [172.16.33.134] (unknown [64.114.24.114]) by mail.nic.cz (Postfix) with ESMTPSA id D93BC13F9FC; Wed, 6 Nov 2013 22:34:35 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1383773677; bh=rConn2cgPe805TIXNgvHnJH7rU1cHMQ3EPUJK7FR3Hs=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=SgfTsly13GELOGPvrTd/K3OEhHRLlZX43OQyHP4t4LuaHnPaiL6TJ28jkb1t8lJkI aq2L2VJOOD7pwfxJ/lrOfhqNANzoqODhdOP6tmvVkzMWewUxO00aWRSDbJ69aTQq2o gYCZPIRNmty7hUvuElU0vpg1jT4iadJipRoqXmfo= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) From: Ladislav Lhotka In-Reply-To: <20131106.113628.386256580.mbj@tail-f.com> Date: Wed, 6 Nov 2013 13:34:32 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <5DE98304-C92F-48D8-A957-130CDCDCD2CA@nic.cz> References: <527A155C.6010605@mg-soft.com> <20131106.113628.386256580.mbj@tail-f.com> To: =?iso-8859-1?Q?Martin_Bj=F6rklund?= X-Mailer: Apple Mail (2.1816) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] Fw: New Version Notification for draft-bjorklund-netmod-yang-xpath-extensions-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 21:34:39 -0000 On 06 Nov 2013, at 11:36, Martin Bjorklund wrote: > Hi, >=20 > Ladislav Lhotka wrote: >> So this >> discussion also shows the division line between YANG tools that are >> home-baked, and those that use standard XML tools. >=20 > XPath clearly allows custom functions. We should not limit ourselves Strictly speaking, XPath 1.0 only knows the core function library and = offers no provisions for defining extensions. You can define other = functions, as XSLT does, but it is no more XPath. > just b/c there exist some tools that don't support this. Well, libxslt and xsltproc do support extensions, but if you patch them, = you lose the benefit of relying on ubiquitous tools that everybody = already has pre-installed. Of course, it is not an issue if you only = distribute statically linked binary blobs. Lada >=20 >=20 > /martin -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From lhotka@nic.cz Wed Nov 6 13:44:45 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E591021F9A5F for ; Wed, 6 Nov 2013 13:44:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9vPQ7ZOWJhic for ; Wed, 6 Nov 2013 13:44:45 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 3BDF221E81A5 for ; Wed, 6 Nov 2013 13:42:04 -0800 (PST) Received: from [172.16.33.134] (unknown [64.114.24.114]) by mail.nic.cz (Postfix) with ESMTPSA id 6491113F9FC; Wed, 6 Nov 2013 22:42:00 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1383774123; bh=DG5L6Fyv8zL5zhWlNZgNbGPVu0FUoAQiMxwwM7RY65c=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=Tkjf7lMZUYPr02HbbCTHreeP3g4t5eC6A9ZpvKpQslS1J3NvkwoHAG93Gq5lW4p/L xY3mxNI+VV0dphWpfzcG4N/MpdcsKRH0wGBWZME0fzJkrOpC6VHRu1bYfaguTgT3r1 c7kUfYk+bArWgQzX1Nr7hRTXWFQ83/BhCvAzQqko= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) From: Ladislav Lhotka In-Reply-To: <20131106.083957.438880938.mbj@tail-f.com> Date: Wed, 6 Nov 2013 13:41:57 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20131025.192445.290343408.mbj@tail-f.com> <527A155C.6010605@mg-soft.com> <20131106.083957.438880938.mbj@tail-f.com> To: =?windows-1252?Q?Martin_Bj=F6rklund?= X-Mailer: Apple Mail (2.1816) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] New Version Notification for draft-bjorklund-netmod-yang-xpath-extensions-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 21:44:46 -0000 On 06 Nov 2013, at 08:39, Martin Bjorklund wrote: > Hi, >=20 > Jernej Tuljak wrote: >> Dne 25.10.2013 21:06, pi=9Ae Ladislav Lhotka: >>> On 25 Oct 2013, at 19:24, Martin Bjorklund wrote: >>>=20 >>>> Ladislav Lhotka wrote: >>>>> On 25 Oct 2013, at 17:01, Martin Bjorklund wrote: >>>>>=20 >>>>>> Ladislav Lhotka wrote: >>>>>>> If the server doesn't advertise the "ietf-yang-xpath-extensions" >>>>>>> module, can >>>>>>> other advertized modules still use new XPath functions in "must" = and >>>>>>> "when", >>>>>>> if >>>>>>> they import that module? >>>>>> Yes. Note that all XPath expressions are conceptual. If a = server >>>>>> claims that it implements a module that uses such an xpath = function, >>>>>> it must implement the contraint somehow. It doesn't have to use = an >>>>>> XPath evaluator; it can be implemented in code - just like ane >>>>>> constraints defined in description statements. >>>>> Yes, but one has to be careful with revisions - sec. 10 in RFC = 6020 >>>>> allows new >>>>> extensions in an updated module, but I think in this case it could = be >>>>> dangerous >>>>> because the server cannot easily ignore unknown functions = appearing in >>>>> XPath >>>>> expressions. >>>> You typcially do not just load a new module into a server; it needs >>>> some instrumentation to be useful. So a new revison that uses some >>>> new XPath functions or not needs an implemention effort in the >>>> server. >>>>=20 >>>> But maybe I misunderstood your concern? >>> Sec. 6.3.1 says: >>>=20 >>> If a YANG compiler does not support a particular extension, which >>> appears in a YANG module as an unknown-statement (see Section 12), = the >>> entire unknown-statement MAY be ignored by the compiler. >>>=20 >>> So my point here is that while ignoring extensions is easy because >>> they are self-contained, it is not the case for extensions in XPath >>> expressions. But maybe it is not an issue. >>>=20 >>> Lada >>>=20 >>=20 >> It is an issue. I share Ladislav's concerns and add my own. I do not >> think YANG extensions should be used for extending the value space of >> an existing YANG statement's argument (not this way). >=20 > Please note that this draft updates 6020, see section "XPath > Evaluation Context". Without this section you are right - extensions > cannot arbitrarily make changes like this. This is why a new RFC is > needed. =85 and a new YANG version number, too. Lada >=20 >=20 > /martin -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From mbj@tail-f.com Wed Nov 6 13:53:11 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4490C11E812B for ; Wed, 6 Nov 2013 13:53:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.956 X-Spam-Level: X-Spam-Status: No, score=-1.956 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nm+139QDqd7a for ; Wed, 6 Nov 2013 13:53:05 -0800 (PST) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 5C2F211E80E2 for ; Wed, 6 Nov 2013 13:53:05 -0800 (PST) Received: from localhost (dhcp-90fa.meeting.ietf.org [31.133.144.250]) by mail.tail-f.com (Postfix) with ESMTPSA id F39851200054; Wed, 6 Nov 2013 22:53:02 +0100 (CET) Date: Wed, 06 Nov 2013 13:53:01 -0800 (PST) Message-Id: <20131106.135301.380310252.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: <5DE98304-C92F-48D8-A957-130CDCDCD2CA@nic.cz> References: <20131106.113628.386256580.mbj@tail-f.com> <5DE98304-C92F-48D8-A957-130CDCDCD2CA@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] Fw: New Version Notification for draft-bjorklund-netmod-yang-xpath-extensions-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 21:53:11 -0000 Ladislav Lhotka wrote: > > On 06 Nov 2013, at 11:36, Martin Bjorklund wrote: > > > Hi, > > > > Ladislav Lhotka wrote: > >> So this > >> discussion also shows the division line between YANG tools that are > >> home-baked, and those that use standard XML tools. > > > > XPath clearly allows custom functions. We should not limit ourselves > > Strictly speaking, XPath 1.0 only knows the core function library and > offers no provisions for defining extensions. You can define other > functions, as XSLT does, but it is no more XPath. No this is not correct. The XPath 1.0 spec says that an expression is evaluated in a context, and in the context there is a function library. Then the spec defines the core library, which every implementation must support. The spec does not say that there is a fixed set of functions. /martin From lhotka@nic.cz Wed Nov 6 14:03:32 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28F1C11E80E2 for ; Wed, 6 Nov 2013 14:03:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AGXVFSP1DTay for ; Wed, 6 Nov 2013 14:03: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 0342621F9F9D for ; Wed, 6 Nov 2013 14:03:30 -0800 (PST) Received: from [172.16.33.134] (unknown [64.114.24.114]) by mail.nic.cz (Postfix) with ESMTPSA id 560B113F9FC; Wed, 6 Nov 2013 23:03:27 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1383775410; bh=ZfI8jt7Y9UFsFyHwcPDABNdy2ijEicVVPeS1uF2mo1U=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=A56H/kGsS66V6MFkawXaHD9BZ+V5kT0WeybRlx0qeHfVmVPTCJ6HpjOpSX1O5yEml ub20UrFYpFgPD44HK3SdjiISQ1qhuAvTsnMshS48m1ACqdRkAs5AzLLCH4xndwLevl wTevxixjYS0w5CAkBGwF3f2S2OUxglUMfW71o/Zk= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) From: Ladislav Lhotka In-Reply-To: <20131106.135301.380310252.mbj@tail-f.com> Date: Wed, 6 Nov 2013 14:03:23 -0800 Content-Transfer-Encoding: 7bit Message-Id: <91C490D7-A558-40AA-9AFA-89FE756015F5@nic.cz> References: <20131106.113628.386256580.mbj@tail-f.com> <5DE98304-C92F-48D8-A957-130CDCDCD2CA@nic.cz> <20131106.135301.380310252.mbj@tail-f.com> To: =?iso-8859-1?Q?Martin_Bj=F6rklund?= X-Mailer: Apple Mail (2.1816) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] Fw: New Version Notification for draft-bjorklund-netmod-yang-xpath-extensions-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 22:03:32 -0000 On 06 Nov 2013, at 13:53, Martin Bjorklund wrote: > Ladislav Lhotka wrote: >> >> On 06 Nov 2013, at 11:36, Martin Bjorklund wrote: >> >>> Hi, >>> >>> Ladislav Lhotka wrote: >>>> So this >>>> discussion also shows the division line between YANG tools that are >>>> home-baked, and those that use standard XML tools. >>> >>> XPath clearly allows custom functions. We should not limit ourselves >> >> Strictly speaking, XPath 1.0 only knows the core function library and >> offers no provisions for defining extensions. You can define other >> functions, as XSLT does, but it is no more XPath. > > No this is not correct. The XPath 1.0 spec says that an expression is > evaluated in a context, and in the context there is a function > library. Then the spec defines the core library, which every > implementation must support. The spec does not say that there is a > fixed set of functions. OK, you are right. Lada > > > /martin -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From jernej.tuljak@mg-soft.si Thu Nov 7 00:36:26 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18C5A21E8090 for ; Thu, 7 Nov 2013 00:36:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SqqVzhIbGXtk for ; Thu, 7 Nov 2013 00:36:19 -0800 (PST) Received: from gate.mg-soft.si (gate.mg-soft.si [212.30.73.66]) by ietfa.amsl.com (Postfix) with ESMTP id 42ADB11E819D for ; Thu, 7 Nov 2013 00:36:17 -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 rA78a8cF013816; Thu, 7 Nov 2013 09:36:09 +0100 Message-ID: <527B50F5.80000@mg-soft.com> Date: Thu, 07 Nov 2013 09:36:05 +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: <527A155C.6010605@mg-soft.com> <20131106.113628.386256580.mbj@tail-f.com> In-Reply-To: <20131106.113628.386256580.mbj@tail-f.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] Fw: New Version Notification for draft-bjorklund-netmod-yang-xpath-extensions-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 08:36:27 -0000 Dne 6.11.2013 20:36, piše Martin Bjorklund: > Hi, > > Ladislav Lhotka wrote: >> So this >> discussion also shows the division line between YANG tools that are >> home-baked, and those that use standard XML tools. > XPath clearly allows custom functions. We should not limit ourselves > just b/c there exist some tools that don't support this. But RFC6020 doesn't support it. A decision about that has already been made. You need YANG 2.0 to change that. What XPath 1.0 spec says about this matter is irrelevant, IMO. RFC6020 implies a subset of it is being used for YANG. You can't just ignore this. You can't argue that a RFC6020 tool that reports an error, when a statement argument contains unknown XPath functions, is non-standard. Take a look at how XSLT specs handle this. There's a section that deals with extension functions specifically. It even defines when the XSLT processor should treat unknown functions as an error and when not. Why doesn't RFC6020 have such a section? That's a major problem. And I'm not even mentioning how extension statements need to be abused in order for this whole thing to work. XSLT specs also contain a section for extension elements, which is how I understand YANG extension statements. http://www.w3.org/TR/xslt#extension It is unfortunate, but even another RFC can't change this. Or can it? I'm not familiar with how this works inside IETF. Can you just publish a new RFC which updates a section in an existing RFC? Isn't that more suited for errata or something else that inherently obsoletes the existing section? Jernej > > /martin From j.schoenwaelder@jacobs-university.de Thu Nov 7 04:54:53 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B391011E8173 for ; Thu, 7 Nov 2013 04:54:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.185 X-Spam-Level: X-Spam-Status: No, score=-103.185 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4OYtbfPoPzeA for ; Thu, 7 Nov 2013 04:54:48 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 4151511E8104 for ; Thu, 7 Nov 2013 04:54:48 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id A82A020068; Thu, 7 Nov 2013 13:54:47 +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 tL1IFvfr9Qd7; Thu, 7 Nov 2013 13:54:47 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0656E20079; Thu, 7 Nov 2013 13:54:46 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 14B4229309B4; Thu, 7 Nov 2013 13:54:40 +0100 (CET) Date: Thu, 7 Nov 2013 13:54:40 +0100 From: Juergen Schoenwaelder To: Jernej Tuljak Message-ID: <20131107125440.GC87223@elstar.local> Mail-Followup-To: Jernej Tuljak , Martin Bjorklund , netmod@ietf.org References: <527A155C.6010605@mg-soft.com> <20131106.113628.386256580.mbj@tail-f.com> <527B50F5.80000@mg-soft.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <527B50F5.80000@mg-soft.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] Fw: New Version Notification for draft-bjorklund-netmod-yang-xpath-extensions-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 12:54:53 -0000 On Thu, Nov 07, 2013 at 09:36:05AM +0100, Jernej Tuljak wrote: > > It is unfortunate, but even another RFC can't change this. Or can > it? I'm not familiar with how this works inside IETF. Can you just > publish a new RFC which updates a section in an existing RFC? Isn't > that more suited for errata or something else that inherently > obsoletes the existing section? > A new RFC can update sections in existing RFCs. An implementation of the new RFC will claim to be compliant to the OLD RFC and the NEW RFC while an implementation that implements the OLD RFC will only claim to be compliant to the OLD RFC. So from the procedural side, this is all fine. The WG in charge must of course consider whether any interoperability issues may arise from such an update. This is I think the discussion we are having here and there is no generic answer. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From lhotka@nic.cz Thu Nov 7 05:44:09 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAE3E11E824D for ; Thu, 7 Nov 2013 05:44:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YhGjMVY-lWDm for ; Thu, 7 Nov 2013 05:44:03 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id DE35D11E823C for ; Thu, 7 Nov 2013 05:44:01 -0800 (PST) Received: from [172.16.33.201] (unknown [64.114.24.114]) by mail.nic.cz (Postfix) with ESMTPSA id 9398813FA81; Thu, 7 Nov 2013 14:43:59 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1383831841; bh=zerpBt8VN5FeQHh5nsh1DuOyd+wE/eGG9JLyhzTc7iU=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=IrAw8wqWDnbdlwH9V3wYGcmEdlvr4mAWvlNjiSE83f1dXjaP0by1gPqXH7VgmUN0w mIDsilb7YMyAQK1jctf+T0rDGJ80jgwAZ4LDLbW2Y/e9SxZNgNOuW6XmiK5SnOzG+9 8bbmyoTZt9eI30FXwzyh3+juYGG45PRGIrij/H7I= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) From: Ladislav Lhotka In-Reply-To: <20131107125440.GC87223@elstar.local> Date: Thu, 7 Nov 2013 05:43:56 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <527A155C.6010605@mg-soft.com> <20131106.113628.386256580.mbj@tail-f.com> <527B50F5.80000@mg-soft.com> <20131107125440.GC87223@elstar.local> To: =?windows-1252?Q?J=FCrgen_Sch=F6nw=E4lder?= X-Mailer: Apple Mail (2.1816) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] Fw: New Version Notification for draft-bjorklund-netmod-yang-xpath-extensions-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 13:44:09 -0000 Hi, I think that extensions must really obey the rule stated in sec. 6.3.1 = of RFC 6020, namely that =93the entire [extension] statement MAY be = ignored". This it not the case for extensions that have side effects on = core YANG statements, and =93xpath-function=94 in particular. This leads me back to what I proposed in Berlin: 6020 needs to be opened = and a limited set of updates applied, which would result in a new spec = and a new YANG version. The set of changes of course requires some discussion. A useful = criterion might be that the changes must not make any existing module = invalid. Lada On 07 Nov 2013, at 04:54, Juergen Schoenwaelder = wrote: > On Thu, Nov 07, 2013 at 09:36:05AM +0100, Jernej Tuljak wrote: >>=20 >> It is unfortunate, but even another RFC can't change this. Or can >> it? I'm not familiar with how this works inside IETF. Can you just >> publish a new RFC which updates a section in an existing RFC? Isn't >> that more suited for errata or something else that inherently >> obsoletes the existing section? >>=20 >=20 > A new RFC can update sections in existing RFCs. An implementation of > the new RFC will claim to be compliant to the OLD RFC and the NEW RFC > while an implementation that implements the OLD RFC will only claim to > be compliant to the OLD RFC. So from the procedural side, this is all > fine. >=20 > The WG in charge must of course consider whether any interoperability > issues may arise from such an update. This is I think the discussion > we are having here and there is no generic answer. >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From andy@yumaworks.com Thu Nov 7 07:41:20 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAFB421E81CA for ; Thu, 7 Nov 2013 07:41:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.504 X-Spam-Level: X-Spam-Status: No, score=-2.504 tagged_above=-999 required=5 tests=[AWL=-0.128, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id idajL4Cs7CwP for ; Thu, 7 Nov 2013 07:41:16 -0800 (PST) Received: from mail-qa0-f41.google.com (mail-qa0-f41.google.com [209.85.216.41]) by ietfa.amsl.com (Postfix) with ESMTP id B104221E81C2 for ; Thu, 7 Nov 2013 07:41:15 -0800 (PST) Received: by mail-qa0-f41.google.com with SMTP id k4so569543qaq.14 for ; Thu, 07 Nov 2013 07:41: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=VVKre6GjDvi0ew6jHv1+4DcK5J/52a+7GD97RnnxHrE=; b=dxz4bkoZooU3HjEDzHxILgXN0JU+2grtVhK6UcT8HUKyy4sB9P7omb5PSxoGcm31sM ZQ6S4mi076eJd5xhOuYvqGvqbtsofcMlIAJ7VIOA1DWY1t4GXdi/uLByI9r0Mz0I+7OS vwPfJArUGG8BGroTzcIV+Gsh3HFUxfqond4rz7sWQERAS1ehSApnhT0X4M4nATzFZbTh Mr7O87iE0Q5Nw0r1cSAKx4GzASuJHmTqcQezGgGUQMQlj5CvxLlQBGHz9kkmP8bVlAUB UtT0Ml3EMkwqUQXn15HnvdAflLnBsCaIKEyjiwThvSFkmd9S1/bnImiaGKRiZR2ogxzm 2ObA== X-Gm-Message-State: ALoCoQmqpAW2w1tE5166Xk+Oa0RQkBRcF9+vUQKC6wBUN+Ccdlklt3+GLVKbEeh/5pm2uV7f78kx MIME-Version: 1.0 X-Received: by 10.49.35.144 with SMTP id h16mr13950629qej.35.1383838874989; Thu, 07 Nov 2013 07:41:14 -0800 (PST) Received: by 10.140.100.203 with HTTP; Thu, 7 Nov 2013 07:41:14 -0800 (PST) In-Reply-To: References: <527A155C.6010605@mg-soft.com> <20131106.113628.386256580.mbj@tail-f.com> <527B50F5.80000@mg-soft.com> <20131107125440.GC87223@elstar.local> Date: Thu, 7 Nov 2013 07:41:14 -0800 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=047d7b5d5af49218e404ea98188c Cc: "netmod@ietf.org" Subject: Re: [netmod] Fw: New Version Notification for draft-bjorklund-netmod-yang-xpath-extensions-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 15:41:20 -0000 --047d7b5d5af49218e404ea98188c Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi, I do not have any objection to dropping this work because it cannot be added as an extension. I am strongly opposed to starting any work on a new version of YANG. There is no such thing as a minor update to a DML. Introducing a new language version while many projects still depend on the current version causes market confusion, increases support costs and reduces adoption and deployment. It should only be done if the new features and problems fixed are worth the cost. These XPath extensions are not that important. IMO, NETMOD should finish up the current YANG modules and then shut down for several years. Let other WGs create data models. The IETF needs more experience with YANG before knowing what really needs to be in YANG 2.0. Andy On Thu, Nov 7, 2013 at 5:43 AM, Ladislav Lhotka wrote: > Hi, > > I think that extensions must really obey the rule stated in sec. 6.3.1 of > RFC 6020, namely that =93the entire [extension] statement MAY be ignored"= . > This it not the case for extensions that have side effects on core YANG > statements, and =93xpath-function=94 in particular. > > This leads me back to what I proposed in Berlin: 6020 needs to be opened > and a limited set of updates applied, which would result in a new spec an= d > a new YANG version. > > The set of changes of course requires some discussion. A useful criterion > might be that the changes must not make any existing module invalid. > > Lada > > On 07 Nov 2013, at 04:54, Juergen Schoenwaelder < > j.schoenwaelder@jacobs-university.de> wrote: > > > On Thu, Nov 07, 2013 at 09:36:05AM +0100, Jernej Tuljak wrote: > >> > >> It is unfortunate, but even another RFC can't change this. Or can > >> it? I'm not familiar with how this works inside IETF. Can you just > >> publish a new RFC which updates a section in an existing RFC? Isn't > >> that more suited for errata or something else that inherently > >> obsoletes the existing section? > >> > > > > A new RFC can update sections in existing RFCs. An implementation of > > the new RFC will claim to be compliant to the OLD RFC and the NEW RFC > > while an implementation that implements the OLD RFC will only claim to > > be compliant to the OLD RFC. So from the procedural side, this is all > > fine. > > > > The WG in charge must of course consider whether any interoperability > > issues may arise from such an update. This is I think the discussion > > we are having here and there is no generic answer. > > > > /js > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > > Fax: +49 421 200 3103 > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --047d7b5d5af49218e404ea98188c Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Hi,

I do not have any objection to drop= ping this work because it
cannot be added as an extension. =A0 I = am strongly opposed
to starting any work on a new version of YANG= .

There is no such thing as a minor update to a DML.
Introducing a new language version while many projects still
depend on the current version causes market confusion, increases
support costs and reduces adoption and deployment. =A0It should
<= div>only be done if the new features and problems fixed are worth the cost.=
These XPath extensions are not that important.

IMO, NETMOD should finish up the current YANG modules and
th= en shut down for several years. =A0Let other WGs create data models.
<= div>The IETF needs more experience with YANG before knowing what
really needs to be in YANG 2.0.


Andy


On Thu, No= v 7, 2013 at 5:43 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
Hi,

I think that extensions must really obey the rule stated in sec. 6.3.1 of R= FC 6020, namely that =93the entire [extension] statement MAY be ignored&quo= t;. This it not the case for extensions that have side effects on core YANG= statements, and =93xpath-function=94 in particular.

This leads me back to what I proposed in Berlin: 6020 needs to be opened an= d a limited set of updates applied, which would result in a new spec and a = new YANG version.

The set of changes of course requires some discussion. A useful criterion m= ight be that the changes must not make any existing module invalid.

Lada

On 07 Nov 2013, at 04:54, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de&g= t; wrote:

> On Thu, Nov 07, 2013 at 09:36:05AM +0100, Jernej Tuljak wrote:
>>
>> It is unfortunate, but even another RFC can't change this. Or = can
>> it? I'm not familiar with how this works inside IETF. Can you = just
>> publish a new RFC which updates a section in an existing RFC? Isn&= #39;t
>> that more suited for errata or something else that inherently
>> obsoletes the existing section?
>>
>
> A new RFC can update sections in existing RFCs. An implementation of > the new RFC will claim to be compliant to the OLD RFC and the NEW RFC<= br> > while an implementation that implements the OLD RFC will only claim to=
> be compliant to the OLD RFC. So from the procedural side, this is all<= br> > fine.
>
> The WG in charge must of course consider whether any interoperability<= br> > issues may arise from such an update. This is I think the discussion > we are having here and there is no generic answer.
>
> /js
>
> --
> Juergen Schoenwaelder =A0 =A0 =A0 =A0 =A0 Jacobs University Bremen gGm= bH
> Phone: +49 421 200 3587 =A0 =A0 =A0 =A0 Campus Ring 1, 28759 Bremen, G= ermany
> Fax: =A0 +49 421 200 3103 =A0 =A0 =A0 =A0 <http://www.jacobs-university.de/= >
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

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




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

--047d7b5d5af49218e404ea98188c-- From lhotka@nic.cz Thu Nov 7 10:30:28 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D195111E81B4 for ; Thu, 7 Nov 2013 10:30:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.95 X-Spam-Level: X-Spam-Status: No, score=-1.95 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hUPmhSQvkj29 for ; Thu, 7 Nov 2013 10:30: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 81B1121E8163 for ; Thu, 7 Nov 2013 10:30:10 -0800 (PST) Received: from wireless-v6.meeting.ietf.org (unknown [IPv6:2001:67c:370:160:b88f:5371:b1f2:e6ab]) by mail.nic.cz (Postfix) with ESMTPSA id CEC1A140133; Thu, 7 Nov 2013 19:30:02 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1383849004; bh=N7odBO6ZT0cI1ZJ+nTT5dOR/NzgOR6lIyuQ4FuB6WCs=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=enNSi3JM+hqqB5Uil518+X6EU8/vBGDAM2n5hzM86dztsuVSnvdLHcxZTq96CgxTq DtPpZsr5Hag08DLYDaTMozxlugfFi573jvOG4S2BJZxyywy3U1UsLtCOq9K094uprp x3EBjzDtDj0wS42neM/ovVa8SQSNnje+DB8qeEtk= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) From: Ladislav Lhotka In-Reply-To: Date: Thu, 7 Nov 2013 10:29:59 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <527A155C.6010605@mg-soft.com> <20131106.113628.386256580.mbj@tail-f.com> <527B50F5.80000@mg-soft.com> <20131107125440.GC87223@elstar.local> To: Andy Bierman X-Mailer: Apple Mail (2.1816) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Cc: "netmod@ietf.org" Subject: Re: [netmod] Fw: New Version Notification for draft-bjorklund-netmod-yang-xpath-extensions-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 18:30:29 -0000 On 07 Nov 2013, at 07:41, Andy Bierman wrote: > Hi, >=20 > I do not have any objection to dropping this work because it > cannot be added as an extension. I am strongly opposed > to starting any work on a new version of YANG. >=20 > There is no such thing as a minor update to a DML. Why not? > Introducing a new language version while many projects still > depend on the current version causes market confusion, increases > support costs and reduces adoption and deployment. It should > only be done if the new features and problems fixed are worth the = cost. > These XPath extensions are not that important. IMO (a) it is rather important (e.g. derived-from), and (b) there are = other things that need fixing. >=20 > IMO, NETMOD should finish up the current YANG modules and > then shut down for several years. Let other WGs create data models. > The IETF needs more experience with YANG before knowing what > really needs to be in YANG 2.0. With (hopefully) many YANG modules around, it will become much harder to = change anything in YANG than it is now. Lada >=20 >=20 > Andy >=20 >=20 > On Thu, Nov 7, 2013 at 5:43 AM, Ladislav Lhotka wrote: > Hi, >=20 > I think that extensions must really obey the rule stated in sec. 6.3.1 = of RFC 6020, namely that =93the entire [extension] statement MAY be = ignored". This it not the case for extensions that have side effects on = core YANG statements, and =93xpath-function=94 in particular. >=20 > This leads me back to what I proposed in Berlin: 6020 needs to be = opened and a limited set of updates applied, which would result in a new = spec and a new YANG version. >=20 > The set of changes of course requires some discussion. A useful = criterion might be that the changes must not make any existing module = invalid. >=20 > Lada >=20 > On 07 Nov 2013, at 04:54, Juergen Schoenwaelder = wrote: >=20 > > On Thu, Nov 07, 2013 at 09:36:05AM +0100, Jernej Tuljak wrote: > >> > >> It is unfortunate, but even another RFC can't change this. Or can > >> it? I'm not familiar with how this works inside IETF. Can you just > >> publish a new RFC which updates a section in an existing RFC? Isn't > >> that more suited for errata or something else that inherently > >> obsoletes the existing section? > >> > > > > A new RFC can update sections in existing RFCs. An implementation of > > the new RFC will claim to be compliant to the OLD RFC and the NEW = RFC > > while an implementation that implements the OLD RFC will only claim = to > > be compliant to the OLD RFC. So from the procedural side, this is = all > > fine. > > > > The WG in charge must of course consider whether any = interoperability > > issues may arise from such an update. This is I think the discussion > > we are having here and there is no generic answer. > > > > /js > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > > Fax: +49 421 200 3103 > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod >=20 > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C >=20 >=20 >=20 >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From andy@yumaworks.com Thu Nov 7 11:01:53 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52F4C11E8282 for ; Thu, 7 Nov 2013 11:01:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.502 X-Spam-Level: X-Spam-Status: No, score=-2.502 tagged_above=-999 required=5 tests=[AWL=-0.126, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id feu0xkPq6Zx4 for ; Thu, 7 Nov 2013 11:01:33 -0800 (PST) Received: from mail-qe0-f48.google.com (mail-qe0-f48.google.com [209.85.128.48]) by ietfa.amsl.com (Postfix) with ESMTP id 57F3211E81FF for ; Thu, 7 Nov 2013 10:58:55 -0800 (PST) Received: by mail-qe0-f48.google.com with SMTP id d4so905873qej.7 for ; Thu, 07 Nov 2013 10:58:54 -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=He0B0rdELh1rc49j+FJUsyiejx6IRXps6qyMP3nObPY=; b=C44cN7/wMxqrAuA2vvnbJVovqv37uN4r2dEWOcPabIlnhtjCVoMRFQeY5uwXYf2I9N FdGKTbWX7dZHB8krHXRkrBMMM0rIyjKJnSF3294ZJeLKAy9jmK+KEyHLLb/b/2lZp+yH 3CF92db6thxKeYf82XZl0XhmlsRkBM5YgJdEvGr9EpLHY4AklyXAtu3rz1OiugwFgnOe TFvKYVKYHDzuqp/mcOuOFEVQ/3l61hlOcBe/rUbWbFxblKV42vjiG/Y09WQo6/aeBzrf w7hVis0StR+YcY5j+cYKrsHYA0b0I96REMvZ5MEmLQJvPet4+HK7M7NItIcFwhN9gpig 4ftw== X-Gm-Message-State: ALoCoQnM9RKNVRC07dfJdSsoX68S2yZnrJgVN827SBVTRvwUCbme9akcaFiO9dLwsPQoOOsG6AWN MIME-Version: 1.0 X-Received: by 10.49.35.15 with SMTP id d15mr15731105qej.16.1383850734704; Thu, 07 Nov 2013 10:58:54 -0800 (PST) Received: by 10.140.100.203 with HTTP; Thu, 7 Nov 2013 10:58:54 -0800 (PST) In-Reply-To: References: <527A155C.6010605@mg-soft.com> <20131106.113628.386256580.mbj@tail-f.com> <527B50F5.80000@mg-soft.com> <20131107125440.GC87223@elstar.local> Date: Thu, 7 Nov 2013 10:58:54 -0800 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=047d7b6dcbe0771d2204ea9adb86 Cc: "netmod@ietf.org" Subject: Re: [netmod] Fw: New Version Notification for draft-bjorklund-netmod-yang-xpath-extensions-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 19:01:53 -0000 --047d7b6dcbe0771d2204ea9adb86 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Thu, Nov 7, 2013 at 10:29 AM, Ladislav Lhotka wrote: > > On 07 Nov 2013, at 07:41, Andy Bierman wrote: > > > Hi, > > > > I do not have any objection to dropping this work because it > > cannot be added as an extension. I am strongly opposed > > to starting any work on a new version of YANG. > > > > There is no such thing as a minor update to a DML. > > Why not? > Because the cost of deployment is so high. > > > Introducing a new language version while many projects still > > depend on the current version causes market confusion, increases > > support costs and reduces adoption and deployment. It should > > only be done if the new features and problems fixed are worth the cost. > > These XPath extensions are not that important. > > IMO (a) it is rather important (e.g. derived-from), and (b) there are > other things that need fixing. > I don't think this is a big problem. The purpose of YANG is officially the DML for the NETCONF protocol. Within NETCONF the must/when statements are conceptual -- an XPath parser is not required to implement a YANG module in the server. Support for off-line message validation tools is not the focus of NETCONF. The concern with identityrefs is that they are really QNames but they are encoded in XPath as strings. This is only a problem if the server actually supports multiple identities with the same base with the same local-name. We could easily publish a convention for encoding this QName as a string -- e.g., same as your JSON -- use the module name as the prefix. > > > > IMO, NETMOD should finish up the current YANG modules and > > then shut down for several years. Let other WGs create data models. > > The IETF needs more experience with YANG before knowing what > > really needs to be in YANG 2.0. > > With (hopefully) many YANG modules around, it will become much harder to > change anything in YANG than it is now. > > IMO changing the DML version should only be done as a last resort. YANG 1.0 is good enough for WGs and vendors to use now. > > > > > > > Andy > > > Andy > > > > On Thu, Nov 7, 2013 at 5:43 AM, Ladislav Lhotka wrote: > > Hi, > > > > I think that extensions must really obey the rule stated in sec. 6.3.1 > of RFC 6020, namely that =93the entire [extension] statement MAY be ignor= ed". > This it not the case for extensions that have side effects on core YANG > statements, and =93xpath-function=94 in particular. > > > > This leads me back to what I proposed in Berlin: 6020 needs to be opene= d > and a limited set of updates applied, which would result in a new spec an= d > a new YANG version. > > > > The set of changes of course requires some discussion. A useful > criterion might be that the changes must not make any existing module > invalid. > > > > Lada > > > > On 07 Nov 2013, at 04:54, Juergen Schoenwaelder < > j.schoenwaelder@jacobs-university.de> wrote: > > > > > On Thu, Nov 07, 2013 at 09:36:05AM +0100, Jernej Tuljak wrote: > > >> > > >> It is unfortunate, but even another RFC can't change this. Or can > > >> it? I'm not familiar with how this works inside IETF. Can you just > > >> publish a new RFC which updates a section in an existing RFC? Isn't > > >> that more suited for errata or something else that inherently > > >> obsoletes the existing section? > > >> > > > > > > A new RFC can update sections in existing RFCs. An implementation of > > > the new RFC will claim to be compliant to the OLD RFC and the NEW RFC > > > while an implementation that implements the OLD RFC will only claim t= o > > > be compliant to the OLD RFC. So from the procedural side, this is all > > > fine. > > > > > > The WG in charge must of course consider whether any interoperability > > > issues may arise from such an update. This is I think the discussion > > > we are having here and there is no generic answer. > > > > > > /js > > > > > > -- > > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > > > Fax: +49 421 200 3103 > > > _______________________________________________ > > > netmod mailing list > > > netmod@ietf.org > > > https://www.ietf.org/mailman/listinfo/netmod > > > > -- > > Ladislav Lhotka, CZ.NIC Labs > > PGP Key ID: E74E8C0C > > > > > > > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > --047d7b6dcbe0771d2204ea9adb86 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable



On Thu, Nov 7, 2013 at 10:29 AM, Ladislav Lhotka = <lhotka@nic.cz>= ; wrote:

On 07 Nov 2013, at 07:41, Andy Bierman <andy@yumaworks.com> wrote:

> Hi,
>
> I do not have any objection to dropping this work because it
> cannot be added as an extension. =A0 I am strongly opposed
> to starting any work on a new version of YANG.
>
> There is no such thing as a minor update to a DML.

Why not?

Because the cost of deployment= is so high.

=A0

> Introducing a new language version while many projects still
> depend on the current version causes market confusion, increases
> support costs and reduces adoption and deployment. =A0It should
> only be done if the new features and problems fixed are worth the cost= .
> These XPath extensions are not that important.

IMO (a) it is rather important (e.g. derived-from), and (b) there are other= things that need fixing.

=A0
I don't think this is a big problem.
The purpose of YANG is = officially the DML for the NETCONF protocol.
Within NETCONF the must/when statements are conceptual -- an XPath par= ser
is not required to implement a YANG module in the server. Sup= port for
off-line message validation tools is not the focus of NE= TCONF.

The concern with identityrefs is that they are really Q= Names but they are encoded
in XPath as strings. =A0This is only a= problem if the server actually supports multiple
identities with= the same base with the same local-name. =A0We could easily publish
a convention for encoding this QName as a string -- e.g., same as your= JSON --
use the module name as the prefix.

<= div>



>
> IMO, NETMOD should finish up the current YANG modules and
> then shut down for several years. =A0Let other WGs create data models.=
> The IETF needs more experience with YANG before knowing what
> really needs to be in YANG 2.0.

With (hopefully) many YANG modules around, it will become much harder to ch= ange anything in YANG than it is now.


IMO changing the DML version should on= ly be done as a last resort.
YANG 1.0 is good enough for WGs and = vendors to use now.


=A0

>
>
> Andy
>


Andy

=
=A0
>
> On Thu, Nov 7, 2013 at 5:43 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
> Hi,
>
> I think that extensions must really obey the rule stated in sec. 6.3.1= of RFC 6020, namely that =93the entire [extension] statement MAY be ignore= d". This it not the case for extensions that have side effects on core= YANG statements, and =93xpath-function=94 in particular.
>
> This leads me back to what I proposed in Berlin: 6020 needs to be open= ed and a limited set of updates applied, which would result in a new spec a= nd a new YANG version.
>
> The set of changes of course requires some discussion. A useful criter= ion might be that the changes must not make any existing module invalid. >
> Lada
>
> On 07 Nov 2013, at 04:54, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de<= /a>> wrote:
>
> > On Thu, Nov 07, 2013 at 09:36:05AM +0100, Jernej Tuljak wrote: > >>
> >> It is unfortunate, but even another RFC can't change this= . Or can
> >> it? I'm not familiar with how this works inside IETF. Can= you just
> >> publish a new RFC which updates a section in an existing RFC?= Isn't
> >> that more suited for errata or something else that inherently=
> >> obsoletes the existing section?
> >>
> >
> > A new RFC can update sections in existing RFCs. An implementation= of
> > the new RFC will claim to be compliant to the OLD RFC and the NEW= RFC
> > while an implementation that implements the OLD RFC will only cla= im to
> > be compliant to the OLD RFC. So from the procedural side, this is= all
> > fine.
> >
> > The WG in charge must of course consider whether any interoperabi= lity
> > issues may arise from such an update. This is I think the discuss= ion
> > we are having here and there is no generic answer.
> >
> > /js
> >
> > --
> > Juergen Schoenwaelder =A0 =A0 =A0 =A0 =A0 Jacobs University Breme= n gGmbH
> > Phone: +49 421 200 3587 =A0 =A0 =A0 =A0 Campus Ring 1, 28759 Brem= en, Germany
> > Fax: =A0 +49 421 200 3103 =A0 =A0 =A0 =A0 <http://www.jacobs-university.de= />
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
>
> --
> 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





--047d7b6dcbe0771d2204ea9adb86-- From lhotka@nic.cz Thu Nov 7 11:28:13 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEE9211E828A for ; Thu, 7 Nov 2013 11:28:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.955 X-Spam-Level: X-Spam-Status: No, score=-1.955 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NagcvhGhDK6g for ; Thu, 7 Nov 2013 11:28:13 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id A483511E81B3 for ; Thu, 7 Nov 2013 11:28:12 -0800 (PST) Received: from wireless-v6.meeting.ietf.org (unknown [IPv6:2001:67c:370:160:b88f:5371:b1f2:e6ab]) by mail.nic.cz (Postfix) with ESMTPSA id EADC113F6A3; Thu, 7 Nov 2013 20:28:09 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1383852491; bh=Ad5HPQ5daQ2so/wFuihDd1mE79yxCkN8RpbO48Kf4As=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=aN8tS1OgWUDD5awtGKV/l7FoL2DmrwqIr37KfLh3bapC6JZB9/X+fLAAGucUWTgyb SUaXxOQzgjoLXPNHvnx3OkQXoIS1RxXRYjCH/CmLFcNKnROCxb9x2sRDXeCP6anxxG NaJmePwqW+HSJNfHpAYlms7BFMFc1eH4J7zkhzN4= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) From: Ladislav Lhotka In-Reply-To: Date: Thu, 7 Nov 2013 11:28:06 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <527A155C.6010605@mg-soft.com> <20131106.113628.386256580.mbj@tail-f.com> <527B50F5.80000@mg-soft.com> <20131107125440.GC87223@elstar.local> To: Andy Bierman X-Mailer: Apple Mail (2.1816) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Cc: "netmod@ietf.org" Subject: Re: [netmod] Fw: New Version Notification for draft-bjorklund-netmod-yang-xpath-extensions-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 19:28:13 -0000 On 07 Nov 2013, at 10:58, Andy Bierman wrote: >=20 >=20 >=20 > On Thu, Nov 7, 2013 at 10:29 AM, Ladislav Lhotka = wrote: >=20 > On 07 Nov 2013, at 07:41, Andy Bierman wrote: >=20 > > Hi, > > > > I do not have any objection to dropping this work because it > > cannot be added as an extension. I am strongly opposed > > to starting any work on a new version of YANG. > > > > There is no such thing as a minor update to a DML. >=20 > Why not? >=20 > Because the cost of deployment is so high. You agreed with introducing the XPath functions in a sneaky way via = extensions. Would the cost of deployment be any lower in this case? = Changing the version number only means that we are honest with the = users. >=20 > =20 >=20 > > Introducing a new language version while many projects still > > depend on the current version causes market confusion, increases > > support costs and reduces adoption and deployment. It should > > only be done if the new features and problems fixed are worth the = cost. > > These XPath extensions are not that important. >=20 > IMO (a) it is rather important (e.g. derived-from), and (b) there are = other things that need fixing. >=20 > =20 > I don't think this is a big problem. > The purpose of YANG is officially the DML for the NETCONF protocol. > Within NETCONF the must/when statements are conceptual -- an XPath = parser > is not required to implement a YANG module in the server. Support for > off-line message validation tools is not the focus of NETCONF. No, the expressions must be valid XPath and must be evaluated exactly as = an XPath processor would do. =20 >=20 > The concern with identityrefs is that they are really QNames but they = are encoded > in XPath as strings. This is only a problem if the server actually = supports multiple > identities with the same base with the same local-name. We could = easily publish > a convention for encoding this QName as a string -- e.g., same as your = JSON -- > use the module name as the prefix. Sure, we could do that, but only in a YANG 2 (or 1.1) spec. RFC 6020 = defines an encoding that is based on XML context and prefixes, and this = is where an equality test may fail. This is where things can break in = subtle and unexpected ways, especially if it happens in a =93when=94 = statement. Lada >=20 >=20 >=20 >=20 >=20 > > > > IMO, NETMOD should finish up the current YANG modules and > > then shut down for several years. Let other WGs create data models. > > The IETF needs more experience with YANG before knowing what > > really needs to be in YANG 2.0. >=20 > With (hopefully) many YANG modules around, it will become much harder = to change anything in YANG than it is now. >=20 >=20 > IMO changing the DML version should only be done as a last resort. > YANG 1.0 is good enough for WGs and vendors to use now. >=20 >=20 > =20 >=20 > > > > > > Andy > > >=20 >=20 > Andy >=20 > =20 > > > > On Thu, Nov 7, 2013 at 5:43 AM, Ladislav Lhotka = wrote: > > Hi, > > > > I think that extensions must really obey the rule stated in sec. = 6.3.1 of RFC 6020, namely that =93the entire [extension] statement MAY = be ignored". This it not the case for extensions that have side effects = on core YANG statements, and =93xpath-function=94 in particular. > > > > This leads me back to what I proposed in Berlin: 6020 needs to be = opened and a limited set of updates applied, which would result in a new = spec and a new YANG version. > > > > The set of changes of course requires some discussion. A useful = criterion might be that the changes must not make any existing module = invalid. > > > > Lada > > > > On 07 Nov 2013, at 04:54, Juergen Schoenwaelder = wrote: > > > > > On Thu, Nov 07, 2013 at 09:36:05AM +0100, Jernej Tuljak wrote: > > >> > > >> It is unfortunate, but even another RFC can't change this. Or can > > >> it? I'm not familiar with how this works inside IETF. Can you = just > > >> publish a new RFC which updates a section in an existing RFC? = Isn't > > >> that more suited for errata or something else that inherently > > >> obsoletes the existing section? > > >> > > > > > > A new RFC can update sections in existing RFCs. An implementation = of > > > the new RFC will claim to be compliant to the OLD RFC and the NEW = RFC > > > while an implementation that implements the OLD RFC will only = claim to > > > be compliant to the OLD RFC. So from the procedural side, this is = all > > > fine. > > > > > > The WG in charge must of course consider whether any = interoperability > > > issues may arise from such an update. This is I think the = discussion > > > we are having here and there is no generic answer. > > > > > > /js > > > > > > -- > > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, = Germany > > > Fax: +49 421 200 3103 > > > _______________________________________________ > > > netmod mailing list > > > netmod@ietf.org > > > https://www.ietf.org/mailman/listinfo/netmod > > > > -- > > Ladislav Lhotka, CZ.NIC Labs > > PGP Key ID: E74E8C0C > > > > > > > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > >=20 > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From mbj@tail-f.com Thu Nov 7 12:27:33 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C6C911E827C for ; Thu, 7 Nov 2013 12:27:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.962 X-Spam-Level: X-Spam-Status: No, score=-1.962 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q4vtAFCzkVnC for ; Thu, 7 Nov 2013 12:27:27 -0800 (PST) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 5250421E80B6 for ; Thu, 7 Nov 2013 12:27:22 -0800 (PST) Received: from localhost (dhcp-9507.meeting.ietf.org [31.133.149.7]) by mail.tail-f.com (Postfix) with ESMTPSA id B89E71200454; Thu, 7 Nov 2013 21:27:17 +0100 (CET) Date: Thu, 07 Nov 2013 12:27:16 -0800 (PST) Message-Id: <20131107.122716.427722758.mbj@tail-f.com> To: lhotka@nic.cz 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] Fw: New Version Notification for draft-bjorklund-netmod-yang-xpath-extensions-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 20:27:33 -0000 Ladislav Lhotka wrote: > > The concern with identityrefs is that they are really QNames but they > > are encoded > > in XPath as strings. This is only a problem if the server actually > > supports multiple > > identities with the same base with the same local-name. We could > > easily publish > > a convention for encoding this QName as a string -- e.g., same as your > > JSON -- > > use the module name as the prefix. > > Sure, we could do that, but only in a YANG 2 (or 1.1) spec. RFC 6020 > defines an encoding that is based on XML context and prefixes, and > this is where an equality test may fail. I think we should keep the prefixed name. The problem is an omission in 6020 - it specifies that the prefixed name is ued in the "default" statement, but it should say "default", "when" and "must". Anyway, this only solves the equality test, not the 'derived-from'. /martin From andy@yumaworks.com Thu Nov 7 12:45:01 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F245821E81EE for ; Thu, 7 Nov 2013 12:45:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.501 X-Spam-Level: X-Spam-Status: No, score=-2.501 tagged_above=-999 required=5 tests=[AWL=-0.125, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5VO-7s2EGPSp for ; Thu, 7 Nov 2013 12:44:57 -0800 (PST) Received: from mail-qe0-f48.google.com (mail-qe0-f48.google.com [209.85.128.48]) by ietfa.amsl.com (Postfix) with ESMTP id BB4B521E8187 for ; Thu, 7 Nov 2013 12:44:52 -0800 (PST) Received: by mail-qe0-f48.google.com with SMTP id d4so1054082qej.21 for ; Thu, 07 Nov 2013 12:44:44 -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=EYLbsP9x5bG7ZY8CFdWZ3cpYmrluDchOb509DNXmKpU=; b=MTY9cdFEM2coTvEjypOLvGADXlqq5lLSwpTSTC5w2GdCOABOJamMtquXqmpZVejSAj chKxPGKjxUp+LoUNiHfF/ue4Xq/60j0oDB4XKltS32q9lWjAQdnJF6h/pjIZ5ibmRRTi RFbCJJN3jDuRe8Z9wjynQZFbq2sqzWm66RYX56giBIs0zbhZQUubZfnaKKv50N6LQu/l GXICKfti5Irl27SvE9hhz/929vDDkui6jJzQVfART8pw3+X+4UfQl6XyX3/F0Tk473bV 9DXwThfmALI4IwIc2QS7lBYp+S70jvcLEGlPj48ISI1GGddFJ+r1rRZ5X6trct4LslTW 1rcA== X-Gm-Message-State: ALoCoQkOcjUYCkVoww6NT/tNA1Q2dgEV2/91aN6yRo1JrhqjJVKXJeCK9a1X6bebLROjrVxHnO9O MIME-Version: 1.0 X-Received: by 10.229.54.201 with SMTP id r9mr2953022qcg.2.1383857084490; Thu, 07 Nov 2013 12:44:44 -0800 (PST) Received: by 10.140.100.203 with HTTP; Thu, 7 Nov 2013 12:44:44 -0800 (PST) In-Reply-To: References: <527A155C.6010605@mg-soft.com> <20131106.113628.386256580.mbj@tail-f.com> <527B50F5.80000@mg-soft.com> <20131107125440.GC87223@elstar.local> Date: Thu, 7 Nov 2013 12:44:44 -0800 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=001a1135ef48f0f95d04ea9c55fb Cc: "netmod@ietf.org" Subject: Re: [netmod] Fw: New Version Notification for draft-bjorklund-netmod-yang-xpath-extensions-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 20:45:01 -0000 --001a1135ef48f0f95d04ea9c55fb Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Thu, Nov 7, 2013 at 11:28 AM, Ladislav Lhotka wrote: > > On 07 Nov 2013, at 10:58, Andy Bierman wrote: > > > > > > > > > On Thu, Nov 7, 2013 at 10:29 AM, Ladislav Lhotka wrote: > > > > On 07 Nov 2013, at 07:41, Andy Bierman wrote: > > > > > Hi, > > > > > > I do not have any objection to dropping this work because it > > > cannot be added as an extension. I am strongly opposed > > > to starting any work on a new version of YANG. > > > > > > There is no such thing as a minor update to a DML. > > > > Why not? > > > > Because the cost of deployment is so high. > > You agreed with introducing the XPath functions in a sneaky way via > extensions. Would the cost of deployment be any lower in this case? > Changing the version number only means that we are honest with the users. > > I agree with Phil's comment about the must/when statements being conceptual within the server. If the server says it supports a YANG module that uses a new XPath function, then that is just 1 more implementation detail for the server. The machine-readable XPath could be replaced by description-stmt text. Both are just implementation requirements for a server develop to implement= . > > > > > > > > > Introducing a new language version while many projects still > > > depend on the current version causes market confusion, increases > > > support costs and reduces adoption and deployment. It should > > > only be done if the new features and problems fixed are worth the cos= t. > > > These XPath extensions are not that important. > > > > IMO (a) it is rather important (e.g. derived-from), and (b) there are > other things that need fixing. > > > > > > I don't think this is a big problem. > > The purpose of YANG is officially the DML for the NETCONF protocol. > > Within NETCONF the must/when statements are conceptual -- an XPath pars= er > > is not required to implement a YANG module in the server. Support for > > off-line message validation tools is not the focus of NETCONF. > > No, the expressions must be valid XPath and must be evaluated exactly as > an XPath processor would do. > It is valid XPath. There are no requirements at all for the server to evaluate any XPath. The server code must implement the correct behavior no matter what. The client cannot tell if the server used an XPath parser or not. > > > > > The concern with identityrefs is that they are really QNames but they > are encoded > > in XPath as strings. This is only a problem if the server actually > supports multiple > > identities with the same base with the same local-name. We could easil= y > publish > > a convention for encoding this QName as a string -- e.g., same as your > JSON -- > > use the module name as the prefix. > > Sure, we could do that, but only in a YANG 2 (or 1.1) spec. RFC 6020 > defines an encoding that is based on XML context and prefixes, and this i= s > where an equality test may fail. This is where things can break in subtle > and unexpected ways, especially if it happens in a =93when=94 statement. must/when statements use YANG prefixes, not XML prefixes. I have no confidence that a "quick" YANG 1.1 can be done. I think that IETF charter milestones are a cruel joke and taking 3 years to complete an 8 month project is unfortunately the norm, not the exception. The use of extensions is much better because it only affects the YANG modules that use the new XPath functions. A server vendor can choose to implement the new module or not. A client that needs to support the new module may need t= o change. If the YANG version changes the client must change to even parse the YANG module. > > Lada > Andy > > > > > > > > > > > > > > > > > IMO, NETMOD should finish up the current YANG modules and > > > then shut down for several years. Let other WGs create data models. > > > The IETF needs more experience with YANG before knowing what > > > really needs to be in YANG 2.0. > > > > With (hopefully) many YANG modules around, it will become much harder t= o > change anything in YANG than it is now. > > > > > > IMO changing the DML version should only be done as a last resort. > > YANG 1.0 is good enough for WGs and vendors to use now. > > > > > > > > > > > > > > > > > Andy > > > > > > > > > Andy > > > > > > > > > > On Thu, Nov 7, 2013 at 5:43 AM, Ladislav Lhotka wrote= : > > > Hi, > > > > > > I think that extensions must really obey the rule stated in sec. 6.3.= 1 > of RFC 6020, namely that =93the entire [extension] statement MAY be ignor= ed". > This it not the case for extensions that have side effects on core YANG > statements, and =93xpath-function=94 in particular. > > > > > > This leads me back to what I proposed in Berlin: 6020 needs to be > opened and a limited set of updates applied, which would result in a new > spec and a new YANG version. > > > > > > The set of changes of course requires some discussion. A useful > criterion might be that the changes must not make any existing module > invalid. > > > > > > Lada > > > > > > On 07 Nov 2013, at 04:54, Juergen Schoenwaelder < > j.schoenwaelder@jacobs-university.de> wrote: > > > > > > > On Thu, Nov 07, 2013 at 09:36:05AM +0100, Jernej Tuljak wrote: > > > >> > > > >> It is unfortunate, but even another RFC can't change this. Or can > > > >> it? I'm not familiar with how this works inside IETF. Can you just > > > >> publish a new RFC which updates a section in an existing RFC? Isn'= t > > > >> that more suited for errata or something else that inherently > > > >> obsoletes the existing section? > > > >> > > > > > > > > A new RFC can update sections in existing RFCs. An implementation o= f > > > > the new RFC will claim to be compliant to the OLD RFC and the NEW R= FC > > > > while an implementation that implements the OLD RFC will only claim > to > > > > be compliant to the OLD RFC. So from the procedural side, this is a= ll > > > > fine. > > > > > > > > The WG in charge must of course consider whether any interoperabili= ty > > > > issues may arise from such an update. This is I think the discussio= n > > > > we are having here and there is no generic answer. > > > > > > > > /js > > > > > > > > -- > > > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > > > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, German= y > > > > Fax: +49 421 200 3103 > > > > _______________________________________________ > > > > netmod mailing list > > > > netmod@ietf.org > > > > https://www.ietf.org/mailman/listinfo/netmod > > > > > > -- > > > Ladislav Lhotka, CZ.NIC Labs > > > PGP Key ID: E74E8C0C > > > > > > > > > > > > > > > _______________________________________________ > > > netmod mailing list > > > netmod@ietf.org > > > https://www.ietf.org/mailman/listinfo/netmod > > > > > > > -- > > Ladislav Lhotka, CZ.NIC Labs > > PGP Key ID: E74E8C0C > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > --001a1135ef48f0f95d04ea9c55fb Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable



On Thu, Nov 7, 2013 at 11:28 AM, Ladislav Lhotka = <lhotka@nic.cz>= ; wrote:

On 07 Nov 2013, at 10:58, Andy Bierman <andy@yumaworks.com> wrote:

>
>
>
> On Thu, Nov 7, 2013 at 10:29 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
>
> On 07 Nov 2013, at 07:41, Andy Bierman <andy@yumaworks.com> wrote:
>
> > Hi,
> >
> > I do not have any objection to dropping this work because it
> > cannot be added as an extension. =A0 I am strongly opposed
> > to starting any work on a new version of YANG.
> >
> > There is no such thing as a minor update to a DML.
>
> Why not?
>
> Because the cost of deployment is so high.

You agreed with introducing the XPath functions in a sneaky way via extensi= ons. Would the cost of deployment be any lower in this case? Changing the v= ersion number only means that we are honest with the users.



I agree with Phil's= comment about the must/when statements being conceptual
within t= he server. =A0If the server says it supports a YANG module that uses a new<= /div>
XPath function, then that is just 1 more implementation detail for the= server.

The machine-readable XPath could be repla= ced by description-stmt text.
Both are just implementation requir= ements for a server develop to implement.

=A0
>
>
>
> > Introducing a new language version while many projects still
> > depend on the current version causes market confusion, increases<= br> > > support costs and reduces adoption and deployment. =A0It should > > only be done if the new features and problems fixed are worth the= cost.
> > These XPath extensions are not that important.
>
> IMO (a) it is rather important (e.g. derived-from), and (b) there are = other things that need fixing.
>
>
> I don't think this is a big problem.
> The purpose of YANG is officially the DML for the NETCONF protocol. > Within NETCONF the must/when statements are conceptual -- an XPath par= ser
> is not required to implement a YANG module in the server. Support for<= br> > off-line message validation tools is not the focus of NETCONF.

No, the expressions must be valid XPath and must be evaluated exactly as an= XPath processor would do.

It is valid = XPath. =A0There are no requirements at all for the server to evaluate any X= Path.
The server code must implement the correct behavior no matter what. = =A0The client cannot
tell if the server used an XPath parser or n= ot.

=A0

>
> The concern with identityrefs is that they are really QNames but they = are encoded
> in XPath as strings. =A0This is only a problem if the server actually = supports multiple
> identities with the same base with the same local-name. =A0We could ea= sily publish
> a convention for encoding this QName as a string -- e.g., same as your= JSON --
> use the module name as the prefix.

Sure, we could do that, but only in a YANG 2 (or 1.1) spec. RFC 6020 define= s an encoding that is based on XML context and prefixes, and this is where = an equality test may fail. This is where things can break in subtle and une= xpected ways, especially if it happens in a =93when=94 statement.

=A0
must/when statements use YANG prefixes, n= ot XML prefixes.

I have no confidence that a "= ;quick" YANG 1.1 can be done.
I think that IETF charter mile= stones are a cruel joke and taking 3 years to
complete an 8 month project is unfortunately the norm, not the excepti= on.
The use of extensions is much better because it only affects = the YANG modules
that use the new XPath functions. =A0A server ve= ndor can choose to implement the
new module or not. A client that needs to support the new module may n= eed to
change. =A0If the YANG version changes the client must cha= nge to even parse the YANG module.



=A0

Lada


Andy
=A0<= /div>

>
>
>
>
>
> >
> > IMO, NETMOD should finish up the current YANG modules and
> > then shut down for several years. =A0Let other WGs create data mo= dels.
> > The IETF needs more experience with YANG before knowing what
> > really needs to be in YANG 2.0.
>
> With (hopefully) many YANG modules around, it will become much harder = to change anything in YANG than it is now.
>
>
> IMO changing the DML version should only be done as a last resort.
> YANG 1.0 is good enough for WGs and vendors to use now.
>
>
>
>
> >
> >
> > Andy
> >
>
>
> Andy
>
>
> >
> > On Thu, Nov 7, 2013 at 5:43 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
> > Hi,
> >
> > I think that extensions must really obey the rule stated in sec. = 6.3.1 of RFC 6020, namely that =93the entire [extension] statement MAY be i= gnored". This it not the case for extensions that have side effects on= core YANG statements, and =93xpath-function=94 in particular.
> >
> > This leads me back to what I proposed in Berlin: 6020 needs to be= opened and a limited set of updates applied, which would result in a new s= pec and a new YANG version.
> >
> > The set of changes of course requires some discussion. A useful c= riterion might be that the changes must not make any existing module invali= d.
> >
> > Lada
> >
> > On 07 Nov 2013, at 04:54, Juergen Schoenwaelder <j.schoenwaelder@jacobs-universit= y.de> wrote:
> >
> > > On Thu, Nov 07, 2013 at 09:36:05AM +0100, Jernej Tuljak wrot= e:
> > >>
> > >> It is unfortunate, but even another RFC can't change= this. Or can
> > >> it? I'm not familiar with how this works inside IETF= . Can you just
> > >> publish a new RFC which updates a section in an existing= RFC? Isn't
> > >> that more suited for errata or something else that inher= ently
> > >> obsoletes the existing section?
> > >>
> > >
> > > A new RFC can update sections in existing RFCs. An implement= ation of
> > > the new RFC will claim to be compliant to the OLD RFC and th= e NEW RFC
> > > while an implementation that implements the OLD RFC will onl= y claim to
> > > be compliant to the OLD RFC. So from the procedural side, th= is is all
> > > fine.
> > >
> > > The WG in charge must of course consider whether any interop= erability
> > > issues may arise from such an update. This is I think the di= scussion
> > > we are having here and there is no generic answer.
> > >
> > > /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, Germany
> > > Fax: =A0 +49 421 200 3103 =A0 =A0 =A0 =A0 <http://www.jacobs-universi= ty.de/>
> > > _______________________________________________
> > > netmod mailing list
> > > netmod@ietf.org
> > > https://www.ietf.org/mailman/listinfo/netmod
> >
> > --
> > Ladislav Lhotka, CZ.NIC Labs
> > PGP Key ID: E74E8C0C
> >
> >
> >
> >
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> >
>
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C

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




--001a1135ef48f0f95d04ea9c55fb-- From lhotka@nic.cz Thu Nov 7 13:05:15 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE58511E81B3 for ; Thu, 7 Nov 2013 13:05:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yW7e3yEdv1FV for ; Thu, 7 Nov 2013 13:05:14 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id B548511E8116 for ; Thu, 7 Nov 2013 13:05:13 -0800 (PST) Received: from [172.16.34.210] (unknown [64.114.24.114]) by mail.nic.cz (Postfix) with ESMTPSA id 5769513FA81; Thu, 7 Nov 2013 22:05:10 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1383858312; bh=N4lmziy9BCo8t9igoO6QB59/Fm4GuLsq0GS59f+Rsn4=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=yN/Cl1qnb/kB2PS9ifpJTb3fLdKuFGsltGwQJdlEOtvqqR+H2DoWEeEgPXDS9DSD8 gPvdWOTdNJkaWJ4te5GaR+JnCKzCh9OWImO6a3JZYqO7zL/h0SZpHvLOQBPG8EEtIk N2E/HsrjvHY9PjAaKt4I8LvebSAp6E/xNoXJZMm4= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) From: Ladislav Lhotka In-Reply-To: <20131107.122716.427722758.mbj@tail-f.com> Date: Thu, 7 Nov 2013 13:05:07 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20131107.122716.427722758.mbj@tail-f.com> To: =?windows-1252?Q?Martin_Bj=F6rklund?= X-Mailer: Apple Mail (2.1816) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] Fw: New Version Notification for draft-bjorklund-netmod-yang-xpath-extensions-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 21:05:15 -0000 On 07 Nov 2013, at 12:27, Martin Bjorklund wrote: > Ladislav Lhotka wrote: >>> The concern with identityrefs is that they are really QNames but = they >>> are encoded >>> in XPath as strings. This is only a problem if the server actually >>> supports multiple >>> identities with the same base with the same local-name. We could >>> easily publish >>> a convention for encoding this QName as a string -- e.g., same as = your >>> JSON -- >>> use the module name as the prefix. >>=20 >> Sure, we could do that, but only in a YANG 2 (or 1.1) spec. RFC 6020 >> defines an encoding that is based on XML context and prefixes, and >> this is where an equality test may fail. >=20 > I think we should keep the prefixed name. The problem is an omission > in 6020 - it specifies that the prefixed name is ued in the "default" > statement, but it should say "default", "when" and "must=94. It says =93=85 identity name in the default value MAY have a prefix.=94 = (sec 9.10.3), and the preceding paragraph defines the default namespace = if no prefix is used. So if a prefix is on one side of =91=3D=91 and no = prefix on the other side, the quality test will fail. Lada >=20 > Anyway, this only solves the equality test, not the 'derived-from'. >=20 >=20 > /martin -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From lhotka@nic.cz Thu Nov 7 13:27:07 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBBBD11E8110 for ; Thu, 7 Nov 2013 13:27:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.849 X-Spam-Level: X-Spam-Status: No, score=-1.849 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oxSRw9VgT4HG for ; Thu, 7 Nov 2013 13:27:03 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 13DE511E8101 for ; Thu, 7 Nov 2013 13:27:03 -0800 (PST) Received: from [172.16.34.210] (unknown [64.114.24.114]) by mail.nic.cz (Postfix) with ESMTPSA id 6389A13FA81; Thu, 7 Nov 2013 22:26:59 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1383859622; bh=Vb9Q3XVFLr7njfnF02TUnKvLpjE5vJVCBEapYuR3N78=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=deW9OyDviYdoxhZp7WYuH4Cb/2e64QmJusmtF00xgRAUaPYkbh6XUqvE5E7P1SBVN 5XpursyZsqT4vi1y9zwHjwGsTIVPhMSfA061UFvE1Fr/KfGzXMUq0qdINV6KAqHgY2 fpXECfD8t52yJ7NvBOmhTlB4gV6cSVOvBi+7QvV8= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) From: Ladislav Lhotka In-Reply-To: Date: Thu, 7 Nov 2013 13:26:56 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <527A155C.6010605@mg-soft.com> <20131106.113628.386256580.mbj@tail-f.com> <527B50F5.80000@mg-soft.com> <20131107125440.GC87223@elstar.local> To: Andy Bierman X-Mailer: Apple Mail (2.1816) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Cc: "netmod@ietf.org" Subject: Re: [netmod] Fw: New Version Notification for draft-bjorklund-netmod-yang-xpath-extensions-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 21:27:07 -0000 On 07 Nov 2013, at 12:44, Andy Bierman wrote: >=20 >=20 >=20 > On Thu, Nov 7, 2013 at 11:28 AM, Ladislav Lhotka = wrote: >=20 > On 07 Nov 2013, at 10:58, Andy Bierman wrote: >=20 > > > > > > > > On Thu, Nov 7, 2013 at 10:29 AM, Ladislav Lhotka = wrote: > > > > On 07 Nov 2013, at 07:41, Andy Bierman wrote: > > > > > Hi, > > > > > > I do not have any objection to dropping this work because it > > > cannot be added as an extension. I am strongly opposed > > > to starting any work on a new version of YANG. > > > > > > There is no such thing as a minor update to a DML. > > > > Why not? > > > > Because the cost of deployment is so high. >=20 > You agreed with introducing the XPath functions in a sneaky way via = extensions. Would the cost of deployment be any lower in this case? = Changing the version number only means that we are honest with the = users. >=20 >=20 >=20 > I agree with Phil's comment about the must/when statements being = conceptual > within the server. If the server says it supports a YANG module that = uses a new > XPath function, then that is just 1 more implementation detail for the = server. But it will be the same even if the version number is bumped. >=20 > The machine-readable XPath could be replaced by description-stmt text. > Both are just implementation requirements for a server develop to = implement. So why do we bother with the XPath stuff? container universe { description =93Dear implementor, remove me with all my content if ../foo =3D = 42.=94; =85 } >=20 > =20 > > > > > > > > > Introducing a new language version while many projects still > > > depend on the current version causes market confusion, increases > > > support costs and reduces adoption and deployment. It should > > > only be done if the new features and problems fixed are worth the = cost. > > > These XPath extensions are not that important. > > > > IMO (a) it is rather important (e.g. derived-from), and (b) there = are other things that need fixing. > > > > > > I don't think this is a big problem. > > The purpose of YANG is officially the DML for the NETCONF protocol. > > Within NETCONF the must/when statements are conceptual -- an XPath = parser > > is not required to implement a YANG module in the server. Support = for > > off-line message validation tools is not the focus of NETCONF. >=20 > No, the expressions must be valid XPath and must be evaluated exactly = as an XPath processor would do. >=20 > It is valid XPath. There are no requirements at all for the server to = evaluate any XPath. > The server code must implement the correct behavior no matter what. = The client cannot > tell if the server used an XPath parser or not. Exactly, so identities must be compared as strings, because this is what = an XPath processor does. >=20 > =20 >=20 > > > > The concern with identityrefs is that they are really QNames but = they are encoded > > in XPath as strings. This is only a problem if the server actually = supports multiple > > identities with the same base with the same local-name. We could = easily publish > > a convention for encoding this QName as a string -- e.g., same as = your JSON -- > > use the module name as the prefix. >=20 > Sure, we could do that, but only in a YANG 2 (or 1.1) spec. RFC 6020 = defines an encoding that is based on XML context and prefixes, and this = is where an equality test may fail. This is where things can break in = subtle and unexpected ways, especially if it happens in a =93when=94 = statement. >=20 > =20 > must/when statements use YANG prefixes, not XML prefixes. "An identityref is encoded as the referred identity's qualified name as = defined in [XML-NAMES].=94 >=20 > I have no confidence that a "quick" YANG 1.1 can be done. > I think that IETF charter milestones are a cruel joke and taking 3 = years to > complete an 8 month project is unfortunately the norm, not the = exception. > The use of extensions is much better because it only affects the YANG = modules > that use the new XPath functions. A server vendor can choose to = implement the > new module or not. A client that needs to support the new module may = need to > change. If the YANG version changes the client must change to even = parse the YANG module. I don=92t see how an extension differs from a function definition that = is a part of YANG spec. What really matters is whether new functions = appear in XPath expressions or not. Lada >=20 >=20 >=20 > =20 >=20 > Lada >=20 >=20 > Andy > =20 >=20 > > > > > > > > > > > > > > > > IMO, NETMOD should finish up the current YANG modules and > > > then shut down for several years. Let other WGs create data = models. > > > The IETF needs more experience with YANG before knowing what > > > really needs to be in YANG 2.0. > > > > With (hopefully) many YANG modules around, it will become much = harder to change anything in YANG than it is now. > > > > > > IMO changing the DML version should only be done as a last resort. > > YANG 1.0 is good enough for WGs and vendors to use now. > > > > > > > > > > > > > > > > > Andy > > > > > > > > > Andy > > > > > > > > > > On Thu, Nov 7, 2013 at 5:43 AM, Ladislav Lhotka = wrote: > > > Hi, > > > > > > I think that extensions must really obey the rule stated in sec. = 6.3.1 of RFC 6020, namely that =93the entire [extension] statement MAY = be ignored". This it not the case for extensions that have side effects = on core YANG statements, and =93xpath-function=94 in particular. > > > > > > This leads me back to what I proposed in Berlin: 6020 needs to be = opened and a limited set of updates applied, which would result in a new = spec and a new YANG version. > > > > > > The set of changes of course requires some discussion. A useful = criterion might be that the changes must not make any existing module = invalid. > > > > > > Lada > > > > > > On 07 Nov 2013, at 04:54, Juergen Schoenwaelder = wrote: > > > > > > > On Thu, Nov 07, 2013 at 09:36:05AM +0100, Jernej Tuljak wrote: > > > >> > > > >> It is unfortunate, but even another RFC can't change this. Or = can > > > >> it? I'm not familiar with how this works inside IETF. Can you = just > > > >> publish a new RFC which updates a section in an existing RFC? = Isn't > > > >> that more suited for errata or something else that inherently > > > >> obsoletes the existing section? > > > >> > > > > > > > > A new RFC can update sections in existing RFCs. An = implementation of > > > > the new RFC will claim to be compliant to the OLD RFC and the = NEW RFC > > > > while an implementation that implements the OLD RFC will only = claim to > > > > be compliant to the OLD RFC. So from the procedural side, this = is all > > > > fine. > > > > > > > > The WG in charge must of course consider whether any = interoperability > > > > issues may arise from such an update. This is I think the = discussion > > > > we are having here and there is no generic answer. > > > > > > > > /js > > > > > > > > -- > > > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > > > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, = Germany > > > > Fax: +49 421 200 3103 = > > > > _______________________________________________ > > > > netmod mailing list > > > > netmod@ietf.org > > > > https://www.ietf.org/mailman/listinfo/netmod > > > > > > -- > > > Ladislav Lhotka, CZ.NIC Labs > > > PGP Key ID: E74E8C0C > > > > > > > > > > > > > > > _______________________________________________ > > > netmod mailing list > > > netmod@ietf.org > > > https://www.ietf.org/mailman/listinfo/netmod > > > > > > > -- > > Ladislav Lhotka, CZ.NIC Labs > > PGP Key ID: E74E8C0C >=20 > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C >=20 >=20 >=20 >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From internet-drafts@ietf.org Thu Nov 7 14:02:04 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC2C521E8144; Thu, 7 Nov 2013 14:02:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.572 X-Spam-Level: X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wAzRgPLJWOkS; Thu, 7 Nov 2013 14:02:04 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 789C511E8127; Thu, 7 Nov 2013 14:02:04 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.83 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131107220204.21849.43112.idtracker@ietfa.amsl.com> Date: Thu, 07 Nov 2013 14:02:04 -0800 Cc: netmod@ietf.org Subject: [netmod] I-D Action: draft-ietf-netmod-system-mgmt-09.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 22:02:05 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the NETCONF Data Modeling Language Working Gr= oup of the IETF. Title : YANG Data Model for System Management Author(s) : Andy Bierman Martin Bjorklund Filename : draft-ietf-netmod-system-mgmt-09.txt Pages : 37 Date : 2013-11-07 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-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netmod-system-mgmt-09 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 yiya@cisco.com Thu Nov 7 15:49:56 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E8A611E812F for ; Thu, 7 Nov 2013 15:49:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cSAUpa8e4N-p for ; Thu, 7 Nov 2013 15:49:51 -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 D4D2511E8162 for ; Thu, 7 Nov 2013 15:49:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=203; q=dns/txt; s=iport; t=1383868190; x=1385077790; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=+xTa/Lf59tACr94g+3fkFDtDC6FAcHjWiG1nN03KsOA=; b=epyPhl4d+qOJVUwFyJWI0wSW++vbQdK1mHajIjKFAzCDR1tznLSwxOVr NWmtcWqX0TAHUPrnJudAHSE8aXkz21G8MD+vKVeMjFWon5fOwvgL0s1wj vrdqXjROoYBVbw2Cv3uCWf1emssPSICTGfNsd0KIMUg3oGPmL8a7kal6K k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApQGAIomfFKtJV2c/2dsb2JhbABagweBC8A4Fm0Hgiw6UQE+QicEiBSbVqFelBADmAySCoMmgio X-IronPort-AV: E=Sophos;i="4.93,655,1378857600"; d="scan'208";a="282212913" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-5.cisco.com with ESMTP; 07 Nov 2013 23:49:50 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id rA7NnooP023399 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 7 Nov 2013 23:49:50 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.19]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0123.003; Thu, 7 Nov 2013 17:49:50 -0600 From: "Yi Yang (yiya)" To: "netmod@ietf.org" Thread-Topic: draft-ietf-netmod-ip-cfg Thread-Index: AQHO3BQLM5qI3G26gU2gG2vjnLO2mg== Date: Thu, 7 Nov 2013 23:49:49 +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.7.130812 x-originating-ip: [10.82.247.83] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [netmod] draft-ietf-netmod-ip-cfg X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 23:49:56 -0000 I have to admit I was confused by the title at my first glance. As the doc focuses on interface management, IMO, an title like "A YANG Data Model for IP Interface Management" seems more clear. Yi From internet-drafts@ietf.org Thu Nov 7 15:54:02 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1280511E80FA; Thu, 7 Nov 2013 15:54:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.572 X-Spam-Level: X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CciHUnNcZLrF; Thu, 7 Nov 2013 15:54:01 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E57911E81C9; Thu, 7 Nov 2013 15:54:01 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.83 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131107235401.21849.46605.idtracker@ietfa.amsl.com> Date: Thu, 07 Nov 2013 15:54:01 -0800 Cc: netmod@ietf.org Subject: [netmod] I-D Action: draft-ietf-netmod-iana-if-type-08.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 23:54:02 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the NETCONF Data Modeling Language Working Gr= oup of the IETF. Title : IANA Interface Type YANG Module Author(s) : Martin Bjorklund Filename : draft-ietf-netmod-iana-if-type-08.txt Pages : 40 Date : 2013-11-07 Abstract: This document defines the initial version of the iana-if-type YANG module. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-iana-if-type There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-netmod-iana-if-type-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netmod-iana-if-type-08 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 internet-drafts@ietf.org Thu Nov 7 15:55:52 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3235421E81A7; Thu, 7 Nov 2013 15:55:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.572 X-Spam-Level: X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4HIs+NTwZcbA; Thu, 7 Nov 2013 15:55:51 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B198721E808F; Thu, 7 Nov 2013 15:55:51 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.83 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131107235551.21816.75544.idtracker@ietfa.amsl.com> Date: Thu, 07 Nov 2013 15:55:51 -0800 Cc: netmod@ietf.org Subject: [netmod] I-D Action: draft-ietf-netmod-interfaces-cfg-13.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 23:55:52 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the NETCONF Data Modeling Language Working Gr= oup of the IETF. Title : A YANG Data Model for Interface Management Author(s) : Martin Bjorklund Filename : draft-ietf-netmod-interfaces-cfg-13.txt Pages : 45 Date : 2013-11-07 Abstract: This document defines a YANG data model for the management of network interfaces. It is expected that interface type specific data models augment the generic interfaces data model defined in this document. The data model includes configuration data, state data and counters for the collection of statistics. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-interfaces-cfg There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-netmod-interfaces-cfg-13 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netmod-interfaces-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 j.schoenwaelder@jacobs-university.de Thu Nov 7 16:09:46 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA20A11E829A for ; Thu, 7 Nov 2013 16:09:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.194 X-Spam-Level: X-Spam-Status: No, score=-103.194 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YUtHNfvjZ0ZJ for ; Thu, 7 Nov 2013 16:09:35 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 6CB6E11E829D for ; Thu, 7 Nov 2013 16:09:35 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 357472008C; Fri, 8 Nov 2013 01:09:31 +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 6aeEyep37wgf; Fri, 8 Nov 2013 01:09:31 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 675C120078; Fri, 8 Nov 2013 01:09:30 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 754CE29324FD; Fri, 8 Nov 2013 01:09:25 +0100 (CET) Date: Fri, 8 Nov 2013 01:09:25 +0100 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20131108000924.GA90184@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] vancouver meeting summary and action items X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Nov 2013 00:09:46 -0000 Hi! About 60 people attended the NETMOD meeting in Vancouver. The chartered documents and the associated actions items are listed below: - draft-ietf-netmod-ip-cfg has been sent to the AD (Benoit). - draft-ietf-netmod-interfaces-cfg and draft-ietf-netmod-iana-if-type will both be revised once more to change the interface type to an identity. The documents will then be sent to the AD (Benoit). - draft-ietf-netmod-routing-cfg will be updated after the IETF meeting and then put into WG last call. - draft-ietf-netmod-system-mgmt and draft-ietf-netmod-iana-timezones have completed WG last call. The shepherd (Juergen) has to produce a writeup and then the document will be send to the AD (Benoit). - draft-ietf-netmod-snmp-cfg has been updated shortly before the meeting and the authors believe it is complete. It will go to WG last call. The remaining meeting time was used to look at some of the proposed new work. The meeting went short of time and further discussions of proposed new work and whether the WG should recharter or close down once all chartered documents have been delivered will take place on the mailing list. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From internet-drafts@ietf.org Thu Nov 7 16:41:11 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C4EF21E8194; Thu, 7 Nov 2013 16:41:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.572 X-Spam-Level: X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ug4R1MoBx3Q6; Thu, 7 Nov 2013 16:41:10 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E53321E8153; Thu, 7 Nov 2013 16:41:10 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.83 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131108004053.7919.85402.idtracker@ietfa.amsl.com> Date: Thu, 07 Nov 2013 16:40:53 -0800 Cc: netmod@ietf.org Subject: [netmod] I-D Action: draft-ietf-netmod-routing-cfg-12.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Nov 2013 00:41:11 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the NETCONF Data Modeling Language Working Gr= oup of the IETF. Title : A YANG Data Model for Routing Management Author(s) : Ladislav Lhotka Filename : draft-ietf-netmod-routing-cfg-12.txt Pages : 92 Date : 2013-11-07 Abstract: This document contains a specification of three YANG modules. Together they form the core routing data model which serves as a framework for configuring and managing a routing subsystem. It is expected that these modules will be augmented by additional YANG modules defining data models for individual routing protocols and other related functions. The core routing data model provides common building blocks for such extensions - routing instances, routes, routing information bases (RIB), routing protocols and route filters. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-routing-cfg There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-netmod-routing-cfg-12 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netmod-routing-cfg-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 j.schoenwaelder@jacobs-university.de Thu Nov 7 19:09:56 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 361D811E818C for ; Thu, 7 Nov 2013 19:09:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.195 X-Spam-Level: X-Spam-Status: No, score=-103.195 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j+IEwEYTHgNv for ; Thu, 7 Nov 2013 19:09:51 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 1428B21F898A for ; Thu, 7 Nov 2013 19:09:25 -0800 (PST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id D5506200A6; Fri, 8 Nov 2013 04:09:23 +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 hVaZV9tohKoJ; Fri, 8 Nov 2013 04:09:23 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 69E9D2009F; Fri, 8 Nov 2013 04:09:23 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id D7CC3293291B; Fri, 8 Nov 2013 04:09:17 +0100 (CET) Date: Fri, 8 Nov 2013 04:09:17 +0100 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20131108030917.GA90715@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] vancouver meeting minutes X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Nov 2013 03:09:56 -0000 Hi, I have posted meeting minutes: http://www.ietf.org/proceedings/88/minutes/minutes-88-netmod Please let me know if something needs correction. Thanks to Alex for taking notes. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From jeffrey.K.lange@ge.com Fri Nov 8 06:17:36 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB41111E8184; Fri, 8 Nov 2013 06:17:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.082 X-Spam-Level: X-Spam-Status: No, score=-6.082 tagged_above=-999 required=5 tests=[AWL=0.517, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C+nbTvrfohlh; Fri, 8 Nov 2013 06:17:30 -0800 (PST) Received: from exprod5og104.obsmtp.com (exprod5og104.obsmtp.com [64.18.0.178]) by ietfa.amsl.com (Postfix) with ESMTP id 0387011E8138; Fri, 8 Nov 2013 06:17:29 -0800 (PST) Received: from cinmlip13.e2k.ad.ge.com ([12.71.149.1]) (using TLSv1) by exprod5ob104.postini.com ([64.18.4.12]) with SMTP ID DSNKUnzydhkEy+/ThtJkmxJ5n0FxIerqcDhA@postini.com; Fri, 08 Nov 2013 06:17:30 PST Received: from unknown (HELO ALPMBHT04.e2k.ad.ge.com) ([3.159.19.197]) by cinmlip13.e2k.ad.ge.com with ESMTP/TLS/AES128-SHA; 08 Nov 2013 09:17:24 -0500 Received: from CINMLCH01.e2k.ad.ge.com (3.159.212.50) by ALPMBHT04.e2k.ad.ge.com (3.159.19.197) with Microsoft SMTP Server (TLS) id 14.3.146.0; Fri, 8 Nov 2013 09:17:22 -0500 Received: from CINURAPD01.e2k.ad.ge.com (3.159.212.109) by cinmlch01.e2k.ad.ge.com (3.159.212.50) with Microsoft SMTP Server (TLS) id 14.3.146.0; Fri, 8 Nov 2013 09:17:18 -0500 Received: from CINURCNA15.e2k.ad.ge.com ([169.254.3.12]) by CINURAPD01.e2k.ad.ge.com ([169.254.7.204]) with mapi id 14.03.0146.000; Fri, 8 Nov 2013 09:17:18 -0500 From: "Lange, Jeffrey K (GE Energy Management)" To: "internet-drafts@ietf.org" , "i-d-announce@ietf.org" Thread-Topic: [netmod] I-D Action: draft-ietf-netmod-interfaces-cfg-13.txt Thread-Index: AQHO3BT7IGgZEQySp0qAgNsSVmRAfJobYWjQ Date: Fri, 8 Nov 2013 14:17:17 +0000 Message-ID: References: <20131107235551.21816.75544.idtracker@ietfa.amsl.com> In-Reply-To: <20131107235551.21816.75544.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [3.159.212.187] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "netmod@ietf.org" Subject: Re: [netmod] I-D Action: draft-ietf-netmod-interfaces-cfg-13.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Nov 2013 14:17:37 -0000 The examples in this document are using ianaift: for the interface type, an= d section 3.1 has added a paragraph about the iana-if-type module. But the= data model uses the new interface-type identity Also section 9.2 added in a regerence to the iana-if-type draft. -Jeff > -----Original Message----- > From: netmod-bounces@ietf.org [mailto:netmod-bounces@ietf.org] On Behalf > Of internet-drafts@ietf.org > Sent: Thursday, November 07, 2013 6:56 PM > To: i-d-announce@ietf.org > Cc: netmod@ietf.org > Subject: [netmod] I-D Action: draft-ietf-netmod-interfaces-cfg-13.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the NETCONF Data Modeling Language Working > Group of the IETF. >=20 > Title : A YANG Data Model for Interface Management > Author(s) : Martin Bjorklund > Filename : draft-ietf-netmod-interfaces-cfg-13.txt > Pages : 45 > Date : 2013-11-07 >=20 > Abstract: > This document defines a YANG data model for the management of network > interfaces. It is expected that interface type specific data models > augment the generic interfaces data model defined in this document. > The data model includes configuration data, state data and counters > for the collection of statistics. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-netmod-interfaces-cfg >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-netmod-interfaces-cfg-13 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netmod-interfaces-cfg-13 >=20 >=20 > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From mbj@tail-f.com Fri Nov 8 07:07:12 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB63B11E8128; Fri, 8 Nov 2013 07:07:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.968 X-Spam-Level: X-Spam-Status: No, score=-1.968 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HGu0YAeFYu20; Fri, 8 Nov 2013 07:07:06 -0800 (PST) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id E9CB021E8113; Fri, 8 Nov 2013 07:07:04 -0800 (PST) Received: from localhost (dhcp-9507.meeting.ietf.org [31.133.149.7]) by mail.tail-f.com (Postfix) with ESMTPSA id A3C5A12000B3; Fri, 8 Nov 2013 16:07:02 +0100 (CET) Date: Fri, 08 Nov 2013 07:07:00 -0800 (PST) Message-Id: <20131108.070700.405832473.mbj@tail-f.com> To: jeffrey.K.lange@ge.com From: Martin Bjorklund In-Reply-To: References: <20131107235551.21816.75544.idtracker@ietfa.amsl.com> X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: internet-drafts@ietf.org, netmod@ietf.org, i-d-announce@ietf.org Subject: Re: [netmod] I-D Action: draft-ietf-netmod-interfaces-cfg-13.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Nov 2013 15:07:12 -0000 Hi, "Lange, Jeffrey K (GE Energy Management)" wrote: > The examples in this document are using ianaift: for the interface > type, and section 3.1 has added a paragraph about the iana-if-type > module. But the data model uses the new interface-type identity > > Also section 9.2 added in a regerence to the iana-if-type draft. I am sorry, but I don't understand what you mean. Can you point to a specific bug/inconsistency? /martin From jeffrey.K.lange@ge.com Fri Nov 8 07:13:27 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A410321E8194; Fri, 8 Nov 2013 07:13:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.11 X-Spam-Level: X-Spam-Status: No, score=-6.11 tagged_above=-999 required=5 tests=[AWL=0.490, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l5DlkZvHl7eW; Fri, 8 Nov 2013 07:13:21 -0800 (PST) Received: from exprod5og111.obsmtp.com (exprod5og111.obsmtp.com [64.18.0.22]) by ietfa.amsl.com (Postfix) with ESMTP id 05CD621E8183; Fri, 8 Nov 2013 07:13:16 -0800 (PST) Received: from alpmlip10.e2k.ad.ge.com ([165.156.5.1]) (using TLSv1) by exprod5ob111.postini.com ([64.18.4.12]) with SMTP ID DSNKUnz/jFMfW8T8jqrO1ZItfCYC6arI1OLK@postini.com; Fri, 08 Nov 2013 07:13:17 PST Received: from unknown (HELO CINMBHT04.e2k.ad.ge.com) ([3.159.212.197]) by alpmlip10.e2k.ad.ge.com with ESMTP/TLS/AES128-SHA; 08 Nov 2013 10:13:15 -0500 Received: from CINURCNA20.e2k.ad.ge.com (3.159.212.168) by CINMBHT04.e2k.ad.ge.com (3.159.212.197) with Microsoft SMTP Server (TLS) id 14.3.146.0; Fri, 8 Nov 2013 10:13:15 -0500 Received: from CINURCNA15.e2k.ad.ge.com ([169.254.3.12]) by CINURCNA20.e2k.ad.ge.com ([169.254.2.221]) with mapi id 14.03.0146.000; Fri, 8 Nov 2013 10:13:11 -0500 From: "Lange, Jeffrey K (GE Energy Management)" To: Martin Bjorklund Thread-Topic: [netmod] I-D Action: draft-ietf-netmod-interfaces-cfg-13.txt Thread-Index: AQHO3BT7IGgZEQySp0qAgNsSVmRAfJobYWjQgABimAD//60TsA== Date: Fri, 8 Nov 2013 15:13:10 +0000 Message-ID: References: <20131107235551.21816.75544.idtracker@ietfa.amsl.com> <20131108.070700.405832473.mbj@tail-f.com> In-Reply-To: <20131108.070700.405832473.mbj@tail-f.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [3.159.212.187] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "internet-drafts@ietf.org" , "netmod@ietf.org" , "i-d-announce@ietf.org" Subject: Re: [netmod] I-D Action: draft-ietf-netmod-interfaces-cfg-13.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Nov 2013 15:13:27 -0000 If interfaces-cfg-13 was created to change the /interfaces/interface/type t= o be an identity, all of the references in the document to the iana-iftype = enumeration should be removed and replaced. e.g: page 6: import iana-if-type { prefix ianaift; } augment "/if:interfaces/if:interface" { when "if:type =3D 'ianaift:ethernetCsmacd'"; container ethernet { leaf duplex { ... } } } > -----Original Message----- > From: Martin Bjorklund [mailto:mbj@tail-f.com] > Sent: Friday, November 08, 2013 10:07 AM > To: Lange, Jeffrey K (GE Energy Management) > Cc: internet-drafts@ietf.org; i-d-announce@ietf.org; netmod@ietf.org > Subject: Re: [netmod] I-D Action: draft-ietf-netmod-interfaces-cfg-13.txt >=20 > Hi, >=20 > "Lange, Jeffrey K (GE Energy Management)" wrote: > > The examples in this document are using ianaift: for the interface > > type, and section 3.1 has added a paragraph about the iana-if-type > > module. But the data model uses the new interface-type identity > > > > Also section 9.2 added in a regerence to the iana-if-type draft. >=20 >=20 > I am sorry, but I don't understand what you mean. Can you point to a > specific bug/inconsistency? >=20 >=20 > /martin From mbj@tail-f.com Fri Nov 8 07:26:44 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F93021E81B3; Fri, 8 Nov 2013 07:26:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.972 X-Spam-Level: X-Spam-Status: No, score=-1.972 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x9aQPdlVRM0G; Fri, 8 Nov 2013 07:26:26 -0800 (PST) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 59F2321E8193; Fri, 8 Nov 2013 07:26:23 -0800 (PST) Received: from localhost (dhcp-9507.meeting.ietf.org [31.133.149.7]) by mail.tail-f.com (Postfix) with ESMTPSA id 4A3A712000B3; Fri, 8 Nov 2013 16:26:18 +0100 (CET) Date: Fri, 08 Nov 2013 07:26:16 -0800 (PST) Message-Id: <20131108.072616.482745166.mbj@tail-f.com> To: jeffrey.K.lange@ge.com From: Martin Bjorklund In-Reply-To: References: <20131108.070700.405832473.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: internet-drafts@ietf.org, netmod@ietf.org, i-d-announce@ietf.org Subject: Re: [netmod] I-D Action: draft-ietf-netmod-interfaces-cfg-13.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Nov 2013 15:26:44 -0000 "Lange, Jeffrey K (GE Energy Management)" wrote: > If interfaces-cfg-13 was created to change the > /interfaces/interface/type to be an identity, all of the references in > the document to the iana-iftype enumeration should be removed and > replaced. Section 3.1 says: The "iana-if-type" module [I-D.ietf-netmod-iana-if-type] defines YANG identities for the interface types in the IANA-maintained "ifType registry". Note that there's a new version of the iana document posted, where the typedef has been replaced with an identity. > e.g: page 6: > > import iana-if-type { > prefix ianaift; > } > > augment "/if:interfaces/if:interface" { > when "if:type = 'ianaift:ethernetCsmacd'"; ^^^^^^^^^^^^^^^^^^^^^^ This is the ethernetCsmacd *identity*, defined in iana-if-type.yang. /martin From jeffrey.K.lange@ge.com Fri Nov 8 07:30:12 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 328D721E81D2 for ; Fri, 8 Nov 2013 07:30:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.134 X-Spam-Level: X-Spam-Status: No, score=-6.134 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ECGtaIPh0aNw for ; Fri, 8 Nov 2013 07:30:03 -0800 (PST) Received: from exprod5og106.obsmtp.com (exprod5og106.obsmtp.com [64.18.0.182]) by ietfa.amsl.com (Postfix) with ESMTP id 8FD9121F9FF6 for ; Fri, 8 Nov 2013 07:30:03 -0800 (PST) Received: from cinmlip13.e2k.ad.ge.com ([12.71.149.1]) (using TLSv1) by exprod5ob106.postini.com ([64.18.4.12]) with SMTP ID DSNKUn0Deyt0b4nZrsP4DWeMjy+yvlJlJQFL@postini.com; Fri, 08 Nov 2013 07:30:03 PST Received: from unknown (HELO ALPMBHT02.e2k.ad.ge.com) ([3.159.19.195]) by cinmlip13.e2k.ad.ge.com with ESMTP/TLS/AES128-SHA; 08 Nov 2013 10:30:01 -0500 Received: from ALPMLCH01.e2k.ad.ge.com (3.159.17.20) by ALPMBHT02.e2k.ad.ge.com (3.159.19.195) with Microsoft SMTP Server (TLS) id 14.3.146.0; Fri, 8 Nov 2013 10:30:01 -0500 Received: from CINURAPD04.e2k.ad.ge.com (3.159.212.112) by alpmlch01.e2k.ad.ge.com (3.159.17.20) with Microsoft SMTP Server (TLS) id 14.3.146.0; Fri, 8 Nov 2013 10:30:00 -0500 Received: from CINURCNA15.e2k.ad.ge.com ([169.254.3.12]) by CINURAPD04.e2k.ad.ge.com ([169.254.10.110]) with mapi id 14.03.0146.000; Fri, 8 Nov 2013 10:30:00 -0500 From: "Lange, Jeffrey K (GE Energy Management)" To: Martin Bjorklund Thread-Topic: [netmod] I-D Action: draft-ietf-netmod-interfaces-cfg-13.txt Thread-Index: AQHO3BT7IGgZEQySp0qAgNsSVmRAfJobYWjQgABimAD//60TsIAAWE8A//+tCGA= Date: Fri, 8 Nov 2013 15:29:59 +0000 Message-ID: References: <20131108.070700.405832473.mbj@tail-f.com> <20131108.072616.482745166.mbj@tail-f.com> In-Reply-To: <20131108.072616.482745166.mbj@tail-f.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [3.159.212.187] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "netmod@ietf.org" Subject: Re: [netmod] I-D Action: draft-ietf-netmod-interfaces-cfg-13.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Nov 2013 15:30:12 -0000 > -----Original Message----- > From: Martin Bjorklund [mailto:mbj@tail-f.com] > Sent: Friday, November 08, 2013 10:26 AM > To: Lange, Jeffrey K (GE Energy Management) > Cc: internet-drafts@ietf.org; i-d-announce@ietf.org; netmod@ietf.org > Subject: Re: [netmod] I-D Action: draft-ietf-netmod-interfaces-cfg-13.txt >=20 > "Lange, Jeffrey K (GE Energy Management)" wrote: > > If interfaces-cfg-13 was created to change the > > /interfaces/interface/type to be an identity, all of the references in > > the document to the iana-iftype enumeration should be removed and > > replaced. >=20 > Section 3.1 says: >=20 > The "iana-if-type" module [I-D.ietf-netmod-iana-if-type] defines YANG > identities for the interface types in the IANA-maintained "ifType > registry". >=20 > Note that there's a new version of the iana document posted, where the > typedef has been replaced with an identity. Ahh.. I guess I missed that.. sorry for the confusion... -Jeff >=20 > > e.g: page 6: > > > > import iana-if-type { > > prefix ianaift; > > } > > > > augment "/if:interfaces/if:interface" { > > when "if:type =3D 'ianaift:ethernetCsmacd'"; > ^^^^^^^^^^^^^^^^^^^^^^ >=20 > This is the ethernetCsmacd *identity*, defined in iana-if-type.yang. >=20 >=20 > /martin From ietfc@btconnect.com Fri Nov 8 10:25:17 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C15DB11E81C1 for ; Fri, 8 Nov 2013 10:25:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=-0.927, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fFk5mpNWlK4m for ; Fri, 8 Nov 2013 10:25:12 -0800 (PST) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe005.messaging.microsoft.com [216.32.181.185]) by ietfa.amsl.com (Postfix) with ESMTP id 67A8011E8108 for ; Fri, 8 Nov 2013 10:25:12 -0800 (PST) Received: from mail215-ch1-R.bigfish.com (10.43.68.242) by CH1EHSOBE003.bigfish.com (10.43.70.53) with Microsoft SMTP Server id 14.1.225.22; Fri, 8 Nov 2013 18:25:10 +0000 Received: from mail215-ch1 (localhost [127.0.0.1]) by mail215-ch1-R.bigfish.com (Postfix) with ESMTP id 5D6E9380289; Fri, 8 Nov 2013 18:25:10 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.249.213; KIP:(null); UIP:(null); IPV:NLI; H:AM2PRD0710HT005.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -15 X-BigFish: PS-15(zz9371I542I1432I4015Izz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h20f7h1d1ah1d2ah1fc6hzz1de098h1033IL8275bh8275dh1de097h186068hz2dh2a8h5a9h839h947hd24hf0ah1177h1179h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h1758h17f1h184fh1898h18e1h1946h19b5h19ceh1ad9h1b0ah2222h224fh1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1e23h2218h2216h304l1d11m1155h) Received: from mail215-ch1 (localhost.localdomain [127.0.0.1]) by mail215-ch1 (MessageSwitch) id 1383935109458022_21549; Fri, 8 Nov 2013 18:25:09 +0000 (UTC) Received: from CH1EHSMHS037.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.231]) by mail215-ch1.bigfish.com (Postfix) with ESMTP id 6B3B036020D; Fri, 8 Nov 2013 18:25:09 +0000 (UTC) Received: from AM2PRD0710HT005.eurprd07.prod.outlook.com (157.56.249.213) by CH1EHSMHS037.bigfish.com (10.43.69.246) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 8 Nov 2013 18:25:09 +0000 Received: from AMXPRD0310HT002.eurprd03.prod.outlook.com (157.56.248.133) by pod51017.outlook.com (10.255.165.40) with Microsoft SMTP Server (TLS) id 14.16.371.2; Fri, 8 Nov 2013 18:24:53 +0000 Message-ID: <02c901cedcaf$7a166a80$4001a8c0@gateway.2wire.net> From: t.petch To: David Kessens , References: Date: Fri, 8 Nov 2013 17:58:13 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.248.133] X-OriginatorOrg: btconnect.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: Re: [netmod] Last chance for review: draft-ietf-netmod-ip-cfg &draft-ietf-netmod-ip-cfg X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Nov 2013 18:25:17 -0000 David Again harking back to May, another lengthy discussion over interfaces was about name, which is in both interfaces/interface and interfaces-state/interface. Where I think we ended up was that an interface could appear in one list or the other list or both, but when it does appear in botch (mmm interesting typo, both I think), then it is this name that ties the entries in the two lists together. This is sort of implied but not explicitly stated, and while it may become obvious, it was not so on this list in May so I think it shoud be explicitly stated, as in my first sentence, in s.3.1. Tom Petch ----- Original Message ----- From: "David Kessens" To: Sent: Monday, November 04, 2013 2:20 AM > Hi, > > As the document shepherd for: > > draft-ietf-netmod-interfaces-cfg-12 > and > draft-ietf-netmod-ip-cfg-11 > > I have requested our Area Director Benoit whether he can take up the > document for final IESG review. > > I have done a final review and I have not found any changes that are more > than minor/already has consensus since our last calls. > > Since Benoit will be busy during this week, you will have until the end of > this week if there is anything that escaped our attention that you believe > needs more discussion. > > Thanks, > > David Kessens > --- > ------------------------------------------------------------------------ -------- > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From ietfc@btconnect.com Fri Nov 8 10:25:18 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 033C711E8108 for ; Fri, 8 Nov 2013 10:25:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.433 X-Spam-Level: X-Spam-Status: No, score=-2.433 tagged_above=-999 required=5 tests=[AWL=-0.794, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t48BS-i78CrC for ; Fri, 8 Nov 2013 10:25:12 -0800 (PST) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe005.messaging.microsoft.com [216.32.181.185]) by ietfa.amsl.com (Postfix) with ESMTP id D4A5311E81A2 for ; Fri, 8 Nov 2013 10:25:12 -0800 (PST) Received: from mail77-ch1-R.bigfish.com (10.43.68.243) by CH1EHSOBE003.bigfish.com (10.43.70.53) with Microsoft SMTP Server id 14.1.225.22; Fri, 8 Nov 2013 18:25:11 +0000 Received: from mail77-ch1 (localhost [127.0.0.1]) by mail77-ch1-R.bigfish.com (Postfix) with ESMTP id 0340F20282; Fri, 8 Nov 2013 18:25:11 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.249.213; KIP:(null); UIP:(null); IPV:NLI; H:AM2PRD0710HT005.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -15 X-BigFish: PS-15(zz9371I542I1432I4015Izz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h20f7h1d1ah1d2ah1fc6hzz1de098h1033IL8275bh8275dh1de097h186068hz2dh2a8h5a9h839h947hd24hf0ah1177h1179h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h1758h17f1h184fh1898h18e1h1946h19b5h19ceh1ad9h1b0ah2222h224fh1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1e23h2218h2216h304l1d11m1155h) Received: from mail77-ch1 (localhost.localdomain [127.0.0.1]) by mail77-ch1 (MessageSwitch) id 1383935109105169_30119; Fri, 8 Nov 2013 18:25:09 +0000 (UTC) Received: from CH1EHSMHS037.bigfish.com (snatpool3.int.messaging.microsoft.com [10.43.68.225]) by mail77-ch1.bigfish.com (Postfix) with ESMTP id 1578D10004D; Fri, 8 Nov 2013 18:25:09 +0000 (UTC) Received: from AM2PRD0710HT005.eurprd07.prod.outlook.com (157.56.249.213) by CH1EHSMHS037.bigfish.com (10.43.69.246) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 8 Nov 2013 18:25:09 +0000 Received: from AMXPRD0310HT002.eurprd03.prod.outlook.com (157.56.248.133) by pod51017.outlook.com (10.255.165.40) with Microsoft SMTP Server (TLS) id 14.16.371.2; Fri, 8 Nov 2013 18:24:52 +0000 Message-ID: <02c801cedcaf$79dc6ec0$4001a8c0@gateway.2wire.net> From: t.petch To: David Kessens , References: Date: Fri, 8 Nov 2013 17:52:32 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.248.133] X-OriginatorOrg: btconnect.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: Re: [netmod] Last chance for review: draft-ietf-netmod-ip-cfg &draft-ietf-netmod-ip-cfg X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Nov 2013 18:25:18 -0000 David Back in May there was a lengthy debate about what identifier should be used for the two types of interfaces and what the semantic difference between them was. We now have system-controlled interface and user-controlled interface with definitions of both, which I think good, but I think the work is not quite complete. We still have quite a lot of 'physical' and a pair of 'logical', which, to me, are the obsoleted terms and most of them I think should be replaced. e.g. "The data model should support both physical interfaces as well as logical interfaces" which, given the length of discussion we had on those terms, I think cannot help the reader. Tom Petch ----- Original Message ----- From: "David Kessens" To: Sent: Monday, November 04, 2013 2:20 AM > As the document shepherd for: > > draft-ietf-netmod-interfaces-cfg-12 > and > draft-ietf-netmod-ip-cfg-11 > > I have requested our Area Director Benoit whether he can take up the > document for final IESG review. > > I have done a final review and I have not found any changes that are more > than minor/already has consensus since our last calls. > > Since Benoit will be busy during this week, you will have until the end of > this week if there is anything that escaped our attention that you believe > needs more discussion. > > Thanks, > > David Kessens > --- > ------------------------------------------------------------------------ -------- > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From lhotka@nic.cz Fri Nov 8 11:32:23 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A88D821E81DA for ; Fri, 8 Nov 2013 11:32:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.564 X-Spam-Level: X-Spam-Status: No, score=-1.564 tagged_above=-999 required=5 tests=[AWL=-0.165, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V5FYCLT+WjJe for ; Fri, 8 Nov 2013 11:32: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 1002A11E81A2 for ; Fri, 8 Nov 2013 11:32:15 -0800 (PST) Received: from [172.16.34.210] (unknown [64.114.24.114]) by mail.nic.cz (Postfix) with ESMTPSA id 5C56613FD9F; Fri, 8 Nov 2013 20:32:11 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1383939133; bh=fmVWxFAxqeCqcyQpJaXrGEbyRivVOjy4yQY7kr8r3N4=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=Z5RkxnMXtR54cOHedCNoF7e8dlmEuj1GddMqUiQ8LwfXKNesIK+zhM5uzFX+rrsK5 0nDyy+XSJgNrzrx9HEyXGjejZWd2F7G7txJETAsVpMVWmy73jcMctSExQhkKqKzkiD 8Xop8WRZ5pYoVQwoIWpWi8WIZn/b8D+7HneqlyoY= Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) Content-Type: text/plain; charset=us-ascii From: Ladislav Lhotka X-Priority: 3 In-Reply-To: <02c901cedcaf$7a166a80$4001a8c0@gateway.2wire.net> Date: Fri, 8 Nov 2013 11:32:07 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <489BFDAE-81B2-4146-9D2C-E381073A6B69@nic.cz> References: <02c901cedcaf$7a166a80$4001a8c0@gateway.2wire.net> To: "t.petch" X-Mailer: Apple Mail (2.1816) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] Last chance for review: draft-ietf-netmod-ip-cfg &draft-ietf-netmod-ip-cfg X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Nov 2013 19:32:23 -0000 Hi, Tom, On 08 Nov 2013, at 09:58, t.petch wrote: > David >=20 > Again harking back to May, another lengthy discussion over interfaces > was about name, which is in both interfaces/interface and > interfaces-state/interface. >=20 > Where I think we ended up was that an interface could appear in one = list > or the other list or both, but when it does appear in botch (mmm > interesting typo, both I think), then it is this name that ties the > entries in the two lists together. This is sort of implied but not > explicitly stated, and while it may become obvious, it was not so on > this list in May so I think it shoud be explicitly stated, as in my > first sentence, in s.3.1. Yes. If you look at the routing draft, it is explicitly stated in sec. = 4.1. If 6020bis is started some day, these definitions should probably go = there, and maybe there could even be an annotation identifying = system-controlled entries. Lada =20 >=20 > Tom Petch >=20 >=20 > ----- Original Message ----- > From: "David Kessens" > To: > Sent: Monday, November 04, 2013 2:20 AM >=20 >=20 >> Hi, >>=20 >> As the document shepherd for: >>=20 >> draft-ietf-netmod-interfaces-cfg-12 >> and >> draft-ietf-netmod-ip-cfg-11 >>=20 >> I have requested our Area Director Benoit whether he can take up the >> document for final IESG review. >>=20 >> I have done a final review and I have not found any changes that are > more >> than minor/already has consensus since our last calls. >>=20 >> Since Benoit will be busy during this week, you will have until the > end of >> this week if there is anything that escaped our attention that you > believe >> needs more discussion. >>=20 >> Thanks, >>=20 >> David Kessens >> --- >>=20 >=20 >=20 > = ------------------------------------------------------------------------ > -------- >=20 >=20 >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >>=20 >=20 >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From mbj@tail-f.com Fri Nov 8 11:53:58 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89FE511E8118 for ; Fri, 8 Nov 2013 11:53:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E4cmDqMTadDP for ; Fri, 8 Nov 2013 11:53:53 -0800 (PST) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 0D18721F9DCE for ; Fri, 8 Nov 2013 11:53:52 -0800 (PST) Received: from localhost (dhcp-9507.meeting.ietf.org [31.133.149.7]) by mail.tail-f.com (Postfix) with ESMTPSA id 1B6D51200054; Fri, 8 Nov 2013 20:53:50 +0100 (CET) Date: Fri, 08 Nov 2013 11:53:48 -0800 (PST) Message-Id: <20131108.115348.186601367.mbj@tail-f.com> To: ietfc@btconnect.com From: Martin Bjorklund In-Reply-To: <02c901cedcaf$7a166a80$4001a8c0@gateway.2wire.net> References: <02c901cedcaf$7a166a80$4001a8c0@gateway.2wire.net> 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 chance for review: draft-ietf-netmod-ip-cfg &draft-ietf-netmod-ip-cfg X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Nov 2013 19:53:58 -0000 t.petch wrote: > David > > Again harking back to May, another lengthy discussion over interfaces > was about name, which is in both interfaces/interface and > interfaces-state/interface. > > Where I think we ended up was that an interface could appear in one > list > or the other list or both, but when it does appear in botch (mmm > interesting typo, both I think), then it is this name that ties the > entries in the two lists together. This is sort of implied but not > explicitly stated Section 3.1 has this: When a system-controlled interface is created by the system, the system tries to apply the interface configuration in /interfaces/ interface with the same name as the new interface. /martin , and while it may become obvious, it was not so on > this list in May so I think it shoud be explicitly stated, as in my > first sentence, in s.3.1. > > Tom Petch > > > ----- Original Message ----- > From: "David Kessens" > To: > Sent: Monday, November 04, 2013 2:20 AM > > > > Hi, > > > > As the document shepherd for: > > > > draft-ietf-netmod-interfaces-cfg-12 > > and > > draft-ietf-netmod-ip-cfg-11 > > > > I have requested our Area Director Benoit whether he can take up the > > document for final IESG review. > > > > I have done a final review and I have not found any changes that are > more > > than minor/already has consensus since our last calls. > > > > Since Benoit will be busy during this week, you will have until the > end of > > this week if there is anything that escaped our attention that you > believe > > needs more discussion. > > > > Thanks, > > > > David Kessens > > --- > > > > > ------------------------------------------------------------------------ > -------- > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From ietfc@btconnect.com Sat Nov 9 04:44:00 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE7AE21E80AE for ; Sat, 9 Nov 2013 04:44:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.534 X-Spam-Level: X-Spam-Status: No, score=-1.534 tagged_above=-999 required=5 tests=[AWL=-1.495, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, RCVD_IN_BL_SPAMCOP_NET=1.96] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WVO4BBjkjiAB for ; Sat, 9 Nov 2013 04:43:55 -0800 (PST) Received: from db9outboundpool.messaging.microsoft.com (mail-db9lp0252.outbound.messaging.microsoft.com [213.199.154.252]) by ietfa.amsl.com (Postfix) with ESMTP id 5A8A421E80B2 for ; Sat, 9 Nov 2013 04:43:55 -0800 (PST) Received: from mail139-db9-R.bigfish.com (10.174.16.233) by DB9EHSOBE034.bigfish.com (10.174.14.97) with Microsoft SMTP Server id 14.1.225.22; Sat, 9 Nov 2013 12:43:54 +0000 Received: from mail139-db9 (localhost [127.0.0.1]) by mail139-db9-R.bigfish.com (Postfix) with ESMTP id 281B74A0604; Sat, 9 Nov 2013 12:43:54 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.249.213; KIP:(null); UIP:(null); IPV:NLI; H:AM2PRD0710HT003.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -16 X-BigFish: PS-16(zz98dI9371I542I1432I4015Izz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h20f7h1d1ah1d2ah1fc6hzz1de098h1033IL8275bh8275dh1de097h186068hz2dh2a8h5a9h839h947hd24hf0ah1177h1179h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h1758h17f1h184fh1898h18e1h1946h19b5h19ceh1ad9h1b0ah2222h224fh1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1e23h2218h2216h304l1d11m1155h) Received: from mail139-db9 (localhost.localdomain [127.0.0.1]) by mail139-db9 (MessageSwitch) id 1384001031663301_21974; Sat, 9 Nov 2013 12:43:51 +0000 (UTC) Received: from DB9EHSMHS002.bigfish.com (unknown [10.174.16.252]) by mail139-db9.bigfish.com (Postfix) with ESMTP id 93C546010A; Sat, 9 Nov 2013 12:43:51 +0000 (UTC) Received: from AM2PRD0710HT003.eurprd07.prod.outlook.com (157.56.249.213) by DB9EHSMHS002.bigfish.com (10.174.14.12) with Microsoft SMTP Server (TLS) id 14.16.227.3; Sat, 9 Nov 2013 12:43:51 +0000 Received: from AMXPRD0111HT002.eurprd01.prod.exchangelabs.com (157.56.250.117) by pod51017.outlook.com (10.255.165.38) with Microsoft SMTP Server (TLS) id 14.16.371.2; Sat, 9 Nov 2013 12:43:50 +0000 Message-ID: <01ad01cedd48$ff61b3e0$4001a8c0@gateway.2wire.net> From: t.petch To: Martin Bjorklund References: <02c901cedcaf$7a166a80$4001a8c0@gateway.2wire.net> <20131108.115348.186601367.mbj@tail-f.com> Date: Sat, 9 Nov 2013 12:31:40 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.250.117] X-OriginatorOrg: btconnect.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: netmod@ietf.org Subject: Re: [netmod] Last chance for review: draft-ietf-netmod-ip-cfg &draft-ietf-netmod-ip-cfg X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Nov 2013 12:44:00 -0000 ----- Original Message ----- From: "Martin Bjorklund" To: Cc: ; Sent: Friday, November 08, 2013 7:53 PM > t.petch wrote: > > David > > > > Again harking back to May, another lengthy discussion over interfaces > > was about name, which is in both interfaces/interface and > > interfaces-state/interface. > > > > Where I think we ended up was that an interface could appear in one > > list > > or the other list or both, but when it does appear in botch (mmm > > interesting typo, both I think), then it is this name that ties the > > entries in the two lists together. This is sort of implied but not > > explicitly stated > > Section 3.1 has this: > > When a system-controlled interface is created by the system, the > system tries to apply the interface configuration in /interfaces/ > interface with the same name as the new interface. Which makes my point nicely. It is sort of implied but not stated explicitly. Read what is there and then, gosh, I just realised, can entries be in both, how are they related? mmm ...well, if that sentence is accurate, then yes, sort of. Tom Petch > > > /martin > > > > , and while it may become obvious, it was not so on > > this list in May so I think it shoud be explicitly stated, as in my > > first sentence, in s.3.1. > > > > Tom Petch > > > > > > ----- Original Message ----- > > From: "David Kessens" > > To: > > Sent: Monday, November 04, 2013 2:20 AM > > > > > > > Hi, > > > > > > As the document shepherd for: > > > > > > draft-ietf-netmod-interfaces-cfg-12 > > > and > > > draft-ietf-netmod-ip-cfg-11 > > > > > > I have requested our Area Director Benoit whether he can take up the > > > document for final IESG review. > > > > > > I have done a final review and I have not found any changes that are > > more > > > than minor/already has consensus since our last calls. > > > > > > Since Benoit will be busy during this week, you will have until the > > end of > > > this week if there is anything that escaped our attention that you > > believe > > > needs more discussion. > > > > > > Thanks, > > > > > > David Kessens > > > --- > > > > > > > > > ---------------------------------------------------------------------- -- > > -------- > > > > > > > _______________________________________________ > > > 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 internet-drafts@ietf.org Tue Nov 12 07:50:17 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F61F21E825A; Tue, 12 Nov 2013 07:50:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.59 X-Spam-Level: X-Spam-Status: No, score=-102.59 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tugSX-04B7VN; Tue, 12 Nov 2013 07:50:16 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A415E21E817D; Tue, 12 Nov 2013 07:50:16 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.83 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131112155016.28813.51693.idtracker@ietfa.amsl.com> Date: Tue, 12 Nov 2013 07:50:16 -0800 Cc: netmod@ietf.org Subject: [netmod] I-D Action: draft-ietf-netmod-iana-timezones-01.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 15:50:17 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the NETCONF Data Modeling Language Working Gr= oup of the IETF. Title : IANA Timezone Database YANG Module Author(s) : Jeffrey Lange Filename : draft-ietf-netmod-iana-timezones-01.txt Pages : 39 Date : 2013-11-12 Abstract: This document defines the iana-timezones YANG module for timezone configuration. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-iana-timezones There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-netmod-iana-timezones-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netmod-iana-timezones-01 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 jeffrey.K.lange@ge.com Tue Nov 12 08:05:54 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5101511E8190 for ; Tue, 12 Nov 2013 08:05:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.156 X-Spam-Level: X-Spam-Status: No, score=-4.156 tagged_above=-999 required=5 tests=[AWL=-1.557, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uR-4QXQ5VreU for ; Tue, 12 Nov 2013 08:05:48 -0800 (PST) Received: from exprod5og119.obsmtp.com (exprod5og119.obsmtp.com [64.18.0.189]) by ietfa.amsl.com (Postfix) with ESMTP id CAA3F11E823B for ; Tue, 12 Nov 2013 08:05:43 -0800 (PST) Received: from cinmlip14.e2k.ad.ge.com ([12.71.149.1]) (using TLSv1) by exprod5ob119.postini.com ([64.18.4.12]) with SMTP ID DSNKUoJRzh4DzX3MJlNYws0tzLZuxf3ifivM@postini.com; Tue, 12 Nov 2013 08:05:44 PST Received: from unknown (HELO CINMBHT03.e2k.ad.ge.com) ([3.159.212.196]) by cinmlip14.e2k.ad.ge.com with ESMTP/TLS/AES128-SHA; 12 Nov 2013 11:05:33 -0500 Received: from ALPMLCH01.e2k.ad.ge.com (3.159.17.20) by CINMBHT03.e2k.ad.ge.com (3.159.212.196) with Microsoft SMTP Server (TLS) id 14.3.146.0; Tue, 12 Nov 2013 11:05:33 -0500 Received: from CINURCNA12.e2k.ad.ge.com (3.159.212.129) by alpmlch01.e2k.ad.ge.com (3.159.17.20) with Microsoft SMTP Server (TLS) id 14.3.146.0; Tue, 12 Nov 2013 11:05:32 -0500 Received: from CINURCNA15.e2k.ad.ge.com ([169.254.3.12]) by CINURCNA12.e2k.ad.ge.com ([169.254.6.143]) with mapi id 14.03.0146.000; Tue, 12 Nov 2013 11:05:32 -0500 From: "Lange, Jeffrey K (GE Energy Management)" To: "netmod@ietf.org" Thread-Topic: New Version Notification for draft-ietf-netmod-iana-timezones-01.txt Thread-Index: AQHO377kCzdDzCmBt06mCCpOHiNlN5ohwUDg Date: Tue, 12 Nov 2013 16:05:31 +0000 Message-ID: References: <20131112155016.28813.13732.idtracker@ietfa.amsl.com> In-Reply-To: <20131112155016.28813.13732.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [3.159.212.187] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [netmod] New Version Notification for draft-ietf-netmod-iana-timezones-01.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 16:05:54 -0000 SSd2ZSB1cGRhdGVkIHRoZSBpYW5hIHRpbWV6b25lIHR5cGVkZWYgdG8gcmVmbGVjdCB0aGUgbGF0 ZXN0IHZlcnNpb24gb2YgdGhlIElBTkEgdGltZXpvbmUgZGF0YWJhc2UuICBIb3dldmVyIGluIGRv aW5nIHRoaXMgSSB0aGluayBJJ3ZlIGZvdW5kIGEgbGFyZ2VyIGlzc3VlLiAgT25lIG9mIHRoZSBj aGFuZ2VzIHdhcyB0aGUgcmVtb3ZhbCBvZiB0aGUgdGltZXpvbmUgIkFudGFyY3RpY2EvU291dGhf UG9sZSIgVGhpcyBsZWFkcyB0byBhIHByb2JsZW0gaWYgd2UgYXJlIHRyeWluZyB0byByZWZsZWN0 IHRoaXMgYXMgYW4gZW51bWVyYXRpb24gKHdpdGggYW4gYXV0byBpbmNyZW1lbnRpbmcgdmFsdWUp LiBXb3VsZCB0aGlzIG5vdCBtYWtlIG1vcmUgc2Vuc2UgdG8gY29udmVydCB0aGlzIHRvIGFuIGlk ZW50aXR5IHNvIHRoYXQgY2hhbmdlcyB0byB0aGUgSUFOQSB0aW1lem9uZSBkYXRhYmFzZSB3b3Vs ZCBub3QgYmUgYXMgaW50cnVzaXZlPw0KDQotSmVmZg0KDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCj4gRnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJu ZXQtZHJhZnRzQGlldGYub3JnXQ0KPiBTZW50OiBUdWVzZGF5LCBOb3ZlbWJlciAxMiwgMjAxMyAx MDo1MCBBTQ0KPiBUbzogTGFuZ2UsIEplZmZyZXkgSyAoR0UgRW5lcmd5IE1hbmFnZW1lbnQpDQo+ IFN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtaWV0Zi1uZXRtb2Qt aWFuYS10aW1lem9uZXMtDQo+IDAxLnR4dA0KPiANCj4gDQo+IEEgbmV3IHZlcnNpb24gb2YgSS1E LCBkcmFmdC1pZXRmLW5ldG1vZC1pYW5hLXRpbWV6b25lcy0wMS50eHQNCj4gaGFzIGJlZW4gc3Vj Y2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBKZWZmcmV5IExhbmdlIGFuZCBwb3N0ZWQgdG8gdGhlDQo+ IElFVEYgcmVwb3NpdG9yeS4NCj4gDQo+IEZpbGVuYW1lOgkgZHJhZnQtaWV0Zi1uZXRtb2QtaWFu YS10aW1lem9uZXMNCj4gUmV2aXNpb246CSAwMQ0KPiBUaXRsZToJCSBJQU5BIFRpbWV6b25lIERh dGFiYXNlIFlBTkcgTW9kdWxlDQo+IENyZWF0aW9uIGRhdGU6CSAyMDEzLTExLTEyDQo+IEdyb3Vw OgkJIG5ldG1vZA0KPiBOdW1iZXIgb2YgcGFnZXM6IDM5DQo+IFVSTDogICAgICAgICAgICAgaHR0 cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi1uZXRtb2QtDQo+IGlh bmEtdGltZXpvbmVzLTAxLnR4dA0KPiBTdGF0dXM6ICAgICAgICAgIGh0dHA6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1uZXRtb2QtaWFuYS0NCj4gdGltZXpvbmVzDQo+IEh0 bWxpemVkOiAgICAgICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1uZXRt b2QtaWFuYS0NCj4gdGltZXpvbmVzLTAxDQo+IERpZmY6ICAgICAgICAgICAgaHR0cDovL3d3dy5p ZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1uZXRtb2QtaWFuYS0NCj4gdGltZXpvbmVz LTAxDQo+IA0KPiBBYnN0cmFjdDoNCj4gICAgVGhpcyBkb2N1bWVudCBkZWZpbmVzIHRoZSBpYW5h LXRpbWV6b25lcyBZQU5HIG1vZHVsZSBmb3IgdGltZXpvbmUNCj4gICAgY29uZmlndXJhdGlvbi4N Cj4gDQo+IA0KPiANCj4gDQo+IFBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUg b2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mDQo+IHN1Ym1pc3Npb24NCj4gdW50aWwgdGhlIGh0 bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4N Cj4gDQo+IFRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg== From j.schoenwaelder@jacobs-university.de Tue Nov 12 08:28:33 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CBB321E822F for ; Tue, 12 Nov 2013 08:28:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.202 X-Spam-Level: X-Spam-Status: No, score=-103.202 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9XRZqJnXale9 for ; Tue, 12 Nov 2013 08:28:28 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id C12FC21E81F8 for ; Tue, 12 Nov 2013 08:28:27 -0800 (PST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id CAF9920056; Tue, 12 Nov 2013 17:28:26 +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 mmD1EdYzIJyY; Tue, 12 Nov 2013 17:28:26 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6587F20054; Tue, 12 Nov 2013 17:28:26 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 9B9272945F3D; Tue, 12 Nov 2013 17:28:20 +0100 (CET) Date: Tue, 12 Nov 2013 17:28:20 +0100 From: Juergen Schoenwaelder To: "Lange, Jeffrey K (GE Energy Management)" Message-ID: <20131112162820.GC3992@elstar.local> Mail-Followup-To: "Lange, Jeffrey K (GE Energy Management)" , "netmod@ietf.org" References: <20131112155016.28813.13732.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] New Version Notification for draft-ietf-netmod-iana-timezones-01.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 16:28:33 -0000 On Tue, Nov 12, 2013 at 04:05:31PM +0000, Lange, Jeffrey K (GE Energy Management) wrote: > I've updated the iana timezone typedef to reflect the latest version of the IANA timezone database. However in doing this I think I've found a larger issue. One of the changes was the removal of the timezone "Antarctica/South_Pole" This leads to a problem if we are trying to reflect this as an enumeration (with an auto incrementing value). Would this not make more sense to convert this to an identity so that changes to the IANA timezone database would not be as intrusive? Thanks for looking into the update. Concerning the removal, I think the proper YANG way would be to mark the status of the enum obsolete. This should actually be discussed in the IANA guidelines. I am not sure how choosing identities instead of enums makes a difference here - perhaps I am missing something? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From mbj@tail-f.com Tue Nov 12 08:31:25 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2729D11E818E for ; Tue, 12 Nov 2013 08:31:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.019 X-Spam-Level: X-Spam-Status: No, score=-2.019 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lpvIoheQjvq0 for ; Tue, 12 Nov 2013 08:31:19 -0800 (PST) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 1459011E810C for ; Tue, 12 Nov 2013 08:31:19 -0800 (PST) Received: from localhost (unknown [193.12.34.23]) by mail.tail-f.com (Postfix) with ESMTPSA id 4ABF91200054; Tue, 12 Nov 2013 17:31:17 +0100 (CET) Date: Tue, 12 Nov 2013 17:31:16 +0100 (CET) Message-Id: <20131112.173116.502008483.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20131112162820.GC3992@elstar.local> References: <20131112155016.28813.13732.idtracker@ietfa.amsl.com> <20131112162820.GC3992@elstar.local> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] New Version Notification for draft-ietf-netmod-iana-timezones-01.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 16:31:25 -0000 Juergen Schoenwaelder wrote: > On Tue, Nov 12, 2013 at 04:05:31PM +0000, Lange, Jeffrey K (GE Energy > Management) wrote: > > I've updated the iana timezone typedef to reflect the latest version > > of the IANA timezone database. However in doing this I think I've > > found a larger issue. One of the changes was the removal of the > > timezone "Antarctica/South_Pole" This leads to a problem if we are > > trying to reflect this as an enumeration (with an auto incrementing > > value). Would this not make more sense to convert this to an identity > > so that changes to the IANA timezone database would not be as > > intrusive? > > Thanks for looking into the update. > > Concerning the removal, I think the proper YANG way would be to mark > the status of the enum obsolete. This should actually be discussed in > the IANA guidelines. +1 > I am not sure how choosing identities instead of > enums makes a difference here - perhaps I am missing something? In fact, using identities give the impression that this is a "decentralized extensible enumeration", which I believe it is not. It is a centralized enumeration. /martin From jeffrey.K.lange@ge.com Tue Nov 12 08:41:08 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAA5F11E8190 for ; Tue, 12 Nov 2013 08:41:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.085 X-Spam-Level: X-Spam-Status: No, score=-6.085 tagged_above=-999 required=5 tests=[AWL=0.514, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U6XhL3ormnoX for ; Tue, 12 Nov 2013 08:41:00 -0800 (PST) Received: from exprod5og112.obsmtp.com (exprod5og112.obsmtp.com [64.18.0.24]) by ietfa.amsl.com (Postfix) with ESMTP id 8B36E11E81AC for ; Tue, 12 Nov 2013 08:41:00 -0800 (PST) Received: from cinmlip12.e2k.ad.ge.com ([12.71.149.1]) (using TLSv1) by exprod5ob112.postini.com ([64.18.4.12]) with SMTP ID DSNKUoJaHPiZzg5hrcapDCf0cErpiIJxRL9l@postini.com; Tue, 12 Nov 2013 08:41:00 PST Received: from unknown (HELO ALPMBHT03.e2k.ad.ge.com) ([3.159.19.196]) by cinmlip12.e2k.ad.ge.com with ESMTP/TLS/AES128-SHA; 12 Nov 2013 11:40:59 -0500 Received: from CINURCNA14.e2k.ad.ge.com (3.159.212.151) by ALPMBHT03.e2k.ad.ge.com (3.159.19.196) with Microsoft SMTP Server (TLS) id 14.3.146.0; Tue, 12 Nov 2013 11:40:58 -0500 Received: from CINURCNA15.e2k.ad.ge.com ([169.254.3.12]) by CINURCNA14.e2k.ad.ge.com ([169.254.2.176]) with mapi id 14.03.0146.000; Tue, 12 Nov 2013 11:40:57 -0500 From: "Lange, Jeffrey K (GE Energy Management)" To: Martin Bjorklund , "j.schoenwaelder@jacobs-university.de" Thread-Topic: [netmod] New Version Notification for draft-ietf-netmod-iana-timezones-01.txt Thread-Index: AQHO377kCzdDzCmBt06mCCpOHiNlN5ohwUDggABbeQCAAADSAP//rHxg Date: Tue, 12 Nov 2013 16:40:57 +0000 Message-ID: References: <20131112155016.28813.13732.idtracker@ietfa.amsl.com> <20131112162820.GC3992@elstar.local> <20131112.173116.502008483.mbj@tail-f.com> In-Reply-To: <20131112.173116.502008483.mbj@tail-f.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [3.159.212.187] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "netmod@ietf.org" Subject: Re: [netmod] New Version Notification for draft-ietf-netmod-iana-timezones-01.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 16:41:08 -0000 > -----Original Message----- > From: Martin Bjorklund [mailto:mbj@tail-f.com] > Sent: Tuesday, November 12, 2013 11:31 AM > To: j.schoenwaelder@jacobs-university.de > Cc: Lange, Jeffrey K (GE Energy Management); netmod@ietf.org > Subject: Re: [netmod] New Version Notification for draft-ietf-netmod-iana= - > timezones-01.txt >=20 > Juergen Schoenwaelder wrote: > > On Tue, Nov 12, 2013 at 04:05:31PM +0000, Lange, Jeffrey K (GE Energy > > Management) wrote: > > > I've updated the iana timezone typedef to reflect the latest version > > > of the IANA timezone database. However in doing this I think I've > > > found a larger issue. One of the changes was the removal of the > > > timezone "Antarctica/South_Pole" This leads to a problem if we are > > > trying to reflect this as an enumeration (with an auto incrementing > > > value). Would this not make more sense to convert this to an identity > > > so that changes to the IANA timezone database would not be as > > > intrusive? > > > > Thanks for looking into the update. > > > > Concerning the removal, I think the proper YANG way would be to mark > > the status of the enum obsolete. This should actually be discussed in > > the IANA guidelines. >=20 > +1 >=20 > > I am not sure how choosing identities instead of > > enums makes a difference here - perhaps I am missing something? >=20 > In fact, using identities give the impression that this is a > "decentralized extensible enumeration", which I believe it is not. It > is a centralized enumeration. >=20 I agree, perhaps it should stay an enumeration, currently the IANA consider= ations talks about adding a new entry, but not removing them: The iana-timezones module is intended to reflect the IANA "timezone database". When a timezone location is added to the database, the "iana-timezone" enumeration MUST be updated as defined in RFC 6020 Section 10 to add the newly created timezone location to the enumeration. The new "enum" statement MUST be added to the "iana- timezone" typedef with the same name as the newly added timezone location. A new enum value MUST be allocated by IANA and applied to the newly created enum entry. New entries MAY be placed in any order in the enumeration as long as the previously assigned enumeration values are not changed. How about in addition: If a timezone location is removed or renamed in the IANA timezone database, the exiting enum statement MUST NOT be removed from the enumeration. The status of the existing enum statement MUST be changed to "obsolete". -Jeff >=20 > /martin From j.schoenwaelder@jacobs-university.de Tue Nov 12 08:47:46 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74A0711E81AD for ; Tue, 12 Nov 2013 08:47:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.204 X-Spam-Level: X-Spam-Status: No, score=-103.204 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eCwnukTsqsrJ for ; Tue, 12 Nov 2013 08:47:29 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id A936221E80AC for ; Tue, 12 Nov 2013 08:47:29 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2524920055; Tue, 12 Nov 2013 17:47:29 +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 ze8h_3DNwWQ3; Tue, 12 Nov 2013 17:47: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 5D87F20058; Tue, 12 Nov 2013 17:47:28 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id EDF11294628F; Tue, 12 Nov 2013 17:47:21 +0100 (CET) Date: Tue, 12 Nov 2013 17:47:20 +0100 From: Juergen Schoenwaelder To: "Lange, Jeffrey K (GE Energy Management)" Message-ID: <20131112164720.GA7296@elstar.local> Mail-Followup-To: "Lange, Jeffrey K (GE Energy Management)" , Martin Bjorklund , "netmod@ietf.org" References: <20131112155016.28813.13732.idtracker@ietfa.amsl.com> <20131112162820.GC3992@elstar.local> <20131112.173116.502008483.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "netmod@ietf.org" Subject: Re: [netmod] New Version Notification for draft-ietf-netmod-iana-timezones-01.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 16:47:46 -0000 On Tue, Nov 12, 2013 at 04:40:57PM +0000, Lange, Jeffrey K (GE Energy Management) wrote: > > > How about in addition: > If a timezone location is removed or renamed in the IANA timezone > database, the exiting enum statement MUST NOT be removed from the > enumeration. The status of the existing enum statement MUST be > changed to "obsolete". > I suggest to discuss remove and renaming separately for clarity, e.g. something like this: If a timezone location is removed in the IANA timezone database, the corresponding existing enum statement is kept and a status statement is added to mark the enum 'obsolete'. If a timezone location is renamed in the IANA timezone database, a new enum is added with the new timezone name (as described above) and the enum representing the old timezone name is kept but marked with a status statement declaring the enum 'obsolete'. Since IANA is not having YANG expertise, we may want to add concrete examples they can work with (e.g. using the south pole 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 j.schoenwaelder@jacobs-university.de Mon Nov 18 07:19:21 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCCBB11E82D3 for ; Mon, 18 Nov 2013 07:19:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.39 X-Spam-Level: X-Spam-Status: No, score=-101.39 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oTl4aQuyKlYa for ; Mon, 18 Nov 2013 07:19:06 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 7B64011E8167 for ; Mon, 18 Nov 2013 07:11:35 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7D5F8200BE; Mon, 18 Nov 2013 16:11:34 +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 q8A-3zeDDzVQ; Mon, 18 Nov 2013 16:11:34 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0AD2C20027; Mon, 18 Nov 2013 16:11:33 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 605C6297604A; Mon, 18 Nov 2013 16:11:28 +0100 (CET) Date: Mon, 18 Nov 2013 16:11:27 +0100 From: Juergen Schoenwaelder To: "Lange, Jeffrey K (GE Energy Management)" Message-ID: <20131118151126.GB39299@elstar.local> Mail-Followup-To: "Lange, Jeffrey K (GE Energy Management)" , "netmod@ietf.org" References: <20131112155016.28813.13732.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] New Version Notification for draft-ietf-netmod-iana-timezones-01.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Nov 2013 15:19:22 -0000 Jeffrey, I took a look at the revised documents and this is where I think we are in terms of pending updates: - Leave only one revision statement since we do not track revisions of I-Ds with revision statements (I-Ds are not published documents but just temporary drafts documenting work-in-progress). - Is the IANA description of Europe/Berlin really "most locations"? - Text should be added to the IANA considerations that explains how IANA has to deal with removals and renamings. Can we get this worked out and a revised I-D posted in a few days? I would like to put this together with the system configuration document on Benoit's desk. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From alex@cisco.com Tue Nov 19 13:43:56 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C9881AE078 for ; Tue, 19 Nov 2013 13:43:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.025 X-Spam-Level: X-Spam-Status: No, score=-15.025 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.525, 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 Zzbmt10LiZsU for ; Tue, 19 Nov 2013 13:43:53 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 715851ADF4B for ; Tue, 19 Nov 2013 13:43:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7964; q=dns/txt; s=iport; t=1384897427; x=1386107027; h=from:to:cc:subject:date:message-id:mime-version; bh=qP2GjaKbw3tSwz6IFqZ9qIN1RuzgbMPde2QCbsKj2g8=; b=lykDdtgNJI7RrDJv/uc9TW5oWlFVOVWxKfvaaDfMyPb6gbamKfYurwND at21bse3Ic191wcEcO1Pj5wvqb4StYM9pnG8zfJH+K/jxgomdY/tqWeEv e6neWZYaHW9hOn1VF8d8gGHzd7PmKVUjbBTsgnpbUVgKx7Nz1fxoUlMFy Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArMFAEbai1KtJXG+/2dsb2JhbABZgkNEOFO/QIEhFm0HgicBBC1MEgEqViYBBA4Nh3m/axePJjGDJ4ESA6ofgyiCKg X-IronPort-AV: E=Sophos;i="4.93,732,1378857600"; d="scan'208,217";a="286151897" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-2.cisco.com with ESMTP; 19 Nov 2013 21:43:46 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id rAJLhkS6030235 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 19 Nov 2013 21:43:46 GMT Received: from xmb-rcd-x05.cisco.com ([169.254.15.100]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0123.003; Tue, 19 Nov 2013 15:43:46 -0600 From: "Alexander Clemm (alex)" To: "netmod@ietf.org" Thread-Topic: On the road towards a YANG data model for Stateless Packet Filters Thread-Index: Ac7lb6xst8kIj6DfTC2L87vQ/fbU+Q== Date: Tue, 19 Nov 2013 21:43:45 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.154.204.145] Content-Type: multipart/alternative; boundary="_000_DBC595ED2346914F9F81D17DD5C32B5718615AD6xmbrcdx05ciscoc_" MIME-Version: 1.0 Subject: [netmod] On the road towards a YANG data model for Stateless Packet Filters 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, 19 Nov 2013 21:43:56 -0000 --_000_DBC595ED2346914F9F81D17DD5C32B5718615AD6xmbrcdx05ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, at the IETF 88 in Vancouver, we were going to present an update on the YANG= data model for stateless packet filter configuration - draft-huang-netmod-= acl-03.txt, but unfortunately the session ran out of time before. Therefor= e we wanted to give a quick update on the mailer. Just to recap, the draft presents an extensible and modular framework for m= anagement of stateless packet filters (SPFs). IP, MAC, and ARP are address= ed as initial SPF types, more can be defined. We presented the first draft = of this a year ago in Atlanta, then an update in Orlando. There was good s= upport for this expressed by the working group. A number of changes have be= en incorporated into subsequent revisions based on feedback from the group,= including an explanation of how SPF chains would be supported, and (new in= this latest revision 03) refactoring this to stateless packet filters (bey= ond ACLs). Our ask is to adopt this as a standards-track working group item. We believ= e there are several strong reasons for this: SPFs and ACLs are an importan= t part of device configuration. They are needed both by administrators and= by applications. Also, many SDN-type applications involve control loops i= nvolving manipulation of stateless packet filters; in the context of I2RS (= which looks like it will leverage YANG) and Open Daylight (which does today= ) this need been repeatedly stated. Clearly, standardization is needed to = enable this and, if not championed by the IETF, may well happen outside. Si= nce we have been discussing this data model for a while, we believe that it= is time for the working group to reach a decision. Please let us know if you have any questions. We would also like to ask yo= u to please speak up and let the working group know if you believe that thi= s should be pursued further. Thanks --- Lisa, Alex, Andy --_000_DBC595ED2346914F9F81D17DD5C32B5718615AD6xmbrcdx05ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

at the IETF 88 in Vancouver, we were going to present an =
update on the YANG data model for stateless packet filter configuration - d=
raft-huang-netmod-acl-03.txt, but unfortunately the session ran out of time=
 before.  Therefore we wanted to give a quick update on the mailer.&nb=
sp; 
 

Just to recap, the draft presents an ex= tensible and modular framework for management of stateless packet filters (= SPFs).  IP, MAC, and ARP are addressed as initial SPF types, more can be defined. We presented the first draft of this a year ago in At= lanta, then an update in Orlando.  There was good support for this exp= ressed by the working group. A number of changes have been incorporated int= o subsequent revisions based on feedback from the group, including an explanation of how SPF chains would be suppor= ted, and (new in this latest revision 03) refactoring this to stateless pac= ket filters (beyond ACLs).  

 

Our ask is to adopt this as a standards= -track working group item. We believe there are several strong reasons= for this:  SPFs and ACLs are an important part of device configuratio= n.  They are needed both by administrators and by applications.  Also, ma= ny SDN-type applications involve control loops involving manipulation of st= ateless packet filters; in the context of I2RS (which looks like it will le= verage YANG) and Open Daylight (which does today) this need been repeatedly stated.  Clearly, standardizati= on is needed to enable this and, if not championed by the IETF, may well ha= ppen outside. Since we have been discussing this data model for a while, we= believe that it is time for the working group to reach a decision.

 

Please let us know if you have any ques= tions.  We would also like to ask you to please speak up and let the w= orking group know if you believe that this should be pursued further. 

 

Thanks

--- Lisa, Alex, Andy<= /p>

 

--_000_DBC595ED2346914F9F81D17DD5C32B5718615AD6xmbrcdx05ciscoc_-- From j.schoenwaelder@jacobs-university.de Tue Nov 19 23:00:28 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBEE81AE374 for ; Tue, 19 Nov 2013 23:00:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.775 X-Spam-Level: X-Spam-Status: No, score=-2.775 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.525] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RFTKoc1-YGYn for ; Tue, 19 Nov 2013 23:00: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 4E9611A1F76 for ; Tue, 19 Nov 2013 23:00:26 -0800 (PST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7ECD22008F; Wed, 20 Nov 2013 08:00:19 +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 83XISGEPOnoQ; Wed, 20 Nov 2013 08:00:19 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id ABD78200AF; Wed, 20 Nov 2013 08:00:18 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 433502979879; Wed, 20 Nov 2013 08:00:12 +0100 (CET) Date: Wed, 20 Nov 2013 08:00:12 +0100 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20131120070012.GA44513@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] poll of interest on I-Ds submitted to the NETMOD WG 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, 20 Nov 2013 07:00:28 -0000 Hi, at the last WG meeting in Vancouver, we did run out of time to discuss what to do with the various individual I-Ds that have been submitted to the NETMOD WG. So I like to poll for opinions on the list in order to get a feeling where we are. In particular, I like to poll for opinions on whether the following I-Ds should be worked on in an IETF working group and how you see the priorities. In particular, it would be nice to know who is willing to actively review documents and also who is planning to implement the technology proposed in the various I-Ds. YANG Infrastructure: [1] http://tools.ietf.org/id/draft-bierman-netmod-yang-conformance-01.txt [2] http://tools.ietf.org/id/draft-bjorklund-netmod-yang-xpath-extensions-00.txt [3] http://tools.ietf.org/id/draft-lhotka-netmod-yang-json-02.txt Data Models: [4] http://tools.ietf.org/id/draft-huang-netmod-acl-03.txt [5] http://tools.ietf.org/id/draft-clemm-netmod-yang-network-topo-01.txt Other Stuff: [6] http://tools.ietf.org/id/draft-clemm-netmod-mount-01.txt If I am missing an I-D that is mature enough to be included in this list, please let me know. /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 Wed Nov 20 05:23:47 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAF181ADF72 for ; Wed, 20 Nov 2013 05:23:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] 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 cQ7kMaCrXvmi for ; Wed, 20 Nov 2013 05:23:46 -0800 (PST) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 3ACDA1ADF65 for ; Wed, 20 Nov 2013 05:23:46 -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 72D0F12002BA; Wed, 20 Nov 2013 14:23:39 +0100 (CET) Date: Wed, 20 Nov 2013 14:23:39 +0100 (CET) Message-Id: <20131120.142339.298369920756989697.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20131120070012.GA44513@elstar.local> References: <20131120070012.GA44513@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] poll of interest on I-Ds submitted to the NETMOD WG 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, 20 Nov 2013 13:23:47 -0000 Juergen Schoenwaelder wrote: > Hi, > > at the last WG meeting in Vancouver, we did run out of time to discuss > what to do with the various individual I-Ds that have been submitted > to the NETMOD WG. So I like to poll for opinions on the list in order > to get a feeling where we are. In particular, I like to poll for > opinions on whether the following I-Ds should be worked on in an IETF > working group and how you see the priorities. In particular, it would > be nice to know who is willing to actively review documents and also > who is planning to implement the technology proposed in the various > I-Ds. > > YANG Infrastructure: > > [1] http://tools.ietf.org/id/draft-bierman-netmod-yang-conformance-01.txt My problem with this document is that it identifies a couple of real issues, but the proposed solution doesn't address them. Specifically the problem w/ import-by revision (2.1.1) and the problem with supporting just an identity but not the data tree in a module (last sentence in 2.2). (In fact, I think the YANG specification needs to be updated to fix these issues). > [2] > http://tools.ietf.org/id/draft-bjorklund-netmod-yang-xpath-extensions-00.txt I obviously think this is a good idea, but I can also see that doing this as part of a minor update to YANG (1.1) makes sense. (we implement most of the features in this document already) > [3] http://tools.ietf.org/id/draft-lhotka-netmod-yang-json-02.txt I think this document should be adopted, I am willing to review it, and we are already implementing this mapping. > Data Models: > > [4] http://tools.ietf.org/id/draft-huang-netmod-acl-03.txt > [5] http://tools.ietf.org/id/draft-clemm-netmod-yang-network-topo-01.txt I support these documents, but I am not sure that NETMOD is the right home for them. I am also willing to review them from a YANG perspective; I cannot claim that I have enough domain expertise though. > Other Stuff: > > [6] http://tools.ietf.org/id/draft-clemm-netmod-mount-01.txt This document touches the important issue of how to model a network-wide system, including the devices in the network. (We actually discussed this issue in a bar bof in Maastricht). But I think the solution described is too implementation-specific, and thus limiting for other implementations. /martin From andy@yumaworks.com Wed Nov 20 07:03:15 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD9591AE3EB for ; Wed, 20 Nov 2013 07:03:15 -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 PgbXevkf6x8v for ; Wed, 20 Nov 2013 07:03:12 -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 2306A1ADF99 for ; Wed, 20 Nov 2013 07:03:12 -0800 (PST) Received: by mail-qc0-f179.google.com with SMTP id v1so2194274qcw.38 for ; Wed, 20 Nov 2013 07:03:05 -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=SI0yec/0C3qavFs2edt9KtzSy0QB0qEqwtvoK6sMC1Y=; b=E8X3YiFfKoLFHuvlsctKbstn8nF1QvUbjpV7MpWf09UPSbhMJs4N0++9ka/76cadrN bKNGK0Hd7cpSLWbRS351KnhDKF9nKmBoTVmZtB9tlceIWlqSXuV0cSmKJZ5V3a0sNWHF 6vuMj3sLGvUrpzg4oX2pRpYUuiCjub+JnTsGJga7PXr9gQa1wbe7dDvAzkHVn0O0vsfK iqaJ6oxWJOR6z/hOv/U0/0JIBnqtATsIQYm4p/o2AhqF5kUIyVXao0roxxtq7TImdM7q VkQoup3yeMMP69T4Uh6MFzqsB6+QPrpRA5wCjU3/UUQOAz+I8UDE/RgH29WG72HLkX5R oPuQ== X-Gm-Message-State: ALoCoQnBIGa73E6FuYGYrT8LzmxjZ+cX+zztb1DAFo9zplrIFQkqGMoZAsBeo0q3F4KLGnVx2ikq MIME-Version: 1.0 X-Received: by 10.224.11.68 with SMTP id s4mr2201685qas.88.1384959785399; Wed, 20 Nov 2013 07:03:05 -0800 (PST) Received: by 10.140.86.200 with HTTP; Wed, 20 Nov 2013 07:03:05 -0800 (PST) In-Reply-To: <20131120.142339.298369920756989697.mbj@tail-f.com> References: <20131120070012.GA44513@elstar.local> <20131120.142339.298369920756989697.mbj@tail-f.com> Date: Wed, 20 Nov 2013 07:03:05 -0800 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: multipart/alternative; boundary=001a11c2c370099dc704eb9d1451 Cc: "netmod@ietf.org" Subject: Re: [netmod] poll of interest on I-Ds submitted to the NETMOD WG 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, 20 Nov 2013 15:03:16 -0000 --001a11c2c370099dc704eb9d1451 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Nov 20, 2013 at 5:23 AM, Martin Bjorklund wrote: > Juergen Schoenwaelder wrote: > > Hi, > > > > at the last WG meeting in Vancouver, we did run out of time to discuss > > what to do with the various individual I-Ds that have been submitted > > to the NETMOD WG. So I like to poll for opinions on the list in order > > to get a feeling where we are. In particular, I like to poll for > > opinions on whether the following I-Ds should be worked on in an IETF > > working group and how you see the priorities. In particular, it would > > be nice to know who is willing to actively review documents and also > > who is planning to implement the technology proposed in the various > > I-Ds. > > > > YANG Infrastructure: > > > > [1] > http://tools.ietf.org/id/draft-bierman-netmod-yang-conformance-01.txt > > My problem with this document is that it identifies a couple of real > issues, but the proposed solution doesn't address them. Specifically > the problem w/ import-by revision (2.1.1) and the problem with > supporting just an identity but not the data tree in a module (last > sentence in 2.2). (In fact, I think the YANG specification needs to > be updated to fix these issues). > > For import-by-revision, the min-version and max-version can be set the same for every module used in the conformance profile. Why doesn't this address the definition-drift problem that import-by-revision does a horrible job attempting to solve? For importing only meta-data like identities, the module-conformance leaf would be set to 'import'. Why doesn't this address the problem of the confused client that does not know if this module is implemented of just imported for meta-data? IMO any solution that uses the YANG module for all conformance information is going to be module-centric. In order to describe service-level conformance, multiple YANG modules and even NETCONF capabilities may be required. > [2] > > > http://tools.ietf.org/id/draft-bjorklund-netmod-yang-xpath-extensions-00.txt > > I obviously think this is a good idea, but I can also see that doing > this as part of a minor update to YANG (1.1) makes sense. > > (we implement most of the features in this document already) > > > [3] http://tools.ietf.org/id/draft-lhotka-netmod-yang-json-02.txt > > I think this document should be adopted, I am willing to review it, > and we are already implementing this mapping. > > > Data Models: > > > > [4] http://tools.ietf.org/id/draft-huang-netmod-acl-03.txt > > [5] http://tools.ietf.org/id/draft-clemm-netmod-yang-network-topo-01.txt > > I support these documents, but I am not sure that NETMOD is the right > home for them. I am also willing to review them from a YANG > perspective; I cannot claim that I have enough domain expertise > though. > +1 although there does not seem to be enough interest in the IETF to do domain-specific data models. In SNMP days, there were WGs for specific MIB modules. I think this time the YANG work will probably happen in other SDOs. > > > Other Stuff: > > > > [6] http://tools.ietf.org/id/draft-clemm-netmod-mount-01.txt > > This document touches the important issue of how to model a > network-wide system, including the devices in the network. (We > actually discussed this issue in a bar bof in Maastricht). But I > think the solution described is too implementation-specific, and thus > limiting for other implementations. > > I think the problem of network-wide data models is different than the NFS Mount type solution in this draft. The concept of config that is changed on server X, but affects X, Y, and Z needs a lot of thought. IMO it is too complicated to standardize. We can standardize the mid-level-manager that is actually running the network-wide model, but distribution through proprietary clustering (or other management frameworks) is going to be too implementation-specific. > /martin > Andy --001a11c2c370099dc704eb9d1451 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Wed, Nov 20, 2013 at 5:23 AM, Martin Bjorklund <mbj@tail-f.com= > wrote:
Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de<= /a>> wrote:
> Hi,
>
> at the last WG meeting in Vancouver, we did run out of time to discuss=
> what to do with the various individual I-Ds that have been submitted > to the NETMOD WG. So I like to poll for opinions on the list in order<= br> > to get a feeling where we are. In particular, I like to poll for
> opinions on whether the following I-Ds should be worked on in an IETF<= br> > working group and how you see the priorities. In particular, it would<= br> > be nice to know who is willing to actively review documents and also > who is planning to implement the technology proposed in the various > I-Ds.
>
> YANG Infrastructure:
>
> [1] http://tools.ietf.org/id/draft-bierman-ne= tmod-yang-conformance-01.txt

My problem with this document is that it identifies a couple of real
issues, but the proposed solution doesn't address them. =A0Specifically=
the problem w/ import-by revision (2.1.1) and the problem with
supporting just an identity but not the data tree in a module (last
sentence in 2.2). =A0(In fact, I think the YANG specification needs to
be updated to fix these issues).



For import-by-revision,= the min-version and max-version can be set the
same for every mo= dule used in the conformance profile. =A0Why doesn't
this add= ress the definition-drift problem that import-by-revision does
a horrible job attempting to solve?

For impor= ting only meta-data like identities, the module-conformance leaf
= would be set to 'import'. =A0Why doesn't this address the probl= em of the
confused client that does not know if this module is implemented of ju= st imported
for meta-data?

IMO any solut= ion that uses the YANG module for all conformance information
is going to be module-centric. =A0In order to describe service-level confor= mance,
multiple YANG modules and even NETCONF capabilities may be= required.


http://tools.ietf.org/id/draft-bjorklu= nd-netmod-yang-xpath-extensions-00.txt

I obviously think this is a good idea, but I can also see that doing
this as part of a minor update to YANG (1.1) makes sense.

(we implement most of the features in this document already)

> [3] http://tools.ietf.org/id/draft-lhotka-netmod-yang= -json-02.txt

I think this document should be adopted, I am willing to review it,
and we are already implementing this mapping.

> Data Models:
>
> [4] http://tools.ietf.org/id/draft-huang-netmod-acl-03.txt
> [5] http://tools.ietf.org/id/draft-clemm-netmo= d-yang-network-topo-01.txt

I support these documents, but I am not sure that NETMOD is the right
home for them. =A0I am also willing to review them from a YANG
perspective; I cannot claim that I have enough domain expertise
though.


+1 although ther= e does not seem to be enough interest in the IETF
to do domain-sp= ecific data models. =A0In SNMP days, there were
WGs for specific = MIB modules. =A0I think this time the YANG work will
probably happen in other SDOs.
=A0

> Other Stuff:
>
> [6] http://tools.ietf.org/id/draft-clemm-netmod-mount-01.t= xt

This document touches the important issue of how to model a
network-wide system, including the devices in the network. =A0(We
actually discussed this issue in a bar bof in Maastricht). =A0But I
think the solution described is too implementation-specific, and thus
limiting for other implementations.



I think the problem of = network-wide data models is different than the NFS
Mount type sol= ution in this draft. =A0The concept of config that is changed
on server X, but affects X, Y, and Z needs a lot of thought. =A0IMO it is t= oo
complicated to standardize. =A0We can standardize the mid-leve= l-manager
that is actually running the network-wide model, but di= stribution through
proprietary clustering (or other management frameworks) is going to
be too implementation-specific.


=

/martin


Andy
= =A0
--001a11c2c370099dc704eb9d1451-- From internet-drafts@ietf.org Wed Nov 20 07:52:08 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 905591AE443; Wed, 20 Nov 2013 07:52:08 -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 YT8dpkWVMvIx; Wed, 20 Nov 2013 07:52:07 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F07AA1AE43D; Wed, 20 Nov 2013 07:52:04 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.83.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131120155204.11850.18696.idtracker@ietfa.amsl.com> Date: Wed, 20 Nov 2013 07:52:04 -0800 Cc: netmod@ietf.org Subject: [netmod] I-D Action: draft-ietf-netmod-iana-timezones-02.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: Wed, 20 Nov 2013 15:52:08 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the NETCONF Data Modeling Language Working Gr= oup of the IETF. Title : IANA Timezone Database YANG Module Author(s) : Jeffrey Lange Filename : draft-ietf-netmod-iana-timezones-02.txt Pages : 39 Date : 2013-11-20 Abstract: This document defines the iana-timezones YANG module for timezone configuration. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-iana-timezones There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-netmod-iana-timezones-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netmod-iana-timezones-02 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 Wed Nov 20 08:03:49 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00B031AE475 for ; Wed, 20 Nov 2013 08:03:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] 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 xejFVgH-mS5Z for ; Wed, 20 Nov 2013 08:03:47 -0800 (PST) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 4D6BE1AE3FC for ; Wed, 20 Nov 2013 08:03:47 -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 22F4E12000A3; Wed, 20 Nov 2013 17:03:40 +0100 (CET) Date: Wed, 20 Nov 2013 17:03:39 +0100 (CET) Message-Id: <20131120.170339.157290014569112009.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: <20131120070012.GA44513@elstar.local> <20131120.142339.298369920756989697.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] poll of interest on I-Ds submitted to the NETMOD WG 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, 20 Nov 2013 16:03:49 -0000 Andy Bierman wrote: > On Wed, Nov 20, 2013 at 5:23 AM, Martin Bjorklund wrote: > > > Juergen Schoenwaelder wrote: > > > Hi, > > > > > > at the last WG meeting in Vancouver, we did run out of time to discuss > > > what to do with the various individual I-Ds that have been submitted > > > to the NETMOD WG. So I like to poll for opinions on the list in order > > > to get a feeling where we are. In particular, I like to poll for > > > opinions on whether the following I-Ds should be worked on in an IETF > > > working group and how you see the priorities. In particular, it would > > > be nice to know who is willing to actively review documents and also > > > who is planning to implement the technology proposed in the various > > > I-Ds. > > > > > > YANG Infrastructure: > > > > > > [1] > > http://tools.ietf.org/id/draft-bierman-netmod-yang-conformance-01.txt > > > > My problem with this document is that it identifies a couple of real > > issues, but the proposed solution doesn't address them. Specifically > > the problem w/ import-by revision (2.1.1) and the problem with > > supporting just an identity but not the data tree in a module (last > > sentence in 2.2). (In fact, I think the YANG specification needs to > > be updated to fix these issues). > > > > > > For import-by-revision, the min-version and max-version can be set the > same for every module used in the conformance profile. Why doesn't > this address the definition-drift problem that import-by-revision does > a horrible job attempting to solve? B/c if a module uses import-by-revision it doesn't work. Maybe the proper solution would be to remove import-by-revision. Then your solution would work for the conformance problem. > For importing only meta-data like identities, the module-conformance leaf > would be set to 'import'. Why doesn't this address the problem of the > confused client that does not know if this module is implemented of just > imported > for meta-data? B/c if a server advertises module foo, it means it implements everything in module foo (minus features). This is a YANG rule, and it cannot be changed by advertising additional capabilities (which the client may or may not understand). > IMO any solution that uses the YANG module for all conformance information > is going to be module-centric. In order to describe service-level > conformance, > multiple YANG modules and even NETCONF capabilities may be required. Agreed. /martin From andy@yumaworks.com Wed Nov 20 09:13:49 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8278A1AE4A8 for ; Wed, 20 Nov 2013 09:13:49 -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 y-mcxVGOQhFc for ; Wed, 20 Nov 2013 09:13:46 -0800 (PST) Received: from mail-qa0-f50.google.com (mail-qa0-f50.google.com [209.85.216.50]) by ietfa.amsl.com (Postfix) with ESMTP id C50001AE106 for ; Wed, 20 Nov 2013 09:13:45 -0800 (PST) Received: by mail-qa0-f50.google.com with SMTP id i13so2365357qae.9 for ; Wed, 20 Nov 2013 09:13: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:cc:content-type; bh=9NuWlvuhuHSdnK+MTfsX+XVmfrbzGIol2NM14C52yGU=; b=CrIHm7Xr9RvwZHvQvoOnVtXtKj4Qek5ns46lwzjBeiuP+QfVGOUAvsy6tRi8ujQr0s pe2HMtfQ9FVOsZH6QyKqQDnjp4wo9hiAU2qocykahlh5dHu0JcEcraJgYkATU5cn333A ZnaR5hYYVjfVODuTTrL8aUNrzQd2wNbP5jp1zQJ98E9fGknrQiiQLwC3cZRDtkVzPWQP nCrBY2vSZLLEjUN/IjOWT0fYpfaRf1mJtKqZTieF7ctgL02227mar4Uja2GJ+xj4za0F UI6vwiNfSBa8/cPOKUa+Uk48ne746gifsT1/YrVJjqIBuJD1VcKw20FMTfKrZhqzBPBp JSHg== X-Gm-Message-State: ALoCoQky5Er8E6cSdXfTjbUewvCLz0f6+rKuAMK5TjUV6FLYTtUD+kiA1tDINXXDqXKvgSG0v83b MIME-Version: 1.0 X-Received: by 10.224.69.132 with SMTP id z4mr3391780qai.78.1384967618353; Wed, 20 Nov 2013 09:13:38 -0800 (PST) Received: by 10.140.86.200 with HTTP; Wed, 20 Nov 2013 09:13:38 -0800 (PST) In-Reply-To: <20131120.170339.157290014569112009.mbj@tail-f.com> References: <20131120070012.GA44513@elstar.local> <20131120.142339.298369920756989697.mbj@tail-f.com> <20131120.170339.157290014569112009.mbj@tail-f.com> Date: Wed, 20 Nov 2013 09:13:38 -0800 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: multipart/alternative; boundary=001a11c2310eeb3b4e04eb9ee6c0 Cc: "netmod@ietf.org" Subject: Re: [netmod] poll of interest on I-Ds submitted to the NETMOD WG 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, 20 Nov 2013 17:13:49 -0000 --001a11c2310eeb3b4e04eb9ee6c0 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Nov 20, 2013 at 8:03 AM, Martin Bjorklund wrote: > Andy Bierman wrote: > > On Wed, Nov 20, 2013 at 5:23 AM, Martin Bjorklund > wrote: > > > > > Juergen Schoenwaelder wrote: > > > > Hi, > > > > > > > > at the last WG meeting in Vancouver, we did run out of time to > discuss > > > > what to do with the various individual I-Ds that have been submitted > > > > to the NETMOD WG. So I like to poll for opinions on the list in order > > > > to get a feeling where we are. In particular, I like to poll for > > > > opinions on whether the following I-Ds should be worked on in an IETF > > > > working group and how you see the priorities. In particular, it would > > > > be nice to know who is willing to actively review documents and also > > > > who is planning to implement the technology proposed in the various > > > > I-Ds. > > > > > > > > YANG Infrastructure: > > > > > > > > [1] > > > http://tools.ietf.org/id/draft-bierman-netmod-yang-conformance-01.txt > > > > > > My problem with this document is that it identifies a couple of real > > > issues, but the proposed solution doesn't address them. Specifically > > > the problem w/ import-by revision (2.1.1) and the problem with > > > supporting just an identity but not the data tree in a module (last > > > sentence in 2.2). (In fact, I think the YANG specification needs to > > > be updated to fix these issues). > > > > > > > > > > For import-by-revision, the min-version and max-version can be set the > > same for every module used in the conformance profile. Why doesn't > > this address the definition-drift problem that import-by-revision does > > a horrible job attempting to solve? > > B/c if a module uses import-by-revision it doesn't work. Maybe the > proper solution would be to remove import-by-revision. Then your > solution would work for the conformance problem. > > I am trying to avoid a new version of YANG. Of course import-by-revision is unusable but it isn't the only dead weight in the language. The usage model for min-version and max-version is not explained well in the draft, but the YANG conformance is supposed to be updated over time as reality dictates. Think of the "install_requires" in setup.py: install_requires=[ 'TurboGears >= 1.5.1', 'TurboKid', 'TGExpandingFormWidget', 'WebTest', 'SQLObject>=0.10.1', docutils >= 0.3, <=0.5 ], This actually provides more variants than 1 range, but the required usage depends on the actual conformance requirements. There are 2 main use -cases: * min-revision: the required functionality was added to the module in a specific release * max-revision: functionality in use was altered or broken in a specific release In a way, import-by-revision works in YANG Conformance. (e.g., Foo==1.5.1 in the example above), because it isn't an import-stmt at at all. It is a conformance-stmt. The only thing needed to freeze a snapshot for conformance purposes is the complete list of module/revision-dates used by the conformance profile. Each time module X is published, a new conformance-stmt update is needed, identifying the module/dates used at the time of publication. The min-revision/max-revision can be removed. However, import-by-revision is totally broken in YANG and should never be used. If module A uses module B/rev1 and module C uses module B/rev2 then the server is advertising 2 revisions of B. I prefer that only 1 revision of each module is loaded into the server. The language should be robust enough so the current version of each module can be loaded into a new server without breaking any old clients. The way to do that is to explicitly state the conformance in a way that does not change if the module is updated (like SMIv2 has had for about 20 years ;-) > For importing only meta-data like identities, the module-conformance leaf > > would be set to 'import'. Why doesn't this address the problem of the > > confused client that does not know if this module is implemented of just > > imported > > for meta-data? > > B/c if a server advertises module foo, it means it implements > everything in module foo (minus features). This is a YANG rule, and > it cannot be changed by advertising additional capabilities (which the > client may or may not understand). > IMO the additional YANG package info allows the server to sort out the list of capabilities. They are too course-grained. Current YANG is broken if the server MUST implement the entire base just to use a typedef out of a module. The complete list is needed by the client. The ability to grab the YANG modules from the server, and compile them on the fly to generate an exact view of the "server contract" is light years ahead of SNMP and CLI. (So the answer cannot be advertise an incomplete module set.) > > IMO any solution that uses the YANG module for all conformance > information > > is going to be module-centric. In order to describe service-level > > conformance, > > multiple YANG modules and even NETCONF capabilities may be required. > > Agreed. > > > > /martin > Andy --001a11c2310eeb3b4e04eb9ee6c0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Wed, Nov 20, 2013 at 8:03 AM, Martin Bjorklund <mbj@tail-f.com= > wrote:
Andy Bierman <and= y@yumaworks.com> wrote:
> On Wed, Nov 20, 2013 at 5:23 AM, Martin Bjorklund <mbj@tail-f.com> wrote:
>
> > Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
> > > Hi,
> > >
> > > at the last WG meeting in Vancouver, we did run out of time = to discuss
> > > what to do with the various individual I-Ds that have been s= ubmitted
> > > to the NETMOD WG. So I like to poll for opinions on the list= in order
> > > to get a feeling where we are. In particular, I like to poll= for
> > > opinions on whether the following I-Ds should be worked on i= n an IETF
> > > working group and how you see the priorities. In particular,= it would
> > > be nice to know who is willing to actively review documents = and also
> > > who is planning to implement the technology proposed in the = various
> > > I-Ds.
> > >
> > > YANG Infrastructure:
> > >
> > > [1]
> > http://tools.ietf.org/id/draft-bierman-n= etmod-yang-conformance-01.txt
> >
> > My problem with this document is that it identifies a couple of r= eal
> > issues, but the proposed solution doesn't address them. =A0Sp= ecifically
> > the problem w/ import-by revision (2.1.1) and the problem with > > supporting just an identity but not the data tree in a module (la= st
> > sentence in 2.2). =A0(In fact, I think the YANG specification nee= ds to
> > be updated to fix these issues).
> >
> >
>
> For import-by-revision, the min-version and max-version can be set the=
> same for every module used in the conformance profile. =A0Why doesn= 9;t
> this address the definition-drift problem that import-by-revision does=
> a horrible job attempting to solve?

B/c if a module uses import-by-revision it doesn't work. =A0Maybe the proper solution would be to remove import-by-revision. =A0Then your
solution would work for the conformance problem.



I am trying to avoid a = new version of YANG.
Of course import-by-revision is unusable but= it isn't the only dead weight
in the language. =A0

The usage model for min-version and max-version is not expla= ined well
in the draft, but the YANG conformance is supposed to b= e updated
over time as reality dictates.

Think of the "install_requires" in setup.py:

<= /div>=A0install_requires=3D[
=A0 =A0 =A0 =A0 'TurboGears >=3D 1.5= .1',
=A0 =A0 =A0 =A0 'TurboKid',
=A0 =A0 =A0 =A0 'TGE= xpandingFormWidget',
=A0 =A0 =A0 =A0 'WebTest',
=A0 =A0 =A0 =A0 'SQLObject>=3D= 0.10.1',
=A0 =A0 =A0 =A0 docutils >=3D 0.3, <=3D0.5
=A0 =A0= ],

Th= is actually provides more variants than 1 range, but the required usage
depends on the actual conformance requirements.<= /div>

There = are 2 main use -cases:

=A0 * min-revision: the required functionality was added to the module
=A0 =A0 in a specific release

=A0 * max-revision: f= unctionality in use was altered or broken in a specific release

In a way, i= mport-by-revision works in YANG Conformance. (e.g., Foo=3D=3D1.5.1
in the example above), because it isn't an impo= rt-stmt at at all. =A0It is
a conformance-stmt. The only thing needed to fre= eze a snapshot for
conformance purposes is = the complete list of module/revision-dates
= used by the conformance profile. =A0Each time module X is published,
a new conformance-stmt update is needed, identif= ying the module/dates
used at the time of p= ublication. The min-revision/max-revision can be removed.

However, import-by-revision is to= tally broken in YANG and should
never be used. =A0If module A use= s module B/rev1 and module C uses module B/rev2
then the server i= s advertising 2 revisions of B.

I prefer that only 1 revision of each module is loaded = into the server.
The language should be robust enough so the curr= ent version of each module
can be loaded into a new server withou= t breaking any old clients.
The way to do that is to explicitly state the conformance in a way tha= t
does not change if the module is updated (like SMIv2 has had fo= r about 20 years ;-)


> For importing only meta-data like identities, the module-conformance l= eaf
> would be set to 'import'. =A0Why doesn't this address the = problem of the
> confused client that does not know if this module is implemented of ju= st
> imported
> for meta-data?

B/c if a server advertises module foo, it means it implements
everything in module foo (minus features). =A0This is a YANG rule, and
it cannot be changed by advertising additional capabilities (which the
client may or may not understand).


=
IMO the additional YANG package info allows the server to sort o= ut
the list of capabilities. =A0They are too course-grained. =A0C= urrent YANG is broken
if the server MUST implement the entire base just to use a typedef out=
of a module. =A0The complete list is needed by the client. =A0Th= e ability to
grab the YANG modules from the server, and compile t= hem on the fly
to generate an exact view of the "server contract" is light = years ahead
of SNMP and CLI. (So the answer cannot be advertise a= n incomplete
module set.)



> IMO any solution that uses the YANG module for all conformance informa= tion
> is going to be module-centric. =A0In order to describe service-level > conformance,
> multiple YANG modules and even NETCONF capabilities may be required.
Agreed.



/martin

Andy<= /div>

--001a11c2310eeb3b4e04eb9ee6c0-- From rapenno@gmail.com Wed Nov 20 14:40:56 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A2361AE014 for ; Wed, 20 Nov 2013 14:40:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F8LeTCQAy6Vn for ; Wed, 20 Nov 2013 14:40:53 -0800 (PST) Received: from mail-lb0-x236.google.com (mail-lb0-x236.google.com [IPv6:2a00:1450:4010:c04::236]) by ietfa.amsl.com (Postfix) with ESMTP id 9597C1ADF98 for ; Wed, 20 Nov 2013 14:40:52 -0800 (PST) Received: by mail-lb0-f182.google.com with SMTP id u14so4358489lbd.41 for ; Wed, 20 Nov 2013 14:40:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=QKZ0K2K7E/w85ar7q37QiW3u8BqpE6NjJjKXp2SDrk0=; b=Tgqfdeyv+7OiZlmR48+J6PCLXS59sHwfrKCc98HckWoAd++PT5gCeOpuaKjLrvsnJd dfeV+IXZ8w+ZK0yuqMh9mNO6YqUSao3AnvncZEDYcHyaU+AF2N3QRTFlEeXRsDVYx8Gs 6MshTxbueyPl73b6X4o+KzpoPhlWlxcoL8SQ5+WUBbit0/jpBTe7GX3WftYLJ+lDCm6Q Do22NvSl7I1nWvjCRCAfdQ4eKwfdvHZep1RFuu+FoSTfAIg0ucoCS6QVRrfiQ9YXKPKE 8USEGQWCyOljXtBPjRhjtYaVfalh0FpiaaY962+Ib3FJQBUX6mQv7rof65GSUqjWiRzH n1uA== MIME-Version: 1.0 X-Received: by 10.112.136.163 with SMTP id qb3mr2040871lbb.14.1384987245206; Wed, 20 Nov 2013 14:40:45 -0800 (PST) Received: by 10.152.143.98 with HTTP; Wed, 20 Nov 2013 14:40:45 -0800 (PST) In-Reply-To: <20131120070012.GA44513@elstar.local> References: <20131120070012.GA44513@elstar.local> Date: Wed, 20 Nov 2013 14:40:45 -0800 Message-ID: From: Reinaldo Penno To: Juergen Schoenwaelder , netmod@ietf.org Content-Type: multipart/alternative; boundary=089e0112c73cc4e10304eba37899 Subject: Re: [netmod] poll of interest on I-Ds submitted to the NETMOD WG 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, 20 Nov 2013 22:40:56 -0000 --089e0112c73cc4e10304eba37899 Content-Type: text/plain; charset=ISO-8859-1 My feedback inline with [RP] On Tue, Nov 19, 2013 at 11:00 PM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > Hi, > > at the last WG meeting in Vancouver, we did run out of time to discuss > what to do with the various individual I-Ds that have been submitted > to the NETMOD WG. So I like to poll for opinions on the list in order > to get a feeling where we are. In particular, I like to poll for > opinions on whether the following I-Ds should be worked on in an IETF > working group and how you see the priorities. In particular, it would > be nice to know who is willing to actively review documents and also > who is planning to implement the technology proposed in the various > I-Ds. > > YANG Infrastructure: > > [1] http://tools.ietf.org/id/draft-bierman-netmod-yang-conformance-01.txt > [RP] Did not read it, can not comment > [2] > http://tools.ietf.org/id/draft-bjorklund-netmod-yang-xpath-extensions-00.txt > [RP] I support this work but with lower priority than the ones below. > [3] http://tools.ietf.org/id/draft-lhotka-netmod-yang-json-02.txt > [RP] I support adoption. I read this draft a couple of times and exchanged private emails with the author . This goes with the discussion on proposed Netconf extensions to support JSON as an option to XML. This is something we also touched upon in the presentation of Opendaylight "asks" for Netconf/Netmod WGs.. I can spend time to review the draft and help it further. > Data Models: > > [4] http://tools.ietf.org/id/draft-huang-netmod-acl-03.txt > [RP] I support adoption. I read this draft a couple of times as well and used it as a base for our work on Services Function Chaining models. I can spend time to review the draft and help it further. > [5] http://tools.ietf.org/id/draft-clemm-netmod-yang-network-topo-01.txt > [RP] Is there anybody working on a device model to complement this one? > > Other Stuff: > > [6] http://tools.ietf.org/id/draft-clemm-netmod-mount-01.txt > [RP] I read it and certainly support this work. I can spend time to review the draft and help it further. > If I am missing an I-D that is mature enough to be included in this > list, please let me know. > > /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 > --089e0112c73cc4e10304eba37899 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
My feedback inline with [R= P]


On Tue, Nov 19, 2013 at 11:0= 0 PM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-uni= versity.de> wrote:
Hi,

at the last WG meeting in Vancouver, we did run out of time to discuss
what to do with the various individual I-Ds that have been submitted
to the NETMOD WG. So I like to poll for opinions on the list in order
to get a feeling where we are. In particular, I like to poll for
opinions on whether the following I-Ds should be worked on in an IETF
working group and how you see the priorities. In particular, it would
be nice to know who is willing to actively review documents and also
who is planning to implement the technology proposed in the various
I-Ds.

YANG Infrastructure:

[1] http://tools.ietf.org/id/draft-bierman-netmod-= yang-conformance-01.txt

[RP] Did no= t read it, can not comment
=A0
[2] http://tools.ietf.org/id/draft-bjorklun= d-netmod-yang-xpath-extensions-00.txt


[RP] I support this work but with lower priority than the ones below.<= br>
=A0
[3] http://tools.ietf.org/id/draft-lhotka-netmod-yang-json= -02.txt

[RP] I support adoption. I = read this draft a couple of times and exchanged private emails with the aut= hor . This goes with the discussion on proposed Netconf extensions to suppo= rt JSON as an option to XML. This is something we also touched upon in the = presentation of Opendaylight "asks" for Netconf/Netmod WGs..

I can spend time to review the draft and help it further.


Data Models:

[4] http://tools.ietf.org/id/draft-huang-netmod-acl-03.txt

[RP] I support adoption. I read this draf= t a couple of times as well and used it as a base for our work on Services = Function Chaining models.

I can spend time to review the draft and help it further.

=A0
[5] http://tools.ietf.org/id/draft-clemm-netmod-yan= g-network-topo-01.txt


[RP] Is t= here anybody working on a device model to complement this one?
=A0

Other Stuff:

[6] http://tools.ietf.org/id/draft-clemm-netmod-mount-01.txt


--089e0112c73cc4e10304eba37899-- From andy@yumaworks.com Wed Nov 20 17:47:23 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5C341ADBCF for ; Wed, 20 Nov 2013 17:47:23 -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 nuuOTftK-fA1 for ; Wed, 20 Nov 2013 17:47:22 -0800 (PST) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0A2C71A802B for ; Wed, 20 Nov 2013 17:47:21 -0800 (PST) Received: by mail-qc0-f172.google.com with SMTP id l13so3234577qcy.3 for ; Wed, 20 Nov 2013 17:47: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:date:message-id:subject:from:to:cc :content-type; bh=gwjhZER7e1TngvFhu4Tm5egWk3QaBK9Ol6LZTRCUE3s=; b=JSUh1XE8yhHWsUpHFvszThuzKKrxTvScsgQLM5eq0iOhIksVraxpXw56kBnDL9r/ye x6MNWsOlkYV3r12JRFapk9V6DhvwhdPejMK7OBbMpd5mBJyAU9ijDC5QBwczcVbdUyXi KDBafCAKn7+wg3MHZxrWK2BiL7h9bFJhXhUKds/cofhXBByYASCiAAIMr5Xx09h+jVAq dnrtXeW5NmWpxvSf4wfwbPa8HcSG1C6zgPNqkjpdkhYbvhp0FEnT/0BZ/hoPAeAbHXae /vpMrosp+o9fKaNZhNxrm07zi7m2zmUAWqFiK3mZz0NN4K9x4hjbgYQVbdGsb5G+iWQa 7LKA== X-Gm-Message-State: ALoCoQnYrNF49Bah6CIsQU63mI8TO1uCc74SaBB0YciwYnBJukDD1uD3WfONhG7vx/mbgMAtV+4O MIME-Version: 1.0 X-Received: by 10.224.15.144 with SMTP id k16mr7061658qaa.16.1384998435162; Wed, 20 Nov 2013 17:47:15 -0800 (PST) Received: by 10.140.86.200 with HTTP; Wed, 20 Nov 2013 17:47:15 -0800 (PST) Date: Wed, 20 Nov 2013 17:47:15 -0800 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: multipart/alternative; boundary=047d7bdc9a86be3b8904eba6135f Cc: "netmod@ietf.org" Subject: [netmod] network-wide config (was Re: poll of interest on I-Ds submitted to the NETMOD WG) 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, 21 Nov 2013 01:47:24 -0000 --047d7bdc9a86be3b8904eba6135f Content-Type: text/plain; charset=ISO-8859-1 Hi, On Wed, Nov 20, 2013 at 5:23 AM, Martin Bjorklund wrote: > Juergen Schoenwaelder wrote: > > Hi, > >.... > > [6] http://tools.ietf.org/id/draft-clemm-netmod-mount-01.txt > > This document touches the important issue of how to model a > network-wide system, including the devices in the network. (We > actually discussed this issue in a bar bof in Maastricht). But I > think the solution described is too implementation-specific, and thus > limiting for other implementations. > > I ran that Bar BoF and it ended with action items that never got completed. I think we should get the architecture right before diving into complicated spot solutions. I2RS architecture has the concept of a broker (even if the NBI is not standardized right away). I think the correct architecture for NETCONF is to also have a broker. It should have a NETCONF or RESTCONF northbound interface and it would be a network-wide server that supported southbound NETCONF servers in network elements. YANG may need new features to describe special aspects of network-wide configuration data models. I don't think this draft addresses this sort of architecture. Network-wide data models are not the same as a network device data model that is a composite of multiple subtrees from various NE server configurations. > > /martin > Andy --047d7bdc9a86be3b8904eba6135f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,


On Wed, Nov 20, 2013 at 5:23 AM, Martin Bjorklund <mbj@tail-f.com<= /a>> wrote:
Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de<= /a>> wrote:
> Hi,
>....
> [6] http://tools.ietf.org/id/draft-clemm-netmod-mount-01.t= xt

This document touches the important issue of how to model a
network-wide system, including the devices in the network. =A0(We
actually discussed this issue in a bar bof in Maastricht). =A0But I
think the solution described is too implementation-specific, and thus
limiting for other implementations.


I ran that Bar BoF and it ended with a= ction items that never got completed.
I think we should get the a= rchitecture right before diving into
complicated spot solutions.<= /div>

I2RS architecture has the concept of a broker (even if = the NBI is
not standardized right away). =A0I think the correct a= rchitecture
for NETCONF is to also have a broker. =A0It should ha= ve a NETCONF
or RESTCONF northbound interface and it would be a network-wide
<= div>server that supported southbound NETCONF servers in network elements.
YANG may need new features to describe special aspects
of network-wide configuration data models.

I don&#= 39;t think this draft addresses this sort of architecture.
Networ= k-wide data models are not the same as a network device data model
that is a composite of multiple subtrees from various NE server config= urations.

=A0

/martin


Andy
= =A0
--047d7bdc9a86be3b8904eba6135f-- From lhotka@nic.cz Thu Nov 21 01:17:04 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CBCD1ACCE8 for ; Thu, 21 Nov 2013 01:17:04 -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 HHlRFks3ZPP2 for ; Thu, 21 Nov 2013 01:17:02 -0800 (PST) Received: from trail.lhotka.name (nat-5.bravonet.cz [77.48.224.5]) by ietfa.amsl.com (Postfix) with ESMTP id 99C6B1A1F1A for ; Thu, 21 Nov 2013 01:17:02 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id EE6C854039F for ; Thu, 21 Nov 2013 10:16:54 +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 QgIr1xPCRi+z for ; Thu, 21 Nov 2013 10:16:44 +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 DDF1854018C for ; Thu, 21 Nov 2013 10:16:39 +0100 (CET) From: Ladislav Lhotka To: netmod@ietf.org In-Reply-To: <20131120070012.GA44513@elstar.local> References: <20131120070012.GA44513@elstar.local> User-Agent: Notmuch/0.16+154~g96c0ce2 (http://notmuchmail.org) Emacs/23.4.1 (x86_64-apple-darwin12.3.0) Mail-Followup-To: netmod@ietf.org Date: Thu, 21 Nov 2013 10:16:39 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [netmod] poll of interest on I-Ds submitted to the NETMOD WG 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, 21 Nov 2013 09:17:04 -0000 Hi, I agree with Martin that a conservative update to YANG (let's call it 1.1) is needed. IMO, the alternative is a series of ugly hacks (extensions) implementing pretty much the same changes but pretending - for political or marketing reasons - it is still the good old YANG 1.0. I think this would actually undermine the standard. YANG 1.1 could include (parts of) [1], [2], or perhaps even [3] - having sections "JSON encoding" along with "XML encoding". Regarding new data models: The core modules were a necessary exercise for the NETCONF WG, and they helped a lot in shaping "best practice" approaches and revealing problems, such as the relationship between configuration and state data. However, I am not convinced that NETMOD WG is the right place for the development of a new set of domain-specific modules. One issue that we saw was that domain experts kept popping up randomly during the process with new comments and requests. So, while the result is hopefully good, it took way too much time. I think a more concentrated effort involving all domain experts at once is needed. Lada Juergen Schoenwaelder writes: > Hi, > > at the last WG meeting in Vancouver, we did run out of time to discuss > what to do with the various individual I-Ds that have been submitted > to the NETMOD WG. So I like to poll for opinions on the list in order > to get a feeling where we are. In particular, I like to poll for > opinions on whether the following I-Ds should be worked on in an IETF > working group and how you see the priorities. In particular, it would > be nice to know who is willing to actively review documents and also > who is planning to implement the technology proposed in the various > I-Ds. > > YANG Infrastructure: > > [1] http://tools.ietf.org/id/draft-bierman-netmod-yang-conformance-01.txt > [2] http://tools.ietf.org/id/draft-bjorklund-netmod-yang-xpath-extensions-00.txt > [3] http://tools.ietf.org/id/draft-lhotka-netmod-yang-json-02.txt > > Data Models: > > [4] http://tools.ietf.org/id/draft-huang-netmod-acl-03.txt > [5] http://tools.ietf.org/id/draft-clemm-netmod-yang-network-topo-01.txt > > Other Stuff: > > [6] http://tools.ietf.org/id/draft-clemm-netmod-mount-01.txt > > If I am missing an I-D that is mature enough to be included in this > list, please let me know. > > /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 XLiu@advaoptical.com Thu Nov 21 13:02:12 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC2861AE348 for ; Thu, 21 Nov 2013 13:02:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.425 X-Spam-Level: X-Spam-Status: No, score=-2.425 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.525] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v7uVXVxJHV72 for ; Thu, 21 Nov 2013 13:02:09 -0800 (PST) Received: from mail3.advaoptical.com (mail3.advaoptical.com [74.202.24.82]) by ietfa.amsl.com (Postfix) with ESMTP id A6CFE1AE330 for ; Thu, 21 Nov 2013 13:02:08 -0800 (PST) Received: from atl-srv-mail10.atl.advaoptical.com (atl-srv-mail10.atl.advaoptical.com [172.16.5.39]) by atl-vs-fsmail.advaoptical.com (8.14.5/8.14.5) with ESMTP id rALL20hi004377 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 21 Nov 2013 16:02:00 -0500 Received: from ATL-SRV-MAIL10.atl.advaoptical.com ([fe80::c4d6:b136:bc16:77ae]) by atl-srv-mail10.atl.advaoptical.com ([fe80::c4d6:b136:bc16:77ae%17]) with mapi id 14.03.0169.001; Thu, 21 Nov 2013 16:02:00 -0500 From: Xufeng Liu To: Juergen Schoenwaelder , "netmod@ietf.org" Thread-Topic: [netmod] poll of interest on I-Ds submitted to the NETMOD WG Thread-Index: AQHO5b4z5tAAQSwOHUixU7u2v/dJf5owHd/w Date: Thu, 21 Nov 2013 21:01:59 +0000 Message-ID: References: <20131120070012.GA44513@elstar.local> In-Reply-To: <20131120070012.GA44513@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.21.1.125] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.14, 0.0.0000 definitions=2013-11-21_06:2013-11-21,2013-11-21,1970-01-01 signatures=0 Subject: Re: [netmod] poll of interest on I-Ds submitted to the NETMOD WG 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, 21 Nov 2013 21:02:13 -0000 I'd like to express my opinion inline. Thanks, - Xufeng > -----Original Message----- > From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Juergen > Schoenwaelder > Sent: Wednesday, November 20, 2013 2:00 AM > To: netmod@ietf.org > Subject: [netmod] poll of interest on I-Ds submitted to the NETMOD WG >=20 > Hi, >=20 > at the last WG meeting in Vancouver, we did run out of time to discuss wh= at > to do with the various individual I-Ds that have been submitted to the > NETMOD WG. So I like to poll for opinions on the list in order to get a f= eeling > where we are. In particular, I like to poll for opinions on whether the > following I-Ds should be worked on in an IETF working group and how you > see the priorities. In particular, it would be nice to know who is willin= g to > actively review documents and also who is planning to implement the > technology proposed in the various I-Ds. >=20 > YANG Infrastructure: >=20 > [1] http://tools.ietf.org/id/draft-bierman-netmod-yang-conformance-01.txt > [2] http://tools.ietf.org/id/draft-bjorklund-netmod-yang-xpath-extensions= - > 00.txt [XL] I support the idea to update YANG to a new version. We'd also like to = have a solution soon, so if a new version of YANG takes too long to settle,= we'd like to have something in between. > [3] http://tools.ietf.org/id/draft-lhotka-netmod-yang-json-02.txt [XL] Support this, and we are implementing this way. >=20 > Data Models: >=20 > [4] http://tools.ietf.org/id/draft-huang-netmod-acl-03.txt > [5] http://tools.ietf.org/id/draft-clemm-netmod-yang-network-topo-01.txt [XL] I support this. Actually we are preparing a draft to augment the topol= ogy for transport network (this draft currently covers topologies for OSPF = and ISIS). We have started the implementation. >=20 > Other Stuff: >=20 > [6] http://tools.ietf.org/id/draft-clemm-netmod-mount-01.txt >=20 > If I am missing an I-D that is mature enough to be included in this list,= please > let me know. >=20 > /js >=20 > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From wdec.ietf@gmail.com Tue Nov 26 06:02:10 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 416C01AE20C for ; Tue, 26 Nov 2013 06:02:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v62KEVoIbTVQ for ; Tue, 26 Nov 2013 06:02:08 -0800 (PST) Received: from mail-pd0-x230.google.com (mail-pd0-x230.google.com [IPv6:2607:f8b0:400e:c02::230]) by ietfa.amsl.com (Postfix) with ESMTP id 4EFBB1AE206 for ; Tue, 26 Nov 2013 06:02:08 -0800 (PST) Received: by mail-pd0-f176.google.com with SMTP id w10so7718931pde.35 for ; Tue, 26 Nov 2013 06:02:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=5hmSi4wHnu/bY8eJBtl2QiWic4BStOtPc2d9qf/pkU4=; b=OlR/jFO1Ar7V9tPSw5SO12J0vEfXNCiY4e2yuSRCuGh3N7mAXRs7OSEft3ZGDWiBjK r0REwxvDdgULhfS+asIYSW3mGyxUAa/TIW9lCz/kJDHTN5oWr8HSVPwwiaxb51A5fbnm E4C7sby26qmHmSKI055PWoFJNhPggJZl7eildiMJFKVFSkzvQ4nwrG5yqgCLcNXYZ0Wp afpAJ4hnJqZ7wRgGfyspVvO8DEi4ypKIryYUfa71OZ5WYJu/ebXgZDO27z10HoW6gzUc tyeaTi9wDd450VqPw8ZDeNl+oDVvs239yKoyByvGcsjX4aDiAbVEdY7Mw2SC9G74wBjV PHaw== MIME-Version: 1.0 X-Received: by 10.66.145.40 with SMTP id sr8mr35713220pab.60.1385474527650; Tue, 26 Nov 2013 06:02:07 -0800 (PST) Received: by 10.70.57.163 with HTTP; Tue, 26 Nov 2013 06:02:07 -0800 (PST) Date: Tue, 26 Nov 2013 15:02:07 +0100 Message-ID: From: Wojciech Dec To: draft-bierman-netconf-restconf@tools.ietf.org Content-Type: multipart/alternative; boundary=047d7b6da6f210e9bc04ec14ed0c Cc: netmod@ietf.org Subject: [netmod] Restconf - config and operational data sets 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, 26 Nov 2013 14:02:10 -0000 --047d7b6da6f210e9bc04ec14ed0c Content-Type: text/plain; charset=ISO-8859-1 Hello Restconf authors, (retrying) got a question regarding your latest Restconf draft. This features the split between /config and /operational URIs . The text in section 5.1.1 and 5.1.2 indicates that the data in these URIs use data-stores that are effectively dis-joint sets, i.e. Rw data is in /config and ro data is in /operational. Is that the intent, correct interpretation? If so, then the following example also in the draft indicates something else: The jukebox data model is: | +--ro artist-count? uint32 | +--ro album-count? uint32 | +--rw song-count? uint32 (p102) While on p52 we see the following returned from the operational store: GET /restconf/operational/example-jukebox:jukebox/library HTTP/1.1 Host: example.com Accept: application/yang.data+json The server might respond: HTTP/1.1 200 OK Date: Mon, 23 Apr 2012 17:01:30 GMT Server: example-server Cache-Control: no-cache Pragma: no-cache Content-Type: application/yang.data+json { "example-jukebox:library" : { "artist-count" : 42, "album-count" : 59, "song-count" : 374 } } Which interpretation is correct? That said, personally I find this URI "fork" undesirable, and not something a Rest-like interface ought to provide. If anything, the example, even if it turns out to be due to a typo, offers a better alternative; ie have a resource that provides "all" info, config and operational, and another that delivers an oper or config only set. Some better even better options can also be thought of. Anyway, before going there, it would be great to understand whether my interpretation is correct. Regards, Wojciech. --047d7b6da6f210e9bc04ec14ed0c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello Restconf authors,

(retrying)

got a question regarding your latest Restconf draft. This features t= he split
between /config and /operational URIs .

The text in sect= ion 5.1.1 and 5.1.2 indicates that the data in these URIs use
data-stores that are effectively dis-joint sets, i.e. Rw data is in /config= and
ro data is in /operational.
Is that the intent, correct interpre= tation?

If so, then the following example also in the draft indicate= s something
else:

The jukebox data model is:

=A0=A0=A0=A0=A0=A0=A0=A0 |= =A0 +--ro artist-count?=A0=A0 uint32
=A0=A0=A0=A0=A0=A0=A0 |=A0 +--ro al= bum-count?=A0=A0=A0 uint32
=A0=A0=A0=A0=A0=A0=A0 |=A0 +--rw song-count?= =A0=A0=A0=A0 uint32


(p102)

While on p52 we see the follow= ing returned from the operational store:

GET /restconf/operational/example-jukebox:jukebox/library
=A0=A0=A0= =A0=A0=A0=A0 HTTP/1.1
=A0=A0=A0=A0 Host: = example.com <http://example.com/= >
=A0=A0=A0=A0 Accept: application/yang.data+json

=A0 The server might respond:

=A0=A0=A0=A0 HTTP/1.1 200 OK
= =A0=A0=A0=A0 Date: Mon, 23 Apr 2012 17:01:30 GMT
=A0=A0=A0=A0 Server: ex= ample-server
=A0=A0=A0=A0 Cache-Control: no-cache
=A0=A0=A0=A0 Pragma= : no-cache
=A0=A0=A0=A0 Content-Type: application/yang.data+json

=A0=A0=A0=A0 {
=A0=A0=A0=A0=A0=A0 "example-jukebox:library"= ; : {
=A0=A0=A0=A0=A0=A0=A0=A0=A0 "artist-count" : 42,
=A0= =A0=A0=A0=A0=A0=A0=A0=A0 "album-count" : 59,
=A0=A0=A0=A0=A0= =A0=A0=A0=A0 "song-count" : 374
=A0=A0=A0=A0=A0=A0 }
=A0=A0= =A0=A0 }

Which interpretation is correct?

That said, personally I find this URI "fork" undesirable, and= not
something a Rest-like interface ought to provide. If anything, the<= br>example, even if it turns out to be due to a typo, offers a better
alternative; ie have a resource that provides "all" info, config = and
operational, and another that delivers an oper or config only set. S= ome
better even better options can also be thought of. Anyway, before go= ing
there, it would be great to understand whether my interpretation is
corr= ect.

Regards,
Wojciech.

--047d7b6da6f210e9bc04ec14ed0c-- From j.schoenwaelder@jacobs-university.de Tue Nov 26 08:47:11 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 015521AD628 for ; Tue, 26 Nov 2013 08:47:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.251 X-Spam-Level: X-Spam-Status: No, score=-2.251 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.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 K3kOw5IOxX4E for ; Tue, 26 Nov 2013 08:47:09 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 582A01A1F55 for ; Tue, 26 Nov 2013 08:47:09 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 007BD2007D; Tue, 26 Nov 2013 17:47:09 +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 eUMYHx1dmyp5; Tue, 26 Nov 2013 17:47:08 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 90A682006E; Tue, 26 Nov 2013 17:47:08 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 3138A2986049; Tue, 26 Nov 2013 17:47:02 +0100 (CET) Date: Tue, 26 Nov 2013 17:47:02 +0100 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20131126164700.GC63813@elstar.local> Mail-Followup-To: netmod@ietf.org References: <20131120070012.GA44513@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20131120070012.GA44513@elstar.local> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [netmod] poll of interest on I-Ds submitted to the NETMOD WG 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, 26 Nov 2013 16:47:11 -0000 Hi, one week has passed and I have seen input from _five_ people. This is not a whole lot of people I think. If you have an interest in any of the proposed work, please speak up now. Likewise, if you have strong reasons why you think some work should not be done, please speak up as well. I plan to draw conclusions from this poll next week - so please send your comments until Dec. 1st. /js On Wed, Nov 20, 2013 at 08:00:12AM +0100, Juergen Schoenwaelder wrote: > Hi, > > at the last WG meeting in Vancouver, we did run out of time to discuss > what to do with the various individual I-Ds that have been submitted > to the NETMOD WG. So I like to poll for opinions on the list in order > to get a feeling where we are. In particular, I like to poll for > opinions on whether the following I-Ds should be worked on in an IETF > working group and how you see the priorities. In particular, it would > be nice to know who is willing to actively review documents and also > who is planning to implement the technology proposed in the various > I-Ds. > > YANG Infrastructure: > > [1] http://tools.ietf.org/id/draft-bierman-netmod-yang-conformance-01.txt > [2] http://tools.ietf.org/id/draft-bjorklund-netmod-yang-xpath-extensions-00.txt > [3] http://tools.ietf.org/id/draft-lhotka-netmod-yang-json-02.txt > > Data Models: > > [4] http://tools.ietf.org/id/draft-huang-netmod-acl-03.txt > [5] http://tools.ietf.org/id/draft-clemm-netmod-yang-network-topo-01.txt > > Other Stuff: > > [6] http://tools.ietf.org/id/draft-clemm-netmod-mount-01.txt > > If I am missing an I-D that is mature enough to be included in this > list, please let me know. -- 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 Nov 26 18:30:33 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BF441AE0DD for ; Tue, 26 Nov 2013 18:30:33 -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 w4HkpI27R7sz for ; Tue, 26 Nov 2013 18:30:30 -0800 (PST) Received: from mail-qa0-f49.google.com (mail-qa0-f49.google.com [209.85.216.49]) by ietfa.amsl.com (Postfix) with ESMTP id 2EE031AE0DC for ; Tue, 26 Nov 2013 18:30:30 -0800 (PST) Received: by mail-qa0-f49.google.com with SMTP id ii20so8492617qab.15 for ; Tue, 26 Nov 2013 18:30:29 -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=SnpZJg8WPQTFhIKW7f+efFlxGeX3bp9mWqyvnLpbvuE=; b=Azx44M8+THSWVkWC73DQYezpdgYPbJw8cUvJJksoP30HzBOXxz3pqOLppR4oCpErjE vIpjSIEM8mQ/XD6FJb5y6BL97PAjJq+l+hEBVQZWj98HkgKv2GLu3bWxWI19NRb4GiVe vhjG6PWtTQ0P/12VmFfACDZzEDIVpj2+xGnLi3hATrgvECSuaSYxtLEUycX6qWImDZa2 Uvv4mag6cnpNM8rMWkdXDEjDhOSDlAAo6M9IAWC4mMJmR7urMQEXh4X37bzkMc+lX63l 7ErVLQ8ekTjynWQA2HmDkNbxb1Qn+iY0W+7xrJcQDZybLtxMQflKYeZnuQoSv8Av+LZh OSeg== X-Gm-Message-State: ALoCoQlLCnAoIqegoNA9hZVQiuxM74D3ssMv9PH3o28QfYmhyQXZBje0jyAV4CRPKnfckjW+RYpp MIME-Version: 1.0 X-Received: by 10.49.35.15 with SMTP id d15mr63351203qej.16.1385519429564; Tue, 26 Nov 2013 18:30:29 -0800 (PST) Received: by 10.140.86.200 with HTTP; Tue, 26 Nov 2013 18:30:29 -0800 (PST) In-Reply-To: <20131126164700.GC63813@elstar.local> References: <20131120070012.GA44513@elstar.local> <20131126164700.GC63813@elstar.local> Date: Tue, 26 Nov 2013 18:30:29 -0800 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , "netmod@ietf.org" Content-Type: multipart/alternative; boundary=047d7b6dcbe06dcf9104ec1f614d Subject: Re: [netmod] poll of interest on I-Ds submitted to the NETMOD WG 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, 27 Nov 2013 02:30:33 -0000 --047d7b6dcbe06dcf9104ec1f614d Content-Type: text/plain; charset=ISO-8859-1 On Tue, Nov 26, 2013 at 8:47 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > Hi, > > one week has passed and I have seen input from _five_ people. This is > not a whole lot of people I think. If you have an interest in any of > the proposed work, please speak up now. Likewise, if you have strong > reasons why you think some work should not be done, please speak up as > well. I plan to draw conclusions from this poll next week - so please > send your comments until Dec. 1st. > > /js > > On Wed, Nov 20, 2013 at 08:00:12AM +0100, Juergen Schoenwaelder wrote: > > Hi, > > > > at the last WG meeting in Vancouver, we did run out of time to discuss > > what to do with the various individual I-Ds that have been submitted > > to the NETMOD WG. So I like to poll for opinions on the list in order > > to get a feeling where we are. In particular, I like to poll for > > opinions on whether the following I-Ds should be worked on in an IETF > > working group and how you see the priorities. In particular, it would > > be nice to know who is willing to actively review documents and also > > who is planning to implement the technology proposed in the various > > I-Ds. > > > > YANG Infrastructure: > > > > [1] > http://tools.ietf.org/id/draft-bierman-netmod-yang-conformance-01.txt Obviously support this work > > > [2] > http://tools.ietf.org/id/draft-bjorklund-netmod-yang-xpath-extensions-00.txt Support this work as YANG extensions, not as a new version of YANG. > > > [3] http://tools.ietf.org/id/draft-lhotka-netmod-yang-json-02.txt This work is coupled to RESTCONF so if that gets chartered then this work must be chartered as well. > > > > Data Models: > > > > [4] http://tools.ietf.org/id/draft-huang-netmod-acl-03.txt > > [5] http://tools.ietf.org/id/draft-clemm-netmod-yang-network-topo-01.txt > > > Support both drafts. Not clear to me that NETMOD WG is the correct WG to do domain-specific data models. The "MIB WG Model" (spin up a WG for just that module and close it when the module is done) had mixed success in the past. IMO the NETMOD WG should focus on the YANG language. > > Other Stuff: > > > > [6] http://tools.ietf.org/id/draft-clemm-netmod-mount-01.txt > > > Not sure if this is solving a real standards problem or just exposing some server implementation details, so I don't support this draft at this time. Andy --047d7b6dcbe06dcf9104ec1f614d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Tue, Nov 26, 2013 at 8:47 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
Hi,

one week has passed and I have seen input from _five_ people. This is
not a whole lot of people I think. If you have an interest in any of
the proposed work, please speak up now. Likewise, if you have strong
reasons why you think some work should not be done, please speak up as
well. I plan to draw conclusions from this poll next week - so please
send your comments until Dec. 1st.

/js

On Wed, Nov 20, 2013 at 08:00:12AM +0100, Juergen Schoenwaelder wrote:
> Hi,
>
> at the last WG meeting in Vancouver, we did run out of time to discuss=
> what to do with the various individual I-Ds that have been submitted > to the NETMOD WG. So I like to poll for opinions on the list in order<= br> > to get a feeling where we are. In particular, I like to poll for
> opinions on whether the following I-Ds should be worked on in an IETF<= br> > working group and how you see the priorities. In particular, it would<= br> > be nice to know who is willing to actively review documents and also > who is planning to implement the technology proposed in the various > I-Ds.
>
> YANG Infrastructure:
>
> [1] http://tools.ietf.org/id/draft-bierman-ne= tmod-yang-conformance-01.txt


Obviously support this work
=A0

> [2] http://tools.ietf.org/id/draft-bjo= rklund-netmod-yang-xpath-extensions-00.txt


Support this work as YANG extensions, not as a new vers= ion of YANG.

=A0

> [3] http://tools.ietf.org/id/draft-lhotka-netmod-yang= -json-02.txt


This work i= s coupled to RESTCONF so if that gets chartered then
this work must be chartered as well.


>
> Data Models:
>
> [4] http://tools.ietf.org/id/draft-huang-netmod-acl-03.txt
> [5] http://tools.ietf.org/id/draft-clemm-netmo= d-yang-network-topo-01.txt
>

Support both drafts. =A0Not clear = to me that NETMOD WG is
the correct WG to do domain-specific data= models. =A0The
"MIB WG Model" (spin up a WG for just t= hat module and close
it when the module is done) had mixed success in the past.
I= MO the NETMOD WG should focus on the YANG language.


=A0
> Other Stuff:
>
> [6] http://tools.ietf.org/id/draft-clemm-netmod-mount-01.t= xt
>


Not sure if this is= solving a real standards problem or
just exposing some server im= plementation details,
so I don't support this draft at this t= ime.



Andy

=
--047d7b6dcbe06dcf9104ec1f614d-- From lhotka@nic.cz Tue Nov 26 22:31:39 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB0A41AE10C for ; Tue, 26 Nov 2013 22:31:39 -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 VCUYty6WCC9W for ; Tue, 26 Nov 2013 22:31:38 -0800 (PST) Received: from trail.lhotka.name (nat-5.bravonet.cz [77.48.224.5]) by ietfa.amsl.com (Postfix) with ESMTP id 06F151AE08B for ; Tue, 26 Nov 2013 22:31:36 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 9029C540432 for ; Wed, 27 Nov 2013 07:31:35 +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 oQppLtZenhxF for ; Wed, 27 Nov 2013 07:31:31 +0100 (CET) Received: from localhost (unknown [172.29.2.202]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 46371540069 for ; Wed, 27 Nov 2013 07:31:27 +0100 (CET) From: Ladislav Lhotka To: netmod@ietf.org In-Reply-To: References: <20131120070012.GA44513@elstar.local> <20131126164700.GC63813@elstar.local> User-Agent: Notmuch/0.16+154~g96c0ce2 (http://notmuchmail.org) Emacs/23.4.1 (x86_64-apple-darwin12.3.0) Mail-Followup-To: netmod@ietf.org Date: Wed, 27 Nov 2013 07:31:26 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [netmod] poll of interest on I-Ds submitted to the NETMOD WG 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, 27 Nov 2013 06:31:40 -0000 Andy Bierman writes: ... >> >> > [2] >> http://tools.ietf.org/id/draft-bjorklund-netmod-yang-xpath-extensions-00.txt > > > > Support this work as YANG extensions, not as a new version of YANG. > I am strongly against any use of extensions that violates the rule stated in RFC6020, sec. 6.3.1, namely: If a YANG compiler does not support a particular extension, which appears in a YANG module as an unknown-statement (see Section 12), the entire unknown-statement MAY be ignored by the compiler. It is not the only use case for YANG to serve as guidelines for server implementors. For instance, I am now talking to guys that develop user interfaces from data models. For them, this extension would be a showstopper. Every vendor could (and would) define their own XPath functions, and then interoperability would be gone. ... >> > >> > Data Models: >> > >> > [4] http://tools.ietf.org/id/draft-huang-netmod-acl-03.txt >> > [5] http://tools.ietf.org/id/draft-clemm-netmod-yang-network-topo-01.txt >> > >> > > Support both drafts. Not clear to me that NETMOD WG is > the correct WG to do domain-specific data models. The > "MIB WG Model" (spin up a WG for just that module and close > it when the module is done) had mixed success in the past. > IMO the NETMOD WG should focus on the YANG language. I agree. The approach to domain-specific models might be something for the IESG to discuss and decide, based also on the past experience. Lada > > > > >> > Other Stuff: >> > >> > [6] http://tools.ietf.org/id/draft-clemm-netmod-mount-01.txt >> > >> > > > Not sure if this is solving a real standards problem or > just exposing some server implementation details, > so I don't support this draft at this time. > > > > Andy > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From andy@yumaworks.com Wed Nov 27 07:20:06 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DD8A1AC862 for ; Wed, 27 Nov 2013 07:20: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 v6Ix_Z7gEO_H for ; Wed, 27 Nov 2013 07:19:59 -0800 (PST) Received: from mail-qe0-f51.google.com (mail-qe0-f51.google.com [209.85.128.51]) by ietfa.amsl.com (Postfix) with ESMTP id B2B781A1F1A for ; Wed, 27 Nov 2013 07:19:59 -0800 (PST) Received: by mail-qe0-f51.google.com with SMTP id 1so5490136qee.10 for ; Wed, 27 Nov 2013 07:19: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:content-type; bh=xDY+1zN2qw/uE/vMHT2mvHmsRyowp3MBIdFJtcP5dgQ=; b=mODUwZMojWcmnpyeRi+Xw8Dv6GcXyFgKO4eGsdqai4R2TXGON6itOClUQnwabkaVTh 993TaC+KOIRrdLJg33xwkkV23A9eUHpjOwgKjjXsEVAulGsKQ0zGm3nAEaf15GEAxX4j QuaoxEbpgUx0MvPbcRRM0ZTqqh7MmhOueqod353oq43FmZsQLP/gRg4fxmnoI+TURQwi OLheuJZRFWD3w6mu4XWKOla00aVa5I2tkoJQ/iGJQOk+CKSX4ioJ9Zt1xBBEcZ2xxau1 8nIDn+dHliza8v4phha8adijqPDDML6bfcqlwL3HyAaWSP2r8FIkePPLGW8cKkkOnNjm Y78A== X-Gm-Message-State: ALoCoQm/YpXEq6CimWGgtf/rVmBb+ts2+1Y7rN4p3qxzisoYKDbecdD9DE8gyUvfmJWaopwgGTBE MIME-Version: 1.0 X-Received: by 10.224.60.193 with SMTP id q1mr24153111qah.99.1385565598609; Wed, 27 Nov 2013 07:19:58 -0800 (PST) Received: by 10.140.86.200 with HTTP; Wed, 27 Nov 2013 07:19:58 -0800 (PST) In-Reply-To: References: <20131120070012.GA44513@elstar.local> <20131126164700.GC63813@elstar.local> Date: Wed, 27 Nov 2013 07:19:58 -0800 Message-ID: From: Andy Bierman To: "netmod@ietf.org" Content-Type: multipart/alternative; boundary=001a1133dee65188ce04ec2a21fd Subject: Re: [netmod] poll of interest on I-Ds submitted to the NETMOD WG 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, 27 Nov 2013 15:20:06 -0000 --001a1133dee65188ce04ec2a21fd Content-Type: text/plain; charset=ISO-8859-1 On Tue, Nov 26, 2013 at 10:31 PM, Ladislav Lhotka wrote: > Andy Bierman writes: > > ... > > >> > >> > [2] > >> > http://tools.ietf.org/id/draft-bjorklund-netmod-yang-xpath-extensions-00.txt > > > > > > > > Support this work as YANG extensions, not as a new version of YANG. > > > > I am strongly against any use of extensions that violates the rule stated > in RFC6020, sec. 6.3.1, namely: > > If a YANG compiler does not support a particular extension, which > appears in a YANG module as an unknown-statement (see Section 12), > the entire unknown-statement MAY be ignored by the compiler. > > It is not the only use case for YANG to serve as guidelines for server > implementors. For instance, I am now talking to guys that develop user > interfaces from data models. For them, this extension would be a > showstopper. Every vendor could (and would) define their own XPath > functions, and then interoperability would be gone. > > OK -- I do not feel strongly that the XPath extensions should be added. I agree that RFC 6020 did not properly define how to add XPath functions to the server or how to deal with invalid function call exceptions. I think it forbids new functions instead. However I do not think a new YANG version is warranted at this time. The deployment costs for a new language version go much farther than the compiler writers. The YANG module readers, writers, and developers have to deal with 2 versions for several years. Breaking YANG 1.0 implementations is just as bad by RFC as it is by extension. (Ask the SMIng WG survivors how easy it is to make changes to a deployed modeling language ;-) ... > > >> > > >> > Data Models: > >> > > >> > [4] http://tools.ietf.org/id/draft-huang-netmod-acl-03.txt > >> > [5] > http://tools.ietf.org/id/draft-clemm-netmod-yang-network-topo-01.txt > >> > > >> > > > > Support both drafts. Not clear to me that NETMOD WG is > > the correct WG to do domain-specific data models. The > > "MIB WG Model" (spin up a WG for just that module and close > > it when the module is done) had mixed success in the past. > > IMO the NETMOD WG should focus on the YANG language. > > I agree. The approach to domain-specific models might be something for the > IESG to discuss and decide, based also on the past experience. > > Lada > > Andy --001a1133dee65188ce04ec2a21fd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Tue, Nov 26, 2013 at 10:31 PM, Ladislav Lhotka <lhotka@nic.cz&g= t; wrote:
Andy Bierman <andy@yumaworks.com> writes:

...

>>
>> > [2]
>> http://tools.ietf.org/id/draft-bjo= rklund-netmod-yang-xpath-extensions-00.txt
>
>
>
> Support this work as YANG extensions, not as a new version of YANG. >

I am strongly against any use of extensions that violates the rule stated i= n RFC6020, sec. 6.3.1, namely:

=A0 =A0If a YANG compiler does not support a particular extension, which =A0 =A0appears in a YANG module as an unknown-statement (see Section 12), =A0 =A0the entire unknown-statement MAY be ignored by the compiler.

It is not the only use case for YANG to serve as guidelines for server impl= ementors. For instance, I am now talking to guys that develop user interfac= es from data models. For them, this extension would be a showstopper. Every= vendor could (and would) define their own XPath functions, and then intero= perability would be gone.



OK -- I do not feel str= ongly that the XPath extensions should be added.
I agree that RFC= 6020 did not properly define how to add XPath functions
to the s= erver or how to deal with invalid function call exceptions.
I think it forbids new functions instead.

How= ever I do not think a new YANG version is warranted at this time. The deplo= yment
costs for a new language version go much farther than the c= ompiler writers.
The YANG module readers, writers, and developers have to deal with 2 v= ersions for
several years. =A0Breaking YANG 1.0 implementations i= s just as bad by RFC
as it is by extension. =A0(Ask the SMIng WG = survivors how easy it is to
make changes to a deployed modeling language ;-)

<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex"> ...

>> >
>> > Data Models:
>> >
>> > [4] http://tools.ietf.org/id/draft-huang-netmod-acl= -03.txt
>> > [5] http://tools.ietf.org/id/draft-cl= emm-netmod-yang-network-topo-01.txt
>> >
>>
>
> Support both drafts. =A0Not clear to me that NETMOD WG is
> the correct WG to do domain-specific data models. =A0The
> "MIB WG Model" (spin up a WG for just that module and close<= br> > it when the module is done) had mixed success in the past.
> IMO the NETMOD WG should focus on the YANG language.

I agree. The approach to domain-specific models might be something for the = IESG to discuss and decide, based also on the past experience.

Lada



Andy
=A0
--001a1133dee65188ce04ec2a21fd-- From lhotka@nic.cz Wed Nov 27 08:07:59 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6BA81AE088 for ; Wed, 27 Nov 2013 08:07:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.652 X-Spam-Level: X-Spam-Status: No, score=-0.652 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.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 oC11Wd-LN4oy for ; Wed, 27 Nov 2013 08:07:57 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 74B341AE01A for ; Wed, 27 Nov 2013 08:07:57 -0800 (PST) Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 6D5FB140143; Wed, 27 Nov 2013 17:07:55 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1385568475; bh=9bNyWVXY8Q0wb2CVpREUT9PvEF313SkkzvRegJ65MdQ=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=N0vr2cohyafaEQFJ087jXYD40U7U/DCu8FlxknsWpJrDDv4HX1yffBgPNwbmoEMNw 0PKJAdOwa0R2+EKwJpX9Oz63YnUqLF1iqXFPMtbPXXvIxGwvSWr4LQpILssGTjcjkg rHOqoH8daA1UtY11M150PLk2Z2nhOngUEMQk5ILA= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Ladislav Lhotka In-Reply-To: Date: Wed, 27 Nov 2013 17:07:50 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <3BE361F5-2B5A-4589-9FC6-145826FDE282@nic.cz> References: <20131120070012.GA44513@elstar.local> <20131126164700.GC63813@elstar.local> To: Andy Bierman X-Mailer: Apple Mail (2.1822) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Cc: "netmod@ietf.org" Subject: Re: [netmod] poll of interest on I-Ds submitted to the NETMOD WG 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, 27 Nov 2013 16:08:00 -0000 On 27 Nov 2013, at 16:19, Andy Bierman wrote: >=20 >=20 >=20 > On Tue, Nov 26, 2013 at 10:31 PM, Ladislav Lhotka = wrote: > Andy Bierman writes: >=20 > ... >=20 > >> > >> > [2] > >> = http://tools.ietf.org/id/draft-bjorklund-netmod-yang-xpath-extensions-00.t= xt > > > > > > > > Support this work as YANG extensions, not as a new version of YANG. > > >=20 > I am strongly against any use of extensions that violates the rule = stated in RFC6020, sec. 6.3.1, namely: >=20 > If a YANG compiler does not support a particular extension, which > appears in a YANG module as an unknown-statement (see Section 12), > the entire unknown-statement MAY be ignored by the compiler. >=20 > It is not the only use case for YANG to serve as guidelines for server = implementors. For instance, I am now talking to guys that develop user = interfaces from data models. For them, this extension would be a = showstopper. Every vendor could (and would) define their own XPath = functions, and then interoperability would be gone. >=20 >=20 >=20 > OK -- I do not feel strongly that the XPath extensions should be = added. > I agree that RFC 6020 did not properly define how to add XPath = functions > to the server or how to deal with invalid function call exceptions. > I think it forbids new functions instead. In my view, this is actually a feature. New XPath functions for use in = =93must=94 and =93when=94 should imply a new YANG version, as long as = their semantics cannot be formally specified. Perhaps it would be useful to distinguish XPath functions in NETCONF = filters from those that are used in =93must=94 and =93when=94. While the = former are essentially analogical to new RPCs, the latter affect the = meaning of a data model. A client that doesn=92t support an XPath = function simply won=92t use it in filters, but an unknown function in a = YANG module cannot be ignored. >=20 > However I do not think a new YANG version is warranted at this time. = The deployment > costs for a new language version go much farther than the compiler = writers. In this respect, how does the function-defining extension help in = comparison to a bumped YANG version? The difference seems mainly = psychological, actual software changes will be pretty much identical. > The YANG module readers, writers, and developers have to deal with 2 = versions for > several years. Breaking YANG 1.0 implementations is just as bad by = RFC > as it is by extension. (Ask the SMIng WG survivors how easy it is to > make changes to a deployed modeling language ;-) The basic assumption should be that YANG 1.1 won=92t break any existing = modules. Lada >=20 > ... >=20 > >> > > >> > Data Models: > >> > > >> > [4] http://tools.ietf.org/id/draft-huang-netmod-acl-03.txt > >> > [5] = http://tools.ietf.org/id/draft-clemm-netmod-yang-network-topo-01.txt > >> > > >> > > > > Support both drafts. Not clear to me that NETMOD WG is > > the correct WG to do domain-specific data models. The > > "MIB WG Model" (spin up a WG for just that module and close > > it when the module is done) had mixed success in the past. > > IMO the NETMOD WG should focus on the YANG language. >=20 > I agree. The approach to domain-specific models might be something for = the IESG to discuss and decide, based also on the past experience. >=20 > Lada >=20 >=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 Wed Nov 27 08:25:35 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 920871AD8F2 for ; Wed, 27 Nov 2013 08:25:35 -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 54WGeBXdZTce for ; Wed, 27 Nov 2013 08:25:34 -0800 (PST) Received: from mail-qe0-f42.google.com (mail-qe0-f42.google.com [209.85.128.42]) by ietfa.amsl.com (Postfix) with ESMTP id 0C0EE1ACCE7 for ; Wed, 27 Nov 2013 08:25:33 -0800 (PST) Received: by mail-qe0-f42.google.com with SMTP id b4so6795882qen.15 for ; Wed, 27 Nov 2013 08:25:33 -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=xTXQ+lV4H9EhPCA1fvPJalA6JphKgE4Srl2K4dt5PVU=; b=CYMT8uQdfXg4PMeAv57KTG2aM0x9+MfKzhFl/irIzQg7mRLlz2BGqarM0Tyle3wV7f J7+3MDsfUZHuf5/rNAvTbR3QQGaxFksIpb57GMAQOp+27o7xhQc/B2dINJKQs8feEsV+ hiojWgB1uaFfwqUQAWfs69H4rsSwQWnU8EcTwVrvYnt7cRQSluRPqujQunY6z+Axx1IA ELLIpkfqAJ0JnqAfTyVHfwxhsowy1X1oVaJHQVOoGpdd/honlKqBWdAGfXHwBG69SUWR R0vvbAxygwD0NgMlWWco6w9JtJkBFUtaNZSG0/8qxMRQC1LvStxciF26NeQrpqyri+Yc iJPw== X-Gm-Message-State: ALoCoQnzgDOJnldKat3D7UA4IRMH7SYcuo6o5QN8Q3rn7p4d915SSr0QAVP5IPed1RCQGbhWdRlY MIME-Version: 1.0 X-Received: by 10.224.11.68 with SMTP id s4mr68610014qas.88.1385569533114; Wed, 27 Nov 2013 08:25:33 -0800 (PST) Received: by 10.140.86.200 with HTTP; Wed, 27 Nov 2013 08:25:33 -0800 (PST) In-Reply-To: <3BE361F5-2B5A-4589-9FC6-145826FDE282@nic.cz> References: <20131120070012.GA44513@elstar.local> <20131126164700.GC63813@elstar.local> <3BE361F5-2B5A-4589-9FC6-145826FDE282@nic.cz> Date: Wed, 27 Nov 2013 08:25:33 -0800 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=001a11c2c370d5400a04ec2b0bb5 Cc: "netmod@ietf.org" Subject: Re: [netmod] poll of interest on I-Ds submitted to the NETMOD WG 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, 27 Nov 2013 16:25:35 -0000 --001a11c2c370d5400a04ec2b0bb5 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable .... > The basic assumption should be that YANG 1.1 won=92t break any existing > modules. > > That isn't the problem. New tools working with old modules is usually not a problem. Deploying new modules that break old tools is the problem. Lada > Andy --001a11c2c370d5400a04ec2b0bb5 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable



....
The basic assumption should be that YANG 1.1 won=92t break any existing mod= ules.


That isn't the problem. New tools = working with old modules
is usually not a problem. Deploying new = modules that break old
tools is the problem.

Lada

Andy

--001a11c2c370d5400a04ec2b0bb5-- From lhotka@nic.cz Wed Nov 27 08:44:30 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86AC91ADD9D for ; Wed, 27 Nov 2013 08:44:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.652 X-Spam-Level: X-Spam-Status: No, score=-0.652 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.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 5zSOoEsuta08 for ; Wed, 27 Nov 2013 08:44:29 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 2B03E1AD948 for ; Wed, 27 Nov 2013 08:44:29 -0800 (PST) Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id D6304140143; Wed, 27 Nov 2013 17:44:27 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1385570668; bh=K4ywKTul4WKY5TSNckY0IVzrGhHKRddnBvJt0KWqOjc=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=ij6bZvusakdq8pgbneZQOI1hXmhPRi2TaWBI1Vs5RYcozl+8BkbJ6PTzs0Jb9zJ9t DK4emIx7SD2hTrE340lY7CfUT/TdJRnUIstW/vs1oTv6dmmA/uNEgUvv6wnxvyGbFM BGyW5l8m63q/kKg63W2Cw6cFr0l9X/mo/f78w5Uc= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Ladislav Lhotka In-Reply-To: Date: Wed, 27 Nov 2013 17:44:25 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <5BD0C353-AB85-4EEC-9211-8E0E20A0B337@nic.cz> References: <20131120070012.GA44513@elstar.local> <20131126164700.GC63813@elstar.local> <3BE361F5-2B5A-4589-9FC6-145826FDE282@nic.cz> To: Andy Bierman X-Mailer: Apple Mail (2.1822) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Cc: "netmod@ietf.org" Subject: Re: [netmod] poll of interest on I-Ds submitted to the NETMOD WG 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, 27 Nov 2013 16:44:30 -0000 On 27 Nov 2013, at 17:25, Andy Bierman wrote: >=20 >=20 >=20 > .... > The basic assumption should be that YANG 1.1 won=92t break any = existing modules. >=20 >=20 > That isn't the problem. New tools working with old modules > is usually not a problem. Deploying new modules that break old > tools is the problem. But this will only get worse with new tools appearing (hopefully) in the = future. If there are things in YANG that need to be fixed, it should be = done as soon as possible. Lada =20 >=20 > Lada >=20 > Andy >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From alex@cisco.com Wed Nov 27 15:33:31 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCD801ADF63 for ; Wed, 27 Nov 2013 15:33:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.502 X-Spam-Level: X-Spam-Status: No, score=-9.502 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.001, 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 uDQrv4nGR9Up for ; Wed, 27 Nov 2013 15:33:29 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) by ietfa.amsl.com (Postfix) with ESMTP id 80CEA1ADE72 for ; Wed, 27 Nov 2013 15:33:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4845; q=dns/txt; s=iport; t=1385595209; x=1386804809; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=NPQ6Qhk75wXuyeYi6hvg9SR8I3/a4nXxOdA7eI56J8k=; b=LsdULsKwVm0OvCQN2Je73YfLAL0zQbumPUk8mqgrqwOun6LbZd7pjuSI Gu0IkF5uVsCl6/+6+NkS/LC9iLuuxM+Kj/vcEDqTuOGm2btALcjY33M4J 7C7tspTWIIGKB3NPV5FaF90z71INI9hUgTxWrOEoEh7Um1pU273GIjxQv 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgYFAC2AllKtJV2a/2dsb2JhbABWA4MHOFO3dU6BIRZ0giUBAQEDAQEBATcxAxAHAgICAQgOAgEEAQEBChQJBxsMCxQJCAIEARIIE4dgBg2/ZBcEjhsyBhsXAgQLgw+BEwOUMYUTkGODKYIq X-IronPort-AV: E=Sophos;i="4.93,785,1378857600"; d="scan'208";a="2802937" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-8.cisco.com with ESMTP; 27 Nov 2013 23:33:28 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id rARNXSkW015683 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 27 Nov 2013 23:33:28 GMT Received: from xmb-rcd-x05.cisco.com ([169.254.15.73]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0123.003; Wed, 27 Nov 2013 17:33:28 -0600 From: "Alexander Clemm (alex)" To: Juergen Schoenwaelder , "netmod@ietf.org" Thread-Topic: [netmod] poll of interest on I-Ds submitted to the NETMOD WG Thread-Index: AQHO5b4yVXxIylpIBEqhesKsFh0KWZo4J1sAgAGDGkA= Date: Wed, 27 Nov 2013 23:33:27 +0000 Message-ID: References: <20131120070012.GA44513@elstar.local> <20131126164700.GC63813@elstar.local> In-Reply-To: <20131126164700.GC63813@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.154.204.199] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [netmod] poll of interest on I-Ds submitted to the NETMOD WG 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, 27 Nov 2013 23:33:32 -0000 Hi Juergen, here is my input - inline Thanks --- Alex -----Original Message----- From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Juergen Schoenwa= elder Sent: Tuesday, November 26, 2013 8:47 AM To: netmod@ietf.org Subject: Re: [netmod] poll of interest on I-Ds submitted to the NETMOD WG Hi, one week has passed and I have seen input from _five_ people. This is not a= whole lot of people I think. If you have an interest in any of the propose= d work, please speak up now. Likewise, if you have strong reasons why you t= hink some work should not be done, please speak up as well. I plan to draw = conclusions from this poll next week - so please send your comments until D= ec. 1st. /js On Wed, Nov 20, 2013 at 08:00:12AM +0100, Juergen Schoenwaelder wrote: > Hi, >=20 > at the last WG meeting in Vancouver, we did run out of time to discuss=20 > what to do with the various individual I-Ds that have been submitted=20 > to the NETMOD WG. So I like to poll for opinions on the list in order=20 > to get a feeling where we are. In particular, I like to poll for=20 > opinions on whether the following I-Ds should be worked on in an IETF=20 > working group and how you see the priorities. In particular, it would=20 > be nice to know who is willing to actively review documents and also=20 > who is planning to implement the technology proposed in the various=20 > I-Ds. >=20 > YANG Infrastructure: >=20 > [1]=20 > http://tools.ietf.org/id/draft-bierman-netmod-yang-conformance-01.txt =20 Conformance is an important aspect. The issues pointed out are the right o= nes. The solution needs more work, but I think this is a good working grou= p item. =20 > [2]=20 > http://tools.ietf.org/id/draft-bjorklund-netmod-yang-xpath-extensions- > 00.txt Support [3]=20 > http://tools.ietf.org/id/draft-lhotka-netmod-yang-json-02.txt I think this is important and needs to be worked on. Part of the re= stconf, which is important as well, having a JSON alternative to XML to enc= ode information makes a lot of sense >=20 > Data Models: General comment: I think data models are an important enabler for a= pplications; data models for common items should be taken up for standardiz= ation by IETF and netmod makes for a natural home for these. So, I am stro= ngly supporting these. =20 Of course, it is a possible that some of the data models will be developed = in other working groups with expertise for the particular subject matter. = However, I don't think that YANG is mainstream enough yet where this will j= ust happen by itself in other working groups. =20 >=20 > [4] http://tools.ietf.org/id/draft-huang-netmod-acl-03.txt =20 Obviously, I am biased here - I strongly support this. ACLs and SPFs are a= mong the most important items to configure today; no configuration solution= is complete unless it addresses these. There are many applications, also = in the SDN space, which involve configuring stateless packet filters and ac= cess control rules and which will benefit from standardization. =20 > [5]=20 > http://tools.ietf.org/id/draft-clemm-netmod-yang-network-topo-01.txt Same here. I am biased here and I strongly support this. Network topology= is also needed by I2RS and can be considered a foundational data model. I= t adds the aspect of data models that capture a network-level abstraction, = not just a device-level abstraction. Also, Open Daylight is already implem= enting to this. =20 >=20 > Other Stuff: >=20 > [6] http://tools.ietf.org/id/draft-clemm-netmod-mount-01.txt >=20 Again, I am biased. I strongly support this. The reason why this is impor= tant is that this enables federated data stores which can incorporate infor= mation/data from other systems without duplicating model development effort= s. It facilitates the development e.g. of northbound SDN controller interf= aces and offers an alternative to the conventional information and mediatio= n layers which make e.g. EMSs and NMSs hard to maintain (since everything n= eeds to be mediated and supported). It is possible to constrain the scope = of this draft to specific use cases and scenarios as needed. =20 > If I am missing an I-D that is mature enough to be included in this=20 > list, please let me know. --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From andy@yumaworks.com Wed Nov 27 15:58:06 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4DF21ADF7C for ; Wed, 27 Nov 2013 15:58: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 cGZ4bmLxCJMl for ; Wed, 27 Nov 2013 15:58:05 -0800 (PST) Received: from mail-qe0-f43.google.com (mail-qe0-f43.google.com [209.85.128.43]) by ietfa.amsl.com (Postfix) with ESMTP id E60E51A1EF9 for ; Wed, 27 Nov 2013 15:58:04 -0800 (PST) Received: by mail-qe0-f43.google.com with SMTP id 2so8224239qeb.2 for ; Wed, 27 Nov 2013 15:58: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:cc:content-type; bh=lyO6gvUAwNCVevWPzGoRb9xgyD3R2jvRN/3/MzEcbSk=; b=KkXW/QrCKVLp3Aa3ARXf0qeRokjxDb512Sou5fSr0ZmdlLt/uGaf4Y23R2zdQ5Fe7V 15cWa2/ELqCh3b93+rvorDnViyBZFx6BwiDetCUqPYYn8ZZMO0ZWcvVLOx7ssPI+Birp qrDWKTt62rLiUf/r83wou2bJ8ErN0q/xeWX1vGnsLPQ+YJ+SRBQLZCtxLWv+pfWELmYL ka7SXWO9Q1hig1edw6SH/q+xBzXUDWaH1sVytJwqDqLrM2Rqx76WiIifdRv1cIFG+75K a/9AMoLm8BJUsLRKMvJLsbuTZOpaNi/wdqEwwkd8Fz04VLiHZjBMoJ7ml7dok6lsgXv9 zJVA== X-Gm-Message-State: ALoCoQnigJ19DWWRevzs/ly9CFzXy4zG2QQpqSamY9UKO+Ehh/oE1t1CGFdbjqIVAP17u5k/Rd7s MIME-Version: 1.0 X-Received: by 10.224.69.132 with SMTP id z4mr70670657qai.78.1385596684156; Wed, 27 Nov 2013 15:58:04 -0800 (PST) Received: by 10.140.86.200 with HTTP; Wed, 27 Nov 2013 15:58:04 -0800 (PST) In-Reply-To: References: <20131120070012.GA44513@elstar.local> <20131126164700.GC63813@elstar.local> Date: Wed, 27 Nov 2013 15:58:04 -0800 Message-ID: From: Andy Bierman To: "Alexander Clemm (alex)" Content-Type: multipart/alternative; boundary=001a11c2310e2953e904ec315e96 Cc: "netmod@ietf.org" Subject: Re: [netmod] poll of interest on I-Ds submitted to the NETMOD WG 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, 27 Nov 2013 23:58:06 -0000 --001a11c2310e2953e904ec315e96 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Nov 27, 2013 at 3:33 PM, Alexander Clemm (alex) wrote: > Hi Juergen, > here is my input - inline > Thanks > --- Alex > .... > > > > Data Models: > > > > General comment: I think data models are an important enabler for > applications; data models for common items should be taken up for > standardization by IETF and netmod makes for a natural home for these. So, > I am strongly supporting these. > > Of course, it is a possible that some of the data models will be developed > in other working groups with expertise for the particular subject matter. > However, I don't think that YANG is mainstream enough yet where this will > just happen by itself in other working groups. > > > > The plan was discussed 2 IETFs ago -- pretty much the same thing we did with MIB modules for 20 years -- at least 1 YANG doctor will be following every WG effort to create a YANG module. The domain experts figure out the info model and the YANG expert(s) help translate their ideas to NETCONF/YANG (or RESTCONF/YANG ;-) It's better than just early review, because the help is throughout the process. IMO the domain-specific data models being done now in NETMOD are taking a long time because domain experts are being brought into the process fairly late, and perhaps that is because it is done in NETMOD WG instead of the INT or RTG area. Andy --001a11c2310e2953e904ec315e96 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Wed, Nov 27, 2013 at 3:33 PM, Alexander Clemm (alex) <alex@cisco= .com> wrote:
Hi Juergen,
here is my input - inline <ALEX>
Thanks
--- Alex
....
>
> Data Models:



<ALEX> General comment: =A0I think data models are an important enabl= er for applications; data models for common items should be taken up for st= andardization by IETF and netmod makes for a natural home for these. =A0So,= I am strongly supporting these.

Of course, it is a possible that some of the data models will be developed = in other working groups with expertise for the particular subject matter. = =A0However, I don't think that YANG is mainstream enough yet where this= will just happen by itself in other working groups.
<ALEX>




The plan was discus= sed 2 IETFs ago -- pretty much the same thing we did with
MIB mod= ules for 20 years -- at least 1 YANG doctor will be following every
WG effort to create a YANG module. The domain experts figure out= the info model
and the YANG expert(s) help translate their ideas= to NETCONF/YANG (or RESTCONF/YANG ;-)
It's better than just = early review, because the help is throughout the process.

IMO the domain-specific data models being done now in N= ETMOD are taking a long
time because domain experts are being bro= ught into the process fairly late, and perhaps
that is because it= is done in NETMOD WG instead of the INT or RTG area.


Andy

--001a11c2310e2953e904ec315e96--