Subject: Re: [netmod] New 6087bis issues - connect config - state - statistics

From: Randy Presuhn <[email-masked]>
Date: Fri, 3 Apr 2015 23:48:46 -0700 (GMT-07:00)

Hi -

>From: Andy Bierman <[email-masked]>
>Sent: Apr 3, 2015 7:55 PM
>To: Randy Presuhn <[email-masked]>
>Cc: "[email-masked]" <[email-masked]>
>Subject: Re: [netmod] New 6087bis issues - connect config - state -	statistics
>
>On Fri, Apr 3, 2015 at 11:43 AM, Randy Presuhn
><[email-masked]> wrote:
>> Hi -
>>
>>>From: Andy Bierman <[email-masked]>
>>>Sent: Apr 3, 2015 2:14 AM
>> ...
>>>Subject: Re: [netmod] New 6087bis issues - connect config - state - statistics
>> ...
>>>RESTCONF already has the 'content' query parameter that allows
>>>config, operational, or both.  This is good enough.
>>>It is trivial for you to add your own content filters to
>>>the RPC operations (if you want to prove that standards
>>>for more classifications are needed)
>>
>> I think you're setting a really low bar for "good enough,"
>> but recognize that this is a judgement call.
>>
>
>
>There have been proposals to the NETCONF WG
>several times to address the operational state issue
>in the NETCONF protocol.
>
>There was the <get2> operation in NETCONF-EX that
>added many new retrieval options.
>Martin proposed a <get-operational> RPC that could
>solve this problem. Phil suggested a new operational
>datastore at the IETF meeting instead of replicating datastore
>contents.
>
>Do you have a definition of "statistics" that everyone will
>understand so we can add some new YANG statement
>to pick between different kinds of config=false nodes?

You've just made the case for *not* building specific categories
into the modeling language itself.  The amount of angst
suffered in the process of figuring out "config false"
shows how hard it is even for the easy cases. I'm pessismistic
about the possibility that such categories could be defined or
standardized in the Yang world with sufficient precision
to be useful.

There have been a couple of different lines of argumentation
in this thread, but at their core they're all about the
extent to which the semantics of management information
are represented in machine-intelligible form, and the extent
to which common semantics / semantic relationships can be
exploited without requiring the services of an expensive
human expert.

It's a trade-off.  Putting those machine-intelligible
semantics into definitions of management information is
expensive and error-prone.  Relying on humans to code
those semantics into management applications is expensive
and error-prone.  Pick your poison.  :-)

I'm not going to argue that this would be the right thing
to do with Yang.  I'm just sticking with the observation
that the current toolbox seems to have an excellent selection
of hammers and not much else.  :-)

Randy

---

From: Rob Shakir <[email-masked]>
Date: Tue, 7 Apr 2015 11:58:07 +0100

Hi Randy,

> of hammers and not much else. :-)

These are both good points.

Speaking as someone that has responsibility for 10+ IP networks within an operator — I expect to write more implementations *against* the model than I expect to write versions of a model. I therefore prefer to make things easier and consistent for the guys writing the consuming code, and put the pain on the modeller at the time of model definition.

At the moment, the prevailing opinion I am taking from this list is that the proposal that we have put forward is ‘messy’ in terms of modelling — but as such, no real solutions to this that also keep the consistency for folks writing consuming applications are being proposed.

If taken here is to simply present a mish-mash of tools, and disapprove of them not being used in anything but a modelling-pure manner, then this will end up having unintended consequences for the relevance of this community to solving real-world problems IMHO. A bit blunt, but it’s how I see it.

Cheers,
r.

---

From: "Jonathan Hansford" <[email-masked]>
Date: Tue, 07 Apr 2015 12:39:59 +0100

I know it is an expired Internet-Draft, but
 draft-bjorklund-yang-requirements-00 states:

	YANG is designed to give priority to data model readers.  The
readers and reviewers of data models need insight into the
organization, constraints, and meaning of its elements...

	... YANG values the time and effort of the readers of models above
those of modules writers and YANG tool-chain developers...

	... Above all, the users of NETCONF models (operators) were given
highest priority in YANG's design.

	That would seem to place the needs of operators above those of module
readers or writers, yet the recent threads from operators would seem
to indicate that has not been the case, either with the design of YANG
or the modules written in YANG.

----- Original Message -----
From: "Rob Shakir" 
To:"Randy Presuhn" , "[email-masked]" 
Cc:
Sent:Tue, 7 Apr 2015 11:58:07 +0100
Subject:Re: [netmod] New 6087bis issues - connect config - state -
statistics

 Hi Randy,

 On 4 April 2015 at 07:48:57, Randy Presuhn
([email-masked]) wrote:
 > expensive and error-prone Relying on humans to code

 Speaking as someone that has responsibility for 10+ IP networks
within an operator — I expect to write more implementations
*against* the model than I expect to write versions of a model. I
therefore prefer to make things easier and consistent for the guys
writing the consuming code, and put the pain on the modeller at the
time of model definition.

 At the moment, the prevailing opinion I am taking from this list is
that the proposal that we have put forward is ‘messy’ in terms of
modelling — but as such, no real solutions to this that also keep
the consistency for folks writing consuming applications are being
proposed.

 If taken here is to simply present a mish-mash of tools, and
disapprove of them not being used in anything but a modelling-pure
manner, then this will end up having unintended consequences for the
relevance of this community to solving real-world problems IMHO. A bit
blunt, but it’s how I see it. 
 Cheers,
 r.

 _______________________________________________
 netmod mailing list
 [email-masked]
 https://www.ietf.org/mailman/listinfo/netmod