# Abstract

I suggest to slightly increase the precision:

OLD
   [...] This document defines an FCI
   protocol using the Application-Layer Traffic Optimization (ALTO)
   protocol, following the guidelines defined in RFC 8008.

NEW
   [...] This document defines a new Application-Layer Traffic
   Optimization (ALTO) service called "CDNI Advertisement Service" that
   provides an implementation of the FCI, following the guidelines
   defined in RFC 8008.

# Section 2.1

While, in general, I have found the introduction and background section to
contain very clear and valuable information about context, rationale and
high level requirements and features, I am having some trouble parsing
this bit:

      [...] Multiple
      footprint constraints are additive, i.e., the advertisement of
      different types of footprint narrows the dCDN candidacy
      cumulatively.

Maybe it's just me, but I'd have appreciated if you could unpack this a
little.

# Section 2.2

For identification it's not the integrity property of signatures that
you care about but origin authentication:

OLD 
   o  Security: The identification between uCDNs and dCDNs is an
      important requirement.  ALTO maps can be signed and hence provide
      inherent integrity protection.  Please see Section 8.

NEW 
   o  Security: The identification between uCDNs and dCDNs is an
      important requirement.  ALTO maps can be signed and hence provide
      inherent origin authentication.  Please see Section 8.

It is not clear to a newcomer why a RESTful design is listed as one of
the criteria for choosing ALTO.  Please be more specific about the
advantages.  E.g., it's a good fit with the rest of the CDNI suite and
therefore reduces the cognitive dissonance for users and developers
alike?  It allows at least some level of code reuse?  

Typo:

OLD
      [...] A CDNI FCI interface based on ALTO
      would inherit this this extensive error-handling framework.

NEW
      [...] A CDNI FCI interface based on ALTO
      would inherit this extensive error-handling framework.

At this point in the document it may not be necessarily evident what
"the new endpoint property for ALTO" is -- at least to a newcomer.  I
suggest sticking a reference to I-D.ietf-alto-unified-props-new when
the term is first introduced.

# Section 3

I suggest adding a note regarding I-JSON (as per RFC 8008).

# Section 3.1

Is this the only CDNI interface envisaged in ALTO?  If the answer is
either "no" or "I don't know", it's probably better being more specific
WRT the name choice of the media type -- e.g.,
"application/alto-cdni-advertisement+json"?

# Section 3.2

Is there any specific recommendation regarding caching of these
resources?

# Section 3.5

   The "uses" field SHOULD NOT appear unless the CDNI Advertisement
   resource depends on other ALTO information resources

If the semantic of uses is not defined without an explicit resource
dependency why should you allow that?  I.e., why is this not a MUST NOT
rather than just a SHOULD NOT?

# Section 3.6

Expand IRD.  Maybe a better place to introduce the acronym is in Section
3.

What is the semantics of a CDNIAdvertisementData with empty
capabilities-with-footprints?  (I suggest you provide a one-liner that
presents the context in which that would be meaningful.)

What is the semantics of ""global" coverage"?  Is it what is
contractually (i.e., OOB) defined for the dCDN?

This text:
   To be self-contained, below is a non-normative specification of
   BaseAdvertisementObject.

I don't understand the "non-normative" bit: isn't this normatively
describing the syntax that implements the semantics defined in the CDNI
doc?

I am having a hard time parsing this text:

   Note: Further optimization of BaseAdvertisement objects to
   effectively provide the advertisement of capabilities with footprint
   restrictions is certainly possible. 

what optimisation are hinted here?  And what is their relation with the
examples?  Are those associated with the use of altopid?  If so, you
should consider adding a forward reference to section 4.1 here.

# Section 3.7.3

Typo:

OLD
  due to maintenance of the https/1.1 clusters

NEW
  due to maintenance of the http/1.1 clusters

# Section 3.7.3

At the end of:

   A benefit of using ALTO to provide CDNI Advertisement resources is
   that such resources can be updated using ALTO incremental updates

maybe add a reference to RFC8895 (also, I think RFC8895 should be
normatively referenced rather than just informatively?)

There seems to be a typo in the example:

OLD
    data:     "capabilities": [
    data:       {
    data:         "capability-type": "FCI.DeliveryProtocol",

NEW
    data:     "capabilities-with-footprints": [
    data:       {
    data:         "capability-type": "FCI.DeliveryProtocol",


# Section 5.3

The definition:

  [CDNIFCICapability cdni-capabilities<0..*>;]

looks a bit odd.  I'd have thought one of

  CDNIFCICapability cdni-capabilities<0..*>;

or

  [CDNIFCICapability cdni-capabilities<1..*>;]

would give the client all it needs to say: "give me the full resource".


Typo:

OLD
    cdni-fci-capabilities:  A list of CDNI capabilities defined in

NEW
    cdni-capabilities:  A list of CDNI capabilities defined in


# Section 5.6

Maybe put the conditional clause first:

OLD
   The response MUST indicate an error, using ALTO protocol error
   handling specified in Section 8.5 of the ALTO protocol [RFC7285], if
   the request is invalid.

NEW
   If the request is invalid, the response MUST indicate an error
   using the ALTO protocol error handling specified in Section 8.5
   of [RFC7285].


   [...] a filtered CDNI Advertisement request is invalid if:

      o  the value of "capability-type" is null;

      o  the value of "capability-value" is null;

What if one of capability-type or capability-value is missing?  What if
one of them is the empty value for the type or if any mandatory fields
are missing?  What if the value in "capability-type" is not known?  It'd
seem to me that the conditions that can make a request invalid can be
many more than those currently listed.  And in general I'd leave the
decision to the server.

Typo (same as above):

OLD
   superset of one of CDNI capability object in "cdni-fci-capabilities".

NEW
   superset of one of CDNI capability object in "cdni-capabilities".

# Section 5.7.3

(also in Sections 6.3.2 and 6.3.3)

Typo:

OLD
    HOST: alto.example.com

NEW
    Host: alto.example.com


# Section 6.1

   o  According to [I-D.ietf-alto-unified-props-new], "ipv4" and "ipv6"
      are two predefined entity domain types, which can be used to
      represent "ipv4cidr" and "ipv6cidr" footprints respectively.

AFAIU, for both ipv4 and ipv6, unified-props-new makes an encoding
distinction between individual and hierarchical addresses.  However,
ipv4cidr and ipv6cidr are always encoded as CIDR blocks, so the mapping
is not perfect and need a small adjustment (e.g., 192.0.2.1 =>
192.0.2.1/32).  Maybe this is worth noting?

# Section 7.1

The alignment in Table 1 is quite atrocious :-)  Also, in the
Specification column rather than just "Section N", consider using
"Section N of RFCthis" -- same as you do in Table 2 and 3.

# Section 7.2

OLD
   As proposed in Section 7.2 of [RFC8006], "CDNI Metadata Footprint
   Types" registry is requested.  A new footprint type is to be
   registered, listed in Table 2.

NEW
   IANA is requested to add the footprint type "altopid" described
   in Table 2 to the "CDNI Metadata Footprint Types" registry.

# Section 7.3

OLD
   As proposed in Section 11.2 of [I-D.ietf-alto-unified-props-new],
   "ALTO Entity Domain Type Registry" is requested.  Two new entity
   domain types are to be registered, listed in Table 3.

NEW
   IANA is requested to add the entity domain types "asn" and
   "countrycode" described in Table 3 to the "ALTO Entity Domain Type"
   registry.

Also, please fix the alignment of the "Entity Address Encoding" column
in Table 3.

# Section 7.4

OLD
   As proposed in Section 11.3 of [I-D.ietf-alto-unified-props-new],
   "ALTO Entity Property Type Registry" is required.  A new entity
   property type is to be registered, listed in Table 4.

NEW
   IANA is requested to add the identifier "cdni-capabilities" 
   described in Table 4 to the "ALTO Entity Property Type" registry.

# Section 8

OLD
   Although protection strategies as described in Section 15 of
   [RFC7285] should be applied to address aforementioned security
   considerations, [...]

NEW
   Although protection strategies as described in Section 15 of
   [RFC7285] should be applied to address aforementioned security
   and privacy considerations, [...]