Re: configuration: writable MIB modules versus NETCONF/YANG modules

----- Original Message -----
From: "Benoit Claise" <[email protected]>
To: "Andy Bierman" <[email protected]>; "ietfdbh" <[email protected]>
Cc: <[email protected]>
Sent: Tuesday, February 18, 2014 12:38 AM

> Dear all,
>
> As pointed by Simon, Jürgen, Dan, Bert, Joan, yes, it was a feature
not
> to speak about monitoring in this statement. If we do, then why not
> Fault, Accounting, Performance?

Because we already have 45 pages gently maturing on the topic
(draft-ietf-opsawg-oam-overview)?

I think that that I-D well demonstrates the challenges of producing
satisfactory guidance on the work of the IETF.

Tom Petch

> If we take on the task to specify all FCAP aspects, this will be too
big
> of a job for an IESG statement. However, as I mentioned multiple
times,
> I'll work on this ... I have 2 years (to try) to achieve that. I
foresee
> a lot of discussions.
>
> So, I would prefer to keep this statement purely for configuration.
>
> Regards, Benoit.
> > Hi,
> >
> > Note that none of the people asking for more text have provided any
> > proposed changes.
> >
> >    WGs should use the monitoring protocol(s) that best fit their
> > requirements.
> >
> > How's that?
> >
> > Not sure it is worth the effort to create a cookbook
> > for all possible requirements that could occur, or
> > try to give meaningful guidance in 1 or 2 sentences.
> >
> >
> > Andy
> >
> > On Mon, Feb 17, 2014 at 3:40 PM, ietfdbh <[email protected]
> > <mailto:[email protected]>> wrote:
> >
> >     I don't think remaining silent is a feature, when WGs have asked
for
> >     guidance.
> >
> >     David Harrington
> >     [email protected] <mailto:[email protected]>
> >     +1-603-828-1401
> >     > -----Original Message-----
> >     > From: OPS-AREA [mailto:[email protected]
> >     <mailto:[email protected]>] On Behalf Of Dave
> >     > Thaler
> >     > Sent: Monday, February 17, 2014 2:23 PM
> >     > To: Juergen Schoenwaelder; Simon Leinen
> >     > Cc: [email protected] <mailto:[email protected]>
> >     > > -----Original Message-----
> >     > > From: OPS-AREA [mailto:[email protected]
> >     <mailto:[email protected]>] On Behalf Of Juergen
> >     > > Schoenwaelder
> >     > > Sent: Monday, February 17, 2014 1:54 AM
> >     > > To: Simon Leinen
> >     > > Cc: [email protected] <mailto:[email protected]>
> >     > >
> >     > > On Mon, Feb 17, 2014 at 10:39:26AM +0100, Simon Leinen
wrote:
> >     > > > Benoit Claise writes:
> >     > > > > 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.
> >     > > >
> >     > > > Agree - it's time for such a statement, and this is a good
one.
> >     > > > It doesn't make any recommendations about monitoring or
> >     notifications.
> >     > > > I think that (absence) is also appropriate at this point.
> >     > >
> >     > > I agree that it is a feature to be silent about things this
> >     statement is
> >     not
> >     > > talking about.
> >     > >
> >     > > /js
> >     >
> >     > It may be a feature to the OPS area, but it is not a feature
as
> >     far as the
> >     > audience
> >     > of the statement is concerned (I speak as one of the latter,
and
> >     one who's
> >     > asked
> >     > for a statement about notifications).
> >     >
> >     > It sounds like the silence is due to lack of any consensus or
simple
> >     answer.
> >     > The lack of a simple consensus answer is a problem, not a
feature.
> >     > But that's the current world we live in.
> >     >
> >     > -Dave