Re: [Lime] Last Call: <draft-ietf-lime-yang-connectionless-oam-11.txt> (Generic YANG Data Model for Connectionless Operations, Administration, and Maintenance(OAM) protocols) to Proposed Standard

Huub van Helvoort <huubatwork@gmail.com> Wed, 29 November 2017 20:38 UTC

Return-Path: <huubatwork@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 9FA15126BF6; Wed, 29 Nov 2017 12:38:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.976
X-Spam-Level:
X-Spam-Status: No, score=-1.976 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, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no 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 47FT5hyR3yOQ; Wed, 29 Nov 2017 12:38:50 -0800 (PST)
Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (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 1E6381200CF; Wed, 29 Nov 2017 12:38:50 -0800 (PST)
Received: by mail-wm0-x22b.google.com with SMTP id t8so8893531wmc.3; Wed, 29 Nov 2017 12:38:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=reply-to:subject:to:cc:references:from:message-id :disposition-notification-to:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=1De0CODwx//ZkqT+ARgriBaXv9oUj5qc8t56vGZzPK8=; b=HWcmILuuO7sLqUExuajQvhp6NJ9nzMRFBGpAx06ylLrPzNIIrKn/RHoUruWkRGDAeB pzpM7/UaohCOLCHa+XS103rSGvj5/ACpM2+PJh0OAJQHKjJR2LTg0hvPyah7EDgLUVpb sbYXtR0FEv7+I4qKyqpFMNYaEZMnnb5TfuBkDIt7gBOF+ImJ/odqipNC3m1LS/NWDEQQ 4b4BTuzLFfO3vVcPdbRQSxFwlhLEq+OZOGaO7/tCRGkDVyKp8sVFLQV9Xh9mnIbo3NK7 mMKt8riZbP/6v/Z1fWkX3xhr+QcKnjDcYeP1XddYKX4ZC/Ah04GSA9N7eM2VUHHhh+HC ZAQw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:reply-to:subject:to:cc:references:from :message-id:disposition-notification-to:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=1De0CODwx//ZkqT+ARgriBaXv9oUj5qc8t56vGZzPK8=; b=ILVsvYH9sNJaadhjeU/ykEWxwzA62YeteUGl8ip6g6Cu/HnGSPNcuXuXri3TaC/V4x k3nXKpFKeKC8OoYwAw/eCdFz0IxTdWdWe/jlCMatWyQ4plWgMLbdb15bo0xxaaUuyi1M F2ERLiM/lUh8/5DBQ9tpYLaCgJwPOlHZWso1Qs/FQZl5wsr/SE+i+hX3GI7WSHs0ew6c Rs/dFaJjMngkHXymj5qjfAgzJJwge16nsLfOgbeEsjNr5d3zHXXu1KfAQOiWgRJyUd1G z2OgiFeExrraN9cKa8KvUoSAwJBtRFog7M5ZEf+6Blrrel0nRiRTFdE62QaWCFPQpqx0 WpSA==
X-Gm-Message-State: AJaThX6fWfiI3Rw7UhdHDVV15ODozYf3a96E41bFktTnYC/1+96wITw4 Azo3vgSO3Cck00HJFV+RhAb1VA==
X-Google-Smtp-Source: AGs4zMaW5UpuGzJ1s9LvX9uoJqcA61MfHj4jkieEhI+/P7TgLTqP1iSj+HHH5rJVWlUVdc5BbGdTGQ==
X-Received: by 10.80.219.69 with SMTP id b5mr9572464edl.218.1511987928053; Wed, 29 Nov 2017 12:38:48 -0800 (PST)
Received: from McAsterix.local (g77189.upc-g.chello.nl. [80.57.77.189]) by smtp.gmail.com with ESMTPSA id w13sm2187246edk.46.2017.11.29.12.38.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 29 Nov 2017 12:38:47 -0800 (PST)
Reply-To: huubatwork@gmail.com
To: "Carlos Pignataro (cpignata)" <cpignata@cisco.com>
Cc: "Benoit Claise (bclaise)" <bclaise@cisco.com>, Greg Mirsky <gregimirsky@gmail.com>, Qin Wu <bill.wu@huawei.com>, The IESG <iesg@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>, "Ronald P. 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>
References: <150772925005.24695.3851410645764765123.idtracker@ietfa.amsl.com> <CA+RyBmVq9MnC97LuVRzhYiR+_dj0gQ2YRSp+b-223fjQXvhR_w@mail.gmail.com> <CA+RyBmXfB2fPn8GzaWYKwUJZhLwnKc_raO9ELf+8ANnAcED-vA@mail.gmail.com> <B8F9A780D330094D99AF023C5877DABA9AC0F246@nkgeml513-mbx.china.huawei.com> <CA+RyBmXhhxcrrhfB+ZT9A813_M35U4zuirWpt6YhM5rwGN09eQ@mail.gmail.com> <B8F9A780D330094D99AF023C5877DABA9AC15C2E@nkgeml513-mbx.china.huawei.com> <CA+RyBmV9vN-pzUjBNmDhYL7=E52w3NNDGk5OWGNnn1g1wrkrjA@mail.gmail.com> <B8F9A780D330094D99AF023C5877DABA9AC173CC@nkgeml513-mbx.china.huawei.com> <CA+RyBmXsE6WHEWBb4ReYN3O6ztNTFZ4nG-YOBvxjQvckxc=XHQ@mail.gmail.com> <499e8dc0-fcac-a3a9-e3ae-630691b70bc4@gmail.com> <0888e2d6-f39f-1683-b174-5e3d19df1eae@cisco.com> <3b6c5ab3-ff5e-1d1a-313c-2dd7bdd0919d@gmail.com> <646B9160-2BBF-4546-9163-D6504A47C7D7@cisco.com>
From: Huub van Helvoort <huubatwork@gmail.com>
Message-ID: <1b527039-bf80-ead5-e341-c8cfeb24f855@gmail.com>
Date: Wed, 29 Nov 2017 21:39:22 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <646B9160-2BBF-4546-9163-D6504A47C7D7@cisco.com>
Content-Type: text/html; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/lime/mlJGU6pMpASONyFgfNVRP8CduVQ>
X-Mailman-Approved-At: Wed, 29 Nov 2017 13:08:11 -0800
Subject: Re: [Lime] Last Call: <draft-ietf-lime-yang-connectionless-oam-11.txt> (Generic YANG Data Model for Connectionless Operations, Administration, and Maintenance(OAM) protocols) to Proposed Standard
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: Wed, 29 Nov 2017 20:38:53 -0000

Hello Carlos,

Thank you for the additional information.

As I mentioned I already looked at version 18 because that was mentioned
in Gregs response.

I have understood that this draft was discussed in Singapore.
Unfortunately the agreed resolution was not reported on the list.
That is why I missed (part of) the discussion.

I will have no further comments.

Best regards, Huub.

-----------
Additionally, please see https://www.ietf.org/rfcdiff?url1=draft-ietf-lime-yang-connectionless-oam-17&url2=draft-ietf-lime-yang-connectionless-oam-18" class="" rel="nofollow">https://www.ietf.org/rfcdiff?url1=draft-ietf-lime-yang-connectionless-oam-17&url2=draft-ietf-lime-yang-connectionless-oam-18, which shows the changes relevant to that specific comment.

I believe the authors are using text suggested by Greg.

Like Benoit said, the document is approved and in the RFC Editor queue:

Best,
 

Carlos Pignataro, carlos@cisco.com

“Sometimes I use big words that I do not fully understand, to make myself sound more photosynthesis."

On Nov 28, 2017, at 5:21 AM, Huub van Helvoort <huubatwork@gmail.com> wrote:

Hello Benoit,

You reply:
For your information, the document is now in the RFC editor queue, ready to be published.
https://datatracker.ietf.org/doc/draft-ietf-lime-yang-connectionless-oam/" rel="nofollow">https://datatracker.ietf.org/doc/draft-ietf-lime-yang-connectionless-oam/
I had not seen any response from the authors to the email from Greg
(I checked the archive) so I assumed that the issue was still being
discussed.
Other on-line comments were addressed by the authors.

I also checked for updates to version 18, but did not find any, so I
don't know how the issue has been resolved.

So now I have to wait until the RFC is published.

Regards, Huub.

=========

Hello Greg,

I agree with you that the current (version 18) text in section 3.3 is very confusing.

Authors:

If I look at the definition of TP in section 2.2 I think a TP is similar
to a maintenance point as defined for Ethernet. Am I correct?

I don't understand why there are TPs with no neighboring TPs,
where will their initiated OAM test be sent? Or where are OAM
tests they react to initiated?

It is IMHO also possible that there are TPs with a neighboring
TP before AND a neighboring TP after the current TP.

Please explain.

Regards, Huub.

---------

Dear All,
I was under impression that that question of oam-neighboring-tps has been discussed and since authors couldn't produce technical rationale for this object we've agreed that it will be removed altogether from the grouping connectionless-oam-tps. But authors just changed name from level to position but had missed to synchronize descriptions in the model and in section 3.3. The later still refers to vertical layers:
                     "List of related neighboring test points in adjacent
                     layers up and down the stack for the same interface
                     that are related to the current test point.";
while the model insists that it is peering relationship:
        description
          "The relative position
           of neighboring test point
           corresponding to the current
           test point. Level 0 indicates no neighboring
           test points placed before or after the current
           test point in the same layer.-1 means there is
           a neighboring test point placed before the current
           test point in the same layer and +1 means there is
           a neighboring test point placed after the current
           test point in same layer.";
So, what is it? Perhaps it is time to remove list oam-neighboring-tps altogether also because having it s fixed size list is plain wrong. (Sorry for being so blunt but I commented too many times on the same to no avail from the authors).

Regards,
Greg


-- 
================================================================
Always remember that you are unique...just like everyone else...