Re: [Rtg-yang-coord] Fwd: [netmod] Opstate solutions discussions: update and request for WG input

Martin Bjorklund <> Wed, 08 June 2016 17:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A334712D7B8; Wed, 8 Jun 2016 10:40:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.327
X-Spam-Status: No, score=-3.327 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id B9Xa9_ZP6LZE; Wed, 8 Jun 2016 10:40:30 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 7EC3812D7B6; Wed, 8 Jun 2016 10:40:30 -0700 (PDT)
Received: from localhost ( []) by (Postfix) with ESMTPSA id CB0721AE0389; Wed, 8 Jun 2016 19:40:28 +0200 (CEST)
Date: Wed, 08 Jun 2016 19:40:28 +0200 (CEST)
Message-Id: <>
From: Martin Bjorklund <>
In-Reply-To: <00d301d1c1a0$3b12c8f0$b1385ad0$>
References: <> <> <00d301d1c1a0$3b12c8f0$b1385ad0$>
X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [Rtg-yang-coord] Fwd: [netmod] Opstate solutions discussions: update and request for WG input
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "\"List to discuss coordination between the Routing related YANG models\"" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 08 Jun 2016 17:40:31 -0000

Hi Sue,

"Susan Hares" <> wrote:
> In [4], the author states: 
>    "o  The model foresees ephemeral datastores that are by definition not
>       part of the persistent configuration of a device.  These ephemeral
>       datastores are considered to interact with the rest of the system
>       like any other control-plane mechanisms (e.g., routing protocols,
>       discovery protocols).  [XXX Note that this is different from what
>       is described in some of the I2RS documents.  XXX]"


> Therefore, the result of I2RS WG spending 2 years writing requirements for
> the ephemeral data store that both option 2 documents "do not  match" the
> I2RS ephemeral requirements set.  [4] lumps ephemeral with operational
> state.

I don't think this last sentence is correct.  Admittedly, the details
about ephemeral in [4] are not worked out (by design).  But the idea
was not to "lump ephemeral and operational state".  The idea was
rather that the content of ephemeral datastore(s) would interact with
the applied config to produce the resulting operational state.

If the WG agrees that B is the right way to go, we'll need to work out
all the details about how the ephemeral datastore(s) work.

The main point is that [4] (and [5]) provides an architecture into
which ephemeral datastores can fit.