Subject: Re: [alto] Artart last call review of draft-ietf-alto-cdni-request-routing-alto-16

From: Jensen Zhang <[email-masked]>
Date: Tue, 7 Sep 2021 19:03:40 +0800

Hi Thomas,

Thanks for the very nice review! Please see our responses inline.

Thanks,
Jensen

On Sat, Aug 28, 2021 at 8:28 AM Thomas Fossati via Datatracker <
[email-masked]> wrote:

> Reviewer: Thomas Fossati
> Review result: Ready with Nits
>
> # 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.
>

Thanks for the suggestion. We will update the abstract.

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

Thanks for the feedback. We will change this sentence as follows:

NEW

   [...] Different types of footprint
   constraints can be combined together to narrow the dCDN candidacy, i.e.,
the
   uCDN should consider the dCDN a candidate only if the request routing
source
   satisfies all the types of footprint constraints in the advertisement.

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

Fixed.

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

Thanks for the suggestion. We will add the following sentence into this
bullet to make the benefit clear:

   [...] It can provide the consistent
   client-server interaction model for other existing CDNI interfaces or
   potential future extensions and therefore reduce the learning cost for
both
   users and developers, although they are not in the scope of this
   document. A CDNI FCI interface ...

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

Thanks. Fixed.

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

Good suggestion. Fixed.

>
> # Section 3
>
> I suggest adding a note regarding I-JSON (as per RFC 8008).
>

We will add the following note before Sec 3.1:

   Note that the encoding of BaseAdvertisementObject exactly reuses the one
   defined in [RFC8008] and therefore also follows the recommendations of
I-JSON
   (Internet JSON) [RFC7493], which is required by [RFC8008].

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

We do consider providing other CDNI interfaces in ALTO. But we think
"advertisement" can be a common and default CDNI functionality that is
considered to be delivered using ALTO.
Therefore we assign "application/alto-cdni+json" to it. But indeed, your
suggestion is also convincing. We will work with other IANA and CDNI
experts to update it.

>
> # Section 3.2
>
> Is there any specific recommendation regarding caching of these
> resources?
>

Can you explain more? ALTO is based on HTTP and therefore can reuse HTTP
cache control. Is it what you are looking for?

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

You are right. We will use MUST NOT instead.

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

Thanks for the catch. Fixed.

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

Good suggestion. We will add the following note at the end of the 4th
paragraph:

   If the value of this
   property is an empty array, it means the corresponding dCDN cannot
provide any
   mandatory-to-implement CDNI capabilities for any footprints.

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

We append the following explanation:

   [...] "global" coverage, i.e., the corresponding dCDN can provide them
for any request routing source.

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

"non-normative" may be confusing. We just want to introduce the encoding
using the consistent notation used in other ALTO-related documents.
How about we change this sentence to the following:

NEW:

   To be self-contained, below is an equivalent specification of
   BaseAdvertisementObject described in the ALTO-style notation (see
Section 8.2 of
   [RFC7285]). [...]

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

Example 1 contains two BaseAdvertisementObject objects for delivery
protocol http/1.1 and https/1.1 respectively.
But they have the same footprint constraints.
Example 2 merges them to a single BaseAdvertisementObject.
It has not been associated with altopid yet.
Do you think we need to illustrate the examples more?

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

Fixed.

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

Good catch. We will update it.

>
> 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",
>
>
Fixed.

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

Thanks for the suggestion. To be consistent with other ALTO services, we
will change it to the former one.

>
>
> Typo:
>
> OLD
>     cdni-fci-capabilities:  A list of CDNI capabilities defined in
>
> NEW
>     cdni-capabilities:  A list of CDNI capabilities defined in
>
>
Fixed.

>
> # 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].
>
>
Fixed.

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

Here we just discuss the E_INVALID_FIELD_VALUE error because this is the
only case that [RFC7285] does not define how to commonly handle.

For missing field cases, the ALTO server returns E_MISSING_FIELD. For other
cases, the ALTO server returns E_INVALID_FIELD_TYPE.

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

Fixed.

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

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

Very good catch! We will append a note and an additional example to
illustrate it.

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

Fixed.

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

Fixed.

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

Fixed.

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

> # 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, [...]
>
>
Fixed.

>
>
> _______________________________________________
> alto mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/alto
>

---

From: Thomas Fossati <[email-masked]>
Date: Tue, 7 Sep 2021 17:06:57 +0000

Hi Jensen,

Thanks very much for addressing my review.  Your proposed changes
generally look very good to me.

Some more (very minor) comments in-lined below.

cheers!

On 07/09/2021, 12:04, "Jensen Zhang" <[email-masked]> wrote:
> > On Sat, Aug 28, 2021 at 8:28 AM Thomas Fossati via Datatracker <[email-masked]> wrote:
> > 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?
>
> Thanks for the suggestion. We will add the following sentence into
> this bullet to make the benefit clear:
>
>    client-server interaction model for other existing CDNI interfaces
>    or potential future extensions and therefore reduce the learning
>    cost for both users and developers, although they are not in the
>    scope of this document. A CDNI FCI interface ...

That's great.  Although, I'd argue that developers are certainly in
scope :-) and -- to a smaller extent -- users too.

>    Note that the encoding of BaseAdvertisementObject exactly reuses
>    the one defined in [RFC8008] and therefore also follows the
>    recommendations of I-JSON (Internet JSON) [RFC7493], which is
>    required by [RFC8008].

Great.  (Maybe you could drop "exactly".)

> Can you explain more? ALTO is based on HTTP and therefore can reuse
> HTTP cache control. Is it what you are looking for?

Yes, I was wondering whether you have any specific recommendation for
the cache control settings associated with the resources you define.

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

The examples are pretty clear to me.  The thing that I couldn't
understand was what "further optimization [...] is certainly possible".
Is this referring to the merged example?

> > 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.
>
> Here we just discuss the E_INVALID_FIELD_VALUE error because this is
> the only case that [RFC7285] does not define how to commonly handle.
>
> For missing field cases, the ALTO server returns E_MISSING_FIELD. For
> other cases, the ALTO server returns E_INVALID_FIELD_TYPE.

WFM, and thanks for the explanation!  My comment was obviously missing
the wider ALTO context.

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.