[NGO] Re: [YANG] YANG augment-stmt

[Martin Bjorklund <[e-mail]>]

Andy Bierman <[e-mail]> wrote:
> Martin Bjorklund wrote:
> > Andy Bierman <[e-mail]> wrote:
> >> Hi,
> >>
> >> Looking at the ABNF for the all-powerful augment statement,
> >> I notice it can appear inside a list or inside an another augment,
> >> anywhere a data-def-stmt can go in fact.
> >>
> >> Since this clause does not instantiate any data where it
> >> located, but rather at the target specified by the augment-arg-str,
> >> the containment for the augment seems pretty much irrelevant,
> >> except that the augment could be nested within N different 'when'
> >> statements, nested inside obsolete nodes, etc.
> >>
> >> The key in a list with an augment-stmt has no affect on the target data,
> >> does it?
> > 
> > I'm not sure I understand this question.
> > 
> 
> 
> It seems strange to me to define an augment of 'some' other data
> in a potentially different namespace, in the middle of the constructs
> that define named list entries.

But this isn't allowed.  Only top-level augments can have absolute
paths to augment.  "Nested" augments MUST have descendant paths.

> I'm not clear on the use-case,
> which is why I cc:ed the NGO list.  We need to agree on the requirements
> for data model augmentation, just like every other part of
> standard NETCONF content.

Ok.


> >> What does it mean to have an augment inside a grouping, so that
> >> it is copied everywhere a 'uses' for that grouping is specified?
> >>
> >> What is the use-case for augment inside augment?
> > 
> > The use case for augment inside anything but on the top-level is to be
> > used in combination with 'uses'.  The idea is that you can do 'uses
> > foo', and then in a following augment add new nodes to the foo
> > grouping:
> > 
> >   grouping server {
> >     leaf name { type string; }
> >     container address {
> >       leaf ip { type inet:ip-address; }
> >     }
> >   }
> > 
> >   container foo {
> >     uses server;
> >     augment address {
> >       leaf port { type inet:port-number; } 
> >     }
> >   }
> 
> Is this right? Don't you mean:
> 
>     container foo {
>       uses server {
>         augment address {
>           leaf port { type inet:port-number; }
>         }
>       }
>     }

No, augment within a uses is not allowed.  I do see your point though
- if the use case is to allow augment of a 'uses', why not put the
augment within the uses.  The problem with this, as I see it, is that
it might be confusing b/c all the other stmts with 'uses' are
refinements of stmts found in the grouping.

> I understand this use-case, where the descendant-schema-nodeid
> is the target, instead of an absolute-schema-nodeid.
> 
> I still don't see any use-case for augment-within-augment,

  augment /foo/bar {
    uses my-grouping; // defines a container 'baz'
    augment baz {
      leaf xxx { ... }
    }
  }

> or allowing nested augments to modify data structures outside
> their parent node.

No, that is not allowed.

> >> That means while you are defining extra data to attach to /acme:foo
> >> you also define some extra data for /a:bar/b:baz?
> > 
> > Yes.
> 
> Why is this a feature, and what is it needed for?

Sorry.  My "Yes" should have been "No!!".


> We should base the solution (DML) on the agreed-upon requirements.
> The requirements should be based upon real use-cases.

Absolutely.

> IMO, there is a need for top-level augment clauses that name the target
> with an absolute path expression, as well as nested augment clauses
> that extend the data within their containment node (container, list,
> choice/case-foo, rpc/input, rpc/output, notification).  It is
> the DM writers choice which form to use.
> 
> You should use descendant form if 'when' clauses exist in any
> ancestor nodes, instead of replicating the effective Xpath 'when'
> expression for a top-level clause.

I don't see how this has anything to do with 'when'...?

> It boils down to 1 simple CLR:
> 
>     A top-level augment-stmt must use the absolute form,
>     and a nested augment-stmt must use the descendant form
>     of the schema-nodeid target of the augmentation.
>     (A top-level augment-stmt has no context for descendants.)

This is already in the draft.

> The ABNF does not reflect this, or that only a choice augment
> can use the case-stmt, or only an RPC augment can use the
> input-stmt | output-stmt.

Yes you're right, we should make this change in the ABNF.  Currently
it's just in the text.


/martin


_______________________________________________
NGO mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ngo