[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.