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

Mahdi Soleimani <mahdi.soleimani@yale.edu> Wed, 31 May 2023 19:21 UTC

Return-Path: <mahdi.soleimani@yale.edu>
X-Original-To: alto@ietfa.amsl.com
Delivered-To: alto@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8DD6C151998 for <alto@ietfa.amsl.com>; Wed, 31 May 2023 12:21:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.094
X-Spam-Level:
X-Spam-Status: No, score=-2.094 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=yale.edu
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tKVKQ6XQmI7B for <alto@ietfa.amsl.com>; Wed, 31 May 2023 12:21:12 -0700 (PDT)
Received: from mail-oo1-xc2a.google.com (mail-oo1-xc2a.google.com [IPv6:2607:f8b0:4864:20::c2a]) (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 ietfa.amsl.com (Postfix) with ESMTPS id EE37CC15198D for <alto@ietf.org>; Wed, 31 May 2023 12:21:12 -0700 (PDT)
Received: by mail-oo1-xc2a.google.com with SMTP id 006d021491bc7-557c27145d4so6707eaf.1 for <alto@ietf.org>; Wed, 31 May 2023 12:21:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yale.edu; s=googleprd; t=1685560872; x=1688152872; h=cc:to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=nyGisPwQ4f5wUSQfRCiDSniehuqeaUdjBIfBXhNPOl8=; b=u3yHaINPQrAP7zQ9GPuZJ5OiiRgsrN6+tnA+jwmIOxd1psholr/PA9eyFI0X3R2cHp DD3IBWVhNPBx93y7JIP8fjKZ5go/dDlpCTD9gmyoQ14YC7BwP4FzzAGjrGWO6WJji97t 4aT7tRN1Jjf4FQCr1dYoVzsJAgEFec1fxSmPw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1685560872; x=1688152872; h=cc:to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=nyGisPwQ4f5wUSQfRCiDSniehuqeaUdjBIfBXhNPOl8=; b=a8qEN57wPqbHwSIZTNM3gqNuIa+IOi5+4VL0GmBfwWaYYhTjIOYDNfV88S9uRH+Qna 0Qx35uf1Z26P+zKzSBdDUqLULYlpmKinQUF3wP8RwYkmxN0C+3urlhu799AVPJdhWBdS ObwICf+xUoTa3fDSxJsG5Q/ExeQmOMg0DoSaqJrK8r1zSwQmDC5E4XbaolHiIQdi4V+M DT30lRsUpUpCKgKr3Od/HCOBkXoULJk1X7uYuDSNHftZ5FJLJXr08bEsZBSAspSu8ykE p1QdQQGcGMBSIXxHdrBYtWnE9e3D2Z9mG/voxixpfeL/AnmwG3rnZarvAVNkwx6SxXJn Us+g==
X-Gm-Message-State: AC+VfDzqcoY7SesS0JQeRzSHFtkIT6qc6yEAZHkPU7MAa+gjZlAscjcC i2ZjF/sCeKad0qHjSNFvMVOhaFNKp0PxW5UcBZJb1WHFZn76UehIBPg=
X-Google-Smtp-Source: ACHHUZ5DBuymo+Ff3stn/INrcXVCtb8aN79VDsgoytp0z20PQmBqTJEdTLNbd+p/kYMOB/qqKjI7thlBt0bIIzMCEdo=
X-Received: by 2002:a4a:bd8e:0:b0:555:87eb:bc14 with SMTP id k14-20020a4abd8e000000b0055587ebbc14mr1443720oop.0.1685560871794; Wed, 31 May 2023 12:21:11 -0700 (PDT)
MIME-Version: 1.0
From: Mahdi Soleimani <mahdi.soleimani@yale.edu>
Date: Wed, 31 May 2023 15:20:35 -0400
Message-ID: <CAESy9RBW77hb2-WWmFTB09XYGG2Jk1gne10U6Nz+isYQ2483QA@mail.gmail.com>
To: draft-ietf-alto-oam-yang@ietf.org
Cc: alto@ietf.org
Content-Type: multipart/alternative; boundary="00000000000002d31405fd02397b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/alto/oXCo8ElvuafxC1GTPzp1G8T7nqw>
Subject: [alto] Another review for draft-ietf-alto-oam-yang-08
X-BeenThere: alto@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Application-Layer Traffic Optimization \(alto\) WG mailing list" <alto.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/alto>, <mailto:alto-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/alto/>
List-Post: <mailto:alto@ietf.org>
List-Help: <mailto:alto-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/alto>, <mailto:alto-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 31 May 2023 19:21:16 -0000

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.

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.
   2.

   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.
   3.

   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.

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."
   2.

   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.
   3.

   A reference to the relevant figure is missing from section 5.3.4.
   4.

   On page 7, section 4.4 under "performance monitor," instead of "during,"
   it should be "while" to accurately convey the intended meaning.
   5. 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?

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