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

From: "Ori Finkelman (IETF)" <[email-masked]>
Date: Tue, 24 Sep 2019 16:59:41 +0300

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: <[email-masked]>
Date: Tue, Sep 24, 2019 at 4:49 PM
Subject: [CDNi] I-D Action:
draft-ietf-cdni-request-routing-extensions-07.txt
To: <[email-masked]>
Cc: <[email-masked]>

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
[email-masked]
https://www.ietf.org/mailman/listinfo/cdni

---

From: Barry Leiba <[email-masked]>
Date: Tue, 24 Sep 2019 11:15:49 -0400

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)
<[email-masked]> 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.
>
>
> 2. Section 3 - typo in the first paragraph '...the uCDN MUST be differnet ...'
> >> fixed
>
> #1: There are a lot of abbreviations that are not provided with explanations or
> #2: The example of of a Redirect Target capability object serialization, is it
> http-target MUST be present and non-empty." I wonder whether there should be a
> 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
> 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.
>
> >> we have added drawings of sequences that explain it all, I hope it will be clearer now.
>
> * 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
> 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.
>
> Subject: [CDNi] I-D Action: draft-ietf-cdni-request-routing-extensions-07.txt
> 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.
>