Re: [netmod] [OPS-AREA] configuration: writable MIB modules versus NETCONF/YANG modules
Giles Heron <giles.heron@gmail.com> Fri, 14 February 2014 15:48 UTC
Return-Path: <giles.heron@gmail.com>
X-Original-To: l2vpn@ietfa.amsl.com
Delivered-To: l2vpn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com
(Postfix) with ESMTP id 045A21A02D6 for <l2vpn@ietfa.amsl.com>;
Fri, 14 Feb 2014 07:48:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,
DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 gOaU19JEhr2k for
<l2vpn@ietfa.amsl.com>; Fri, 14 Feb 2014 07:48:22 -0800 (PST)
Received: from mail-ee0-x22a.google.com (mail-ee0-x22a.google.com
[IPv6:2a00:1450:4013:c00::22a]) by ietfa.amsl.com (Postfix) with ESMTP id
5C9EA1A02D9 for <l2vpn@ietf.org>; Fri, 14 Feb 2014 07:48:17 -0800 (PST)
Received: by mail-ee0-f42.google.com with SMTP id b15so5778623eek.1 for
<l2vpn@ietf.org>; Fri, 14 Feb 2014 07:48:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=content-type:mime-version:subject:from:in-reply-to:date:cc
:content-transfer-encoding:message-id:references:to;
bh=URCADZYp0AB7gQFUZAYeyAlkh9tqilgpLUI0VWIr+S0=;
b=mWZ+Ks5ZVK3v4ZKKGcj9J1bUD53dC5Y+cg+NyDuuD2PyQy5f9VPvTadZ0H4wqZ0E9V
XwZSSiF2mZLyo6qG5gih5Enm6oFAHN3z6XN40foRrQWGHAyvGsg3CJNBCYPZsbdL7tbJ
uMNP9i4P36kkYsz2vJ9mXhlJ30bYPMazZr1GVuNtz1Lq+Yh1PxokDivq9hT07JppsdJA
e0VtyVtlvq2hmOXMpvpTvbjbLhNrYsVV+X1QUQkmL0nMA+99o+UU3jfLJlyr8msocFmM
m+YW8XYMi438r8Kx4djisMS8kcBojvxvb1YX4AFjRMvEpElutlVyxm3zTXyYD9ZCVp8d NvfQ==
X-Received: by 10.14.216.3 with SMTP id f3mr3423683eep.66.1392392895419;
Fri, 14 Feb 2014 07:48:15 -0800 (PST)
Received: from ams3-vpn-dhcp7025.cisco.com (173-38-208-169.cisco.com.
[173.38.208.169]) by mx.google.com with ESMTPSA id
f45sm21121643eeg.5.2014.02.14.07.48.14 for <multiple recipients>
(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
Fri, 14 Feb 2014 07:48:15 -0800 (PST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
Subject: Re: [netmod] [OPS-AREA] configuration: writable MIB modules versus
NETCONF/YANG modules
From: Giles Heron <giles.heron@gmail.com>
In-Reply-To: <CF2389E4.5B811%josh.rogers@twcable.com>
Date: Fri, 14 Feb 2014 15:48:12 +0000
Content-Transfer-Encoding: quoted-printable
Message-Id: <DB9DD43A-C3E4-4270-8241-2EE54A841D5D@gmail.com>
References: <876DDDF4-C991-4C03-81C3-81417F48FE0A@lucidvision.com>
<D985BE1A-830D-4007-8069-CB9E120B9CF5@gmail.com>
<CF2389E4.5B811%josh.rogers@twcable.com>
To: "Rogers, Josh" <josh.rogers@twcable.com>
X-Mailer: Apple Mail (2.1510)
Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/X-1qy9U-_iLDXFddgkwsJj_HvJ4
Cc: "l2vpn@ietf.org" <l2vpn@ietf.org>
X-BeenThere: l2vpn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Layer 2 Virtual Private Networks <l2vpn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/l2vpn>,
<mailto:l2vpn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/l2vpn/>
List-Post: <mailto:l2vpn@ietf.org>
List-Help: <mailto:l2vpn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/l2vpn>,
<mailto:l2vpn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 14 Feb 2014 15:48:29 -0000
Hi Josh, Fair comment. I have to say though that the vast majority of the pain in shepherding the VPLS MIB has been in read-write. IIRC the main issue was around references from one table to another where there's an implied order of creation (so if X points to Y you have to either create Y before X, or allow a "dangling reference"). NETCONF resolves a lot of that by wrapping changes into a single edit-config operation which either succeeds or fails. Giles On 14 Feb 2014, at 14:58, "Rogers, Josh" <josh.rogers@twcable.com> wrote: > It is unfortunate to see RW abandoned. I believe that SNMP R/W is not adopted more because of poor documentation, than because SNMP is not a good configuration vehicle. I know of one vendor that provides a "CLI to SNMP" dictionary that provides OID's for every CLI command in their cli guide. I think if everyone did something similar, tools that leverage SNMP R/W would be more prolific. > > Honestly, I don't see netconf adopted much better (although I wish it was, its an excellent configuration vehicle). > > -Josh > > From: Giles Heron <giles.heron@gmail.com> > Date: Friday, February 14, 2014 8:49 AM > To: "l2vpn@ietf.org" <l2vpn@ietf.org> > Subject: Fwd: [netmod] [OPS-AREA] configuration: writable MIB modules versus NETCONF/YANG modules > > Worth noting. > > Giles > > Begin forwarded message: > >> From: Thomas Nadeau <tnadeau@lucidvision.com> >> Subject: [netmod] Fwd: [OPS-AREA] configuration: writable MIB modules versus NETCONF/YANG modules >> Date: 14 February 2014 01:41:34 GMT >> To: netmod@ietf.org >> >> >> FYI in case you are not on the ops dir list... >> >> --Tom >> >> >> Begin forwarded message: >> >>> From: Benoit Claise <bclaise@cisco.com> >>> Subject: [OPS-AREA] configuration: writable MIB modules versus NETCONF/YANG modules >>> Date: February 13, 2014 at 7:39:57 PM EST >>> To: "ops-area@ietf.org" <ops-area@ietf.org> >>> >>> Dear all, >>> >>> We occasionally see read-write MIB module proposals within the IETF. >>> However, the write capabilities of those MIB modules are rarely implemented. >>> >>> While discussing this issue with the MIB doctors, we arrive to the conclusion that it's now time to set the direction for future MIB developments within the IETF. Basically, let's not specify read-write MIB modules unless we have a good reason. Read-only MIB modules are still fine though, as SNMP is clearly used for monitoring purposes. >>> >>> Here is the statement we came up with: >>>> The OPS area recommends the use of NETCONF/YANG standards for configuration. IETF working groups are therefore encouraged to use the NETCONF/YANG standards for configuration, specifically in new charters. SNMP MIB modules modifying persistent configuration state should only be produced by working groups in cases of clear utility >>>> and consensus to use SNMP write operations for configuration. >>> Ideally, this should become an IESG statement. >>> Your feedback is most welcome. >>> >>> Regards, the MIB doctors & Benoit >>> >>> _______________________________________________ >>> OPS-AREA mailing list >>> OPS-AREA@ietf.org >>> https://www.ietf.org/mailman/listinfo/ops-area >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod > > > This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.
- Fwd: [netmod] [OPS-AREA] configuration: writable … Giles Heron
- Re: [netmod] [OPS-AREA] configuration: writable M… Rogers, Josh
- Re: [netmod] [OPS-AREA] configuration: writable M… Giles Heron