IETF Logo Mail Archive

Re: [Rtg-yang-coord] I-D Action: draft-openconfig-mpls-consolidated-model-00.txt

Rob Shakir <rjs@rob.sh> Fri, 20 March 2015 15:47 UTC

Return-Path: <rjs@rob.sh>
X-Original-To: rtg-yang-coord@ietfa.amsl.com
Delivered-To: rtg-yang-coord@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FB851ACD58; Fri, 20 Mar 2015 08:47:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 VdRJ9fO2-HsV; Fri, 20 Mar 2015 08:47:55 -0700 (PDT)
Received: from cappuccino.rob.sh (cappuccino.rob.sh [IPv6:2a03:9800:10:4c::cafe:b00c]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C16881ACD56; Fri, 20 Mar 2015 08:47:54 -0700 (PDT)
Received: from [86.146.148.203] (helo=[172.16.1.15]) by cappuccino.rob.sh with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from <rjs@rob.sh>) id 1YYz9N-0001bs-H7; Fri, 20 Mar 2015 15:47:53 +0000
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
From: Rob Shakir <rjs@rob.sh>
In-Reply-To: <4F1DF791-876B-442D-AA5B-9170875525EA@rob.sh>
Date: Fri, 20 Mar 2015 15:47:50 +0000
Content-Transfer-Encoding: quoted-printable
Message-Id: <9A432361-6411-49E7-9597-2F1B2786DD7C@rob.sh>
References: <20150309224815.8246.60629.idtracker@ietfa.amsl.com> <14c12af9498.27e9.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <14c12b948f8.27e9.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <CAKL6Z6kXHuARkLtVT19TmLwtOGnrur_7KgOgP91p+5tMFxTF3A@mail.gmail.com> <5507588A.9010105@labn.net> <5507E141.5010807@pi.nu> <550841BA.4040205@labn.net> <55084C4D.3050107@pi.nu> <5508522E.8020402@labn.net> <63CB93BC589C1B4BAFDB41A0A19B7ACD1A05F905@USIDCWVEMBX08.corp.global.level3.com> <D12DCF90.10C80%acee@cisco.com> <5509AB9E.6090201@labn.net> <550A95DF.4080805@pi.nu> <550A9F40.10109@pi.nu> <550AD63A.8030008@labn.net> <550AD956.20800@pi.nu> <CAG4d1reyAd5LwAB3_bg57DZuwV-hwogxK0+Zm_-j1sjWKxKQsQ@mail.gmail.com> <14AF59C9-CF61-45CB-9A0B-12D35AD98AA3@lucidvision.com> <4F1DF791-876B-442D-AA5B-9170875525EA@rob.sh>
To: "Thomas D. Nadeau" <tnadeau@lucidvision.com>
X-Mailer: Apple Mail (2.2070.6)
Archived-At: <http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/eqLr6K9VlFbjPZzcuLPeg4wF_MI>
Cc: "draft-openconfig-mpls-consolidated-model@ietf.org" <draft-openconfig-mpls-consolidated-model@ietf.org>, "rtg-yang-coord@ietf.org" <rtg-yang-coord@ietf.org>, Alia Atlas <akatlas@gmail.com>, Alia Atlas <akatlas@juniper.net>, Berger Lou <lberger@labn.net>, Joshua George <jgeorge@google.com>, Loa Andersson <loa@pi.nu>
Subject: Re: [Rtg-yang-coord] I-D Action: draft-openconfig-mpls-consolidated-model-00.txt
X-BeenThere: rtg-yang-coord@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "\"List to discuss coordination between the Routing related YANG models\"" <rtg-yang-coord.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-yang-coord>, <mailto:rtg-yang-coord-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtg-yang-coord/>
List-Post: <mailto:rtg-yang-coord@ietf.org>
List-Help: <mailto:rtg-yang-coord-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-yang-coord>, <mailto:rtg-yang-coord-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 20 Mar 2015 15:47:57 -0000

Oh, and the other point that I would like to make on this (but got trigger happy with pressing send) — I’m not sure that anyone (I certainly wouldn’t) would claim that this draft, or the other more structural modules that we (openconfig) have published recently reflect a wholly completed items to be rubber-stamped. That is clearly not the intention and there are surely issues and concerns that have not even been considered at the moment… however, community feedback and review is the best way to get that thinking done — so I certainly would welcome feedback on them.

Some of the issues might be cross-working-group, but that’s sort of the point of this list - and the way we work on network _management_ might not end up looking exactly like the way that we work on network _protocols_. Let’s not constrain our thinking.

(Thanks to the ADs and rtgwg chairs for accommodating discussion in Dallas.)

r.

v2.8.7 | Report a Bug | By Email