Re: [Netconf] Draft Charter Proposal for NETCONF WG

Andy Bierman <andy@yumaworks.com> writes:

> On Wed, Mar 1, 2017 at 4:01 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
>
>>
>> > On 1 Mar 2017, at 10:58, t.petch <ietfc@btconnect.com> wrote:
>> >
>> >
>> > ----- Original Message -----
>> > From: "Juergen Schoenwaelder" <j.schoenwaelder@jacobs-university.de>
>> > To: "Mehmet Ersue" <mersue@gmail.com>
>> > Cc: "'Netconf'" <netconf@ietf.org>
>> > 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 think that the rush to  get
>> > draft-ietf-netmod-revised-datastores
>> > out is militating against the long term health of NETCONF.
>> >
>>
>> I agree, and I would also add draft-ietf-netmod-schema-mount to it (of
>> which I am a co-author).
>>
>> Original NETCONF and YANG were limited but (mostly) coherent and, in a
>> way, simple and elegant. The recent developments are afterthoughts and
>> kitchen sinks that will destroy these qualities.
>>
>> Instead of rushing with these documents, we should step back and think
>> about a new architecture that could consistently support the new
>> requirements.
>>
>>
> I think the entire approach to virtual servers is too complicated with
> schema-mount.

As I see it, schema mount is primarily intended as another tool for
constructing the overall data model from YANG modules, along with
augments and YANG library. 

> Instead of keeping the protocol fixed and playing tricks with the data tree,
> it might be better to keep the current YANG we have, and enhance
> the protocols in order to access virtual servers from the 'real'
> server.

This sounds more like data mount, not schema mount. Actually, I'd argue
that virtual servers, and in general the "inline" method in the
schema-mount draft, are all about instance data, a part of which happens
to be a new instance of YANG library.

Lada

>
>
> Lada
>>
>
>
> Andy
>
>
>>
>>
>> > Tom Petch
>> >
>> >> /js
>> >>
>> >> --
>> >> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
>> >> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
>> >> Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>
>> >>
>> >> _______________________________________________
>> >> Netconf mailing list
>> >> Netconf@ietf.org
>> >> https://www.ietf.org/mailman/listinfo/netconf
>> >
>> > _______________________________________________
>> > Netconf mailing list
>> > Netconf@ietf.org
>> > https://www.ietf.org/mailman/listinfo/netconf
>>
>> --
>> Ladislav Lhotka, CZ.NIC Labs
>> PGP Key ID: 0xB8F92B08A9F76C67
>>
>>
>>
>>
>>
>> _______________________________________________
>> Netconf mailing list
>> Netconf@ietf.org
>> https://www.ietf.org/mailman/listinfo/netconf
>>

-- 
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67