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-dra...@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-annou...@ietf.org>
Cc: <c...@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
c...@ietf.org
https://www.ietf.org/mailman/listinfo/cdni
_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
