Martin,

We are almost certainly not on the same page as to what we're debating.
Martin Bjorklund <mailto:m...@tail-f.com>
August 28, 2015 at 08:55
<https://www.postbox-inc.com/?utm_source=email&utm_medium=sumlink&utm_campaign=reach>

Ok.  So your proposal doesn't help with the problem of locating
relevant YANG modules, but once their located, it is easier to find
the ones related to a specific function, b/c they would augment a
common path.  Is this what you mean?
Having a structure to the way that the tree is defined helps a developer trying to consume functions find the relevant functionality. The model-writer needs to be aware of this structure. I think there is an important difference between model writer (not very many of these), and model consumer (lots of these).

But this is the what we have been arguing about!  Remove /device and
we can put this behind us and move forward.

So, if I take openconfig-model-structure and make it look like:

module: model-structure [NB: trimmed for legibility.]
      +--rw info
      +--rw hardware
      +--rw system
      +--rw interfaces
      +--rw acl
      +--rw qos
      +--rw logical-routers
         +--rw logical-router* [router-id]
            +--rw router-id            uint8
            +--rw router-name?         string
            +--rw layer-2-protocols
            +--rw layer-3-protocols
               +--rw vrf* [vrf-name]
               +--rw routing-policy

Then you have no objection to this approach? Even though it will *still* very likely obsolete RFC'd models, which don't fit into the structure.

I certainly do not have the impression that this is a common position from the other replies.

I reviewed this thread, and I'm just not sure that any of my responses say that the very top-level container is the most important thing. I even said this in the original post:

"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."

Rgds,
r.


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

Reply via email to