Subject: [i2rs] Comments on I2RS and YANG suggestions (aka, finally woke up)

From: Joe Clarke <[email-masked]>
Date: Wed, 29 Mar 2017 16:09:20 -0400

Lunch has been really good here at the Swissôtel, but that wasn't the
reason I didn't get up at the mic.  I have been going through the
various YANG and *CONF drafts from Sue this week, and I was hoping the
presentation would help in my clue on some things.  After mulling things
over, it did not.  At the risk of asking stupid questions, I will comment.

First, there appears to be a big typo in draft-hares-netmod-i2rs-yang-04
that may change my understanding of how to specify something is
ephemeral.  If you look at section 3.4, it states:

The value "true" indicates the object is not ephemeral.
The value "false" indicates the value is ephemeral.

I think (hope) that is backwards.  But if not, can you explain to me why
the logic is thus?

===

Now on to my bigger questions/comments.

I have been trying to figure out why we need a dstype.  I see that the
examples listed are control-plane, config, and i2rs-v[o0] (this shows up
in various spellings without any explanation).

I see no mention of the idea of a "control-plane" DS in the revised DS
draft, and I don't see why we need this added complexity.  The revised
DS draft already allows us to specify a DS name, additional attributes
such as "ephemeral," protocol support, and supporting modules.  Why add
this DS type?  What does it give us and how would one figure out how to
make use of it?

I'm strongly leaning on letting this draft expire and working to create
an I2RS YANG module that fits into the revised DS guidance.  I think
that would make things much clearer.

===

Additionally, if the revised DS draft progresses (and it seems like it
will), do we need <write-data> at all?  Yes, we need to sort out
validation, but why can't we use <edit-config> (revised DS already gives
us <get-data>).

===

Again, sorry if these are dumb questions.  It seems like the work around
revised datastores is already addressing most of what we need.  If the
WG agrees, I think we should focus on removing confusion and ambiguity
and work to define clearly distinct documents that can inform the
current world order.

Thanks.

Joe

---

From: Phil Shafer <[email-masked]>
Date: Wed, 29 Mar 2017 16:57:09 -0400

Joe Clarke writes:
>Additionally, if the revised DS draft progresses (and it seems like it will), do
>we need <write-data> at all?  Yes, we need to sort out validation, but why can't
>we use <edit-config> (revised DS already gives us <get-data>).

<edit-config> is defined in the base NETCONF spec, and we're trying
to avoid reving that.  Instead we're proposing edits to dynamic
datastores (like i2rs-defined ones) will be performed using a new
<edit-data> operation (patterned after <edit-config>, named to
mirror <get-data>).  This operation will take an argument to indicate
the target datastore.

Following the outcome of Tuesday NETCONF meeting, we'll be preparing
individual drafts for NETCONF and RESTCONF based on the "impact to
..." sections that are currently in the datastore draft.  (Those
sections will be removed from the datastore draft.)

And based on Sue's comments, we'll be adding more details re: dynamic
datastores to the datastore draft.

Thanks,
 Phil

---

From: Joe Clarke <[email-masked]>
Date: Thu, 30 Mar 2017 11:48:59 -0400

> mirror <get-data>).  This operation will take an argument to indicate

Thanks, Phil.  I had to keep popping in and out of netmod and netconf,
so I missed this discussion.  This does make sense.

> datastores to the datastore draft.

Thanks.  I still think it would be worth revising or spinning down the
i2rs drafts as they have diverged from the revised DS draft, and this is
adding to at least my confusion.

Joe

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 30 Mar 2017 13:25:21 -0400

Joe:

Excellent questions.  The intent was to spin down the *hares* drafts.  I wished you’d asked the question in the meeting.   In my experience, you questions are always timely.  Please start a YANG module draft for I2RS.    

My recommendation to I2RS/NETCONF/RESTCONF chairs was: 

·        Expand revised datastores – to allow dynamic datastores + name 

·        Add capabilities to NETCONF/RESTCONF for dynamic datastores and capability 

·        Get volunteers from I2RS/NETMOD work on YANG syntax in NETMOD 

·        Get volunteers from I2RS/NETCONF work on the NETCONF changes in NETCONF

·        Get volunteers from  I2RS/NETCONF work on the RESTCONF changes for ephemeral in NETCONF. 

Open issues for these people: 

·        Precedence:  (yang/protocols) – must determine how to prioritize between datastores during installation of configuration

·        Validation (yang/protocols) - does it need to be identified in YANG or is it an implementation specific? 

·        RESTCONF (protocol) - how to encode client-id/priority in entity-tag 

·        NETCONF  (protocol) – how to handle edit-collision (aka multiple client write) 

·        Protocol support – how do you note what protocol and protocol features are needed to support this model. 

Now -- to your specific comments: 

·        Draft: This draft was intended to be a chair's kick start document on open issus. 

·        Why Kickstart:   I started it when the revised datastores people did not open their github archive or publish drafts to make sure we covered this work at IETF. 

o   Fortunately – they did release -01.txt revised datastores. 

·        Content errors: 

o   For edit-config, see the comments by Phil Schafer.      

o   The ephemeral logic is backward =  (red face) 

o   Revised datastores revisions-01 – did the following old/control-plane datastores/dynamic datastores/ (my draft worked off -00.txt) 

Let me know if I’ve answered all the questions. 

Sue Hares 

-----Original Message-----
From: i2rs [mailto:[email-masked]] On Behalf Of Joe Clarke
Sent: Wednesday, March 29, 2017 4:09 PM
To: [email-masked]
Subject: [i2rs] Comments on I2RS and YANG suggestions (aka, finally woke up)

Lunch has been really good here at the Swissôtel, but that wasn't the reason I didn't get up at the mic.  I have been going through the various YANG and *CONF drafts from Sue this week, and I was hoping the presentation would help in my clue on some things.  After mulling things over, it did not.  At the risk of asking stupid questions, I will comment.

First, there appears to be a big typo in draft-hares-netmod-i2rs-yang-04 that may change my understanding of how to specify something is ephemeral.  If you look at section 3.4, it states:

I think (hope) that is backwards.  But if not, can you explain to me why the logic is thus?

===

I have been trying to figure out why we need a dstype.  I see that the examples listed are control-plane, config, and i2rs-v[o0] (this shows up in various spellings without any explanation).

I see no mention of the idea of a "control-plane" DS in the revised DS draft, and I don't see why we need this added complexity.  The revised DS draft already allows us to specify a DS name, additional attributes such as "ephemeral," protocol support, and supporting modules.  Why add this DS type?  What does it give us and how would one figure out how to make use of it?

I'm strongly leaning on letting this draft expire and working to create an I2RS YANG module that fits into the revised DS guidance.  I think that would make things much clearer.

===

Additionally, if the revised DS draft progresses (and it seems like it will), do we need <write-data> at all?  Yes, we need to sort out validation, but why can't we use <edit-config> (revised DS already gives us <get-data>).

===

Again, sorry if these are dumb questions.  It seems like the work around revised datastores is already addressing most of what we need.  If the WG agrees, I think we should focus on removing confusion and ambiguity and work to define clearly distinct documents that can inform the current world order.

Thanks.

Joe

_______________________________________________

i2rs mailing list

 <mailto:[email-masked]> [email-masked]

 <https://www.ietf.org/mailman/listinfo/i2rs> https://www.ietf.org/mailman/listinfo/i2rs

---

From: Joe Clarke <[email-masked]>
Date: Thu, 30 Mar 2017 15:01:15 -0400

On 3/30/17 13:25, Susan Hares wrote:
>  
> 
> Joe:
> 
>  
> 
> Excellent questions.  The intent was to spin down the **hares** drafts. 
> I wished you’d asked the question in the meeting.   In my experience,
> you questions are always timely.  Please start a YANG module draft for
> I2RS.    

At least the comments are recorded more for posterity here :-).  I'd be
happy to work with people to define this model.

> *Open issues for these people: *

I have some thoughts on the first two.

> 
> ·        Precedence:  (yang/protocols) – must determine how to
> prioritize between datastores during installation of configuration

I'd like to see a general precedence model followed as you know from my
previous comments.  That is, I'd like to have a mechanism at the
datastore level that isn't just specific to I2RS.

> 
> ·        Validation (yang/protocols) - does it need to be identified in
> YANG or is it an implementation specific?

MY thinking is this might be implementation specific, but should likely
be reported from the device as to what method will be done.  This still
requires some YANG, but I'm not sure how client-requestable this will be.

>  
> 
> *Now -- to your specific comments: *
> 
> ·        *Draft:* This draft was intended to be a chair's kick start
> document on open issus.
> 
> ·        *Why Kickstart:*   I started it when the revised datastores
> people did not open their github archive or publish drafts to make sure
> we covered this work at IETF.
> 
> o   *Fortunately –* they did release -01.txt revised datastores.
> 
> ·        *Content errors: *
> 

Yep, makes a lot of sense.

> o   The ephemeral logic is backward =  (red face)

Cool.  Thought so.

> 
> o   Revised datastores revisions-01 – did the following
> old/control-plane datastores/dynamic datastores/ (my draft worked off
> -00.txt)

Understood.  Thanks for the clarifications.

Joe