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

Joe Clarke <jclarke@cisco.com> Wed, 29 March 2017 20:09 UTC

Return-Path: <jclarke@cisco.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 44DCC129483 for <i2rs@ietfa.amsl.com>; Wed, 29 Mar 2017 13:09:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.523
X-Spam-Level:
X-Spam-Status: No, score=-14.523 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 e19lrDYThH-t for <i2rs@ietfa.amsl.com>; Wed, 29 Mar 2017 13:09:30 -0700 (PDT)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2FBC129968 for <i2rs@ietf.org>; Wed, 29 Mar 2017 13:09:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2144; q=dns/txt; s=iport; t=1490818161; x=1492027761; h=to:from:subject:message-id:date:mime-version: content-transfer-encoding; bh=tnJ8epqY3WSBcX/wC9qc2syln2nG0WvH01dr1NfhZQg=; b=YHY4ya3MdBtWgihWmWgBJJXbEkflSA2yeUdDQoQUAjeDJCNJR5Z1uAt2 sJRlgDKvUc/auT2DyN6Nb9Z2M6XTYLf60sBEQYkLc8cP3e6jH1lR7w/eb lKqz1jqPytPNfmJe6b4FOKQWB4vdcYB8hK7VOyqweqcX6Mtx2PbZBgL34 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0C9AgDvE9xY/4gNJK1eGgEBAQECAQEBAQgBAQEBg1WFTooRkTCTXoIPgg6GHQODRz8YAQIBAQEBAQEBax0LhT8PAXsCJgJfDQgBAYoGng6QBoImilQBAQgCJoELhUOCBQiKPIJfBY9hhi+GUIFVhiaCLIgpgXyIXoZZk2ofOIEEOh8VhRkdgX8khzArghABAQE
X-IronPort-AV: E=Sophos;i="5.36,242,1486425600"; d="scan'208";a="224551964"
Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 29 Mar 2017 20:09:21 +0000
Received: from [10.24.168.228] ([10.24.168.228]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v2TK9K2U009196 for <i2rs@ietf.org>; Wed, 29 Mar 2017 20:09:20 GMT
To: "i2rs@ietf.org" <i2rs@ietf.org>
From: Joe Clarke <jclarke@cisco.com>
Organization: Cisco Systems, Inc.
Message-ID: <f727456e-8130-3d71-3261-8413198980c3@cisco.com>
Date: Wed, 29 Mar 2017 16:09:20 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/i2rs/EHbloysF3mFoF6EKMXwBdJpwgmE>
Subject: [i2rs] Comments on I2RS and YANG suggestions (aka, finally woke up)
X-BeenThere: i2rs@ietf.org
X-Mailman-Version: 2.1.22
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, 29 Mar 2017 20:09:32 -0000

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