Re: [Netconf] Draft Charter Proposal for NETCONF WG

[Andy Bierman <[e-mail]>]

On Thu, Mar 9, 2017 at 4:12 AM, t.petch <[e-mail]> wrote:

> ----- Original Message -----
> From: "Robert Wilton" <[e-mail]>
> Sent: Friday, March 03, 2017 5:41 PM
>
> > On 03/03/2017 17:18, t.petch wrote:
> > > ----- Original Message -----
> > > From: "Mehmet Ersue" <[e-mail]>
> > > Sent: Friday, March 03, 2017 2:33 PM
> > >
> > >>> Back to your question, it seems obvious to me that YANG and the
> XML
> > >> encoding rules naturally belong to NETMOD, the 'NETCONF protocol
> > > details
> > >> that NETCONF
> > >>> did not define' naturally belong to NETCONF.
> > >> Basically it is our aim to make the YANG language specification
> > > generally
> > >> applicable to all protocols and to put protocol-specific details
> into
> > > the
> > >> protocol specifications.
> > > See my response to Juergen; I agree with you but I define XML as not
> > > being a protocol and so XML would remain; and I think that YANG will
> > > have to say something about operations on the data it defines, just
> that
> > > they are defined as an abstract 'create', 'delete' etc and not as
> the
> > > set that NETCONF currently offers.
> > FWIW, this is the block
> > "      Common protocol abstraction
> > (that all YANG protocols should conform to). "
> >
> > That I was referring to in the diagram that I gave previously,
> although
> > I was suggesting that should belong in NETCONF WG rather than in YANG.
>
> Robert
>
> It has taken me a while to work out what you mean but now I have, I
> disagree!
>
> You seem to place data(stores) at the heart of things, the root from
> which all else flows.  I think that this can work with application
> software in a stable, secure, delay-less environment where nothing ever
> goes wrong (a mobile phone app perhaps!).
>
> Network management is different;  the failing network is both the
> subject under consideration and an integral part of the solution.  The
> operator has to use the failing network to find out what is failing and
> what might be done about it and then use the failing network to convey
> changes to the failing component of the network.  SNMP recognised this
> but I am not sure the NETCONF/YANG do - after all, their focus is on
> configuration, before things start going wrong.
>
>
I don't know if NETCONF or RESTCONF will ever be suitable as a replacement
for SNMP wrt/ functioning in a broken network. TCP and SSH need to function
first, before any network management can start. That's why some of us are
looking
at CoMI as a replacement for SNMP.

NETCONF is designed to be a resource hog running on a stable network.


> I see revised-datastores as an attempt to fix this but one that will
> fail, in the sense that it cannot go far enough; what may be needed is a
> paradigm shift in Computer Science so a server can say that the model it
> has been given cannot reflect reality but here is a better one freshly
> created for the client to use!
>

This might work in an open system, but I have not seen this trend in
routers.
Our server can automatically load/unload modules or module bundles
at runtime, but vendors are not really using it because it doesn't fit
their QA model.
They want to test monolithic images, not modular systems that can be
changed by
the operator at run-time.

The DS work takes care of some corner cases, but does nothing to make
NETCONF
100% suitable for network management.




>
> I don't see that happening just yet so revised-datastores will have to
> do but I think it wrong to make that central - it will not be close
> enough to reality.
>
> Tom Petch
>


Andy


>
> > Rob
> >
> > > Tom Petch
> > >
> > >> Mehmet
> > >>
> > >>> -----Original Message-----
> > >>> From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-
> > >>> university.de]
> > >>> Sent: Friday, March 3, 2017 2:35 PM
> > > <snip>
> > >
> > > _______________________________________________
> > > Netconf mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/netconf
> > > .
> > >
> >
>
> _______________________________________________
> Netconf mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netconf
>