}
Is all this leading up to a draft? ;)
Kent // contributor
*From: *Robert Wilton
*Date: *Monday, December 12, 2016 at 6:10 AM
*To: *Kent Watsen , Andy Bierman
*Cc: *"netmod@ietf.org"
*Subject: *Re: [netmod] Modelling different "levels" of data in YANG
Hi Kent,
? ;)
Kent // contributor
*From: *Robert Wilton
*Date: *Monday, December 12, 2016 at 6:10 AM
*To: *Kent Watsen , Andy Bierman
*Cc: *"netmod@ietf.org"
*Subject: *Re: [netmod] Modelling different "levels" of data in YANG
Hi Kent,
On 10/12/2016 00:59, Kent Watsen wrote:
>
ing different "levels" of data in YANG
Hi Kent,
On 10/12/2016 00:59, Kent Watsen wrote:
> I prefer not to use specialized operations.
Agreed, I was thinking something more along the lines of:
<--- note this flag here
Hi Kent,
On 10/12/2016 00:59, Kent Watsen wrote:
> I prefer not to use specialized operations.
Agreed, I was thinking something more along the lines of:
<--- note this flag here
http://example.com/schema/1.2/config";>
Hi Andy,
On 09/12/2016 18:50, Andy Bierman wrote:
Why can't you use a when-stmt?
system
...
// config false
// when "/top/diag-mode = 'system'"
A when statement has two problems:
i) It affects all clients that are
> I prefer not to use specialized operations.
Agreed, I was thinking something more along the lines of:
<--- note this flag here
http://example.com/schema/1.2/config";>
T
On Fri, Dec 9, 2016 at 1:02 PM, Kent Watsen wrote:
>
>
>
>
> > Why can't you use a when-stmt?
>
> >
>
> >
>
> > system
>
> >
>
> > ...
>
> >
>
> >// config false
>
> >// when "/top/diag-mode = 'system'"
>
> >
>
> >
>
> >
>
>
>
>
>
> Why can't you use a when-stmt?
>
>
> system
>
> ...
>
>// config false
>// when "/top/diag-mode = 'system'"
>
>
>
Can we have a solution that is session-oriented, like with-defaults? Maybe
the ‘when’ expression’s context cou
On Fri, Dec 9, 2016 at 10:10 AM, Robert Wilton wrote:
>
>
> On 09/12/2016 15:17, Martin Bjorklund wrote:
>
>> Robert Wilton wrote:
>>
>>>
>>> On 09/12/2016 12:06, Juergen Schoenwaelder wrote:
>>>
On Fri, Dec 09, 2016 at 11:25:35AM +, Robert Wilton wrote:
> Even if they don't br
On 09/12/2016 15:17, Martin Bjorklund wrote:
Robert Wilton wrote:
On 09/12/2016 12:06, Juergen Schoenwaelder wrote:
On Fri, Dec 09, 2016 at 11:25:35AM +, Robert Wilton wrote:
Even if they don't break, debug and diagnostics information can be
very
verbose.
If a client had 4 connections
Robert Wilton wrote:
>
>
> On 09/12/2016 12:06, Juergen Schoenwaelder wrote:
> > On Fri, Dec 09, 2016 at 11:25:35AM +, Robert Wilton wrote:
> >> Even if they don't break, debug and diagnostics information can be
> >> very
> >> verbose.
> >>
> >> If a client had 4 connections to a device for
On 09/12/2016 12:06, Juergen Schoenwaelder wrote:
On Fri, Dec 09, 2016 at 11:25:35AM +, Robert Wilton wrote:
Even if they don't break, debug and diagnostics information can be very
verbose.
If a client had 4 connections to a device for monitoring different things,
then you don't want to s
On Fri, Dec 09, 2016 at 11:46:39AM +, Robert Wilton wrote:
> Hi Juergen,
>
> Please can you expand on your proposed solution if using just one NACM
> entry.
Perhaps we talk past each other because 'NACM entry' is ambiguous. I mean
one 'rule-list' entry, you probably mean N 'rule' entries.
>
On Fri, Dec 09, 2016 at 11:25:35AM +, Robert Wilton wrote:
>
> Even if they don't break, debug and diagnostics information can be very
> verbose.
>
> If a client had 4 connections to a device for monitoring different things,
> then you don't want to suddenly start sending a large amount of ex
Hi Juergen,
On 09/12/2016 11:19, Juergen Schoenwaelder wrote:
On Fri, Dec 09, 2016 at 10:54:14AM +, Robert Wilton wrote:
Assuming that diagnostics information was specified for each of N different
protocols on a device. Then this would seem to mean that every device would
have to install
> On 9 Dec 2016, at 12:05, Robert Wilton wrote:
>
>
>
> On 09/12/2016 10:54, Ladislav Lhotka wrote:
>>> On 9 Dec 2016, at 11:48, Robert Wilton wrote:
>>>
>>> Hi Lada,
>>>
>>>
>>> On 09/12/2016 10:33, Ladislav Lhotka wrote:
Hi Rob,
I didn't follow the previous discussion clo
On 09/12/2016 11:16, Juergen Schoenwaelder wrote:
On Fri, Dec 09, 2016 at 11:05:47AM +, Robert Wilton wrote:
OK, so this is closer, but still would mean that enabling the debug flag via
RPC would potentially cause all clients to start to see the diagnostics
information (which may break the
On Fri, Dec 09, 2016 at 10:54:14AM +, Robert Wilton wrote:
>
> Assuming that diagnostics information was specified for each of N different
> protocols on a device. Then this would seem to mean that every device would
> have to install N default NACM deny entries (one for each supported
> prot
On Fri, Dec 09, 2016 at 11:05:47AM +, Robert Wilton wrote:
>
> OK, so this is closer, but still would mean that enabling the debug flag via
> RPC would potentially cause all clients to start to see the diagnostics
> information (which may break them).
>
A client that breaks when receiving unk
On 09/12/2016 10:54, Ladislav Lhotka wrote:
On 9 Dec 2016, at 11:48, Robert Wilton wrote:
Hi Lada,
On 09/12/2016 10:33, Ladislav Lhotka wrote:
Hi Rob,
I didn't follow the previous discussion closely but a natural solution
seems to be to define a leaf like "debug" - it could be just boolea
> On 9 Dec 2016, at 11:48, Robert Wilton wrote:
>
> Hi Lada,
>
>
> On 09/12/2016 10:33, Ladislav Lhotka wrote:
>> Hi Rob,
>>
>> I didn't follow the previous discussion closely but a natural solution
>> seems to be to define a leaf like "debug" - it could be just boolean or
>> an enumeration o
On 08/12/2016 19:11, Juergen Schoenwaelder wrote:
On Thu, Dec 08, 2016 at 05:49:11PM +, Robert Wilton wrote:
On 07/12/2016 16:13, Juergen Schoenwaelder wrote:
On Wed, Dec 07, 2016 at 02:39:00PM +, Robert Wilton wrote:
Alas, xpath filtering is optional, and I'm not sure how many devic
Hi Lada,
On 09/12/2016 10:33, Ladislav Lhotka wrote:
Hi Rob,
I didn't follow the previous discussion closely but a natural solution
seems to be to define a leaf like "debug" - it could be just boolean or
an enumeration of debug levels. And then add the diagnostic
data as an augment that condit
Hi Rob,
I didn't follow the previous discussion closely but a natural solution
seems to be to define a leaf like "debug" - it could be just boolean or
an enumeration of debug levels. And then add the diagnostic
data as an augment that conditionally depends on the value of the
"debug" leaf.
Would
On Thu, Dec 08, 2016 at 05:49:11PM +, Robert Wilton wrote:
>
> On 07/12/2016 16:13, Juergen Schoenwaelder wrote:
> > On Wed, Dec 07, 2016 at 02:39:00PM +, Robert Wilton wrote:
> > > Alas, xpath filtering is optional, and I'm not sure how many devices have
> > > implemented support for it.
On 07/12/2016 16:13, Juergen Schoenwaelder wrote:
On Wed, Dec 07, 2016 at 02:39:00PM +, Robert Wilton wrote:
Alas, xpath filtering is optional, and I'm not sure how many devices have
implemented support for it. Further, this still requires every client to be
coded to avoid receiving the in
On Wed, Dec 07, 2016 at 02:39:00PM +, Robert Wilton wrote:
>
> Alas, xpath filtering is optional, and I'm not sure how many devices have
> implemented support for it. Further, this still requires every client to be
> coded to avoid receiving the information that they are very unlikely to be
>
Hi,
On 07/12/2016 13:30, Vladimir Vassilev wrote:
On 12/06/2016 10:03 PM, Alex Campbell wrote:
IMO using an action or rpc is an okay solution for now, certainly
better than than not including the data at all.
If I have to chose between RPC with 'output' containing the state data
for select
On 12/06/2016 10:03 PM, Alex Campbell wrote:
IMO using an action or rpc is an okay solution for now, certainly
better than than not including the data at all.
If I have to chose between RPC with 'output' containing the state data
for selected interface and mapping the data to a container/list
On Wed, Dec 07, 2016 at 12:25:59PM +0100, Vladimir Vassilev wrote:
> On 12/06/2016 10:40 PM, Juergen Schoenwaelder wrote:
>
> > I fear that a dumb client sending a without a proper filter to
> > select the data that is relevant for the client will not necessarily
> > get smarter by defining addit
On 12/06/2016 10:40 PM, Juergen Schoenwaelder wrote:
I fear that a dumb client sending a without a proper filter to
select the data that is relevant for the client will not necessarily
get smarter by defining additional operations.
Sometimes access control can help to control dumb clients that
7;s "hide groups", but it's hard to
> see how those would be extended to support programmatic interfaces.
>
>
>
> From: netmod on behalf of Robert Wilton
>
> Sent: Wednesday, 7 December 2016 3:58 a.m.
> To: Athanasios Kypar
From: Athanasios Kyparlis
Sent: Tuesday, December 6, 2016 4:06 PM
To: 'Alex Campbell' ; Robert Wilton
; netmod@ietf.org
Subject: RE: [netmod] Modelling different "levels" of data in YANG
To answer Rob's question (if I understand it correctly), the client would know
th
t's hard to see
how those would be extended to support programmatic interfaces.
From: netmod on behalf of Robert Wilton
Sent: Wednesday, 7 December 2016 3:58 a.m.
To: Athanasios Kyparlis; netmod@ietf.org
Subject: Re: [netmod] Modelling different "levels"
Hi Vladimir,
Thanks for your suggestion. Please see some comments inline ...
On 06/12/2016 10:34, Vladimir Vassilev wrote:
On 12/05/2016 07:10 PM, Robert Wilton wrote:
Hi,
We are currently working on modelling 802.3 Ethernet YANG within the
802.3 YANG study group.
One interesting issue t
On 12/05/2016 07:10 PM, Robert Wilton wrote:
Hi,
We are currently working on modelling 802.3 Ethernet YANG within the
802.3 YANG study group.
One interesting issue that has come up is the scope of the operational
state data that could be modeled:
At the top level, an operator may just wan
Hi,
We are currently working on modelling 802.3 Ethernet YANG within the
802.3 YANG study group.
One interesting issue that has come up is the scope of the operational
state data that could be modeled:
At the top level, an operator may just want to know whether an Ethernet
interface is up
37 matches
Mail list logo
