Re: [alto] New Version Notification for draft-lachosrothenberg-alto-brokermdo-01.txt
Hello Richard Thanks a lot for your reviews. We will go over your comments in detail. Ss Danny Lachos On Mon, Jul 9, 2018 at 6:14 PM Y. Richard Yang wrote: > Danny, Christian, > > Very interesting work. I finished a review of Sec. 6, and below is > the second part of my review. > > Richard > > > 6. Proposed Approach > >The primary design goal for ALTO-based Broker-assisted Multi-domain >Orchestration is to discover resource and topology information from >different administrative domains involved in the federation, while >also safeguarding the privacy and autonomy of every domain. > > [yry] Connect to all requirements above? > >In the architectural proposal shown in Figure 1, a broker component >is conceived to be working as coordinator of a set of MdOs, whose key > > [yry] coordinator -> a coordinator; whose it is not clear righ away > what "whose" refers to, MdOs or broker? > >components are: the Inter-domain Resource (IdR), the Inter-domain >Topology (IdT) and the ALTO Server. > > > BROKER COMPONENT > [yry] COMPONENTS > > ++ > || > | +-+| > | | || > XXX ALTO SERVER(s) || > X | | +| > X | ++\| > X |/ \ | > X | / \ | > X | +--+/+---+ +---+ | > X | | Inter-domain | | Inter-domain | | > X | | Topology (IdT) | | Resource (IdR)| | > X | +-^--^---+ +---^---^---+ | > X || | | | | > X ++ > X| | | | > X| | | | >+--X+---++ | >| | | | >| | +++---+ >| MdO1 | || >| +<->++---+ >+---+ | MdO2 | | >|| | >+-+--+ | > | | >Legend: | MdO(n) | >XXX ALTO Protocol +--+ > > > >Figure 1: Broker-assisted Multi-operator Network Architecture > > [yry] Does it help to label all, or key edges, not only the single > XXX, on which protocol (protocols) will be used? You mentioned > BGP/BGP-LS, ... > > 6.1. Inter-domain Resource (IdR) Component > >It creates a hierarchical database that contains inter-domain >resource information such as resource availability (i.e., CPU, >memory, and storage), Virtual Network Functions (VNFs) and Physical >Network Functions (PNFs) supported and Service Access Points (SAPs) >to access those resources. UNIFY [UNIFY.NFFG], TOSCA [TOSCA], ETSI- > > [yry] It can be ambiguous what Service Access Points refer to, > only VNFs/PNFs or all? The idea of a hierarchical database appears > to > be not fully specified. > >NFV [ETSI-NFV-MANO], among other data models can be used to create >the interface between IdR and MdOs. > > [yry] IdR not defined yet---appeared only in the section title. > > 6.2. Inter-domain Topology (IdT) Component > >A hierarchical TED (Traffic Engineering Database) that contains >inter-domain network topology information including additional key >parameters (e.g., throughput and latency of links). This information >can be retrieved from each MdO through BGP-LS or REST interfaces. > > 6.3. ALTO Server Functionalities > >The ALTO server component is the core of the broker layer. Multiple >logically centralized ALTO servers use the information collected from >IdR and IdT modules to create and provide abstract maps with a > > [yry] module vs component > >simplified view, yet enough information about MdOs involved in the >federation. This information includes domain-level topology, storage >resources, computation resources, networking resources and PNF/VNF >capabilities. > > [yry] Consistency: missing CPU, as above? > >As an ALTO client, each MdO sends ALTO service queries to the ALTO >server. This server provides aggregated inter-domain information >exposed as set ALTO base services
Re: [alto] New Version Notification for draft-lachosrothenberg-alto-brokermdo-01.txt
Danny, Christian, Very interesting work. I finished a review of Sec. 6, and below is the second part of my review. Richard 6. Proposed Approach The primary design goal for ALTO-based Broker-assisted Multi-domain Orchestration is to discover resource and topology information from different administrative domains involved in the federation, while also safeguarding the privacy and autonomy of every domain. [yry] Connect to all requirements above? In the architectural proposal shown in Figure 1, a broker component is conceived to be working as coordinator of a set of MdOs, whose key [yry] coordinator -> a coordinator; whose it is not clear righ away what "whose" refers to, MdOs or broker? components are: the Inter-domain Resource (IdR), the Inter-domain Topology (IdT) and the ALTO Server. BROKER COMPONENT [yry] COMPONENTS ++ || | +-+| | | || XXX ALTO SERVER(s) || X | | +| X | ++\| X |/ \ | X | / \ | X | +--+/+---+ +---+ | X | | Inter-domain | | Inter-domain | | X | | Topology (IdT) | | Resource (IdR)| | X | +-^--^---+ +---^---^---+ | X || | | | | X ++ X| | | | X| | | | +--X+---++ | | | | | | | +++---+ | MdO1 | || | +<->++---+ +---+ | MdO2 | | || | +-+--+ | | | Legend: | MdO(n) | XXX ALTO Protocol +--+ Figure 1: Broker-assisted Multi-operator Network Architecture [yry] Does it help to label all, or key edges, not only the single XXX, on which protocol (protocols) will be used? You mentioned BGP/BGP-LS, ... 6.1. Inter-domain Resource (IdR) Component It creates a hierarchical database that contains inter-domain resource information such as resource availability (i.e., CPU, memory, and storage), Virtual Network Functions (VNFs) and Physical Network Functions (PNFs) supported and Service Access Points (SAPs) to access those resources. UNIFY [UNIFY.NFFG], TOSCA [TOSCA], ETSI- [yry] It can be ambiguous what Service Access Points refer to, only VNFs/PNFs or all? The idea of a hierarchical database appears to be not fully specified. NFV [ETSI-NFV-MANO], among other data models can be used to create the interface between IdR and MdOs. [yry] IdR not defined yet---appeared only in the section title. 6.2. Inter-domain Topology (IdT) Component A hierarchical TED (Traffic Engineering Database) that contains inter-domain network topology information including additional key parameters (e.g., throughput and latency of links). This information can be retrieved from each MdO through BGP-LS or REST interfaces. 6.3. ALTO Server Functionalities The ALTO server component is the core of the broker layer. Multiple logically centralized ALTO servers use the information collected from IdR and IdT modules to create and provide abstract maps with a [yry] module vs component simplified view, yet enough information about MdOs involved in the federation. This information includes domain-level topology, storage resources, computation resources, networking resources and PNF/VNF capabilities. [yry] Consistency: missing CPU, as above? As an ALTO client, each MdO sends ALTO service queries to the ALTO server. This server provides aggregated inter-domain information exposed as set ALTO base services defined in [RFC7285], e.g., Network Map, Cost Map and ALTO extension services, e.g., Property Map [DRAFT-PM], Multi-Cost Map [RFC8189], Path Vector [DRAFT-PV]. For example, when a source MdO receives a customer service request, it checks whether or not it can deliver the full service. If it is unable to do so, the MdO consumes from the ALTO
Re: [alto] FW: I-D Action: draft-ietf-alto-unified-props-new-04.txt
Hi Jensen and WG I finished my review on Sec 5-9. My comments are in the attached file marked with [DANNY]. Ss Danny Lachos On Mon, Jul 9, 2018 at 4:23 AM Jensen Zhang wrote: > Hi Danny, > > Thanks for your review. I quickly go over your comments. Many of your > comments are about the format issue. Authors will fix them soon. > > Thanks, > Jensen > > On Mon, Jul 9, 2018 at 1:24 AM Danny Alex Lachos Perez < > dlachos...@gmail.com> wrote: > >> Hello Sabine and WG >> >> I reviewed Introduction, S1, S2, S3, and S4 of the Unified Property >> draft. My comments are in the attached file (marked with [DANNY]). >> >> Ss >> >> Danny Lachos >> >> On Fri, Jun 29, 2018 at 3:11 PM Randriamasy, Sabine (Nokia - >> FR/Paris-Saclay) wrote: >> >>> Hello, >>> >>> The main updates in this new version relate to the consistency procedure >>> between ALTO Address Type Registry and >>> ALTO Entity Domain Registry as discussed during the ALTO WG session in >>> London. This is addressed in section 9. IANA Considerations, where 9.2 >>> specifies the ALTO Entity Domain Registry and 9.2.1. proposes an algorithm >>> to ensure consistency between both registries. >>> >>> Other updates include: >>> - in section 1. Introduction: a paragraph introducing ALTO Entity >>> domains, >>> - In section 6.3, some rewording to clarify between "pid" and "PID" to >>> avoid headaches, >>> - section 7.3 example IRD: name update for the Endpoint property resource >>> - section 7.4: example transaction >>> - Section 10 References: updates and reformatting >>> - usage of expression "ALTO Entity Domain" throughout the document >>> >>> Your feeback will be highly appreciated >>> >>> Thanks >>> Sabine, Jensen, Dawn >>> >>> -Original Message- >>> From: alto [mailto:alto-boun...@ietf.org] On Behalf Of >>> internet-dra...@ietf.org >>> Sent: Friday, June 29, 2018 7:29 PM >>> To: i-d-annou...@ietf.org >>> Cc: alto@ietf.org >>> Subject: [alto] I-D Action: draft-ietf-alto-unified-props-new-04.txt >>> >>> >>> 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 : Unified Properties for the ALTO Protocol >>> Authors : Wendy Roome >>> Shiwei Dawn Chen >>> Sabine Randriamasy >>> Y. Richard Yang >>> Jingxuan Jensen Zhang >>> Filename: draft-ietf-alto-unified-props-new-04.txt >>> Pages : 30 >>> Date: 2018-06-29 >>> >>> Abstract: >>>This document extends the Application-Layer Traffic Optimization >>>(ALTO) Protocol [RFC7285] by generalizing the concept of "endpoint >>>properties" to domains of other entities, and by presenting those >>>properties as maps, similar to the network and cost maps in ALTO. >>> >>> >>> >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-alto-unified-props-new/ >>> >>> There are also htmlized versions available at: >>> https://tools.ietf.org/html/draft-ietf-alto-unified-props-new-04 >>> >>> https://datatracker.ietf.org/doc/html/draft-ietf-alto-unified-props-new-04 >>> >>> A diff from the previous version is available at: >>> https://www.ietf.org/rfcdiff?url2=draft-ietf-alto-unified-props-new-04 >>> >>> >>> 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 >>> alto@ietf.org >>> https://www.ietf.org/mailman/listinfo/alto >>> >>> ___ >>> alto mailing list >>> alto@ietf.org >>> https://www.ietf.org/mailman/listinfo/alto >>> >> ___ >> alto mailing list >> alto@ietf.org >> https://www.ietf.org/mailman/listinfo/alto >> > ALTO WG W. Roome Internet-Draft Nokia Bell Labs Intended status: Standards Track S. Chen Expires: December 31, 2018 Tongji University S. Randriamasy Nokia Bell Labs Y. Yang Yale University J. Zhang Tongji University June 29, 2018 Unified Properties for the ALTO Protocol
Re: [alto] WGLC for draft-ietf-alto-incr-update-sse-11
Dear WG,
Just to clarify, the authors will revise SSE will fix the following issues:
1. fix text issues conveyed in the reviews
2. go over the server names and make the names of the servers consistent
(ALTO server, update stream server, stream control server);
3. clarify the stream control response codes
{204 + standard alto error codes} ->
add 202 Accepted
4. make a slight revision of the control update message syntax to be more
compact and extensible.
SSE is an important capability. If we miss any major items, please do let
the aithors know. We plan to make a pass before the ALTO session Monday
next week---exactly one week from today.
Thank you so much!
Ricard
On Mon, Jul 9, 2018 at 1:19 PM Y. Richard Yang wrote:
> Thanks a lot, Vijay, for the shepherding; Isabelle, Dawn, Kerim for the
> reviews.
>
> The authors are revising the document and will upload a new version
> addressing the reviews right after draft submission reopens.
>
> Richard
>
> On Mon, Jul 9, 2018 at 11:55 AM Vijay K. Gurbani
> wrote:
>
>> All: The WGLC for draft-ietf-alto-incr-update-sse is now over.
>>
>> Authors, please attend to the review comments by releasing a new version
>> that incorporates these.
>>
>> We will move the document ahead when the new version becomes available.
>>
>> Cheers,
>>
>> - vijay
>> --
>> Vijay K. Gurbani / vijay.gurb...@nokia.com
>> Network Data Science, Nokia Networks
>> Calendar: http://goo.gl/x3Ogq
>>
>> ___
>> alto mailing list
>> alto@ietf.org
>> https://www.ietf.org/mailman/listinfo/alto
>
>
--
--
=
| Y. Richard Yang|
| Professor of Computer Science |
| http://www.cs.yale.edu/~yry/|
=
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto
Re: [alto] WGLC for draft-ietf-alto-incr-update-sse-11
Thanks a lot, Vijay, for the shepherding; Isabelle, Dawn, Kerim for the reviews. The authors are revising the document and will upload a new version addressing the reviews right after draft submission reopens. Richard On Mon, Jul 9, 2018 at 11:55 AM Vijay K. Gurbani wrote: > All: The WGLC for draft-ietf-alto-incr-update-sse is now over. > > Authors, please attend to the review comments by releasing a new version > that incorporates these. > > We will move the document ahead when the new version becomes available. > > Cheers, > > - vijay > -- > Vijay K. Gurbani / vijay.gurb...@nokia.com > Network Data Science, Nokia Networks > Calendar: http://goo.gl/x3Ogq > > ___ > alto mailing list > alto@ietf.org > https://www.ietf.org/mailman/listinfo/alto ___ alto mailing list alto@ietf.org https://www.ietf.org/mailman/listinfo/alto
Re: [alto] WGLC for draft-ietf-alto-incr-update-sse-11
All: The WGLC for draft-ietf-alto-incr-update-sse is now over. Authors, please attend to the review comments by releasing a new version that incorporates these. We will move the document ahead when the new version becomes available. Cheers, - vijay -- Vijay K. Gurbani / vijay.gurb...@nokia.com Network Data Science, Nokia Networks Calendar: http://goo.gl/x3Ogq ___ alto mailing list alto@ietf.org https://www.ietf.org/mailman/listinfo/alto
[alto] Publication has been requested for draft-ietf-alto-cost-calendar-07
Vijay Gurbani has requested publication of draft-ietf-alto-cost-calendar-07 as Proposed Standard on behalf of the ALTO working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-alto-cost-calendar/ ___ alto mailing list alto@ietf.org https://www.ietf.org/mailman/listinfo/alto
Re: [alto] I-D Action: draft-ietf-alto-cost-calendar-06.txt
Jensen and Dawn have reviewed S6 and S7 of draft-ietf-alto-cost-calendar-07. Their review has not uncovered substantive drawbacks of the text in these sections; the changes requested by the authors are more editorial in nature. Authors, please make a note of these editorial comments. Therefore, based on this, I will go ahead and put -07 up for IESG review with the expectation that these comments on S6 and S7 will be fixed with whatever feedback we get from IESG for the draft. Cheers, - vijay -- Vijay K. Gurbani / vijay.gurb...@nokia.com Network Data Science, Nokia Networks Calendar: http://goo.gl/x3Ogq ___ alto mailing list alto@ietf.org https://www.ietf.org/mailman/listinfo/alto
Re: [alto] I-D Action: draft-ietf-alto-cdni-request-routing-alto-03.txt
Hi Jensen,
Thank you so much! Very appreciated! Please see my comments in line.
On Mon, Jul 9, 2018 at 11:47 AM Jensen Zhang
wrote:
> 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.
>
>
PID is one type of Footprint. BaseAdvertisementObject contains Capabilities
and Footprints. So using PID to index the BaseAdvertisementObject may not
be proper. And in current design, we can use the unified property map to
descripe a Footprint with its Capabilities. I think I can add one example
to show a PID Footprint with its Capabilities.
"pid:pid1": {
"cdni-fci-capabilities": [{"capability-type":,
"capability-value":}]
}
A potentially way to utilizing the existed ALTO services to filter based on
Capabilities is to use the unified property map. We could consider
Capability as an entity as well.
"FCIDeliveryProtocol:http_11": {
"footprints": [{"footprint-type":, "footprint-value":}]
}
If we do so, we may need to rich the semantics of entity. Section 2.4
Entity Address in unified property map may need to be revised.
What do you think?
> 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.
>
> Thanks, fixed.
>
> 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.
>
> Thanks, fixed.
>
> 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
>
> Thanks, fixed.
>
> 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
>
> Thanks, fixed.
>
>
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
> >
Re: [alto] FW: I-D Action: draft-ietf-alto-unified-props-new-04.txt
Hi Danny, Thanks for your review. I quickly go over your comments. Many of your comments are about the format issue. Authors will fix them soon. Thanks, Jensen On Mon, Jul 9, 2018 at 1:24 AM Danny Alex Lachos Perez wrote: > Hello Sabine and WG > > I reviewed Introduction, S1, S2, S3, and S4 of the Unified Property > draft. My comments are in the attached file (marked with [DANNY]). > > Ss > > Danny Lachos > > On Fri, Jun 29, 2018 at 3:11 PM Randriamasy, Sabine (Nokia - > FR/Paris-Saclay) wrote: > >> Hello, >> >> The main updates in this new version relate to the consistency procedure >> between ALTO Address Type Registry and >> ALTO Entity Domain Registry as discussed during the ALTO WG session in >> London. This is addressed in section 9. IANA Considerations, where 9.2 >> specifies the ALTO Entity Domain Registry and 9.2.1. proposes an algorithm >> to ensure consistency between both registries. >> >> Other updates include: >> - in section 1. Introduction: a paragraph introducing ALTO Entity domains, >> - In section 6.3, some rewording to clarify between "pid" and "PID" to >> avoid headaches, >> - section 7.3 example IRD: name update for the Endpoint property resource >> - section 7.4: example transaction >> - Section 10 References: updates and reformatting >> - usage of expression "ALTO Entity Domain" throughout the document >> >> Your feeback will be highly appreciated >> >> Thanks >> Sabine, Jensen, Dawn >> >> -Original Message- >> From: alto [mailto:alto-boun...@ietf.org] On Behalf Of >> internet-dra...@ietf.org >> Sent: Friday, June 29, 2018 7:29 PM >> To: i-d-annou...@ietf.org >> Cc: alto@ietf.org >> Subject: [alto] I-D Action: draft-ietf-alto-unified-props-new-04.txt >> >> >> 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 : Unified Properties for the ALTO Protocol >> Authors : Wendy Roome >> Shiwei Dawn Chen >> Sabine Randriamasy >> Y. Richard Yang >> Jingxuan Jensen Zhang >> Filename: draft-ietf-alto-unified-props-new-04.txt >> Pages : 30 >> Date: 2018-06-29 >> >> Abstract: >>This document extends the Application-Layer Traffic Optimization >>(ALTO) Protocol [RFC7285] by generalizing the concept of "endpoint >>properties" to domains of other entities, and by presenting those >>properties as maps, similar to the network and cost maps in ALTO. >> >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-alto-unified-props-new/ >> >> There are also htmlized versions available at: >> https://tools.ietf.org/html/draft-ietf-alto-unified-props-new-04 >> https://datatracker.ietf.org/doc/html/draft-ietf-alto-unified-props-new-04 >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=draft-ietf-alto-unified-props-new-04 >> >> >> 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 >> alto@ietf.org >> https://www.ietf.org/mailman/listinfo/alto >> >> ___ >> alto mailing list >> alto@ietf.org >> https://www.ietf.org/mailman/listinfo/alto >> > ___ > alto mailing list > alto@ietf.org > https://www.ietf.org/mailman/listinfo/alto > ___ alto mailing list alto@ietf.org https://www.ietf.org/mailman/listinfo/alto
Re: [alto] FW: I-D Action: draft-ietf-alto-unified-props-new-04.txt
Hi Qiao, Thanks for your review. Authors will consider your comments and update the document soon. About the technical issues you mentioned, see my comments inline: Thanks, Jensen On Sun, Jul 8, 2018 at 11:16 AM Qiao Xiang wrote: > Dear Sabine, Jensen and Dawn, > > I finished my review on Section 1-6 of the Unified Property draft. In the > attached file,, all the comments are marked wtih "[qiao]". I will send > out the reviews for the remaining sections soon. > > Most of my comments are related to consistency and clarity. However, there > are two technical issues I want to emphasize here, to seek the opinions > from you and other WG members: > > 1. In Section 4.4: in the PropertyMapCapabilities object to define the > capabilities of a Property Map: the types of entity domains and the types > of properties provided in this map are each defined using a list, > respectively. With such a spec, how should the client know which domain has > which property? Consider the case where the server announces that it has a > property map with two entity domains d1 and d2, and property p1 and p2. If > the client wants to know the property of some entities in domain d1, it > sends a filtered property map query to the server. But it turns out, the > server only provides property p1 for domain d2. As such, the client gets a > bunch of "null" or error code. Only by now the client knows that the server > only provides property p1 for domain d2 entities, but a round-trip is > wasted. Simple as this example is, it can turn into a much troubling > scenario: imaging X (e.g., 10) domains and Y (e.g., 20) properties. > > One solution to fix this issue, proposed during my offline discussion with > Jensen, is to redefine the PropertyMapCapabilities using an array of > (entity, property) combination. > > Sure, we already discussed offline. But after that, I rethink about this problem. In a single property map resource, the "prop-types" and the "entity-domain-types" should be fully bound. So if an ALTO server wants to provide property p1 and p2 for domain d1, and only property p1 for domain d2, the best practice should be to separate domain d1 and d2 to different property maps. Does it make sense? Waiting for more comments from others. > 2. In Section 6.3, the writing seems to only focus on the pid property of > IP entities. But conceptually other entity domains may also have a "pid" > property, right? I understand that this section is mainly to discuss the > compatibility with the pid property provided by ALTO EPS service, but it > should be stated clearly so that the readers would not be confused. > > Although we do not mention that "pid" property must bind with the IP entities, I'm not sure whether we should emphasize this. Because in this document, we only define IP domain and PID domain. And only IP domain may own the "pid" property. If the future documents define another entity domain owning a property called "pid", it can specify the semantics by itself. > Please let me know if you have any thoughts on these. Thanks. > > > Best > Qiao > > > > > > On Fri, Jun 29, 2018 at 2:11 PM Randriamasy, Sabine (Nokia - > FR/Paris-Saclay) wrote: > >> Hello, >> >> The main updates in this new version relate to the consistency procedure >> between ALTO Address Type Registry and >> ALTO Entity Domain Registry as discussed during the ALTO WG session in >> London. This is addressed in section 9. IANA Considerations, where 9.2 >> specifies the ALTO Entity Domain Registry and 9.2.1. proposes an algorithm >> to ensure consistency between both registries. >> >> Other updates include: >> - in section 1. Introduction: a paragraph introducing ALTO Entity domains, >> - In section 6.3, some rewording to clarify between "pid" and "PID" to >> avoid headaches, >> - section 7.3 example IRD: name update for the Endpoint property resource >> - section 7.4: example transaction >> - Section 10 References: updates and reformatting >> - usage of expression "ALTO Entity Domain" throughout the document >> >> Your feeback will be highly appreciated >> >> Thanks >> Sabine, Jensen, Dawn >> >> -Original Message- >> From: alto [mailto:alto-boun...@ietf.org] On Behalf Of >> internet-dra...@ietf.org >> Sent: Friday, June 29, 2018 7:29 PM >> To: i-d-annou...@ietf.org >> Cc: alto@ietf.org >> Subject: [alto] I-D Action: draft-ietf-alto-unified-props-new-04.txt >> >> >> 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 : Unified Properties for the ALTO Protocol >> Authors : Wendy Roome >> Shiwei Dawn Chen >> Sabine Randriamasy >> Y. Richard Yang >> Jingxuan Jensen Zhang >> Filename: draft-ietf-alto-unified-props-new-04.txt >> Pages : 30 >> Date
