Skip to main content

Content Delivery Network Interconnection (CDNI) Request Routing Extensions
draft-ietf-cdni-request-routing-extensions-08

Revision differences

Document history

Date Rev. By Action
2020-09-17
08 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2020-07-26
08 (System) RFC Editor state changed to AUTH48 from RFC-EDITOR
2020-03-23
08 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2020-02-20
08 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2020-02-20
08 (System) IANA Action state changed to Waiting on RFC Editor from In Progress
2020-02-20
08 (System) IANA Action state changed to In Progress from Waiting on Authors
2020-02-18
08 (System) IANA Action state changed to Waiting on Authors from In Progress
2020-02-14
08 (System) IANA Action state changed to In Progress
2020-02-14
08 (System) RFC Editor state changed to EDIT
2020-02-14
08 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2020-02-14
08 (System) Announcement was received by RFC Editor
2020-02-14
08 Amy Vezza Downref to RFC 7336 approved by Last Call for draft-ietf-cdni-request-routing-extensions-08
2020-02-14
08 Amy Vezza IESG state changed to Approved-announcement sent from Approved-announcement to be sent
2020-02-14
08 Amy Vezza IESG has approved the document
2020-02-14
08 Amy Vezza Closed "Approve" ballot
2020-02-14
08 Amy Vezza Ballot approval text was generated
2020-02-14
08 Barry Leiba IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup
2019-11-21
08 Roman Danyliw [Ballot comment]
Thank you for addressing my DISCUSSes and COMMENTs.
2019-11-21
08 Roman Danyliw [Ballot Position Update] Position for Roman Danyliw has been changed to No Objection from Discuss
2019-11-20
08 (System) Sub state has been changed to AD Followup from Revised ID Needed
2019-11-20
08 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2019-11-20
08 Ori Finkelman New version available: draft-ietf-cdni-request-routing-extensions-08.txt
2019-11-20
08 (System) New version approved
2019-11-20
08 (System) Request for posting confirmation emailed to previous authors: Sanjay Mishra , Ori Finkelman
2019-11-20
08 Ori Finkelman Uploaded new revision
2019-10-17
07 Cindy Morgan IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation
2019-10-17
07 Suresh Krishnan [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan
2019-10-17
07 Martin Vigoureux [Ballot Position Update] New position, No Objection, has been recorded for Martin Vigoureux
2019-10-17
07 Zitao Wang Request for Last Call review by OPSDIR Completed: Ready. Reviewer: Zitao Wang. Sent review to list.
2019-10-16
07 Alvaro Retana
[Ballot comment]
The Abstract and Introduction talk about Open Caching (and specifically about the Open Caching working group of the Streaming Video Alliance (SVA)) as …
[Ballot comment]
The Abstract and Introduction talk about Open Caching (and specifically about the Open Caching working group of the Streaming Video Alliance (SVA)) as a driving use case for this work...but there are no references to that work, including a description of what Open Caching is.

Open Caching may be well known in the cdni WG and to the interested community, but not to the casual reader...like me.  The document would benefit from referencing the background material.
2019-10-16
07 Alvaro Retana [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana
2019-10-16
07 Benjamin Kaduk
[Ballot comment]
Section 2

  o  Footprint: The dCDN may want to have a different target per
      footprint.  Note that a dCDN …
[Ballot comment]
Section 2

  o  Footprint: The dCDN may want to have a different target per
      footprint.  Note that a dCDN may spread across multiple
      geographies.  This makes it easier to route client requests to a
      nearby request router.  Though this can be achieved using a single
      canonical name and Geo DNS, that approach has limitations; for

We probably want a reference for "Geo DNS".

  A redirect target for DNS redirection is an IPv4 address used as an A
  record response, an IPv6 address used as an AAAA record response or a
  FQDN used as an alias in a CNAME record response (see [RFC1034]) of
  the uCDN DNS router.  Note that DNS routers make routing decisions
  based on either the DNS resolver's IP address or the client IP
  address when EDNS0 client-subnet is used (see [RFC7871]).  The dCDN
  may choose to advertise redirect targets and footprints to cover both
  cases.  [...]

We may want to say a bit more about how the dCDN's advertisements
interact with the uCDN's DNS redirection decision here -- is the idea
just that the set of redirect targets should try to be "close to" both
the end-user and recursive resolver IP addresses that will be making
requests of the uCDN?

  The following is an example of a Redirect Target capability object
  serialization that advertises a dCDN target address that is attached
  to a specific list of uCDN "redirecting-hosts".  A uCDN host that is
  included in that list can redirect to the advertised dCDN redirect
  target.  The capabilities object is serialized as a JSON object as
  defined in Section 5 of [RFC8008]

To check my understanding: the Redirect Target capability object is a
new object, in some sense a peer of the (e.g.) Delivery Protocol
capability object, but encoded in a similar fashion as the objects
specified in sections 5.3 through 5.7 of RFC 8008.  In that case, I
wonder if Section 5.2 or 5.1 is a better reference than the top-level
Section 5 of RFC 8008.

Section 2.2

Do we want an example with an IP address as well, to illustrate the full
spectrum of possible behaviors?

Section 2.3

My apologies for not doing much background reading, but what are the
expected scenarios with respect to TLS usage?  Is the redirect expected
to preserve the URI scheme (http:// vs. https://) or could we go from
one to the other as part of the redirect?  (I do see that the example
has an http:// redirection target.)
I ask because there are probably some considerations here relating to
the TLS server name indication, particularly for the case of redirection
to an IP address.

Section 2.4

It's quite possible I've confused myself, but in Figure 1 are the
"redirecting-hosts" and "target host" swapped?  The former is supposed
to be an uCDN host, is it not?

Section 3

  o  Error: A cache may receive a request that it cannot properly
      serve, for example, some of the metadata objects for that service
      were not properly acquired.  In this case, the cache may resolve
      to redirect back to uCDN.

nit: I think this last sentence would benefit from another word or two
or some punctuation to clarify what/how the cache is resolving, e.g.,
quotes around "redirect back to uCDN" or "cache's action" or similar.

  The Fallback target metadata object is used to indicate the target
  address the dCDN should use in order to redirect a client back to the
  uCDN.  Fallback target is represented as endpoint objects as defined
  in section 4.3.3 of [RFC8006].

nit: singular/plural mismatch "target"/"objects"

  The uCDN fallback target address may be used as a DNS A record, AAAA
  record or CNAME record in case of DNS redirection or a hostname for
  HTTP redirect.

nit: I don't think "used as" is quite right (that is, the sense would
apply in the other direction: a DNS A record might be used as a fallback
target address) and could probably be removed.

Section 3.2

[same comment about Figure 3 as for Figure 1 above]

Section 5

The presence of a fallback uCDN host could make for a more tempting
attack target -- if the fallback target is known, then an attacker could
concentrate resources on that fallback host (more effectively DoS'd than
the whole CDN) and thrash the cash on the dCDN to effect a DoS.  This
speaks to the need to keep the exchanged metadata confidential, as
already noted, but is also a latent risk of the topology independently
of keeping the metadata confidential.
The attacks made possible by having the Redirect Target are mostly a
subset of the generic risks listed in RFC 8006; by allowing per-host
granularity of the uCDN behavior, there is perhaps a new opportunity to
have degraded (but present) service, by directing requests to dCDN hosts
that are "far away".  This seems somewhat challenging for an active
attacker to pull off, but may still be the result of misconfiguration.

As I mentioned above, we probably need to say something about TLS usage
for HTTP-level redirection, though I'm not sure yet what exactly that
is, since I don't understand the expected usage yet.
2019-10-16
07 Benjamin Kaduk [Ballot Position Update] New position, No Objection, has been recorded for Benjamin Kaduk
2019-10-16
07 Amanda Baber IANA Experts State changed to Expert Reviews OK from Reviews assigned
2019-10-16
07 Amanda Baber IANA Review state changed to IANA OK - Actions Needed from IANA - Not OK
2019-10-16
07 Alexey Melnikov [Ballot Position Update] New position, No Objection, has been recorded for Alexey Melnikov
2019-10-16
07 Ignas Bagdonas [Ballot Position Update] New position, No Objection, has been recorded for Ignas Bagdonas
2019-10-16
07 Magnus Westerlund [Ballot Position Update] New position, No Objection, has been recorded for Magnus Westerlund
2019-10-15
07 Adam Roach [Ballot comment]
I support Roman's DISCUSS.
2019-10-15
07 Adam Roach [Ballot Position Update] New position, No Objection, has been recorded for Adam Roach
2019-10-15
07 Deborah Brungard [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard
2019-10-15
07 Warren Kumari [Ballot comment]
Thank you for writing this, also thank you for addressing the OpsDir Review comments. Also thank you to wangzitao@huawei.com for the review.
2019-10-15
07 Warren Kumari [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari
2019-10-15
07 Roman Danyliw
[Ballot discuss]
Section 2 notes the use of EDNS0.  Please provide guidance in Section 5.1 (Privacy Considerations) given the caution described in Sections 2 and …
[Ballot discuss]
Section 2 notes the use of EDNS0.  Please provide guidance in Section 5.1 (Privacy Considerations) given the caution described in Sections 2 and 11.1 of RFC7871. This is likely the same feedback provided by Alissa Cooper in her ballot.
2019-10-15
07 Roman Danyliw
[Ballot comment]
** Section 1.  Add an informative reference to the Open Caching WG of SVA

** Editorial Nits
Abstract.  Typo.  s/Interconnetion/Interconnection/

Section 1. Typo. …
[Ballot comment]
** Section 1.  Add an informative reference to the Open Caching WG of SVA

** Editorial Nits
Abstract.  Typo.  s/Interconnetion/Interconnection/

Section 1. Typo. s/commerical/commercial/

Section 1.1.  Typo.  s/Additionaly/Additionally/

Section 2.  Typo.  s/defintion/definition/

Section 2.  Typo.  s/implemenation/implementation/

Section 2. Typo. s/interperet/interpret/

Section 4.  Typo. s/adveritses/advertises/

Section 5.1.  Typo.  s/strcture/structure/

Section 5.1.  Typo.  s/implemenation/implementation/
2019-10-15
07 Roman Danyliw [Ballot Position Update] New position, Discuss, has been recorded for Roman Danyliw
2019-10-14
07 Alissa Cooper
[Ballot comment]
I think it would be good to note in Section 5.1 that the way the redirect target capability is specified here potentially encourages …
[Ballot comment]
I think it would be good to note in Section 5.1 that the way the redirect target capability is specified here potentially encourages further use of the EDNS client subnet option to identify the geographic area of a client, which has a number of known privacy drawbacks per RFC 7871 Section 2 and Section 11.1.
2019-10-14
07 Alissa Cooper [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper
2019-10-14
07 Éric Vyncke
[Ballot comment]
Thank you for the work put into this document. I have a couple of comments and nits.

Regards,

-éric

== COMMENTS ==

One …
[Ballot comment]
Thank you for the work put into this document. I have a couple of comments and nits.

Regards,

-éric

== COMMENTS ==

One generic suggestion (no need to act on a COMMENT): add the definition of "router" in this document as it is not the typical IP-layer router as in most IETF documents.

-- Section 2.3 --
It is unclear to me whether the 3xx redirection (cfr last example) can switch from HTTP to HTTPS or vice-versa? Should the 'httptarget' include the scheme/protocol to be used ? In any case, the text should be clear whether the scheme is kept between original request and the scheme in the redirected location. Or is it specify in the OpenCache spec ?


== NITS ==

-- Abstract --
Please expand FCI at first use.

-- Requirements language --
Unusual place in the document. It will be fixed by the RFC Editor probably later in the process.

-- Section 2 --
s/defintion/definition/, I will stop looking for typos, easier to use a spell checker ;)
2019-10-14
07 Éric Vyncke [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke
2019-10-11
07 Mirja Kühlewind [Ballot Position Update] New position, No Objection, has been recorded for Mirja Kühlewind
2019-10-09
07 Amy Vezza Placed on agenda for telechat - 2019-10-17
2019-10-09
07 Barry Leiba IESG state changed to IESG Evaluation from Waiting for Writeup
2019-10-09
07 Barry Leiba Ballot has been issued
2019-10-09
07 Barry Leiba [Ballot Position Update] New position, Yes, has been recorded for Barry Leiba
2019-10-09
07 Barry Leiba Created "Approve" ballot
2019-10-09
07 Barry Leiba Ballot writeup was changed
2019-10-08
07 Sabrina Tanamal IANA Experts State changed to Reviews assigned from Expert Reviews OK
2019-10-08
07 (System) IANA Review state changed to IANA - Not OK from Version Changed - Review Needed
2019-10-08
07 Sabrina Tanamal
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-cdni-request-routing-extensions-07. If any part of this review is inaccurate, please let …
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-cdni-request-routing-extensions-07. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that, upon approval of this document, there is a single action which we must complete.

In the CDNI Payload Types registry on the Content Delivery Network Interconnection (CDNI) Parameters registry page located at:

https://www.iana.org/assignments/cdni-parameters/

two, new registrations are to be made as follows:

Payload Type: FCI.RedirectTarget
Reference: [ RFC-to-be ]

Payload Type: MI.FallbackTarget
Reference: [ RFC-to-be ]

As this document requests registrations in a Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC.

The IANA Functions Operator understands that this is the only action required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist
2019-10-08
07 (System) IESG state changed to Waiting for Writeup from In Last Call
2019-10-01
07 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Zitao Wang
2019-10-01
07 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Zitao Wang
2019-09-24
07 Amy Vezza
The following Last Call announcement was sent out (ends 2019-10-08):

From: The IESG
To: IETF-Announce
CC: cdni@ietf.org, cdni-chairs@ietf.org, Kevin Ma , barryleiba@gmail.com, …
The following Last Call announcement was sent out (ends 2019-10-08):

From: The IESG
To: IETF-Announce
CC: cdni@ietf.org, cdni-chairs@ietf.org, Kevin Ma , barryleiba@gmail.com, kevin.j.ma.ietf@gmail.com, draft-ietf-cdni-request-routing-extensions@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (CDNI Request Routing Extensions) to Proposed Standard


The IESG has received a request from the Content Delivery Networks
Interconnection WG (cdni) to do a second last call on the following document:
- 'CDNI Request Routing Extensions'
  as Proposed Standard

This second last call is specifically to consider having moved RFC 7336 to be
a normative reference, as it defines terminology required to understand this
document, and as RFC 7336 is a downref to an Informational document.
Please concentrate comments at this stage on that issue.

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2019-10-08. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

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 file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-cdni-request-routing-extensions/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-cdni-request-routing-extensions/ballot/


No IPR declarations have been submitted directly on this I-D.


The document contains these normative downward references.
See RFC 3967 for additional information:
    rfc7336: Framework for Content Distribution Network Interconnection (CDNI) (Informational - IETF stream)

2019-09-24
07 Amy Vezza IESG state changed to In Last Call from Last Call Requested
2019-09-24
07 Barry Leiba Last call was requested
2019-09-24
07 Barry Leiba IESG state changed to Last Call Requested from Waiting for AD Go-Ahead::AD Followup
2019-09-24
07 Barry Leiba Last call announcement was changed
2019-09-24
07 Barry Leiba Last call announcement was generated
2019-09-24
07 Ori Finkelman New version available: draft-ietf-cdni-request-routing-extensions-07.txt
2019-09-24
07 (System) New version approved
2019-09-24
07 (System) Request for posting confirmation emailed to previous authors: Sanjay Mishra , Ori Finkelman
2019-09-24
07 Ori Finkelman Uploaded new revision
2019-09-24
06 (System) Sub state has been changed to AD Followup from Revised ID Needed
2019-09-24
06 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2019-09-24
06 Ori Finkelman New version available: draft-ietf-cdni-request-routing-extensions-06.txt
2019-09-24
06 (System) New version approved
2019-09-24
06 (System) Request for posting confirmation emailed to previous authors: Sanjay Mishra , Ori Finkelman
2019-09-24
06 Ori Finkelman Uploaded new revision
2019-09-09
05 Michael Tüxen Request for Last Call review by TSVART Completed: Ready with Nits. Reviewer: Michael Tüxen. Sent review to list.
2019-09-09
05 Sabrina Tanamal IANA Experts State changed to Expert Reviews OK
2019-09-09
05 Sabrina Tanamal IANA Review state changed to IANA OK - Actions Needed from IANA - Not OK
2019-08-28
05 (System) IANA Review state changed to IANA - Not OK from IANA - Review Needed
2019-08-28
05 Sabrina Tanamal
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-cdni-request-routing-extensions-05. If any part of this review is inaccurate, please let …
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-cdni-request-routing-extensions-05. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that, upon approval of this document, there is a single action which we must complete.

In the CDNI Payload Types registry on the Content Delivery Network Interconnection (CDNI) Parameters registry page located at:

https://www.iana.org/assignments/cdni-parameters/

two, new registrations will be made as follows:

Payload Type: FCI.RedirectTarget
Reference: [ RFC-to-be ]

Payload Type: MI.FallbackTarget
Reference: [ RFC-to-be ]

As this document requests registrations in a Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC.

The IANA Functions Operator understands that this is the only action required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist
2019-08-28
05 Barry Leiba IESG state changed to Waiting for AD Go-Ahead::Revised I-D Needed from Waiting for Writeup
2019-08-28
05 (System) IESG state changed to Waiting for Writeup from In Last Call
2019-08-26
05 Linda Dunbar Request for Last Call review by SECDIR Completed: Has Nits. Reviewer: Linda Dunbar. Sent review to list.
2019-08-20
05 Dan Romascanu Request for Last Call review by GENART Completed: Ready with Nits. Reviewer: Dan Romascanu. Sent review to list.
2019-08-20
05 Zitao Wang Request for Last Call review by OPSDIR Completed: Has Issues. Reviewer: Zitao Wang. Sent review to list.
2019-08-19
05 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Zitao Wang
2019-08-19
05 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Zitao Wang
2019-08-19
05 Wesley Eddy Request for Last Call review by TSVART is assigned to Michael Tüxen
2019-08-19
05 Wesley Eddy Request for Last Call review by TSVART is assigned to Michael Tüxen
2019-08-15
05 Jean Mahoney Request for Last Call review by GENART is assigned to Dan Romascanu
2019-08-15
05 Jean Mahoney Request for Last Call review by GENART is assigned to Dan Romascanu
2019-08-15
05 Tero Kivinen Request for Last Call review by SECDIR is assigned to Linda Dunbar
2019-08-15
05 Tero Kivinen Request for Last Call review by SECDIR is assigned to Linda Dunbar
2019-08-14
05 Cindy Morgan IANA Review state changed to IANA - Review Needed
2019-08-14
05 Cindy Morgan
The following Last Call announcement was sent out (ends 2019-08-28):

From: The IESG
To: IETF-Announce
CC: cdni@ietf.org, cdni-chairs@ietf.org, Kevin Ma , barryleiba@gmail.com, …
The following Last Call announcement was sent out (ends 2019-08-28):

From: The IESG
To: IETF-Announce
CC: cdni@ietf.org, cdni-chairs@ietf.org, Kevin Ma , barryleiba@gmail.com, kevin.j.ma.ietf@gmail.com, draft-ietf-cdni-request-routing-extensions@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (CDNI Request Routing Extensions) to Proposed Standard


The IESG has received a request from the Content Delivery Networks
Interconnection WG (cdni) to consider the following document: - 'CDNI Request
Routing Extensions'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2019-08-28. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract

  The Open Caching working group of the Streaming Video Alliance is
  focused on the delegation of video delivery requests from commercial
  CDNs to a caching layer at the ISP.  In that aspect, Open Caching is
  a specific use case of CDNI, where the commercial CDN is the upstream
  CDN (uCDN) and the ISP caching layer is 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 applicable to CDNI use cases in general.


There is currently an informative reference to RFC 6707, "CDNI Problem Statement".
The reference is there to define necessary terminology, and will probably be moved to
be a normative reference in the next revision.  Please treat that Informational document
as a downref when reviewing this document.


The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-cdni-request-routing-extensions/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-cdni-request-routing-extensions/ballot/


No IPR declarations have been submitted directly on this I-D.




2019-08-14
05 Cindy Morgan IESG state changed to In Last Call from Last Call Requested
2019-08-14
05 Barry Leiba Last call was requested
2019-08-14
05 Barry Leiba Ballot approval text was generated
2019-08-14
05 Barry Leiba Ballot writeup was generated
2019-08-14
05 Barry Leiba IESG state changed to Last Call Requested from AD Evaluation
2019-08-14
05 Barry Leiba Last call announcement was changed
2019-08-14
05 Barry Leiba IESG state changed to AD Evaluation from Publication Requested
2019-08-14
05 Kevin Ma
Document Shepherd: Kevin J. Ma

Responsible AD: Barry Leiba

This document defines one new CDNI Metadata object (MI.FallbackTarget) and one new CDNI Capability object (FCI.RedirectTarget).  …
Document Shepherd: Kevin J. Ma

Responsible AD: Barry Leiba

This document defines one new CDNI Metadata object (MI.FallbackTarget) and one new CDNI Capability object (FCI.RedirectTarget).  The CDNI Metadata Interface (RFC8006) and CDNI Footprint and Capabilities Semantics (RFC8008) define generic base objects and registries to allow extensibility in defining new metadata and capabilities as the need arises.  We did this knowing that we would not think of everything when we wrote RFC8006 and RFC8008.  The Open Caching Working Group (OCWG) at the Streaming Video Alliance (SVA) has adopted the CDNI interfaces as the basis for their work, and in developing their solution discovered one additional metadata object and one additional capability object that they deemed necessary that the CDNI WG did not think of originally.  We asked them to bring the new objects back to the CDNI WG for standardization and they did.  This draft is the result of that request.  The CDNI WG has reviewed the new objects and agreed that they are reasonable and useful additions to the CDNI interfaces.  We are requesting publication as "Proposed Standard" as the object extend the exiting RFC8006 and RFC8008 proposed standards.

The contents of the document have been extensively reviewed within the SVA OCWG.  I was an active member of the SVA OCWG (until a job change) and participated in those discussions.  Within the CDNI WG, an SVA OCWG representative presented a number of topics which received varying levels of discussion.  The two new objects defined in this document were the least controversial items presented.  As such, there was not extensive discussion, but they also didn't need much discussion to garner quick and broad consensus.  As one of the primary authors of both RFC8006 and RFC8008, I am acting as both the expert reviewer and shepherd.  The two objects defined are relatively straight forward and inline with the purposes and goals of RFC8006 and RFC8008.

I am no longer active in the SVA OCWG, but I know they did a proof of concept and had plans to implement these features.

Both authors have confirmed that there is no known IPR related to contents of this document.

There are no downward references in the document, and I agree with the normative vs informative reference designations.

This document registers two new CDNI Payload Types in our IANA registry.  I am the creator of and one of the two expert reviewers for that registry.  The authors addressed all my comments wrt the IANA registrations.
2019-08-14
05 Kevin Ma Responsible AD changed to Barry Leiba
2019-08-14
05 Kevin Ma IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up
2019-08-14
05 Kevin Ma IESG state changed to Publication Requested from I-D Exists
2019-08-14
05 Kevin Ma IESG process started in state Publication Requested
2019-08-11
05 Kevin Ma
Document Shepherd: Kevin J. Ma

Responsible AD: Barry Leiba

This document defines one new CDNI Metadata object (MI.FallbackTarget) and one new CDNI Capability object (FCI.RedirectTarget).  …
Document Shepherd: Kevin J. Ma

Responsible AD: Barry Leiba

This document defines one new CDNI Metadata object (MI.FallbackTarget) and one new CDNI Capability object (FCI.RedirectTarget).  The CDNI Metadata Interface (RFC8006) and CDNI Footprint and Capabilities Semantics (RFC8008) define generic base objects and registries to allow extensibility in defining new metadata and capabilities as the need arises.  We did this knowing that we would not think of everything when we wrote RFC8006 and RFC8008.  The Open Caching Working Group (OCWG) at the Streaming Video Alliance (SVA) has adopted the CDNI interfaces as the basis for their work, and in developing their solution discovered one additional metadata object and one additional capability object that they deemed necessary that the CDNI WG did not think of originally.  We asked them to bring the new objects back to the CDNI WG for standardization and they did.  This draft is the result of that request.  The CDNI WG has reviewed the new objects and agreed that they are reasonable and useful additions to the CDNI interfaces.  We are requesting publication as "Proposed Standard" as the object extend the exiting RFC8006 and RFC8008 proposed standards.

The contents of the document have been extensively reviewed within the SVA OCWG.  I was an active member of the SVA OCWG (until a job change) and participated in those discussions.  Within the CDNI WG, an SVA OCWG representative presented a number of topics which received varying levels of discussion.  The two new objects defined in this document were the least controversial items presented.  As such, there was not extensive discussion, but they also didn't need much discussion to garner quick and broad consensus.  As one of the primary authors of both RFC8006 and RFC8008, I am acting as both the expert reviewer and shepherd.  The two objects defined are relatively straight forward and inline with the purposes and goals of RFC8006 and RFC8008.

I am no longer active in the SVA OCWG, but I know they did a proof of concept and had plans to implement these features.

Both authors have confirmed that there is no known IPR related to contents of this document.

There are no downward references in the document, and I agree with the normative vs informative reference designations.

This document registers two new CDNI Payload Types in our IANA registry.  I am the creator of and one of the two expert reviewers for that registry.  The authors addressed all my comments wrt the IANA registrations.
2019-08-11
05 Kevin Ma Intended Status changed to Proposed Standard from None
2019-08-11
05 Kevin Ma Changed consensus to Yes from Unknown
2019-08-11
05 Kevin Ma IETF WG state changed to WG Consensus: Waiting for Write-Up from WG Document
2019-08-09
05 Ori Finkelman New version available: draft-ietf-cdni-request-routing-extensions-05.txt
2019-08-09
05 (System) New version approved
2019-08-09
05 (System) Request for posting confirmation emailed to previous authors: Sanjay Mishra , Ori Finkelman
2019-08-09
05 Ori Finkelman Uploaded new revision
2019-07-29
04 Ori Finkelman New version available: draft-ietf-cdni-request-routing-extensions-04.txt
2019-07-29
04 (System) New version approved
2019-07-29
04 (System) Request for posting confirmation emailed to previous authors: Sanjay Mishra , Ori Finkelman
2019-07-29
04 Ori Finkelman Uploaded new revision
2019-05-21
03 Ori Finkelman New version available: draft-ietf-cdni-request-routing-extensions-03.txt
2019-05-21
03 (System) New version approved
2019-05-21
03 (System) Request for posting confirmation emailed to previous authors: Sanjay Mishra , Ori Finkelman
2019-05-21
03 Ori Finkelman Uploaded new revision
2019-05-04
02 Kevin Ma Notification list changed to Kevin Ma <kevin.j.ma.ietf@gmail.com>
2019-05-04
02 Kevin Ma Document shepherd changed to Kevin J. Ma
2019-03-31
02 Ori Finkelman New version available: draft-ietf-cdni-request-routing-extensions-02.txt
2019-03-31
02 (System) New version approved
2019-03-31
02 (System) Request for posting confirmation emailed to previous authors: Sanjay Mishra , cdni-chairs@ietf.org, Ori Finkelman
2019-03-31
02 Ori Finkelman Uploaded new revision
2019-02-03
01 Ori Finkelman New version available: draft-ietf-cdni-request-routing-extensions-01.txt
2019-02-03
01 (System) New version approved
2019-02-03
01 (System) Request for posting confirmation emailed to previous authors: Sanjay Mishra , Ori Finkelman
2019-02-03
01 Ori Finkelman Uploaded new revision
2018-10-17
00 Phil Sorber This document now replaces draft-finkelman-cdni-rr-sva-extensions instead of None
2018-10-17
00 Ori Finkelman New version available: draft-ietf-cdni-request-routing-extensions-00.txt
2018-10-17
00 (System) WG -00 approved
2018-10-17
00 Ori Finkelman Set submitter to "Ori Finkelman ", replaces to draft-finkelman-cdni-rr-sva-extensions and sent approval email to group chairs: cdni-chairs@ietf.org
2018-10-17
00 Ori Finkelman Uploaded new revision