Re: [i2rs] Can I2RS focus on the "Over the Wire" data structure , not on how end point handle the "DataStore"?

Andy Bierman <andy@yumaworks.com> Wed, 01 June 2016 02:04 UTC

Return-Path: <andy@yumaworks.com>
X-Original-To: i2rs@ietfa.amsl.com
Delivered-To: i2rs@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1FF512D09C for <i2rs@ietfa.amsl.com>; Tue, 31 May 2016 19:04:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vIZwvEawwhwd for <i2rs@ietfa.amsl.com>; Tue, 31 May 2016 19:04:49 -0700 (PDT)
Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2323128874 for <i2rs@ietf.org>; Tue, 31 May 2016 19:04:48 -0700 (PDT)
Received: by mail-yw0-x234.google.com with SMTP id o16so5562905ywd.2 for <i2rs@ietf.org>; Tue, 31 May 2016 19:04:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=PdafmPiwrdW7eR1WCETadKZlVgXglRz1DeZ3h/iM1jE=; b=HBY479OHW/pbSlWqY8cfeHhRgjj7P/x169dZVfWfUDJ4/mL0Iy+pQu5VZjBYtSQ388 OnPEpwbEk0254TYHbpdnCkyLT8pwqyPjsyLD1GArXliVL5t02UYPn4rj/1HzfQuvOeIm 0dCWQrP6kFU95JJZXo+01XgG184hY+IEqcc4/RJU7YPKXzuzSPLOKnMc0kFtgO/Hurf2 gE+TyLWpS2n6xkpnwKul1FKxwF/NGxhti93XQWWFQjNWwCrPYiiGHW/A3aVon7ZqEewb 68ggf0OUZb6eO1nPPtiPl6hhePYNZryXrKQjqi6U5c6UvPh4fIrC6nnQd9BipHYLIZio z3TQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=PdafmPiwrdW7eR1WCETadKZlVgXglRz1DeZ3h/iM1jE=; b=j/RUM0cJOIwx7EHleN7cTctS3P+i7T8vu9NUDodxpmfVcxCuI/7Bz87pDKmvXeXJLO A5Sw6RCg1B3qdvRp2VLTrVxS3ELHx0BN3x/dgVNmyMkYr9GqIhLqtl/c19PPeAvhGFay 2mtfMY6WERIIY1nmUCpPLHOlOHJ/7oijQogykpBZm9yKzmHqY6gCz5uCsIN4tLvV2Fia Hl0Q503k1i9ontx0aMFjpkWjy35lEvSgvc5VvcOHxJgkHSYybrN+0+/ddqhhcJLwSPWA 7XWpXUBxgOzHkWtXs5fbHtavRKPjV5HoAe2Q9+yGL/Huu7pZ7piQ531ILL8O0xsagwL9 AXSw==
X-Gm-Message-State: ALyK8tJDlQp3drKCcR44wI6S7ugOfD+khI13lLsfvs9QHr56dlXGogC9gf9CVZvk+JgKVPSYE+OONdfnOfUyjA==
MIME-Version: 1.0
X-Received: by 10.129.101.137 with SMTP id z131mr849032ywb.88.1464746687879; Tue, 31 May 2016 19:04:47 -0700 (PDT)
Received: by 10.37.115.208 with HTTP; Tue, 31 May 2016 19:04:47 -0700 (PDT)
In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F657EACE6D@dfweml501-mbb>
References: <000601d1bad5$70523090$50f691b0$@ndzh.com> <20160531063840.GA21289@elstar.local> <00d501d1bb45$0da83500$28f89f00$@ndzh.com> <20160531142540.GA22420@elstar.local> <001401d1bb4e$cfaefd10$6f0cf730$@ndzh.com> <20160531171304.GA22857@elstar.local> <CABCOCHR2JChAg1zmKDy_qxVOGYVeTm9wGVLyxzpChb5Ht0uaww@mail.gmail.com> <20160531195123.GN17462@pfrc.org> <CABCOCHQka+BezA6pLSiyOPcTghgx-UKK5dY6y70nME_EFZxCZg@mail.gmail.com> <4A95BA014132FF49AE685FAB4B9F17F657EACE6D@dfweml501-mbb>
Date: Tue, 31 May 2016 19:04:47 -0700
Message-ID: <CABCOCHSWi=KjNBSxoqMDQniKLGDXX76YQMyVqbJirF=LoK6PHg@mail.gmail.com>
From: Andy Bierman <andy@yumaworks.com>
To: Linda Dunbar <linda.dunbar@huawei.com>
Content-Type: multipart/related; boundary="001a114c6d8c04ad2105342dea40"
Archived-At: <http://mailarchive.ietf.org/arch/msg/i2rs/RqL2RmsXv4j9VT7SHnsDSd1-FOs>
Cc: "i2rs@ietf.org" <i2rs@ietf.org>, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>, Alia Atlas <akatlas@gmail.com>, Benoit Claise <bclaise@cisco.com>, Jeffrey Haas <jhaas@pfrc.org>, Susan Hares <shares@ndzh.com>
Subject: Re: [i2rs] Can I2RS focus on the "Over the Wire" data structure , not on how end point handle the "DataStore"?
X-BeenThere: i2rs@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Interface to The Internet Routing System \(IRS\)" <i2rs.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/i2rs>, <mailto:i2rs-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/i2rs/>
List-Post: <mailto:i2rs@ietf.org>
List-Help: <mailto:i2rs-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/i2rs>, <mailto:i2rs-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 01 Jun 2016 02:04:52 -0000

Hi,

If your graphic advice means "the requirements are good enough, move on"
then I agree.

The datastore framework would be nice to have, but it is very close
to the implementation details.  It is also attempting to be a superset of
all
"accepted" implementation choices.

By "on the wire" we usually mean a protocol specification.
IMO, all that is needed (for editing) is a set of RESTCONF extensions.
Some people want to describe the I2RS desired behavior wrt/ how it
interacts with the local config. (and many more features...)

Perhaps a good first step would be ephemeral data models that do not
interact with the local config at all.  I2RS is the only protocol of
concern and the
highest priority client.  I2RS just needs to support read/write/notify of
ephemeral data.
If this is not acceptable then be prepared to wait until all the framework
stuff is settled
and standardized.


Andy




On Tue, May 31, 2016 at 4:09 PM, Linda Dunbar <linda.dunbar@huawei.com>
wrote:

> IETF has been successful for past 20 years  in focusing on “Over the Wire”
> data structure.  It would be so much cleaner and straight forward if the
> YANG modules developed by I2RS  focusing on the “Over the Wire” data
> structure (and with NETMOD to focus on other aspects).
>
> The “I2RS ephemeral State” has the needed description for the desired
> behavior  of the data received over I2RS interface. If we follow the IETF
> practice,  it is good enough.
>
> Internal implementation framework is always controversial, hard to
> converge, usually ending up with a document (if completed) that is too big
> and difficult to read.
>
>
>
> Providing some source code to show the internal implementation would be
> much more useful as a reference implementation.
>
>
>
> The draft-schoenw-netmod-revised-datastores-00 is on the architectural
> framework for datastores as they are used by network management protocols.
> IMHO, how data stores are used are internal to the end points.
>
>
>
> [image:
> http://www.urbanblisslife.com/wp-content/uploads/2012/10/Done-is-Better-Than-Perfect.jpg]
> <http://www.google.com/url?sa=i&rct=j&q=&esrc=s&source=images&cd=&cad=rja&uact=8&ved=0ahUKEwj50KWat4XNAhULxGMKHRhqDPQQjRwIBw&url=http%3A%2F%2Fwww.urbanblissmedia.com%2Fentrepreneur-rules-done-is-better-than-perfect%2F&psig=AFQjCNGKEiPB2iHSqyBiF5609pd72H0L7w&ust=1464822503865777>
>
>
>
> Linda Dunbar
>
>
>
> *From:* i2rs [mailto:i2rs-bounces@ietf.org] *On Behalf Of *Andy Bierman
> *Sent:* Tuesday, May 31, 2016 4:09 PM
> *To:* Jeffrey Haas
> *Cc:* Benoit Claise; i2rs@ietf.org; Juergen Schoenwaelder; Susan Hares;
> Alia Atlas
> *Subject:* Re: [i2rs] I2RS Interim Meeting - June 1, 2016 - 10:00am -
> 11:00am - Topic: Ephemeral State Requirements
>
>
>
> Hi,
>
>
>
> I am not convinced the IETF can be forced to function as if it were
>
> a dev-group in some corporation.  This is a volunteer organization so
>
> usually solution proposals come from people who have created a solution
>
> and they want the WG to standardize it.
>
>
>
>
>
> Andy
>
>
>
>
>
> On Tue, May 31, 2016 at 12:51 PM, Jeffrey Haas <jhaas@pfrc.org> wrote:
>
> Andy,
>
> On Tue, May 31, 2016 at 11:41:59AM -0700, Andy Bierman wrote:
> > At some point the WG needs to agree on normative text instead of
> iterating
> > on requirements forever.
>
> IMO, it would be in I2RS's best interests if netconf/netmod provided drafts
> in appropriately normative language covering I2RS requirements.  However,
> we've been in a pathological cycle of:
> "We don't understand, please give us requirements"
> "We don't understand your requirements"
> "You provided examples with your requirements that appear to be attempts to
> change our protocol - don't do that."
>
> The most recent revised-datastore draft would be a good place to document
> where netmod(/netconf) believes ephemeral datastores (if that's the
> instantiation) could live, and also how ephemeral configuration state could
> interact with candidate, startup and running configuration.
>
> yang-push covers much of our desired pub-sub behavior. (Yay!)
>
> Discussion is required for how to tag security considerations impacting
> transport into the yang model, in particular for notification.
>
> Proposals for secondary identity and priority are also needed.
>
> -- Jeff
>
>
>