Subject: [CDNi] Mirja Kühlewind's No Objection on draft-ietf-cdni-footprint-capabilities-semantics-16: (with COMMENT)

From: "Mirja Kuehlewind" <[email-masked]>
Date: Wed, 20 Apr 2016 09:03:47 -0700

Mirja Kühlewind has entered the following ballot position for
draft-ietf-cdni-footprint-capabilities-semantics-16: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-cdni-footprint-capabilities-semantics/

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