Subject: [Netconf] NETCONF Draft Charter discussion WAS:RE: health of NETCONF

From: "Mehmet Ersue" <[email-masked]>
Date: Thu, 2 Mar 2017 23:35:43 +0100

Dear Tom, Rob, All,

Thank You for the valuable discussion.

I think we need to be aware that we have two different WGs with different charter definition and targets. Because of the related and dependent topics in development, naturally the attendance is overlapping. However, this overlapping is only partly and the fact that a few key player are attending both WGs does not mean the topics and charters are interchangeable freely. 

Basically NETMOD WG is chartered to develop mainly the YANG modeling language (as the WG title "NETCONF Data Modeling Language" says), its extensions and guidance documents as well as essential YANG modules. OTOH NETCONF WG has been established to develop the standards for configuration protocols and the required network configuration framework on which the protocols are operated.

In case of RFC 6244 it didn’t matter really in which WG it was done, as this document was trying to bring NETCONF and YANG into relation with an informational overview. This overview has been prepared after the finalization of the related standard documents. In case of the datastore concept draft it doesn’t matter too, as this is IMO again a concept proposal and informational in nature. Based on this, we the NETCONF chairs agreed to have the datastore concept information draft developed in NETMOD WG.

However when it comes to the standardization of the network configuration framework and the revision of current NETCONF/RESTCONF standards concerning datastore handling from protocol pov. it does matter where it is done.

We wrote into the draft charter proposal what we think is required from the pov. of NETCONF WG (unfortunately this couldn’t be aligned with NETMOD co-chairs before going to the ML). The reason for point 6) is the fact that the current NETCONF datastore concept in RFC 6241 needs to be revised and we need a normative reference addressing  NC/RC concerns and protocol-specific implications. 

We fully agree that the timing and work split between 6241bis/8040bis and 7950bis is essentially important and requires an alignment. But this is business as usual.

Best Regards,

Mehmet & Mahesh

From: Andy Bierman [mailto:[email-masked]] 
Sent: Wednesday, March 1, 2017 4:40 PM
To: t.petch <[email-masked]>
Cc: Juergen Schoenwaelder <[email-masked]>; Mehmet Ersue <[email-masked]>; Robert Wilton <[email-masked]>; Netconf <[email-masked]>
Subject: Re: [Netconf] health of NETCONF

On Wed, Mar 1, 2017 at 3:04 AM, t.petch <[email-masked] <mailto:[email-masked]> > wrote:

From: "Robert Wilton" <[email-masked] <mailto:[email-masked]> >
Sent: Wednesday, March 01, 2017 10:45 AM
> Hi Tom,
>
> On 01/03/2017 09:58, t.petch wrote:
> > ----- Original Message -----
> > From: "Juergen Schoenwaelder" <[email-masked] <mailto:[email-masked]> 
> > 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.

I think this is getting done.

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.

If you mean an update to RFC 6244 would be useful, then I agree

Tom Petch

Andy

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

_______________________________________________
Netconf mailing list
[email-masked] <mailto:[email-masked]> 
https://www.ietf.org/mailman/listinfo/netconf