Re: [alto] Lars Eggert's No Objection on draft-ietf-alto-cost-mode-03: (with COMMENT)

[mohamed.boucadair]

Hi Lars,

Thanks for the comment.

Please see inline.

Cheers,
Med

> -Message d'origine-
> De : Lars Eggert via Datatracker 
> Envoyé : lundi 30 mai 2022 13:42
> À : The IESG 
> Cc : draft-ietf-alto-cost-m...@ietf.org; alto-cha...@ietf.org;
> alto@ietf.org; kai...@scu.edu.cn; kai...@scu.edu.cn
> Objet : Lars Eggert's No Objection on draft-ietf-alto-cost-mode-
> 03: (with COMMENT)
> 
> Lars Eggert has entered the following ballot position for
> draft-ietf-alto-cost-mode-03: 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-cost-mode/
> 
> 
> 
> --
> 
> COMMENT:
> --
> 
> 
> # GEN AD review of draft-ietf-alto-cost-mode-03
> 
> CC @larseggert
> 
> Thanks to Roni Even for the General Area Review Team (Gen-ART)
> review
> (https://mailarchive.ietf.org/arch/msg/gen-
> art/xlaIzXHKY1NzjJRJpuXpzKwP4rc).
> 
> ## Comments
> 
> ### Section 1, paragraph 4
> ```
>  Additional cost modes are required for specific ALTO
> deployment cases
>  (e.g., [I-D.ietf-alto-path-vector]).  In order to allow for
> such use
>  cases, this document relaxes the constraint imposed by the
> base ALTO
>  specification on allowed cost modes (Section 3) and creates a
> new
>  ALTO registry to track new cost modes (Section 4).
> ```
> I second Rob's DISCUSS, i.e., it's not clear at all that current
> ALTO
> implementations will handle this protocol parameter now taking on
> values other than "numerical" or "ordinal" without explicit
> negotiation.
>

[Med] All what actually this draft does is to declare it legitimate to 
manipulate other cost modes for specific cost metrics.  

In practice, legacy implementations will only support one cost metric 
(routingcost) as per 7285. So far, such a metric can be associated with two 
cost types. 

If in the future, a document defines a new cost mode that can also be used for 
the "routingcost" cost metric or new metrics with additional cost modes, and a 
server is upgraded to support that, the procedure in 9.2 of RFC7285 will be 
followed by such upgraded servers to announce the new metrics. clients 
(including legacy ones) will take these capabilities when building forthcoming 
requests. 

Note also that legacy servers can also report errors based on unsupported cost 
modes as per the following from RFC7285:   

   A request with the correct fields and types of values for the fields
   may specify a wrong value for a field.  For example, a Filtered Cost
   Map request may specify a wrong value for CostMode in the "cost-type"
   field (Section 11.3.2.3).  The server indicates such an error with
   the error code E_INVALID_FIELD_VALUE.  For an E_INVALID_FIELD_VALUE
   error, the server may include an optional field named "field" in the
   "meta" field of the response, to indicate the field that contains the
   wrong value.  The server may also include an optional field named
   "value" in the "meta" field of the response to indicate the wrong
   value that triggered the error.  


_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.

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

[alto] ALTO meeting with PBE-CC team

[Y. Richard Yang]

Hi ALTO group,

We will meet with the PBE-CC team (Kyle Jamieson, Jen Rexford, and Yaxiong
Xie, all from Princeton) tomorrow at 9:00 AM US ET to discuss the
possibility of exposing more network information for applications.

The direct relevant paper is:
https://arxiv.org/abs/2002.03475

Another related work:
https://dl.acm.org/doi/pdf/10.1145/3405672.3409489

One "grand" scheme is network information exposure from control channel,
data channel, and control channel embedded in the data channel, e.g.,
https://datatracker.ietf.org/doc/rfc/

The meeting info is at the bottom of this page.

Looking forward to see the design team and more tomorrow.

- Richard on behalf of the meeting organizers

JOIN WEBEX MEETING
https://ietf.webex.com/ietf/j.php?MTID=ma0e97cc97c4cd71bb59cf1a094682686
Meeting number (access code): 2424 884 8159

Meeting password: ymKtkapb394

TAP TO JOIN FROM A MOBILE DEVICE (ATTENDEES ONLY)
+1-650-479-3208,
,24248848159##
tel:%2B1-650-479-3208,,*01*24248848159%23%23*01* Call-in toll number
(US/Canada)

JOIN BY PHONE
1-650-479-3208 Call-in toll number (US/Canada)

Global call-in numbers
https://ietf.webex.com/ietf/globalcallin.php?MTID=mb80643ae6bba4f3cf51f1b5918b3ce49

JOIN FROM A VIDEO SYSTEM OR APPLICATION
Dial sip:24248848...@ietf.webex.com
You can also dial 173.243.2.68 and enter your meeting number.

Can't join the meeting?
https://collaborationhelp.cisco.com/article/WBX29055

IMPORTANT NOTICE: Please note that this Webex service allows audio and
other information sent during the session to be recorded, which may be
discoverable in a legal matter. By joining this session, you automatically
consent to such recordings. If you do not consent to being recorded,
discuss your concerns with the host or do not join the session.
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] [Last-Call] Genart last call review of draft-ietf-alto-cost-mode-02

[Lars Eggert]

Roni, thank you for your review. I have entered a No Objection ballot for this 
document.

Lars


> On 2022-5-7, at 14:38, Roni Even via Datatracker  wrote:
> 
> Reviewer: Roni Even
> Review result: Ready
> 
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair.  Please treat these comments just
> like any other last call comments.
> 
> For more information, please see the FAQ at
> 
> .
> 
> Document: draft-ietf-alto-cost-mode-??
> Reviewer: Roni Even
> Review Date: 2022-05-07
> IETF LC End Date: 2022-05-13
> IESG Telechat date: Not scheduled for a telechat
> 
> Summary: The document is ready for publication as a standard track RFC
> 
> Major issues:
> 
> Minor issues:
> 
> Nits/editorial comments:
> 
> 
> 
> --
> last-call mailing list
> last-c...@ietf.org
> https://www.ietf.org/mailman/listinfo/last-call



signature.asc
Description: Message signed with OpenPGP
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

[alto] Lars Eggert's No Objection on draft-ietf-alto-cost-mode-03: (with COMMENT)

[Lars Eggert via Datatracker]

Lars Eggert has entered the following ballot position for
draft-ietf-alto-cost-mode-03: 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-cost-mode/



--
COMMENT:
--

# GEN AD review of draft-ietf-alto-cost-mode-03

CC @larseggert

Thanks to Roni Even for the General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/xlaIzXHKY1NzjJRJpuXpzKwP4rc).

## Comments

### Section 1, paragraph 4
```
 Additional cost modes are required for specific ALTO deployment cases
 (e.g., [I-D.ietf-alto-path-vector]).  In order to allow for such use
 cases, this document relaxes the constraint imposed by the base ALTO
 specification on allowed cost modes (Section 3) and creates a new
 ALTO registry to track new cost modes (Section 4).
```
I second Rob's DISCUSS, i.e., it's not clear at all that current ALTO
implementations will handle this protocol parameter now taking on
values other than "numerical" or "ordinal" without explicit
negotiation.

I will let Rob hold the DISCUSS, but will monitor the discussion to
see if this issue will be addressed.

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT].

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments
[IRT]: https://github.com/larseggert/ietf-reviewtool



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