date:20150827

Andy Bierman  wrote:
> Hi,
> 
> I started a new subject line because the way logical vs. physical systems
> are managed is a separate issue from the others.
> 
>+--rw device
>   +--rw logical-network-elements
>  +--rw logical-network-element* [network-element-id]
> +--rw network-element-id  uint8
> +--rw network-element-name?   string
> +--rw default-networking-instance-name?   string
> +--rw system-management
> |  +--rw device-view? boolean
> |  +--rw syslog
> |  +--rw dns
> |  +--rw ntp
> |  +--rw statistics-collection
> |  +--rw ssh
> |  +--rw tacacs
> |  +--rw snmp
> |  +--rw netconf
> 
> 
> I do not know of any systems where the logical view
> is managed with an array entry like in this proposal.
> Usually the protocol (or CLI command) picks one logical context
> and the PDU is for that one logical system.  Each logical system
> is self-contained so that the data models are written for
> a single system.
> 
> Putting the multiplexing in the data model
> adds a lot of extra complexity and protocol overhead for
> systems that do not have virtual servers.

+1

I also believe that it is too limiting.  Some systems might do it this
way, but then there are others that have the concept of "virtual
system" that works differently.  For example, the virtual system might
give you your very own sandbox not just for the data model but also
for the underlying config data store.  There are essentially separate
instances of a NETCONF server running (or other protocol).


> When it comes to converting this tree to CLI (since this
> is a common practice) the "interfaces" command will become
> "devices interfaces", "system" becomes "device system", etc.
> I don't know of any CLIs that work this way.
> 
> The "nacm enable false" command will become
> 
> device logical-network-elements logical-network-element 1 \
> system-management netconf nacm enable false

And this would be a weird place for NACM.  Would there be another NACM
for logical-network-element 2?  They would share the same root, so are
rules somehow merged?

Ditto for the snmp container btw.


/martin

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Motivations for Structuring Models

Rob Shakir  wrote:
> 
> Martin,
> 
> Apologies, I switched to a new client and, wow, yes, it's not
> readable. I reported a bug and switched clients again... I *hope* this
> one is more readable (and it was when I checked last).

Thank you Rob!

> I'll put aside questions of whether the questions I'm asking are
> completely fair. Apologies. They're written from my perspective of
> problems I'm actually experiencing.
> > Martin Bjorklund 
> > August 27, 2015 at 15:45
> > 1) As a consumer of YANG models, how do I identify the set of models
> > that provide a set of functionality?
> >
> > I think that neither your proposed solution or what we have today (7
> > published modules) solves this problem.
> I respectfully disagree. By defining some form of structure for the
> models, I can have a logical grouping that gives me some pointers as
> to where to find the right things that I need. I want to configure
> OAM, great, let's go look at
> /device/logical-network-elements/logical-network-element/network-instances/network-instance/oam-protocols
> - because that's where all OAM stuff happens to live.

So the idea is that this structure is defined in one module,
ietf-something-structure, right?

And then different oam protocol modules augment this structure?

How does this help you find the modules that augment this structure?

> If I have to
> rather look through / to find a subset of some ping functionality in
> one module, and some in another, it's not clear to me how I even start
> to find the right thing - because at the moment one type of ping lives
> in one module, and another in a completely different one, even though
> they're almost identical in terms of management plane interface.

I agree this sounds like a bad design.  I absolutely agree that it is
necessary to look at how a generic X is handled before doing a model
for a specific instance of X.  For example, it is probably useful to
define how interfaces in general are managed before creating a model
for ethernet interfaces.  And maybe useful to think about how routing
protocols in general are handled before doing a model for bgp.

[...]

> >> “Just read through the modules” is not acceptable answer when
> >> considering making things easy to use for YANG model consumers.
> >
> > But how does the top-level node /device (sorry, but I really have to
> > ask this) solve this problem?  I *really* do not understand this.
> > Even with your solution you'd have a set of modules that augment this
> > structure, right?  How do I know what these other modules are?

You didn't answer this question.  So I repeated it above and below ;)

> >
> > Now, I should add that the way I see your solution is a YANG module
> > that defines a structure of NP-containers.  You (or was it Anees?)
> > then mentioned that we shouldn't focus so much on the *YANG module*;
> > it was the structure that was important.
> >
> First off, we drew a picture [0] that showed the set of modules that
> we figured we might need. These break down into various bits of device
> functionality. To make this more accessible as something that could be
> shown in a draft, we expressed it in YANG and used pyang to draw out
> the tree.

Thanks, this is what I remember you mentioned in Dallas.

But what does this really mean?  Are you proposing:

  1)  to define one model ietf-something that contains this proposed
  structure, which then other modules augment?

  2)  to define one single ietf model, period.  no augments by the
  ietf.

  3)  to define the structure more loosely in text, and use this
  structure when new models are developed?

  4)  something else?

> The layout of the sets of functions that we have, and how they are
> grouped, is the important thing. The fact that we are configuring a
> device makes /device a good starting point. I think this is how you
> implemented NEDs in NCS too...?

No, each NED (device) is modelled according to its native "model".  So
for example the IOS NED has /interface, /ip, /xconnect, etc.

But, as I have said before, the device abstraction is really
important - in the NMS/OSS/controller/whatever.  There we have a list
of devices, and each device has a name and meta-data and then its real
data, so for example we can have:

   /devices/device[name='rtr4']/ip
   /devices/device[name='rtr4']/port

and then we put all data models from the device under a common
container 'data':

   /devices/device[name='rtr4']/data/interface/
   /devices/device[name='rtr4']/data/xconnect/

If the device had a top-level container "device" this would have been:

   /devices/device[name='rtr4']/data/device/interfaces

/martin
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Motivations for Structuring Models

2015-08-27 Thread Qin Wu

Hi,
发件人: netmod [mailto:netmod-boun...@ietf.org] 代表 Andy Bierman
发送时间: 2015年8月28日 0:25
收件人: Rob Shakir
抄送: netmod@ietf.org
主题: Re: [netmod] Motivations for Structuring Models

On Thu, Aug 27, 2015 at 6:56 AM, Rob Shakir mailto:r...@rob.sh>> 
wrote:

NETMOD,

One of the chairs encouraged me to post this to the list. I didn’t really find 
how it fits in to the existing threads, but I wanted to make an observation.

It strikes me that there is a need to take a step back from the debate of 
whether /device is a good idea or not.

As a user of something that results from compiling/generating bindings from a 
YANG model, I have two requirements:

  *   I need to be able to compose the right modules to be able to get the 
functionality that that the thing I’m trying to configure uses.

 *   Let’s say I want to configure some OAM continuity checking functions - 
for both MPLS and IP.
 *   Right now, I have the choice of ‘ietf-lspping’ which defines 
/lsp-pings, then ‘mplstp-oam’ which defines /mplstp-oam. Presumably then we’ll 
have ‘ietf-ip-oam’ and then ‘ietf-ipv6-oam’.
 *   As a developer - how do I figure out which models I need to build my 
OAM function. Do I have to trawl some directory to find all of the different 
fragments of OAM
[Qin]: I think this is also what LIME WG is trying to solve by defining generic 
YANG model for OAM to provide technology independent framework. Please take a 
look at LIME WG charter:
http://datatracker.ietf.org/wg/lime/charter/

 *   Do I then need to accept the complexity of dealing with the fact that 
the structures of LSP pings is completely different to the IP OAM structures? 
[Given that there is no co-ordination of models, then this will happen.]
 I think this is something we need to try to avoid. I believe coordination 
of these models are really needed.

  *   As someone that is building YANG models, how do I know where I should 
leaf-ref too.

 *   Let’s say I want to tie an OAM probe to some protocol liveliness - 
where do I point my leafref to? At the moment, without some structure, than any 
path that is specified is pointing to some placeholder location, until we agree 
where the structure might sit.
   [Qin]: Two comments:

1.   I think draft-rtgyangdt-rtgwg-device-model-00 provide a good structure 
for these OAM models organization but not limited to provide structure for OAM 
model organization.

  +--rw logical-network-elements

+--rw networking-instances

   +--rw networking-instance* [networking-instance-name]

  +--rw oam-protocols

  |  +--rw bfd

  |  +--rw cfm

  |  +--rw twamp



2.   draft-tissa-lime-yang-oam-model also provide a good common structure 
for OAM models organization.
LIME WG is chartered to work on generic YANG model for OAM (the relevant draft 
is draft-tissa-lime-yang-oam-model)and provides a common structure for various 
OAM technologies, technology specific OAM data models will be worked on 
respective protocol WGs(e.g., BFD, MPLS).

Therefore based on LIME charter (http://datatracker.ietf.org/wg/lime/charter/), 
the relation with protocol based OAM models can be depicted, for example, as 
follows:
   +-+-+-+-+-+
   | LIME gen|
   |OAM YANG |
   +-+-+-+-+-+
|
|
+-+
|  |   | ||
+-+-+-+-+-+   +-+-+-+-+-+   +-+-+-+-+-+ +-+-+-+-+-+  +-+-+-+-+-+
| CFM |   | MPLS-TP |   | MPLS| | IP  | . . .|  foo|
|OAM YANG |   |OAM YANG |   |OAM YANG | |OAM YANG |  |OAM YANG |
+-+-+-+-+-+   +-+-+-+-+-+   +-+-+-+-+-+ +-+-+-+-+-+  +-+-+-+-+-+
  | | |   |  |
  |   +-+-+-+-+-+   +-+-+-+-+-+   |  +-+-+-+-+-+
  |   | MPLS-TP |   | MPLS|   | . . .|  foo|
  |   |sub tech |   |sub tech |   |  |sub tech |
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Motivations for Structuring Models

2015-08-27 Thread Kent Watsen


One response already, minutes for all interim meetings are linked here:

  http://www.ietf.org/meeting/interim/proceedings.html


This list contains entries other working groups too, and sorting by
groups, by clicking "Group" at the top, does not retain the secondary sort
on Date, so the NETMOD entries are grouped together, but all out of order
- ugh.  I'll see if this page can be improved too...

Kent

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] logical systems model

Hi,

I started a new subject line because the way logical vs. physical systems
are managed is a separate issue from the others.

   +--rw device
  +--rw logical-network-elements
 +--rw logical-network-element* [network-element-id]
+--rw network-element-id  uint8
+--rw network-element-name?   string
+--rw default-networking-instance-name?   string
+--rw system-management
|  +--rw device-view? boolean
|  +--rw syslog
|  +--rw dns
|  +--rw ntp
|  +--rw statistics-collection
|  +--rw ssh
|  +--rw tacacs
|  +--rw snmp
|  +--rw netconf


I do not know of any systems where the logical view
is managed with an array entry like in this proposal.
Usually the protocol (or CLI command) picks one logical context
and the PDU is for that one logical system.  Each logical system
is self-contained so that the data models are written for
a single system.

Putting the multiplexing in the data model
adds a lot of extra complexity and protocol overhead for
systems that do not have virtual servers.

When it comes to converting this tree to CLI (since this
is a common practice) the "interfaces" command will become
"devices interfaces", "system" becomes "device system", etc.
I don't know of any CLIs that work this way.

The "nacm enable false" command will become

device logical-network-elements logical-network-element 1 \
system-management netconf nacm enable false


Andy
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Y34 - root node

2015-08-27 Thread Alexander Clemm (alex)

Yes.  The one thing I would add is that validation of the mounted data can 
occur in its original path (the authoritative owner (in the distributed case)). 
 It should not be required to do this validation with the chrooted path, 
although that path can be used by other data nodes that refer to / have 
dependencies on the mounted data.  

Regarding naming, do you have an alternative suggestion?

Cheers
--- Alex

-Original Message-
From: Martin Bjorklund [mailto:m...@tail-f.com] 
Sent: Wednesday, August 26, 2015 11:27 PM
To: Alexander Clemm (alex) 
Cc: lho...@nic.cz; netmod@ietf.org
Subject: Re: [netmod] Y34 - root node

"Alexander Clemm (alex)"  wrote:
> - As Martin mentioned, clearly by allowing to mount you are decoupling 
> schema information and instance population.  Regarding the issue of 
> validation, this can be addressed by several ways.

I think that the mount point effectively works as a 'chroot' for all mounted 
data models in the mount point.  This means that if ietf-interfaces and 
ietf-routing are mounted under /devices/device/data, all XPath expressions and 
leafref paths and instance-identifiers in these models are evaluated in a 
chrooted environment where their '/' is set to /device/device[name='...']/data. 
 This is how we implement validation for such modules in our NCS (manager 
product).

In an implementation that actually does not store the data locally, but fetches 
it from a remote device (like the original mount proposal), it is fine to push 
also validation to the remote node.

[maybe mount is not a good name for this generalized thing; this term might 
make you believe that the data has to be provided by some other server.]

/martin

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Motivations for Structuring Models

2015-08-27 Thread Kent Watsen


Hi Martin,

>BTW, are these interim meeting
>minutes available somewhere?  This is not the first time I had to
>search old emails in order to find interim minutes.

I just sent email to the WG chairs alias asking about this.  I'm proposing
that minutes for interim meetings be linked off the "Minutes" page too, as
they are already for conference meetings
(http://tools.ietf.org/wg/netmod/minutes)

Using the meeting manager tool I have access to, I can see a list of all
the interim meetings that were scheduled in 2014 and 2015.  And I can
drill down to find the link for the minutes that were uploaded for that
meeting.  Looking at the results (see below), I see that the minutes were
uploaded for about 1/2 of the meetings.  In some cases, this is an error
by the chairs forgetting to upload them or not knowing that they should
and, in other cases, this is because (I speculate) that the interim
meeting was cancelled and was left dangling.

For interim meetings that took place and yet missing minutes, Tom and I
will work to get them posted.  For the interim meetings that were
cancelled, I imagine we can uploaded some fake minutes that just say the
meeting was cancelled, though I'd much rather find a way to delete the
meeting entirely from the meeting manager tool's record - I'll ask around
to see if that's possible...


2015-10-12 : none linked
2015-10-05 : none linked
2015-09-28 : none linked
2015-09-21 : none linked
2015-09-14 : none linked
2015-09-07 : none linked
2015-08-31 : none linked
2015-08-24 : 
https://www.ietf.org/proceedings/interim/2015/08/24/netmod/minutes/minutes-
interim-2015-netmod-15
2015-06-25 : none linked
2015-06-18 : none linked
2015-03-12 : none linked
2015-03-05 : 
https://www.ietf.org/proceedings/interim/2015/03/04/netmod/minutes/minutes-
interim-2015-netmod-5
2015-03-04 : none linked
2015-02-22 : none linked
2015-02-18 : 
https://www.ietf.org/proceedings/interim/2015/02/18/netmod/minutes/minutes-
interim-2015-netmod-4
2015-02-04 : 
https://www.ietf.org/proceedings/interim/2015/02/04/netmod/minutes/minutes-
interim-2015-netmod-3
2015-01-21 : 
https://www.ietf.org/proceedings/interim/2015/01/21/netmod/minutes/minutes-
interim-2015-netmod-2
2015-01-15 : none linked
2015-01-08 : none linked
2015-01-07 : 
https://www.ietf.org/proceedings/interim/2015/01/07/netmod/minutes/minutes-
interim-2015-netmod-1
2014-12-17 : 
https://www.ietf.org/proceedings/interim/2014/12/17/netmod/minutes/minutes-
interim-2014-netmod-19
2014-12-11 : none linked
2014-12-04 : none linked
2014-12-03 : 
https://www.ietf.org/proceedings/interim/2014/12/03/netmod/minutes/minutes-
interim-2014-netmod-18
2014-11-19 : 
https://www.ietf.org/proceedings/interim/2014/11/19/netmod/minutes/minutes-
interim-2014-netmod-17
2014-10-22 : none linked
2014-10-15 : 
https://www.ietf.org/proceedings/interim/2014/10/15/netmod/minutes/minutes-
interim-2014-netmod-15
2014-10-08 : 
https://www.ietf.org/proceedings/interim/2014/10/08/netmod/minutes/minutes-
interim-2014-netmod-14
2014-10-01 : 
https://www.ietf.org/proceedings/interim/2014/10/01/netmod/minutes/minutes-
interim-2014-netmod-13
2014-09-24 : none linked
2014-09-17 : 
https://www.ietf.org/proceedings/interim/2014/09/17/netmod/minutes/minutes-
interim-2014-netmod-11
2014-09-10 : none linked
2014-09-03 : 
https://www.ietf.org/proceedings/interim/2014/09/03/netmod/minutes/minutes-
interim-2014-netmod-9
2014-08-27 : 
https://www.ietf.org/proceedings/interim/2014/08/27/netmod/minutes/minutes-
interim-2014-netmod-8
2014-07-16 : none linked
2014-07-09 : 
https://www.ietf.org/proceedings/interim/2014/07/09/netmod/minutes/minutes-
interim-2014-netmod-6
2014-07-02 : 
https://www.ietf.org/proceedings/interim/2014/07/02/netmod/minutes/minutes-
interim-2014-netmod-5
2014-06-25 : none linked
2014-06-18 : none linked
2014-06-11 : 
https://www.ietf.org/proceedings/interim/2014/06/11/netmod/minutes/minutes-
interim-2014-netmod-2
2014-06-04 : 
https://www.ietf.org/proceedings/interim/2014/06/04/netmod/minutes/minutes-
interim-2014-netmod-1



Kent


___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Motivations for Structuring Models

On Thu, Aug 27, 2015 at 12:48 PM, Rob Shakir  wrote:

> Hi Andy,
>
> On August 27, 2015 at 14:48:58, Andy Bierman (a...@yumaworks.com) wrote:
>
> Did you really think that just because we created a nice DML that
> somehow you would not need to know about the topic of your YANG module?
> I actually have heard this complaint from some people.  Great.  How does
> YANG help?  I still have to be an expert in MPLS to write a YANG module
> that manages MPLS.  Yep.  That's right.  Nothing in YANG helps you
> know more than you do now about specific networking technologies.
>
> No, I didn’t at all.
>
> So, I work operating networks, and the surrounding systems that we use to
> manage them. I could consider myself to have some knowledge in the various
> areas that I’m trying to model right now - and am even luckier to be able
> to work with a bunch of folk who have also operated different networks,
> such that we can figure out how things should be laid out. So, we’re
> writing these modules - and you’ll see them here:
> https://github.com/YangModels/yang/tree/master/experimental/openconfig
>
> What I am saying is that as the person looking at how to /actually use/
> these modules, it is much, much easier for me if I can have some idea of
> where to find things that I know are related, and have some consistency in
> the approach.
>
> The group of people that are writing these modules noted the need for us
> to have some structure. However, the IETF is also writing a bunch of
> modules, which we figure it’d be super-neat if we can use.
>
> So we wrote some conventions, one is a structure; the other is an approach
> for how opstate is modelled.
>
> From your mail, I think that you are saying that you don’t care how we do
> this. If that’s the case we’ll head off and write our modules.
>
> However, there are two discrepancies:
>
>1. Lots of others in the IETF are writing models, and we’d like all
>these to combine to be usable. To do this, we need to agree on a structure.
>NETMOD looked like the place to do this based on the fact that
>draft-ietf-netmod-routing-cfg is a NETMOD draft. So we brought them here.
>2. Your objection is based on a specific subset of models that have
>already been created, that you assert will still need to exist. This is
>then counter to the fact that I can go and model things how I like. Again,
>it seems like raising the issues that we have with these models in context
>of a structure should be something raised with NETMOD, given that these
>documents are the output of NETMOD according to the data tracker.
>
> There are really two options:
>
> a) NETMOD does not care about how models fit together - because their
> contents are arbitrary. If this is the case, fine, I’ll talk with the area
> directors as to where we should propose these approaches such that the
> pan-IETF models end up working nicely together within the DML that this
> group has defined.
> b) NETMOD does care, and should try and define a structure because it is
> the custodian working group for YANG and YANG models.
>
>
this is a strawman.
Just because some people don't agree that the existing modules should be
moved doesn't mean the NETMOD WG wants every module to create its
own top-level node.

Create some organization for the 194 new modules.
I completely agree with you that these modules should be written with
a coherent development plan in mind.




> I think a lot of my problems are solved by having a defined structure for
> models, that has been worked through by folks with protocol knowledge, and
> knowledge of how these elements are used and managed. I would like it to be
> adopted by the IETF. My view is that b) is currently true - and hence it
> was brought to NETMOD
>


Given that CLIs are being driven by YANG, I completely agree that
understanding of the command hierarchy is useful.   I have no objections
to the creation of a hierarchy or "node placement plan" or whatever.
This is a non-issue.

The issue I see is whether the existing 7 modules should be grandfathered
or whether these RFCs have to be changed to Obsolete status and replaced
with new RFCs.



Andy



>

> At the moment, I can’t reconcile the apparent disparities between your
> statements in this mail and your objections in other messages. Further to
> this, I still cannot see any alternative to the structure that we did
> define - so whilst I can remove /device from the start of the path, which
> ‘protects’ /interfaces [0] - this doesn’t actually help me progress
> anything. This is why “/device or not” is irrelevant.
>
> r.
>
> [0]: Note that actually, some work to refactor 7223 further to just its
> path has been done…
> https://github.com/YangModels/yang/tree/master/experimental/openconfig/interfaces
>
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Motivations for Structuring Models

Martin,

Apologies, I switched to a new client and, wow, yes, it's not readable.
I reported a bug and switched clients again... I *hope* this one is more
readable (and it was when I checked last).

I'll put aside questions of whether the questions I'm asking are
completely fair. Apologies. They're written from my perspective of
problems I'm actually experiencing.

Martin Bjorklund
August 27, 2015 at 15:45
1) As a consumer of YANG models, how do I identify the set of models
that provide a set of functionality?

I think that neither your proposed solution or what we have today (7
published modules) solves this problem.
I respectfully disagree. By defining some form of structure for the
models, I can have a logical grouping that gives me some pointers as to
where to find the right things that I need. I want to configure OAM,
great, let's go look at
/device/logical-network-elements/logical-network-element/network-instances/network-instance/oam-protocols
- because that's where all OAM stuff happens to live. If I have to
rather look through / to find a subset of some ping functionality in one
module, and some in another, it's not clear to me how I even start to
find the right thing - because at the moment one type of ping lives in
one module, and another in a completely different one, even though
they're almost identical in terms of management plane interface.

I agree, an alternative is that one can have something that has a
registry that defines sets of functionality, and we then need to define
the 'blocks' of functionality that we need (hey! this looks a lot like
some definition of a set of modules!). If this is a better solution,
yes, please, propose it. The way that we proposed in
openconfig-model-structure tries to have a way that you can not have a
single model code-block and pull in different logical sub-modules, but
know where to find the functionality you need.

How do YANG model writers
ensure that their models are as easy to deal with as possible by
having consistent modelling approaches for config?

Hmm, your question contains the answer; that's cheating ;-)

Shouldn't the question be:

How do YANG model writers ensure that their models are as easy to
deal with as possible?

The answer to this one is the same as to the question how do a C
programmer ensure that his program is as easy to deal with as
possible?
How do I write code that is generally easy to deal with? Follow
conventions that generally tell me where to put stuff, and how to name
it. What I don't understand is why model-structure or opstate is
actually different to defining such conventions?

2) As a creator of YANG models, how do I know the targets for
references such that I capture references to the elements that I
want, given there is no currently defined structure?

Again your question is biased... shouldn't it be:

As a creator of YANG models, how do I know the targets for
references such that I capture references to the elements that I
want?

And the answer to this one is the same as to question 1 - I don't
think your proposal solves this, and the solution is that you need to
find these other modules.
Structure really helps me here, since when someone creates a module that
wants to reference a particular type of function, then we reference a
well-known path for that. If someone adds a function of that type, it
must sit in that path so it can be referenced. See the VRRP example I
wrote out before.

“Just read through the modules” is not acceptable answer when
considering making things easy to use for YANG model consumers.

But how does the top-level node /device (sorry, but I really have to
ask this) solve this problem? I *really* do not understand this.
Even with your solution you'd have a set of modules that augment this
structure, right? How do I know what these other modules are?

Now, I should add that the way I see your solution is a YANG module
that defines a structure of NP-containers. You (or was it Anees?)
then mentioned that we shouldn't focus so much on the *YANG module*;
it was the structure that was important.

First off, we drew a picture [0] that showed the set of modules that we
figured we might need. These break down into various bits of device
functionality. To make this more accessible as something that could be
shown in a draft, we expressed it in YANG and used pyang to draw out the
tree.

The layout of the sets of functions that we have, and how they are
grouped, is the important thing. The fact that we are configuring a
device makes /device a good starting point. I think this is how you
implemented NEDs in NCS too...?

Cheers,
r.

[0]: http://rob.sh/files/model-structure.pdf

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Motivations for Structuring Models

Nadeau Thomas  wrote:
> I think everyone agreed
> at the interim meeting that the requirements were clear and sound.
> This is detailed in the meeting minutes.

Which interim meeting do you mean?  BTW, are these interim meeting
minutes available somewhere?  This is not the first time I had to
search old emails in order to find interim minutes.

The reason I ask is that I don't remember discussing requirements for
the structure; I do remember discussing requirements for relating
state to config though, but that is a separate issue.

/martin

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Motivations for Structuring Models

Hi Andy,

On August 27, 2015 at 14:48:58, Andy Bierman (a...@yumaworks.com) wrote:

Did you really think that just because we created a nice DML that
somehow you would not need to know about the topic of your YANG module?
I actually have heard this complaint from some people.  Great.  How does
YANG help?  I still have to be an expert in MPLS to write a YANG module
that manages MPLS.  Yep.  That's right.  Nothing in YANG helps you
know more than you do now about specific networking technologies.
No, I didn’t at all.

So, I work operating networks, and the surrounding systems that we use to 
manage them. I could consider myself to have some knowledge in the various 
areas that I’m trying to model right now - and am even luckier to be able to 
work with a bunch of folk who have also operated different networks, such that 
we can figure out how things should be laid out. So, we’re writing these 
modules - and you’ll see them here: 
https://github.com/YangModels/yang/tree/master/experimental/openconfig

What I am saying is that as the person looking at how to /actually use/ these 
modules, it is much, much easier for me if I can have some idea of where to 
find things that I know are related, and have some consistency in the approach.

The group of people that are writing these modules noted the need for us to 
have some structure. However, the IETF is also writing a bunch of modules, 
which we figure it’d be super-neat if we can use.

So we wrote some conventions, one is a structure; the other is an approach for 
how opstate is modelled.

From your mail, I think that you are saying that you don’t care how we do this. 
If that’s the case we’ll head off and write our modules.

However, there are two discrepancies:

Lots of others in the IETF are writing models, and we’d like all these to 
combine to be usable. To do this, we need to agree on a structure. NETMOD 
looked like the place to do this based on the fact that 
draft-ietf-netmod-routing-cfg is a NETMOD draft. So we brought them here. 
Your objection is based on a specific subset of models that have already been 
created, that you assert will still need to exist. This is then counter to the 
fact that I can go and model things how I like. Again, it seems like raising 
the issues that we have with these models in context of a structure should be 
something raised with NETMOD, given that these documents are the output of 
NETMOD according to the data tracker.
There are really two options:

a) NETMOD does not care about how models fit together - because their contents 
are arbitrary. If this is the case, fine, I’ll talk with the area directors as 
to where we should propose these approaches such that the pan-IETF models end 
up working nicely together within the DML that this group has defined.
b) NETMOD does care, and should try and define a structure because it is the 
custodian working group for YANG and YANG models.

I think a lot of my problems are solved by having a defined structure for 
models, that has been worked through by folks with protocol knowledge, and 
knowledge of how these elements are used and managed. I would like it to be 
adopted by the IETF. My view is that b) is currently true - and hence it was 
brought to NETMOD.

At the moment, I can’t reconcile the apparent disparities between your 
statements in this mail and your objections in other messages. Further to this, 
I still cannot see any alternative to the structure that we did define - so 
whilst I can remove /device from the start of the path, which ‘protects’ 
/interfaces [0] - this doesn’t actually help me progress anything. This is why 
“/device or not” is irrelevant.

r.

[0]: Note that actually, some work to refactor 7223 further to just its path 
has been done… 
https://github.com/YangModels/yang/tree/master/experimental/openconfig/interfaces
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Motivations for Structuring Models

Hi Rob,

[I am replying to this email since you have your two issues clearly
enumerated here; thanks for doing that]

[side note: the text versions of your replies are very difficult to
read and thus reply to; your mail client doesn't quite get the
citation right.  is there any knob you can tweak to improve that?]

Rob Shakir  wrote:
> Please re-read my email - here’s the single statement where I said
> that this
> was NOT the discussion that I think is important:
> 
>>> It strikes me that there is a need to take a step back from the debate
>>> of whether /device is a good idea or not.

Ok, I will try to do that.

> Please suggest an alternate approach to the one that is laid out in
> draft-openconfig-netmod-model-structure that you believe will help
> with the two
> problems that I raised. I’ll rephrase them here with less explanation,
> albeit
> that comes with less clarity.
> 
>
> 1) As a consumer of YANG models, how do I identify the set of models
> that provide a set of functionality?

I think that neither your proposed solution or what we have today (7
published modules) solves this problem.

This is a hard problem to solve.  It is similar to the problem of
finding the correct linux package that solves a given problem.  In
some cases I can search a central registry (package manager), and in
some cases I have to expand the search.

One solution is to not allow extensible modules at all; instead we
would work with ONE model that we just add to over time, and republish
this ever growing module when we need to.  Vendors and other SDOs
would not be able to add to this single module.  I don't think this is
a realistic approach.

Another solution is to try to have some kind of registry of all
modules.  This might work for IETF modules, but who knows what other
SDOs or vendors do?  (Incidentally there is such a registry for IETF
modules, maintained by IANA
(http://www.iana.org/assignments/yang-parameters/yang-parameters.xhtml#yang-parameters-1))

For MIBs, there are sites that try to collect all published MIBs,
including vendor MIBs.

> How do YANG model writers
> ensure that their models are as easy to deal with as possible by
> having consistent modelling approaches for config?

Hmm, your question contains the answer; that's cheating ;-)

Shouldn't the question be:

  How do YANG model writers ensure that their models are as easy to
  deal with as possible?

The answer to this one is the same as to the question how do a C
programmer ensure that his program is as easy to deal with as
possible?

> 2) As a creator of YANG models, how do I know the targets for
> references such that I capture references to the elements that I
> want, given there is no currently defined structure?

Again your question is biased...  shouldn't it be:

  As a creator of YANG models, how do I know the targets for
  references such that I capture references to the elements that I
  want?

And the answer to this one is the same as to question 1 - I don't
think your proposal solves this, and the solution is that you need to
find these other modules.

> “Just read through the modules” is not acceptable answer when
> considering making things easy to use for YANG model consumers.

But how does the top-level node /device (sorry, but I really have to
ask this) solve this problem?  I *really* do not understand this.
Even with your solution you'd have a set of modules that augment this
structure, right?  How do I know what these other modules are?

Now, I should add that the way I see your solution is a YANG module
that defines a structure of NP-containers.  You (or was it Anees?)
then mentioned that we shouldn't focus so much on the *YANG module*;
it was the structure that was important.

/martin
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Motivations for Structuring Models

On Thu, Aug 27, 2015 at 11:56 AM, Nadeau Thomas 
wrote:

>
> On Aug 27, 2015:2:29 PM, at 2:29 PM, Andy Bierman 
> wrote:
>
>
>
> On Thu, Aug 27, 2015 at 11:14 AM, Nadeau Thomas 
> wrote:
>
>>
>> On Aug 27, 2015:1:59 PM, at 1:59 PM, Andy Bierman 
>> wrote:
>>
>>
>>
>> On Thu, Aug 27, 2015 at 10:39 AM, Rob Shakir  wrote:
>>
>>>
>>> Andy,
>>>
>>> Apologies, I don’t understand how your mail answers the questions that I
>>> posed.
>>>
>>> On August 27, 2015 at 12:25:20, Andy Bierman (a...@yumaworks.com) wrote:
>>>
>>> A whole lots of words here, but I am still confused why /device is
>>> better than /
>>> for solving your "data model awareness" problem.
>>>
>>> Please re-read my email - here’s the single statement where I said that
>>> this was NOT the discussion that I think is important:
>>>
>>> It strikes me that there is a need to take a step back from the debate
 of whether /device is a good idea or not.

>>> I’m not sure how this could be clearer.
>>>
>>>
>> Sorry -- are you suggesting that maybe /device adds no value beyond /?
>> If so, I agree.
>>
>>
>>
>>> YANG is no different than any other part of the source code.
>>> Reusable YANG is just as likely or unlikely as reusable C,
>>> depending on how aware people are of the existing code base.
>>>
>>> Which OAM? Read the modules and decide. No magic there.
>>> How would /device vs / (as the first node) help you figure this out?
>>>
>>> Nobody is objecting at all to creating structure for the new modules.
>>> If /device has siblings, then let's see them in the uber-tree.
>>> The objection is to adding in a useless layer, and moving existing
>>> data nodes, which breaks existing implementations of all those data
>>> nodes.
>>>
>>> Please suggest an alternate approach to the one that is laid out in
>>> draft-openconfig-netmod-model-structure that you believe will help with the
>>> two problems that I raised. I’ll rephrase them here with less explanation,
>>> albeit that comes with less clarity.
>>>
>>> 1) As a consumer of YANG models, how do I identify the set of models
>>> that provide a set of functionality? How do YANG model writers ensure that
>>> their models are as easy to deal with as possible by having consistent
>>> modelling approaches for config?
>>>
>>
>> RTFM
>>
>>
>> Andy,
>>
>> While it might be frustrating, coming to an understanding of what the
>> problem is or might be, and then looking at
>> why the existing mechanisms/models or additional ones solve these
>> requirements (or do not) is what is at hand.  I think everyone agreed
>> at the interim meeting that the requirements were clear and sound.  This
>> is detailed in the meeting minutes.  If anyone disputes this,
>> I am happy to do an official WG call for consensus on these specifics,
>> but given the unanimous agreement at the meeting, I did
>> not feel that it was necessary to do this.  Based on that, the next
>> question is: are these problems solved with what is here today,
>> or do we need another approach/es.  Rob is clearly not an idiot and is
>> asking for detailed reasons why you and others
>> believe what he/OpenConfig have proposed is insufficient. Please be as
>> considerate and constructive as he has been in asking his
>> questions when you address them.
>>
>>
> Are you suggesting that the openconfig drafts offer some solution
> to "how do I use this YANG module" that does not involve reading the YANG
> module?
> If so, I didn't see it.  Please point it out to us.
>
>
> I am not taking sides. I hope I don’t need to point out these guys have
> presented an alternative
> solution. The WG must consider this seriously as it is a serious proposal
> that is being seriously
> considered in other parts of the IETF such as the routing area.  I will
> point out again that we are
> looking at this closely and thoroughly. If its determined to be desired
> via consensus,
> then we will go forward with it; if not, then no.  Its my action and job
> to determine this and I’ve
> outlined the process for this.
>
>

We are going to interim meetings.
We are discussing the issues on the WG mailing list.
I was under the impression this is our process.

I hope we get past the hand-waving phase and
you can enumerate the exact changes and how they are going
to be accomplished.  For example, do all 7 of the existing RFCs need
to recharter and start over? Is a WG going to be formed to create the
uber-tree?

There have been several objections to moving /interfaces to
/device/interfaces.
Are you declaring that the IETF agrees that this change is needed, despite
all the objections and statements such as "an uber-tree makes things worse"?



My only objection is to moving data that has already been published in an
> RFC.
> I am not the only person on this list that has questioned to value of
> moving this small number of data models to new roots in the data tree.
>
> Everything done in an IETF meeting needs to be confirmed on
> the mailing list.  You know that.
>
> So what specifics are you rea

Re: [netmod] Motivations for Structuring Models

2015-08-27 Thread Nadeau Thomas


> On Aug 27, 2015:2:29 PM, at 2:29 PM, Andy Bierman  wrote:
> 
> 
> 
> On Thu, Aug 27, 2015 at 11:14 AM, Nadeau Thomas  > wrote:
> 
>> On Aug 27, 2015:1:59 PM, at 1:59 PM, Andy Bierman > > wrote:
>> 
>> 
>> 
>> On Thu, Aug 27, 2015 at 10:39 AM, Rob Shakir > > wrote:
>> 
>> Andy,
>> 
>> Apologies, I don’t understand how your mail answers the questions that I 
>> posed.
>> 
>> On August 27, 2015 at 12:25:20, Andy Bierman (a...@yumaworks.com 
>> ) wrote:
>> 
>>> A whole lots of words here, but I am still confused why /device is better 
>>> than /
>>> for solving your "data model awareness" problem.
>> 
>> Please re-read my email - here’s the single statement where I said that this 
>> was NOT the discussion that I think is important:
>> 
>>> It strikes me that there is a need to take a step back from the debate of 
>>> whether /device is a good idea or not.
>>> 
>> 
>> I’m not sure how this could be clearer.
>> 
>> 
>> Sorry -- are you suggesting that maybe /device adds no value beyond /?
>> If so, I agree.
>> 
>>  
>>> YANG is no different than any other part of the source code.
>>> Reusable YANG is just as likely or unlikely as reusable C,
>>> depending on how aware people are of the existing code base.
>>> 
>>> Which OAM? Read the modules and decide. No magic there.
>>> How would /device vs / (as the first node) help you figure this out?
>>> 
>>> Nobody is objecting at all to creating structure for the new modules.
>>> If /device has siblings, then let's see them in the uber-tree.
>>> The objection is to adding in a useless layer, and moving existing
>>> data nodes, which breaks existing implementations of all those data nodes.
>> 
>> Please suggest an alternate approach to the one that is laid out in 
>> draft-openconfig-netmod-model-structure that you believe will help with the 
>> two problems that I raised. I’ll rephrase them here with less explanation, 
>> albeit that comes with less clarity.
>> 
>> 1) As a consumer of YANG models, how do I identify the set of models that 
>> provide a set of functionality? How do YANG model writers ensure that their 
>> models are as easy to deal with as possible by having consistent modelling 
>> approaches for config?
>> 
>> 
>> RTFM
> 
>   Andy, 
> 
>   While it might be frustrating, coming to an understanding of what the 
> problem is or might be, and then looking at
> why the existing mechanisms/models or additional ones solve these 
> requirements (or do not) is what is at hand.  I think everyone agreed
> at the interim meeting that the requirements were clear and sound.  This is 
> detailed in the meeting minutes.  If anyone disputes this,
> I am happy to do an official WG call for consensus on these specifics, but 
> given the unanimous agreement at the meeting, I did
> not feel that it was necessary to do this.  Based on that, the next question 
> is: are these problems solved with what is here today, 
> or do we need another approach/es.  Rob is clearly not an idiot and is asking 
> for detailed reasons why you and others
> believe what he/OpenConfig have proposed is insufficient. Please be as 
> considerate and constructive as he has been in asking his
> questions when you address them. 
> 
> 
> Are you suggesting that the openconfig drafts offer some solution
> to "how do I use this YANG module" that does not involve reading the YANG 
> module?
> If so, I didn't see it.  Please point it out to us.

I am not taking sides. I hope I don’t need to point out these guys have 
presented an alternative 
solution. The WG must consider this seriously as it is a serious proposal that 
is being seriously
considered in other parts of the IETF such as the routing area.  I will point 
out again that we are
looking at this closely and thoroughly. If its determined to be desired via 
consensus, 
then we will go forward with it; if not, then no.  Its my action and job to 
determine this and I’ve
outlined the process for this. 

> My only objection is to moving data that has already been published in an RFC.
> I am not the only person on this list that has questioned to value of
> moving this small number of data models to new roots in the data tree.
> 
> Everything done in an IETF meeting needs to be confirmed on
> the mailing list.  You know that. 
> 
> So what specifics are you ready to declare have WG consensus?

Again, my assumption was that there was sufficient consensus and 
understanding around
the requirements (not the solutions) after the interim meetings.  I explicitly 
asked that
question at the meeting and went around the WebEx call to confirm.   Those 
conclusions were
documented in the meeting minutes posted on the list.

—Tom




> 
> 
> 
>   —Tom (Speaking as Co-chair)
> 
> 
> 
> Andy
>  
>> 2) As a creator of YANG mode
>> 
>> ls, how do I know the targets for references such that I capture references 
>> to the elem

Re: [netmod] Motivations for Structuring Models

On Thu, Aug 27, 2015 at 11:19 AM, Rob Shakir  wrote:

> Hi Andy,
>
> I’m struggling with this debate.
>
> On August 27, 2015 at 13:59:55, Andy Bierman (a...@yumaworks.com) wrote:
>
>
> Sorry -- are you suggesting that maybe /device adds no value beyond /?
> If so, I agree.
>
> No, I am suggesting that should understand what the alternatives to
> solving issues are, before moving on to debating the merits of a particular
> solution that has nothing to compare and contrast against.
>

There is a proposal for the data root -- use / as we are doing now.

> One container does not add value, the structure (which happens to start
> with /device in ONE proposal, to which there are no alternates) is what
> matters. Unfortunately you seem to be stuck on this container. Please
> ignore it and focus on the problems I defined.
>
>  RTFM
>
> Great. So, I need to go and write a bunch of different implementations of
> how to set up a ping, and trawl through a huge number of roots to find
> things that are related. If this is the approach we take with IETF modules,
> then they will be worse to use than the existing configuration approaches
> that we have. At least the vendor specific ones have some form of logic as
> to how they are usable to consumers.
>

Did you really think that just because we created a nice DML that
somehow you would not need to know about the topic of your YANG module?
I actually have heard this complaint from some people.  Great.  How does
YANG help?  I still have to be an expert in MPLS to write a YANG module
that manages MPLS.  Yep.  That's right.  Nothing in YANG helps you
know more than you do now about specific networking technologies.

I don't see what the "huge number of roots" has to do with this issue.

> 2) As a creator of YANG models, how do I know the targets for references
>> such that I capture references to the elements that I want, given there is
>> no currently defined structure?
>>
> The modules you are using have data locations defined.
> In order to define YANG data (with YANG 1.0 or 1.1)
> a top-level data node or augment-stmt will be present specifying the
> /path/from/root
>
> How do you know where data is that has not been defined yet?
> You don't and YANG has no ability to reference undefined data anyway.
>
> Consider VRRP ‘tracking’. I want to be able to add some form of new thing
> that VRRP might track. If we’ve defined a structure that says that there is
> some list of ‘tracking-objects’ that I can leafref to, then my new OAM
> mechanism can augment there. If there is no such structure, then we cannot
> do that, and rather the VRRF model only leafrefs to the currently known
> paths (my ‘track’ leaf has explicit leafref to a subset of ‘ping’ and known
> continuity checks when I wrote the module). Adding the new OAM mechanism
> then means a new version of the VRRP module - which seems suboptimal. The
> first approach is cleaner, but needs someone to define the structure such
> that we get it right.
>

No matter what set of NP containers you create, there might be stuff that
could
reasonably be put in different places.  So what?  This is part of the
design choice
when picking the one true home for everything.

The structure is ad-hoc and arbitrary.  Its only value is in the
common agreement of where things should go.  So make up
some structure and fill it in.  What's the problem?

Nothing whatsoever is stopping the routing area from defining some structure
> for new modules.  Pick whatever you like.
>
> The only pushback is wrt/ obsoleting existing RFC modules and moving the
> data nodes in them to a different location. Some of us do not agree that
> a problem has been demonstrated that warrants starting over for these RFCs.
>
> Defining structure with arbitrary subsets of the tree doesn’t help! As an
> operator I want to be able to configure a device, because this is what my
> network is built from. Not IETF areas.
>
> Do you suggest that the existing models are placed as a constraint on any
> new work in YANG? If so, I’d be grateful if you can point out to me what
> the precedent is to show that they are useful in the real world?
>

I have not seen any evidence that moving /interfaces, /interfaces-state,
/nacm, /netconf-state, /netconf, /ipfix, /system and /snmp will solve any
real problems.
There are implementations of these modules already.

Are you suggesting that work the new routing modules cannot proceed
because these 8 top-level nodes are somehow preventing this work?
Are you suggesting it would solve your OAM or VRRP design problems
if the path was /device/interfaces instead of just /interfaces?

Kind regards,
> r.
>
>
Andy
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Motivations for Structuring Models

On Thu, Aug 27, 2015 at 11:14 AM, Nadeau Thomas 
wrote:

>
> On Aug 27, 2015:1:59 PM, at 1:59 PM, Andy Bierman 
> wrote:
>
>
>
> On Thu, Aug 27, 2015 at 10:39 AM, Rob Shakir  wrote:
>
>>
>> Andy,
>>
>> Apologies, I don’t understand how your mail answers the questions that I
>> posed.
>>
>> On August 27, 2015 at 12:25:20, Andy Bierman (a...@yumaworks.com) wrote:
>>
>> A whole lots of words here, but I am still confused why /device is better
>> than /
>> for solving your "data model awareness" problem.
>>
>> Please re-read my email - here’s the single statement where I said that
>> this was NOT the discussion that I think is important:
>>
>> It strikes me that there is a need to take a step back from the debate of
>>> whether /device is a good idea or not.
>>>
>> I’m not sure how this could be clearer.
>>
>>
> Sorry -- are you suggesting that maybe /device adds no value beyond /?
> If so, I agree.
>
>
>
>> YANG is no different than any other part of the source code.
>> Reusable YANG is just as likely or unlikely as reusable C,
>> depending on how aware people are of the existing code base.
>>
>> Which OAM? Read the modules and decide. No magic there.
>> How would /device vs / (as the first node) help you figure this out?
>>
>> Nobody is objecting at all to creating structure for the new modules.
>> If /device has siblings, then let's see them in the uber-tree.
>> The objection is to adding in a useless layer, and moving existing
>> data nodes, which breaks existing implementations of all those data nodes.
>>
>> Please suggest an alternate approach to the one that is laid out in
>> draft-openconfig-netmod-model-structure that you believe will help with the
>> two problems that I raised. I’ll rephrase them here with less explanation,
>> albeit that comes with less clarity.
>>
>> 1) As a consumer of YANG models, how do I identify the set of models that
>> provide a set of functionality? How do YANG model writers ensure that their
>> models are as easy to deal with as possible by having consistent modelling
>> approaches for config?
>>
>
> RTFM
>
>
> Andy,
>
> While it might be frustrating, coming to an understanding of what the
> problem is or might be, and then looking at
> why the existing mechanisms/models or additional ones solve these
> requirements (or do not) is what is at hand.  I think everyone agreed
> at the interim meeting that the requirements were clear and sound.  This
> is detailed in the meeting minutes.  If anyone disputes this,
> I am happy to do an official WG call for consensus on these specifics, but
> given the unanimous agreement at the meeting, I did
> not feel that it was necessary to do this.  Based on that, the next
> question is: are these problems solved with what is here today,
> or do we need another approach/es.  Rob is clearly not an idiot and is
> asking for detailed reasons why you and others
> believe what he/OpenConfig have proposed is insufficient. Please be as
> considerate and constructive as he has been in asking his
> questions when you address them.
>
>
Are you suggesting that the openconfig drafts offer some solution
to "how do I use this YANG module" that does not involve reading the YANG
module?
If so, I didn't see it.  Please point it out to us.

My only objection is to moving data that has already been published in an
RFC.
I am not the only person on this list that has questioned to value of
moving this small number of data models to new roots in the data tree.

Everything done in an IETF meeting needs to be confirmed on
the mailing list.  You know that.

So what specifics are you ready to declare have WG consensus?




—Tom (Speaking as Co-chair)
>
>
>
Andy


> 2) As a creator of YANG mode
>>
> ls, how do I know the targets for references such that I capture
>> references to the elements that I want, given there is no currently defined
>> structure?
>>
>
>
> The modules you are using have data locations defined.
> In order to define YANG data (with YANG 1.0 or 1.1)
> a top-level data node or augment-stmt will be present specifying the
> /path/from/root
>
> How do you know where data is that has not been defined yet?
> You don't and YANG has no ability to reference undefined data anyway.
>
>
> “Just read through the modules” is not acceptable answer when considering
>> making things easy to use for YANG model consumers. I want to have things
>> that are logical to humans such that they can easily adopt YANG-based
>> netmgmt. If they need to adopt the ecosystem by having to use hodgepodge
>> approaches, then this feels like we are fundamentally missing an
>> opportunity to simplify things.
>>
>
>
> Why isn't RTFM good enough?
> Is there some expectation that just /the/path/from/root is enough
> to make somebody an expert in managing some feature or an expert
> in writing new YANG modules?
>
> Additional tools outside the scope of IETF standardization work are needed
> to make development easier.
>
> Nothing whatsoever is stopping the routing area from defining som

Re: [netmod] Motivations for Structuring Models

Hi Andy,

I’m struggling with this debate.
On August 27, 2015 at 13:59:55, Andy Bierman (a...@yumaworks.com) wrote:


Sorry -- are you suggesting that maybe /device adds no value beyond /?
If so, I agree.
No, I am suggesting that should understand what the alternatives to solving 
issues are, before moving on to debating the merits of a particular solution 
that has nothing to compare and contrast against.

One container does not add value, the structure (which happens to start with 
/device in ONE proposal, to which there are no alternates) is what matters. 
Unfortunately you seem to be stuck on this container. Please ignore it and 
focus on the problems I defined.

 RTFM
Great. So, I need to go and write a bunch of different implementations of how 
to set up a ping, and trawl through a huge number of roots to find things that 
are related. If this is the approach we take with IETF modules, then they will 
be worse to use than the existing configuration approaches that we have. At 
least the vendor specific ones have some form of logic as to how they are 
usable to consumers.

2) As a creator of YANG models, how do I know the targets for references such 
that I capture references to the elements that I want, given there is no 
currently defined structure?

The modules you are using have data locations defined.
In order to define YANG data (with YANG 1.0 or 1.1)
a top-level data node or augment-stmt will be present specifying the 
/path/from/root

How do you know where data is that has not been defined yet?
You don't and YANG has no ability to reference undefined data anyway.
Consider VRRP ‘tracking’. I want to be able to add some form of new thing that 
VRRP might track. If we’ve defined a structure that says that there is some 
list of ‘tracking-objects’ that I can leafref to, then my new OAM mechanism can 
augment there. If there is no such structure, then we cannot do that, and 
rather the VRRF model only leafrefs to the currently known paths (my ‘track’ 
leaf has explicit leafref to a subset of ‘ping’ and known continuity checks 
when I wrote the module). Adding the new OAM mechanism then means a new version 
of the VRRP module - which seems suboptimal. The first approach is cleaner, but 
needs someone to define the structure such that we get it right.

Nothing whatsoever is stopping the routing area from defining some structure
for new modules.  Pick whatever you like.

The only pushback is wrt/ obsoleting existing RFC modules and moving the
data nodes in them to a different location. Some of us do not agree that
a problem has been demonstrated that warrants starting over for these RFCs.
Defining structure with arbitrary subsets of the tree doesn’t help! As an 
operator I want to be able to configure a device, because this is what my 
network is built from. Not IETF areas.

Do you suggest that the existing models are placed as a constraint on any new 
work in YANG? If so, I’d be grateful if you can point out to me what the 
precedent is to show that they are useful in the real world?

Kind regards,
r.
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Motivations for Structuring Models

2015-08-27 Thread Nadeau Thomas


> On Aug 27, 2015:1:59 PM, at 1:59 PM, Andy Bierman  wrote:
> 
> 
> 
> On Thu, Aug 27, 2015 at 10:39 AM, Rob Shakir  > wrote:
> 
> Andy,
> 
> Apologies, I don’t understand how your mail answers the questions that I 
> posed.
> 
> On August 27, 2015 at 12:25:20, Andy Bierman (a...@yumaworks.com 
> ) wrote:
> 
>> A whole lots of words here, but I am still confused why /device is better 
>> than /
>> for solving your "data model awareness" problem.
> 
> Please re-read my email - here’s the single statement where I said that this 
> was NOT the discussion that I think is important:
> 
>> It strikes me that there is a need to take a step back from the debate of 
>> whether /device is a good idea or not.
>> 
> 
> I’m not sure how this could be clearer.
> 
> 
> Sorry -- are you suggesting that maybe /device adds no value beyond /?
> If so, I agree.
> 
>  
>> YANG is no different than any other part of the source code.
>> Reusable YANG is just as likely or unlikely as reusable C,
>> depending on how aware people are of the existing code base.
>> 
>> Which OAM? Read the modules and decide. No magic there.
>> How would /device vs / (as the first node) help you figure this out?
>> 
>> Nobody is objecting at all to creating structure for the new modules.
>> If /device has siblings, then let's see them in the uber-tree.
>> The objection is to adding in a useless layer, and moving existing
>> data nodes, which breaks existing implementations of all those data nodes.
> 
> Please suggest an alternate approach to the one that is laid out in 
> draft-openconfig-netmod-model-structure that you believe will help with the 
> two problems that I raised. I’ll rephrase them here with less explanation, 
> albeit that comes with less clarity.
> 
> 1) As a consumer of YANG models, how do I identify the set of models that 
> provide a set of functionality? How do YANG model writers ensure that their 
> models are as easy to deal with as possible by having consistent modelling 
> approaches for config?
> 
> 
> RTFM

Andy, 

While it might be frustrating, coming to an understanding of what the 
problem is or might be, and then looking at
why the existing mechanisms/models or additional ones solve these requirements 
(or do not) is what is at hand.  I think everyone agreed
at the interim meeting that the requirements were clear and sound.  This is 
detailed in the meeting minutes.  If anyone disputes this,
I am happy to do an official WG call for consensus on these specifics, but 
given the unanimous agreement at the meeting, I did
not feel that it was necessary to do this.  Based on that, the next question 
is: are these problems solved with what is here today, 
or do we need another approach/es.  Rob is clearly not an idiot and is asking 
for detailed reasons why you and others
believe what he/OpenConfig have proposed is insufficient. Please be as 
considerate and constructive as he has been in asking his
questions when you address them. 

—Tom (Speaking as Co-chair)


> 2) As a creator of YANG mode
> 
> ls, how do I know the targets for references such that I capture references 
> to the elements that I want, given there is no currently defined structure?
> 
> 
> 
> The modules you are using have data locations defined.
> In order to define YANG data (with YANG 1.0 or 1.1)
> a top-level data node or augment-stmt will be present specifying the 
> /path/from/root
> 
> How do you know where data is that has not been defined yet?
> You don't and YANG has no ability to reference undefined data anyway.
> 
> 
> “Just read through the modules” is not acceptable answer when considering 
> making things easy to use for YANG model consumers. I want to have things 
> that are logical to humans such that they can easily adopt YANG-based 
> netmgmt. If they need to adopt the ecosystem by having to use hodgepodge 
> approaches, then this feels like we are fundamentally missing an opportunity 
> to simplify things.
> 
> 
> 
> Why isn't RTFM good enough?
> Is there some expectation that just /the/path/from/root is enough
> to make somebody an expert in managing some feature or an expert
> in writing new YANG modules?
> 
> Additional tools outside the scope of IETF standardization work are needed
> to make development easier.
> 
> Nothing whatsoever is stopping the routing area from defining some structure
> for new modules.  Pick whatever you like.
> 
> The only pushback is wrt/ obsoleting existing RFC modules and moving the
> data nodes in them to a different location. Some of us do not agree that
> a problem has been demonstrated that warrants starting over for these RFCs.
> 
> 
> I want to make sure that we DO have re-usable YANG - like we have re-usable 
> code elsewhere. In my experience this is done elsewhere by defining 
> conventions that ensure that this is the case. 
> 
> 
> Regards,
> r.
> 
> 
> Andy
> 
> ___
> netmod mailing

Re: [netmod] Motivations for Structuring Models

On Thu, Aug 27, 2015 at 10:39 AM, Rob Shakir  wrote:

> Andy,
>
> Apologies, I don’t understand how your mail answers the questions that I
> posed.
>
> On August 27, 2015 at 12:25:20, Andy Bierman (a...@yumaworks.com) wrote:
>
> A whole lots of words here, but I am still confused why /device is better
> than /
> for solving your "data model awareness" problem.
>
> Please re-read my email - here’s the single statement where I said that
> this was NOT the discussion that I think is important:
>
> It strikes me that there is a need to take a step back from the debate of
>> whether /device is a good idea or not.
>>
> I’m not sure how this could be clearer.
>
>
Sorry -- are you suggesting that maybe /device adds no value beyond /?
If so, I agree.



> YANG is no different than any other part of the source code.
> Reusable YANG is just as likely or unlikely as reusable C,
> depending on how aware people are of the existing code base.
>
> Which OAM? Read the modules and decide. No magic there.
> How would /device vs / (as the first node) help you figure this out?
>
> Nobody is objecting at all to creating structure for the new modules.
> If /device has siblings, then let's see them in the uber-tree.
> The objection is to adding in a useless layer, and moving existing
> data nodes, which breaks existing implementations of all those data nodes.
>
> Please suggest an alternate approach to the one that is laid out in
> draft-openconfig-netmod-model-structure that you believe will help with the
> two problems that I raised. I’ll rephrase them here with less explanation,
> albeit that comes with less clarity.
>
> 1) As a consumer of YANG models, how do I identify the set of models that
> provide a set of functionality? How do YANG model writers ensure that their
> models are as easy to deal with as possible by having consistent modelling
> approaches for config?
>

RTFM



> 2) As a creator of YANG models, how do I know the targets for references
> such that I capture references to the elements that I want, given there is
> no currently defined structure?
>


The modules you are using have data locations defined.
In order to define YANG data (with YANG 1.0 or 1.1)
a top-level data node or augment-stmt will be present specifying the
/path/from/root

How do you know where data is that has not been defined yet?
You don't and YANG has no ability to reference undefined data anyway.


“Just read through the modules” is not acceptable answer when considering
> making things easy to use for YANG model consumers. I want to have things
> that are logical to humans such that they can easily adopt YANG-based
> netmgmt. If they need to adopt the ecosystem by having to use hodgepodge
> approaches, then this feels like we are fundamentally missing an
> opportunity to simplify things.
>


Why isn't RTFM good enough?
Is there some expectation that just /the/path/from/root is enough
to make somebody an expert in managing some feature or an expert
in writing new YANG modules?

Additional tools outside the scope of IETF standardization work are needed
to make development easier.

Nothing whatsoever is stopping the routing area from defining some structure
for new modules.  Pick whatever you like.

The only pushback is wrt/ obsoleting existing RFC modules and moving the
data nodes in them to a different location. Some of us do not agree that
a problem has been demonstrated that warrants starting over for these RFCs.


I want to make sure that we DO have re-usable YANG - like we have re-usable
> code elsewhere. In my experience this is done elsewhere by defining
> conventions that ensure that this is the case.
>
> Regards,
> r.
>
>
Andy
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Motivations for Structuring Models

Lada,


On August 27, 2015 at 12:54:39, Ladislav Lhotka (lho...@nic.cz) wrote:

We certainly need *some* structure, and since there was a requirement to 
support multiple routing instances, a list of them seems natural. 
Great, we agree that we need some structure like we have for routing elsewhere.

Can you point me towards any proposal other than 
draft-openconfig-netmod-model-structure or 
draft-rtgyangdt-rtgwg-device-model–00 for this structure?

Already, implementors are having problems with this - because existing modules 
that are pretty mature (ietf-bgp for example), need more functionality than is 
in ietf-routing to make usable multi-VRF systems, let alone 
multi-routing-instance. If there were some structure, we could understand how 
these models need to be augmented to support the use cases. I’ll come back to 
the case of how I configure something that is a L2 virtual forwarding instance, 
that uses has a L3 IP interface within it.

On the latter comments in your mail, I place little importance on obsoleting 
existing RFCs, I care about:

Primarily: whether the existing models let me configure things that I need to 
on my network (or form a suitable base for doing so).
Secondary: impact to existing implementations where these models are actually 
usable to some external consumer.
Kind regards,
r.

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Motivations for Structuring Models

Andy,

Apologies, I don’t understand how your mail answers the questions that I posed.

On August 27, 2015 at 12:25:20, Andy Bierman (a...@yumaworks.com) wrote:

A whole lots of words here, but I am still confused why /device is better than /
for solving your "data model awareness" problem.
Please re-read my email - here’s the single statement where I said that this 
was NOT the discussion that I think is important:

It strikes me that there is a need to take a step back from the debate of 
whether /device is a good idea or not.

I’m not sure how this could be clearer.

YANG is no different than any other part of the source code.
Reusable YANG is just as likely or unlikely as reusable C,
depending on how aware people are of the existing code base.

Which OAM? Read the modules and decide. No magic there.
How would /device vs / (as the first node) help you figure this out?

Nobody is objecting at all to creating structure for the new modules.
If /device has siblings, then let's see them in the uber-tree.
The objection is to adding in a useless layer, and moving existing
data nodes, which breaks existing implementations of all those data nodes.
Please suggest an alternate approach to the one that is laid out in 
draft-openconfig-netmod-model-structure that you believe will help with the two 
problems that I raised. I’ll rephrase them here with less explanation, albeit 
that comes with less clarity.

1) As a consumer of YANG models, how do I identify the set of models that 
provide a set of functionality? How do YANG model writers ensure that their 
models are as easy to deal with as possible by having consistent modelling 
approaches for config?

2) As a creator of YANG models, how do I know the targets for references such 
that I capture references to the elements that I want, given there is no 
currently defined structure?

“Just read through the modules” is not acceptable answer when considering 
making things easy to use for YANG model consumers. I want to have things that 
are logical to humans such that they can easily adopt YANG-based netmgmt. If 
they need to adopt the ecosystem by having to use hodgepodge approaches, then 
this feels like we are fundamentally missing an opportunity to simplify things.

I want to make sure that we DO have re-usable YANG - like we have re-usable 
code elsewhere. In my experience this is done elsewhere by defining conventions 
that ensure that this is the case. 

Regards,
r.
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Motivations for Structuring Models

2015-08-27 Thread Ladislav Lhotka

> On 27 Aug 2015, at 17:30, Rob Shakir  wrote:
> 
> 
> Hi Lada,
> 
> 
> Thanks for the reply.
> On August 27, 2015 at 11:21:18, Ladislav Lhotka (lho...@nic.cz) wrote:
> 
>> This one is actually easy to explain, exactly as the top-level container 
>> "interfaces" in ietf-interfaces: it is a courtesy to XML encoding. 
> Apologies, I’m not sure my question was clear enough. The point was, why do 
> we need a model that defines a structure for routing if one that defines a 
> structure for device is not useful?

We certainly need *some* structure, and since there was a requirement to 
support multiple routing instances, a list of them seems natural.

In the past we also discussed the option of defining a common root for all 
configuration but we came to the conclusion that it is not needed.

Choices have been made and in some cases an alternative design could certainly 
be usable, too. However, since some of the models already became RFCs, 
convincing technical argument are needed to throw them away and go back to 
square 1. And I also think that moving from / to /device isn’t of that category.

Lada  

> 
> 
> Thanks,
> r

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

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Y34 - root node

2015-08-27 Thread t . petch

- Original Message -
From: "Lou Berger" 
To: "Juergen Schoenwaelder" 
Cc: "t. petch" ; "Martin Bjorklund"
; 
Sent: Thursday, August 27, 2015 12:27 PM
> On 08/27/2015 02:42 AM, Juergen Schoenwaelder wrote:
> >> The flat sea of YANG modules brings a different set of issues and I
> >> > am unsure what they are;
> >
> > This is main problem I have. What the heck is the problem we are
trying
> > to fix?
> >
>
> The first, but not only problem, is today's ~200 top level models
> (looking at current RFCs and I-Ds) with little apparent organization
or
> inter-relationship.

Lou

yes, but so what:-)

I do share Juergen's view here of what is the problem.  Earlier this
year, the focus was on presenting a coherent picture to the user and
Randy rightly pointed out that it took expert writers of NMS to bring
together data from mulitple modules to give the user a coherent display;
or it took expert writers of DDLs to produce modules that brought the
data together so that the writer of NMS have an easier task -  either
way, it needs experts and I do not see YANG being that different from
SMI in that regard.  Likely 'augments' will be used more so that YANG
will have more defined interrelationships in the DDL than SMI but not
enough to produce a coherent picture.

I do not see the benefit, in this or other regards, of placing YANG
modules in a tree, or in multiple trees.  What is the audience that will
benefit from that?

I do see the flat sea of modules as reflecting the way in which the IETF
works, in a loose federation, so that even within an Area, such as
Routing, you would not expect OSPF, say, to be au fait with MPLS, say;
so when they create their modules, they may not well dovetail as well as
they might but that is the way that the IETF is

Tom Petch

ps I have other concerns, but I have said enough about those lately so I
think about them some more

> Lou

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Motivations for Structuring Models

On Thu, Aug 27, 2015 at 6:56 AM, Rob Shakir  wrote:

> NETMOD,
>
> One of the chairs encouraged me to post this to the list. I didn’t really
> find how it fits in to the existing threads, but I wanted to make an
> observation.
>
> It strikes me that there is a need to take a step back from the debate of
> whether /device is a good idea or not.
>
> As a *user* of something that results from compiling/generating bindings
> from a YANG model, I have two requirements:
>
>- I need to be able to compose the right modules to be able to get the
>functionality that that the thing I’m trying to configure uses.
>   - Let’s say I want to configure some OAM continuity checking
>   functions - for both MPLS and IP.
>   - Right now, I have the choice of ‘ietf-lspping’ which defines
>   /lsp-pings, then ‘mplstp-oam’ which defines /mplstp-oam. Presumably then
>   we’ll have ‘ietf-ip-oam’ and then ‘ietf-ipv6-oam’.
>   - As a developer - how do I figure out which models I need to build
>   my OAM function. Do I have to trawl some directory to find all of the
>   different fragments of OAM?
>   - Do I then need to accept the complexity of dealing with the fact
>   that the structures of LSP pings is completely different to the IP OAM
>   structures? [Given that there is no co-ordination of models, then this
>   *will* happen.]
>- As someone that is building YANG models, how do I know where I
>should leaf-ref too.
>   - Let’s say I want to tie an OAM probe to some protocol liveliness
>   - where do I point my leafref to? At the moment, without *some*
>   structure, than any path that is specified is pointing to some 
> placeholder
>   location, until we agree where the structure might sit.
>
> On the first issue here, it strikes me that this is what ietf-routing is
> doing. It is placing a set of models under some root node which happens to
> be /routing. If we don’t need /device, then why do we need /routing?
>
> The other point here, is that it is entirely unclear how ietf-routing
> actually fits in to the structure. I can configure L3 protocols here,
> great. But what happens when the ‘instance’ that I create has L2 protocols
> too (e.g., is a VPLS with a routed L3 interface in it), or is a mix of the
> two? ietf-routing doesn’t help me here - but there’s no overall structure
> that tells me what should fit in. If we have *some structure* then we can
> start to define what models should do what such that they are actually
> usable to people who want to build things via YANG models.
>
> I would also observe that of the vendor implementations of YANG models I
> have looked at already, almost all define some form of structure of the
> data within them. In addition, the OSS tools that I’ve looked at that help
> interact with devices via NETCONF/YANG do the same thing.
>
> When I originally drew the tree that was iterated on to form
> openconfig-model-structure, the reason to draw it was not to create some
> ‘/device’ node. It was to answer the two questions above. Reviewing Section
> 1 of draft-openconfig-netmod-model-structure, these problems are again
> drawn out.
>
> The issue of the IETF here is that we are solutions-driven. It is
> difficult to bring this ‘challenge’ to the IETF without bringing a
> solution. I first raised these points with one of the routing ADs almost a
> year ago. I had found that in our attempts to define any form of models for
> higher-layer functions in the systems we were debating at the time, we
> needed an architecture for the models at that layer. The same thing is
> needed at the device layer - the draft I presented in Dallas is an attempt
> to suggest a possible solution for the challenges I outlined above.
>
> So. Please can we take a step back and figure out if the IETF is
> interested in building models that are usable to the consumers of them?
>
> To me, this means debating solutions for the two questions above, and then
> figuring out how to support that structure.
>
> If we don’t solve this issue in the IETF, then efforts elsewhere that are
> more usable to developers will probably have to remain separate.
>
>


A whole lots of words here, but I am still confused why /device is better
than /
for solving your "data model awareness" problem.

YANG is no different than any other part of the source code.
Reusable YANG is just as likely or unlikely as reusable C,
depending on how aware people are of the existing code base.

Which OAM? Read the modules and decide. No magic there.
How would /device vs / (as the first node) help you figure this out?

Nobody is objecting at all to creating structure for the new modules.
If /device has siblings, then let's see them in the uber-tree.
The objection is to adding in a useless layer, and moving existing
data nodes, which breaks existing implementations of all those data nodes.




> Just my £0.0002,
> r.
>
>
>
Andy


>
>
> ___
> n

Re: [netmod] Motivations for Structuring Models

Hi Lada,

Thanks for the reply.
On August 27, 2015 at 11:21:18, Ladislav Lhotka (lho...@nic.cz) wrote:

This one is actually easy to explain, exactly as the top-level container 
"interfaces" in ietf-interfaces: it is a courtesy to XML encoding. 
Apologies, I’m not sure my question was clear enough. The point was, why do we 
need a model that defines a structure for routing if one that defines a 
structure for device is not useful?

Thanks,
r
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Motivations for Structuring Models

2015-08-27 Thread Ladislav Lhotka

Hi Rob,

Rob Shakir  writes:

> On the first issue here, it strikes me that this is what ietf-routing
> is doing. It is placing a set of models under some root node which
> happens to be /routing. If we don’t need /device, then why do we need
> /routing?

This one is actually easy to explain, exactly as the top-level container
"interfaces" in ietf-interfaces: it is a courtesy to XML encoding.

In both cases, a list is just below the top-level container. If the
top-level container wasn't there we could see interleaved entries of
both lists in XML encoding, for example

...
...
...
...
...

This was considered problematic, so the top-level containers were added
to avoid this.

Note that this is not an issue in JSON encoding where all entries of a
list are neatly organised in an array:

"interface": [{...}, {...}, {...}]
"routing-instance": [{...}, {...}]

Cheers, Lada

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

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] Motivations for Structuring Models

2015-08-27 Thread Martin Ciglan -X (mciglan - PANTHEON TECHNOLOGIES at Cisco)

NETMOD,

One of the chairs encouraged me to post this to the list. I didn’t really find 
how it fits in to the existing threads, but I wanted to make an observation.

It strikes me that there is a need to take a step back from the debate of 
whether /device is a good idea or not.

As a user of something that results from compiling/generating bindings from a 
YANG model, I have two requirements:

I need to be able to compose the right modules to be able to get the 
functionality that that the thing I’m trying to configure uses.
Let’s say I want to configure some OAM continuity checking functions - for both 
MPLS and IP.
Right now, I have the choice of ‘ietf-lspping’ which defines /lsp-pings, then 
‘mplstp-oam’ which defines /mplstp-oam. Presumably then we’ll have 
‘ietf-ip-oam’ and then ‘ietf-ipv6-oam’.
As a developer - how do I figure out which models I need to build my OAM 
function. Do I have to trawl some directory to find all of the different 
fragments of OAM?
Do I then need to accept the complexity of dealing with the fact that the 
structures of LSP pings is completely different to the IP OAM structures? 
[Given that there is no co-ordination of models, then this will happen.]
As someone that is building YANG models, how do I know where I should leaf-ref 
too.
Let’s say I want to tie an OAM probe to some protocol liveliness - where do I 
point my leafref to? At the moment, without some structure, than any path that 
is specified is pointing to some placeholder location, until we agree where the 
structure might sit.
On the first issue here, it strikes me that this is what ietf-routing is doing. 
It is placing a set of models under some root node which happens to be 
/routing. If we don’t need /device, then why do we need /routing?

The other point here, is that it is entirely unclear how ietf-routing actually 
fits in to the structure. I can configure L3 protocols here, great. But what 
happens when the ‘instance’ that I create has L2 protocols too (e.g., is a VPLS 
with a routed L3 interface in it), or is a mix of the two? ietf-routing doesn’t 
help me here - but there’s no overall structure that tells me what should fit 
in. If we have some structure then we can start to define what models should do 
what such that they are actually usable to people who want to build things via 
YANG models.

I would also observe that of the vendor implementations of YANG models I have 
looked at already, almost all define some form of structure of the data within 
them. In addition, the OSS tools that I’ve looked at that help interact with 
devices via NETCONF/YANG do the same thing.

When I originally drew the tree that was iterated on to form 
openconfig-model-structure, the reason to draw it was not to create some 
‘/device’ node. It was to answer the two questions above. Reviewing Section 1 
of draft-openconfig-netmod-model-structure, these problems are again drawn out.

The issue of the IETF here is that we are solutions-driven. It is difficult to 
bring this ‘challenge’ to the IETF without bringing a solution. I first raised 
these points with one of the routing ADs almost a year ago. I had found that in 
our attempts to define any form of models for higher-layer functions in the 
systems we were debating at the time, we needed an architecture for the models 
at that layer. The same thing is needed at the device layer - the draft I 
presented in Dallas is an attempt to suggest a possible solution for the 
challenges I outlined above.

So. Please can we take a step back and figure out if the IETF is interested in 
building models that are usable to the consumers of them?

To me, this means debating solutions for the two questions above, and then 
figuring out how to support that structure.

If we don’t solve this issue in the IETF, then efforts elsewhere that are more 
usable to developers will probably have to remain separate.

Just my £0.0002,
r.



___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Y34 - root node

2015-08-27 Thread Ambika Prasad Tripathy (ambtripa)

IMHO, there should a YANG Construct should allow modules to be reused within 
another module with a restriction of looping.

When the YANG modules organized at controller, or any manager, re use of 
grouping or a particular XPath mount makes life static in YANG. 

Br,
Ambika Prasad Tripathy (ambtripa)
-Original Message-
From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Lou Berger
Sent: Thursday, August 27, 2015 6:30 PM
To: Andy Bierman; Juergen Schoenwaelder; t. petch; Martin Bjorklund; 
netmod@ietf.org
Subject: Re: [netmod] Y34 - root node

On 8/27/2015 8:23 AM, Andy Bierman wrote:
>
> I don't see the 6 modules that have already been published so far in 
> RFCs as the problem.  I suggest focusing on the 194 modules that have 
> not been published.

100% agree
>   Should the IETF spend a year or two debating the ONE TRUE PERFECT 
> uber-tree? 6 months?
No, IMO we should take a stab at it and go with our best understanding and 
consensus -- that is after all what the I*E*TF is all about.

> How long will it take for all interested vendors to agree where every 
> little thing goes, before starting on any of it.
>

The DT's proposal seems to be a consensus starting point (from my DT and
individual perspective, based on *many* discussions with vendors and
users) in at least the routing area.  Outside the routing area, I've
heard three or four individual objections.  Not saying we have it right,
but just that we have a solid start.

Lou

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Y34 - root node

2015-08-27 Thread Lou Berger

On 8/27/2015 8:23 AM, Andy Bierman wrote:
>
> I don't see the 6 modules that have already been published so far in RFCs
> as the problem.  I suggest focusing on the 194 modules that have not
> been published.

100% agree
>   Should the IETF spend a year or two debating the ONE TRUE
> PERFECT uber-tree? 6 months?
No, IMO we should take a stab at it and go with our best understanding
and consensus -- that is after all what the I*E*TF is all about.

> How long will it take for all interested
> vendors to agree where every little thing goes, before starting on any
> of it.
>

The DT's proposal seems to be a consensus starting point (from my DT and
individual perspective, based on *many* discussions with vendors and
users) in at least the routing area.  Outside the routing area, I've
heard three or four individual objections.  Not saying we have it right,
but just that we have a solid start.

Lou

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] issue and question: YANG short-case-stmt in augment-stmt or uses-augment-stmt

Hi Ladislav

Thanks for the asnwer.
I've realized that leaf stmt in augment is parsed as data-def-stmt, not 
short-case-stmt (even though it is augmented to choice), 
so all is valid according to RFC6020.

   Best Regards

  Martin

Od: Ladislav Lhotka [lho...@nic.cz]
Odoslané: 25. augusta 2015 15:06
Do: Martin Ciglan -X (mciglan - PANTHEON TECHNOLOGIES at Cisco); netmod@ietf.org
Predmet: Re: [netmod] issue and question: YANG short-case-stmt in augment-stmt 
or uses-augment-stmt

Hi Martin,

as far as I can tell, these groupings are OK, and pyang also doesn't
complain.

Ahoj, Láďa

"Martin Ciglan -X (mciglan - PANTHEON TECHNOLOGIES at Cisco)"
 writes:

> Hello
>
> I've come across a yang module which defines a short-case-stmt in 
> augment-stmt or uses-augment-stmt
>
> Something like this:
>
> grouping grp1 {
>   uses grp2 {
> augment mychoice {
>   leaf myleaf1 {
> type string;
>  }
>}
>  }
>   }
>
>   grouping grp2 {
> choice mychoice {
>   leaf myleaf2 {
> type string;
>   }
> }
>   }
>
> Based on my findings in RFC6020 and errata, this is invalid and there should 
> be only full case-stmt in augment/uses-augment.
>
> Can you confirm please? Many thanks in advance.
>
> Best Regards
>
> Martin
>
>
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

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

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Y34 - root node