Subject: [CDNi] I-D Action: draft-ietf-cdni-request-routing-extensions-08.txt

From: [email-masked]
Date: Wed, 20 Nov 2019 13:29:32 -0800

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-08.txt
	Pages           : 19
	Date            : 2019-11-20

Abstract:
   Open Caching architecture is a use case of Content Delivery Networks
   Interconnection (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 Interface (MI) and the Footprint
   and Capabilities Interface (FCI) 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-08
https://datatracker.ietf.org/doc/html/draft-ietf-cdni-request-routing-extensions-08

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-cdni-request-routing-extensions-08

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/

---

From: Ori Finkelman <[email-masked]>
Date: Thu, 21 Nov 2019 00:21:08 +0200

Dear all,
Draf 08 was just submitted.
Thanks goes to all the reviewers and commenters.

As a general note, we have removed the option to advertise an IPv4 / IPv6
address in both redirect target and fallback target and left only the CNAME
option. The reason is that in the CDNI docs there is only reference to
CNAME option for DNS routing, not AAAA/A records, and this is also aligned
with Open Caching specification.

Fixes list by commenter:

*Alissa Cooper*
+ EDNS0 client-subnet - a note was added to new section 2.1 regarding the
privacy drawbacks and reference to guidance in RFC 7871.

*Roman Danyliw*
+ EDNS0 client-subnet - see comment above.
+ Add references to SVA and Open Caching - added to the introduction
+ Typos - all fixed.

*Alvaro Retana*
+ Add references to SVA and Open Caching - added to the introduction

*Éric Vyncke*+ Router definition - Request Router definition added to
section 1.1
+ Switching / preserving of URI scheme - we have added a "scheme" property
to the redirect target object, to determine if the scheme is preset or to
be the same as the original request (if the property is absent)
+ Expand FCI in Abstract - done
+ Requirement Langague - moved to the introduction
+ Typos - all fixed

*Benjamin Kaduk*
+ Geo DNS reference
     - there is no RFC or other official standard, instead we have added a
short explanation of that we mean by "Geo DNS"
+ The dCDN's advertisements interaction with the uCDN's DNS redirection
decision
     - we have elaborated more about how uCDN is expected to use the dCDN
advertisement
+ Change reference from section 5 of RFC8008 to sections 5.1 and 5.2 of the
same
   - accepted and done
+ IP address examples - see first comment in this email, we have removed
the options to route to IP addresses and left only CNAME
+ Redirection to TLS
   - we have added "scheme" property to the Http redirect target. Regarding
SNI, an implemenation should avoid using an IP address for hostname if it
is using HTTPS, that makes certificates more complex and creates SNI
problems, but that is a general issue, not specific to CDNI.
+ swapping of redirecting and target host in the figures  - correct, I have
fixed it. Thanks for catching it.
+ nits - all fixed
+ Attacks on the fallback - we have added an explanation on how the
fallback should be designed to have the same level of load balancing and
redundancy as the original uCDN nodes, so that the fallback would be not
expose a new attack surface (beyond the original uCDN architecture)
+ Scheme in fallback address - the same as in the redirect target, we have
added a "scheme" property. The default is to use the same scheme as the
received request. One can set a specific scheme if needed using this
property.

Best regards,
Ori

---------- Forwarded message ---------
From: <[email-masked]>
Date: Wed, Nov 20, 2019 at 11:29 PM
Subject: [CDNi] I-D Action:
draft-ietf-cdni-request-routing-extensions-08.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.

Abstract:

_______________________________________________
CDNi mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/cdni