Re: [Netconf] health of NETCONF

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

----- Original Message -----
From: "Robert Wilton" <[e-mail]>
Sent: Wednesday, March 01, 2017 11:38 AM

> On 01/03/2017 11:04, t.petch wrote:
> > From: "Robert Wilton" <[e-mail]>
> > Sent: Wednesday, March 01, 2017 10:45 AM
> >>
> >> On 01/03/2017 09:58, t.petch wrote:
> >>> ----- Original Message -----
> >>> From: "Juergen Schoenwaelder"
<[e-mail]
> >>> Sent: Monday, February 27, 2017 10:14 PM
> >>>> On Mon, Feb 27, 2017 at 09:44:06PM +0100, Mehmet Ersue wrote:
> >>>>
> >>>>> 6. Revise the current NETCONF datastore concept as a protocol-
and
> >>> modeling
> >>>>> language-independent standard as part of the network
configuration
> >>>>> framework. Use the datastore solution proposal in
> >>>>> draft-ietf-netmod-revised-datastores as its basis. Will be used
as
> > a
> >>>>> normative reference in protocol specifications.
> >>>> There is no point in dupliating work in WGs that have a common
> > history
> >>>> and a common set of active contributors.
> >>> Juergen
> >>>
> >>> I am not sure what you are proposing;  Currently, datastores are
> > poorly
> >>> described in RFC6241 and RFC7950 and the publication of another
> >>> incomplete description in the shape of
> >>> draft-ietf-netmod-revised-datastores
> >>> will likely make things worse.
> >>>
> >>> I see a need for a datastores RFC, probably separate from the
> > current
> >>> specifications, and do see the NETCONF WG as better placed to do
it.
> >> I see that datastores and YANG are directly linked.  Specifically,
I
> >> think that the "config" statement, and any future I2RS related
> >> "ephemeral" statement (or extension) give the data nodes in a YANG
> > data
> >> model particular semantics in the different datastores.
> >>
> >> So, I sort of see the document hierarchy should be something like:
> >>
> >>      Datastores architecture
> >>               ^
> >>               |                    (NETMOD WG)
> >>          YANG language
> >>          ^          ^
> >>          |          |
> >>          |   Encodings of YANG data trees
> >>          |               (XML, JSON, CBOR)
> >>          |                    ^
> >>     -  - |-  -  -  -  -  -  - |-  -  -  -  -  -
> >>          |                    |    (NETCONF WG)
> >>       Common protocol abstraction
> >> (that all YANG protocols should conform to).
> >>       ^             ^            ^
> >>       |             |            |
> >>    RESTCONF      NETCONF        CoMI
> >>
> >> So, for the split of work between NETMOD and NETCONF, my thoughts
are
> >> that basically the work above the dotted line should be done in
> > NETMOD,
> >> and the work below the line should be done in NETCONF.  Of course,
> > some
> >> of the work may be done in other WGs (CoMI, I2RS, etc).
> >>
> >>> I think that the rush to  get
> >>> draft-ietf-netmod-revised-datastores
> >>> out is militating against the long term health of NETCONF.
> >> Please can you clarify, do you mean long term health of the NETCONF
> > WG,
> >> or the NETCONF RFC, or the NETCONF protocol?
> > I mean NETCONF the means of doing network configuration, so that
> > includes the protocol as defined in RFC6241, datastores as defined
in
> > RFC6241 and the existence of a data modelling language and data
models
> > written therein.  Essentially, the problem that the NETCONF WG was
set
> > up to solve.
> >
> > The weakness I see is the lack of a Standards Track architecture or
> > framework or some such which would likely have datastores at its
heart;
> > and, unlike you, I see the expertise for that in the NETCONF WG and
not
> > in the NETMOD WG.
>
> OK.  I had, perhaps incorrectly, assumed that the same experts are
> participating in both WGs, and the split was more for a division of
> labour rather than differing areas of expertise.

Robert

There is another practical reason for me.  NETCONF is a 'friendly' list
where I get any e-mail thereon next time I logon, which is most days a
week.  NETMOD is different.  I am currently up-to-date, but only for the
first time in a month; some times I am months behind and thinking I
could have contributed to that if only the topic were not several
hundred e-mails further on by now.  So anything on NETCONF I have the
chance to contribute to; NETMOD de facto I do not.

Tom Petch

> Rob
>
>
> >
> > Tom Petch
> >
> >> Thanks,
> >> Rob
> >>
> >>
> >>> Tom Petch
> >>>
> >>>> /js
> >>>>
> > .
> >
>