Re: [alto] Benjamin Kaduk's Discuss on draft-ietf-alto-path-vector-22: (with DISCUSS and COMMENT)

[Martin Duke <[e-mail]>]

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 <[e-mail]> 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
>
> *发件人:* [e-mail] [mailto:[e-mail]]
> *发送时间:* 2022年3月4日 15:24
> *收件人:* Martin Duke <[e-mail]>
> *抄送:* Benjamin Kaduk <[e-mail]>; IETF ALTO <[e-mail]>;
> alto-chairs <[e-mail]>; The IESG <[e-mail]>;
> [e-mail]
> *主题:* 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" <[e-mail]>
> *Sent Time:*2022-03-04 04:25:37 (Friday)
> *To:* "Kai Gao" <[e-mail]>
> *Cc:* "Benjamin Kaduk" <[e-mail]>, "IETF ALTO" <[e-mail]>,
> alto-chairs <[e-mail]>, "The IESG" <[e-mail]>,
> [e-mail]
> *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 <[e-mail]> 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
>
>
> &gt; -----Original Messages-----
> &gt; From: "Benjamin Kaduk via Datatracker" <[e-mail]>
> &gt; Sent Time: 2022-03-03 17:53:16 (Thursday)
> &gt; To: "The IESG" <[e-mail]>
> &gt; Cc: [e-mail], [e-mail],
> [e-mail]
> &gt; Subject: [alto] Benjamin Kaduk's Discuss on
> draft-ietf-alto-path-vector-22: (with DISCUSS and COMMENT)
> &gt;
> &gt; Benjamin Kaduk has entered the following ballot position for
> &gt; draft-ietf-alto-path-vector-22: Discuss
> &gt;
> &gt; When responding, please keep the subject line intact and reply to all
> &gt; email addresses included in the To and CC lines. (Feel free to cut
> this
> &gt; introductory paragraph, however.)
> &gt;
> &gt;
> &gt; Please refer to
> https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
> &gt; for more information about how to handle DISCUSS and COMMENT
> positions.
> &gt;
> &gt;
> &gt; The document, along with other ballot positions, can be found here:
> &gt; https://datatracker.ietf.org/doc/draft-ietf-alto-path-vector/
> &gt <https://datatracker.ietf.org/doc/draft-ietf-alto-path-vector/&gt>;
> &gt;
> &gt;
> &gt; ----------------------------------------------------------------------
> &gt; DISCUSS:
> &gt; ----------------------------------------------------------------------
> &gt;
> &gt; The IANA Considerations section seems incomplete.
> &gt; Looking over the registries at
> &gt; https://www.iana.org/assignments/alto-protocol/alto-protocol.xhtml
> and
> &gt; comparing against the mechanisms defined in this document, it seems
> that
> &gt; 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.
>
> &gt; More worryingly, there is
> &gt; no registry on that page in which the "array" cost mode could be
> &gt; registered, and it seems that using any value other than "numerical"
> or
> &gt; "ordinal" would violate a "MUST" in §10.5 of RFC 7285.  This seems to
> &gt; present some procedural difficulties, especially now that this
> document is
> &gt; targeting Experimental status rather than Proposed Standard (which,
> to be
> &gt; 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.
>
> &gt;
> &gt;
> &gt; ----------------------------------------------------------------------
> &gt; COMMENT:
> &gt; ----------------------------------------------------------------------
> &gt;
> &gt; Thanks for fleshing out the security considerations section
> substantially
> &gt; in recent revisions, and thanks to Sam Weiler for the multiple secdir
> &gt; reviews.  While I agree with Sam that it would be nice to be able to
> list
> &gt; examples of non-DRM technical measures to protect the confidentiality
> of
> &gt; sensitive path vector information, I can't actually think of any that
> &gt; would be worth listing, myself.  So we may have to proceed with the
> &gt; current text (unless you have further ideas, of course).
> &gt;
> &gt; It looks like the VersionTag.tag value of
> "d827f484cb66ce6df6b5077cb8562b0a"
> &gt; is used in a few different examples.  While being associated with
> &gt; different VersionTag.ResourceID values is sufficient to distinguish
> the
> &gt; uses from each other, it seems like these examples might be more
> &gt; enlightening if distinct VersionTag.tag values were used for the
> distinct
> &gt; resources.
>
> Very good suggestion. We will use different version tags in different
> examples.
>
> &gt;
> &gt; Section 1
> &gt;
> &gt;    Predicting such information can be very complex without the help of
> &gt;    ISPs [BOXOPT].  [...]
> &gt;
> &gt; I'm not entirely sure which part(s) of [BOXOPT] are being referenced
> here.
> &gt; Their scheme seems to involve producing a privacy-preserving scheme
> for
> &gt; resource allocation that does involve exchnages between client and
> &gt; network, just not ones that reveal sensitive information.  Did I miss
> a
> &gt; part where they compare against a scenario where the network/ISP does
> not
> &gt; 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.
>
> &gt;
> &gt; Section 4.1
> &gt;
> &gt;    *  The ALTO server must expose abstract information on the
> properties
> &gt;       of the ANEs used by "eh1 -&gt; eh2" and "eh1 -&gt; eh4", e.g.,
> the
> &gt;       available bandwidth between "eh1 - sw1", "sw1 - sw5", "sw5 -
> sw7",
> &gt;       "sw5 - sw6", "sw6 - sw7", "sw7 - sw2", "sw7 - sw4", "sw2 - eh2",
> &gt;       "sw4 - eh4" in Case 1.
> &gt;
> &gt; Does it actually need to expose exactly the available bandwidth
> between
> &gt; all those listed pairs of entities?  I would have thought that some
> of the
> &gt; 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 -&gt; eh2" and "eh1 -&gt; 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.
>
> &gt;
> &gt; Section 4.2.1
> &gt;
> &gt;                                     For example, assume hosts "a",
> "b",
> &gt;    "c" are in site 1 and hosts "d", "e", "f" are in site 2, and there
> &gt;
> &gt; In Figure 5, I see something that looks like an entry for [d] in the
> "Site
> &gt; 1" part, and an entry for [c] in the "Site 2" part.  I'm not sure if
> &gt; that's just an attempt to indicate the directionality of the core
> backbone
> &gt; 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.
>
> &gt;
> &gt; Section 6.4
> &gt;
> &gt;    Note that these property types do not depend on any information
> &gt;    resource.  As such, their ResourceID part must be empty.
> &gt;
> &gt; Does this mean that the '.' is absent as well?
> &gt;
>
> 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.
>
> &gt; Section 6.5.2
> &gt;
> &gt;    Note that this cost mode only requires the cost value to be a JSON
> &gt;    array of JSONValue.  However, an ALTO server that enables this
> &gt;    extension MUST return a JSON array of ANEName (Section 6.1) when
> the
> &gt;    cost metric is "ane-path".
> &gt;
> &gt; If we're going to require that the cost mode "array" only be used
> with an
> &gt; array of ANEName, then would it make more sense to call the cost mode
> &gt; "anearray", leaving the generic "array" for a more generic behavior?
> &gt;
>
> 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.
>
> &gt; Section 6.6
> &gt;
> &gt;    DOMAIN-NAME:  DOMAIN-NAME has the same format as dot-atom-text
> &gt;       specified in Section 3.2.3 of [RFC5322].  It must be the domain
> &gt;       name of the ALTO server.
> &gt;
> &gt; (somewhat editorial) is there always exactly one domain name of the
> ALTO
> &gt; server (vs. more than one)?
> &gt;
>
> Yes. I think so. In the IRD, each ALTO service is associated with exactly
> one uri and hence has a unique domain name.
>
> &gt; Section 7.2.4
> &gt;
> &gt;    object {
> &gt;      [EntityPropertyName ane-property-names&lt;0..*&gt;;]
> &gt;    } PVFilteredCostMapCapabilities : FilteredCostMapCapabilities;
> &gt;
> &gt;    with fields:
> &gt;
> &gt; Up in §7.2.3 we didn't repeat any of the fields from the base type we
> &gt; inherited from.  Here we do, but (apparently) only because we have
> more to
> &gt; say about them, e.g., new restrictions on the cost-type-names field to
> &gt; include the Path Vector cost type.  Do we want to mention that some
> fields
> &gt; are repeated because we make their definiton more specific for the
> &gt; 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: ...
>
> &gt;
> &gt; Also, since we're repeating most of the FilteredCostMapCapabilities
> &gt; 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?
>
> &gt;
> &gt; Section 7.2.6
> &gt;
> &gt;    The "Content-Type" header of the response MUST be
> "multipart/related"
> &gt;    as defined by [RFC2387] with the following parameters:
> &gt;
> &gt; This could be read as saying that all three parameters are mandatory,
> but
> &gt; the actual description for "start" includes the phrase "if present",
> &gt; implying that it is optional.  Some more clarity would be helpful
> &gt; (especially relating to whether "boundary" is optional or mandatory,
> which
> &gt; 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.
>
> &gt;
> &gt;    *  The Path Vector part MUST include "Content-ID" and
> "Content-Type"
> &gt;       [...]
> &gt;       RESOURCE-ID in the "Content-ID" of the Path Vector part.  The
> &gt;       "meta" field MUST also include the "dependent-vtags" field,
> whose
> &gt;       value is a single-element array to indicate the version tag of
> the
> &gt;       network map used, where the network map is specified in the
> "uses"
> &gt;       attribute of the multipart Filtered Cost Map resource in IRD.
> &gt;
> &gt; Just to confirm, there would not be a need to include in this
> &gt; "dependent-vtags" field any dependent resources relating to persistent
> &gt; 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.
> &gt;
> &gt;       Vector part MUST be included in the "dependent-vtags".  If
> &gt;       "persistent-entity-id" is requested, the version tags of the
> &gt;       dependent resources that MAY expose the entities in the response
> &gt;       MUST also be included.
> &gt;
> &gt; This seems a surprising use of the normative MAY, to me.
>
> Thanks for pointing this out. This should not be a normative MAY.
>
> &gt;
> &gt;    HTTP/1.1 200 OK
> &gt;    Content-Length: 821
> &gt;    Content-Type: multipart/related; boundary=example-1;
> &gt;
> &gt; I'm having a hard time reproducing this Content-Length value.  Could
> you
> &gt; double-check it?
> &gt;
> Thanks for the comment. I save the examples and use curl to calculate the
> value. The new value is 859.
>
> &gt; Section 7.3.3
> &gt;
> &gt;    POST /ecs/pv HTTP/1.1
> &gt;    Host: alto.example.com
> &gt;    Accept: multipart/related;type=application/alto-endpointcost+json,
> &gt;            application/alto-error+json
> &gt;    Content-Length: 222
> &gt;
> &gt; I'm getting a length of 226 or 227 (depending on newline at end of
> file);
> &gt; please confirm that 222 is correct.
> &gt;
> The new calculated value is 227.
>
> &gt; Section 7.3.6
> &gt;
> &gt;    boundary:  The boundary parameter is as defined in [RFC2387].
> &gt;
> &gt; As I alluded to above, the boundary parameter is actually defined in
> RFC
> &gt; 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?
>
> &gt;
> &gt;       The body of the Path Vector part MUST be a JSON object with the
> &gt;       same format as defined in Section 11.5.1.6 of [RFC7285] when the
> &gt;       "cost-type" field is present in the input parameters and MUST
> be a
> &gt;       JSON object with the same format as defined in Section 4.1.3 of
> &gt;       [RFC8189] if the "multi-cost-types" field is present.  The JSON
> &gt;
> &gt; 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.
>
> &gt;
> &gt;       The body of the Unified Property Map part MUST be a JSON object
> &gt;       with the same format as defined in Section 4.6 of
> &gt;       [I-D.ietf-alto-unified-props-new].  [...]
> &gt;
> &gt; Is §4.6 the right reference here?  I don't see much defining a JSON
> format
> &gt; in that section or subsections.
>
> Thanks for pointing that out. It should be section 7.6 now.
>
> &gt;
> &gt;       Vector part MUST be included in the "dependent-vtags".  If
> &gt;       "persistent-entity-id" is requested, the version tags of the
> &gt;       dependent resources that MAY expose the entities in the response
> &gt;       MUST also be included.
> &gt;
> &gt; As above, this is an unusual use of the normative "MAY".
>
> We will change it to "may".
>
> &gt;
> &gt;    HTTP/1.1 200 OK
> &gt;    Content-Length: 810
> &gt;    Content-Type: multipart/related; boundary=example-1;
> &gt;                  type=application/alto-endpointcost+json
> &gt;
> &gt; 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.
>
> &gt;
> &gt; Section 8.4
> &gt;
> &gt;    As mentioned in Section 6.5.1, an advanced ALTO server may
> obfuscate
> &gt;    the response in order to preserve its own privacy or conform to its
> &gt;    own policies.  [...]
> &gt;
> &gt; Is §6.5.1 the correct reference?  The word "obfuscate" does not appear
> &gt; 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.
>
> &gt;
> &gt; Section 8.5
> &gt;
> &gt; Is there anything to say about updates needing to be paired in the
> same
> &gt; way/for the same reasons we have to use multipart/related to get a
> &gt; consistent picture of the path vector cost map and its associated ANE
> &gt; property map?  Or perhaps in §9.3 instead?
> &gt;
>
> 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).
>
> &gt; Section 8.6
> &gt;
> &gt;    The second part is the same as in Section 8.4
> &gt;
> &gt; It seems only analogous, not "the same as", to me -- this example uses
> &gt; 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.
>
> &gt;
> &gt;      "endpoint-cost-map": {
> &gt;        "ipv4:192.0.2.34": {
> &gt;          "ipv4:192.0.2.2":   [[ "NET3", "AGGR1" ], 1],
> &gt;          "ipv4:192.0.2.50":   [[ "NET3", "AGGR2" ], 1]
> &gt;        },
> &gt;        "ipv6:2001:db8::3:1": {
> &gt;          "ipv6:2001:db8::4:1": [[ "NET3", "AGGR2" ], 1]
> &gt;
> &gt; Is it really plausible to use the same routing cost of 1 for all three
> &gt; paths?
> &gt;
> 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]
>
> &gt; Section 11
> &gt;
> &gt; Streaming updates of max-reservable-bandwidth seems to provide
> basically
> &gt; an equivalent information stream as to what paths have been reserved
> (and
> &gt; their bandwidth).  That information might be differently sensitive
> than
> &gt; the primary network information we're exposing with the path-vector
> &gt; methodology, so we should probably mention this "information leakage"
> &gt; channel and give some guidance about what server behaviors might
> mitigate
> &gt; the leakage (e.g., batching updates, though I suspect that the policy
> for
> &gt; doing so in a way that minimizes information leakage will be about as
> hard
> &gt; 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?
>
> &gt;
> &gt; I'm a little surprised that we didn't mention anything about
> persistent
> &gt; ANEs here (which would be a great way to contrast with the obfuscation
> &gt; that ephemeral ANEs provide).
>
> Good point. We will think about this and propose some new text soon.
>
> &gt;
> &gt; MIME parsers have historically been a recurring source of
> &gt; security-relevant bugs in other contexts.  Perhaps that's sufficiently
> &gt; well known to not need restating here, though.
> &gt;
> &gt;    For risk type (3), an ALTO server MUST use dynamic mappings from
> &gt;    ephemeral ANE names to underlying physical entities.  Thus, ANE
> names
> &gt;    contained in the Path Vector responses to different clients or even
> &gt;    for different request from the same client SHOULD point to
> different
> &gt;    physical entities.  [...]
> &gt;
> &gt; The guidance of "SHOULD point to different physical entities" doesn't
> seem
> &gt; quite right.  If the ANE abstraction actually attempted to maximize
> the
> &gt; number of distinct physical entities represented, that seems lke it
> would
> &gt; make graph reconstruction easier, rather than harder.  Perhaps it is
> &gt; better to give guidance about noncorrelation over time of the ANE
> &gt; name/physical element mapping, or even guidance to just use
> randomized ANE
> &gt; names.
> &gt;
>
> 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.
>
> &gt; Section 13.1
> &gt;
> &gt; I don't think RFC 4271 needs to be classified as normative; we seem to
> &gt; only reference it as an analogy for the Path Vector/AS Path.
>
> Good point. We will make it informative.
>
> &gt;
> &gt; Section 13.2
> &gt;
> &gt;    [BOXOPT]   Xiang, Q., Yu, H., Aspnes, J., Le, F., Kong, L., and
> Y.R.
> &gt;               Yang, "Optimizing in the dark: Learning an optimal
> &gt;               solution through a simple request interface",
> Proceedings
> &gt;               of the AAAI Conference on Artificial Intelligence 33,
> &gt;               1674-1681 , 2019.
> &gt;
> &gt; It looks like this is https://doi.org/10.1609/aaai.v33i01.33011674 ;
> if
> &gt; so, including the DOI link would be very helpful for readers.
> &gt;
> &gt; That's just the one I happend to go pull up; DOIs for the other
> papers (if
> &gt; available) should be included, too.
>
> OK. We will add the DOI link for each academic paper.
>
> &gt;
> &gt; NITS
> &gt;
> &gt; Section 1
> &gt;
> &gt;    Map that contains the properties requested for these ANEs.  To
> &gt;    enforce consistency and improve server scalability, this document
> &gt;    uses the "multipart/related" message defined in [RFC2387] to return
> &gt;    the two maps in a single response.
> &gt;
> &gt; I think it's more typical to say "content type" than "message" in this
> &gt; context.
>
> We will modify as suggested.
> &gt;
> &gt; Section 3
> &gt;
> &gt;       performance of traffic.  An ANE can be a physical device such
> as a
> &gt;       router, a link or an interface, or an aggregation of devices
> such
> &gt;       as a subnetwork, or a data center.
> &gt;
> &gt; I think we do not want a comma before "or a data center", since the
> data
> &gt; center is just another example of an aggregation of devices.
> &gt;
> We will modify as suggested.
>
> &gt; Section 4.1
> &gt;
> &gt;    performance.  The capacity region information for those flows will
> &gt;    benefit the scheduling.  However, Cost Maps as defined in [RFC7285]
> &gt;    can not reveal such information.
> &gt;
> &gt; I'm not sure I know what "capacity region information" is; did we mean
> &gt; "region capacity information" (or maybe "Knowledge of the relevant
> &gt; capacity regions for those flows")?
>
> We change the term to "constraints on feasible rate allocations of those
> flows" which may be clearer.
>
> &gt;
> &gt;    With the ALTO Cost Map, the cost between PID1 and PID2 and between
> &gt;    PID1 and PID4 will be 100 Mbps.  The client can get a capacity
> region
> &gt;
> &gt; I'd suggest "will both be".
>
> We will modify as suggested.
> &gt;
> &gt; Section 4.2.1
> &gt;
> &gt;    With the Path Vector extension, a site can reveal the bottlenecks
> &gt;    inside its own network with necessary information (such as link
> &gt;    capacities) to the ALTO client, instead of providing the full
> &gt;    topology and routing information.  [...]
> &gt;
> &gt; I'd suggest adding "or no bottleneck information at all".
> &gt;
> We will modify as suggested.
>
> &gt; Section 4.2.2
> &gt;
> &gt;    in various documents (e.g., [SEREDGE] and [MOWIE]).  Internet
> Service
> &gt;    Providers may deploy multiple layers of CDN caches, or more
> generally
> &gt;    service edges, with different latency and available resources
> &gt;    including number of CPU cores, memory in Gigabytes (G), and storage
> &gt;    measured in Terabytes (T).
> &gt;
> &gt; The units are probably not relevant for the abstract scenario, and
> would
> &gt; only become relevant when we start introducing Figure 6 as a specific
> &gt; instantiation of the multi-layer model.
> &gt;
>
> 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).
>
> &gt; Section 5.1.3
> &gt;
> &gt;    Specifically, the available properties for a given resource are
> &gt;    announced in the Information Resource Directory as a new capability
> &gt;    called "ane-property-names".  The selected properties are specified
> &gt;    in a filter called "ane-property-names" in the request body, and
> the
> &gt;    response includes and only includes the selected properties for the
> &gt;    ANEs in the response.
> &gt;
> &gt; Going from the first to second sentence, we switch from using the
> string
> &gt; "ane-property-names" to refer to the available properties announced
> in the
> &gt; IRD, to using it to refer to the properties that a client supplies in
> a
> &gt; path vector query for use in filtering the response results.  To help
> the
> &gt; reader make this transition smoothly, I suggest rephrasing the
> transition,
> &gt; perhaps to something like "The properties selected by a client as
> being of
> &gt; interest are specified in the subsequent Path Vector queries using the
> &gt; filter called 'ane-property-names'."
> &gt;
> Good point. We will modify as suggested.
>
> &gt; Section 5.3
> &gt;
> &gt;    1.  Since ANEs may be constructed on demand, and potentially based
> on
> &gt;        the requested properties (See Section 5.1 for more details).
> If
> &gt;
> &gt; Incomplete sentence.
> &gt;
> We will remove "Since".
>
> &gt; Section 6.2.4
> &gt;
> &gt;    multipart response.  Meanwhile, for persistent ANEs whose entity
> &gt;    domain name has the format of "PROPMAP.ane" where PROPMAP is the
> name
> &gt;    of a Property Map resource, PROPMAP is the defining resource of
> these
> &gt;
> &gt; Is it better to say "name" of "ResourceID"?
>
> We propose to change the "name" to "resource ID".
> &gt;
> &gt;
> &gt;
> &gt; _______________________________________________
> &gt; alto mailing list
> &gt; [e-mail]
> &gt; https://www.ietf.org/mailman/listinfo/alto
> </[e-mail]></[e-mail]>
>
>