Re: [alto] draft-ietf-alto-oam-yang review (Part 1)

Jensen Zhang <jingxuan.n.zhang@gmail.com> Tue, 23 May 2023 13:06 UTC

Return-Path: <jingxuan.n.zhang@gmail.com>
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 6EB88C14CE40 for <alto@ietfa.amsl.com>; Tue, 23 May 2023 06:06:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.095
X-Spam-Level:
X-Spam-Status: No, score=-2.095 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, 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 (2048-bit key) header.d=gmail.com
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 ljdGPF3ng8-o for <alto@ietfa.amsl.com>; Tue, 23 May 2023 06:06:21 -0700 (PDT)
Received: from mail-wm1-x336.google.com (mail-wm1-x336.google.com [IPv6:2a00:1450:4864:20::336]) (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 03ED9C14F738 for <alto@ietf.org>; Tue, 23 May 2023 06:06:20 -0700 (PDT)
Received: by mail-wm1-x336.google.com with SMTP id 5b1f17b1804b1-3f608074b50so16635515e9.0 for <alto@ietf.org>; Tue, 23 May 2023 06:06:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1684847179; x=1687439179; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=K6VsFR6FB4VAdTiLPxHIjfUPsIvnc5x3zFplTcDbwQM=; b=abus+cAgA5DC238kr5UcBcPgz1M+jE8dLxhJ/Z6CIv5IddJtTcYJ4Aer741g9Xgggl etmagVl068C62v7EEFFm9K/vp7pRkzb2PmygMrWg8UqPFiC/tfenHFEeG2UXZ2o25lY4 w/a3s9odz1Grd84pO5Lbs/IAbtj0ScA3bv8yrYe3LUJXDHxyB+zEgBoEOTO0oEHToQ15 /C4yiZrdBQH/qYWqP8ICsn+eUJCX6Al7H6Qq4uxO6+4lEVYm5sbTTHnnH+/6tj1DyOrk 4qZMcqLixfkFqYvxPDEScd9u2ZdAxzRpMatKs82YDaJrjAaCCS5xh65azXJdQUdpTZFN iReQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684847179; x=1687439179; 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=K6VsFR6FB4VAdTiLPxHIjfUPsIvnc5x3zFplTcDbwQM=; b=EXSIAzh93nXKSPvACT4gYwV3PNO9w+xmPILdhALo+qoVxDEK+BMyE4npXUUnCQKjGw aOYcWBvnsN5MUDt5aKh0zTKA9Zk81+sPXE7LujO2iW1sAxDvtNbu6zoODkGcFpLAexh1 VKY5cE2vSvJxCLf3uF+HW6dZxkw1fwUUmrNR+dg5dNAGOF9B9hfE6OjRbCVIL3odKpw4 d+dbkXreIuNM4td/S+w6nJrjJDfgWPApULWYWVQ4F18LecFLghMGolbaPZUUE4Ml0L9A yi0zIMbDyVu3MedXewdCQ3mQRLsXjEGSq1fDlHZjclXXL/5QSS98xofpBhwAoN1SK3va 9Hpw==
X-Gm-Message-State: AC+VfDxEMMdRnADAL7Qly53uS5bAqMXqCC+JLCwf12MH4QkDW8Eoy3D8 t8uzS5xRLKS3S42N7XnkD4Dg+ADHm3mgSElBBMPTxsW9+T0=
X-Google-Smtp-Source: ACHHUZ6UgsdHdwgm1ial/I0+rettqXArPs8qo2wOSkymWfmxvg4bsom8q21B3SeJpwx+riLA8328jYf1hn3gGi0/4FA=
X-Received: by 2002:a1c:e905:0:b0:3f5:fbd0:94ab with SMTP id q5-20020a1ce905000000b003f5fbd094abmr7381728wmc.3.1684847178844; Tue, 23 May 2023 06:06:18 -0700 (PDT)
MIME-Version: 1.0
References: <CANUuoLpW5tPPB6-WjUb21rCKMw4pHQ+KwsetpFWQVVJL+sF0Fw@mail.gmail.com>
In-Reply-To: <CANUuoLpW5tPPB6-WjUb21rCKMw4pHQ+KwsetpFWQVVJL+sF0Fw@mail.gmail.com>
From: Jensen Zhang <jingxuan.n.zhang@gmail.com>
Date: Tue, 23 May 2023 21:06:07 +0800
Message-ID: <CAAbpuyqY3JxSbCCkyrLbNyBDq4647mQ7jh-Jj8G+N4y+Ueewuw@mail.gmail.com>
To: "Y. Richard Yang" <yry@cs.yale.edu>
Cc: IETF ALTO <alto@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000988c9905fc5c0d3f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/alto/euJsBC-FAUr17fxYOOmUoutHEtw>
Subject: Re: [alto] draft-ietf-alto-oam-yang review (Part 1)
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: Tue, 23 May 2023 13:06:23 -0000

Hi Richard,

Many thanks for your wonderful comments. Please see my response inline.

Looking forward to seeing your further review comments.

Thanks,
Jensen


On Mon, May 22, 2023 at 10:23 AM Y. Richard Yang <yry@cs.yale.edu> wrote:

> Hi Jensen, all,
>
> Thank you for authoring the OAM document. It clearly is a massive effort
> on an important task that helps with ALTO development. In the first part of
> this review, I will focus on early text and structure. I will review the
> yang model details soon.
>
> High-level structure: My understanding of the model structure is that it
> consists of (Figure 2)
> - a set of alto clients
> - an alto server
>
> It helps, to me, that Figure 2 gives all of the top-level structures; that
> is, it lists the complete first-level structures under alto-server, instead
> of using ...
>
> In particular, the structure appears to be a bit interleaved. For example,
>
> - It looks that the access control is somehow flattened into the top
> alto-server container (Figure 2): auth-client and role
> Should they belong to a sub structure that defines access control? Such a
> contained structure may allow easier replacement/plug and play?
>
> Similar to access control, sever level op also appears to be
> flattened (Figure 4). For example, why is cost-type in the top level?
>
> In general, what is the principle to define the current container
> structure? It helps to clarify.
>

That's a very good suggestion. Although Section 5 has explained each
subtree structure, it is still helpful to restructure the module to make
the mapping clear.


>
> ==== Some details ====
> Abs/Intro: I appreciate that the document follows RFC6291 when using the
> terms, Operations, Administration, Maintenance, Management, OAM, and O&M.
> But these terms are defined for the context of managing a network, not a
> service such as ALTO. It helps to clarify/motivate why this document can
> follow RFC6291. It looks like this document uses only O&M and if so, it
> helps to make clear that this is the case.
>

Good capture. We will explain how these terms are applied in this document.


>
> Abs: “The operator can use these data models to set up an ALTO server, ..”
> => “The operator of an ALTO server can use these data models to set up the
> ALTO server, “ More generally, it helps to give an order of the workflow.
> For example, the words “set up” and “create” appear to be redundant. Also,
> the abstract mentions sever but the document also has client.
>

Good point. We will update the abstract as the following:

OLD:

  ... The operator can use these data models to set up an ALTO server,
create, update and remove ALTO information resources, manage the access
control, configure server discovery, and collect statistical data.

NEW:

  ... The operator of an ALTO server can use these data models to (1) set
up the ALTO server, (2) configure server discovery, (3) create, update and
remove ALTO information resources, (4) manage the access control of each
ALTO information resource, and (5) collect statistical data of the ALTO
server. The application provider can also use these data models to
configure ALTO clients to communicate with known ALTO servers.


>
> Intro: “This document defines a YANG data model”, but the title and abs
> say models. The rest of the 1st paragraph uses one model. It helps to be
> consistent in saying models or model. You may search the document and find
> model vs models and be consistent (e.g., first para of 4.2). It might be
> that a model consists of multiple modules.
>

We will fix all the inconsistent words in the next revision.


>
>
> Intro: “implementation-agnostic“. It helps to make clear the list in
> Section 4.1 early.
>

OK. We will also summarize the scope list in the introduction.


>
> Intro: “... the design will also be extensible for future standard
> extensions.” This is a hard-to-defend statement because an extension could
> be a major change. How about not making this statement?
>

Will remove this.


>
> Overall suggestion: reorganize paragraphs 2,3,4.
>
> Sec. 3.1 “names of data nodes and other data model objects
>    are often used without a prefix, as long as it is clear from the
>    context in which YANG module each name is defined.  Otherwise, names
>    are prefixed using the standard prefix associated with the
>    corresponding YANG module”
> => // use singular
> “the complete name of a data node or data model object
>  includes a prefix, which indicates the YANG module in which the name is
> defined.
>  We omit the prefix when the YANG module is clear from the
>    context;  otherwise, we include the prefix.
>    The prefixes indicating the corresponding YANG modules are shown in
> Table 1”
>
> Sec. 3.2 3.3: Does Table 1 miss a few prefixes, for example, ncc?
>
> Sec. 4.1: “Functionality/capability configuration of ALTO services.” =>
> “Configuring functionality/capability of ALTO services.” to be consistent
> with the other items
>
> Sec 4.4: “Figure 1 shows a reference architecture for the ALTO server
>  implementation.” => Figure 1 shows a reference architecture for an ALTO
> server implementation.” ?
>
> Sec. 5.1: Thanks for providing a reference architecture. Two quick
> comments. (1) It helps to say a few words about what a client is and hence
> one may get a sense of the client id it. Is it a running instance or a
> template?  (2) An immediate reaction is that a “data source” can be another
> alto client, for multi-domain integration.
>
> Sec. 5.3 “The ALTO server instance contains a set of data nodes
> server-level operation and management for ALTO that are shown in Figure 4.”
> Fragmented sentence?
>
> Sec. 5.3.2 shonw
> Sec. 5: ird -> IRD in text because it is an acronym?
>

Thanks for the editing suggestions above. We will consider them in the next
revision.


>
> _______________________________________________
> alto mailing list
> alto@ietf.org
> https://www.ietf.org/mailman/listinfo/alto
>