Hi Sabine and all, Probably I did not make myself clear. When I said the two sections are similar to Sec 2 and Sec 5 in RFC 7285, I was mostly talking about the structure instead of the contents.
I think a brief summary of what Sec 2 of UP draft looks like the follows: > *ALTO information resources* contain relationships between different *entities* and *entity properties* and constrain the *domain of valid entities*. > To aggregate and distribute such information to ALTO clients, we define a new ALTO resource called Property Map. > For efficiency, clarity and other practical concerns, we define > *resource-specific entity domain*, *aggregated entity domain*, and *resource-specific entity property*. So we have two groups of concepts: those that motivate Property Map (i.e., WHY), and those that realize Property Map (HOW). The WHY concepts exist once we identify the problem and do not depend on the solution (which answers your second question), while the HOW concepts only exist because we solve the problem in a particular way. In RFC 7285, these two parts are put into two different sections. For example, Network Map is aimed to provide the aggregation of endpoints, using PID and endpoint address groups. Endpoint is in Sec 2, while PID and Endpoint Address (Group) are in Sec 5 after the Network Map is introduced. I feel we can use the same structure so we don't mix objectives and solutions. Best, Kai On Thu, Oct 10, 2019 at 9:07 PM Randriamasy, Sabine (Nokia - FR/Paris-Saclay) <[email protected]> wrote: > Hi Jensen, Kai > > > > Thanks Kai for your suggestions, please see my comments inline > > Best regards, > > Sabine > > > > > > *From:* alto <[email protected]> *On Behalf Of *Kai GAO > *Sent:* Thursday, October 10, 2019 5:42 AM > *To:* Jensen Zhang <[email protected]> > *Cc:* IETF ALTO <[email protected]> > *Subject:* Re: [alto] I-D Action: draft-ietf-alto-unified-props-new-09.txt > > > > Sounds good. :) > > > > On Thu, Oct 10, 2019 at 10:59 AM Jensen Zhang <[email protected]> > wrote: > > Hi Kai, > > > > Great! This structure looks better to clarify those concepts. I would like > to support it. If nobody has another proposal against it, let's add this > change in the next revision. > > > > I can send a new draft to you by this weekend so that you can take another > pass before we upload the next revision. > > > > Thanks, > > Jensen > > > > > > On Wed, Oct 9, 2019 at 10:46 PM Kai GAO <[email protected]> wrote: > > Hi Jensen and all, > > > > Actually, I would suggest the following structure: > > > > - Basic Concepts > > - Information Resource > > *[[SR]] it is indeed good to start with the Information Resource that this > draft introduces, which is the Property Map. Maybe provide a > “human-readable” definition and explain how it extends properties from > endpoints to entities and allows resource-specific entities and properties > for purposes of locality and others. And say this will be detailed in > further sections. Maybe also add a subsection with examples? * > > - Entity > > - Entity Property > > - Entity Domain > > - Property Map <==== Explain how property map works and the motivations > for exporting and aggregating entity domains > > - Resource-Specific Entity Domain > > - Aggregated Entity Domain > > - Resource-Specify Entity Property > > > > The two top-level sections (basic concepts and property map) are similar > to Sec 2 (Terminology) and Sec 5 (Network Map) in RFC 7285. > > > > In the basic concepts section, we are describing what already exists even > without the property map service. > > *[[SR]] Not sure I understand. RFC7285 supports Endpoint property maps, > not Entity property maps. So what is it that already exists? * > > > > In the property map section, we are "inventing" concepts that serve > certain practical purposes (e.g., provide indications of what > entities/properties can be queried, aggregate entities/properties). > > > > Having said that, it is OK with me that we keep the current structure or > only make some small changes if it requires too much work. > > > > Best, > > Kai > > > > > > > > On Thu, Oct 10, 2019 at 12:11 AM Jensen Zhang <[email protected]> > wrote: > > Hi Kai, > > > > I reviewed the document again. I think you are proposing the following > restructure, right? > > > > Entity -> Information Resource -> Entity Property (Resource-Specific > Entity Property) -> Property Map -> Entity Domain (Resource-Specific Entity > Domain, Aggregated Entity Domain) > > > > Intuitively it looks good. But when you look into the motivation of > Resource-Specific Entity Property, you will find it is weak here. Because > only when you use the Aggregated Entity Domain representation in a Property > Map, you will need this concept. Otherwise, it is useless. That is why I > put it behind those two concepts. But maybe your intuition is right. The " > Resource-Specific Entity Property" should be out of "Entity Domain". How > about we move 2.5.4 to 2.6? How do you think? > > > > Best, > > Jensen > > > > > > On Wed, Oct 9, 2019 at 9:02 AM Kai GAO <[email protected]> wrote: > > Hi Jensen and all, > > > > I'm looking at the -10 version and find it quite odd to have 2.5.4 > Resource-specific Entity Property as a subsection of 2.4 Entity Domain. > > > > My suggestion is to move 2.5.4 to 2.2 instead. Another potential > improvement is to move 2.4 Information Resource before 2.2. > > > > Best, > > Kai > > > > > > > > On Fri, Sep 27, 2019 at 5:28 AM Jensen Zhang <[email protected]> > wrote: > > Hi Danny, > > > > Thanks for your review and comments. Sabine and I are working on the next > revision. We will address all the issues in the next revision. > > > > And for your additional comment, actually, the "ip-pid-property-map" > resource in IRD is an example of Aggregated Entity Domain. Sec 9.7 should > illustrate it. But you are right, the current example in Sec 9.7 does not > show the benefit of Aggregated Entity Domain. I will also revise this > example in the next revision. > > > > Looking forward to your further comments. > > > > Thanks, > > Jensen > > > > > > On Wed, Sep 25, 2019 at 9:50 AM Danny Alex Lachos Perez < > [email protected]> wrote: > > Hi Sabine, > > > > I have a quick additional comment: > > > > I believe that an example (sec. 9) of Aggregated Entity Domain is missing.. > Perhaps you could re-use (or extend) the IRD example [0] and try to add a > couple of sentences to indicate equivalent entity property mappings (see > slide 17, 18 in [1]). > > > Best regards, > > > > Danny Lachos > > [0] > https://tools.ietf.org/html/draft-ietf-alto-unified-props-new-09#page-28 > > [1] > https://datatracker.ietf.org/meeting/105/materials/slides-105-alto-unified-properties-for-the-alto-protocol-02.pdf > > > > On Tue, Sep 24, 2019 at 10:42 AM Randriamasy, Sabine (Nokia - > FR/Paris-Saclay) <[email protected]> wrote: > > Hi Danny, > > > > Many thanks for your review. I saw your last comment is in Section 9.7. > > Should we consider that until section 9.7 your review is complete or will > you have more questions? > > We look forward to your other comments, > > Best regards, > > Sabine > > > > > > *From:* alto <[email protected]> *On Behalf Of *Danny Alex Lachos > Perez > *Sent:* Tuesday, September 17, 2019 8:28 PM > *To:* IETF ALTO <[email protected]> > *Cc:* [email protected] > *Subject:* Re: [alto] I-D Action: > draft-ietf-alto-unified-props-new-09....txt > > > > Dear authors, > > > > I started to read the “*Unified Properties for the ALTO Protocol*” draft > (-09). > > > > Please, see my first comments in the attached file (search for '[DANNY]').. > > Many of them are suggestions about clarity and format issues . > > > > I will continue the review and send additional comments in a short time. > > > Best regards, > > > > Danny Lachos > > > > > > On Wed, Sep 4, 2019 at 10:41 AM <[email protected]> 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 : Unified Properties for the ALTO Protocol > Authors : Wendy Roome > Sabine Randriamasy > Y. Richard Yang > Jingxuan Jensen Zhang > Kai Gao > Filename : draft-ietf-alto-unified-props-new-09.txt > Pages : 43 > Date : 2019-09-04 > > Abstract: > This document extends the Application-Layer Traffic Optimization > (ALTO) Protocol [RFC7285] by generalizing the concept of "endpoint > properties" to generic types of entities, and by presenting those > properties as maps, similar to the network and cost maps in > [RFC7285]. > > > > 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-09 > https://datatracker.ietf.org/doc/html/draft-ietf-alto-unified-props-new-09 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-alto-unified-props-new-09 > > > 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/ > <ftp://ftp.ietf.org/internet-drafts/> > > _______________________________________________ > alto mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/alto > > _______________________________________________ > alto mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/alto > > _______________________________________________ > alto mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/alto > >
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
