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:
=======
Post by i***@ietf.orgThe 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.
Post by i***@ietf.orgThis 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.
Post by i***@ietf.orgThe 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
Post by i***@ietf.orgo 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
Post by i***@ietf.orgo 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.,
Post by i***@ietf.orgo 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.,
Post by i***@ietf.orgo The semantics of an ALTO network map are an exact match for the
[Jensen] are -> is
Post by i***@ietf.orgneeded 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,"
Post by i***@ietf.orgThe 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.,"
Post by i***@ietf.orgThis 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.
Post by i***@ietf.orgIf 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.
Post by i***@ietf.orgdefined 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
Post by i***@ietf.orgSpecifically, 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"?
Post by i***@ietf.orgThe ALTO client MUST interpret footprints appearing multiple times as
[Jensen] "The ALTO client MUST ..." -> "For each
BaseAdvertisementObject, the ALTO client MUST ..."
Post by i***@ietf.orgif 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
Post by i***@ietf.orgBelow 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)".
Post by i***@ietf.orgIn 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.
Post by i***@ietf.orgIn this example, the ALTO client is interested in changes of "my-
cdnifci-map-with-network-map-footrprints". And we present two
[Jensen] footrprints -> footprints
Post by i***@ietf.orgSince 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
Post by i***@ietf.orgDear 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
Post by i***@ietf.orgA 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
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.
https://datatracker.ietf.org/doc/draft-ietf-alto-cdni-request-routing-alto/
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
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.
ftp://ftp.ietf.org/internet-drafts/
_______________________________________________
alto mailing list
https://www.ietf.org/mailman/listinfo/alto
_______________________________________________
alto mailing list
https://www.ietf.org/mailman/listinfo/alto