Re: [Teas] Yangdoctors early review of draft-ietf-teas-actn-pm-telemetry-autonomics-08

Dhruv Dhody <> Mon, 11 July 2022 13:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 42CCEC05FA55; Mon, 11 Jul 2022 06:51:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.104
X-Spam-Status: No, score=-2.104 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id CGcjwV1C0-GM; Mon, 11 Jul 2022 06:51:31 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::d33]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by (Postfix) with ESMTPS id 68F90C16ED03; Mon, 11 Jul 2022 06:51:28 -0700 (PDT)
Received: by with SMTP id u20so4925417iob.8; Mon, 11 Jul 2022 06:51:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=AhoAIb1XgkGLWyoWjfe2cnka0qJ3ggQOzuIik7BnCb4=; b=Xr628lPmRAfeOt5SlS91aDoXgMFTU+B4SfQHWH81FEddglnbEpDBBM+s8cglRUElmI BDGubLgwjhG5HJm0Iyzfm///SwoiqbaPZ+SdnU1gLly0z9UROmoqrI3nVI+sFLnm6iKR LLXLaO26djVDlhqAd1+s2vtYiYvie7HrJRRguBeHVhaj0qX0N4BFWJr+5JqL4ix92LMy SPfuqxXji+mh8Z8pBRMfQ4lY6aRfMgE/KPNBQ7cIStpO+iCqEqjJU30rwj9DAI3su7Jw IiyDW/8yIXEbqwTetR41uwdoYifKvzilKs+gfM81T+hmt+lk1HhqH71YVEFIXoLL+G4u fOTg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=AhoAIb1XgkGLWyoWjfe2cnka0qJ3ggQOzuIik7BnCb4=; b=OYVgp+zsbeW6x1ICGBF3UCI363M3hDAeoKOzoftSk3hsXTDImFbGIBR0Gmz6bpQlv3 3IOQZkUCVoNvNY2KWVEqOHUPz44igeHe2IrM+awURsGHCeSkPzKlLK8J4qOfL81siua1 XU7KNt+BEFTUDAO5rWtLag/Nx41jfnc7Hi7MQ5Y/fulXI97ND1uSuxX37GiXUMfpXY+s MrM2AsmIjiXKcBC4mB8k4WMPQLhdqugXb9sDkMVx/mZ8vXJ5LAo1Dl4Jo8PDWKcAJ0ja pGjphdSNxEEy6FukVS29q5ozvEt8j/+1qMN6pkKNrfqg8qucaCEmF5UD/y0fQhRql1et iFMw==
X-Gm-Message-State: AJIora/9Txbfo5w4BQTE/7jrnzy21l5cU2r0zK4UfyfyBJjeUQLcBKQJ a24BHuch/KUUsoy+dRoZWtmLLqnjkWxXBvj0MFy+gMEkTW/Txg==
X-Google-Smtp-Source: AGRyM1tDpElBuCB0LDMB/JTY/O2kyK6NbhqmTKR0CmgE2EPW6mMyrVhwZjU3epdSNsXOxQk9pbEjrjhadbuLhtwoWa4=
X-Received: by 2002:a02:a50e:0:b0:33f:363f:36d7 with SMTP id e14-20020a02a50e000000b0033f363f36d7mr8820716jam.161.1657547487221; Mon, 11 Jul 2022 06:51:27 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Dhruv Dhody <>
Date: Mon, 11 Jul 2022 19:20:51 +0530
Message-ID: <>
To: Reshad Rahman <>
Cc:,, "TEAS WG (" <>
Content-Type: multipart/alternative; boundary="0000000000002c9f1a05e387d99a"
Archived-At: <>
Subject: Re: [Teas] Yangdoctors early review of draft-ietf-teas-actn-pm-telemetry-autonomics-08
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Traffic Engineering Architecture and Signaling working group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 11 Jul 2022 13:51:32 -0000

Hi Reshad,

Thanks for your early Yangdoctors review. I have posted an update -

Please see inline.

On Sat, Mar 12, 2022 at 11:40 PM Reshad Rahman via Datatracker <> wrote:

> Reviewer: Reshad Rahman
> Review result: Ready with Issues
> This is my YANG Doctor review of
> draft-ietf-teas-actn-pm-telemetry-autonomics-08.
> I have reviewed the document and looked at references such as
> draft-ietf-teas-actn-vn-yang, RFC8453, RFC8309 etc. I think I got to grasp
> the
> intent of the document, at least the autonomics part. However I am not
> sure I
> fully understand how everything fits in together. I don't follow the TEAS
> WG
> anymore, I tried to catch up by searching the archive but I didn't see any
> discussions on this document in the archive. Having more examples may help.
I have added another example and did some rearranging of text.

> Comments on the document:
> The document title, abstract and YANG modules all use the term
> "telemetry". I
> do not see anything specific to telemetry in the YANG modules, it is just
> extra
> data being modelled in TE tunnels and VNs. There are a couple of examples
> with
> establish-subscription, but that IMO still doesn't the model telemetry
> specific.
I added a clarification in the abstract and introduction. I am shying away
from removing the term entirely as it is the key use.

> Introduction, 5th paragraph. I don't get "to provide an ability to program
> their customized performance monitoring subscription". Possible it's
> because
> I'm missing the big picture. My suggestion is to clarify/simplify. But if
> the
> WG is good with this, fine with me.
I did some re-wording, hope that helps!

> Introduction, 6th paragraph. The following statement is of some concern to
> me
> because of the potential confusion. Again, up to the WG. Nit: missing "way"
> after "different".
>  "The term performance monitoring is used in this document in a
>    different from how the term has been used in TE networks for many
>    years."
This text is now removed based on the comment from Greg.

> Section 2. Figure 1 is a nice diagram, but it is not clear where/how this
> document fits in.
It was coming from another document that is no longer progressing. It was
decided to keep the figure bit and remove the reference. I added text to
say it is just an example!

> Section 2, next to last bullet. "other SLA requirements". It would help
> to have
> an example of such an SLA requirement.

> Section 5.2. There's a mismatch between the text for figure 9 (copy-paste
> from
> text for figure 8?) and figure 9.
Updated, thanks for spotting it!

> IANA Considerations: For YANG module name registry, the reference should be
> RFC6020, not RFC7950.

> Comments on the YANG models:
> Why use identity for scale-op? enum seems fine for up and down.

> For threshold-time and cooldown-time, is it ok to have value 0?
Yes, added text for it.

> For threshold-value, why use a string. I realize using a union might be
> tricky
> here, but why not uint64? Is it because there might be a threshold which
> cannot
> be expressed as a value?
Uint64 could be an issue for float bandwidth. I created a union to
accommodate various values.

> Telemetry-id seems unnecessary. First it's not clear whether it's unique
> per TE
> tunnel. And, why invent a new "id", why not refer to the TE tunnel using
> its
> key?


> For scale-in and scale-out, by how much? Is there a missing leaf node or
> did I
> misunderstand how this works?
leaf scale (that we changed from string to unit64) is that!

> For grouping-op(eration), are "and" and "or" still needed considering
> those are
> in scaling-criteria-operation?
They are not and thus they are different identities.

> Typos:
> - analize (analyze)
> - interpritted (interpreted)
> - criterias (criteria)
Thanks for spotting these!


> Regards,
> Reshad.