Yes, the so the idea here is that we'd do a short new PS document updating 7285 to loosen the MUST and establish a registry, which path-vector could then reference.
On Fri, Mar 4, 2022 at 2:42 AM Qin Wu <bill...@huawei.com> wrote: > Kai: > > If my understanding is correct, an Experimental RFC can not update a > Standards Track RFC. It is unlikely IESG will make a new rule for this. > > > > -Qin > > *发件人:* kai...@scu.edu.cn [mailto:kai...@scu.edu.cn] > *发送时间:* 2022年3月4日 15:24 > *收件人:* Martin Duke <martin.h.d...@gmail.com> > *抄送:* Benjamin Kaduk <ka...@mit.edu>; IETF ALTO <alto@ietf.org>; > alto-chairs <alto-cha...@ietf.org>; The IESG <i...@ietf.org>; > draft-ietf-alto-path-vec...@ietf.org > *主题:* Re: Re: [alto] Benjamin Kaduk's Discuss on > draft-ietf-alto-path-vector-22: (with DISCUSS and COMMENT) > > > > Hi Martin and Ben, > > > > I think ideally making an update to RFC 7285 probably is the best way to > solve the issue. In RFC 7285, the definition for the cost services actually > leave space for non-numerical/ordinal cost values: > > > > Section 11.2.3.6: > > > > ... An implementation of the protocol in this document > > SHOULD assume that the cost is a JSONNumber and fail to parse if it > > is not, unless the implementation is using an extension to this > > document that indicates when and how costs of other data types are > > signaled. > > and similarly in section 11.5.1.6: > > > > ... An implementation of the protocol in this document > > SHOULD assume that the cost value is a JSONNumber and fail to parse > > if it is not, unless the implementation is using an extension to this > > document that indicates when and how costs of other data types are > > signaled. > > > > Thus, adding a cost mode registry and modifying the definition of CostMode > in section 10.5 may be sufficient to solve the issue without breaking the > other parts of RFC 7285 and other extensions. > > > > Best, > > Kai > > > > > -----Original Messages----- > *From:*"Martin Duke" <martin.h.d...@gmail.com> > *Sent Time:*2022-03-04 04:25:37 (Friday) > *To:* "Kai Gao" <kai...@scu.edu.cn> > *Cc:* "Benjamin Kaduk" <ka...@mit.edu>, "IETF ALTO" <alto@ietf.org>, > alto-chairs <alto-cha...@ietf.org>, "The IESG" <i...@ietf.org>, > draft-ietf-alto-path-vec...@ietf.org > *Subject:* Re: [alto] Benjamin Kaduk's Discuss on > draft-ietf-alto-path-vector-22: (with DISCUSS and COMMENT) > > Ben and Kai, > > > > Thanks for calling attention to this problem. > > > > In RFC 7285, there is no IANA registry for Cost Mode, because, as you > point out Sec 10.5 > <https://www.rfc-editor.org/rfc/rfc7285.html#section-10.5> says the Mode > MUST be "ordinal" or "numerical". > > > > RFC 8896, though not listed as a document that updates RFC 7285, certainly > implies it is doing so in Sec 3.3.1: > <https://www.rfc-editor.org/rfc/rfc8896.html#name-alto-cost-calendar-for-all-> > > > > An ALTO Cost Calendar is well suited for values encoded in the "numerical" > mode. Actually, a Calendar can also represent metrics in other modes > considered as compatible with time-varying values. For example, types of > cost values (such as JSONBool) can also be calendared (as their value may > be 'true' or 'false' depending on given time periods or likewise) values > represented by strings, such as "medium", "high", "low", "blue", and "open". > > > > and in 3.3.2: > > > > As a consequence, when a metric is available as a Calendar array, it also > *MUST* be available as a single value, as required by [RFC7285 > <https://www.rfc-editor.org/rfc/rfc8896.html#RFC7285>]. The Server, in > this case, provides the current value of the metric to either > Calendar-aware Clients not interested in future or time-based values or > Clients implementing [RFC7285 > <https://www.rfc-editor.org/rfc/rfc8896.html#RFC7285>] only. > > > > then in Sec 4.3 there are fictitious examples of string Cost Modes, etc. > > > > I'm not sure that any of that is helpful, but RFC8896 is at least a worked > example of delivering an array of costs without coining a new Cost Mode. > Unfortunately, this is an array of strings, not an array of numericals or > ordinals. > > > > I'm not sure I see a way forward other than a short new PS draft that > updates 7285 and creates a Cost Mode registry. Other ideas? > > > > > > > > > > > > On Thu, Mar 3, 2022 at 9:51 AM <kai...@scu.edu.cn> wrote: > > Hi Ben, > > Thanks a lot for the review. The comments are really helpful. We have > proposed texts for most of the comments except for calculating > content-lengths and the security-related comments, which we will come up > with some proposal tomorrow. Please see our feedback inline. > > Best, > Kai > > > > -----Original Messages----- > > From: "Benjamin Kaduk via Datatracker" <nore...@ietf.org> > > Sent Time: 2022-03-03 17:53:16 (Thursday) > > To: "The IESG" <i...@ietf.org> > > Cc: alto-cha...@ietf.org, draft-ietf-alto-path-vec...@ietf.org, > alto@ietf.org > > Subject: [alto] Benjamin Kaduk's Discuss on > draft-ietf-alto-path-vector-22: (with DISCUSS and COMMENT) > > > > Benjamin Kaduk has entered the following ballot position for > > draft-ietf-alto-path-vector-22: Discuss > > > > When responding, please keep the subject line intact and reply to all > > email addresses included in the To and CC lines. (Feel free to cut > this > > introductory paragraph, however.) > > > > > > Please refer to > https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ > > for more information about how to handle DISCUSS and COMMENT > positions. > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-alto-path-vector/ > > <https://datatracker.ietf.org/doc/draft-ietf-alto-path-vector/>>; > > > > > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > The IANA Considerations section seems incomplete. > > Looking over the registries at > > https://www.iana.org/assignments/alto-protocol/alto-protocol.xhtml > and > > comparing against the mechanisms defined in this document, it seems > that > > we need to register the "ane-path" Cost Metric. > > Thanks for pointing that out. We will add a new section to register the > cost metric. > > > More worryingly, there is > > no registry on that page in which the "array" cost mode could be > > registered, and it seems that using any value other than "numerical" > or > > "ordinal" would violate a "MUST" in §10.5 of RFC 7285. This seems to > > present some procedural difficulties, especially now that this > document is > > targeting Experimental status rather than Proposed Standard (which, > to be > > clear, I think was the right thing to do). > > Indeed this is a big issue. As it also doesn't make sense if we use either > ordinal or numerical as the cost mode, we cannot fall back to what is > compatible with RFC 7285. Here is what we have in mind: first we make it > clear that the new cost mode will violate RFC 7285; second, we restrict the > use of the cost mode to only the ALTO information resources that enable > this extension. Here is the proposed text: > > Note that the new cost mode violates the requirements that cost mode > MUST either > be "numerical" or "ordinal" in Section 10.5 of {{RFC7285}}. To avoid > compatibility issues, an ALTO server MUST NOT use this cost mode in an > ALTO > information resource that does not enable this extension. > > > > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > Thanks for fleshing out the security considerations section > substantially > > in recent revisions, and thanks to Sam Weiler for the multiple secdir > > reviews. While I agree with Sam that it would be nice to be able to > list > > examples of non-DRM technical measures to protect the confidentiality > of > > sensitive path vector information, I can't actually think of any that > > would be worth listing, myself. So we may have to proceed with the > > current text (unless you have further ideas, of course). > > > > It looks like the VersionTag.tag value of > "d827f484cb66ce6df6b5077cb8562b0a" > > is used in a few different examples. While being associated with > > different VersionTag.ResourceID values is sufficient to distinguish > the > > uses from each other, it seems like these examples might be more > > enlightening if distinct VersionTag.tag values were used for the > distinct > > resources. > > Very good suggestion. We will use different version tags in different > examples. > > > > > Section 1 > > > > Predicting such information can be very complex without the help of > > ISPs [BOXOPT]. [...] > > > > I'm not entirely sure which part(s) of [BOXOPT] are being referenced > here. > > Their scheme seems to involve producing a privacy-preserving scheme > for > > resource allocation that does involve exchnages between client and > > network, just not ones that reveal sensitive information. Did I miss > a > > part where they compare against a scenario where the network/ISP does > not > > provide input? (I only skimmed the paper.) > > The paper is mainly referenced because of its analysis on the NP-hardness > of predicting the values without the help of ISPs (in the introduction). > How about we use the following text to make it clear? > > Predicting such information can be very complex without the help of > ISPs, for example, [BOXOPT] has shown that finding the optimal > bandwidth reservation for multiple flows is NP-hard without > further information than whether a reservation succeeds. > > > > > Section 4.1 > > > > * The ALTO server must expose abstract information on the > properties > > of the ANEs used by "eh1 -> eh2" and "eh1 -> eh4", e.g., > the > > available bandwidth between "eh1 - sw1", "sw1 - sw5", "sw5 - > sw7", > > "sw5 - sw6", "sw6 - sw7", "sw7 - sw2", "sw7 - sw4", "sw2 - eh2", > > "sw4 - eh4" in Case 1. > > > > Does it actually need to expose exactly the available bandwidth > between > > all those listed pairs of entities? I would have thought that some > of the > > details could be abstracted away. > > Not really. Actually for this use case the information can be abstracted > as linear constraints. Maybe we should make this more explicit by adding > the following text: > > * The ALTO server must expose abstract information on the properties > of the ANEs used by "eh1 -> eh2" and "eh1 -> eh4". For > example, > an ALTO server can either expose the available bandwidth between > "eh1 - sw1", "sw1 - sw5", "sw5 - sw7", "sw5 - sw6", "sw6 - sw7", > "sw7 - sw2", "sw7 - sw4", "sw2 - eh2", "sw4 - eh4" in Case 1, or > expose 3 abstract elements "A", "B" and "C", which represent the > linear constraints that define the same capacity region in Case 1. > > > > > Section 4.2.1 > > > > For example, assume hosts "a", > "b", > > "c" are in site 1 and hosts "d", "e", "f" are in site 2, and there > > > > In Figure 5, I see something that looks like an entry for [d] in the > "Site > > 1" part, and an entry for [c] in the "Site 2" part. I'm not sure if > > that's just an attempt to indicate the directionality of the core > backbone > > or something else. > > Yes. The figure is trying to illustrate a flow across sites from host [c] > to host [d]. The reason why [d] is shown in Site 1 is to illustrate that > the traffic to [d] goes to the backbone in Site 1's network. > > > > > Section 6.4 > > > > Note that these property types do not depend on any information > > resource. As such, their ResourceID part must be empty. > > > > Does this mean that the '.' is absent as well? > > > > Yes, indeed. We will make this clear with the following text: > > Note that these property types do not depend on any information > resource. As such, the EntityPropertyName MUST only have the > EntityPropertyType part. > > > Section 6.5.2 > > > > Note that this cost mode only requires the cost value to be a JSON > > array of JSONValue. However, an ALTO server that enables this > > extension MUST return a JSON array of ANEName (Section 6.1) when > the > > cost metric is "ane-path". > > > > If we're going to require that the cost mode "array" only be used > with an > > array of ANEName, then would it make more sense to call the cost mode > > "anearray", leaving the generic "array" for a more generic behavior? > > > > This design is actually discussed in early versions of this document. See > [1]. The main point is that "cost-mode" is the type of the value and > "cost-metric" is the meaning of the value. I think maybe we can put this as > a constraint to the cost metric instead of the cost mode, as proposed below: > > [1] > https://datatracker.ietf.org/doc/html/draft-ietf-alto-path-vector-02#section-4.1.3 > > This cost metric MUST be used when the cost mode is "array" unless > explicitly specified by another extension. An ALTO server MUST > ensure the returned cost value is an array of ANENames. The client > MUST also check that each element contained in the array is an > ANEName (Section 6.1). Otherwise, the client MUST discard the > response and SHOULD follow the instructions in Section 8.3.4.3 of > [RFC7285] to handle the error. > > > Section 6.6 > > > > DOMAIN-NAME: DOMAIN-NAME has the same format as dot-atom-text > > specified in Section 3.2.3 of [RFC5322]. It must be the domain > > name of the ALTO server. > > > > (somewhat editorial) is there always exactly one domain name of the > ALTO > > server (vs. more than one)? > > > > Yes. I think so. In the IRD, each ALTO service is associated with exactly > one uri and hence has a unique domain name. > > > Section 7.2.4 > > > > object { > > [EntityPropertyName ane-property-names<0..*>;] > > } PVFilteredCostMapCapabilities : FilteredCostMapCapabilities; > > > > with fields: > > > > Up in §7.2.3 we didn't repeat any of the fields from the base type we > > inherited from. Here we do, but (apparently) only because we have > more to > > say about them, e.g., new restrictions on the cost-type-names field to > > include the Path Vector cost type. Do we want to mention that some > fields > > are repeated because we make their definiton more specific for the > > PVFilteredCostMapCapabilities usage? > > Very good suggestion. We intend to put the new field after "with fields" > and then insert a sentence to explicitly say that the others have specific > restrictions. Here is the proposed text: > > > ane-property-names: ... > > This extension also introduces additional restrictions for the > following fields: > > cost-type-names: ... > cost-constraints: ... > > > > > Also, since we're repeating most of the FilteredCostMapCapabilities > > fields, is it worth also defining max-cost-types for completeness? > > This extension does not need modification to the max-cost-types field. > With the proposed change to the previous comment, maybe we can skip > max-cost-types? > > > > > Section 7.2.6 > > > > The "Content-Type" header of the response MUST be > "multipart/related" > > as defined by [RFC2387] with the following parameters: > > > > This could be read as saying that all three parameters are mandatory, > but > > the actual description for "start" includes the phrase "if present", > > implying that it is optional. Some more clarity would be helpful > > (especially relating to whether "boundary" is optional or mandatory, > which > > RFC 2387 itself does not actually clarify directly). > > Good point. We explicitly specify for each parameter whether it is > mandatory or optional. For example: > > start: The start parameter is as defined in [RFC2387] and is > optional. > > boundary: The boundary parameter is as defined in [RFC2387] and is > mandatory. > > > > > * The Path Vector part MUST include "Content-ID" and > "Content-Type" > > [...] > > RESOURCE-ID in the "Content-ID" of the Path Vector part. The > > "meta" field MUST also include the "dependent-vtags" field, > whose > > value is a single-element array to indicate the version tag of > the > > network map used, where the network map is specified in the > "uses" > > attribute of the multipart Filtered Cost Map resource in IRD. > > > > Just to confirm, there would not be a need to include in this > > "dependent-vtags" field any dependent resources relating to persistent > > ANEs? > > The vtags of dependent resources are used by the property map part and > here it's for the Path Vector part (which is essentially an ALTO cost map). > Thus, the interpretation of the Path Vector part only depends on the > network map. > > > > Vector part MUST be included in the "dependent-vtags". If > > "persistent-entity-id" is requested, the version tags of the > > dependent resources that MAY expose the entities in the response > > MUST also be included. > > > > This seems a surprising use of the normative MAY, to me. > > Thanks for pointing this out. This should not be a normative MAY. > > > > > HTTP/1.1 200 OK > > Content-Length: 821 > > Content-Type: multipart/related; boundary=example-1; > > > > I'm having a hard time reproducing this Content-Length value. Could > you > > double-check it? > > > Thanks for the comment. I save the examples and use curl to calculate the > value. The new value is 859. > > > Section 7.3.3 > > > > POST /ecs/pv HTTP/1.1 > > Host: alto.example.com > > Accept: multipart/related;type=application/alto-endpointcost+json, > > application/alto-error+json > > Content-Length: 222 > > > > I'm getting a length of 226 or 227 (depending on newline at end of > file); > > please confirm that 222 is correct. > > > The new calculated value is 227. > > > Section 7.3.6 > > > > boundary: The boundary parameter is as defined in [RFC2387]. > > > > As I alluded to above, the boundary parameter is actually defined in > RFC > > 2045; the only appearance in RFC 2387 is in two examples. > > Thanks for the pointer. I checked RFC 2045 and see it actually refers to > RFC 2046 (section 5.1.1) for the format of boundary. How about we use RFC > 2046 instead? > > > > > The body of the Path Vector part MUST be a JSON object with the > > same format as defined in Section 11.5.1.6 of [RFC7285] when the > > "cost-type" field is present in the input parameters and MUST > be a > > JSON object with the same format as defined in Section 4.1.3 of > > [RFC8189] if the "multi-cost-types" field is present. The JSON > > > > I think §4.2.3 of RFC 8189 is somewhat more relevant than §4.1.3, > here. > > Yes indeed. We will change 4.1.3 to 4.2.3. > > > > > The body of the Unified Property Map part MUST be a JSON object > > with the same format as defined in Section 4.6 of > > [I-D.ietf-alto-unified-props-new]. [...] > > > > Is §4.6 the right reference here? I don't see much defining a JSON > format > > in that section or subsections. > > Thanks for pointing that out. It should be section 7.6 now. > > > > > Vector part MUST be included in the "dependent-vtags". If > > "persistent-entity-id" is requested, the version tags of the > > dependent resources that MAY expose the entities in the response > > MUST also be included. > > > > As above, this is an unusual use of the normative "MAY". > > We will change it to "may". > > > > > HTTP/1.1 200 OK > > Content-Length: 810 > > Content-Type: multipart/related; boundary=example-1; > > type=application/alto-endpointcost+json > > > > Continuing the theme, please check this Content-Length as well. > > The new calculated value is 845 and we will check the content-length for > all examples in the document. > > > > > Section 8.4 > > > > As mentioned in Section 6.5.1, an advanced ALTO server may > obfuscate > > the response in order to preserve its own privacy or conform to its > > own policies. [...] > > > > Is §6.5.1 the correct reference? The word "obfuscate" does not appear > > therein that I can see. > > Thanks for pointing that out. There was a paragraph in early revisions on > obfuscation in 6.5.1 but was later moved into security considerations. Here > is the proposed text: > > Under certain scenarios where the traversal order is not crucial, an > ALTO server implementation may choose to not follow strictly the > physical traversal order and may even obfuscate the order > intentionally to preserve its own privacy or conform to its own > policies. > > > > > Section 8.5 > > > > Is there anything to say about updates needing to be paired in the > same > > way/for the same reasons we have to use multipart/related to get a > > consistent picture of the path vector cost map and its associated ANE > > property map? Or perhaps in §9.3 instead? > > > > Thanks for the comment. We feel 9.3 is more appropriate and below is the > proposed text: > > Additionally, the incremental updates of the Path > Vector part and the Property Map part MUST be published separately, > where the substream ID of each part MUST have the following format: > > substream-id '.' part-resource-id > > where "substream-id" is the substream ID of the Path Vector request > (e.g., "ecspvsub1" in Section 8.5) and "part-resource-id" is the Part > resource ID (e.g., "ecsmap" for the Path Vector part and "propmap" > for the Property Map part in Section 8.5). > > > Section 8.6 > > > > The second part is the same as in Section 8.4 > > > > It seems only analogous, not "the same as", to me -- this example uses > > aggregated ANEs but §8.3 used the full topology of Figure 10. > > The second part is actually the same as the second (obfuscated) example in > Section 8.4. However, to avoid ambiguity, we propose to use the following > text instead: > > The second part contains a Property Map that maps the ANEs to their > requested properties. > > > > > "endpoint-cost-map": { > > "ipv4:192.0.2.34": { > > "ipv4:192.0.2.2": [[ "NET3", "AGGR1" ], 1], > > "ipv4:192.0.2.50": [[ "NET3", "AGGR2" ], 1] > > }, > > "ipv6:2001:db8::3:1": { > > "ipv6:2001:db8::4:1": [[ "NET3", "AGGR2" ], 1] > > > > Is it really plausible to use the same routing cost of 1 for all three > > paths? > > > We use different routing cost values as below: > > "endpoint-cost-map": { > "ipv4:192.0.2.34": { > "ipv4:192.0.2.2": [[ "NET3", "AGGR1" ], 3], > "ipv4:192.0.2.50": [[ "NET3", "AGGR2" ], 2] > }, > "ipv6:2001:db8::3:1": { > "ipv6:2001:db8::4:1": [[ "NET3", "AGGR2" ], 2] > > > Section 11 > > > > Streaming updates of max-reservable-bandwidth seems to provide > basically > > an equivalent information stream as to what paths have been reserved > (and > > their bandwidth). That information might be differently sensitive > than > > the primary network information we're exposing with the path-vector > > methodology, so we should probably mention this "information leakage" > > channel and give some guidance about what server behaviors might > mitigate > > the leakage (e.g., batching updates, though I suspect that the policy > for > > doing so in a way that minimizes information leakage will be about as > hard > > a problem to solve as padding policies are in general). > > True if the server is returning all physical links on the paths. However, > a major point of introducing (ephemeral) abstract network element is trying > to hide such information. For example, with the obfuscation methods (e.g., > only returning the linear constraints), only the "bottlenecks" will be > revealed and their orders can be arbitrary. We did say in section 11 that > these obfuscation methods should be considered/adopted (e.g., reference > [NOVA]), though. Do you think we should make this more specific for the > "max-reservable-bandwidth" property? > > > > > I'm a little surprised that we didn't mention anything about > persistent > > ANEs here (which would be a great way to contrast with the obfuscation > > that ephemeral ANEs provide). > > Good point. We will think about this and propose some new text soon. > > > > > MIME parsers have historically been a recurring source of > > security-relevant bugs in other contexts. Perhaps that's sufficiently > > well known to not need restating here, though. > > > > For risk type (3), an ALTO server MUST use dynamic mappings from > > ephemeral ANE names to underlying physical entities. Thus, ANE > names > > contained in the Path Vector responses to different clients or even > > for different request from the same client SHOULD point to > different > > physical entities. [...] > > > > The guidance of "SHOULD point to different physical entities" doesn't > seem > > quite right. If the ANE abstraction actually attempted to maximize > the > > number of distinct physical entities represented, that seems lke it > would > > make graph reconstruction easier, rather than harder. Perhaps it is > > better to give guidance about noncorrelation over time of the ANE > > name/physical element mapping, or even guidance to just use > randomized ANE > > names. > > > > The sentence is trying to say that the same ANEName (e.g., ane1) should > not point to the same entity. We agree the guidance might be misleading and > the randomized ANE names can be a good option. We will propose the new text > soon. > > > Section 13.1 > > > > I don't think RFC 4271 needs to be classified as normative; we seem to > > only reference it as an analogy for the Path Vector/AS Path. > > Good point. We will make it informative. > > > > > Section 13.2 > > > > [BOXOPT] Xiang, Q., Yu, H., Aspnes, J., Le, F., Kong, L., and > Y.R. > > Yang, "Optimizing in the dark: Learning an optimal > > solution through a simple request interface", > Proceedings > > of the AAAI Conference on Artificial Intelligence 33, > > 1674-1681 , 2019. > > > > It looks like this is https://doi.org/10.1609/aaai.v33i01.33011674 ; > if > > so, including the DOI link would be very helpful for readers. > > > > That's just the one I happend to go pull up; DOIs for the other > papers (if > > available) should be included, too. > > OK. We will add the DOI link for each academic paper. > > > > > NITS > > > > Section 1 > > > > Map that contains the properties requested for these ANEs. To > > enforce consistency and improve server scalability, this document > > uses the "multipart/related" message defined in [RFC2387] to return > > the two maps in a single response. > > > > I think it's more typical to say "content type" than "message" in this > > context. > > We will modify as suggested. > > > > Section 3 > > > > performance of traffic. An ANE can be a physical device such > as a > > router, a link or an interface, or an aggregation of devices > such > > as a subnetwork, or a data center. > > > > I think we do not want a comma before "or a data center", since the > data > > center is just another example of an aggregation of devices. > > > We will modify as suggested. > > > Section 4.1 > > > > performance. The capacity region information for those flows will > > benefit the scheduling. However, Cost Maps as defined in [RFC7285] > > can not reveal such information. > > > > I'm not sure I know what "capacity region information" is; did we mean > > "region capacity information" (or maybe "Knowledge of the relevant > > capacity regions for those flows")? > > We change the term to "constraints on feasible rate allocations of those > flows" which may be clearer. > > > > > With the ALTO Cost Map, the cost between PID1 and PID2 and between > > PID1 and PID4 will be 100 Mbps. The client can get a capacity > region > > > > I'd suggest "will both be". > > We will modify as suggested. > > > > Section 4.2.1 > > > > With the Path Vector extension, a site can reveal the bottlenecks > > inside its own network with necessary information (such as link > > capacities) to the ALTO client, instead of providing the full > > topology and routing information. [...] > > > > I'd suggest adding "or no bottleneck information at all". > > > We will modify as suggested. > > > Section 4.2.2 > > > > in various documents (e.g., [SEREDGE] and [MOWIE]). Internet > Service > > Providers may deploy multiple layers of CDN caches, or more > generally > > service edges, with different latency and available resources > > including number of CPU cores, memory in Gigabytes (G), and storage > > measured in Terabytes (T). > > > > The units are probably not relevant for the abstract scenario, and > would > > only become relevant when we start introducing Figure 6 as a specific > > instantiation of the multi-layer model. > > > > We propose the following text: > > ... Internet Service > Providers may deploy multiple layers of CDN caches, or more generally > service edges, with different latency and available resources > including number of CPU cores, memory, and storage. > > For example, Figure 6 illustrates a typical edge-cloud scenario where > memory is measured in Gigabytes (G) and storage is measured in > Terabytes (T). > > > Section 5.1.3 > > > > Specifically, the available properties for a given resource are > > announced in the Information Resource Directory as a new capability > > called "ane-property-names". The selected properties are specified > > in a filter called "ane-property-names" in the request body, and > the > > response includes and only includes the selected properties for the > > ANEs in the response. > > > > Going from the first to second sentence, we switch from using the > string > > "ane-property-names" to refer to the available properties announced > in the > > IRD, to using it to refer to the properties that a client supplies in > a > > path vector query for use in filtering the response results. To help > the > > reader make this transition smoothly, I suggest rephrasing the > transition, > > perhaps to something like "The properties selected by a client as > being of > > interest are specified in the subsequent Path Vector queries using the > > filter called 'ane-property-names'." > > > Good point. We will modify as suggested. > > > Section 5.3 > > > > 1. Since ANEs may be constructed on demand, and potentially based > on > > the requested properties (See Section 5.1 for more details). > If > > > > Incomplete sentence. > > > We will remove "Since". > > > Section 6.2.4 > > > > multipart response. Meanwhile, for persistent ANEs whose entity > > domain name has the format of "PROPMAP.ane" where PROPMAP is the > name > > of a Property Map resource, PROPMAP is the defining resource of > these > > > > Is it better to say "name" of "ResourceID"? > > We propose to change the "name" to "resource ID". > > > > > > > > _______________________________________________ > > alto mailing list > > alto@ietf.org > > https://www.ietf.org/mailman/listinfo/alto > </i...@ietf.org></nore...@ietf.org> > >
_______________________________________________ alto mailing list alto@ietf.org https://www.ietf.org/mailman/listinfo/alto