Benoit Claise's No Objection on draft-ietf-rtgwg-lne-model-06: (with COMMENT)
Benoit Claise <bclaise@cisco.com> Wed, 07 February 2018 17:37 UTC
Return-Path: <bclaise@cisco.com>
X-Original-To: rtgwg@ietf.org
Delivered-To: rtgwg@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D2547127023; Wed, 7 Feb 2018 09:37:05 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Benoit Claise <bclaise@cisco.com>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-rtgwg-lne-model@ietf.org, Yingzhen Qu <yingzhen.ietf@gmail.com>, rtgwg-chairs@ietf.org, yingzhen.ietf@gmail.com, rtgwg@ietf.org, dromasca@gmail.com
Subject: Benoit Claise's No Objection on draft-ietf-rtgwg-lne-model-06: (with COMMENT)
X-Test-IDTracker: no
X-IETF-IDTracker: 6.72.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <151802502585.4901.3650492840820191193.idtracker@ietfa.amsl.com>
Date: Wed, 07 Feb 2018 09:37:05 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtgwg/_teTEeGsbvdUxEGN-U_YUuezUVk>
X-BeenThere: rtgwg@ietf.org
X-Mailman-Version: 2.1.22
List-Id: Routing Area Working Group <rtgwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtgwg/>
List-Post: <mailto:rtgwg@ietf.org>
List-Help: <mailto:rtgwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 07 Feb 2018 17:37:06 -0000
Benoit Claise has entered the following ballot position for draft-ietf-rtgwg-lne-model-06: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-rtgwg-lne-model/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- No objection to the document, but a few points must addressed. - I agree with Alvaro's point: the example should be corrected. - This draft is NMDA compliant: it should be mentioned. >From Dan Romascanu's OPS DIR, at least the 3 first three points should be addressed (the 4rth one is a nice to have, but a bigger task IMO): This is a very useful, well thought and well written document, which reflects work and discussions within the RTG and OPS areas. From an operational point of view it's a very useful tool in support of network operators that will manage and configure logical elements. I believe that the document is almost ready, but there are a number of issues that are worth being discussed and addressed before approval by the IESG. 1. The name and scope of the document as presented in the title and Abstract are not exactly reflecting the content. LNEs are not YANG LNEs as the title says, and the type of module (a YANG module) being defined is not stated in the Abstract. I would suggest that the document actually defines 'A Data Model and YANG Module for Logical Network Elements'. 2. There is no reference and relationship definition in the document to the YANG Data Model for Hardware Management defined in https://tools.ietf.org/html/draft-ietf-netmod-entity-07. Actually the LNEs are almost similar with the 'logical entities' that were dropped from the netmod-entity work. It is expected that in the future network operators will use both data models and the respective YANG modules when managing hardware devices on which logical network entities are being run. Even if this relationship is not explicitly present in the DM, I believe that it needs to be looked at and mentioned in the document. 3. In Section 2 I see: 'The logical-network-element module augments existing interface management model by adding an identifier which is used on physical interface types to identify an associated LNE.' I am wondering why the mentioning of 'physical interface types' here. What if the interface type in not 'physical' representing a protocol layer or sublayer on the device? After all, if all interfaces to be considered were 'physical' we could have augmented the entity hardware module rather than the interfaces module, as all physical interfaces are represented there as well. 4. Sections 3.2 and 3.3 seem to be written for the benefit and the perspective of the implementations writers rather than of the operators. Are there any hints, advice, or indications for the operators using the module to manage their LNEs? These could be described also in the examples appendices, which are otherwise very useful to illustrate and explain the models.
- Benoit Claise's No Objection on draft-ietf-rtgwg-… Benoit Claise
- Re: Benoit Claise's No Objection on draft-ietf-rt… Benoit Claise