Skip to main content

Content Delivery Network Interconnection (CDNI) Request Routing: Footprint and Capabilities Semantics
draft-ietf-cdni-footprint-capabilities-semantics-20

Revision differences

Document history

Date Rev. By Action
2016-11-07
20 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2016-10-18
20 (System) RFC Editor state changed to AUTH48 from RFC-EDITOR
2016-09-23
20 (System) RFC Editor state changed to RFC-EDITOR from REF
2016-09-20
20 (System) RFC Editor state changed to REF from AUTH
2016-09-19
20 (System) RFC Editor state changed to AUTH from EDIT
2016-08-29
20 (System) RFC Editor state changed to EDIT from MISSREF
2016-05-31
20 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2016-05-27
20 (System) IANA Action state changed to Waiting on RFC Editor from Waiting on Authors
2016-05-27
20 (System) IANA Action state changed to Waiting on Authors
2016-05-23
20 (System) RFC Editor state changed to MISSREF
2016-05-23
20 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2016-05-23
20 (System) Announcement was received by RFC Editor
2016-05-23
20 Amy Vezza IESG state changed to Approved-announcement sent from Approved-announcement to be sent::Point Raised - writeup needed
2016-05-23
20 Amy Vezza IESG has approved the document
2016-05-23
20 Amy Vezza Closed "Approve" ballot
2016-05-23
20 Alexey Melnikov Ballot writeup was changed
2016-05-23
20 Alexey Melnikov Ballot approval text was generated
2016-05-23
20 Alexey Melnikov [Ballot comment]
Note to IESG: This is now returning to IESG as PS (instead of Informational), please make sure that you are happy with that.
2016-05-23
20 Alexey Melnikov Ballot comment text updated for Alexey Melnikov
2016-05-20
20 Kevin Ma IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2016-05-20
20 Kevin Ma New version available: draft-ietf-cdni-footprint-capabilities-semantics-20.txt
2016-05-19
19 Amy Vezza IESG state changed to Approved-announcement to be sent::Point Raised - writeup needed from IESG Evaluation
2016-05-18
19 Amanda Baber IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed
2016-05-18
19 Alia Atlas [Ballot Position Update] New position, No Objection, has been recorded for Alia Atlas
2016-05-18
19 Alexey Melnikov
[Ballot comment]
Note to IESG: This is now returning to IESG as PS (instead of Informational), please make sure that you are happy with that. …
[Ballot comment]
Note to IESG: This is now returning to IESG as PS (instead of Informational), please make sure that you are happy with that.


As Stephen pointed out: is "http1.1" correct or should this be "http/1.1"? Similarly for "https1.1".
2016-05-18
19 Alexey Melnikov Ballot comment text updated for Alexey Melnikov
2016-05-16
19 Alexey Melnikov IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead
2016-05-14
19 Kevin Ma IANA Review state changed to Version Changed - Review Needed from IANA - Not OK
2016-05-14
19 Kevin Ma New version available: draft-ietf-cdni-footprint-capabilities-semantics-19.txt
2016-05-12
18 (System) IESG state changed to Waiting for AD Go-Ahead from In Last Call
2016-05-10
18 Alexey Melnikov
[Ballot comment]
Note to IESG: This is now returning to IESG as PS (instead of Informational), please make sure that you are happy with that. …
[Ballot comment]
Note to IESG: This is now returning to IESG as PS (instead of Informational), please make sure that you are happy with that.


As Stephen pointed out: is "http1.1" correct or should this be "http/1.1". Similarly for "https1.1".
2016-05-10
18 Alexey Melnikov Ballot comment text updated for Alexey Melnikov
2016-05-10
18 Alexey Melnikov
[Ballot comment]
This is now returning to IESG as PS (instead of Informational), please make sure that you are happy with that.

Are examples in …
[Ballot comment]
This is now returning to IESG as PS (instead of Informational), please make sure that you are happy with that.

Are examples in the document in JSON? If yes, you need to have JSON as a reference. Informative if they are just examples, Normative otherwise.

As Stephen pointed out: is "http1.1" correct or should this be "http/1.1". Similarly for "https1.1".
2016-05-10
18 Alexey Melnikov Ballot comment text updated for Alexey Melnikov
2016-05-09
18 (System) IANA Review state changed to IANA - Not OK from Version Changed - Review Needed
2016-05-09
18 Sabrina Tanamal
(Via drafts-lastcall-comment@iana.org): IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-cdni-footprint-capabilities-semantics-17.txt. If any part of this review is inaccurate, please let us know.

IANA …
(Via drafts-lastcall-comment@iana.org): IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-cdni-footprint-capabilities-semantics-17.txt. If any part of this review is inaccurate, please let us know.

IANA understands that, upon approval of this document, there are two actions which IANA must complete.

First, in the CDNI Payload Types subregistry of the Content Delivery Network Interconnection (CDNI) Parameters registry located at:

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

five new payload types are to be registered as follows:

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

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

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

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

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

As this document requests registrations in an Expert Review or Specification Required (see RFC 5226) 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.

Second, a new registry is to be created called the CDNI Capabilities Redirection Modes registry. The new registry will be a subregistry in the "Content Delivery Networks Interconnection (CDNI) Parameters" registry located at:

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

The new subregistry will be managed via the "IETF Review" policy as defined in [RFC5226].

There are initial registrations in the new registry as follows:


+------------------+----------------------------------+---------------+
| Redirection Mode | Description | RFC |
+------------------+----------------------------------+---------------+
| DNS-I | Iterative DNS-based Redirection | [ RFC-to-be ] |
| | | |
| DNS-R | Recursive DNS-based Redirection | [ RFC-to-be ] |
| | | |
| HTTP-I | Iterative HTTP-based Redirection | [ RFC-to-be ] |
| | | |
| HTTP-R | Recursive HTTP-based Redirection | [ RFC-to-be ] |
+------------------+----------------------------------+---------------+

IANA understands that these are the only actions 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 only to confirm what actions will be performed. 


Thank you,

Sabrina Tanamal
IANA Specialist
ICANN
2016-04-28
18 Kevin Ma New version available: draft-ietf-cdni-footprint-capabilities-semantics-18.txt
2016-04-28
17 Amy Vezza
The following Last Call announcement was sent out:

From: The IESG
To: "IETF-Announce"
CC: flefauch@cisco.com, cdni-chairs@ietf.org, draft-ietf-cdni-footprint-capabilities-semantics@ietf.org, alexey.melnikov@isode.com, cdni@ietf.org, "Francois …
The following Last Call announcement was sent out:

From: The IESG
To: "IETF-Announce"
CC: flefauch@cisco.com, cdni-chairs@ietf.org, draft-ietf-cdni-footprint-capabilities-semantics@ietf.org, alexey.melnikov@isode.com, cdni@ietf.org, "Francois Le Faucheur"
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (CDNI Request Routing: Footprint and Capabilities Semantics) 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: Footprint and Capabilities Semantics'
  as Proposed
Standard

This is a Second IETF LC, because the document status changed from
Informational to 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 2016-05-12. 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

  This document captures the semantics of the "Footprint and
  Capabilities Advertisement" part of the CDNI Request Routing
  interface, i.e., the desired meaning of "Footprint" and
  "Capabilities" in the CDNI context, and what the "Footprint and
  Capabilities Advertisement Interface (FCI)" offers within CDNI.  The
  document also provides guidelines for the CDNI FCI protocol.  It
  further defines a Base Advertisement Object, the necessary registries
  for capabilities and footprints, and guidelines on how these
  registries can be extended in the future.

The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-cdni-footprint-capabilities-semantics/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-cdni-footprint-capabilities-semantics/ballot/


The following IPR Declarations may be related to this I-D:

  https://datatracker.ietf.org/ipr/2656/
2016-04-28
17 Amy Vezza IESG state changed to In Last Call from Last Call Requested
2016-04-28
17 Alexey Melnikov Telechat date has been changed to 2016-05-19 from 2016-04-21
2016-04-28
17 Alexey Melnikov Last call was requested
2016-04-28
17 Alexey Melnikov IESG state changed to Last Call Requested from IESG Evaluation::AD Followup
2016-04-28
17 Alexey Melnikov Last call announcement was changed
2016-04-28
17 Alexey Melnikov Last call announcement was generated
2016-04-28
17 Alexey Melnikov The document was updated to be Proposed Standard as per initial IESG review.
2016-04-28
17 Alexey Melnikov Intended Status changed to Proposed Standard from Informational
2016-04-28
17 Alexey Melnikov Last call announcement was generated
2016-04-28
17 Alissa Cooper
[Ballot comment]
Thanks for updating the document status. Will re-review when it comes back to the IESG. Leaving my comment below since I haven't re-reviewed …
[Ballot comment]
Thanks for updating the document status. Will re-review when it comes back to the IESG. Leaving my comment below since I haven't re-reviewed yet.

(2) Section 4: "For all of these mandatory-to-implement footprint types ..." seems like a misuse of the term "mandatory-to-implement." I thought this section was specifying requirements for the FCI which is to be specified, but this implies that all conforming implementations would also have to implement all of the footprint types (country code, AS, and IP prefix). Has that already been decided as well? If so, it could be explained more clearly in the text.
2016-04-28
17 Alissa Cooper [Ballot Position Update] Position for Alissa Cooper has been changed to No Objection from Discuss
2016-04-27
17 Alexey Melnikov
[Ballot comment]
I need to re-Last Call the document as PS.

Are examples in the document in JSON? If yes, you need to have JSON …
[Ballot comment]
I need to re-Last Call the document as PS.

Are examples in the document in JSON? If yes, you need to have JSON as a reference. Informative if they are just examples, Normative otherwise.

As Stephen pointed out: is "http1.1" correct or should this be "http/1.1". Similarly for "https1.1".
2016-04-27
17 Alexey Melnikov Ballot comment text updated for Alexey Melnikov
2016-04-27
17 Alexey Melnikov
[Ballot comment]
Are examples in the document in JSON? If yes, you need to have JSON as a reference. Informative if they are just examples, …
[Ballot comment]
Are examples in the document in JSON? If yes, you need to have JSON as a reference. Informative if they are just examples, Normative otherwise.
2016-04-27
17 Alexey Melnikov Ballot comment text updated for Alexey Melnikov
2016-04-23
17 Kevin Ma IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2016-04-23
17 Kevin Ma New version available: draft-ietf-cdni-footprint-capabilities-semantics-17.txt
2016-04-22
16 Alexey Melnikov Ballot writeup was changed
2016-04-22
16 Alexey Melnikov Ballot approval text was generated
2016-04-21
16 Cindy Morgan IESG state changed to IESG Evaluation::AD Followup from IESG Evaluation
2016-04-21
16 Kathleen Moriarty [Ballot comment]
I also support Alissa & Mirja's discuss & comment points.
2016-04-21
16 Kathleen Moriarty [Ballot Position Update] New position, No Objection, has been recorded for Kathleen Moriarty
2016-04-21
16 Stephen Farrell
[Ballot comment]

- I wonder if IETF participants know if the phrase "included in
a standard adopted by IETF" used in the IPR declaration does …
[Ballot comment]

- I wonder if IETF participants know if the phrase "included in
a standard adopted by IETF" used in the IPR declaration does
or does not apply to this informational document? FWIW, I do
not know.  (We see this from time to time and mostly I think
it's just a case of using company-standard IPR boilerplate and
not considering informational and experimental RFCs, but who
knows. I think I do recall one company modifying their IPR
boilerplate before when this ambiguity was pointed out to
them, so maybe if someone knows someone here, that'd be good
info to pass on...:-)

- section 4: I don't get why a full IP address is needed here,
i.e. the v4 /32 or v6 /128. Why is that? And if it is needed,
will it cause the usual CDNI privacy issue for a standards
track document?

- 7.5: the value "https1.1" is odd - would that really be
used?
2016-04-21
16 Stephen Farrell [Ballot Position Update] New position, No Objection, has been recorded for Stephen Farrell
2016-04-20
16 Jari Arkko [Ballot Position Update] New position, No Objection, has been recorded for Jari Arkko
2016-04-20
16 Suresh Krishnan [Ballot comment]
I agree with Alissa and Mirja's positions.
2016-04-20
16 Suresh Krishnan [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan
2016-04-20
16 Amanda Baber IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed
2016-04-20
16 Joel Jaeggli [Ballot comment]
Rick Ceasarez reviewed for opsdir
2016-04-20
16 Joel Jaeggli [Ballot Position Update] New position, No Objection, has been recorded for Joel Jaeggli
2016-04-20
16 Ben Campbell
[Ballot comment]
I agree with Alissa's discuss and comments (and transitively, Mirja's comments). Specifically, I agree that the object definitions seem like they should be …
[Ballot comment]
I agree with Alissa's discuss and comments (and transitively, Mirja's comments). Specifically, I agree that the object definitions seem like they should be PS, and that much of the motivational text seems like input to the working group process, not output from it.

Additionally, I find the mix of using 2119 language for implementation requirements and requirements on protocol work confusing--especially in those sections where 2119 keywords are intermixed with the aforementioned motivational text.
2016-04-20
16 Ben Campbell [Ballot Position Update] New position, No Objection, has been recorded for Ben Campbell
2016-04-20
16 Alissa Cooper
[Ballot discuss]
I agree with Mirja's point #1, and I think it is DISCUSS-worthy. The document seems to be a mix of almost stream-of-conscious reasoning …
[Ballot discuss]
I agree with Mirja's point #1, and I think it is DISCUSS-worthy. The document seems to be a mix of almost stream-of-conscious reasoning for how the WG arrived at particular design decisions (which probably doesn't need to be in the document at all), requirements on the CDNI FCI, requirements on CDNs (Sec. 5), and then the definition of objects the FCI will use. At a minimum, the last two of these seem like they need to be in a standards-track document if interoperability is to be achieved. Thinking about it another way, when an FCI solution document does get written, won't it need a normative reference to this document because of Section 7? My hunch is that the answer is yes.
2016-04-20
16 Alissa Cooper
[Ballot comment]
(1) In line with Mirja's points #1 and #3, I also that the intermingling and redundancy in the text makes the document unclear …
[Ballot comment]
(1) In line with Mirja's points #1 and #3, I also that the intermingling and redundancy in the text makes the document unclear and probably not too easily accessible for implementers (e.g., burying requirements about what CDNs should and shouldn't advertise in the middle of a document that up to that point seemed to be mostly about the motivations for designing footprints/capabilities in particular ways). I would suggest streamlining the text so that the requirements on the FCI are clearly enumerated, and the motivation text is stripped or moved later in the document.

(2) Section 4: "For all of these mandatory-to-implement footprint types ..." seems like a misuse of the term "mandatory-to-implement." I thought this section was specifying requirements for the FCI which is to be specified, but this implies that all conforming implementations would also have to implement all of the footprint types (country code, AS, and IP prefix). Has that already been decided as well? If so, it could be explained more clearly in the text.
2016-04-20
16 Alissa Cooper [Ballot Position Update] New position, Discuss, has been recorded for Alissa Cooper
2016-04-20
16 Deborah Brungard [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard
2016-04-20
16 Mirja Kühlewind
[Ballot comment]
I did enter enter 'No Objection' because non of my comments should hold up publication, however, I really would like to see another …
[Ballot comment]
I did enter enter 'No Objection' because non of my comments should hold up publication, however, I really would like to see another revision of this doc to make it easier to read and understand.

1) Intended status
This documents contains two things
  a) Requirements (or here called Design Decision) for a FCI protocol
  b) Definition of the mandatory base object as well as  needed registries
While a) would clearly be an informational document, I would see b) rather as being a Standards track document.
Further, the document reads as if b) was added late in the process.
So my question is: was the intended status discussed in the working group and why was it decided to go for information?

2) footprint vs. capabilities
I'm sure (I hope) these terms are well understood in the wg, however, for me it is still not clear why a footprint is not just a capability but something special. I understood that other capabilities can be bounded to a footprint, however, can this not also be true for other capabilities? E.g. a certain protocol is only supported for a certain content type... or something like this?
Further, I still don't understand why you need a new term called footprint. In 2.2 you only talk about coverage which would be the better (more easy to understand) term for me. Also if you don't support something because of resource restrictions, this would still simple mean that you don't cover something.
If those terms are well understand and use in the wg, I do understand if you don't want to apply any changes anymore here. However, for the readability it might be helpful to at least add a terminology section at the very beginning of the doc.

3) Reduce Redundancy
I think it would help the readability if the requirements and the specification bits would be more clearly separated. I guess all requirements are listed and explained well in section 2. Therefore all reasoning given in the later section can simply be removed (and if needed replaced by a reference to the respective subsection in 2). Further, it's a little confusion that the requirements are phrased as if they should be addressesd in a future doc, while some of the requirements are already addressed in this doc by the given definitions.

4) Requirements
  a) It is mentioned a few times that the additional network load by sending these information must be limited to a reasonable amount, however, there is no explicit requirement in section 2 that is saying this. Would it make sense to add one more requirement here?
  b) Not sure if Focusing on Main Use Cases can/should actually be a requirement. The question might be rather but are the restrictions you will have by only focusing on the main use case/what cannot/does not have to be supported (overlapping coverage?)... however, that might only be a wording thing.

5) References:
[RFC2818], [RFC5226], [RFC7230], and [RFC7525] should be informative, while potentially some of the innformative refernces, e.g. RFC6770, should be normative.
2016-04-20
16 Mirja Kühlewind Ballot comment text updated for Mirja Kühlewind
2016-04-20
16 Mirja Kühlewind
[Ballot comment]
I did enter enter 'No Objection' because non of my comments should hold up publication, however, I really would like to see another …
[Ballot comment]
I did enter enter 'No Objection' because non of my comments should hold up publication, however, I really would like to see another revision of this doc to make it easier to read and understand.

1) Intended status
This documents contains two things
  a) Requirements (or here called Design Decision) for a FCI protocol
  b) Definition of the mandatory base object as well as  needed registries
While a) would clearly be an informational document, I would see b) rather as being a Standards track document.
Further, the document reads as if b) was added late in the process.
So my question is: was the intended status discussed in the working group and why was it decided to go for information?

2) footprint vs. capabilities
I'm sure (I hope) these terms are well understood in the wg, however, for me it is still not clear why a footprint is not just a capability but something special. I understood that other capabilities can be bounded to a footprint, however, can this not also be true for other capabilities? E.g. a certain protocol is only supported for a certain content type... or something like this?
Further, I still don't understand why you need a new term called footprint. In 2.2 you only talk about coverage which would be the better (more easy to understand) term for me. Also if you don't support something because of resource restrictions, this would still simple mean that you don't cover something.
If those terms are well understand and use in the wg, I do understand if you don't want to apply any changes anymore here. However, for the readability it might be helpful to at least add a terminology section at the very beginning of the doc.

3) Reduce Redundancy
I think it would help the readability if the requirements and the specification bits would be more clearly separated. I guess all requirements are listed and explained well in section 2. Therefore all reasoning given in the later section can simply be removed (and if needed replaced by a reference to the respective subsection in 2). Further, it's a little confusion that the requirements are phrased as if they should be addressesd in a future doc, while some of the requirements are already addressed in this doc by the given definitions.

4) Requirements
  a) It is mentioned a few times that the additional network load by sending these information must be limited to a reasonable amount, however, there is no explicit requirement in section 2 that is saying this. Would it make sense to add one more requirement here?
  b) Not sure if Focusing on Main Use Cases can/should actually be a requirement. The question might be rather but are the restrictions you will have by only focusing on the main use case/what cannot/does not have to be supported (overlapping coverage?)... however, that might only be a wording thing.

5) References:
[RFC2818], [RFC5226], [RFC7230], and [RFC7525] should be informational, while potentially some of the informational refernces, e.g. RFC6770, should be normative.
2016-04-20
16 Mirja Kühlewind Ballot comment text updated for Mirja Kühlewind
2016-04-20
16 Mirja Kühlewind
[Ballot comment]
I did enter enter 'No Objection' because non of my comments should hold up publication, however, I really would like to see another …
[Ballot comment]
I did enter enter 'No Objection' because non of my comments should hold up publication, however, I really would like to see another revision of this doc to make it easier to read and understand.

1) Intended status
This documents contains two things
  a) Requirements (or here called Design Decision) for a FCI protocol
  b) Definition of the mandatory base object as well as  needed registries
While a) would clearly be an informational document, I would see b) rather as being a Standards track document.
Further, the document reads as if b) was added late in the process.
So my question is: was the intended status discussed in the working group and why was it decided to go for information?

2) footprint vs. capabilities
I'm sure (I hope) these terms are well understood in the wg, however, for me it is still not clear why a footprint is not just a capability but something special. I understood that other capabilities can be bounded to a footprint, however, can this not also be true for other capabilities? E.g. a certain protocol is only supported for a certain content type... or something like this?
Further, I still don't understand why you need a new term called footprint. In 2.2 you only talk about coverage which would be the better (more easy to understand) term for me. Also if you don't support something because of resource restrictions, this would still simple mean that you don't cover something.
If those terms are well understand and use in the wg, I do understand if you don't want to apply any changes anymore here. However, for the readability it might be helpful to at least add a terminology section at the very beginning of the doc.

3) Reduce Redundancy
I think it would help the readability if the requirements and the specification bits would be more clearly separated. I guess all requirements are listed and explained well in section 2. Therefore all reasoning given in the later section can simply be removed (and if needed replaced by a reference to the respective subsection in 2). Further, it's a little confusion that the requirements are phrased as if they should be addressesd in a future doc, while some of the requirements are already addressed in this doc by the given definitions.

4) Requirements
  a) It is mentioned a few times that the additional network load by sending these information must be limited to a reasonable amount, however, there is no explicit requirement in section 2 that is saying this. Would it make sense to add one more requirement here?
  b) Not sure if Focusing on Main Use Cases can/should actually be a requirement. The question might be rather but are the restrictions you will have by only focusing on the main use case/what cannot/does not have to be supported (overlapping coverage?)... however, that might only be a wording thing.
2016-04-20
16 Mirja Kühlewind [Ballot Position Update] New position, No Objection, has been recorded for Mirja Kühlewind
2016-04-19
16 Terry Manderson [Ballot Position Update] New position, No Objection, has been recorded for Terry Manderson
2016-04-19
16 Alvaro Retana [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana
2016-04-18
16 Benoît Claise [Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise
2016-04-13
16 Kevin Ma New version available: draft-ietf-cdni-footprint-capabilities-semantics-16.txt
2016-04-12
15 Kevin Ma New version available: draft-ietf-cdni-footprint-capabilities-semantics-15.txt
2016-04-10
14 Gunter Van de Velde Request for Last Call review by OPSDIR Completed: Has Nits. Reviewer: Rick Casarez.
2016-04-07
14 Alexey Melnikov [Ballot Position Update] New position, Yes, has been recorded for Alexey Melnikov
2016-04-06
14 Amy Vezza Shepherding AD changed to Alexey Melnikov
2016-04-04
14 Kevin Ma New version available: draft-ietf-cdni-footprint-capabilities-semantics-14.txt
2016-04-04
13 Kevin Ma IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2016-04-04
13 Kevin Ma New version available: draft-ietf-cdni-footprint-capabilities-semantics-13.txt
2016-03-27
12 Jouni Korhonen Request for Telechat review by GENART No Response. Reviewer: Jouni Korhonen.
2016-03-27
12 Jouni Korhonen Request for Last Call review by GENART Completed: Ready with Nits. Reviewer: Jouni Korhonen.
2016-03-23
12 Tero Kivinen Request for Last Call review by SECDIR Completed: Has Issues. Reviewer: Brian Weis.
2016-03-23
12 Sabrina Tanamal IANA Review state changed to IANA OK - Actions Needed from IANA - Not OK
2016-03-22
12 Barry Leiba IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead
2016-03-22
12 (System) IESG state changed to Waiting for AD Go-Ahead from In Last Call
2016-03-21
12 Barry Leiba Changed consensus to Yes from Unknown
2016-03-21
12 (System) IANA Review state changed to IANA - Not OK from IANA - Review Needed
2016-03-21
12 Sabrina Tanamal
(Via drafts-lastcall-comment@iana.org): IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-cdni-footprint-capabilities-semantics-12.txt. If any part of this review is inaccurate, please let us know.

IANA …
(Via drafts-lastcall-comment@iana.org): IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-cdni-footprint-capabilities-semantics-12.txt. If any part of this review is inaccurate, please let us know.

IANA understands that, upon approval of this document, there are two actions which IANA must complete.

First, in the CDNI Payload Types subregistry of the Content Delivery Network Interconnection (CDNI) Parameters registry located at:

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

three new payload types are to be registered as follows:

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

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

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

As this document requests registrations in an Expert Review or Specification Required (see RFC 5226) 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.

Second, a new registry called the CDNI Capabilities Redirection Modes registry is to be created in the Content Delivery Network Interconnection (CDNI) Parameters registry located at:

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

The new registry will be managed via IETF Review as defined by RFC 5226. There are initial registrations in the registry as follows:

+------------------+----------------------------------+---------------+
| Redirection Mode | Description | Reference |
+------------------+----------------------------------+---------------+
| DNS-I | Iterative DNS-based Redirection | [ RFC-to-be ] |
| DNS-R | Recursive DNS-based Redirection | [ RFC-to-be ] |
| HTTP-I | Iterative HTTP-based Redirection | [ RFC-to-be ] |
| HTTP-R | Recursive HTTP-based Redirection | [ RFC-to-be ] |
+------------------+----------------------------------+---------------+

IANA understands that the two actions above are the only ones 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 only to confirm what actions will be performed. 


Thank you,

Sabrina Tanamal
IANA Specialist
ICANN
2016-03-21
12 Barry Leiba Ballot has been issued
2016-03-21
12 Barry Leiba [Ballot Position Update] New position, Yes, has been recorded for Barry Leiba
2016-03-21
12 Barry Leiba Created "Approve" ballot
2016-03-15
12 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Rick Casarez
2016-03-15
12 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Rick Casarez
2016-03-13
12 Barry Leiba Placed on agenda for telechat - 2016-04-21
2016-03-10
12 Jean Mahoney Request for Last Call review by GENART is assigned to Jouni Korhonen
2016-03-10
12 Jean Mahoney Request for Last Call review by GENART is assigned to Jouni Korhonen
2016-03-10
12 Tero Kivinen Request for Last Call review by SECDIR is assigned to Brian Weis
2016-03-10
12 Tero Kivinen Request for Last Call review by SECDIR is assigned to Brian Weis
2016-03-08
12 Amy Vezza IANA Review state changed to IANA - Review Needed
2016-03-08
12 Amy Vezza
The following Last Call announcement was sent out:

From: The IESG
To: "IETF-Announce"
CC: flefauch@cisco.com, cdni-chairs@ietf.org, barryleiba@gmail.com, draft-ietf-cdni-footprint-capabilities-semantics@ietf.org, cdni@ietf.org, "Francois …
The following Last Call announcement was sent out:

From: The IESG
To: "IETF-Announce"
CC: flefauch@cisco.com, cdni-chairs@ietf.org, barryleiba@gmail.com, draft-ietf-cdni-footprint-capabilities-semantics@ietf.org, cdni@ietf.org, "Francois Le Faucheur"
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (CDNI Request Routing: Footprint and Capabilities Semantics) to Informational RFC


The IESG has received a request from the Content Delivery Networks
Interconnection WG (cdni) to consider the following document:
- 'CDNI Request Routing: Footprint and Capabilities Semantics'
  as
Informational RFC

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 2016-03-22. 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

  This document captures the semantics of the "Footprint and
  Capabilities Advertisement" part of the CDNI Request Routing
  interface, i.e., the desired meaning of "Footprint" and
  "Capabilities" in the CDNI context, and what the "Footprint and
  Capabilities Advertisement Interface (FCI)" offers within CDNI.  The
  document also provides guidelines for the CDNI FCI protocol.  It
  further defines a Base Advertisement Object, the necessary registries
  for capabilities and footprints, and guidelines on how these
  registries can be extended in the future.


The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-cdni-footprint-capabilities-semantics/

When IESG discussion begins, it can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-cdni-footprint-capabilities-semantics/ballot/


The following IPR Declarations may be related to this I-D:

  https://datatracker.ietf.org/ipr/2656/



2016-03-08
12 Amy Vezza IESG state changed to In Last Call from Last Call Requested
2016-03-08
12 Barry Leiba Last call was requested
2016-03-08
12 Barry Leiba Ballot approval text was generated
2016-03-08
12 Barry Leiba IESG state changed to Last Call Requested from AD Evaluation::Point Raised - writeup needed
2016-03-08
12 Barry Leiba Last call announcement was changed
2016-03-08
12 Barry Leiba Last call announcement was generated
2016-03-08
12 Kevin Ma New version available: draft-ietf-cdni-footprint-capabilities-semantics-12.txt
2016-03-08
11 Barry Leiba IESG state changed to AD Evaluation::Point Raised - writeup needed from AD Evaluation
2016-03-05
11 Barry Leiba Ballot writeup was changed
2016-03-05
11 Barry Leiba Ballot writeup was generated
2016-03-05
11 Barry Leiba IESG state changed to AD Evaluation from Publication Requested
2016-03-05
11 François Le Faucheur
1. Summary

The document shepherd is Francois Le Faucheur.  The responsible AD is Barry Leiba. The requested RFC status is Informational.

This document describes the …
1. Summary

The document shepherd is Francois Le Faucheur.  The responsible AD is Barry Leiba. The requested RFC status is Informational.

This document describes the semantic of a footprint and capability advertisement function usable by interconnected CDNs allowing downstream CDNs (dCDNs) to advertise capabilities and the coverage footprint of those capabilities to upstream CDNs (uCDNs). This function is to be supported by the CDNI Footprint & Capabilities interface (FCI) identified in the CDNI Framework (RFC 7336). The FCI is intended to help an uCDN decides whether or not to delegate requests to a given dCDN.  

The WG had extensive discussions about the potential scope of the CDNI Footprint & Capabilities interface (FCI); this document provides a useful record of the key aspects of that discussion and the conclusions as to the scope agreed by the WG for FCI. Based on this, the document also captures the semantics of the FCI, defines a Base Advertisement Object, defines the necessary registries and provides guidelines on how these registries may be extended in the future. The document does not define, nor select, a specific protocol to realise the FCI interface.

2. Review and Consensus

The document contains historical information discussing and defining the scope of FCI (e.g., non-real-time updates, with no attempts to prevent CDNs from lying about footprints, and without requiring CDNs to divulge topology or capacity information).  There was a long history of debate over these issues, but consensus was reached.  This document defines the broad WG consensus on a minimum set of capabilities to be advertised, and the WG consensus on a minimum set of footprint types to support, with registries created for the future extensibility of both.  The document also defines an abstract object for defining new capabilities and footprints. This document is intended to provide guidance for the FCI interface standards track documents.

An independent review was performed by Iuniana Oprescu; all comments were addressed.

A large discussion took place over logistical issues around how to handle common references between FCI and CDNI Metadata, CDNI Logging, and CDNI Redirection interfaces. A broad consensus was reached after many small design team meetings were held to consider options.  The current IANA registry and media type structure is the result.

As document shepherd, I performed a final review including IANA considerations and normative references, as well as citing editorial and consistency issues; all comments were addressed.  

3. Intellectual Property

Each author has confirmed conformance with BCP 78/79.

There was one IPR disclosure from Juniper Networks.  The disclosure was announced on the list with only one response on the list stating that the RAND-like terms seemed reasonable. The disclosure was also discussed in the WG meeting at IETF94.  The chairs, as individuals, agreed that the RAND-like terms seemed reasonable and that they did not see any reason to hold up the document and, as chairs, proposed to go ahead with current plans to progress the document, and asked if anyone had any objection. There were no objections from the WG.

4. Other Points

There are no downward references in the document.

The IANA Considerations registers three new CDNI Paylod Types. One of the Authors is lined up as the designated expert reviewer for the CDNI Protocol Types registry.

The IANA Considerations also creates a new registry for redirection modes, providing sufficient guidelines to IANA. One of the Authors is lined up as the designated expert reviewer for the CDNI Capabilities Redirection Modes registry.
2016-03-05
11 François Le Faucheur Responsible AD changed to Barry Leiba
2016-03-05
11 François Le Faucheur IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up
2016-03-05
11 François Le Faucheur IESG state changed to Publication Requested
2016-03-05
11 François Le Faucheur IESG process started in state Publication Requested
2016-03-04
11 Kevin Ma New version available: draft-ietf-cdni-footprint-capabilities-semantics-11.txt
2016-03-04
10 François Le Faucheur Changed document writeup
2016-03-03
10 Kevin Ma New version available: draft-ietf-cdni-footprint-capabilities-semantics-10.txt
2016-01-15
09 Kevin Ma Intended Status changed to Informational from None
2016-01-15
09 Kevin Ma IETF WG state changed to WG Consensus: Waiting for Write-Up from WG Document
2015-11-04
09 Kevin Ma Notification list changed to "Francois Le Faucheur" <flefauch@cisco.com>
2015-11-04
09 Kevin Ma Document shepherd changed to Francois Le Faucheur
2015-11-03
09 Kevin Ma New version available: draft-ietf-cdni-footprint-capabilities-semantics-09.txt
2015-10-18
08 Kevin Ma New version available: draft-ietf-cdni-footprint-capabilities-semantics-08.txt
2015-08-21
Naveen Khan Posted related IPR disclosure: Juniper Networks, Inc.'s Statement about IPR related to draft-ietf-cdni-footprint-capabilities-semantics
2015-08-18
07 Kevin Ma New version available: draft-ietf-cdni-footprint-capabilities-semantics-07.txt
2015-03-09
06 Kevin Ma New version available: draft-ietf-cdni-footprint-capabilities-semantics-06.txt
2015-03-03
05 Jan Seedorf New version available: draft-ietf-cdni-footprint-capabilities-semantics-05.txt
2014-10-27
04 Kevin Ma New version available: draft-ietf-cdni-footprint-capabilities-semantics-04.txt
2014-07-20
03 Kevin Ma New version available: draft-ietf-cdni-footprint-capabilities-semantics-03.txt
2014-02-14
02 Kevin Ma New version available: draft-ietf-cdni-footprint-capabilities-semantics-02.txt
2013-10-21
01 Kevin Ma New version available: draft-ietf-cdni-footprint-capabilities-semantics-01.txt
2013-07-17
00 Jan Seedorf New version available: draft-ietf-cdni-footprint-capabilities-semantics-00.txt