Re: [alto] I-D Action: draft-ietf-alto-cdni-request-routing-alto-03.txt

[Jensen Zhang <[e-mail]>]

Hi authors and WG,

I reviewed the document alto-cdni-request-routing-alto-03 until Section 4.
About the content after Section 4, I only quick go over the English issues.
I will post my detailed review of the later sections tomorrow.

My current thought is that cdni fci information may not match the ALTO map
service very well. Because it does not even provide an object-map format
message. So it's hard to use the benefit of the ALTO map service, like
filtering. Or maybe we need to introduce a proper key like PID to index
the BaseAdvertisementObject.

Below is the part 1 of my detailed review:

=======
Abstract:

>    The Content Delivery Networks Interconnection (CDNI) WG is defining a
>    set of protocols to inter-connect CDNs, to achieve multiple goals
>    such as extending the reach of a given CDN to areas that are not
>    covered by that particular CDN.  One component that is needed to
>    achieve the goal of CDNI is the CDNI Request Routing Footprint &
>    Capabilities Advertisement interface (FCI) [RFC7336].  [RFC8008] has
>    defined precisely the semantics of FCI and provided guidelines on the
>    FCI protocol, but the exact protocol is explicitly outside the scope
>    of that document.  In this document, we define an FCI protocol using
>    the Application-Layer Traffic Optimization (ALTO) protocol.

  [Jensen] Based on nits:

https://www.ietf.org/tools/idnits?url=https://www.ietf.org/archive/id/draft-ietf-alto-cdni-request-routing-alto-03.txt
,
  the references should not appear in the abstract.


Section 1., paragraph 13:

>    This document focuses solely on CDNI FCI, with a goal to specify a
>    new Application-Layer Traffic Optimization (ALTO) [RFC7285] service
>    called "CDNI FCI Map Service", to transport and update CDNI FCI
>    objects, which are defined in a separate document in [RFC8008] and to
>    describe a mechanism for filtering CDNI FCI map on capabilities or
>    footprints.

  [Jensen] a mechanism -> approaches. If my understanding is right, this
  document does not introduce any new mechanism beyond the JSON encoding
  and the HTTP request/response. And Section 5 and 6 actually propose
  two different approahces for filtering on capabilities and footprints
  respectively.


Section 2., paragraph 1:

>    The design of CDNI FCI transport using ALTO depends on understanding
>    of both FCI semantics and ALTO.  Hence, we start with a review of
>    both.

  [Jensen] understanding -> the understanding


Section 2.1., paragraph 3:

>    o  Given that a large part of Footprint and Capabilities
>       Advertisement will actually happen in contractual agreements, the
>       semantics of CDNI Footprint and Capabilities advertisement refer

  [Jensen] refer -> refers


Section 2.1., paragraph 10:

>    o  For all of these mandatory-to-implement footprint types,
>       footprints can be viewed as constraints for delegating requests to
>       a dCDN: A dCDN footprint advertisement tells the uCDN the
>       limitations for delegating a request to the dCDN.  For IP prefixes
>       or ASN(s), the footprint signals to the uCDN that it should
>       consider the dCDN a candidate only if the IP address of the
>       request routing source falls within the prefix set (or ASN,
>       respectively).  The CDNI specifications do not define how a given
>       uCDN determines what address ranges are in a particular ASN.
>       Similarly, for country codes, a uCDN should only consider the dCDN
>       a candidate if it covers the country of the request routing
>       source.  The CDNI specifications do not define how a given uCDN
>       determines the country of the request routing source.  Multiple
>       footprint constraints are additive, i.e. the advertisement of

  [Jensen] i.e. -> i.e.,


Section 2.1., paragraph 12:

>    o  The following capabilities are defined as "base" capabilities,
>       i.e. ones that are needed in any case and therefore constitute

  [Jensen] i.e. -> i.e.,


Section 2.2., paragraph 5:

>    o  The semantics of an ALTO network map are an exact match for the

  [Jensen] are -> is


Section 2.2., paragraph 6:

>       needed information to convey a footprint by a downstream CDN, in
>       particular if such a footprint is being expressed by IP-prefix
>       ranges.

  [Jensen] "in particular" -> "in particular,"


Section 3., paragraph 1:

>    The ALTO protocol is based on an ALTO Information Service Framework
>    which consists of several services, where all ALTO services are
>    "provided through a common transport protocol, messaging structure
>    and encoding, and transaction model" [RFC7285].  The ALTO protocol
>    specification [RFC7285] defines several such services, e.g. the ALTO
>    map service.

  [Jensen] "e.g." -> "e.g.,"


Section 3., paragraph 2:

>    This document defines a new ALTO Map Service called "CDNI FCI Map
>    Service" which conveys JSON objects of media type "application/alto-
>    cdnifcimap+json".  These JSON objects are used to transport
>    BaseAdvertisementObject objects defined in [RFC8008]; this document
>    specifies how to transport such BaseAdvertisementObject objects via
>    the ALTO protocol with the ALTO "CDNI FCI Map Service".  Given that
>    the "CDNI FCI Map Service" is very similar in structure to the two
>    already defined map services (network maps and cost maps), the
>    specification of CDNI FCI Map below uses the same specification
>    structure for Cost Map specification in Section 11.2.3 of [RFC7285]
>    when specifying cost maps.

  [Jensen] Why use the same structure for Cost Map here? And even in
  structure, I think CDNI FCI Map is very different from Network Map and
  Cost Map. Because the data entry of those two map services point to
  object-map(s). But the data entry of CDNI FCI Map points to an
  JSONArray.


Section 3.6., paragraph 1:

>    If a CDNI FCI map does not depend on other resources, the "meta"
>    field of a CDNI FCI map response MUST include the "vtag" field

  [Jensen] Why need to emphasize "does not depend on other resources"?
  Even it depends on some resource, the "vtag" field is still necessary.
  Because whether the "vtag" field is needed depends on whether there
  are other resources using it, not whether it depends on others.


Section 3.6., paragraph 2:

>    defined in Section 10.3 of [RFC7285], which provides the version tag
>    of the retrieved CDNI FCI map.  If a CDNI FCI map response depends on
>    a resource such a network map, it MUST include the "dependent-vtags"

  [Jensen] such -> ,such as


Section 3.6., paragraph 6:

>    Specifically, a CDNIFCIMapData object is a JSON object, and it
>    includes only one property "capabilities" and whose value is an array

  [Jensen] To be distinguished from the ALTO Information Resource
  Capabilities, how about we change the field name "capabilities" to
  something like "fci-capabilities"?


Section 3.6., paragraph 8:

>    The ALTO client MUST interpret footprints appearing multiple times as

  [Jensen] "The ALTO client MUST ..." -> "For each
  BaseAdvertisementObject, the ALTO client MUST ..."


Section 3.6., paragraph 9:

>    if they appeared only once.  If no footprint restriction list is
>    specified (or an empty list is specified), the ALTO client MUST
>    understand that all footprint types are reset to "global" coverage.

  [Jensen] reset to "global" coverage -> set to the "global" coverage


Section 3.7.1., paragraph 1:

>    Below is an example IRD announcing two network maps, one CDNI FCI map
>    without dependency, one CDNI FCI map depending on a network map, one
>    filtered CDNI FCI map, one unified property map including "cdni-fci-
>    capabilities" as its entities' property, one filtered unified
>    property map including "cdni-fci-capabilities" and "pid" as its
>    entities' properties and two update stream services (one for updating
>    CDNI FCI maps, and the other for updating property maps).

  [Jensen] Since this is the first time to mention the "filtered CDNI
  FCI map", can we refer it to its definition? Like "filtered CDNI FCI
  map (defined in Section xxx)".


Section 4.1., paragraph 1:

>    In addition to the already defined CDNI footprint typs (e.g.,
>    ipv4cidr, ipv6cidr, asn, countrycode), ALTO network maps can be a
>    type of FCI footprint.  To enable such referencing to ALTO network
>    maps, a new CDNI Footprint Type "altonetworkmap" is defined (see also
>    Section 8.1).

  [Jensen] Not "see also Section 8.1". Because the IANA registry should
  point out the detailed specification, this section should describe the
  semantics and the specification of "altonetworkmap" footprint, and the
  Section 8.1 should refer to this section.


Section 4.2.4., paragraph 1:

>    In this example, the ALTO client is interested in changes of "my-
>    cdnifci-map-with-network-map-footrprints".  And we present two

  [Jensen] footrprints -> footprints


Section 5.1., paragraph 1:

>    Since a filtered CDNI FCI map is still a CDNI FCI map, it uses the
>    media type defined for CDNI FCI maps at Section 3.1.

  [Jensen] at -> in
=======

Best,
Jensen

On Wed, Jul 4, 2018 at 9:00 PM Shawn Lin <[e-mail]> wrote:

> Dear ALTO WG members,
>
> This is a short summary of updates in *alto-cdni-request-routing-alto-03*.
>
> *Major updates:*
> 1. Add a new section, "*section 7 Protocol Errors"*.
> 2. In *section 3.6*, shorten the original encoding with
> *BaseAdvertisementObject* defined in Section 5.1 of RFC 8008.
> 3. In *section 3.6*, remove the description of optimization to keep the
> document clean, but keep a note about the optimization of BaseAdvertisement
> objects.
>
> *   Note: Further optimization of BaseAdvertisement objects to*
> *   effectively provide the advertisement of capabilities with footprint*
> *   restrictions is certainly possible, however, it is not necessary for*
> *   the basic interconnection of CDNs.  The note here is for*
> *   completeness, however, the specifics of such mechanisms are outside*
> *   the scope of this document.*
>
>
> *Minor updates:*
> 1. Change media type of CDNI FCI Map to
> *"application/alto+cdnifcimap+json"*.
> 2. Change the response name of CDNI FCI Map to *"cdni-fci-map"* so it is
> consist with "network-map", "cost-map", "endpoint-cost-map".
> 3. Fix some typos.
>
> Any comments or feedback are highly appreciated!
>
> Bests,
> Shawn Lin
>
> On Mon, Jun 18, 2018 at 12:56 PM <[e-mail]> wrote:
>
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>> This draft is a work item of the Application-Layer Traffic Optimization
>> WG of the IETF.
>>
>>         Title           : Content Delivery Network Interconnection (CDNI)
>> Request Routing: CDNI Footprint and Capabilities Advertisement using ALTO
>>         Authors         : Jan Seedorf
>>                           Y.R. Yang
>>                           Kevin J. Ma
>>                           Jon Peterson
>>                           X.S. Lin
>>         Filename        : draft-ietf-alto-cdni-request-routing-alto-03.txt
>>         Pages           : 34
>>         Date            : 2018-06-17
>>
>> Abstract:
>>    The Content Delivery Networks Interconnection (CDNI) WG is defining a
>>    set of protocols to inter-connect CDNs, to achieve multiple goals
>>    such as extending the reach of a given CDN to areas that are not
>>    covered by that particular CDN.  One component that is needed to
>>    achieve the goal of CDNI is the CDNI Request Routing Footprint &
>>    Capabilities Advertisement interface (FCI) [RFC7336].  [RFC8008] has
>>    defined precisely the semantics of FCI and provided guidelines on the
>>    FCI protocol, but the exact protocol is explicitly outside the scope
>>    of that document.  In this document, we define an FCI protocol using
>>    the Application-Layer Traffic Optimization (ALTO) protocol.
>>
>>
>> The IETF datatracker status page for this draft is:
>>
>> https://datatracker.ietf.org/doc/draft-ietf-alto-cdni-request-routing-alto/
>>
>> There are also htmlized versions available at:
>> https://tools.ietf.org/html/draft-ietf-alto-cdni-request-routing-alto-03
>>
>> https://datatracker.ietf.org/doc/html/draft-ietf-alto-cdni-request-routing-alto-03
>>
>> A diff from the previous version is available at:
>>
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-alto-cdni-request-routing-alto-03
>>
>>
>> Please note that it may take a couple of minutes from the time of
>> submission
>> until the htmlized version and diff are available at tools.ietf.org.
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>> _______________________________________________
>> alto mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/alto
>>
> _______________________________________________
> alto mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/alto
>