[Lime] Alia Atlas' No Objection on draft-ietf-lime-yang-connectionless-oam-methods-11: (with COMMENT)
Alia Atlas <akatlas@gmail.com> Thu, 26 October 2017 14:30 UTC
Return-Path: <akatlas@gmail.com>
X-Original-To: lime@ietf.org
Delivered-To: lime@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C129113F5A8; Thu, 26 Oct 2017 07:30:08 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Alia Atlas <akatlas@gmail.com>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-lime-yang-connectionless-oam-methods@ietf.org, Carlos Pignataro <cpignata@cisco.com>, Ron Bonica <rbonica@juniper.net>, lime-chairs@ietf.org, cpignata@cisco.com, lime@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.63.2
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <150902820874.24236.6941116837012439101.idtracker@ietfa.amsl.com>
Date: Thu, 26 Oct 2017 07:30:08 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/lime/uLE0Bu_CBLoA9M4qcR7DPBNMq2M>
Subject: [Lime] Alia Atlas' No Objection on draft-ietf-lime-yang-connectionless-oam-methods-11: (with COMMENT)
X-BeenThere: lime@ietf.org
X-Mailman-Version: 2.1.22
List-Id: "Layer Independent OAM Management in Multi-Layer Environment \(LIME\) discussion list." <lime.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lime>, <mailto:lime-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lime/>
List-Post: <mailto:lime@ietf.org>
List-Help: <mailto:lime-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lime>, <mailto:lime-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 26 Oct 2017 14:30:09 -0000
Alia Atlas has entered the following ballot position for draft-ietf-lime-yang-connectionless-oam-methods-11: 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-lime-yang-connectionless-oam-methods/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- After a useful conversation with Benoit, I better understand how the status-code and sub-status-code are intended to be used. While I do still have some concerns about the clarity and ease of using this, I do not think it is Discuss-worthy, so I have moved these to be Comments. a) It would be helpful to clarify that and how additional OAM YANG modules are expected to use the status-code identityref and sub-status-code identityref so that there is a clear indication of how OAM modules are expected to interact and be build to interact. b) To handle the cases where OAM mechanisms might be triggered by the RPCs but that OAM mechanism may not have an associated YANG module, it would be useful to be able to send back the numeric codes (whether status-code or sub-status-code). Maybe that's a generic module of status codes - but this could help with dependencies. These two points get to what I was concerned/confused by in (1) below. 1) on p. 19: " leaf status-code { type identityref{ base status-code; } mandatory true; description "Error code for continuity-check message, that is relevant to the protocol under use for CC. For example if ICMP is the protocol under use, the error codes are as defined in [RFC4443]."; }" I am quite unclear on how this could technically be used?? RFC4443 defines integer error codes or types and sub-codes that are also integers. Is the expectation that an ICMPv6-specific YANG module will define those codes as identityrefs??? Clarification in at least the description is needed, since I don't see how it could be used as currently defined. ======================================= 1) On p.6 : "leaf protocol-id-meta-data { type uint64; description "An optional meta-data related to the protocol ID. For e.g., this could be the Internet Protocol number for standard Internet Protocols for help in protocol processing."; }" Seems very useful - but how and where would a tool be able to learn the expected contents and parsing of the protocol-id-meta-data? I do not see any indication in the module on p.16 where the protocol-ids are defined - not even in the descriptions much less programmatically. 2) The complete data hierarchy in Sec 3.2 is confusing in a couple ways. First, it isn't clear what is going to be defined in this document and what is from draft-ietf-lime-yang-connectionless-oam-14. Second, the groupings are all expanded - which makes it very hard to see the logical structure & requires sanity-checking that the same information appears.