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

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.

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.

Rick Ceasarez reviewed for opsdir

I also support Alissa & Mirja's discuss & comment points.

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.

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

I agree with Alissa and Mirja's positions.