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

[Benjamin Kaduk]

Hi Kai,

Also inline...

On Fri, Mar 04, 2022 at 01:51:07AM +0800, 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" 
>  Sent Time: 2022-03-03 17:53:16 (Thursday)
>  To: "The IESG" 
>  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/
>  
>  
>  
>  --
>  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.

[just noting that this has been covered downthread already]

>  
>  
>  --
>  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 

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

[Benjamin Kaduk]

Hi Qin, Med,

On Fri, Mar 04, 2022 at 10:27:15AM +, Qin Wu wrote:
> Hi, Martin and Ben, and authors of path vector draft:
> I believe Martin’s proposal is straightforward,
> Med and I have put up a new draft that updates RFC7285 and creates a cost 
> mode registry.
> https://datatracker.ietf.org/doc/html/draft-bw-alto-cost-mode-01

Wow, that was fast!
Yes, this looks like a good approach.  Having read through it, my only
comment is that a sentence or two on deployment considerations might be
useful.  If I remember correctly, the protocol is mostly client-driven and
the server indicates capabilities, so there should be a pretty
straightforward path for in-band negotiation of using new cost modes.
Regardless, it would also be the case that protocol authors can indicate
that the new cost mode is applicable to new ALTO resources when defining
them.

> To accelerate the progress of draft-ietf-path-vector which doesn’t need to 
> wait for another telechat, our chairs’ proposal to authors of 
> draft-ietf-path-vector, is
> draft-ietf-path-vector makes reference to this new cost mode draft and 
> register the new mode. Hope this resolve Ben’s DISCUSS.
> Does this work for you, @Ben @Martin @Kai.

Yes, this will work -- when draft-ietf-alto-path-vector references this new
document that will alleviate my DISCUSS concern.

Thanks,

Ben

> -Qin 
> 发件人: Martin Duke [mailto:martin.h.d...@gmail.com]
> 发送时间: 2022年3月4日 4:26
> 收件人: Kai Gao 
> 抄送: Benjamin Kaduk ; IETF ALTO ; alto-chairs 
> ; The IESG ; 
> draft-ietf-alto-path-vec...@ietf.org
> 主题: 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 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:
> 
> 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]. 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] 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 mailto: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" 
> mailto:nore...@ietf.org>>
>  Sent Time: 2022-03-03 17:53:16 (Thursday)
>  To: "The IESG" mailto: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:
>  

Re: [alto] Éric Vyncke's No Objection on draft-ietf-alto-performance-metrics-26: (with COMMENT)

[Y. Richard Yang]

Hi Éric,

Thank you so much for the update.

For the comment on IPv4: we had some discussions on how to address it. In
earlier documents, we used a mix of IPv4 and IPv6 addresses (e.g., an
earlier version of RFC7285 used a mix of ipv4 and ipv6 in examples such as
https://datatracker.ietf.org/doc/html/rfc7285#section-11.5.1.7), and the
feedback was that this could be confusing, and hence we used only ipv4
addresses. We see two possibilities: (1) add one example, say replicating
Example 1, but with ipv6; and (2) change one of the late examples, say
example 2, from ipv4 to ipv6 addresses.

For the TCP model, the examples we gave (
https://datatracker.ietf.org/doc/html/draft-ietf-alto-performance-metrics-26#section-4.1)
mentioned both Cubic and BBR. Does this address the comment? Or the
suggestion is to change the metric from "TCP Throughput" to something like
"Congestion Control Throughput" to be more general?

Please let us know and we sure can take a pass.

Thank you so much again!
Richard

On Fri, Mar 4, 2022 at 5:57 AM Éric Vyncke via Datatracker 
wrote:

> Éric Vyncke has entered the following ballot position for
> draft-ietf-alto-performance-metrics-26: No Objection
>
> 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-performance-metrics/
>
>
>
> --
> COMMENT:
> --
>
> Thank you for addressing my previous DISCUSS point, I have now updated my
> ballot position into a NO OBJECT.
>
> Nevertheless, I would have appreciated a reaction on the IPv4-only
> examples and
> the focus on TCP only but this is obviously not blocking this document. I
> appreciate that my other comments were used to improve the document.
>
> Regards
>
> -éric
>
> —— below is for archiving only —
>
> Thank you for the work put into this document. Please bear with my lack of
> knowledge about ALTO in general.
>
> Please find below one trivial blocking DISCUSS points (probably easy to
> address), some non-blocking COMMENT points (but replies would be
> appreciated
> even if only for my own education), and some nits.
>
> Special thanks to Jan Seedorf for the shepherd's write-up about the WG
> consensus (even if not using the usual template).
>
> I have appreciated the "operational considerations" section as it addresses
> many questions that popped up during reading the document; notably, how
> can the
> ALTO server measure any metric between the ALTO client and a resource.
>
> I hope that this helps to improve the document,
>
> Regards,
>
> -éric
>
> == COMMENTS ==
>
> Minor regret about the examples as they are all about the IPv4 address
> family
> especially in a world of happy eyeballs where the IPv4 and IPv6 paths may
> still
> have different performance metrics.
>
> -- Section 2.1 --
> Should the figure 1 use "perf monitoring tools" rather than "management
> tool" ?
>
> -- Section 4 --
> This section title is about 'bandwidth' but the first sub-section is about
> 'throughput', while these concepts are related they are also distinct. How
> can
> the reader reconciliate them ?
>
> -- Section 4.1 --
> Is the intent of ALTO to only work for TCP and not for other transport
> protocols ? I.e., is QUIC out of scope ?
>
> -- Section 4.2.3 --
> Where are those 'tunnels' in "by subtracting tunnel reservations " coming
> from
> ? Probably about RSVP-TE but what is the link with ALTO ? (Again I am not
> familiar with ALTO so this may be an uneducated question).
>
> == NITS ==
>
> -- Section 3.1.3 --
> Probably tedious to do but why not replacing "TBA" by the actual value in
> the
> examples for 'content-length' ?
>
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

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

[Martin Duke]

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  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 
> *抄送:* Benjamin Kaduk ; IETF ALTO ;
> alto-chairs ; The IESG ;
> 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" 
> *Sent Time:*2022-03-04 04:25:37 (Friday)
> *To:* "Kai Gao" 
> *Cc:* "Benjamin Kaduk" , "IETF ALTO" ,
> alto-chairs , "The IESG" ,
> 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
>  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:
> 
>
>
>
> 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
> ]. 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
> ] 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  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" 
>  Sent Time: 2022-03-03 17:53:16 (Thursday)
>  To: "The IESG" 
>  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 

Re: [alto] Benjamin Kaduk's Discuss on draft-ietf-alto-unified-props-new-21: (with DISCUSS and COMMENT) / updates on remaining COMMENTS

[Randriamasy, Sabine (Nokia - FR/Paris-Saclay)]

Hello Ben,

Again, thank you very much for your review and guidance.  While DISCUSS and 
COMMENTS on section 10 have been addressed in V22, we still owe you a reponse 
on the remaining comments.  
Please find inline how they have been addressed in V23.  
The text relating to DISCUSS and COMMENTS on Section 10 has been removed from 
this e-mail, for brevity.

The updates upon your remaining comments can be seen in V23
https://datatracker.ietf.org/doc/html/draft-ietf-alto-unified-props-new-23

Best regards,
Sabine

>-Original Message-
>From: Benjamin Kaduk via Datatracker 
>Sent: Thursday, December 2, 2021 12:00 AM
>To: The IESG 
>Cc: draft-ietf-alto-unified-props-...@ietf.org; alto-cha...@ietf.org;
>alto@ietf.org; Vijay Gurbani ;
>vijay.gurb...@gmail.com
>Subject: Benjamin Kaduk's Discuss on draft-ietf-alto-unified-props-new-21:
>(with DISCUSS and COMMENT)
>
>Benjamin Kaduk has entered the following ballot position for
>draft-ietf-alto-unified-props-new-21: 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/blog/handling-iesg-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-unified-props-new/
>
>
>
>--
>COMMENT:
>--
>
>I suggest noting somewhere early-ish that the (semi-)formal notation defined
>in Section 8.2 of RFC 7285 will be used.
>
[ [SR] ] Section 1.1 "Terminology" has been renamed "Terminology and notation" 
with the following appended paragraph   
"This document uses the semi-formal notation defined in Section 8.2 of RFC 
7285."

>Section 1
>
>   properties.  Furthermore, recent ALTO use cases show that properties
>   of entities such as network flows [RFC7011] and routing elements
>   [RFC7921] are also useful.  Such cases are documented in
>   [I-D.gao-alto-fcs].  The current EPS however is restricted to
>
>This is probably more relevant as a comment on draft-gao-alto-fcs than this
>document, but putting the ALTO server in a position to know about individual
>flows seems like a big privacy risk, especially in the face of pervasive
>monitoring (per RFC 7258).  It's not really clear that this is actually a good 
>idea
>to do, and thus whether we want to mention it here.
>
[ [SR] ] agree. This paragraph now refers to [I-D.ietf-alto-path-vector]  and 
has been updated as follows:
OLD
 Furthermore, recent ALTO use cases show that properties
   of entities such as network flows [RFC7011] and routing elements
   [RFC7921] are also useful.  Such cases are documented in
   [I-D.gao-alto-fcs]. 
NEW
 Furthermore, recent ALTO use cases show that properties
   of entities such as abstracted network elements as defined in
  [I-D.ietf-alto-path-vector] are also useful. 
REFERENCE removed: [RFC7011]  and [I-D.gao-alto-fcs].

>Section 3.2.2
>
>There seems to be an unfortunate risk of conflation of parsing as ((entity
>domain) name) vs (entity (domain name)), with domain name being the
>widely-used term (see, e.g., RFC 8499).  Could we find some alternate
>terminology that doesn't suffer from this potential confusion?
>
[ [SR] ] We start section 3.2.2.  Entity Domain Name with the following 
paragraph. 
OLD
   "The name of an entity domain is defined in the scope of an ALTO
   server.  An entity domain name can sometimes be identical to the name
   of its relevant entity domain type.  ..."
NEW
In this document, the identifier of an entity domain is mostly called "entity 
domain name". 
The identifier of an entity domain is defined in the scope of an ALTO server. 
An entity domain identifier can sometimes be identical to the identifier 
of its relevant entity domain type...  "

>Section 4.4
>
>   For some domain types, entities can be grouped in a set and be
>   defined by the identifier of this set.  This is the case for domain
>
>>From a mathematical/set-theoretic perspective, this statement is
>trivially true for all domain types; that's just how sets work.  I think what 
>we
>want to say here is that they can be efficiently grouped by utilizing an
>underlying structure for the entities in the given domain type.  That might
>become, for example, "For some domain types, there is an underlying
>structure that allows entities to efficiently be grouped into a set and be
>defined by the identifier of this set".
>
[ [SR] ] Thanks for this proposal. We replaced with your text.
OLD
   For some domain types, entities can be grouped in a set and be
   defined by the identifier of this set. 
NEW
For some domain types, there is an underlying structure that allows entities to 
efficiently be grouped into a set and be defined by the 

[alto] Éric Vyncke's No Objection on draft-ietf-alto-performance-metrics-26: (with COMMENT)

[Éric Vyncke via Datatracker]

Éric Vyncke has entered the following ballot position for
draft-ietf-alto-performance-metrics-26: No Objection

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-performance-metrics/



--
COMMENT:
--

Thank you for addressing my previous DISCUSS point, I have now updated my
ballot position into a NO OBJECT.

Nevertheless, I would have appreciated a reaction on the IPv4-only examples and
the focus on TCP only but this is obviously not blocking this document. I
appreciate that my other comments were used to improve the document.

Regards

-éric

—— below is for archiving only —

Thank you for the work put into this document. Please bear with my lack of
knowledge about ALTO in general.

Please find below one trivial blocking DISCUSS points (probably easy to
address), some non-blocking COMMENT points (but replies would be appreciated
even if only for my own education), and some nits.

Special thanks to Jan Seedorf for the shepherd's write-up about the WG
consensus (even if not using the usual template).

I have appreciated the "operational considerations" section as it addresses
many questions that popped up during reading the document; notably, how can the
ALTO server measure any metric between the ALTO client and a resource.

I hope that this helps to improve the document,

Regards,

-éric

== COMMENTS ==

Minor regret about the examples as they are all about the IPv4 address family
especially in a world of happy eyeballs where the IPv4 and IPv6 paths may still
have different performance metrics.

-- Section 2.1 --
Should the figure 1 use "perf monitoring tools" rather than "management tool" ?

-- Section 4 --
This section title is about 'bandwidth' but the first sub-section is about
'throughput', while these concepts are related they are also distinct. How can
the reader reconciliate them ?

-- Section 4.1 --
Is the intent of ALTO to only work for TCP and not for other transport
protocols ? I.e., is QUIC out of scope ?

-- Section 4.2.3 --
Where are those 'tunnels' in "by subtracting tunnel reservations " coming from
? Probably about RSVP-TE but what is the link with ALTO ? (Again I am not
familiar with ALTO so this may be an uneducated question).

== NITS ==

-- Section 3.1.3 --
Probably tedious to do but why not replacing "TBA" by the actual value in the
examples for 'content-length' ?



___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

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

[Qin Wu]

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 
抄送: Benjamin Kaduk ; IETF ALTO ; alto-chairs 
; The IESG ; 
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" mailto:martin.h.d...@gmail.com>>
Sent Time:2022-03-04 04:25:37 (Friday)
To: "Kai Gao" mailto:kai...@scu.edu.cn>>
Cc: "Benjamin Kaduk" mailto:ka...@mit.edu>>, "IETF ALTO" 
mailto:alto@ietf.org>>, alto-chairs 
mailto:alto-cha...@ietf.org>>, "The IESG" 
mailto: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 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:

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]. 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] 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 mailto: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" 
mailto:nore...@ietf.org>>
 Sent Time: 2022-03-03 17:53:16 (Thursday)
 To: "The IESG" mailto: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 

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

[Qin Wu]

Hi, Martin and Ben, and authors of path vector draft:
I believe Martin’s proposal is straightforward,
Med and I have put up a new draft that updates RFC7285 and creates a cost mode 
registry.
https://datatracker.ietf.org/doc/html/draft-bw-alto-cost-mode-01

To accelerate the progress of draft-ietf-path-vector which doesn’t need to wait 
for another telechat, our chairs’ proposal to authors of 
draft-ietf-path-vector, is
draft-ietf-path-vector makes reference to this new cost mode draft and register 
the new mode. Hope this resolve Ben’s DISCUSS.
Does this work for you, @Ben @Martin @Kai.

-Qin 
发件人: Martin Duke [mailto:martin.h.d...@gmail.com]
发送时间: 2022年3月4日 4:26
收件人: Kai Gao 
抄送: Benjamin Kaduk ; IETF ALTO ; alto-chairs 
; The IESG ; 
draft-ietf-alto-path-vec...@ietf.org
主题: 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 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:

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]. 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] 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 mailto: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" 
mailto:nore...@ietf.org>>
 Sent Time: 2022-03-03 17:53:16 (Thursday)
 To: "The IESG" mailto: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/



 --
 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