Re: [Lime] Alia Atlas' Discuss on draft-ietf-lime-yang-connectionless-oam-15: (with DISCUSS and COMMENT)
Alia Atlas <akatlas@gmail.com> Mon, 30 October 2017 14:56 UTC
Return-Path: <akatlas@gmail.com>
X-Original-To: lime@ietfa.amsl.com
Delivered-To: lime@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4082613ACAB; Mon, 30 Oct 2017 07:56:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 QB6IownUq992; Mon, 30 Oct 2017 07:56:12 -0700 (PDT)
Received: from mail-wr0-x22d.google.com (mail-wr0-x22d.google.com [IPv6:2a00:1450:400c:c0c::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90C2C13FA20; Mon, 30 Oct 2017 07:56:11 -0700 (PDT)
Received: by mail-wr0-x22d.google.com with SMTP id j15so12908290wre.8; Mon, 30 Oct 2017 07:56:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=PqsOtyl2RD/QW50PQdL4IUB2EbiIKqybF+COWOC3wIU=; b=JqpvbxBiO+lrGF3LXAqhDRS0D4HLgYGmJNhKs5p5ibUNifPTYQNI6R7Lqhk/6s8vyM T0qzBpSyXDLVvtp7SnUt9RS7iEE89KNjOyr8qJI/47B5aZLe/v/gTwWOimA23oZe0WwA Qx5WGwMCKCsdR50nylM1buU3ySC8gb4dYNzzws0ngeothBFJNZAVLzqQFMP4CWJM6T+X bFV+4qrs0TC0N4Z5LCqvKybe4cgM0hy6WbU2FKVYMC+stb2q8DiP1KgN3R78p6dzkJ21 FdHHtmrjmo2vv17dpkqH3oTKQFznhOOzMPEvgRV6uBZPP5H6fgLaaMUwDu34GIgwgOf9 hoVA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=PqsOtyl2RD/QW50PQdL4IUB2EbiIKqybF+COWOC3wIU=; b=AqKdKnBAJ9ILj54kWCHZ2+jx/dR8N+Ui1NGx7AdsqYOqyxWTK7UlkU9VglI1TjYkkk 65AD9Anw4FEMvw+9+qjTBVRYrm2rkW0ZI9F44478O07FPQ3DmoGjj7mfy4EW9JCD2OlB 07yJISnjXNZy6zdBELYSuoit8ea/DDPm2eyUo+IUgSyKw3EIuDZouAgJcPKYXJCHSD3+ 4nD2xkk80g1HrrhAYQT/BdYo8xQswDXbNk06K3eNrp98o5k+Y+/Me02Swq/Gx7GR9naz jY8GEMgyZLIOueKCfWRTMC4RmW0V/uyQNXufwMx5VNU5/i4ouXwUK86CH4utBE6Oq8y8 D0bQ==
X-Gm-Message-State: AMCzsaVuYSGyHvHxMQ4bBXIK0Qm2BQJTs9RUgExVIS1AZGtytaT/GnEF llGuLLE3kvPnALQ1lzsKm+Dhtq3p2s81wUVPDVM=
X-Google-Smtp-Source: ABhQp+RhyfyXSIEdWJGQZbGapHSCkbhUb2F9aw/iosiNcydr81iThQeE/xpF7wz10IZZnqg9qFGG2XgoLCCpydbyL6c=
X-Received: by 10.223.199.138 with SMTP id l10mr7455739wrg.121.1509375369836; Mon, 30 Oct 2017 07:56:09 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.150.10 with HTTP; Mon, 30 Oct 2017 07:56:09 -0700 (PDT)
In-Reply-To: <B8F9A780D330094D99AF023C5877DABA9AC4E24B@nkgeml513-mbs.china.huawei.com>
References: <150937351328.3385.1279910938110067354.idtracker@ietfa.amsl.com> <B8F9A780D330094D99AF023C5877DABA9AC4E24B@nkgeml513-mbs.china.huawei.com>
From: Alia Atlas <akatlas@gmail.com>
Date: Mon, 30 Oct 2017 10:56:09 -0400
Message-ID: <CAG4d1reoRZmKmSAzhBGXfvpYzAhpt9FR2hjMC0Aqa1NyEvQk9A@mail.gmail.com>
To: Qin Wu <bill.wu@huawei.com>
Cc: The IESG <iesg@ietf.org>, Ron Bonica <rbonica@juniper.net>, "lime-chairs@ietf.org" <lime-chairs@ietf.org>, "lime@ietf.org" <lime@ietf.org>, "draft-ietf-lime-yang-connectionless-oam@ietf.org" <draft-ietf-lime-yang-connectionless-oam@ietf.org>, "cpignata@cisco.com" <cpignata@cisco.com>
Content-Type: multipart/alternative; boundary="089e0820dd10c08038055cc4d69c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lime/eoJcQFgtrEOy5hbzZrePf0FtFaY>
Subject: Re: [Lime] Alia Atlas' Discuss on draft-ietf-lime-yang-connectionless-oam-15: (with DISCUSS and COMMENT)
X-BeenThere: lime@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
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: Mon, 30 Oct 2017 14:56:15 -0000
Qin, All this sounds good. Thanks, Alia On Mon, Oct 30, 2017 at 10:51 AM, Qin Wu <bill.wu@huawei.com> wrote: > -----邮件原件----- > 发件人: Alia Atlas [mailto:akatlas@gmail.com] > 发送时间: 2017年10月30日 22:25 > 收件人: The IESG > 抄送: draft-ietf-lime-yang-connectionless-oam@ietf.org; Ron Bonica; Carlos > Pignataro; lime-chairs@ietf.org; cpignata@cisco.com; lime@ietf.org > 主题: Alia Atlas' Discuss on draft-ietf-lime-yang-connectionless-oam-15: > (with DISCUSS and COMMENT) > > Alia Atlas has entered the following ballot position for > draft-ietf-lime-yang-connectionless-oam-15: 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/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > I took a quick look through version -15 and it looks like it addresses > almost all of my serious Discuss points. The only Discuss-worthy point is > (c) below. > I have a few more points related to the changes that were made; they are > just comments & listed here to be with the original points. > > For version 15: > > a) In Sec 3.1, it still says > " o Router-id to represent the device or node. > [I-D.ietf-spring-sr-yang]" > > but [I-D.ietf.spring-sr-yang] has nothing to do with the router-id > > [Qin]: route-id is defined in ietf-rtgwg-routing-types, we will use > ietf-rtgwg-routing-types as reference. > > b) In Section 4, thanks for adding > urn:ietf:params:xml:ns:yang:ietf-lime-common-types - but could it be a > meaningful and accurate name like > ietf-lime-time-types or ietf-time-types (Benoit would know best > structure) > that clearly > shows its intended scope for reuse and please fix the description for it > too. > > [Qin]: I think we could use the former since later on, you may identify > more time related type and will fix the description. > > c) [I-D.ietf-rtgwg-ni-model] is still listed as informative, but the > model defined in there is imported "import ietf-network-instance { > prefix ni; > }" It needs to be normative > > [Qin]: Okay, will fix this. > > d) I-D.ietf-spring-sr-yang is still listed as informative - but not really > correctly used as a reference. > > [Qin]: Agree, I have replace it with ietf-rtgwg-routing-types. > ================= > > Thank you for your work on this document. I have a number of serious > concerns > - but they all amount to fixing up your references and slight > restructuring for clarity and reuse. > > 1) In Sec 3.1, the reference is system-id to represent the device or > node.[I-D.ietf-spring-sr-yang] I believe that should be "typedef router-id { > type yang:dotted-quad; > description > "A 32-bit number in the dotted quad format assigned to each > router. This number uniquely identifies the router within > an Autonomous System."; > }" > from draft-ietf-rtgwg-routing-types. > Certainly "[I-D.ietf-spring-sr-yang]" is NOT an informative reference with > such a dependency. > > I see that this document actually redefines router-id, instead of using it > as part of the included import from import ietf-routing-types { > prefix rt; > } > On p.27, I see "leaf system-id { > type rt:router-id; > description > "System ID assigned to this node."; > }" > so it is using the routing-yang-types, but renaming it as system-id, there. > Consistency isn't just the hobgoblin of little minds - it's actually > useful. > > In choice to-location, again "case system-id { > leaf system-id-location { > type router-id; > description > "System id location"; > } > > description > "System ID";" > using the locally defined router-id and renaming it instead of using > rt:router-id. > > 2) On p. 13 & 14, there are many identities associated with time and > time-stamps. I cannot believe that the best way to handle these is by > having > them as part of an OAM model! At a minimum, they should be defined as a > separate module and then included, even if it is in the same draft. Then > they will be available for reuse elsewhere. > > 3) This is extending [I-D.ietf-i2rs-yang-network-topo] - I do not believe > this should be merely an informative reference. > > 4) I cannot tell if I-D.ietf-rtgwg-ni-model is informative or normative; > it is not referenced in the draft - though there are fields that are > labeled NI without adequate description. > > 5) [I-D.ietf-rtgwg-routing-types] is not an informative reference. Its > module is imported and used. It must be normative. > > 6) [I-D.ietf-spring-sr-yang] is listed as an informative reference, but if > it were actually used as described, it would need to be normative. Instead, > I believe this can be removed as a reference. > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > > ============================== > a) Sec 3.8: It is unfortunate that the cc-session-statistics-data > structure is not a list of {traffic type, cc-session-statistics} instead of > hardcoded members for IPv4 and IPv6 traffic only. While it can still be > extended for additional traffic types, the naming may be inconsistent and > there's no requirement that the contents are cc-session-statistics. > > b) On p.9: " +--:(system-id) > | +--rw system-id-location? router-id" > > Why isn't this just named router-id instead of system-id, for consistency? > This comment applies throughout the draft. > > c) The use of "tp" to mean test-point is a bit unfortunate in a model that > is building off of the network topology one, which uses "tp" for > termination-point. > > d) On p. 13: "identity address-attribute-types { > description > "This is base identity of address > attribute types which are ip-prefix, > bgp, tunnel, pwe3, vpls, etc."; > }" > > I haven't a clue what is meant by a bgp address attribute type or a tunnel > one. > Can you please expand the description to be substantially more meaningful? > How is it used? > > On p. 24, I see these defined > " case bgp { > leaf bgp { > type inet:ip-prefix; > description > "BGP Labeled Prefix "; > } > } > case tunnel { > > leaf tunnel-interface { > type uint32; > description > "VPN Prefix "; > } > } > case pw { > leaf remote-pe-address { > type inet:ip-address; > description > "Remote pe address."; > } > " > but unlike the other cases with clear descriptions and references to the > relevant RFCs, these are NOT clear and do not even fully expand acronyms. > > e) "grouping tp-address-ni " Please expand what NI is the abbreviation > for in the description. > > >
- [Lime] Alia Atlas' Discuss on draft-ietf-lime-yan… Alia Atlas
- Re: [Lime] Alia Atlas' Discuss on draft-ietf-lime… Qin Wu
- Re: [Lime] Alia Atlas' Discuss on draft-ietf-lime… Alia Atlas
- Re: [Lime] Alia Atlas' Discuss on draft-ietf-lime… Qin Wu
- Re: [Lime] Alia Atlas' Discuss on draft-ietf-lime… Alia Atlas