[secdir] Fwd: [CDNi] I-D Action: draft-ietf-cdni-request-routing-extensions-07.txt

"Ori Finkelman (IETF)" <ori.finkelman.ietf@gmail.com> Tue, 24 September 2019 14:00 UTC

Return-Path: <orifinkelman@gmail.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 48E5A120810; Tue, 24 Sep 2019 07:00:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 9IESEuS9XbfH; Tue, 24 Sep 2019 06:59:59 -0700 (PDT)
Received: from mail-ua1-x92c.google.com (mail-ua1-x92c.google.com [IPv6:2607:f8b0:4864:20::92c]) (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 68D0E12080C; Tue, 24 Sep 2019 06:59:59 -0700 (PDT)
Received: by mail-ua1-x92c.google.com with SMTP id b14so584178uap.6; Tue, 24 Sep 2019 06:59:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=UTohYUTEEBCMaa+hS13GfTRALU1fBtIrEREBQKsW+Gs=; b=Rycd0mtNQL+1Ul7NCYMHIoNK/3TaOoTe86DgVN76eADgYiNqU+3gP69GrDHhGFknKW rhofVWW1q3ulz0yd2CzkcaMH7AZO9gwKHGD2KJXTw6v4R+qk0tZ2UGzHiqwA28SX+GxY C+LlN5d0BVOEeSeJIPtz9amqZf5Kn0y4hEuuAinboznXuE5KKHKa0WZarl6W0E8IaTpD WbWcFrMDxKfgCOcsl2gvZEHte2YM4JSSkM/KHrarhUlkCDyNR6S33pdAJzPzP6/ZyPjn OD4BxfdTPPNjqmSlxWcl1HhIacYiAiJ7gVhSthw9k+/IQR/oHUr0mOeT03Uxbk1/8PoC RSnA==
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=UTohYUTEEBCMaa+hS13GfTRALU1fBtIrEREBQKsW+Gs=; b=tcCdypWiXo1FmsdoY3rCIGjvOjeTjv63V6AEseNDkHTkZFwQ8Uh/npdh7/B8Stbnls EoQEabLP/UR+73UKNcNGEkwTbPs46QYgSPguvmUVjnvkSGpikOwhRxa/rKmtPEFFpstd ra8o72/W5gJDFhmi1apadCm3+7mISGZjxko8z6e2CLTREkPxV0cOG72z2MvKwkpHTFXN ZKt9udvrhthfqiVhszmtQDLs6ywScL50FahtiM/0Z8tKnYqahMd86IkSM015iYUDb7bB NQOFAknQX2jc7nPd+3/+N+uUk0pZdUkZHfGTBaR4LOLo5+PJpiU/SeHb9CY7n+z+EK/f ISsQ==
X-Gm-Message-State: APjAAAV7FmYBqObOmHV+6UjnctrsULacVTsgiGGV7pMN1NpAuphxZ63k 9H1vZsUibzVrYgZPQ61043kUE4gSN0+fQNEbW1mymzYJo48=
X-Google-Smtp-Source: APXvYqzTE0+Thgip3snH1PKDGUYqBDpOI88qs+w2pl4G5ymHWGAGeUALl3OZpur2nkd1uDKxCi6bOTMfQLSGbWR0K4Y=
X-Received: by 2002:ab0:30d4:: with SMTP id c20mr1474160uam.136.1569333597974; Tue, 24 Sep 2019 06:59:57 -0700 (PDT)
MIME-Version: 1.0
References: <156933292629.15651.2153181471854597685@ietfa.amsl.com>
In-Reply-To: <156933292629.15651.2153181471854597685@ietfa.amsl.com>
From: "Ori Finkelman (IETF)" <ori.finkelman.ietf@gmail.com>
Date: Tue, 24 Sep 2019 16:59:41 +0300
Message-ID: <CAM8emGX8zbq663EpuQDt_B0Riu3mp60NaUXOPWQemjsmsTXHRA@mail.gmail.com>
To: "<cdni@ietf.org>" <cdni@ietf.org>, draft-ietf-cdni-request-routing-extensions.all@ietf.org
Cc: Dan Romascanu <dromasca@gmail.com>, gen-art@ietf.org, ops-dir@ietf.org, Zitao Wang <wangzitao@huawei.com>, Linda Dunbar <Linda.dunbar@huawei.com>, secdir@ietf.org, Barry Leiba <barryleiba@computer.org>, drafts-lastcall@iana.org, Ben Niven-Jenkins <ben@niven-jenkins.co.uk>, =?UTF-8?Q?Michael_T=C3=BCxen?= <tuexen@fh-muenster.de>, tsv-art@ietf.org
Content-Type: multipart/alternative; boundary="000000000000a4350705934cf3b1"
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/ESgQXGvqva1WsIZQI2rW9Il_KBY>
Subject: [secdir] Fwd: [CDNi] I-D Action: draft-ietf-cdni-request-routing-extensions-07.txt
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 24 Sep 2019 14:00:04 -0000

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
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
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
Terminology are not used for the entire document. I assume that RR would be
one request content, isn't? is RR same as Client?  Is RR part of Downstream
Provider? is the CP same as Downstream CDN provider or Upstream CDN

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

* 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



---------- Forwarded message ---------
From: <internet-drafts@ietf.org>
Date: Tue, Sep 24, 2019 at 4:49 PM
Subject: [CDNi] I-D Action:
To: <i-d-announce@ietf.org>
Cc: <cdni@ietf.org>

A New Internet-Draft is available from the on-line Internet-Drafts
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

   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:

There are also htmlized versions available at:

A diff from the previous version is available at:

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:

CDNi mailing list