Re: [Netconf] Draft Charter Proposal for NETCONF WG

[t.petch <[e-mail]>]

----- 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 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!

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

> 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
> > .
> >
>