Re: [alto] Another review for draft-ietf-alto-oam-yang-08

Jensen Zhang <> Tue, 13 June 2023 12:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 416E9C14CE4C; Tue, 13 Jun 2023 05:58:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 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_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 Pzvs8hTkQbgb; Tue, 13 Jun 2023 05:58:29 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::334]) (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 B98EBC14CF09; Tue, 13 Jun 2023 05:58:29 -0700 (PDT)
Received: by with SMTP id 5b1f17b1804b1-3f8c65020dfso8696535e9.2; Tue, 13 Jun 2023 05:58:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20221208; t=1686661108; x=1689253108; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=5cbOnPcxcgmbnQWU3LEdszm10RpEct51H8PmDl3kqC4=; b=O56WC1GNtKC/nhnQOAtKC2SBTh7snv3r5bJGsttcRm7icDsqbCXXrTKfs3CjAIuVNl eW10uDicjueALn4OtMzjURLiJNABfIM4+VGW5s34+FetRlNfwLToGp1zWItIxvr6rYne v+RoObrPqyusWv3LlyRDEbFVufTwodhFZ5XxJBZN2N4Z7ZVMmLoIBAzrs/HPbdbIqZ7z fTDJOIQxLaBqaqDGDZ2brorRm81yYRa505Zxt1s7w/W+IGqC8h2pZGGtveFZfk98fb5L oyk1IW3MwZDZ2zoNZDgaiHCzRxripy7hPB8w3PvyedO2/ZoXFhntftlkUnRLfOOOuaxk ujGg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20221208; t=1686661108; x=1689253108; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=5cbOnPcxcgmbnQWU3LEdszm10RpEct51H8PmDl3kqC4=; b=lJopSWxABzFqvbN5nNjlbxrmIjhd8Wjewg2Cyma4VUVc/oyBSpTGDHfO8lBG2Bqdq+ 5dppd5VoA7lmoVX50GiNnpScxJuMOERz2dBBJCbe0RuAcG/rtvw8SZ7S6TZBsU3bdkJX A1yhr6yxZGMW8+keZ7TRl87XTRZ+SRehWC/YUyGekDuFksN0AX0xyVXa4qR2ty9mapSW nP3f1L49pjL0SQ8RJ4jzKNHojx/+W57fVw0A88kDCjPHlHwJOOMKsaB+zvwQpf0mNiFz Q0yXMvDbs8GermqW48MwEFpg7rGXUlatVBi+xbcfX96S9l+9X4JtTzbSY/VxJ1Wbtz81 iaTA==
X-Gm-Message-State: AC+VfDxIoyQkIGm6w4GPgOfvLpLcJXxQYUfq+2Mvxl79lMN3vRv40zqJ BGfkbhAlgUBMrsWvDTvbytb8ttu6lzNEJDqbEWlkvBkwYLg=
X-Google-Smtp-Source: ACHHUZ42Fdf3np+nOT1OszYunIxOe/LfaOvEmIlr6SKp6Teq/a4jlbtPKnsBJtz6PSGWyzi5zdoGJnQFVOto4nokgJQ=
X-Received: by 2002:a05:600c:2948:b0:3f7:3a11:e3ae with SMTP id n8-20020a05600c294800b003f73a11e3aemr10347570wmd.38.1686661107925; Tue, 13 Jun 2023 05:58:27 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Jensen Zhang <>
Date: Tue, 13 Jun 2023 20:58:15 +0800
Message-ID: <>
To: Mahdi Soleimani <>
Content-Type: multipart/alternative; boundary="00000000000031ca1805fe026401"
Archived-At: <>
Subject: Re: [alto] Another review for draft-ietf-alto-oam-yang-08
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Application-Layer Traffic Optimization \(alto\) WG mailing list" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 13 Jun 2023 12:58:31 -0000

Hi Mahdi,

Many thanks for your review comments. Based on your comments, the authors
have revised the document. Please see our responses inline.

Jensen on behalf of co-authors of draft-ietf-alto-oam-yang

On Thu, Jun 1, 2023 at 3:21 AM Mahdi Soleimani <>

> Dear authors,
> I have reviewed the draft draft-ietf-alto-oam-yang-07 and have some
> comments to share with you.
> Firstly, I appreciate the concise and clear nature of the document. It was
> easy for me to follow the content, and I believe it lays a solid foundation
> for ALTO-OAM development purposes.
> The document's focus on requirements and providing point solutions for
> those requirements is valuable. However, I noticed that some sections, such
> as 5.4.3 and 6, are missing references to the requirements.
Thanks for catching that. We have added the missing references.

> Since the document is in its final stages, I would like to suggest some
> revisions to improve its readability.
>    1.
>    The document sometimes uses "model[s]" and "module[s]" interchangeably
>    to refer to single notions. For example, in 6.2, the last paragraph refers
>    to "IETF-alto-stats" as both a module and a data model. I believe the
>    intent of the document is to define YANG data models with multiple modules
>    that should remain consistent throughout.
> Thanks. We have made the usage of words consistent. Please check this PR:

>    1.
>    Regarding fault management metrics, I think a simple running count of
>    failure cases may not cover the full range of useful information for
>    administering and maintaining an ALTO server. The document could consider
>    providing additional data points that can guide debugging. For example,
>    snapshots of performance metrics or simple metrics like failure times could
>    be useful. Using failure times, relevant debugging information can be
>    extracted from Syslog.
> Agree. Although the failure times can be found from syslog, putting them
in the data model should be useful.

>    1.
>    On page 18 (section 5.4.2), the definition of the first category of
>    type-specific parameters is not clear. Although the definition of
>    "information resources with specific capabilities (e.g., cost constraints)"
>    is clearer in 9.1.5 of RFC7285.
> Sorry, we don't fully understand your concern here. Could you point out
any potential ambiguity?

> 3.1 Additionally, on the same page, if these two categories are the only
> possible classes, "include two categories" should be changed to "fall into
> two categories."

>    1.
>    The very last sentence of section 5.4.3 is complex. A simpler
>    rephrasing could be: "If an authenticated ALTO client is included in any
>    roles with access permission to a resource, the client is granted access to
>    that resource."
> Good suggestion. We have revised the sentence.

>    1.
>    Regarding the resource usage limits defined in section 5.4.2, a more
>    generic definition that is extensible to general resources, not just
>    limited to memory usage and the number of active update streams, would be
>    favourable. While these two measures may seem the most important/desirable,
>    a broader approach would be beneficial.
> Indeed. But the generic notification may be too complex for the base
model. So we are willing to leave this part for future extensions.

>    1.
>    A reference to the relevant figure is missing from section 5.3.4.
> Could you point out which ref is missing?

>    1.
>    On page 7, section 4.4 under "performance monitor," instead of
>    "during," it should be "while" to accurately convey the intended meaning.
>  Actually, the performance monitor may be a separate service that can run
individually. Even if the server is down, the monitor may still be running.
So both "during" and "while" may not be accurate. But the collected metric
must be from a running server. So how about we change to the following:

"Collects ALTO-specific performance metrics at a running ALTO server."

>    1. The last comment might be my personal opinion, so please feel free
>    to neglect it by all means. The difference between management and
>    maintenance is not fully specified in the RFC6291. The intent of this
>    document is clearly broader than the definition of OAM in 6291 though.
>    Maybe the document can use O&M everywhere to align the terminology?
>  Yes, we are indeed using O&M in this document.

> Lastly, I would like to commend the team once again for writing such a
> clear and well-structured draft. Congratulations, and best of luck.
> I am currently reading the data model code at the end of the document, and
> if I have any comments, I will provide them upon completion. I have no
> comments on the extension examples in the appendix. The examples are very
> clear and informative. Thank you.
> Best regards, Mahdi