Anees,
does it really make sense to have to track multiple different objects
in order to find out which IP address(es) are used by an interface?
Perhaps I am old school but I do like the existing design better - one
place to find the operationally used state. I rather have additional
_metadata_ ab
On Wed, Jun 24, 2015 at 7:57 PM, Anees Shaikh wrote:
> Hi Kent,
>
>
>
>
>>
>>
>>
>> > If I can make some slight tweaks to the diagrams that have
>> > been distributed:
>>
>> This looks like a variant of the picture I posted here:
>> http://www.ietf.org/mail-archive/web/netmod/current/msg12738.ht
On Wed, Jun 24, 2015 at 06:39:44PM +0100, Rob Shakir wrote:
> A portion of the operational state date (marked operational: true)
> is the set of variables that are not related to state that an
> external system can assert the value of — for example, a counter, or
> a negotiated protocol timer.
No
>>>Here's the updated table:
>> >
>> > running actual configoperational state
>> > --- --
>> > t0halfhalf half
>> > t1autohalf half
>> > t2autohalf (*)
On Wed, Jun 24, 2015 at 2:14 PM, Martin Bjorklund wrote:
> Hi,
>
> I am preparing a new version of draft-ietf-netmod-rfc6020bis in order
> to address Y45-04. Note that YANG 1.1 uses the module
> ietf-yang-library from draft-ietf-netconf-yang-library (hence the
> crossposting).
>
> [BTW, shouldn'
Hi,
I am preparing a new version of draft-ietf-netmod-rfc6020bis in order
to address Y45-04. Note that YANG 1.1 uses the module
ietf-yang-library from draft-ietf-netconf-yang-library (hence the
crossposting).
[BTW, shouldn't ietf-yang-library be moved to NETMOD?]
We have a whole bunch of docume
Anees Shaikh wrote:
> Our understanding of the table is that it assumes you have an additional
> state leaf to reflect the negotiated mode (i.e., operational state
> negotiated by protocol) that would be reflected as the "operational" value.
Yes, in this example that is correct. If we agree on t
On Wed, Jun 24, 2015 at 1:10 PM, Martin Bjorklund wrote:
> Kent Watsen wrote:
> >
> > Hi Martin,
> >
> >
> > >Here's the updated table:
> > >
> > > running actual configoperational state
> > > --- --
> > > t0halfhalf
Kent Watsen wrote:
>
> Hi Martin,
>
>
> >Here's the updated table:
> >
> > running actual configoperational state
> > --- --
> > t0halfhalf half
> > t1autohalf half
> > t2
Hi,
Rob Shakir wrote:
> Thanks very much to everyone that has considered the problem that we laid out
> on the last interim call. I think we’re starting to reach a common
> understanding.
As Andy pointed out, there is some overlap in what you describe below
with how NETCONF already works. This
Hi Martin,
>Here's the updated table:
>
> running actual configoperational state
> --- --
> t0halfhalf half
> t1autohalf half
> t2autohalf (*) half
>
[As an individual contributor]
Hi Rob and OC team,
> Thanks very much to everyone that has considered the problem
> that we laid out on the last interim call. I think we¹re
> starting to reach a common understanding.
Indeed!
> If I can make some slight tweaks to the diagrams that have
> bee
Hi Andy,
Yes, I’m definitely aware of this. The intention is to present a holistic view,
from which any deltas to the existing functionality can be identified.
Kind regards,
r.
On 24 June 2015 at 18:56:28, Andy Bierman (a...@yumaworks.com) wrote:
Hi,
Not sure you are aware which parts of y
Hi,
Not sure you are aware which parts of your diagram are already
standardized in NETCONF. The startup and candidate capabilities
as defined in RFC 6241 are not related to operational state.
Andy
On Wed, Jun 24, 2015 at 10:39 AM, Rob Shakir wrote:
> Hi netmod,
>
>
> Thanks very much to eve
On Wed, Jun 24, 2015 at 10:14 AM, Phil Shafer wrote:
> Andy Bierman writes:
> >> How is that expressed in the data model? "auto" would not be an
> >> operational value for "duplex". "none" would not be a valid
> >> configuration value, but would be the operational value for an
> >> empty port.
Hi netmod,
Thanks very much to everyone that has considered the problem that we laid out
on the last interim call. I think we’re starting to reach a common
understanding.
If I can make some slight tweaks to the diagrams that have been distributed:
And some further clarifying points/explanat
Hi Martin,
The table you have is consistent with the proposal that we laid out in the last
interim. Now that we understand the problem, it’d be great to move on to
solutions :)
Cheers,
r.
On 24 June 2015 at 10:39:53, Martin Bjorklund (m...@tail-f.com) wrote:
Kent Watsen wrote:
>
> [As
Andy Bierman writes:
>> How is that expressed in the data model? "auto" would not be an
>> operational value for "duplex". "none" would not be a valid
>> configuration value, but would be the operational value for an
>> empty port.
>
>good point -- the operational instance would not exist is the
On Wed, Jun 24, 2015 at 7:34 AM, Phil Shafer wrote:
> Andy Bierman writes:
> >1) defaults are not used in the ephemeral datastore
> >
> >The default-stmt is altered for the ephemeral datastore.
> >Default leafs are ignored (except for XPath evaluation).
> >Otherwise the schema default would alway
On Mon, Jun 15, 2015 at 10:49:28PM +, Kent Watsen wrote:
>
> This is a notice to start a NETMOD WG last call for the document "JSON
> Encoding of Data Modeled with YANG":
>
> https://tools.ietf.org/html/draft-ietf-netmod-yang-json-04
>
> Please indicate your support by Monday June 29, 2015
Martin Bjorklund writes:
>Yes, agreed; I just wanted to be sure. I think this is worth pointing
>out explicitly. In many cases the oper- node is not needed, but it
>might be.
Would we be better of having YANG statements that detail the
way the model changes between config and operational modes?
Andy Bierman wrote:
> On Wed, Jun 24, 2015 at 7:23 AM, Martin Bjorklund wrote:
>
> > Hi,
> >
> > Andy Bierman wrote:
> > > 5) admin-foo and oper-foo can go away
> >
> > Yes, but I assume that they don't *have* to go away. For example, the
> > duplex example would still have two nodes, since th
Andy Bierman writes:
>1) defaults are not used in the ephemeral datastore
>
>The default-stmt is altered for the ephemeral datastore.
>Default leafs are ignored (except for XPath evaluation).
>Otherwise the schema default would always override the configuration.
List instances in the ephemeral dat
On Wed, Jun 24, 2015 at 7:23 AM, Martin Bjorklund wrote:
> Hi,
>
> Andy Bierman wrote:
> > Hi,
> >
> > thanks.
> > A few details of the solution I am working on...
>
> I would (still!) use a new statement "i2rs:ephemeral true;" to mark
> ephemeral nodes on config false nodes. This can be done w
Hi,
Andy Bierman wrote:
> Hi,
>
> thanks.
> A few details of the solution I am working on...
I would (still!) use a new statement "i2rs:ephemeral true;" to mark
ephemeral nodes on config false nodes. This can be done w/o changing
YANG.
> 1) defaults are not used in the ephemeral datastore
>
Robert Wilton wrote:
> Hi Martin,
>
> One quick clarification:
>
> In your open config model example, should the operational state of the
> last line read 'full'?
yes!
> I.e
>
>running actual configoperational state
>--- --
>
Hi,
thanks.
A few details of the solution I am working on...
1) defaults are not used in the ephemeral datastore
The default-stmt is altered for the ephemeral datastore.
Default leafs are ignored (except for XPath evaluation).
Otherwise the schema default would always override the configuration.
Hi Martin,
One quick clarification:
In your open config model example, should the operational state of the
last line read 'full'?
I.e
running actual configoperational state
--- --
t4autoauto*full*
Andy:
I will post this slide for the i2RS meeting.
Sue
From: i2rs [mailto:i2rs-boun...@ietf.org] On Behalf Of Andy Bierman
Sent: Wednesday, June 24, 2015 9:24 AM
To: netmod@ietf.org; i...@ietf.org
Subject: [i2rs] extended datastores slide
Hi,
I prepared 1 slide (based on Kent
The separations and effects shown there match my understanding.
Thank you,
Joel
On 6/24/15 9:24 AM, Andy Bierman wrote:
Hi,
I prepared 1 slide (based on Kent's slide).
I am trying to understand the types of data
and how they are identified in YANG and conceptually
separated for protocol access.
Hi,
I prepared 1 slide (based on Kent's slide).
I am trying to understand the types of data
and how they are identified in YANG and conceptually
separated for protocol access.
Andy
extended_datastores.pdf
Description: Adobe PDF document
___
netmod m
Hi,
Currently we have an inconsistency in
draft-ietf-netmod-rfc6020bis-05. With Y35, we allow type empty in
unions. But section 7.8.2 says:
A leaf that is part of the key can be of any built-in or derived
type, except it MUST NOT be the built-in type "empty".
This means that this is lega
Kent Watsen wrote:
>
> [As an individual contributor]
>
> I think terminology is mostly converging, with the primary hangup
> being if ephemeral/intended are "configuration" or "state". I'm
> personally in favor of calling both "configuration", as they would
> still contain values like "auto",
33 matches
Mail list logo
