Re: configuration: writable MIB modules versus NETCONF/YANGmodules

----- Original Message -----
From: "Warren Kumari" <[email protected]>
To: "Benoit Claise" <[email protected]>
Cc: "t.petch" <[email protected]>; <[email protected]>
Sent: Tuesday, February 18, 2014 10:08 PM
> On Mon, Feb 17, 2014 at 7:25 PM, Benoit Claise <[email protected]>
wrote:
> > Hi Tom,
> >
> > The important questions are:
> > - will the writable aspects of the MIB module be implemented by the
vendors
> > (basically requested by the operators)?
>
> Who knows if it would be implemented by the vendors, but I'm sure most
> operators would refuse to use it.
> As a test I just proposed enabling SNMP write and got some good
> giggles (actually I got a "Good plan! Do  it with snmpv1, no one uses
> that.", but I'm not really able to convey the sarcasm / mocking tone
> in mail).
>
> I know of no large operator / network that allows write access -- I
> suspect that the risks are not really as bad as folk make out, but it
> has become network lore that snmp write is bad mojo and once something
> becomes lore...

I say again, go look at the mpls list, where
draft-ietf-mpls-tp-te-mib
has been returned to the WG to consider the question of making it
read-only, and several have spoken up against.  They are of course
speaking as individuals and are not speaking for operators, or
manufacturers, but they are a constituency in favour of writable MIB
modules.

And yes, I have in the past worked with enterprises who configure with
SNMP (with security provided other than by SNMP).

Tom Petch

> Things may be different in the enterprise space (I think ciscoworks
> tries to use snmp write). Oh, and Bay Network's Site Mangler used to
> -- which is why most people used BCC...
>
> W
>
>
>
> > - will the writable aspects be used by the NMS'?
> >
> > Regards, Benoit
> >
> >> ----- Original Message -----
> >> From: "Benoit Claise" <[email protected]>
> >> To: <[email protected]>
> >> Sent: Friday, February 14, 2014 12:39 AM
> >>>
> >>> 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.
> >>
> >> You probably know that there is currently a consensus call in
progress
> >> over
> >>
> >> "Please indicate Support or Oppose for this MIB
> >> (draft-ietf-mpls-tp-te-mib) to be read-only."
> >>
> >> and I was pleasantly surprised to see opposition, albeit with one
> >> opponent later changing their mind (perhaps they were sat on from a
> >> height:-).  I don't see much sign of Netxxxx in the mpls arena but
there
> >> is a need there for configuration, since there need not be a
control
> >> plane to set things up.  Perhaps writable MIB modules will still be
with
> >> us in the distant future in some corners of the Internet..
> >>
> >> Ideally, this idea would be fleshed out in an I-D.
> >>
> >> Tom Petch
> >>
> >>> Regards, the MIB doctors & Benoit
> >>
> >> .
> >>
> >
> > _______________________________________________
> > OPS-AREA mailing list
> > [email protected]
> > https://www.ietf.org/mailman/listinfo/ops-area
>