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

[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".

[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".

[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".

(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

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/

[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.

[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".

[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.

[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?

[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.

[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.

[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.

[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.

[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.

[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.

(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

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/

NVO3 WG                                                      E. Nordmark
Internet-Draft                                                C. Appanna
Intended status: Standards Track                                  A. Lo
Expires: September 2, 2016                              Arista Networks
                                                                Mar 2016

    Layer-Transcending Traceroute for Overlay Networks like VXLAN
            draft-nordmark-nvo3-transcending-traceroute-02

Abstract

  Tools like traceroute have been very valuable for the operation of
  the Internet.  Part of that value comes from being able to display
  information about routers and paths over which the user of the tool
  has no control, but the traceroute output can be passed along to
  someone else that can further investigate or fix the problem.

  In overlay networks such as VXLAN and NVGRE the prevailing view is
  that since the overlay network has no control of the underlay there
  needs to be special tools and agreements to enable extracting traces
  from the underlay.  We argue that enabling visibility into the
  underlay and using existing tools like traceroute has been overlooked
  and would add value in many deployments of overlay networks.

  This document specifies an approach that can be used to make
  traceroute transcend layers of encapsulation including details for
  how to apply this to VXLAN.  The technique can be applied to other
  encapsulations used for overlay networks.  It can also be implemented
  using current commercial silicon.

Status of this Memo

  This Internet-Draft is submitted in full conformance with the
  provisions of BCP 78 and BCP 79.

  Internet-Drafts are working documents of the Internet Engineering
  Task Force (IETF).  Note that other groups may also distribute
  working documents as Internet-Drafts.  The list of current Internet-
  Drafts is at http://datatracker.ietf.org/drafts/current/.

  Internet-Drafts are draft documents valid for a maximum of six months
  and may be updated, replaced, or obsoleted by other documents at any
  time.  It is inappropriate to use Internet-Drafts as reference
  material or to cite them other than as "work in progress."

  This Internet-Draft will expire on September 2, 2016.

Nordmark, et al.        Expires September 2, 2016              [Page 1]
Internet-Draft                    LTTON                        Mar 2016

Copyright Notice

  Copyright (c) 2016 IETF Trust and the persons identified as the
  document authors.  All rights reserved.

  This document is subject to BCP 78 and the IETF Trust's Legal
  Provisions Relating to IETF Documents
  (http://trustee.ietf.org/license-info) in effect on the date of
  publication of this document.  Please review these documents
  carefully, as they describe your rights and restrictions with respect
  to this document.  Code Components extracted from this document must
  include Simplified BSD License text as described in Section 4.e of
  the Trust Legal Provisions and are provided without warranty as
  described in the Simplified BSD License.

Table of Contents

  1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
  2.  Solution Overview  . . . . . . . . . . . . . . . . . . . . . .  4
  3.  Goals and Requirements . . . . . . . . . . . . . . . . . . . .  5
  4.  Definition Of Terms  . . . . . . . . . . . . . . . . . . . . .  6
  5.  Example Topologies . . . . . . . . . . . . . . . . . . . . . .  6
  6.  Controlling and selecting ttl behavior . . . . . . . . . . . . 10
  7.  Introducing a ttl copyin flag in the encapsulation header  . . 10
  8.  Encapsulation Behavior . . . . . . . . . . . . . . . . . . . . 11
  9.  Decapsulating Behavior . . . . . . . . . . . . . . . . . . . . 14
  10. Other ICMP errors  . . . . . . . . . . . . . . . . . . . . . . 15
  11. Security Considerations  . . . . . . . . . . . . . . . . . . . 15
  12. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 16
  13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
  14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
    14.1.  Normative References  . . . . . . . . . . . . . . . . . . 16
    14.2.  Informative References  . . . . . . . . . . . . . . . . . 16
  Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18

Nordmark, et al.        Expires September 2, 2016              [Page 2]
Internet-Draft                    LTTON                        Mar 2016

1.  Introduction

  Tools like traceroute have been very valuable for the operation of
  the Internet.  Part of that value comes from being able to display
  information about routers and paths over which the user of the tool
  has no control, but the traceroute output can be passed along to
  someone else that can further investigate or fix the problem.  The
  output of traceroute can be included in an email or a trouble ticket
  to report the problem.  This provide a lot more information than the
  mere indication that A can&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.