I do not understand your question, but the answer is likely 'no'.
See Martin's email, perhaps that one helps.
In RFC 7223, you can configure an interface that is not currently
present. An interface is identified by a name and the interface
configuration sits in the configuration datastore. When an interface
starts to exist (e.g., a line card is inserted) that has a matching
name, then the interface configuration with the same name is applied
to it. This is RFC 7223 style pre-provisioning.
/js
On Thu, Feb 02, 2017 at 09:48:26AM -0500, Susan Hares wrote:
> Lou and Juergen:
>
>
>
> Just to make sure I understand the pre-provisioning comment. What you are
> referring to is the “when” statements in the clause below.
>
>
>
> augment "/if:interfaces/if:interface" {
>
> when "if:type = 'ianaift:ethernetCsmacd'";
>
>
>
> // operational state parameters for Ethernet interfaces
> augment "/if:interfaces-state/if:interface" {
> when "if:type = 'ianaift:ethernetCsmacd'";
>
>
>
>
>
> Thank you,
>
> Sue Hares
>
>
>
>
>
>
>
> From: i2rs [mailto:[email protected]] On Behalf Of Alia Atlas
> Sent: Wednesday, February 1, 2017 4:14 PM
> To: Lou Berger
> Cc: [email protected]; [email protected]; [email protected]
> Subject: Re: [i2rs] Kathleen Moriarty's No Objection on
> draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT)
>
>
>
> On Wed, Feb 1, 2017 at 3:56 PM, Lou Berger <[email protected]> wrote:
>
>
>
> On 2/1/2017 2:32 PM, Juergen Schoenwaelder wrote:
> > On Wed, Feb 01, 2017 at 01:52:25PM -0500, Lou Berger wrote:
> >> Juergen,
> >>
> >> What precludes treating such dependencies in the same way
> >> per-provisioning is handled by RFC7223?
> >>
> > This is fine. But having direct dependencies, e.g., leafrefs from
> > config true leafs to config false leafs, is not.
> >
> > /js
> >
>
> Okay, then we're on the same page -- I think some may have missed the
> possibility of handling references to dynamic topology information in
> config using a 'pre-provisioning' approach.
>
>
>
> I would be happy to see Alex, Xufeng, Kent & Pavan articulate what this would
>
> look like and how it would work for the base topology model, so that the WG
> can
>
> consider all potentially viable options. I'm not certain how it would
> function for the
>
> recursive nature and it does presume the separate /config and /oper-state
> trees in
>
> the data-model that were a concern (though certainly the current recommended
>
> approach for YANG models).
>
>
>
> Regards,
>
> Alia
>
> _______________________________________________
> i2rs mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/i2rs
--
Juergen Schoenwaelder Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax: +49 421 200 3103 <http://www.jacobs-university.de/>
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
