From nobody Sat Mar 1 05:08:14 2014 Return-Path: X-Original-To: ops-area@ietfa.amsl.com Delivered-To: ops-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F24AB1A07E9 for ; Sat, 1 Mar 2014 05:08:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.048 X-Spam-Level: X-Spam-Status: No, score=-10.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i7Nq1l4BElHy for ; Sat, 1 Mar 2014 05:08:09 -0800 (PST) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) by ietfa.amsl.com (Postfix) with ESMTP id 37EE71A07FA for ; Sat, 1 Mar 2014 05:08:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=779; q=dns/txt; s=iport; t=1393679287; x=1394888887; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=pFv3eyizlZS11CVfbTfs0zID2BD/K1Ouk90oTc2YWDg=; b=Y9C/mAiIcUwispHDzwAw25+SCt0r2VI6xh9EoGy0ra6Em6xQ4ifWZv1M zbUGBXK9Odneq0ci25H7VABcG+tOCf2ObSdZ/EMW2HEyElGSvBJSZH20i vZVhO6BshFBkiS1rT3WI30Df1epjtvL7YmHkP4r6fp7JT4LzmWveclZHq Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0FAPHaEVOQ/khM/2dsb2JhbABYgwbCL4ETFnSCJQEBAQMBOEABBQsLIRYPCQMCAQIBRRMBBwEBh20Iy2cXjXMRAVAHFoQiAQOYPIZKi2GBb4E+PIE1 X-IronPort-AV: E=Sophos;i="4.97,568,1389744000"; d="scan'208";a="1863385" Received: from ams-core-3.cisco.com ([144.254.72.76]) by aer-iport-3.cisco.com with ESMTP; 01 Mar 2014 13:08:06 +0000 Received: from [10.61.207.3] ([10.61.207.3]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s21D85wJ008568; Sat, 1 Mar 2014 13:08:05 GMT Message-ID: <5311DBB5.9050507@cisco.com> Date: Sat, 01 Mar 2014 13:08:05 +0000 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: adrian@olddog.co.uk References: <53107BAF.2050808@cisco.com> <15dc01cf34af$961c6c40$c25544c0$@olddog.co.uk> In-Reply-To: <15dc01cf34af$961c6c40$c25544c0$@olddog.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/ops-area/uNnsH_eTkIEAJXFxGqr-gSSobLE Cc: 'ops-area' Subject: Re: [OPS-AREA] configuration: writable MIB modules versus NETCONF/YANG modules - part 2 X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Mar 2014 13:08:11 -0000 > Curiously, the definitions here seem to be different from those that I just read > on a back-channel discussion with Benoit and others where we had: Come on Adrian, cutting and pasting some text from an different email thread between 3 persons, out of context, here, doesn't help anything. I specifically took care of mentioning in THIS email thread " First let me make sure that we agree on one terminology. The NETCONF/YANG terminology is in RFC 6244:" > > "operational data" includes both state learned from the network and the > administrative state pushed to the various routing and such processes. > > "configuration data" can be persistent or ephemeral - but it's all held by the > management side, whether that is CLI or NetConf. > Regards, Benoit From nobody Sat Mar 1 06:08:22 2014 Return-Path: X-Original-To: ops-area@ietfa.amsl.com Delivered-To: ops-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4E3A1A0C55 for ; Sat, 1 Mar 2014 06:08:17 -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 9KvaLwhqv9iQ for ; Sat, 1 Mar 2014 06:08:10 -0800 (PST) Received: from mail-qa0-f54.google.com (mail-qa0-f54.google.com [209.85.216.54]) by ietfa.amsl.com (Postfix) with ESMTP id E5A1C1A0C7B for ; Sat, 1 Mar 2014 06:06:38 -0800 (PST) Received: by mail-qa0-f54.google.com with SMTP id w8so1797167qac.41 for ; Sat, 01 Mar 2014 06:06:36 -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=8vIe6PTNpBIBkQDYbbUtg3ho+5YggUqMY87RI+G75/I=; b=A6WrDbdPcbi3qaN9sUuPa6oWPU0u++fe3IgjJy2sRKMxQKFexrlJWVIX6C5iUfBiuy zs5wCW0fRzPYZkL8OWQ44SBmutsRCWR23VboTC6+q/BypNDnakpC8cMmQ/39EYlJjVgA +k1xh7qIkZLAYUT8CPvkbU9cUOdH6uRkWVzsG8Rv6O0GnQqn/0dHe2UFPCa8eLKJXxvI gYotdcZObvCe/mOV/3C1bat710jSS4C2Q0Ksgdnuy8Yf2hpAQc9rEEiZGOggfzDVX1CS FJu2ShpfYEKCyIvbos/zeN2XcaaHUWREQ7pOWYSDf4i7IVMcK6O+YxUS2LUmGCuF+siJ uUHA== X-Gm-Message-State: ALoCoQnxm9C5Gx1zXrCHPUnDnYUsKgPI3FNS7D+k6xaO66psFrIyyqRxVlKccMAdpLv9dTVQMFIV MIME-Version: 1.0 X-Received: by 10.140.87.9 with SMTP id q9mr10620319qgd.94.1393682796383; Sat, 01 Mar 2014 06:06:36 -0800 (PST) Received: by 10.140.104.194 with HTTP; Sat, 1 Mar 2014 06:06:36 -0800 (PST) In-Reply-To: <00ff01cf34d4$cdcb5640$696202c0$@comcast.net> References: <53107BAF.2050808@cisco.com> <15dc01cf34af$961c6c40$c25544c0$@olddog.co.uk> <20140228185713.GA15098@elstar.local> <163801cf34c1$f2a6e4b0$d7f4ae10$@olddog.co.uk> <20140228204251.GA15464@elstar.local> <00ff01cf34d4$cdcb5640$696202c0$@comcast.net> Date: Sat, 1 Mar 2014 06:06:36 -0800 Message-ID: From: Andy Bierman To: ietfdbh Content-Type: multipart/alternative; boundary=001a113a359c027da604f38c104d Archived-At: http://mailarchive.ietf.org/arch/msg/ops-area/3uRqYxIyKpm-6v5O2F0rrlb9vmQ Cc: ops-area Subject: Re: [OPS-AREA] configuration: writable MIB modules versus NETCONF/YANG modules - part 2 X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Mar 2014 14:08:18 -0000 --001a113a359c027da604f38c104d Content-Type: text/plain; charset=ISO-8859-1 On Friday, February 28, 2014, ietfdbh wrote: > Hi, > > Comments inline. > > David Harrington > ietfdbh@comcast.net > +1-603-828-1401 > > -----Original Message----- > > From: OPS-AREA [mailto:ops-area-bounces@ietf.org ] On > Behalf Of Juergen > > Schoenwaelder > > Sent: Friday, February 28, 2014 3:43 PM > > To: Adrian Farrel > > Cc: 'ops-area' > > Subject: Re: [OPS-AREA] configuration: writable MIB modules versus > > NETCONF/YANG modules - part 2 > > > > On Fri, Feb 28, 2014 at 08:16:19PM +0000, Adrian Farrel wrote: > > > Hi Juergen, > > > > > > Thanks for the explanation of the difference between "configuration > data" > > and > > > "persistent configuration data". > > > > > > From your final statement... > > > > SNMP really is IMHO horribly broken for > > > > configuration management and attempts to fix it failed. This is long > > > > known and also documented in RFC 3535. > > I agree that SNMP is horribly broken for configuration management and > attempts to fix it have failed. > I think a major part of the "brokenness" is that SNMP does not recognize > the > difference between startup config and running config. IMO the problem has always been the lack of a transaction model. An agent has to process a random set of varbinds in each message. A complete row can be mixed with unrelated rows and spread across multiple PDUs. This is not how CLI works and not something operators need. The additional unwarranted complexity causes development schedules to be longer than managers are willing to accept. It costs too much to support SNMP Set. > An SNMP SET cannot specify whether a change 1) should be applied only to > the > running config and NOT persist beyond system reboot, or 2) should be > applied > to the running config and SHOULD persist across reboots, or 3) should be > applied to a startup config and not take effect until a system reboot. > > The community string or context can be used to specify which "config store" > to apply a SET to, but such usage has never been standardized, and > community > and context are so overloaded with proprietary uses that trying to use them > to standardize standardize config stores after the fact is not viable. > Around 1991-1992, there was an effort to try to standardize "temporal > contexts", but it got mired in the SNMP wars, and got dropped from SNMPv3. > > While the SET message in the (v1,v2,and v3 versions of the) SNMP protocol > has no field to specify which config store should be affected, a MIB object > description CAN specify that a RW object's value MUST persist across > reboot. > If the object doesn't specify such persistence, then any modification of > the > value does not persist across reboot. > Putting this into startup vs running config store terminology supported by > Netconf (and by some CLIs), but not required of a netconf implementation, > the non-persistent modification (#1) happens to the "running" config, while > the persistent modification (#2) happens to both the running and the > startup > config, while #3 only happens to the startup config. > > Equipment vendors have had to deal with the relationship between the > running > config and startup config when an SNMP SET modifies the running config, > when > persistence is called for. > > I am not understanding this focus on persistence. This is not an issue in agent implementation at all. I understand the fallback feature of persisting to the next reboot. This allows bad configuration to be dumped if the box is wedged and needs a reboot to recover. I don't see this as a property of the data model. It seems more likely that the operator can decide and the same data could persist or not, depending on the situation. (E.g., IOS write mem command) > Part of the problem we have discussing this issue is terminology. If > Netconf > or a CLI configures a device with a "running" config, and a subsequent > SNMP > SET modifies one of the configuration variables in a non-persistent manner, > is this still called the running config, or is this now called operational > state? Personally, based on what my equipment vendor co-workers called it, > I > think the modifiable variable is still part of the running config; the > running configuration has simply been modified. > I think of operational state as all the information provided to a query - > that would include read-only values, current read-write values, plus > counters. I never think of operational state as something you can write to > with a SET or a Netconf edit command; you write to the running > configuration, which is then echoed in the reported state. I think this is > reflected in MIB-2 (RFC1213), where they defined a RW object for > ifAdminStatus (the desired state of the interface) and a RO object for > ifOperStatus (the current operational state of the interface). The reality is that router vendors do not agree on the meaning of configuration. That's why we have 3 definitions of a default leaf in NETCONF. A lot of compromise has gone into a protocol that actually works for every vendor. It would be nice to converge on one simple architecture with no variance, but we are not there yet. Andy > > If Netconf configures a device, and an SNMP SET modifies it, does that > means > it is now operational state? then what is it called if Netconf configures > the device, and then a subsequent netconf edit command modifies it? is it > still the running config, or is it now operational state? Does the act of > modifying the configuration change it from config to operational state, or > is it the act of querying it that changes it to operational state? > > > > > > > I take it that you would assert that the draft statement should read > > > "SNMP MIB modules creating and modifying configuration" leaving out > > > the word "persistent" > > > > There are different terminologies around and depending on the one used > > I may agree or not. I definitely agree with "SNMP MIB modules creating > > and modifying persistent configuration" but that is likely not what > > you want to hear. ;-) > > > > In the NETCONF world, configuration data is pretty much synonymous > > with what I think you call persistent configuration. (The term > > 'persistent' does never appear in RFC 3535 but then RFC 3535 > > distinguishes between 'configuration data', operational state data, > > and statistics. RFC 6244 says (section 4.3.2): > > > > o Configuration data is the set of writable data that is required to > > transform a system from its initial default state into its current > > state [RFC4741]. > > > > This kind of implies that the configuration data is persistent since it > > needs to be there when the device re-initializes. > > > > o Operational state data is a set of data that has been obtained by > > the system at runtime and influences the system's behavior similar > > to configuration data. In contrast to configuration data, > > operational state is transient and modified by interactions with > > internal components or other systems via specialized protocols. > > > > This means that routing protocols or dhcp or even things like i2rs > > simply mess around with operational state. > > > > o Statistical data is the set of read-only data created by a system > > itself. It describes the performance of the system and its > > components. > > > > Given this terminology, I think what you call non-persistent > > configuration is operational state data. For relatively simple things > > that mess around with operational state (setting a threshold, turning > > off an interface), SNMP's peek and poke model can work. For more > > complex things, I personally would not recommend it but then I must > > also note that there is no well established better generic solution > > available in the IETF. Hence I believe it is right thing to limit > > the statement to 'persistent configuration'. > > > > /js > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > > Fax: +49 421 200 3103 > > > > _______________________________________________ > > OPS-AREA mailing list > > OPS-AREA@ietf.org > > https://www.ietf.org/mailman/listinfo/ops-area > > _______________________________________________ > OPS-AREA mailing list > OPS-AREA@ietf.org > https://www.ietf.org/mailman/listinfo/ops-area > --001a113a359c027da604f38c104d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Friday, February 28, 2014, ietfdbh <ietfdbh@comcast.net> wrote:
Hi,

Comments inline.

David Harrington
ietfdbh@comcast.net
+1-603-828-1401
> -----Original Message-----
> From: OPS-AREA [mailto:ops-area-bounces@ietf.= org] On Behalf Of Juergen
> Schoenwaelder
> Sent: Friday, February 28, 2014 3:43 PM
> To: Adrian Farrel
> Cc: 'ops-area'
> Subject: Re: [OPS-AREA] configuration: writable MIB modules versus
> NETCONF/YANG modules - part 2
>
> On Fri, Feb 28, 2014 at 08:16:19PM +0000, Adrian Farrel wrote:
> > Hi Juergen,
> >
> > Thanks for the explanation of the difference between "config= uration
data"
> and
> > "persistent configuration data".
> >
> > From your final statement...
> > > SNMP really is IMHO horribly broken for
> > > configuration management and attempts to fix it failed. This= is long
> > > known and also documented in RFC 3535.

I agree that SNMP is horribly broken for configuration management and
attempts to fix it have failed.
I think a major part of the "brokenness" is that SNMP does not re= cognize the
difference between startup config and running config.

=

IMO the problem has always been the lack of a tra= nsaction model.
An agent has to process a random set of varbinds = in each message.
A complete row can be mixed with unrelated rows and spread across
multiple PDUs. =A0This is not how CLI works and not something operato= rs
need.

The additional unwarranted complexity caus= es development schedules
to=A0be longer than managers are willing to accept. It costs too much = to
support SNMP Set.


=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex"> An SNMP SET cannot specify whether a change 1) should be applied only to th= e
running config and NOT persist beyond system reboot, or 2) should be applie= d
to the running config and SHOULD persist across reboots, or 3) should be applied to a startup config and not take effect until a system reboot.

The community string or context can be used to specify which "config s= tore"
to apply a SET to, but such usage has never been standardized, and communit= y
and context are so overloaded with proprietary uses that trying to use them=
to standardize standardize config stores after the fact is not viable.
Around 1991-1992, there was an effort to try to standardize "temporal<= br> contexts", but it got mired in the SNMP wars, and got dropped from SNM= Pv3.

While the SET message in the (v1,v2,and v3 versions of the) SNMP protocol has no field to specify which config store should be affected, a MIB object=
description CAN specify that a RW object's value MUST persist across re= boot.
If the object doesn't specify such persistence, then any modification o= f the
value does not persist across reboot.
Putting this into startup vs running config store terminology supported by<= br> Netconf (and by some CLIs), but not required of a netconf implementation, the non-persistent modification (#1) happens to the "running" con= fig, while
the persistent modification (#2) happens to both the running and the startu= p
config, while #3 only happens to the startup config.

Equipment vendors have had to deal with the relationship between the runnin= g
config and startup config when an SNMP SET modifies the running config, whe= n
persistence is called for.



I am not understanding = this focus on persistence.
This is not an issue in agent implemen= tation at all.

I understand the fallback feature o= f persisting to the next reboot.
This allows bad configuration to be dumped if the box is wedged
<= div>and needs a reboot to recover. I don't see this as a property of th= e
data model. =A0It seems more likely that the operator can decid= e
and the same data could persist or not, depending on the situation.
(E.g., IOS write mem command)

=A0
Part of the problem we have discussing this issue is terminology. If Netcon= f
or a CLI configures a device with a "running" config, =A0and a su= bsequent SNMP
SET modifies one of the configuration variables in a non-persistent manner,=
is this still called the running config, or is this now called operational<= br> state? Personally, based on what my equipment vendor co-workers called it, = I
think the modifiable variable is still part of the running config; the
running configuration has simply been modified.
I think of operational state as all the information provided to a query - that would include read-only values, current read-write values, plus
counters. I never think of operational state as something you can write to<= br> with a SET or a Netconf edit command; you write to the running
configuration, which is then echoed in the reported state. I think this is<= br> reflected in MIB-2 (RFC1213), where they defined =A0a RW object for
ifAdminStatus (the desired state of the interface) and a RO object for
ifOperStatus (the current operational state of the interface).
=


The reality is that router vendors do no= t agree on the meaning of configuration.
That's why we have 3= definitions of a default leaf in NETCONF.=A0
A lot of compromise has gone into a protocol that actually works forevery vendor. It would be nice to converge on one simple architecture
with no variance, but we are not there yet.


Andy

=A0

If Netconf configures a device, and an SNMP SET modifies it, does that mean= s
it is now operational state? then what is it called if Netconf configures the device, and then a subsequent netconf edit command modifies it? is it still the running config, or is it now operational state? Does the act of modifying the configuration change it from config to operational state, or<= br> is it the act of querying it that changes it to operational state?

> >
> > I take it that you would assert that the draft statement should r= ead
> > "SNMP MIB modules creating and modifying configuration"= leaving out
> > the word "persistent"
>
> There are different terminologies around and depending on the one used=
> I may agree or not. I definitely agree with "SNMP MIB modules cre= ating
> and modifying persistent configuration" but that is likely not wh= at
> you want to hear. ;-)
>
> In the NETCONF world, configuration data is pretty much synonymous
> with what I think you call persistent configuration. (The term
> 'persistent' does never appear in RFC 3535 but then RFC 3535 > distinguishes between 'configuration data', operational state = data,
> and statistics. RFC 6244 says (section 4.3.2):
>
> =A0 =A0o =A0Configuration data is the set of writable data that is req= uired to
> =A0 =A0 =A0 transform a system from its initial default state into its= current
> =A0 =A0 =A0 state [RFC4741].
>
> This kind of implies that the configuration data is persistent since i= t
> needs to be there when the device re-initializes.
>
> =A0 =A0o =A0Operational state data is a set of data that has been obta= ined by
> =A0 =A0 =A0 the system at runtime and influences the system's beha= vior similar
> =A0 =A0 =A0 to configuration data. =A0In contrast to configuration dat= a,
> =A0 =A0 =A0 operational state is transient and modified by interaction= s with
> =A0 =A0 =A0 internal components or other systems via specialized proto= cols.
>
> This means that routing protocols or dhcp or even things like i2rs
> simply mess around with operational state.
>
> =A0 =A0o =A0Statistical data is the set of read-only data created by a= system
> =A0 =A0 =A0 itself. =A0It describes the performance of the system and = its
> =A0 =A0 =A0 components.
>
> Given this terminology, I think what you call non-persistent
> configuration is operational state data. For relatively simple things<= br> > that mess around with operational state (setting a threshold, turning<= br> > off an interface), SNMP's peek and poke model can work. For more > complex things, I personally would not recommend it but then I must > also note that there is no well established better generic solution > available in the IETF. Hence I believe it is right thing to limit
> the statement to 'persistent configuration'.
>
> /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/= >
>
> _______________________________________________
> OPS-AREA mailing list
> OPS-AREA@ietf.org
> https://www.ietf.org/mailman/listinfo/ops-area

_______________________________________________
OPS-AREA mailing list
OPS-AREA@ietf.org
https://www.ietf.org/mailman/listinfo/ops-area
--001a113a359c027da604f38c104d-- From nobody Sat Mar 1 14:04:16 2014 Return-Path: X-Original-To: ops-area@ietfa.amsl.com Delivered-To: ops-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5EF91A027F for ; Sat, 1 Mar 2014 14:04:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_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 KNRyvF7-oJyL for ; Sat, 1 Mar 2014 14:04:12 -0800 (PST) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3lp0082.outbound.protection.outlook.com [213.199.154.82]) by ietfa.amsl.com (Postfix) with ESMTP id B5C5C1A0228 for ; Sat, 1 Mar 2014 14:04:11 -0800 (PST) Received: from DB3PRD0210HT003.eurprd02.prod.outlook.com (157.56.253.69) by DBXPR07MB064.eurprd07.prod.outlook.com (10.242.147.24) with Microsoft SMTP Server (TLS) id 15.0.888.9; Sat, 1 Mar 2014 22:04:07 +0000 Message-ID: <01e601cf3599$72e03b40$4001a8c0@gateway.2wire.net> From: t.petch To: ietfdbh , 'Juergen Schoenwaelder' , 'Adrian Farrel' References: <53107BAF.2050808@cisco.com> <15dc01cf34af$961c6c40$c25544c0$@olddog.co.uk> <20140228185713.GA15098@elstar.local> <163801cf34c1$f2a6e4b0$d7f4ae10$@olddog.co.uk> <20140228204251.GA15464@elstar.local> <00ff01cf34d4$cdcb5640$696202c0$@comcast.net> Date: Sat, 1 Mar 2014 21:58:51 +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.253.69] X-ClientProxiedBy: AM3PR07CA009.eurprd07.prod.outlook.com (10.242.16.49) To DBXPR07MB064.eurprd07.prod.outlook.com (10.242.147.24) X-Forefront-PRVS: 01371B902F X-Forefront-Antispam-Report: =?iso-8859-1?Q?SFV:NSPM; SFS:(10009001)(6009001)(428001)(199002)(189002)(5?= =?iso-8859-1?Q?1914003)(24454002)(377454003)(51704005)(13464003)(87976001?= =?iso-8859-1?Q?)(31966008)(74502001)(15975445006)(51856001)(47446002)(612?= =?iso-8859-1?Q?96002)(46102001)(80976001)(54316002)(86362001)(94316002)(9?= =?iso-8859-1?Q?5416001)(56776001)(94946001)(76786001)(93916002)(195803950?= =?iso-8859-1?Q?03)(19580405001)(83322001)(76796001)(81542001)(89996001)(7?= =?iso-8859-1?Q?6482001)(74662001)(42186004)(90146001)(56816005)(88136002)?= =?iso-8859-1?Q?(53806001)(85852003)(44716002)(33646001)(79102001)(9313600?= =?iso-8859-1?Q?1)(77156001)(62236002)(83072002)(50226001)(66066001)(14496?= =?iso-8859-1?Q?001)(4396001)(80022001)(74876001)(65816001)(69226001)(9272?= =?iso-8859-1?Q?6001)(81342001)(87286001)(87266001)(92566001)(77096001)(93?= =?iso-8859-1?Q?516002)(95666003)(47976001)(50986001)(47736001)(49866001)(?= =?iso-8859-1?Q?74706001)(50466002)(63696002)(84392001)(62966002)(23756003?= =?iso-8859-1?Q?)(74366001)(77982001)(59766001)(47776003)(44736004)(853060?= =?iso-8859-1?Q?02)(74416001)(7726001);DIR:OUT;SFP:1101;SCL:1;SRVR:DBXPR07?= =?iso-8859-1?Q?MB064;H:DB3PRD0210HT003.eurprd02.prod.outlook.com;CLIP:157?= =?iso-8859-1?Q?.56.253.69;FPR:EE2FFD14.A4229373.82F0FDAB.92E65140.20682;P?= =?iso-8859-1?Q?TR:InfoNoRecords;A:0;MX:1;LANG:en;?= Received-SPF: None (: btconnect.com does not designate permitted sender hosts) X-OriginatorOrg: btconnect.com Archived-At: http://mailarchive.ietf.org/arch/msg/ops-area/x3eMrOEL1rCA3Y-yJOc_OIID-rQ Cc: 'ops-area' Subject: Re: [OPS-AREA] configuration: writable MIB modules versus NETCONF/YANG modules - part 2 X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Mar 2014 22:04:15 -0000 ----- Original Message ----- From: "ietfdbh" To: "'Juergen Schoenwaelder'" ; "'Adrian Farrel'" Cc: "'ops-area'" Sent: Friday, February 28, 2014 10:31 PM > Comments inline. > > David Harrington > ietfdbh@comcast.net > +1-603-828-1401 > > -----Original Message----- > > From: OPS-AREA [mailto:ops-area-bounces@ietf.org] On Behalf Of Juergen > > Schoenwaelder > > Sent: Friday, February 28, 2014 3:43 PM > > To: Adrian Farrel > > Cc: 'ops-area' > > NETCONF/YANG modules - part 2 > > > > On Fri, Feb 28, 2014 at 08:16:19PM +0000, Adrian Farrel wrote: > > > Hi Juergen, > > > > > > Thanks for the explanation of the difference between "configuration > data" > > and > > > "persistent configuration data". > > > > > > From your final statement... > > > > SNMP really is IMHO horribly broken for > > > > configuration management and attempts to fix it failed. This is long > > > > known and also documented in RFC 3535. > > I agree that SNMP is horribly broken for configuration management and > attempts to fix it have failed. > I think a major part of the "brokenness" is that SNMP does not recognize the > difference between startup config and running config. > An SNMP SET cannot specify whether a change 1) should be applied only to the > running config and NOT persist beyond system reboot, or 2) should be applied > to the running config and SHOULD persist across reboots, or 3) should be > applied to a startup config and not take effect until a system reboot. David Oh yes it can! I have done something like it many times while operating a network. All it takes is proprietary MIB modules that provide different objects for the different purposes. The IETF could have standardised such a system - but didn't. Now we have the multiple data stores of NETCONF and so are moving in that direction. Tom Petch > The community string or context can be used to specify which "config store" > to apply a SET to, but such usage has never been standardized, and community > and context are so overloaded with proprietary uses that trying to use them > to standardize standardize config stores after the fact is not viable. > Around 1991-1992, there was an effort to try to standardize "temporal > contexts", but it got mired in the SNMP wars, and got dropped from SNMPv3. > > While the SET message in the (v1,v2,and v3 versions of the) SNMP protocol > has no field to specify which config store should be affected, a MIB object > description CAN specify that a RW object's value MUST persist across reboot. > If the object doesn't specify such persistence, then any modification of the > value does not persist across reboot. > Putting this into startup vs running config store terminology supported by > Netconf (and by some CLIs), but not required of a netconf implementation, > the non-persistent modification (#1) happens to the "running" config, while > the persistent modification (#2) happens to both the running and the startup > config, while #3 only happens to the startup config. > > Equipment vendors have had to deal with the relationship between the running > config and startup config when an SNMP SET modifies the running config, when > persistence is called for. > > Part of the problem we have discussing this issue is terminology. If Netconf > or a CLI configures a device with a "running" config, and a subsequent SNMP > SET modifies one of the configuration variables in a non-persistent manner, > is this still called the running config, or is this now called operational > state? Personally, based on what my equipment vendor co-workers called it, I > think the modifiable variable is still part of the running config; the > running configuration has simply been modified. > I think of operational state as all the information provided to a query - > that would include read-only values, current read-write values, plus > counters. I never think of operational state as something you can write to > with a SET or a Netconf edit command; you write to the running > configuration, which is then echoed in the reported state. I think this is > reflected in MIB-2 (RFC1213), where they defined a RW object for > ifAdminStatus (the desired state of the interface) and a RO object for > ifOperStatus (the current operational state of the interface). > > If Netconf configures a device, and an SNMP SET modifies it, does that means > it is now operational state? then what is it called if Netconf configures > the device, and then a subsequent netconf edit command modifies it? is it > still the running config, or is it now operational state? Does the act of > modifying the configuration change it from config to operational state, or > is it the act of querying it that changes it to operational state? > > > > > > > I take it that you would assert that the draft statement should read > > > "SNMP MIB modules creating and modifying configuration" leaving out > > > the word "persistent" > > > > There are different terminologies around and depending on the one used > > I may agree or not. I definitely agree with "SNMP MIB modules creating > > and modifying persistent configuration" but that is likely not what > > you want to hear. ;-) > > > > In the NETCONF world, configuration data is pretty much synonymous > > with what I think you call persistent configuration. (The term > > 'persistent' does never appear in RFC 3535 but then RFC 3535 > > distinguishes between 'configuration data', operational state data, > > and statistics. RFC 6244 says (section 4.3.2): > > > > o Configuration data is the set of writable data that is required to > > transform a system from its initial default state into its current > > state [RFC4741]. > > > > This kind of implies that the configuration data is persistent since it > > needs to be there when the device re-initializes. > > > > o Operational state data is a set of data that has been obtained by > > the system at runtime and influences the system's behavior similar > > to configuration data. In contrast to configuration data, > > operational state is transient and modified by interactions with > > internal components or other systems via specialized protocols. > > > > This means that routing protocols or dhcp or even things like i2rs > > simply mess around with operational state. > > > > o Statistical data is the set of read-only data created by a system > > itself. It describes the performance of the system and its > > components. > > > > Given this terminology, I think what you call non-persistent > > configuration is operational state data. For relatively simple things > > that mess around with operational state (setting a threshold, turning > > off an interface), SNMP's peek and poke model can work. For more > > complex things, I personally would not recommend it but then I must > > also note that there is no well established better generic solution > > available in the IETF. Hence I believe it is right thing to limit > > the statement to 'persistent configuration'. > > > > /js > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > > Fax: +49 421 200 3103 > > > > _______________________________________________ > > OPS-AREA mailing list > > OPS-AREA@ietf.org > > https://www.ietf.org/mailman/listinfo/ops-area > > _______________________________________________ > OPS-AREA mailing list > OPS-AREA@ietf.org > https://www.ietf.org/mailman/listinfo/ops-area From nobody Mon Mar 3 00:01:27 2014 Return-Path: X-Original-To: ops-area@ietfa.amsl.com Delivered-To: ops-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A28FA1A078B for ; Mon, 3 Mar 2014 00:01:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.047 X-Spam-Level: X-Spam-Status: No, score=-10.047 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oeRia3Jl0rks for ; Mon, 3 Mar 2014 00:01:24 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) by ietfa.amsl.com (Postfix) with ESMTP id A08011A09C3 for ; Mon, 3 Mar 2014 00:01:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4167; q=dns/txt; s=iport; t=1393833676; x=1395043276; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=XjH2nnNr1Y9aDPpVcT/WQaGGfBQ+YIzpCY3UpfLr4F0=; b=hE/aPgbjfhSz4hubXiFo3BjL9njD9mlaF0rFRiIBwCES1RPZHRGdaoW/ 2ryl6V7ei8NrcG63iq6p6m2576gUpVTqbRT7ev2ZQgp7DhdjQXHBNsQk3 IdJIiGgpUYuUKEDcsZzEks5DU/dmvcQV3cIoB7bm2JoXMxmsXjTIaE/UW s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAE02FFOQ/khM/2dsb2JhbABagwY7g1q9TIEdFnSCJQEBAQQjYgQPDQMBAgohAgIPAjUHAggGDQYCAQEFh3ANq1egUReOSBgGgihBgUkEmDyGSothgy08 X-IronPort-AV: E=Sophos;i="4.97,576,1389744000"; d="scan'208,217";a="6236711" Received: from ams-core-3.cisco.com ([144.254.72.76]) by aer-iport-2.cisco.com with ESMTP; 03 Mar 2014 08:01:15 +0000 Received: from [10.61.79.221] (ams3-vpn-dhcp4061.cisco.com [10.61.79.221]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s2381Ffw005601 for ; Mon, 3 Mar 2014 08:01:15 GMT Message-ID: <531436CC.40606@cisco.com> Date: Mon, 03 Mar 2014 08:01:16 +0000 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "ops-area@ietf.org" References: <20140302180143.31340.22881.idtracker@ietfa.amsl.com> In-Reply-To: <20140302180143.31340.22881.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20140302180143.31340.22881.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------010301050105020407000802" Archived-At: http://mailarchive.ietf.org/arch/msg/ops-area/pN2RGyAgPtt_kaZWEGwIyR2jEPM Subject: [OPS-AREA] Fwd: Writable MIB Module IESG Statement X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 08:01:27 -0000 This is a multi-part message in MIME format. --------------010301050105020407000802 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit In case you missed that announcement.... It's officially posted at http://www.ietf.org/iesg/statement/writable-mib-module.html Regards, Benoit -------- Original Message -------- Subject: Writable MIB Module IESG Statement Date: Sun, 2 Mar 2014 10:01:43 -0800 From: The IESG Reply-To: To: IETF Announcement List The IESG is aware of discussions in the OPS area and in a number of working groups about the current practice for standards-based approaches to configuration. The OPS area has shown strong support for the use of NETCONF/YANG while many working groups continue to specify MIB modules for this purpose. The IESG wishes to clarify this situation with this statement: - IETF working groups are therefore encouraged to use the NETCONF/YANG standards for configuration, especially in new charters. - SNMP MIB modules creating and modifying configuration state should only be produced by working groups in cases of clear utility and consensus to use SNMP write operations for configuration, and in consultation with the OPS ADs/MIB doctors. --------------010301050105020407000802 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit In case you missed that announcement....
It's officially posted at http://www.ietf.org/iesg/statement/writable-mib-module.html

Regards, Benoit


-------- Original Message --------
Subject: Writable MIB Module IESG Statement
Date: Sun, 2 Mar 2014 10:01:43 -0800
From: The IESG <iesg@ietf.org>
Reply-To: <ietf@ietf.org>
To: IETF Announcement List <ietf-announce@ietf.org> 


The IESG is aware of discussions in the OPS area and in a number of 
working groups about the current practice for standards-based approaches 
to configuration. The OPS area has shown strong support for the use of 
NETCONF/YANG while many working groups continue to specify MIB modules 
for this purpose. The IESG wishes to clarify this situation with this 
statement:

- IETF working groups are therefore encouraged to use the NETCONF/YANG 
  standards for configuration, especially in new charters. 

- SNMP MIB modules creating and modifying configuration state should 
  only be produced by working groups in cases of clear utility and 
  consensus to use SNMP write operations for configuration,  and in 
  consultation with the OPS ADs/MIB doctors.


--------------010301050105020407000802-- From nobody Mon Mar 3 05:38:01 2014 Return-Path: X-Original-To: ops-area@ietfa.amsl.com Delivered-To: ops-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CF341A016F for ; Mon, 3 Mar 2014 05:37:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.446 X-Spam-Level: X-Spam-Status: No, score=-2.446 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3gmJ415026sx for ; Mon, 3 Mar 2014 05:37:56 -0800 (PST) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id DB4BA1A016B for ; Mon, 3 Mar 2014 05:37:55 -0800 (PST) Received: from dhcp-a24b.meeting.ietf.org (dhcp-a24b.meeting.ietf.org [31.133.162.75]) by lucidvision.com (Postfix) with ESMTP id EC4362714735; Mon, 3 Mar 2014 08:37:51 -0500 (EST) Content-Type: multipart/signed; boundary="Apple-Mail=_0551795E-3A39-4270-8C3A-E068E7310C33"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Thomas Nadeau In-Reply-To: <53107BAF.2050808@cisco.com> Date: Mon, 3 Mar 2014 13:37:49 +0000 Message-Id: <5F163026-71B5-4546-B25B-B9125A63DCC8@lucidvision.com> References: <53107BAF.2050808@cisco.com> To: Benoit Claise X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/ops-area/h8wWJ3PVQ2hg7qnyOIztiNEPU5Q Cc: Randy Bush , "ops-area@ietf.org" Subject: Re: [OPS-AREA] configuration: writable MIB modules versus NETCONF/YANG modules - part 2 X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 13:37:59 -0000 --Apple-Mail=_0551795E-3A39-4270-8C3A-E068E7310C33 Content-Type: multipart/alternative; boundary="Apple-Mail=_C20D40A3-CE60-482E-B7F2-0DF288ED90F1" --Apple-Mail=_C20D40A3-CE60-482E-B7F2-0DF288ED90F1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Sorry for not replying to this thread - been traveling and busy = all weekend... One comment inline below: > Dear all, >=20 > [I bcc'ed some people, with whom I discussed this issue privately. I = want to make sure they're in the opsarea loop. Sorry, if you receive = this email twice] >=20 > I discussed the following statement with the IESG. I ideally wanted to = have this statement approved as an IESG statement before the beginning = of the week, but I realize that it might need some more discussion among = the OPS community... > 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, especially in new charters. = SNMP MIB modules creating and 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. > Btw, one IESG member insisted on having "creating and modifying" = instead of "modifying".=20 >=20 > Let me focus on a more important issue. > First let me make sure that we agree on one terminology. The = NETCONF/YANG terminology is in RFC 6244: > o Configuration data is the set of writable data that is required = to > transform a system from its initial default state into its = current > state [RFC4741]. >=20 > o Operational state data is a set of data that has been obtained = by > the system at runtime and influences the system's behavior = similar > to configuration data. In contrast to configuration data, > operational state is transient and modified by interactions with > internal components or other systems via specialized protocols. >=20 > o Statistical data is the set of read-only data created by a = system > itself. It describes the performance of the system and its > components.=20 > Operational state data is sometimes called ephemeral (or = non-persistent configuration data), as opposed to the "configuration = data" that is persistent. > See RFC 6244 section 4.3.2.x for some useful examples. >=20 > The statement has been carefully crafted to cover the 4 different = cases: >=20 > = SNMP = NETCONF/YANG=20 > = +-----------------------------------------------------------------+-------= -------------------------------------------+ > Configuration data | SHOULD NOT specify writable MIB = modules | SHOULD use NETCONF/YANG | > = |-----------------------------------------------------------------+-------= -------------------------------------------| > Operational State data | Not clear guidelines at time point in = time (*) | SHOULD use NETCONF/YANG | > = +-------------------------------------------------------------------------= --------------------------------------------+ = =20 >=20 > Let me focus on (*). > Some of you are telling: SNMPset is not enabled in networks, period. = Don't specify new writable MIB modules, even for operational state data, = it doesn't make sense. > Some others are telling: Note that this statement limits the = discussion to configuration data. Note also that there is no standard = way to modify operational state via NETCONF at this point in time (so it = would be strange to discourage SNMP if there is no standardized = alternative).=20 >=20 > I believe we need some more discussion on this specific point. Please = share your point of view: > - Should we keep the statement as it is, but better explain it? (which = might require more background, so maybe a draft instead of a brief = statement) > - Should we extend the statement and remove "persistent" from this = sentence: SNMP MIB modules creating and 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? > - Something else? This is precisely what is the question: is the SET operation = enabled in networks or not ? I think the overwhelming answer is "no". = The discussions that are rabbit holing into questions like "what is = configuration?, "is it persistent, etc...?" are completely missing the = point. The simple issue at hand is the fact that boxes in networks are = programmed to reject ANY SNMP SET operations. This is what Randy was = channeling from operators the other day as well. We really need to = listen to the operational feedback on this one.=20 --Tom >=20 > Regards, Benoit >=20 >=20 >=20 >=20 > _______________________________________________ > OPS-AREA mailing list > OPS-AREA@ietf.org > https://www.ietf.org/mailman/listinfo/ops-area --Apple-Mail=_C20D40A3-CE60-482E-B7F2-0DF288ED90F1 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=iso-8859-1
Sorry for not replying to this thread - been traveling and busy all weekend...  One comment inline below:


Dear all,

[I bcc'ed some people, with whom I discussed this issue privately. I want to make sure they're in the opsarea loop. Sorry, if you receive this email twice]

I discussed the following statement with the IESG. I ideally wanted to have this statement approved as an IESG statement before the beginning of the week, but I realize that it might need some more discussion among the OPS community...
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, especially in new charters. SNMP MIB modules creating and 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.
Btw, one IESG member insisted on having "creating and modifying" instead of "modifying".

Let me focus on a more important issue.
First let me make sure that we agree on one terminology. The NETCONF/YANG terminology is in RFC 6244:
  o  Configuration data is the set of writable data that is required to
      transform a system from its initial default state into its current
      state [RFC4741].

   o  Operational state data is a set of data that has been obtained by
      the system at runtime and influences the system's behavior similar
      to configuration data.  In contrast to configuration data,
      operational state is transient and modified by interactions with
      internal components or other systems via specialized protocols.

   o  Statistical data is the set of read-only data created by a system
      itself.  It describes the performance of the system and its
      components.
Operational state data is sometimes called ephemeral (or non-persistent configuration data), as opposed to the "configuration data" that is persistent.
See RFC 6244 section 4.3.2.x for some useful examples.

The statement has been carefully crafted to cover the 4 different cases:

                                                                             SNMP                                                         NETCONF/YANG
                                              +-----------------------------------------------------------------+--------------------------------------------------+
            Configuration data  | SHOULD NOT specify writable MIB modules    |  SHOULD use NETCONF/YANG          |
                                              |-----------------------------------------------------------------+--------------------------------------------------|
     Operational State data  | Not clear guidelines at time point in time  (*)   |   SHOULD use NETCONF/YANG         |
                                              +---------------------------------------------------------------------------------------------------------------------+                                             

Let me focus on (*).
Some of you are telling: SNMPset is not enabled in networks, period. Don't specify new writable MIB modules, even for operational state data, it doesn't make sense.
Some others are telling: Note that this statement limits the discussion to configuration data. Note also that there is no standard way to modify operational state via NETCONF at this point in time (so it would be strange to discourage SNMP if there is no standardized alternative).

I believe we need some more discussion on this specific point.  Please share your point of view:
- Should we keep the statement as it is, but better explain it? (which might require more background, so maybe a draft instead of a brief statement)
- Should we extend the statement and remove "persistent" from this sentence: SNMP MIB modules creating and 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?
- Something else?

This is precisely what is the question: is the SET operation enabled in networks or not ?  I think the overwhelming answer is "no". The discussions that are rabbit holing into questions like "what is configuration?, "is it persistent, etc...?" are completely missing the point. The simple issue at hand is the fact that boxes in networks are programmed to reject ANY SNMP SET operations.  This is what Randy was channeling from operators the other day as well. We really need to listen to the operational feedback on this one. 

--Tom



Regards, Benoit




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

--Apple-Mail=_C20D40A3-CE60-482E-B7F2-0DF288ED90F1-- --Apple-Mail=_0551795E-3A39-4270-8C3A-E068E7310C33 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJTFIWtAAoJEPcO+I7eiUJZPnMQAIFB/RaXiYoWu3pgErBGk85A ABSzbB9MZTl2quIRIqp/s6cgbr4YsdEpjC/yZ2qBhkfNl6n1huSZBLPJE01Hy8e2 ZLDegnDHAe17V75rud/NAybdjFCp6QaCpFXPxQcmYkEnqk73s7LPIOcn5uKzDG7q 65O6JqnWb2E2ggkk79ZUl4IW7tg7ijbHMgkJ2T7XDR+TdaDXylul1M7gwg6fO2uK EyHo1NYcaUQFye4Cturu4caaY6QpC0Uxa/Q5BPN+ygSlBGoPSrz4gHPJnesZnccn N/FDaD14qV4GJKlHAkYPgsdu6soU17KnVJQiF0TcKnUEW/dVXpkiDgUQVceq9BE8 +oXY0KHUTLoFIpYkUjDnqd67QrwPSOZ3QTnit3ovd75NsD1SXvVPctE6feeTsMei 2sy4D3/KOwSdULCa3mMee8k5BovIikWa+vHAH8BHV+X15L5D6ApP5hyqNfUZ5Ydq TsrCZGxlpN8bLFUqvai6gaEeAhcTnPwrhstS27UeuK5PQNPuNA5tOkZQVB88Jg9o 0qAu5SP9zMtAxrT7jqldTe6UijBK8Ly6tcgHGU9kLvodf3pxRhjWidGuuDj8pTwc oicxhWI1NouSbLcXwbsatagLcx/vvL9oo1rUW2Y4gah+psOMn0WG5m1kQHcAD5q4 RtHWEhmQcLzh4w3/vrw0 =CoB7 -----END PGP SIGNATURE----- --Apple-Mail=_0551795E-3A39-4270-8C3A-E068E7310C33-- From nobody Mon Mar 3 08:23:19 2014 Return-Path: X-Original-To: ops-area@ietfa.amsl.com Delivered-To: ops-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 470A51A020B for ; Mon, 3 Mar 2014 08:23:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.566 X-Spam-Level: X-Spam-Status: No, score=-1.566 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334] 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 NQiB2gdxDVvl for ; Mon, 3 Mar 2014 08:23:10 -0800 (PST) Received: from smtp2.emailarray.com (smtp.emailarray.com [69.28.212.198]) by ietfa.amsl.com (Postfix) with ESMTP id 0B2BA1A020E for ; Mon, 3 Mar 2014 08:23:09 -0800 (PST) Received: (qmail 88230 invoked by uid 89); 3 Mar 2014 16:23:06 -0000 Received: from unknown (HELO ?31.133.187.126?) (Y2RsQGFzZ2FhcmQub3JnQDMxLjEzMy4xODcuMTI2) (POLARISLOCAL) by smtp2.emailarray.com with SMTP; 3 Mar 2014 16:23:05 -0000 From: "Christopher LILJENSTOLPE" To: "Thomas Nadeau" Date: Mon, 03 Mar 2014 16:22:57 +0000 Message-ID: In-Reply-To: <5F163026-71B5-4546-B25B-B9125A63DCC8@lucidvision.com> References: <53107BAF.2050808@cisco.com> <5F163026-71B5-4546-B25B-B9125A63DCC8@lucidvision.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Mailer: MailMate (1.7.2r4025) X-PolarisMail-Flags: x Archived-At: http://mailarchive.ietf.org/arch/msg/ops-area/DZQ2YmS9-NruM9x3UIr9BO_4q_g Cc: Randy Bush , "ops-area@ietf.org" Subject: Re: [OPS-AREA] [eX-bulk] : Re: configuration: writable MIB modules versus NETCONF/YANG modules - part 2 X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 16:23:13 -0000 On 3 Mar 2014, at 13:37, Thomas Nadeau wrote: > Sorry for not replying to this thread - been traveling and busy all = > weekend... One comment inline below: > > >> Dear all, >> >> [I bcc'ed some people, with whom I discussed this issue privately. I = >> want to make sure they're in the opsarea loop. Sorry, if you receive = >> this email twice] >> >> I discussed the following statement with the IESG. I ideally wanted = >> to have this statement approved as an IESG statement before the = >> beginning of the week, but I realize that it might need some more = >> discussion among the OPS community... >> 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, especially in new = >> charters. SNMP MIB modules creating and 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. >> Btw, one IESG member insisted on having "creating and modifying" = >> instead of "modifying". >> >> Let me focus on a more important issue. >> First let me make sure that we agree on one terminology. The = >> NETCONF/YANG terminology is in RFC 6244: >> o Configuration data is the set of writable data that is required to >> transform a system from its initial default state into its current >> state [RFC4741]. >> >> o Operational state data is a set of data that has been obtained by >> the system at runtime and influences the system's behavior similar >> to configuration data. In contrast to configuration data, >> operational state is transient and modified by interactions with >> internal components or other systems via specialized protocols. >> >> o Statistical data is the set of read-only data created by a system >> itself. It describes the performance of the system and its >> components. >> Operational state data is sometimes called ephemeral (or = >> non-persistent configuration data), as opposed to the "configuration = >> data" that is persistent. >> See RFC 6244 section 4.3.2.x for some useful examples. >> >> The statement has been carefully crafted to cover the 4 different = >> cases: >> >> = >> SNMP = >> NETCONF/YANG >> = >> +-----------------------------------------------------------------+---= -----------------------------------------------+ >> Configuration data | SHOULD NOT specify writable MIB modules = >> | SHOULD use NETCONF/YANG | >> = >> |-----------------------------------------------------------------+---= -----------------------------------------------| >> Operational State data | Not clear guidelines at time point in time = >> (*) | SHOULD use NETCONF/YANG | >> = >> +---------------------------------------------------------------------= ------------------------------------------------+ >> >> Let me focus on (*). >> Some of you are telling: SNMPset is not enabled in networks, period. = >> Don't specify new writable MIB modules, even for operational state = >> data, it doesn't make sense. >> Some others are telling: Note that this statement limits the = >> discussion to configuration data. Note also that there is no standard = >> way to modify operational state via NETCONF at this point in time (so = >> it would be strange to discourage SNMP if there is no standardized = >> alternative). >> >> I believe we need some more discussion on this specific point. = >> Please share your point of view: >> - Should we keep the statement as it is, but better explain it? = >> (which might require more background, so maybe a draft instead of a = >> brief statement) >> - Should we extend the statement and remove "persistent" from this = >> sentence: SNMP MIB modules creating and 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? >> - Something else? > > This is precisely what is the question: is the SET operation enabled = > in networks or not ? I think the overwhelming answer is "no". The = > discussions that are rabbit holing into questions like "what is = > configuration?, "is it persistent, etc...?" are completely missing the = > point. The simple issue at hand is the fact that boxes in networks are = > programmed to reject ANY SNMP SET operations. This is what Randy was = > channeling from operators the other day as well. We really need to = > listen to the operational feedback on this one. I agree Tom. The larger question, at the end of the day, is how many = models do we want to continue support. Do we want to define MIBs for = statistics, and NETCONF for configuration, going forward, or do we want = to, over time, standardize on a single data model infrastructure = (YANG?), that can then generate NETCONF, and possibly MIBs, if MIBs are = still desired for operational data collection? I'm in favor of a common = data model definition, that can then be rendered into whatever protocols = are deemed appropriate by the implementer. Christopher > > --Tom > > >> >> Regards, Benoit >> >> >> >> >> _______________________________________________ >> OPS-AREA mailing list >> OPS-AREA@ietf.org >> https://www.ietf.org/mailman/listinfo/ops-area > > _______________________________________________ > OPS-AREA mailing list > OPS-AREA@ietf.org > https://www.ietf.org/mailman/listinfo/ops-area -- =E6=9D=8E=E6=9F=AF=E7=9D=BF Check my PGP key here: http://www.asgaard.org/cdl/cdl.asc Current vCard here: http://www.asgaard.org/cdl/cdl.vcf From nobody Mon Mar 3 08:57:13 2014 Return-Path: X-Original-To: ops-area@ietfa.amsl.com Delivered-To: ops-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CDE21A0177 for ; Mon, 3 Mar 2014 08:57:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 92XTeiX9id-4 for ; Mon, 3 Mar 2014 08:57:09 -0800 (PST) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 10AB71A00B6 for ; Mon, 3 Mar 2014 08:57:09 -0800 (PST) Received: from [130.129.157.234] (unknown [130.129.157.234]) by lucidvision.com (Postfix) with ESMTP id BB7D12714EC2; Mon, 3 Mar 2014 11:57:04 -0500 (EST) References: <53107BAF.2050808@cisco.com> <5F163026-71B5-4546-B25B-B9125A63DCC8@lucidvision.com> <7E945E60-DA52-4DD3-9358-0D1DEF714F62@cdl.asgaard.org> Mime-Version: 1.0 (1.0) In-Reply-To: <7E945E60-DA52-4DD3-9358-0D1DEF714F62@cdl.asgaard.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (11B651) From: Thomas D Nadeau Date: Mon, 3 Mar 2014 16:57:03 +0000 To: Christopher LILJENSTOLPE Archived-At: http://mailarchive.ietf.org/arch/msg/ops-area/Wc5Q9YSoi80BaWoGaOS3himp-Fk Cc: Randy Bush , "ops-area@ietf.org" Subject: Re: [OPS-AREA] [eX-bulk] : Re: configuration: writable MIB modules versus NETCONF/YANG modules - part 2 X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 16:57:11 -0000 I'm not sure about the implementations, but models (yang) are definitely the= right direction of you ask me. translation from a common model is easier t= han one from every specific management protocol as (automated) code generati= on is a viable solution (see the direction odp is going). Tom=20 > On Mar 3, 2014, at 16:19, "Christopher LILJENSTOLPE" wrote: >=20 >> On 3 Mar 2014, at 13:37, Thomas Nadeau wrote: >>=20 >> Sorry for not replying to this thread - been traveling and busy all we= ekend... One comment inline below: >>=20 >>=20 >>> Dear all, >>>=20 >>> [I bcc'ed some people, with whom I discussed this issue privately. I wan= t to make sure they're in the opsarea loop. Sorry, if you receive this email= twice] >>>=20 >>> I discussed the following statement with the IESG. I ideally wanted to h= ave this statement approved as an IESG statement before the beginning of the= week, but I realize that it might need some more discussion among the OPS c= ommunity... >>> The OPS area recommends the use of NETCONF/YANG standards for configurat= ion. IETF working groups are therefore encouraged to use the NETCONF/YANG st= andards for configuration, especially in new charters. SNMP MIB modules crea= ting and modifying persistent configuration state should only be produced by= working groups in cases of clear utility and consensus to use SNMP write op= erations for configuration. >>> Btw, one IESG member insisted on having "creating and modifying" instead= of "modifying". >>>=20 >>> Let me focus on a more important issue. >>> First let me make sure that we agree on one terminology. The NETCONF/YAN= G terminology is in RFC 6244: >>> o Configuration data is the set of writable data that is required to >>> transform a system from its initial default state into its current >>> state [RFC4741]. >>>=20 >>> o Operational state data is a set of data that has been obtained by >>> the system at runtime and influences the system's behavior similar >>> to configuration data. In contrast to configuration data, >>> operational state is transient and modified by interactions with >>> internal components or other systems via specialized protocols. >>>=20 >>> o Statistical data is the set of read-only data created by a system >>> itself. It describes the performance of the system and its >>> components. >>> Operational state data is sometimes called ephemeral (or non-persistent c= onfiguration data), as opposed to the "configuration data" that is persisten= t. >>> See RFC 6244 section 4.3.2.x for some useful examples. >>>=20 >>> The statement has been carefully crafted to cover the 4 different cases:= >>>=20 >>> = SNMP NETCONF/YANG >>> +-----------------------------= ------------------------------------+---------------------------------------= -----------+ >>> Configuration data | SHOULD NOT specify writable MIB modules = | SHOULD use NETCONF/YANG | >>> |-----------------------------= ------------------------------------+---------------------------------------= -----------| >>> Operational State data | Not clear guidelines at time point in time (= *) | SHOULD use NETCONF/YANG | >>> +-----------------------------= ----------------------------------------------------------------------------= ------------+ >>>=20 >>> Let me focus on (*). >>> Some of you are telling: SNMPset is not enabled in networks, period. Don= 't specify new writable MIB modules, even for operational state data, it doe= sn't make sense. >>> Some others are telling: Note that this statement limits the discussion t= o configuration data. Note also that there is no standard way to modify oper= ational state via NETCONF at this point in time (so it would be strange to d= iscourage SNMP if there is no standardized alternative). >>>=20 >>> I believe we need some more discussion on this specific point. Please s= hare your point of view: >>> - Should we keep the statement as it is, but better explain it? (which m= ight require more background, so maybe a draft instead of a brief statement)= >>> - Should we extend the statement and remove "persistent" from this sente= nce: SNMP MIB modules creating and modifying persistent configuration state s= hould only be produced by working groups in cases of clear utility and conse= nsus to use SNMP write operations for configuration? >>> - Something else? >>=20 >> This is precisely what is the question: is the SET operation enabled i= n networks or not ? I think the overwhelming answer is "no". The discussion= s that are rabbit holing into questions like "what is configuration?, "is it= persistent, etc...?" are completely missing the point. The simple issue at h= and is the fact that boxes in networks are programmed to reject ANY SNMP SET= operations. This is what Randy was channeling from operators the other day= as well. We really need to listen to the operational feedback on this one. >=20 > I agree Tom. The larger question, at the end of the day, is how many mode= ls do we want to continue support. Do we want to define MIBs for statistics= , and NETCONF for configuration, going forward, or do we want to, over time,= standardize on a single data model infrastructure (YANG?), that can then ge= nerate NETCONF, and possibly MIBs, if MIBs are still desired for operational= data collection? I'm in favor of a common data model definition, that can t= hen be rendered into whatever protocols are deemed appropriate by the implem= enter. >=20 > Christopher >=20 >>=20 >> --Tom >>=20 >>=20 >>>=20 >>> Regards, Benoit >>>=20 >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> OPS-AREA mailing list >>> OPS-AREA@ietf.org >>> https://www.ietf.org/mailman/listinfo/ops-area >>=20 >> _______________________________________________ >> OPS-AREA mailing list >> OPS-AREA@ietf.org >> https://www.ietf.org/mailman/listinfo/ops-area >=20 >=20 > -- > =E6=9D=8E=E6=9F=AF=E7=9D=BF > Check my PGP key here: http://www.asgaard.org/cdl/cdl.asc > Current vCard here: http://www.asgaard.org/cdl/cdl.vcf >=20 From nobody Tue Mar 4 08:38:16 2014 Return-Path: X-Original-To: ops-area@ietfa.amsl.com Delivered-To: ops-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F06C1A003A for ; Tue, 4 Mar 2014 08:38:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mT8xZQT04s3g for ; Tue, 4 Mar 2014 08:38:11 -0800 (PST) Received: from smtp.restena.lu (legolas.restena.lu [IPv6:2001:a18:1::34]) by ietfa.amsl.com (Postfix) with ESMTP id D45821A01CD for ; Tue, 4 Mar 2014 08:38:10 -0800 (PST) Received: from smtp.restena.lu (localhost [127.0.0.1]) by smtp.restena.lu (Postfix) with ESMTP id 1B4D713A62A for ; Tue, 4 Mar 2014 17:38:05 +0100 (CET) Received: from viper.local (unknown [158.64.15.194]) by smtp.restena.lu (Postfix) with ESMTPSA id EEDF813A627 for ; Tue, 4 Mar 2014 17:38:04 +0100 (CET) Message-ID: <53160168.8070007@restena.lu> Date: Tue, 04 Mar 2014 17:38:00 +0100 From: Stefan Winter User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: ops-area@ietf.org Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="krGLwUc5aujQ7iKbJwsUcrenVRITb5bPM" X-Virus-Scanned: ClamAV Archived-At: http://mailarchive.ietf.org/arch/msg/ops-area/HN8Or1trrhLbZ_VPsnTRz8vTFRk Subject: [OPS-AREA] eduroam architecture draft (includes UDP vs. TLS considerations) X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2014 16:38:13 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --krGLwUc5aujQ7iKbJwsUcrenVRITb5bPM Content-Type: multipart/mixed; boundary="------------020000050502020506010002" This is a multi-part message in MIME format. --------------020000050502020506010002 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Hi, this is our draft on the eduroam architecture, as teased in the opsarea meeting. https://datatracker.ietf.org/doc/draft-wierenga-ietf-eduroam/ We are still looking for a home / sponsor for it :-) As a sidenote: contrary to many commercial operators, we are publicly funded and all our documentation is open for everybody. If you have any hands-on questions beyond the draft's content, don't hesitate to ask. I'll merrily tell you everything except the shared secrets ;-) Greetings, Stefan --------------020000050502020506010002 Content-Type: application/pgp-keys; name="0x8A39DC66.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x8A39DC66.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org mQINBFIplEwBEADTSz+DS8nio+RSvfSLLfaOnCGi1nqpn8Pb1laVUyEvnAAzZ5je miS88GxfiDH6hUGlWzcaW0hCfUHGiohr485adbjxRksPngWgAt/1bRxpifsW3zOb Fjgog01WWQV5Sihlwc4zr8zvYbFA5BJZ6YdkR9C5J015riv5OS30WTjA65SSXgYr b7zJWPwmegTFwE093uBFvC39waz3xYpVu5j87nO6w2MVQt/8sY2/2BFPEq+xfOaj l18UEwc7w8SCgnZdlVNcmEK4UBvJuwS/1lsR2JeQa8Gu1EDxC7PRgMgNXsDSWnnB e9aVmfG54+6ILe1QH2dwk9sPBQT5w2+vjijrb3Dv9ur+1kN+TNU2XE436jVpnnY/ 3OsLdix30STQn4Q/XOm7YoVMeDwwviefilRxzK0dXA+wKj92T68Od82CFxuZqPAg BCVmWfQM91iK9piqFK+QP+R3vF6+NGDBdwbe68iVKs0v5L8XmbxBQndjpmo+lo2a smBR2TAIfZHaKdgtBw13u3GPVVKlg/Mpko8ki9JOSem2aFyi3kQEVKptWgXT3POl 97DWJzsR5VyKz6GOx9kJAEISRyLZwm0wqh8+9LCza5oeIKW381lzq1b9x30vOh8C BSQQJ+cG9ko0yPHAj7Suw2TmPXx1qMctmE6Ahq82ZW30SljdZby8WQuR2wARAQAB tDxTdGVmYW4gV2ludGVyIChSRVNURU5BIGtleSAyMDEzKykgPHN0ZWZhbi53aW50 ZXJAcmVzdGVuYS5sdT6JAjkEEwECACMFAlIplEwCGwMHCwkIBwMCAQYVCAIJCgsE FgIDAQIeAQIXgAAKCRDA3mo1ijncZj7/D/99hVS+mJr8dSPCaDaUFFxBiT2eI1Lo R8VKEerTCRw5BsdL6pN2eRJZ9NmsqWo1ynWVHEzO91bNZ+oZGgyoNohcBAI7p+r0 qUTzkyqwdZO4kMm0pqKoM9xkP3tf2mjGujKjOz4Y7S7wnz2ZFokeUsecoRVJF/++ /qHnmeWLn44J1HUKLHYCjMu+QXGOgGXgz024jQ5eUrnPwzNp0Z90AFVHlWC+bymt y/ToIUUCQqS5Ff0jzdWLd8U695OG9iGvjBQT1LdEjsfbAwuKV5UcnpxNqUpUwKa5 9hdX5/2cMZP07FI1UXwnBlxa8rJfdb13FLjSKX4vUUHedYUZMjMPgcwl1a+zGE22 lHiSQWgP8QLA/W3BLsi22ERCEPZBfexOeOtaWIItDIz18fIaQoMDoRPshzar0JI2 CzLYsyeKySAtYJEHFVoLmMvhkwzBmgqA/BEswUA67CfCr1jFHRXdpmWM7YkyAmMa 9q6LwquWKS5+MXlUXe/3oZUcgpw/T9Uuy3Jo3RdS7B3jFcWaVr6KsO/A9u1gr/aY n5M+iJTQSj4vzqtkQaJTpSspRZoKa66HZt3IwSYiDiYZqtM83ynuj9kjnZzGfnuT aNIi996q6Mptr33mOzIE1wmMqnJYwTr3EcNtf483q/qrJwh5ES8Q9xY7aat/ZcSl 8fKubW4TlfVr8YhGBBARAgAGBQJSKZUGAAoJEPo5vdH/HhVmYTgAn24eoqO/O98o vNpt08Uab/+/tmYKAJ9kjXm9Njz5h33efzeelZUa484rr7kCDQRSKZRMARAAvBPp n7FQq7LQ5glohtbL6XIEo1U4X67S0TzUYieENSWSVYuWYIhCBldmWdmH8Bpj/qHe qdon7v+SLtR4WngzMR9toupKcFfHnbP9kpazTSB2ySHxXWGX1gJOpPXdCcg9iveK BHEsDn00ThTcPsvtXpnnzET16pXIvOXO0bxTmVZ4INIF1SWgvYma/g8kBbgXLpkj 8tOywBqFiiYPEZlDeCxDHiMgUDh6olda9K/0TZFTdMPUgjKuubfAeaDNCOrVt4Rj mFOaRLikcZocmgJhm3z/j25x7/mnNu+0di1H/S67YGQJ+pqCFInzIXDx7aRW2+JC iqsY2X3xOPWZZzjyis5SNnfOcPH3gt2hYz1fy+thsBGf4NgCN01JRqIJ2/MOQCgU dwh+9l8xqaJvCkUHM4hVh4W62MAe1u7UEqQbvvNEqxM5034vcvlE+/LRkrDCspw+ 2YJ9QyroLerVRwW5DVleP8Ifi8VB3yD80nqXYs9aqRy0BkDNIQ43ERhESMt8dJqr NkxgC6pemZrhNwyDh+hy2kPNGQh/iBpdKuH1o3E24TIZoV2v3YHvzob7aAYHddE/ PofAXhJW7I9mAs+HdWDmnI8ckuPDFpFH+Y/BFGvEXgcnJAJ1wEvf+4LuiIi0MHjR 4EWFn9vvoFDAIqD10h3FSd3D59HGtdSsNn4XaCsAEQEAAYkCHwQYAQIACQUCUimU TAIbDAAKCRDA3mo1ijncZhBtEACL036ddjc5pFoYIdoUY1vT8SMXJNquewCnL1qu DADzqDZFU5GNlQEy10krSfBwlTb9ahTtE0JFrOdZwUZtoa1Pgfr8nU6KOgrXPHbN jS/9dyc5CwGVVIpOavIm2CsMVDJ9LCF/NT+u/t1k6eGfHhPVl3dUQyDa/lzc1chK UIVQYQkFmr0A/iXP+29lFCaI+IeyU0bSdZhezDwUROn5vEx+fiPZyHDShCb+BxJv /o2LQp9JHenCiSbO+ioRZdxgbWfoKBuXOfmSStqMWXas/gZ5vS3xq72LNtKPRxgp jX3P8Zml1XDqpcBau7eK75VKE0Yd06YxnUIsbcEzInUc3uzW/u0DFpXYkMJb0XIv JyUt5yYPKfV13N8kSkPi5pLxm8yuftXMzfgeFMR7nafY3glTVj/TxElzg6xeZNqf C2ZjIbBtZg9ylHU8u8wwB+dX282crs0R3N9A064C71/cXlBqcjzjlKH2NUIWGxr+ od3TXFIFjszSU3NgMPKrWNhFLLwS81MpbkOe73s6aDhS8RDyNucoxtKXriLR+4Xi u4+pyj5ukYP1JqpB3ZobY/XZgCnJMye+7xeTpIDJ1LPORxM3NNAElyb26lxAK2P+ km+EpI0Zzz6rNSCfg5jYQ474+e/GBgaSG4MlaPoZ+XAfN46u1Xjjv1/AkkA4IA6m 5zP5og=3D=3D =3D3NUt -----END PGP PUBLIC KEY BLOCK----- --------------020000050502020506010002-- --krGLwUc5aujQ7iKbJwsUcrenVRITb5bPM Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCgAGBQJTFgFsAAoJEMDeajWKOdxm+ucQAJF3osZ4KRWmos3D7x2VGHz/ QeJDq4612fe1zta3h+UgIAr5rb28FtywP8OXeMbaThzR2y63p8ur0NxIiGs4aOyM QNI/IcJGrOw9cf1Ssyv9wsnw3WG1ScQVhGjJ4sSLfCUHtMQLyGAokISp9aRSWN+I vg/eUL52fqbwsOh7LFjE2EFd6vMsWSQKoSnR6dHkCbM0Y/u6MAjEiwTGLCXjSUEZ Z9dMrRN82JfgkgP/G2TDabcAA14oabOTJ96eZAoBWlzZgzR9tlW7JCAm/DvFr6wd NyJMjCgpTa3L/qXuSD/ZT8tUrEHcjxfuMxNfABvFQbzhkh0x/MwoayP2vOHdQkur Z2lw7o+JEUpSQMPpR8i5ouoxGTIf4K8QymPgDTkffgY/nu6i6uDxfx1qayBUJk+W O2LsMSM9y0zstgu/AUKQyd+FEfc+dyZCkiKkW37cfGOQK6JMQGbawSWm44I9k4dD GYDqgMxVCEiBdSY7+XfPBMvtOsIYdzxlUbUgtMEEozNKxww/1GLX7jklKuDucJaX 4eKJhoHFws/C239Mt7rVmrnw/QF9VX0oomQVt3R0vPyokwxJo8TVwbKKyUbQqwlI Z7LMBcuJkpCMWaAJ1CNm97Crzs+r7oRTBe4fwSUszEC/3M4pZIH660RIHbXheB/5 2/PzOjI9UqGuSZNz9O1G =FoT+ -----END PGP SIGNATURE----- --krGLwUc5aujQ7iKbJwsUcrenVRITb5bPM--