Re: [Netconf] Operational State: Re: New WGLC for a proposed new WG Charter - respond BEFORE Sept 1st

[Andy Bierman <[e-mail]>]

Interesting data point.

I meant that the SMI2YANG conversion of most MIB modules
is good enough, and a standards effort to rewrite them would take
too long.

Andy


On Wed, Sep 5, 2012 at 9:10 AM, Patrick Gili (pgili) <[e-mail]> wrote:
> Benoit,
>
> I fully support Andy's sentiments regarding NETCONF+YANG. I think it is fully capable of dealing with both configuration and operational data. However, the one point that I don't necessarily agree with his statement, "I don't think replacing standard monitoring MIBs with YANG modules is worth doing, but I would not classify SNMP as good for monitoring, and NETCONF as inappropriate for monitoring." We're receiving quite a different message from customers--in fact, we have customers expressing a desire to abandon everything for NETCONF, including syslog, SNMP, RADIUS, DHCP, RADIUS, and other protocols used today for the exchange of data.
>
> Patrick
>
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of Andy Bierman
> Sent: Wednesday, September 05, 2012 12:04 PM
> To: Benoit Claise (bclaise)
> Cc: netconf
> Subject: Re: [Netconf] Operational State: Re: New WGLC for a proposed new WG Charter - respond BEFORE Sept 1st
>
> On Wed, Sep 5, 2012 at 8:46 AM, Benoit Claise <[e-mail]> wrote:
>> Andy,
>>
>> I cut and pasted your answer into the right email thread, for readability:
>>
>> Andy> I hope we follow a process where we articulate and agree on
>> the problems we are attempting to solve, instead of the usual "here's
>> my solution draft, standardize it".
>>
>> No disagreement here. For the people interested in writing a draft on
>> the operational data (I believe I've seen some interest from Martin
>> and Lada), that's a good advice: let's define the problem statement.
>>
>> Andy> We also learned a thing or 2 about operational state with MIBs
>> over 20+ years and I hope we don't ignore that.  E.g., we have to pick
>> our discontinuity timestamp, such as /system/clock/current-datetime.
>> Some NETCONF systems have no SNMP agent, so sysUpTime is not
>> appropriate. Also <get> returns everything. That was a mistake from
>> the start. We could have <get2> return just config=false.  Simple.
>>
>> IMO the WG is looking for an ocean to boil wrt/ operational state, and
>> ignoring the little details that could make a difference right away.
>>
>>
>> Personally, one problem I see is: a WG charter including a entry for
>> management They might look at NETCONF/YANG, but then the next question
>> is: I have config data, but also operational state and counters. So is
>> NETCONF/YANG suitable?
>
>
> Companies are taking 2 different approaches (or a mix of both)
>   - mixing config=false data nodes with config=true nodes and using <get>
>   - creating custom RPC <get-foo> operations to provide specific data,
>     often matching CLI show commands
>
> IMO NETCONF can be even better than SNMP for monitoring, depending on the application and data model.  SNMP has no real filtering like subtree or XPath. (SNMP doesn't have real sub-trees, it has data scattered all over).  If the INDEX gets big (e.g., RMON2) then SNMP performance is awful, as the naming is 90% of the data, duplicated in every varbind.
>
> I don't think replacing standard monitoring MIBs with YANG modules is worth doing, but I would not classify SNMP as good for monitoring, and NETCONF as inappropriate for monitoring.
>
>>
>> Regards, Benoit
>>
>
>
> Andy
>
>> + 1
>>
>> Regards, Benoit.
>>
>> We had agreed in our last f2f meeting that people would submit
>> individual I-Ds, and based on that we would potentially consider work
>> in this space. So by all means do submit such individual drafts and
>> discuss them on the mailing list.
>>
>> But we do not have a good problem statement or starting I-D to base
>> this work on, so cannot put it on the current charter.
>>
>> Bert Wijnen
>>
>> On 8/17/12 11:04 AM, Ladislav Lhotka wrote:
>>
>> Hi,
>>
>> I had the impression that there was a reasonable agreement that work
>> on operational state data is needed. Although this problem lies
>> somewhere between NETCONF and NETMOD, I think the NETCONF WG is now in
>> a better position to start this work because apparently NETMOD WG will
>> have to continue the work on the core data models for some time.
>>
>> So I propose the following fourth item for the charter:
>>
>> 4. The WG will investigate the relationship and interactions between
>> configurations and
>>     operational state data, propose their appropriate representation
>> and semantics, and
>>     devise methods for effective data modeling of both configurations
>> and operational state data.
>>     It is expected that this work will be carried out in a close
>> sooperation with the NETMOD WG.
>>
>> Lada
>>
>> "Bert Wijnen (IETF)" <[e-mail]> writes:
>>
>> Based on the comments and feedback and the positions expressed on the
>> mailing list, it is clear that after all we did NOT have consensus on
>> the new WG charter.
>>
>> Without further ado, this is another proposed WG charter.
>> It focuses on the things that we do seme to have agreement on.
>>
>> Pls comment and/or express your support or objections no later than
>> August 31, 2012.
>>
>> OK, new chapter text (omitting the description of what we have
>> achieved sofar):
>>
>>     In the current phase of the incremental development of NETCONF the
>>     workgroup will focus on following items:
>>
>>     1. Advance NETCONF over TLS to be in-line with NETCONF 1:1.
>>        This means that RFC5593 needs to be updated.
>>
>>     2. Based on the implementation, deployment experience and
>> interoperability
>>        testing, the WG will document the status of NETCONF in a report.
>>        Based on this, the WG may decide to make some clarifications to
>>        RFC6241 and RFC6242 (then also fixing any reported errata).
>>
>>     3. Since Netconf over BEEP and over SOAP seem not being deployed
>>        the WG will write a document that makes those 2 protocols
>>        (RFC4743 and RFC4744) HISTORIC.
>>
>> Goals and Milestones:
>>     done     - Send with-defaults to IESG for consideration as Proposed
>> Standard
>>     done     - WG Last Call on rfc4741bis
>>     done     - rfc4741bis to IESG for consideration as Proposed Standard
>>     done     - Send rfc4742bis to IESG for consideration as proposed
>> Standard.
>>     done     - first WG draft (rev 00) on NACM posted
>>     done     - first WG draft (rev 00) on NETCONF specific YANG modules
>> posted
>>     done     - WGLC for NACM document
>>     done     - WGLC for NETCONF specific notifications document
>>     done     - submit NACM document to IESG for consideration as Proposed
>> Standard
>>     done     - submit NETCONF specific notifications  document to IESG for
>>                consideration as Proposed Standard
>>     Aug 2012 - submit initial WG draft for rfc5539bis
>>     Aug 2012 - submit initial WG draft for making RFC4743 and RFC4744
>> historic.
>>     Sep 2012 - WGLC for rfc5539bis
>>     Sep 2012 - WGLC for RFC4743 and 4743 to historic
>>     Oct 2012 - submit rfc5539bis to AD/IESG for consideration as
>> Proposed Standard
>>     Oct 2012 - submit request to AD/IESG to make RFC4743 and 4744 historic
>>     Nov 2012 - Collect Implementation/Deployment reports for RFC6241
>> and
>> 6242
>>     Dec 2012 - Initial I-D for RFC6241/6242 implementation/deployment
>> experience
>>     Jan 2013 - WGLC on RFC6241/6242 implementation/deployment experience
>>     Feb 2013 - submit RFC6241/6242 implementation/deployment experience doc
>>                to IESG for publication as Informational RFC.
>>     Mar 2013 - Evaluate if more work needs to be done by NETCONF WG or
>> close WG
>>
>> Bert and Mehmet
>> _______________________________________________
>> Netconf mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/netconf
>>
>>
>> _______________________________________________
>> Netconf mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/netconf
>>
>>
>>
>> _______________________________________________
>> Netconf mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/netconf
>>
>>
>>
> _______________________________________________
> Netconf mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netconf