Subject: Re: [i2rs] [netmod] netmod interim and i2rs requirements

From: Benoit Claise <[email-masked]>
Date: Mon, 01 Sep 2014 18:23:27 +0200

Joel,

On top of what Jürgen wrote, we stressed the need for such a requirement 
document to both I2RS chairs during the last IETF meeting.
The good news is that some of the requirements were mentioned on the 
microphone during the Sunday YANG editing session and/or the NETMOD 
meeting (my memory fails me).

Regards, Benoit

> On Sun, Aug 31, 2014 at 09:58:57PM -0400, Joel M. Halpern wrote:
>> Juergen,
>>      While I understand the request, I presume that such a request can
>> not be met as a working group agreement in the time frame suggested.
>> WHile I hope that some of the folks who have been involved in proposing
>> the use of YANG for I2RS will write such a draft, I can not see how we
>> could even get tot eh point of WG adoption of such a draft, much less WG
>> rough consensus on the content, in the time frame you outline.
>>      Of course, I am not one of the chairs or ADs, but it seems pretty
>> clear cut to me.
> Joel,
>
> all I need is reasonably agreed upon input. Note that this request for
> input is not coming out of the blue, at least not for those I2RS folks
> who have been at the NETMOD meeting in Toronto.
>
> As NETMOD chair, I do have a target date to deliver YANG 1.1 and I
> take that milestone serious. My motivation to delay this by N months
> waiting for I2RS to get their input submitted is very small. I recall
> that there were presentations about "what is missing" bach in London,
> that is March 2014. The regular submission period for YANG 1.1 issues
> was 2014-02-23 until 2014-05-07. The interim meeting is mid September.
>
> /js
>

---

From: Andy Bierman <[email-masked]>
Date: Mon, 1 Sep 2014 10:17:14 -0700

On Mon, Sep 1, 2014 at 9:23 AM, Benoit Claise <[email-masked]> wrote:

> microphone during the Sunday YANG editing session and/or the NETMOD meeting
> (my memory fails me).
>
> Regards, Benoit
>
I agree with Joel that the I2RS does not have consensus on the details.
The slides I presented in London and subsequent discussions suggest this
solution:

   1) define YANG extension to identify I2RS data so typedefs, etc. can be
shared
       in config and state data models
   2) define an I2RS datastore
   3) define or extend a protocol to manage the I2RS datastore

Let's say there is a new datastore added to the RESTCONF architecture for
I2RS.
Explain how this datastore works.  It seems to have the same validation
rules
as YANG running config rules.  The only difference seems to be that the
I2RS datastore
is not NV-saved (or NV-loaded at boot-time) like the running datastore.

YANG 1.1 has some cleanup work planned to make the text less
NETCONF-specific.
I don't think there is much datastore and NV-store specific text that would
need to change.

Andy

 Joel,
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod
>

---

From: Reinaldo Penno <[email-masked]>
Date: Tue, 2 Sep 2014 10:50:26 -0700

Hi,

are we taking this approach only for I2RS or this will be our preferred 
solution from now on?

Meaning, every time when a new protocol/WG has certain valid 
requirements we will create a new datastore for them?

thanks,

On 9/1/14 10:17 AM, Andy Bierman wrote:
>
>
>
> On Mon, Sep 1, 2014 at 9:23 AM, Benoit Claise <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Joel,
>
>     On top of what Jürgen wrote, we stressed the need for such a
>     requirement document to both I2RS chairs during the last IETF meeting.
>     The good news is that some of the requirements were mentioned on
>     the microphone during the Sunday YANG editing session and/or the
>     NETMOD meeting (my memory fails me).
>
>     Regards, Benoit
>
> The slides I presented in London and subsequent discussions suggest 
> this solution:
>
>    1) define YANG extension to identify I2RS data so typedefs, etc. 
> can be shared
> Let's say there is a new datastore added to the RESTCONF architecture 
> for I2RS.
> Explain how this datastore works.  It seems to have the same 
> validation rules
> as YANG running config rules.  The only difference seems to be that 
> the I2RS datastore
> I don't think there is much datastore and NV-store specific text that 
> would need to change.
>
>
> Andy
>
>
>
>
>         Joel,
>
>     [email-masked] <mailto:[email-masked]>
> i2rs mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i2rs

---

From: Andy Bierman <[email-masked]>
Date: Tue, 2 Sep 2014 11:00:05 -0700

On Tue, Sep 2, 2014 at 10:50 AM, Reinaldo Penno <[email-masked]> wrote:

> Meaning, every time when a new protocol/WG has certain valid requirements
> we will create a new datastore for them?
>
>
Good question.
It is a lot more work to add a new datastore than to tag data as ephemeral
in the existing "running" datastore -- if the only difference is no
non-volatile support.
I think the I2RS WG has to agree on those details first.

thanks,
Andy

>     1) define YANG extension to identify I2RS data so typedefs, etc. can
> be shared
> i2rs mailing [email-masked]://www.ietf.org/mailman/listinfo/i2rs
>
>
>

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 4 Sep 2014 11:22:19 -0400

Benoit and Juergen,

My apologies for delay in responding to this mail.  I've had a few
unexpected items that have distracted me from IETF work the last several
days.

I will be chatting with Dean B. who had volunteered to help draft this
document today.  While we have previously discussed a number of items in
terms of requirements and gaps, the request was that we provide a formal
list of the requirements against netmod and netconf.

I hope to have the result of that discussion this afternoon.

-- Jeff

On Mon, Sep 01, 2014 at 06:23:27PM +0200, Benoit Claise wrote:
> Joel,
> 
> On top of what J?rgen wrote, we stressed the need for such a

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 4 Sep 2014 11:26:17 -0400

> I agree with Joel that the I2RS does not have consensus on the details.

I think we continue to have consensus but not in enough detail to declare

>        in config and state data models

And how this was to be different than ephemeral data, if at all.

>    2) define an I2RS datastore

I suspect we have consensus on this.

> is not NV-saved (or NV-loaded at boot-time) like the running datastore.

Exactly.

> I don't think there is much datastore and NV-store specific text that would

Mostly the ability to tag things emphemeral.  More on that in a later
message.

-- Jeff

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 4 Sep 2014 11:29:14 -0400

> I think the I2RS WG has to agree on those details first.

Part of the discussion at the recent netmod session and post-session hallway
discussion provided some suggestion there may be other users desiring
ephemeral characteristics.  If this is the case, providing for a mechanism
for tagging ephemeral state seems to be generally useful.

One of the open questions for the more general mechanism is whether
ephemeral state should be in a separate data store.  While I think there is
good cause for I2RS to desire this, from the general standpoint it may also
simplify implementations to keep ephemeral configuration segregated from
static configuration.

-- Jeff

---

From: Andy Bierman <[email-masked]>
Date: Thu, 4 Sep 2014 09:18:53 -0700

> simplify implementations to keep ephemeral configuration segregated from
It makes a big difference to YANG XPath whether there is a separate
datastore.
YANG only supports 1 static context for each document type
(rpc/input, rpc/output, config-data, all-data, notification). A new
datastore might
require many changes to YANG, depending on I2RS requirements.

There are problems mixing local config and I2RS nodes in "must" or "when"
expressions.
One important detail is whether I2RS objects are config=true (or false) in
YANG.
This impacts how must, when, and other constructs will behave.

If I2RS is config=false, It should be OK to reference local config from
I2RS must/when stmts,
but a config object must/when statement is not allowed to reference an I2RS
object.
Is this OK? Are there any requirements for "YANG integration" between the
local config
and the I2RS datastore?

-- Jeff

Andy

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 4 Sep 2014 12:32:24 -0400

> Is this OK? Are there any requirements for "YANG integration" between the

An example use case that may cover this is a BGP dynamic peer I2RS
interface.  In such a case (ideally):

- Configuration exists for BGP.  This implies an IDR BGP yang module.
- Some re-usable components from the BGP module have been made into
  groupings to permit I2RS re-use.  For example, a "neighbor template".
- The I2RS portion of this module would rely on some amount of local BGP
  configuration outside of the I2RS module.  As a trivial example,
  "router autonomous system number" is a property that is device-wide that may
  be owned by BGP config; the I2RS neighbor configuration would have a "must"
  dependency on the presence of the ASN config.

(Those who are interested in working on such a BGP I2RS module please hold
your nitpicking of the example.  Yes, we'll probably want to permit local
configuration of the neighbor ASN as well, but it highlights the issue...
:-)

If we can't do this sort of thing by using a separate datastore, that may
push the solution a given direction.

-- Jeff

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 15 Sep 2014 08:17:49 -0500

Hi Juergen,

What is Netconf protocol called? SNMP v4?

Regards,

Behcet

On Fri, Aug 29, 2014 at 1:42 AM, Juergen Schoenwaelder
<[email-masked]> wrote:
> Hi,
>
> the NETMOD WG is holding an interim meeting on Sep. 17/18 [1] and one
> of the agenda items is to work on any requirements I2RS might have for
> YANG 1.1. For this, we need a clear definition of what the I2RS
> requirements are for YANG 1.1, ideally posted as an I-D a few days
> before the interim meeting so that people can come prepared. This
> means there are ~15 days left to produce such a requirements writeup.
>
> /js
>
> [1] https://www.ietf.org/meeting/interim/netmod-2014-09-17.txt
>
> --
> 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/>
>

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Mon, 15 Sep 2014 09:21:54 -0400

Netconf is called Netconf; it has nothing to do with SNMP.  

	--Tom