Re: [Gen-art] [CDNi] I-D Action: draft-ietf-cdni-request-routing-extensions-07.txt

Barry Leiba <barryleiba@computer.org> Tue, 24 September 2019 15:16 UTC

Return-Path: <barryleiba@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 9C88E12091C; Tue, 24 Sep 2019 08:16:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.922
X-Spam-Level:
X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.026, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 JptCPWNcqCYD; Tue, 24 Sep 2019 08:16:02 -0700 (PDT)
Received: from mail-io1-f51.google.com (mail-io1-f51.google.com [209.85.166.51]) (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 67EE5120905; Tue, 24 Sep 2019 08:16:02 -0700 (PDT)
Received: by mail-io1-f51.google.com with SMTP id n197so5305963iod.9; Tue, 24 Sep 2019 08:16:02 -0700 (PDT)
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:content-transfer-encoding; bh=EEY7mJjR2nvgM+On/P/dXUcp+AvuPES5KLGYwcfcsoQ=; b=cLG22WsfBwe1i1S26pMIM2h+6uCuq1I4hfP2qZL9+zxYSUMwI/39WChry/eCCnqT2J 53WsMNzG0EuoAalhPXRht0nD9PFsR5SzyK0qNZl619B53ez72ee8CDKU+PnT7Dl8sVX4 NS/CR6i+DHTSQ7WiTA9W7Eb8UFcnMN6GIEazr8l9Osg4B6HAUPQi13+u3TvSzwQBkoFe 2FsPWlS01ubaagpt+yVazMLXYE4vmOAC2GLrebAHZSGVe7vpJpExizQHlhGNk7IDhXmy ou7Lf2bmXxmsOkk1GAPyux9pwUeW/7EV58dS/4S51Eqd9YxmC8SI2GFIfHPNGoof7DJX E7qg==
X-Gm-Message-State: APjAAAW6XSocQYJXFmuSXzkunLhwjeGczVRqpyuxgMnbDEQB+UWdw+uv Mo2y96sTT9cy/6Z7DVHwwGR66dqqIUXpeDZsYcp/NQ==
X-Google-Smtp-Source: APXvYqyq8/++j+Lg09TyJKfnL/fMInIcZws4VvfBSYA4tg9GrtCYhN5CQtEoUHmTMyPmsG/14IseqU0ilgTfAN49D1I=
X-Received: by 2002:a02:608:: with SMTP id 8mr4321441jav.88.1569338161072; Tue, 24 Sep 2019 08:16:01 -0700 (PDT)
MIME-Version: 1.0
References: <156933292629.15651.2153181471854597685@ietfa.amsl.com> <CAM8emGX8zbq663EpuQDt_B0Riu3mp60NaUXOPWQemjsmsTXHRA@mail.gmail.com>
In-Reply-To: <CAM8emGX8zbq663EpuQDt_B0Riu3mp60NaUXOPWQemjsmsTXHRA@mail.gmail.com>
From: Barry Leiba <barryleiba@computer.org>
Date: Tue, 24 Sep 2019 11:15:49 -0400
Message-ID: <CALaySJ+xV_Hh0YA2tgk8zxPTczbxae_tBxtkFQKdgcrG7MY6XQ@mail.gmail.com>
To: draft-ietf-cdni-request-routing-extensions.all@ietf.org
Cc: "<cdni@ietf.org>" <cdni@ietf.org>, Dan Romascanu <dromasca@gmail.com>, General Area Review Team <gen-art@ietf.org>, ops-dir@ietf.org, Zitao Wang <wangzitao@huawei.com>, Linda Dunbar <Linda.dunbar@huawei.com>, IETF SecDir <secdir@ietf.org>, Ben Niven-Jenkins <ben@niven-jenkins.co.uk>, Michael Tüxen <tuexen@fh-muenster.de>, tsv-art@ietf.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/vqT8uXBFf8pAl6D_ugyQ4V4BS7M>
Subject: Re: [Gen-art] [CDNi] I-D Action: draft-ietf-cdni-request-routing-extensions-07.txt
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, 24 Sep 2019 15:16:14 -0000

Thanks for the updates, Ori.  As we discussed, I will now re-run a
2-week last call purely to call out the new downref to RFC 7336, as we
moved 7336 to normative.  The document should be on the IESG telechat
on 17 Oct.

Barry

On Tue, Sep 24, 2019 at 10:00 AM Ori Finkelman (IETF)
<ori.finkelman.ietf@gmail.com> wrote:
>
> Hi All,
> This submission fixes the comments from all reviewers, I would like to thank all reviewers for taking the time and sharing their comments.
> Please note the diff should be against revision 05 rather than 06 as most of the changes were submitted in 06.
>
>
> Here is the full list of comments that were fixed in this version:
> =====================================================================
>
> ****************************************************************
> Reviewer: Barry Leiba (AD)
>
>
> 1. Please use the new BCP 14 boilerplate and references: see RFC 8174.
> >> fixed
>
> 2. Abstract vs Introduction:  The sentence about the SVA seems out of
> place in the Abstract, and is oddly missing from the Introduction.  I
> would add the first two sentences of the Abstract to the Introduction.
> Then remove the first sentence from the Abstract and also remove “In
> that aspect,” from the second sentence.
>
> >> fixed
>
> 3. RFC 6707 defines necessary terminology, so it probably should be
> normative.  I will note a downref in the last-call notice in
> anticipation of that.
> >> fixed
>
>
> ***************************************************
> Reviewer: Dan Romascanu (Genart)
>
> 1. Several non-obvious acronyms are not expanded: FCI, FQDN
> >> fixed and removed the ones not used
> 2. Section 3 - typo in the first paragraph '...the uCDN MUST be differnet ...'
> >> fixed
>
> *************************************************
> Reviewer: Zitao Wang (Opsdir)
>
> #1: There are a lot of abbreviations that are not provided with explanations or
> citations, such as uCDN, dCDN, CFI, etc.
> >> fixed and remove the ones not necessary
>
> #2: The example of of a Redirect Target capability object serialization, is it
> encoded as json? Please present its encoding format.
> >> fixed
>
> #3: In section 2.1, the "Mandatory-to-Specify" attributes of dns-target and
> http-target, it describes that "No, but at least one of dns-target or
> http-target MUST be present and non-empty." I wonder whether there should be a
> detection mechanism. For example, if the requirements are not met, an error
> message will be returned. And if there are existing mechanisms, please briefly
> introduce them.
>
> >> That one is a great catch, thanks. I have changed it so it is not an error anymore. Instead we have defined a default behavior for the case
> it is not present or empty, see the fixed draft.
>
> ******************************************************************
> Reviewer: Linda Dunbar (Secdir)
>
> The terminology RR (Request Router) and CP (Content Provider) specified by the
> Terminology are not used for the entire document. I assume that RR would be the
> one request content, isn't? is RR same as Client?  Is RR part of Downstream CDN
> Provider? is the CP same as Downstream CDN provider or Upstream CDN Provider?
>
> >> In the new version RR appears in a few locations. I have added more explanations and references to the relevant CDNI docs where it was defined.
>
> who issued the Redirect Target?
>
> It would be good for the document to clearly specify the relationship of all
> the entities, such as who makes request and who respond, and who use the
> Redirect Target capability, etc.
>
> >> we have added drawings of sequences that explain it all, I hope it will be clearer now.
>
> *******************************************************************
> Reviewer: Michael Tüxen (Tsvart)
>
> To improve readability, you might want to
> * resolve acronyms on first occurence like CDN, CDNI,...
> >> fixed
> * Remove section 1.1, since the introduced abbreviations are not used in the text.
> >> fixed
> * add a graphical representation of the involved nodes and the messages being exchanged between them
> >> Added sequence diagrams sections for both extensions.
>
> Typos:
> * Section 3: the uCDN provide a fallback -> the uCDN provides a fallback
> * Section 6: Nir B.  Sopher -> Nir B. Sopher (no double space after period)
> * Section 6: Kevin J.  Ma -> Kevin J. Ma (no double space after period)
> >> fixed
>
> *******************************************************************
> Reviewer: Ben Niven-Jenkins (CDNI)
>
> Is there a reason that IPv6 addresses (AAAA records) are excluded from being allowed as DnsTargets, or is this an oversight?
>
> >> fixed. references to ipv6 and AAAA record were added in the relevant places.
>
> *******************************************************************
>
> Thanks,
> Ori
>
>
> ---------- Forwarded message ---------
> From: <internet-drafts@ietf.org>
> Date: Tue, Sep 24, 2019 at 4:49 PM
> Subject: [CDNi] I-D Action: draft-ietf-cdni-request-routing-extensions-07.txt
> To: <i-d-announce@ietf.org>
> Cc: <cdni@ietf.org>
>
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Content Delivery Networks Interconnection WG of the IETF.
>
>         Title           : CDNI Request Routing Extensions
>         Authors         : Ori Finkelman
>                           Sanjay Mishra
>         Filename        : draft-ietf-cdni-request-routing-extensions-07.txt
>         Pages           : 17
>         Date            : 2019-09-24
>
> Abstract:
>    Open Caching is a use case of Content Delivery Networks
>    Interconnetion (CDNI) in which the commercial Content Delivery
>    Network (CDN) is the upstream CDN (uCDN) and the ISP caching layer
>    serves as the downstream CDN (dCDN).  The extensions specified in
>    this document to the CDNI Metadata and FCI interfaces are derived
>    from requirements raised by Open Caching but are also applicable to
>    CDNI use cases in general.
>
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-cdni-request-routing-extensions/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-cdni-request-routing-extensions-07
> https://datatracker.ietf.org/doc/html/draft-ietf-cdni-request-routing-extensions-07
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-cdni-request-routing-extensions-07
>
>
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> CDNi mailing list
> CDNi@ietf.org
> https://www.ietf.org/mailman/listinfo/cdni