[Lime] Alia Atlas' Discuss on draft-ietf-lime-yang-connectionless-oam-methods-11: (with DISCUSS and COMMENT)

Alia Atlas <akatlas@gmail.com> Wed, 25 October 2017 17:44 UTC

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
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <150895344841.4822.10125571058175153773.idtracker@ietfa.amsl.com>
Date: Wed, 25 Oct 2017 10:44:08 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/lime/h4JaPcEPV54q6tl968lvDorENe8>
Subject: [Lime] Alia Atlas' Discuss on draft-ietf-lime-yang-connectionless-oam-methods-11: (with DISCUSS and COMMENT)

Alia Atlas has entered the following ballot position for
draft-ietf-lime-yang-connectionless-oam-methods-11: Discuss

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/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

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.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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.

[Lime] Alia Atlas' Discuss on draft-ietf-lime-yan… Alia Atlas