Re: [i2rs] What is RFC 7223 style pre-provisioning (was Re: Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT))

Lou: 

In concept Martin's answer makes sense, but I would just like to see an example.  I could not find an example of the YANG to go with the NETCONF.  If you could either point me to a section in RFC7223 or provide an example - it would be helpful.  What I think I understand from Martin's message is that the YANG configuration does not have any "must" or "when" statements in the leaf clause.   Is this true?

Sue 

-----Original Message-----
From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Lou Berger
Sent: Thursday, February 2, 2017 11:54 AM
To: Susan Hares; 'Alia Atlas'; draft-ietf-i2rs-yang-l3-topology@ietf.org; i2rs@ietf.org
Subject: [i2rs] What is RFC 7223 style pre-provisioning (was Re: Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT))

Hi Sue,

    I think Juergen's comment covers what I was referring to. Does this answer your question / make sense?

Cheers,

Lou

On 2/2/2017 10:14 AM, Juergen Schoenwaelder wrote:
> 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:i2rs-bounces@ietf.org] On Behalf Of Alia Atlas
>> Sent: Wednesday, February 1, 2017 4:14 PM
>> To: Lou Berger
>> Cc: draft-ietf-i2rs-yang-l3-topology@ietf.org; i2rs@ietf.org; 
>> iesg@ietf.org
>> 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 <lberger@labn.net> 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
>> i2rs@ietf.org
>> https://www.ietf.org/mailman/listinfo/i2rs
>

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