Hi Sebastian and Qin, Thanks for the suggestion and clarifications. I will update the beginning of the abstract as follows: -------------------- This document specifies an extension to the Application-Layer Traffic Optimization (ALTO) Protocol that generalizes the concept of "endpoint properties", which were so far tied to IP addresses, to entities defined by a wide set of objects. Further, these properties are presented as maps, similar to the network and cost maps in the base ALTO protocol. While supporting the endpoints and related endpoint property service defined in RFC7285, the protocol is extended in two major directions. --------------------
Sabine >-----Original Message----- >From: Qin Wu <[email protected]> >Sent: Wednesday, October 20, 2021 3:36 AM >To: Sebastian Kiesel <[email protected]>; Randriamasy, Sabine (Nokia - >FR/Paris-Saclay) <[email protected]> >Cc: alto-chairs <[email protected]>; draft-ietf-alto-unified-props- >[email protected]; [email protected] >Subject: RE: [alto] Update RFC7285 for unified property new draft > >Hi, Sebastian and Sabine: >-----邮件原件----- >发件人: alto [mailto:[email protected]] 代表 Sebastian Kiesel >发送时间: 2021年10月20日 4:07 >收件人: Randriamasy, Sabine (Nokia - FR/Paris-Saclay) ><[email protected]> >抄送: alto-chairs <[email protected]>; Qin Wu <[email protected]>; >[email protected]; [email protected] >主题: Re: [alto] Update RFC7285 for unified property new draft > >Hi Sabine, > >I agree that "specifies an optional extension" may be considered redundant >and a bit overly explicit. Once the RFC is published without the "updates" >tag, >a first sentence "This document specifies an extension to the Application- >Layer Traffic Optimization (ALTO) Protocol, which ..." will be enough that the >reader can understand the significance of the document and its relation to >RFC 7285. >In the meantime, the document shepherd may answer reviewer's questions >about why we chose not to tag the document with "updates" :) > >[Qin Wu] Good suggestion, we will see how to reflect this in the shepherd >write-up. > >please allow me one more comment about the new first sentence: > >> This document specifies an [optional] extension to the >> Application-Layer Traffic Optimization (ALTO) Protocol, which >> generalizes the concept of "endpoint properties" to entities defined >> by a wide set of objects, instead of only IP addresses. > >is a bit difficult for me to read because of two "switches" between old and >new: generalize [old] to [new] instead of [old] > >maybe: > >This document specifies an extension to the Application-Layer Traffic >Optimization (ALTO) Protocol that generalizes the concept of "endpoint >properties", which were so far tied to IP addresses, to entities defined by a >wide set of objects. > >[Qin Wu] :Good wording, I think we are in agreement on this issue, thank for >helping close this issue. >Thanks >Sebastian > > >On Tue, Oct 19, 2021 at 05:49:37PM +0000, Randriamasy, Sabine (Nokia - >FR/Paris-Saclay) wrote: >> Hi Qin and Sebastian, >> >> Thanks for the discussion. I agree with your conclusions and do not see the >need to indicate "updates" and definitely not "obsoletes". >> >> This extension does not oppose entities against endpoints. Therefore it does >not intend to replace endpoints with entities but adds entities and other >related features to the existing ones. Both are useful, as some use cases can >live with the base protocol. >> >> Actually, I suspect the term "limitations" used in the Introduction was >probably misleading, and the wording should be revised. The purpose of the >Introduction is to list a number of cases for which a protocol extension is >beneficial. For instance, use cases: >> (i) that involve entities in other domains than "ipv4" and "ipv6", or >> (ii) that use several or many information resources relatively to >> which entities are defined, or (iii) where clients would be better off >> fetching >with a GET, a whole property map, that covers a moderate number of >aggregated sets of entities instead of querying the properties with POST >requests enumerating all the individual entities. >> The purpose of the extensions listed in the Introduction is to support such >use cases. >> >> Other use cases can perfectly live with the base protocol. For backwards >compatibility, this extension supports RFC7285 services when they are >sufficient for the Client needs in ALTO information. The example IRD in >section 10.3 also indicates a "legacy-endpoint-property" property map. >> >> Last, borrowing from Sebastian, I propose the rewording below for the >abstract. The term "optional" is made optional since I feel most of the >extensions are optional as long as the base protocol is still useful for given >use >cases. >> >> OLD >> This document extends the base Application-Layer Traffic Optimization >> (ALTO) Protocol by generalizing the concept of "endpoint properties" >> to entities defined by a wide set of objects, instead of only IP >> addresses. Further, these properties are presented as maps, similar >> to the network and cost maps in the base ALTO protocol. The protocol >> is extended in two major directions. .... >> >> NEW >> This document specifies an [optional] extension to the Application-Layer >Traffic Optimization (ALTO) Protocol, which generalizes the concept of >"endpoint properties" to entities defined by a wide set of objects, instead of >only IP addresses. >> Further, these properties are presented as maps, similar to the network and >cost maps in the base ALTO protocol. >> While supporting the endpoints and related endpoint property service >defined in RFC7285, the protocol is extended in two major directions. .... >> >> Thanks in advance for your feedback, >> Sabine >> >> >> >-----Original Message----- >> >From: Qin Wu <[email protected]> >> >Sent: Tuesday, October 19, 2021 3:59 AM >> >To: Sebastian Kiesel <[email protected]> >> >Cc: alto-chairs <[email protected]>; [email protected]; >> >draft-ietf-alto-unified- [email protected]; >> >[email protected] >> >Subject: RE: [alto] Update RFC7285 for unified property new draft >> > >> >Thanks Sebastian for proposed change, it looks good and I believe it >> >address comments raised in the directorate review. >> >Authors of unified proper new drafts, please share your view on this. >Thanks! >> > >> >-Qin >> >-----邮件原件----- >> >发件人: Sebastian Kiesel [mailto:[email protected]] >> >发送时间: 2021年10月18日 17:02 >> >收件人: Qin Wu <[email protected]> >> >抄送: alto-chairs <[email protected]>; [email protected]; >> >draft-ietf-alto-unified- [email protected]; >> >[email protected] >> >主题: Re: [alto] Update RFC7285 for unified property new draft >> > >> >Hi Qin, all, >> > >> >I think one option, as draft-kuehlewind-update-tag is not a BCP yet, >> >would be NOT to add "updates: RFC 7285" to >> >draft-ietf-alto-unified-props and instead slightly reword the first sentence >of the abstract, maybe: >> > >> >old: >> > >> >This document extends the base Application-Layer Traffic Optimization >> >(ALTO) Protocol by generalizing the concept of "endpoint properties" >> >to entities defined by a wide set of objects, instead of only IP addresses. >> > >> >new: >> > >> >This document specifies an optional extension to the >> >Application-Layer Traffic Optimization (ALTO) Protocol, which >> >generalizes the concept of "endpoint properties" to entities defined >> >by a wide set of objects, instead of only IP addresses. >> > >> > >> >so it would be even clearer that it is a purely optional extension >> >and that we as the ALTO community, when we talk about "the ALTO >> >protocol" in the foreseeable future, we still mean RFC 7285 and NOT >> >necessarily always the combination of RFC 7285 and the RFC-to-be. >> > >> >thanks, >> >Sebastian >> > >> > >> >On Mon, Oct 18, 2021 at 04:13:01AM +0000, Qin Wu wrote: >> >> Hi, Sebastian: >> >> Good to hear your feedback on this issue, see my reply inline below. >> >> -----邮件原件----- >> >> 发件人: alto [mailto:[email protected]] 代表 Sebastian Kiesel >> >> 发送时间: 2021年10月17日 20:34 >> >> 收件人: Qin Wu <[email protected]> >> >> 抄送: alto-chairs <[email protected]>; [email protected]; >> >> [email protected] >> >> 主题: Re: [alto] Update RFC7285 for unified property new draft >> >> >> >> Hi Qin, all, >> >> >> >> I think "obsoletes" is definitively not adequate in this situation. >> >> My understanding of "A document that obsoletes an earlier document >> >> can >> >stand on its own." is, that if the draft wanted to "obsolete" RFC >> >7285, it would have to contain a complete, self-contained, new >> >specification of the ALTO protocol without any kind of "we do it like >> >described in RFC 7285" reference, such that someone could implement >> >the ALTO protocol without even reading RFC 7285. This is not the >> >case here, to the opposite (sec 3 says: "It assumes the reader is familiar >with the ALTO protocol [RFC7285]."). >> >> >> >> [Qin Wu] Agree, "obsoletes" is definitely not applied here unless >> >> we want >> >to make a bis document for RFC7285. >> >> >> >> Regarding "updates": Does the draft change anything to RFC 7285, >> >> except >> >adding a set of new optional features through the mechanisms we put >> >into RFC 7285 specifically for extending it, i.e., the IRD and the IANA >registries? >> >> [Qin Wu] My understanding is no. >> >> >> >> In other words, if someone were not interested in that addon, would >> >> it still >> >make sense to implement RFC 7285 and completely ignore the RFC-to-be? >> >> [Qin Wu] Yes, it makes sense, in my understanding. >> >> Or did the authors, while working on the extension, identify some >> >> issue in >> >the base protocol specification and specified a fix for that, which >> >is important even if someone is not interested in unified-props as such? >> >> If the latter is true, it's definitively a case for "updates", >> >> otherwise I'm not so >> >sure. >> >> [Qin Wu] Yes, I tend to agree with you, if we replace the existing >> >> text with >> >new text, or if we fix the bug issue in the existing mechanism or >> >protocol, we should use update "tag" >> >> If we extend the base protocol with new protocol extension or new >> >features, our principle is to not tag anything, either "obsolete" or >> >"update" >> >based on RFC2223 and RFC7322. >> >> >> >> But one document catches my eye recently, i.e., >> >> https://datatracker.ietf.org/doc/html/draft-kuehlewind-update-tag >> >> It proposes to link two documents with update by but splits update >> >> tag into >> >3 different tags, one is amends/amended by, the second is >> >extends/extend by, the third is See also/See also. Tag both cases >> >above with update tag flavors. >> >> In other words, for protocol extension or new feature without any >> >> update >> >to existing base protocol, we can still tag such document with update >> >tag, but we need to add more semantics to the update tag. >> >> >> >> Two reviews on unified property new draft now came up with the >> >> similar >> >issue, i.e., clarifying the relation with RFC7285 which makes me >> >rethink this issue again. Hope this clarifies my motivation to bring up this >issue on the list. >> >Maybe the author of draft-kuehlewind-update-tag can chime in to >> >clarify this to us. >> >> >> >> thanks >> >> Sebastian >> >> >> >> On Sun, Oct 17, 2021 at 07:04:38AM +0000, Qin Wu wrote: >> >> > Hi, All: >> >> > I have seen two directorate review discussed the relation of >> >> > unified property new draft >> >> > (https://datatracker.ietf.org/doc/html/draft-ietf-alto-unified-pr >> >> > ops >> >> > -n >> >> > ew) to ALTO based Protocol document (i.e.,RFC7285) and proposed >> >> > to >> >indicate this relation in the RFC header. >> >> > I am thinking whether update or obsolete in the document header >> >> > is to >> >clarify the relation to other RFCs. >> >> > See RFC2223 section 6: >> >> > " >> >> > 6. Relation to other RFCs >> >> > >> >> > Sometimes an RFC adds information on a topic discussed in a previous >> >> > RFC or completely replaces an earlier RFC. There are two terms used >> >> > for these cases respectively, Updates and Obsoletes. A document that >> >> > obsoletes an earlier document can stand on its own. A document that >> >> > merely updates an earlier document cannot stand on its own; it is >> >> > something that must be added to or inserted into the previously >> >> > existing document, and has limited usefulness independently. The >> >> > terms Supercedes and Replaces are no longer used. >> >> > >> >> > Updates >> >> > >> >> > To be used as a reference from a new item that cannot be used >> >> > alone (i.e., one that supplements a previous document), to refer >> >> > to the previous document. The newer publication is a part that >> >> > will supplement or be added on to the existing document; e.g., an >> >> > addendum, or separate, extra information that is to be added to >> >> > the original document. >> >> > >> >> > Obsoletes >> >> > >> >> > To be used to refer to an earlier document that is replaced by >> >> > this document. This document contains either revised information, >> >> > or else all of the same information plus some new information, >> >> > however extensive or brief that new information is; i.e., this >> >> > document can be used alone, without reference to the older >> >> > document. >> >> > >> >> > For example: >> >> > >> >> > On the Assigned Numbers RFCs the term Obsoletes should be used >> >> > since the new document actually incorporate new information >> >> > (however brief) into the text of existing information and is >> >> > more up-to-date than the older document, and hence, replaces it >> >> > and makes it Obsoletes. >> >> > >> >> > " >> >> > See RFC7322 section 4.14, >> >> > " >> >> > >> >> > 4.1.4. Updates and Obsoletes >> >> > >> >> > >> >> > >> >> > When an RFC obsoletes or updates a previously published RFC >> >> > or RFCs, >> >> > >> >> > this information is included in the document header. For example: >> >> > >> >> > >> >> > >> >> > "Updates: nnnn" or "Updates: nnnn, ..., nnnn" >> >> > >> >> > >> >> > >> >> > "Obsoletes: nnnn" or "Obsoletes: nnnn, ... , nnnn" >> >> > >> >> > >> >> > >> >> > If the document updates or obsoletes more than one document, >> >> > numbers >> >> > >> >> > will be listed in ascending order. >> >> > >> >> > " >> >> > Note than RFc7322 has obsoleted RFC2223. >> >> > I think "Update" is more close to what I am looking for since >> >> > what we did is Not to redefine the definition of "Unified >> >> > property map or Entity >> >property map" >> >> > Instead, we adds definitions to the existing RFC(i.e., entity property >map). >> >> > The content of the existing RFC is not invalidated by the new RFC >> >> > and is still needed to implement the endpoint property map in the >> >> > base protocol in some cases, but for some other cases when the >> >> > endpoint property map falls short, we will got for unified >> >> > property map >> >defined in unified property new draft. >> >> > >> >> > Therefore my understanding, is endpoint property map and entity >> >> > property map Have its own use cases, can be used separately, in >> >> > other words, use of endpoint property Map and use of entity >> >> > property map are mutually exclusive, even though like this, We >> >> > should still label >> >update in the document header. >> >> > If there is disagreement on this, please speak up and comment on this. >> >Thanks! >> >> > >> >> > -Qin (with chair hat on) >> >> >> >> > _______________________________________________ >> >> > 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
