Re: [Gen-art] [alto] Genart last call review of draft-ietf-alto-cdni-request-routing-alto-16

Jensen Zhang <jingxuan.n.zhang@gmail.com> Tue, 07 September 2021 03:10 UTC

Return-Path: <jingxuan.n.zhang@gmail.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C38863A0D41; Mon, 6 Sep 2021 20:10:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qqQmV2rhh8oD; Mon, 6 Sep 2021 20:10:37 -0700 (PDT)
Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com [IPv6:2a00:1450:4864:20::42f]) (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 9174C3A0D40; Mon, 6 Sep 2021 20:10:36 -0700 (PDT)
Received: by mail-wr1-x42f.google.com with SMTP id b6so12255669wrh.10; Mon, 06 Sep 2021 20:10:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ET5A6XRepXdAAQbPlpyokjOfcAz0eCOZIdePtaVY0ps=; b=F/0c6OTNbmOBhKSbyVsFxCVHWOGwTnZ0PKzRYSdDg/Iv3rl/JBAv1mL9to2tHW+RmC 67QMR3QG76H70pzpkoKO11mGQVJ7jMsfuzxP6OzSBmfBm7PfJWE1H5Spqj4aC/bc4EMT pww8VT5r/UrDkAx82Le8IEfOTpPk/bf/7O5c2/2j8CgIex1N5RHWNtlKqqzx+XOOuQpf ujEFc4Mlyb3XnGx8wOwJZCV5TaoYC/1tChWC7IsfFhyv+QXlykIj5u1cdjV1ujF/PjeQ Pw2PO6VGzBGyJueXuvWO89PqRPWJUXsy/tWnuAhk6DQScsBMZqGk8AngXbz95ifrhfRY aGpA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ET5A6XRepXdAAQbPlpyokjOfcAz0eCOZIdePtaVY0ps=; b=ULI4oigr/nsPo5dV9uLBxxtTgnJ1WfNml5RUWpgck5UjBSOqjF3R5V+tieqBf8tSgE Hxdp4wG0X5sndLLsOQBP1M4L7aPWlR+y8mFEIYvTmr0Qe6BQ3NPEvLtmxQz6Q3ZmDxMy 4YHFmNPge+GXuOt1w5MkNBE8DIRLDVWBqS37cBt8TmgmNHollnNSAd57BRlEw+TrIM7t Ke4hvCx42NPGbmvMUVkCetNXtnIzYjUlJHTuErjoT0+pm6oZT70eKLAQG2BOcVvj8YHz if3VnNWqNLSsxSJn8D1utnsRmo/YPVKY8B4+y/e5/ABp+O//l8h44K8hiz+nvK08lCmK +v9A==
X-Gm-Message-State: AOAM533bj1FbSwLEOSaEoVrQhVKpnrWdRQbpkFnJC5ez9L6Dfi2NmNE7 72klQ0nY8jRIdaiq1Pu9E48InI5RrkHMp2yPhShJh1wiFb3Xtg==
X-Google-Smtp-Source: ABdhPJz1R1t1uNo8ISZPW5ph2nuiFsN8ig3KWibMLXSyrglhVD1+62Cadho2hroEKMgGWQQIxD7KXb2J1j9Sa3zmvIM=
X-Received: by 2002:adf:ed0c:: with SMTP id a12mr16327591wro.102.1630984233595; Mon, 06 Sep 2021 20:10:33 -0700 (PDT)
MIME-Version: 1.0
References: <162938388879.9100.14963385308969703713@ietfa.amsl.com>
In-Reply-To: <162938388879.9100.14963385308969703713@ietfa.amsl.com>
From: Jensen Zhang <jingxuan.n.zhang@gmail.com>
Date: Tue, 07 Sep 2021 11:10:21 +0800
Message-ID: <CAAbpuyoLtgjjOjtzKzecXTbmMmzumtabSBCgJh7_FZO=QCd3ww@mail.gmail.com>
To: Russ Housley <housley@vigilsec.com>
Cc: gen-art@ietf.org, last-call@ietf.org, IETF ALTO <alto@ietf.org>, draft-ietf-alto-cdni-request-routing-alto.all@ietf.org
Content-Type: multipart/alternative; boundary="000000000000e0b73c05cb5f1b26"
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/-sKKg9KJcTmkJ15VWQ1maik4VWo>
Subject: Re: [Gen-art] [alto] Genart last call review of draft-ietf-alto-cdni-request-routing-alto-16
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 07 Sep 2021 03:10:42 -0000

Hi Russ,

Thanks for the very nice review. Please see our responses inline.

Thanks,
Jensen


On Thu, Aug 19, 2021 at 10:40 PM Russ Housley via Datatracker <
noreply@ietf.org> wrote:

> Reviewer: Russ Housley
> Review result: Almost Ready
>
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair. Please wait for direction from your
> document shepherd or AD before posting a new version of the draft.
>
> For more information, please see the FAQ at
> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
>
> Document: draft-ietf-alto-cdni-request-routing-alto-16
> Reviewer: Russ Housley
> Review Date: 2021-08-19
> IETF LC End Date: 2021-08-30
> IESG Telechat date: unknown
>
> Summary: Almost Ready
>
>
> Major Concerns:
>
> Section 2.2, "Security" bullet: it says:
>
>    o  Security: The identification between uCDNs and dCDNs is an
>       important requirement.  ALTO maps can be signed and hence provide
>       inherent integrity protection.  Please see Section 8.
>
> Section 8 does not talk about digital signatures.  Please add this
> discussion to Section 8.  In addition, if the digital signature is done
> well, it would provide both authentication and integrity protection.
>

Thanks for pointing out it. Although Sec 8 does not explicitly describe the
protection strategy, it cites Sec 15 of RFC7285 where the detailed strategy
is discussed.

We will update this bullet in Sec 2.2 as follows:

   o  Security: The identification between uCDNs and dCDNs is an
      important requirement (see Section 8). ALTO maps can signed and
      hence provide inherent integrity protection. Please see Section 15.1.2
      of RFC7285 for detailed protection strategies.


>
> Section 5.6, 3rd paragraph after bullets:  I do not understand the
> second MUST statement in this paragraph.  The sentence seems to contain
> a mix of defining the superset and a MUST statement.  I cannot suggest
> a rewording.
>

Yes, the original sentence mixed a definition and a MUST statement. To make
it easy to read,
we would like to propose the following change to separate the definition
and the MUST statement:

OLD:

   The returned CDNI Advertisement resource MUST contain only
   BaseAdvertisementObject objects whose CDNI capability object is the
   superset of one of CDNI capability object in "cdni-fci-capabilities".
   Specifically, that a CDNI capability object A is the superset of
   another CDNI capability object B means that these two CDNI capability
   objects have the same capability type and mandatory properties in
   capability value of A MUST include mandatory properties in capability
   value of B semantically.  See Section 5.7.2 for a concrete example.

NEW:

   The returned filtered CDNI Advertisement resource MUST contain all the
   BaseAdvertisementObject objects satisfying the following condition: The
   CDNI capability object of each included BaseAdvertisementObject object
   MUST follow two constraints:

   o The "cdni-capabilities" field of the input includes a CDNI capability
object
      X having the same capability type as it.
   o All the mandatory properties in its capability value is a superset of
      mandatory properties in capability value of X semantically.

   See Section 5.7.2 for a concrete example.


>
> Minor Concerns:
>
> Section 1:  I think that the Introduction would be improved by
> stating very early that this document specifies an extension of the
> base ALTO protocol.
>

Thanks for the suggestion, we will explicitly make this statement.


>
> Section 4.2.4 includes:
>
>      data:     "/cdni-advertisement/capabilities-with-footprints
>      /0/footprints/0/footprint-value/-",
>      data:     "value": "germany"
>
> Since Section 6.1.2.2 says that a countrycode domain is encoded
> as an ISO 3166-1 alpha-2 code in lowercase, I was surprised to see
> "germany" in this example.
>

If you check the example in Sec 4.2.3, you will find "germany" here is not
a country code but an ALTO PID name.
If the name is confusing, we can change it to make it more like a PID name.


>
>
> Nits:
>
> General: Sometimes this document says "ALTO" and other times it says
> "The ALTO protocol". Please be consistent.
>

Fixed.


>
> Abstract: I think the Abstract can be improved.  I suggest:
>
>    The Content Delivery Networks Interconnection (CDNI) framework in
>    RFC 6707 defines a set of protocols to interconnect CDNs to achieve
>    multiple goals, including extending the reach of a given CDN.  A CDNI
>    Request Routing Footprint & Capabilities Advertisement interface
>    (FCI) is needed to achieve the goals of a CDNI.  RFC 8008 defines
>    precisely the semantics of FCI and provides guidelines on the FCI
>    protocol, but the exact protocol is specified.  This document
>    specifies a FCI protocol as an extension to the Application-Layer
>    Traffic Optimization (ALTO) protocol, and it follows the guidelines
>    in RFC 8008.


Thanks for the suggestion. The new text looks good. We will update it.


>
>
> Section 2.1, 4th bullet: please remove "(" and ")" in this text:
> "... prefix set (or ASN, respectively)."
>
> Section 2.1, last bullet: s/prior agreed/previously agreed/
>
> Section 2.1, last bullet: s/uCDN (upstream CDN)/uCDN/
>
> Section 2.2, bullets:  Please pick one style and use it for all of the
> bullets.  Some end with "(see Section X).", and others end with
> "Please see Section X.".  Please be consistent.
>

Fixed


>
> Section 2.2, 1st bullet: please make two bullets, one for
> Application Layer-oriented, and another for CDNI.
>

This bullet explains that ALTO is can provide application layer-oriented
information and therefore is a good match for CDNI.
I am not quite sure what you mean by separating this bullet. Could you
explain more? Thanks.


>
> Section 7.1, Table 1: Please adjust the table so that the media subtype
> is not split across two lines.  Without changing the column widths, I
> suggest:
>
>    +----------------+-------------------------+------------------------+
>    | Type           | Subtype                 | Specification          |
>    +----------------+-------------------------+------------------------+
>    | application    | alto-cdni+json          | Section 3 of RFCthis   |
>    |                |                         |                        |
>    | application    | alto-cdnifilter+json    | Section 5 of RFCthis   |
>    |                |                         |                        |
>    +----------------+-------------------------+------------------------+
>
>    [RFC Editor: Please replace RFCthis with the published RFC number for
>    this document.]
>

Thanks for catching it. This is a format issue. We have fixed it.


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