from:"mohamed.boucadair"

Re: [alto] 2nd WGLC draft-ietf-alto-new-transport (Ends 01/06/2023)

2023-06-01 Thread mohamed.boucadair

Hi all,

The WGLC is now closed for the document. No objection/ major issues were raised 
against progressing this specification. However, there are few minor comments 
[1]/edits[2] that need to be addressed before we send the document to the IESG 
for publication.

Authors, can you please prepare a revised version that addresses these pending 
issues? Thank you.

Cheers,
Med

[1]: 
https://github.com/ietf-wg-alto/draft-ietf-alto-new-transport/issues?q=is%3Aissue+is%3Aopen+label%3A2nd
[2]: https://github.com/ietf-wg-alto/draft-ietf-alto-new-transport/pulls

De : BOUCADAIR Mohamed INNOV/NET
Envoyé : jeudi 25 mai 2023 08:56
À : IETF ALTO (alto@ietf.org) ; 
draft-ietf-alto-new-transp...@ietf.org
Cc : ALTO Working Group 
Objet : 2nd WGLC draft-ietf-alto-new-transport (Ends 01/06/2023)

Hi all,

The authors believe that they addressed the comments raised during the 1st WGLC 
and also from the various directorate.

This message starts the second WGLC for the transport draft: 
https://datatracker.ietf.org/doc/draft-ietf-alto-new-transport/09/. The WGLC 
runs for one week, i.e., till 01/06/23. The are still few PRs in 
https://github.com/ietf-wg-alto/draft-ietf-alto-new-transport/pulls, but those 
will be covered as part of the WGLC.

Please review and share any pending concerns/comments you have with this 
version.

Thank you.

Cheers,
Qin & Med

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

[alto] 2nd WGLC draft-ietf-alto-oam-yang (Ends 06/06/2023)

2023-05-30 Thread mohamed.boucadair

Hi all,

The authors believe that they addressed the comments raised during the 1st WGLC
and also from the various directorate. The full set of resolved issues can be
tracked at [1].

This message starts the second WGLC for the transport draft:
https://datatracker.ietf.org/doc/draft-ietf-alto-oam-yang/08/. The WGLC runs
for one week, i.e., till 06/06/23.

Please review and share any pending concerns/comments you have with this
version.

Thank you.

Cheers,
Qin & Med

[1]
https://github.com/ietf-wg-alto/draft-ietf-alto-oam-yang/issues?q=is%3Aissue+label%3AWGLC+

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] 2nd WGLC draft-ietf-alto-new-transport (Ends 01/06/2023)

2023-05-24 Thread mohamed.boucadair

Hi all,

The authors believe that they addressed the comments raised during the 1st WGLC 
and also from the various directorate.

This message starts the second WGLC for the transport draft: 
https://datatracker.ietf.org/doc/draft-ietf-alto-new-transport/09/. The WGLC 
runs for one week, i.e., till 01/06/23. The are still few PRs in 
https://github.com/ietf-wg-alto/draft-ietf-alto-new-transport/pulls, but those 
will be covered as part of the WGLC.

Please review and share any pending concerns/comments you have with this 
version.

Thank you.

Cheers,
Qin & Med

_

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

Re: [alto] IPJ article on ALTO

2023-05-23 Thread mohamed.boucadair

Hi all,

FYI, the paper is also listed in the WG Datatracker page under "Additional 
resources": https://datatracker.ietf.org/wg/alto/about/.

Cheers,
Med

De : alto  De la part de Jordi Ros Giralt
Envoyé : mardi 23 mai 2023 18:43
À : alto@ietf.org
Objet : [alto] IPJ article on ALTO

Hi ALTOers,

Here is the article on ALTO that was published in the last IPJ issue (which 
happens to celebrate the 25th year anniversary of IPJ):

"The IETF ALTO Protocol: Optimizing Application Performance by Increasing 
Network Awareness"
https://ipj.dreamhosters.com/wp-content/uploads/2023/05/261-ipj.pdf

Thanks,
Jordi, on behalf of ALTO

_

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

Re: [alto] draft-ietf-alto-oam-yang : Call for volunteers to review 2nd WGLC for ALTO docs

2023-05-23 Thread mohamed.boucadair

Hi Jensen, all

On this one : use draft-ietf-netmod-rfc6991-bis instead of RFC6991

I suggest we leave RFC6991 as in the current version and adjust in the future 
if the bis makes it before this one (which is not unlikely but who knows). 
Thanks.

Cheers,
Med

De : alto  De la part de Jensen Zhang
Envoyé : mardi 23 mai 2023 15:10
À : adr...@olddog.co.uk
Cc : alto@ietf.org
Objet : Re: [alto] draft-ietf-alto-oam-yang : Call for volunteers to review 2nd 
WGLC for ALTO docs

Hi Adrian,

Many thanks for your early review and quick comments.

On Mon, May 22, 2023 at 6:41 AM Adrian Farrel 
mailto:adr...@olddog.co.uk>> wrote:
Hi,

I looked at revision -07

This is a really big document and would probably benefit from a more detailed 
review than I was able to give it. But it looks fine and ready to progress to 
me.

A couple of nits…

Section 4.3 might usefully describe that this is an additional requirement.

Although we have mentioned this in the subsection title, we will also describe 
this in the text.


You might reference draft-ietf-netmod-rfc6991-bis instead of RFC6991. You’ll be 
behind it in the queue, so you can safely use it as a normative reference. 
That’ll be a bit more future-proof.

Many thanks for the reminder. We will update the reference.

Thanks,
Jensen


Cheers,
Adrian




From: alto mailto:alto-boun...@ietf.org>> On Behalf Of 
Jordi Ros Giralt
Sent: 17 May 2023 06:41
To: alto@ietf.org
Subject: [alto] Call for volunteers to review 2nd WGLC for ALTO docs

Hi ALTO WG:

As you know, we are in the process of issuing the 2nd WGLC for two of the ALTO 
drafts (New Transport and OAM). Thank you to all of you who have been working 
hard to help get these documents completed, including all the detailed feedback 
provided by reviewers during the first WGLC.

There is now a need (as mentioned by the chairs) to have as many eyes & 
volunteers review the docs to make sure they are in the best possible shape. I 
can volunteer to review both documents. Richard also volunteered, thank you 
Richard. We would like to suggest targeting two more volunteers. Could any of 
you help support this work?

We are targeting 22/05 to complete this new round of revisions, as that's the 
target day for the 2nd WGLC.

These are the docs:

- New Transport: https://datatracker.ietf.org/doc/draft-ietf-alto-new-transport/
- OAM: https://datatracker.ietf.org/doc/draft-ietf-alto-oam-yang/

Please feel free to forward this email if you know others (inside or ouside 
ALTO) who can help review the docs too.

As we are working to wrap up the current charter, this is very important work 
to ensure the quality of the documents produced by ALTO. Thank you for your 
collaboration.

Jordi, on behalf of ALTO

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

_

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

Re: [alto] [ietf-wg-alto/draft-ietf-alto-oam-yang] Security Considerations (Issue #33)

2023-05-10 Thread mohamed.boucadair

Hi Jensen,

Please see inline.

Cheers,
Med

De : Jensen Zhang 
Envoyé : jeudi 11 mai 2023 04:15
À : BOUCADAIR Mohamed INNOV/NET 
Cc : ietf-wg-alto/draft-ietf-alto-oam-yang 
; IETF ALTO 

Objet : Re: [alto] [ietf-wg-alto/draft-ietf-alto-oam-yang] Security 
Considerations (Issue #33)

Hi Med,

Sorry for the late reply.

On Tue, May 9, 2023 at 9:39 PM 
mailto:mohamed.boucad...@orange.com>> wrote:
Hi Jensen,

Thanks for drafting that text. I do still that some sensitive data nodes have 
to be listed. For example,


  *   Access to all authentication-related data nodes should be protected; 
those that are inherited from other models have already 
“nacm:default-deny-write” statement, while there is no such protected from the 
data node that are added in the draft.

Thanks for the suggestion. I agree. But I think the only authentication-related 
data nodes explicitly added in the current document are 
"http-auth-client/user-id" and "https-auth-client/user-id" under "auth-client". 
The leaf nodes referenced by them have already been protected. Shall the 
leafrefs themselves be also protected?
[Med] I think that is safe that the leafrefs themselves be protected. In 
addition, we need at least two other actions: (1) remind that imported 
authentication-related data are adequately protected as per my previous reply. 
(2) add a warning that given that no “nacm:*” statement is added in the 
top-level auth container, future augmentations should include those.

  *   Consider the example of “poll-interval”: a misbehaving node can set a 
very large value that would lead to maintaining stale data. Setting very low 
values can also be considered as a misbehavior.

It is a very interesting point. I agree that the range of "poll-interval" 
should be limited. But the accepted range may depend on the data sources and 
implementations. It is hard to define a fixed range in the module. Do you have 
any suggestions about it? Or we just explain this consideration without any 
concrete solution?

[Med] We don’t need to define random ranges for this or touch the YANG model. 
We only need to list the data node in the security considerations with the 
associated vulnerability. Thanks.

Thanks,
Jensen

_

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

Re: [alto] [ietf-wg-alto/draft-ietf-alto-oam-yang] Security Considerations (Issue #33)

2023-05-09 Thread mohamed.boucadair

Hi Jensen,

Thanks for drafting that text. I do still that some sensitive data nodes have
to be listed. For example,

* Access to all authentication-related data nodes should be protected;
those that are inherited from other models have already
“nacm:default-deny-write” statement, while there is no such protected from the
data node that are added in the draft.
* Consider the example of “poll-interval”: a misbehaving node can set a
very large value that would lead to maintaining stale data. Setting very low
values can also be considered as a misbehavior.

Cheers,
Med

De : alto De la part de Jensen Zhang
Envoyé : mardi 9 mai 2023 15:14
À : ietf-wg-alto/draft-ietf-alto-oam-yang

Cc : IETF ALTO
Objet : Re: [alto] [ietf-wg-alto/draft-ietf-alto-oam-yang] Security
Considerations (Issue #33)

Hi Med,

I am not aware of which data nodes are sensitive in this module. If you find
any, please point them out.

But I am aware that the extended modules (e.g., examples in the appendix) may
include sensitive data. Especially, the "data-source" node. So I added a new
paragraph [1] to clarify this. Do you think it is enough?

[1]:
https://github.com/ietf-wg-alto/draft-ietf-alto-oam-yang/commit/5a2a40db5ebe45a3e16a836f8cae38891f4b5bce

Thanks,
Jensen

On Mon, Mar 20, 2023 at 10:06 PM Med
mailto:notificati...@github.com>> wrote:

I'm afraid that the following text is to be revised:

None of the readable data nodes in these YANG module are considered sensitive
or vulnerable in network environments. The NACM "default-deny-all" extension
has not been set for any data nodes defined in these module.

None of the writable data nodes in these YANG modules are considered sensitive
or vulnerable in network environments. The NACM "default-deny-write" extension
has not been set for any data nodes defined in these modules.

There are several sensitive data node that should be listed. Access to some
data by non-authorized parties may reveal internal topologies/etc.

There should be also a note about the "http-listen" use.

—
Reply to this email directly, view it on
GitHub, or
unsubscribe.
You are receiving this because you are subscribed to this thread.Message ID:
mailto:ietf-wg-alto/draft-ietf-alto-oam-yang/issues/3...@github.com>>

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

[alto] Proposed Agenda for Interims #2-5

2023-04-03 Thread mohamed.boucadair

Hi all,

Please find below the proposed agenda for the forthcoming interims

* interim #2: WGLC follow-up of OAM/Transport I-Ds
* interim #3: Deployment Catalysts

  *   Reuse existing network resources to identify ALTO resources (e.g., BGP 
communities)
  *   Proposals to fix the integration complexity and integration with data 
sources
* interim #4: OAM/Transport I-Ds
* interim #5: Deployment Catalysts

  *   Security/privacy isolation

Comments and suggestions are welcome.

Cheers,
Qin & Med


_

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

Re: [alto] draft-ietf-alto-new-transport known implementations

2023-03-24 Thread mohamed.boucadair

Hi all,

Forwarding to the list, fwiw.

Cheers,
Med

De : Lachlan Keller 
Envoyé : vendredi 3 mars 2023 23:01
À : BOUCADAIR Mohamed INNOV/NET 
Cc : draft-ietf-alto-new-transp...@ietf.org; alto-cha...@ietf.org
Objet : Re: draft-ietf-alto-new-transport known implementations

Hello,

There are no current implementations of draft-ietf-alto-new-transport of which 
I am aware. However, Richard Yang and I are beginning to start an 
implementation that we will be working on throughout March.

Best,
Lachlan

On Fri, Mar 3, 2023 at 8:03 AM 
mailto:mohamed.boucad...@orange.com>> wrote:
Hi all,

Can you please share details about any implementation (even if it covers only a 
subset of the spec) you are aware of this draft? Thank you.

Cheers,
Med


_



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.

_

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

Re: [alto] ALTO deployment wiki page updates

2023-03-23 Thread mohamed.boucadair

Hi Richard,

Thank you for your effort.

FWIW, I added a “related_implementations” tag to the ALTO Datatracker page so 
that the content you shared is easily accessed: 
https://datatracker.ietf.org/wg/alto/about/

Cheers,
Med

De : alto  De la part de Y. Richard Yang
Envoyé : jeudi 23 mars 2023 04:18
À : IETF ALTO 
Objet : [alto] ALTO deployment wiki page updates

Hi all,

Some of us have made additional updates to the ALTO deployment wiki:
https://wiki.ietf.org/en/group/ALTO/deployment

Any feedback and suggestions will be appreciated.

Thanks,
Richard

_

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

Re: [alto] Discussion on the future of ALTO WG

2023-03-23 Thread mohamed.boucadair

Hi Jordi, all,

Only some logistic comments, not reacting to any expressed views so far:


  *   We created a page at 
https://github.com/ietf-wg-alto/wg-materials/blob/main/FutureALTO/alto-direction-of-work.md
 to track the various proposals (yours is posted there), challenge them, enrich 
them, add rebuttals, etc.
  *   For your logistic comment, we organized on purpose an interim meeting to 
offload the IETF#116 agenda and let other I-Ds be presented and discussed. We 
scheduled 4 other interims till end of May. We really need some focus at this 
stage.

Thanks.

Cheers,
Med

De : Jordi Ros Giralt 
Envoyé : jeudi 23 mars 2023 00:13
À : Qin Wu ; BOUCADAIR Mohamed INNOV/NET 

Cc : alto@ietf.org
Objet : Re: [alto] Discussion on the future of ALTO WG

Hi Med, Qin,



Here is my feedback to your analysis below.



I would like to start with a note. The ALTO team has brought (and continues to 
bring) a lot of positive energy (development of RFCs, deployments of the 
standard at major carriers and new deployments that are in the making, running 
code via the development of the open source project OpenALTO, consistent 
participation on IETF hackathons usually with multiple parallel projects/demos, 
chairing important forums such as SIGCOMM NAI to incorporate feedback into the 
WG from the broad spectrum of industry and academic players, etc.), but it is 
also true that much of the (even larger) potential energy of the group has been 
locked for quite some time as the group has not been allowed to discuss the new 
critical topics that we want to bring from our industry needs. We've all being 
waiting for this moment, to be able to discuss the new topics and unlock yet 
another level of positive energy into the IETF; and so, it is at the minimum 
surprising that the only two options being proposed are either (1) recharter 
with just a focus of working on protocol maintenance or (2) close the WG and 
move our current work to other WGs or RGs.



I have two broad comments, one on the proposed options and another one on the 
logistics to make a proper decision.

On the proposed options:



I would like to suggest adding a 3rd proposal, which I believe is what much of 
us have been working for, for quite some time:



# Proposal #3: Support ALTO extension for the new industry needs.



## Rationale:

  *   Many I-Ds have been proposed describing the importance of leveraging ALTO 
key core architecture to enable the new industry needs, where close cooperation 
between the application and the network is critical.
  *   Allowing these extensions would enable the group to grow and unlock its 
true potential, also attracting other industry players that have been writing 
ALTO I-Ds, but not fully joined us yet because their proposals were tagged as 
being out of the scope for the current charter.
  *   Lots of positive energy and determination in the WG, as we understand the 
potential positive impact (better application performance).
  *   The proposed work can't be done in other groups, and even if we tried to 
do so, it would be improper from an architecture/engineering standpoint. For 
instance, trying to move the exposure of compute information for determining 
edge services to CATS is not viable since "Exposure of network and compute 
conditions to applications is not in the scope of CATS" [1]. ALTO is 
inherently/by definition very well positioned here, since it's designed to 
expose such kind of information to the application, that is key to the industry 
problems we are working to resolve.
  *   There is a natural, coherent story for ALTO, which started from P2P 
networks, then CDNs, and now it's moving into edge computing, where the 
application requires more than ever to cooperate closely to meet stringent 
throughput and delay requirements.
  *   There is a belief that the ALTO WG has been running for a very long time, 
but this in general is not a good technical reason to base a rechartering 
decision on. From the abovementioned trend standpoint, keeping ALTO open to 
provide the IETF a platform for close application-network integration appears 
more important than ever before.

## Proposed direction of work:
·Recharter the WG with a focus on ALTO to cover both maintenance and the 
new industry needs (where such needs are currently being discussed in the ALTO 
WG internal meetings and mailing list, see also my next comment on logistics).

[1] CATS charter: https://datatracker.ietf.org/doc/charter-ietf-cats/


On the logistics to make a proper decision:

-
This is of course a very important decision, so it's also important that we as 
a group provide the right discussion environment to make a proper decision. For 
instance, various members of the WG have been working on various I-Ds to enable 
a discussion of the proposed new charter items. Yet during IETF 116, the group 
is only given 20 minutes to discuss 5 differe

[alto] Discussion on the future of ALTO WG

2023-03-22 Thread mohamed.boucadair

Hi all,

As the WG is about to finalize the last chartered items, we would like to have 
a discussion on the future of the WG with all of you. We will also have a slot 
during the IETF#116 meeting on this matter. The plan is to let this discussion 
open for the coming two months (i.e., ** till end of May **).

Please note that we are also planning to organize a set of interims (mostly in 
replacement of the weekly meetings). Announcements should follow soon.

Together with Qin, we discussed the following two options:

# Proposal # 1: Support ATLO Operations
## Rationale

  *   Many I-Ds are being proposed to ALTO.
  *   Some deployments/products are being disclosed.
  *   Having a referent WG is a signal that the IETF is ready to support 
operations and fix flaws/limitations that will be reported.
  *   ALTO integration complications were out of the scope. Documenting those 
with a set of deployment choices may be a helper for other deployments.
  *   There is constant engagement and dedication of a core team to deliver 
ALTO specs.
## Proposed direction of work

  *   Recharter the WG with a focus on ALTO maintenance and integration with 
data sources. Dedicated YANG modules will be produced.

# Proposal # 2: Revitalize ALTO
## Rationale

  *   Some of the proposed ALTO work is research-oriented (PANRG, would be more 
appropriate for some items), while other may be conducted in new WGs (e.g., 
CATS).
  *   Some of the key foundations of ATLO might not be valid after 15 years.
  *   Closing the WG is not a failure, but a sign of ALTO specification 
maturity.
  *   Revitalizing the ALTO effort is thus needed.
## Proposed direction of work

  *   Consider closing ALTO right after the completion of OAM/Transport items.
  *   Move ALTO maintenance to TSVWG.
  *   Use the ALTO/TSVWG mailing lists to socialize deployment experience.
  *   Based on the maintenance that might be shown in TSVWG and shared 
deployments, reassess the interest of the community in enriching ALTO with 
additional features by organizing a formal BoF.

We are seeking for the WG feedback/preference for each of these two options. 
Specifically, feel free to challenge the rationales above, propose concrete 
action items for #1, disclose ALTO products developments you are aware of, etc.

Absent sufficient engagement, the ** default that the Chairs will formally 
discuss with our AD is Proposal #2 **.

FWIW, we expect this discussion to be an input for Martin, as we do have the 
following in the current charter:

  Furthermore, the Area Director and chairs will assess the state of the
  deliverables at the end of 2022. If the Area Director judges that delivery of
  these documents is not imminent, and that documentation of wide deployment is
  missing, the AD may close the working group immediately.

Thank you.

Cheers,
Qin & Med

_

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

Re: [alto] WGLC for draft-ietf-alto-new-transport (Ends 28/03/2023)

2023-03-21 Thread mohamed.boucadair

Hi Kai,

I would use the mailing list given that very few are watching the GitHub 
activity. Thank you.

Cheers,
Med

De : kai...@scu.edu.cn 
Envoyé : mardi 21 mars 2023 16:25
À : BOUCADAIR Mohamed INNOV/NET 
Cc : IETF ALTO ; draft-ietf-alto-new-transp...@ietf.org; ALTO 
Working Group 
Objet : Re: Re: [alto] WGLC for draft-ietf-alto-new-transport (Ends 28/03/2023)


Hi Med,



Thanks for the reminder and organization. Yes, we are preparing to address the 
comments and will post in the next 2 days.



One quick question, what is the best way to do this? Should we resolve the WGLC 
issues on github or respond to the mailing list likely we did in the past?



Best,

Kai



-Original Messages-
From:mohamed.boucad...@orange.com
Sent Time:2023-03-21 22:49:19 (Tuesday)
To: "IETF ALTO" mailto:alto@ietf.org>>, 
"draft-ietf-alto-new-transp...@ietf.org"
 
mailto:draft-ietf-alto-new-transp...@ietf.org>>
Cc: "ALTO Working Group" mailto:alto-cha...@ietf.org>>
Subject: Re: [alto] WGLC for draft-ietf-alto-new-transport (Ends 28/03/2023)
Hi all,

This is a nudge that this WGLC is still running for one more week. So, please 
review and share your comments.

FWIW, the current situation is as follows:


  *   11 Open WGLC Issues: 
https://github.com/ietf-wg-alto/draft-ietf-alto-new-transport/issues?q=is%3Aissue+is%3Aopen+label%3AWGLC
  *   Received directorate reviews:

 *   Tsvart: Early Review of 
draft-ietf-alto-new-transport-07
 *   Artrt: Early Review of 
draft-ietf-alto-new-transport-07

  *   Pending directorate reviews:

 *   RTGDIR Early Review Incomplete, due 2023-03-28
 *   SECDIR Early Review Incomplete, due 2023-03-28
 *   OPSDIR Early Review Incomplete, due 2023-03-28
 *   HTTPDIR Early Review Incomplete, due 2023-03-28

We trust that the authors are digesting the reviews and will engage with the 
reviewers in a timely manner.

Cheers,
Qin & Med

De : BOUCADAIR Mohamed INNOV/NET
Envoyé : mardi 14 mars 2023 08:21
À : IETF ALTO mailto:alto@ietf.org>>
Cc : ALTO Working Group mailto:alto-cha...@ietf.org>>; 
draft-ietf-alto-new-transp...@ietf.org
Objet : RE: WGLC for draft-ietf-alto-new-transport (Ends 28/03/2023)

Hi all,

WGLC comments can also be reported as github issues/PRs. Please use “WGLC” 
label when filling your issues/PR.

FYI, the reported WGLC comments can be seen at: 
https://github.com/ietf-wg-alto/draft-ietf-alto-new-transport/issues?q=is%3Aissue+is%3Aopen+label%3AWGLC.

Cheers,
Med

De : Qin Wu mailto:bill...@huawei.com>>
Envoyé : mardi 14 mars 2023 02:06
À : IETF ALTO mailto:alto@ietf.org>>
Cc : ALTO Working Group mailto:alto-cha...@ietf.org>>; 
BOUCADAIR Mohamed INNOV/NET 
mailto:mohamed.boucad...@orange.com>>
Objet : WGLC for draft-ietf-alto-new-transport (Ends 28/03/2023)


Hi, All

This message starts 2 weeks WGLC for 
https://datatracker.ietf.org/doc/html/draft-ietf-alto-new-transport-07.
 The call ends: 28/03/2023.



Please review and indicate your support or objection to proceed with the 
publication of this document.



Thank you.



Cheers,

Med & Qin


_



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.

_

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

Re: [alto] WGLC for draft-ietf-alto-new-transport (Ends 28/03/2023)

2023-03-21 Thread mohamed.boucadair

Hi all,

This is a nudge that this WGLC is still running for one more week. So, please
review and share your comments.

FWIW, the current situation is as follows:

* 11 Open WGLC Issues:
https://github.com/ietf-wg-alto/draft-ietf-alto-new-transport/issues?q=is%3Aissue+is%3Aopen+label%3AWGLC
* Received directorate reviews:
* Tsvart: Early Review of
draft-ietf-alto-new-transport-07
* Artrt: Early Review of
draft-ietf-alto-new-transport-07
* Pending directorate reviews:
* RTGDIR Early Review Incomplete, due 2023-03-28
* SECDIR Early Review Incomplete, due 2023-03-28
* OPSDIR Early Review Incomplete, due 2023-03-28
* HTTPDIR Early Review Incomplete, due 2023-03-28

We trust that the authors are digesting the reviews and will engage with the
reviewers in a timely manner.

Cheers,
Qin & Med

De : BOUCADAIR Mohamed INNOV/NET
Envoyé : mardi 14 mars 2023 08:21
À : IETF ALTO
Cc : ALTO Working Group ;
draft-ietf-alto-new-transp...@ietf.org
Objet : RE: WGLC for draft-ietf-alto-new-transport (Ends 28/03/2023)

Hi all,

WGLC comments can also be reported as github issues/PRs. Please use "WGLC"
label when filling your issues/PR.

FYI, the reported WGLC comments can be seen at:
https://github.com/ietf-wg-alto/draft-ietf-alto-new-transport/issues?q=is%3Aissue+is%3Aopen+label%3AWGLC.

Cheers,
Med

De : Qin Wu mailto:bill...@huawei.com>>
Envoyé : mardi 14 mars 2023 02:06
À : IETF ALTO mailto:alto@ietf.org>>
Cc : ALTO Working Group mailto:alto-cha...@ietf.org>>;
BOUCADAIR Mohamed INNOV/NET
mailto:mohamed.boucad...@orange.com>>
Objet : WGLC for draft-ietf-alto-new-transport (Ends 28/03/2023)

Hi, All

This message starts 2 weeks WGLC for
https://datatracker.ietf.org/doc/html/draft-ietf-alto-new-transport-07.
The call ends: 28/03/2023.

Please review and indicate your support or objection to proceed with the
publication of this document.

Thank you.

Cheers,

Med & Qin

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

Re: [alto] WGLC for draft-ietf-alto-oam-yang (Ends 26/03/2023)

2023-03-21 Thread mohamed.boucadair

Hi all,

This is a gentle reminder that this WGLC is still running.

Silence does not mean that the document is in good shape. So, please review and
share your comments. If you are happy with the current version, that's also a
good feedback we would like to hear.

FWIW, there are:

* 5 Closed WGLC PRs:
https://github.com/ietf-wg-alto/draft-ietf-alto-oam-yang/pulls?q=is%3Apr+is%3Aclosed+label%3AWGLC
* 2 Closed WGLC Issues:
https://github.com/ietf-wg-alto/draft-ietf-alto-oam-yang/issues?q=is%3Aissue+is%3Aclosed+label%3AWGLC
* 9 Open WGLC Issues:
https://github.com/ietf-wg-alto/draft-ietf-alto-oam-yang/issues?q=is%3Aissue+is%3Aopen+label%3AWGLC

Thank you.

Cheers,
Qin & Med

De : BOUCADAIR Mohamed INNOV/NET
Envoyé : dimanche 12 mars 2023 19:42
À : 'alto@ietf.org' ; 'draft-ietf-alto-oam-y...@ietf.org'

Cc : 'alto-cha...@ietf.org'
Objet : RE: WGLC for draft-ietf-alto-oam-yang (Ends 26/03/2023)

Re-,

FWIW, issues/PRs may be also raised using the github repo. Please use "WGLC"
label when entering your items.

The current active WGLC comments can be seen at:
https://github.com/ietf-wg-alto/draft-ietf-alto-oam-yang/issues?q=is%3Aissue+is%3Aopen+label%3AWGLC

Cheers,
Med

De : BOUCADAIR Mohamed INNOV/NET
Envoyé : dimanche 12 mars 2023 19:23
À : alto@ietf.org; 'draft-ietf-alto-oam-y...@ietf.org'
mailto:draft-ietf-alto-oam-y...@ietf.org>>
Cc : alto-cha...@ietf.org
Objet : WGLC for draft-ietf-alto-oam-yang (Ends 26/03/2023)

Hi all,

This message starts the WGLC for
https://datatracker.ietf.org/doc/html/draft-ietf-alto-oam-yang-06. The call
ends: 26/03/2023.

Please review and indicate your support or objection to proceed with the
publication of this document.

Thank you.

Cheers,
Qin & Med

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

Re: [alto] [art] Second early ART ART review of draft-ietf-alto-new-transport (-07)

2023-03-17 Thread mohamed.boucadair

Hi Spencer,

Thanks for providing the review in a timely manner. Much appreciated.

Unless I’m mistaken, the review was not forwarded to the ALTO WG list. I’m
adding the missing lists, fwiw.

One quick comment on your previous comment about SETTINGS_ENABLE_PUSH, I
remember the authors provided a detailed discussion of the issues your raised
(see Slide 13 of
https://datatracker.ietf.org/meeting/114/materials/slides-114-alto-alto-over-new-transport-01).

Cheers,
Med

De : art De la part de Spencer Dawkins at IETF
Envoyé : vendredi 17 mars 2023 00:53
À : a...@ietf.org
Objet : [art] Second early ART ART review of draft-ietf-alto-new-transport (-07)

This is my second early review of this document - the first was a review of -01.

My "Ready with Issues" is based solely on the number of references to HTTP/3
server PUSH usage, which was tagged in my earlier review.

Beyond that, and the following nits, the document was easy and pleasant for me
to follow.

Best wishes to the working group!

I know a lot of things changed in this draft since I early-reviewed -01 - I'm
now early-reviewing -07 - but I'm not sure that my previous observation about
this HTTP setting

0x02 SETTINGS_ENABLE_PUSH (a BCP14 “MUST”)

has been addressed.

As I pointed out in my previous review RFC 9114 reserves this value in the
parallel HTTP/3 registry
(https://www.rfc-editor.org/rfc/rfc9114.html#iana-setting-table), and says this
about these reserved values in
https://www.rfc-editor.org/rfc/rfc9114.html#section-7.2.4.1:

7.2.4.1.
Defined SETTINGS
Parameters

Setting identifiers that were defined in
[HTTP/2] where there is no
corresponding HTTP/3 setting have also been reserved (Section
11.2.2). These
reserved settings MUST NOT be sent, and their receipt MUST be treated as a
connection error of type
H3_SETTINGS_ERROR.¶

I don't know what needs to be changed in this specification to reflect this,
but even the abstract and the last paragraph of the Introduction refer to
"native HTTP/2 or HTTP/3 server push".

Section 2.4 and 2.5 address the use of TIPS inside an HTTP/1.x connection,
which doesn't support server push, so I know you folks have thought about how
that works.Do you need to address this for HTTP/3 as well?

More strategically, should you be encouraging clients to add support for server
PUSH in a new application protocol, if it's already been removed from HTTP/3?
But I see this document is in WGLC now, so you can think about that and Do The
Right Thing.

I have some BCP 14 questions about this text in

3.3.

Uses

This set may be any subset of the ALTO server's network information resources
and may include resources defined in linked IRDs. However, it is RECOMMENDED
that the ALTO server selects a set that is closed under the resource dependency
relationship. That is, if a TIPS' "uses" set includes resource R1 and resource
R1 depends on ("uses") resource R0, then the TIPS' "uses" set SHOULD include R0
as well as R1. For example, a TIPS for a cost map SHOULD also provide a TIPS
view for the network map upon which that cost map depends.

I have the same question about R1 and R0, but let's start with a specific case.
If a TIPS for a cost map does not also provide a TIPS view for the underlying
network map, what happens next?

(Nit) is there a missing term after TIPS in "a TIPS for a cost map" in this
paragraph?

In 4.4.

Close
Request

An ALTO client can indicate it no longer desires to pull/receive updates for a
specific network resource by "deleting" the TIPS view using the returned
tips-view-uri and the HTTP DELETE method. Whether or not the server actually
deletes the TIPS view is implementation dependent. Likely, a server will remove
the client from a dependency set associated with the TIPS view. A server will
not want to delete a TIPS view if another client is using it.

I'm guessing here, but this looks like it's conflating client usage with server
storage management. If client A says "delete the TIPS view", and no other
client is using it, that view is deleted, but if another client is using it,
and the view is not deleted, what happens next? I could imagine that a server
might delete the un

Re: [alto] Tsvart early review of draft-ietf-alto-new-transport-07

2023-03-16 Thread mohamed.boucadair

Hi Bernard, 

Many thanks for the prompt review. Much appreciated! 

To ease tracking the points you raised, I created three issues at 
https://github.com/ietf-wg-alto/draft-ietf-alto-new-transport/labels/tsvart. 
One of these points is related to a pending comment to clarify to what extent 
the current design adheres to RFC9205, especially the considerations related to 
the versioning.  

I trust the authors will engage soon, preferably by addressing separately each 
of the three key issues. Thanks.

Cheers,
Med

> -Message d'origine-
> De : Bernard Aboba via Datatracker 
> Envoyé : mercredi 15 mars 2023 21:49
> À : tsv-...@ietf.org
> Cc : alto@ietf.org; draft-ietf-alto-new-transport@ietf.org
> Objet : Tsvart early review of draft-ietf-alto-new-transport-07
> 
> Reviewer: Bernard Aboba
> Review result: Not Ready
> 
> This is an early review of draft-ietf-alto-new-transport-07
> 
> The comments below are coming from a perspective based on recent
> work on media delivery over QUIC in which scalable video coding
> can be combined with HTTP/3 and/or WebTransport features
> supporting partial reliability so as to deliver media that is both
> resilient as well as low-latency.  However, the considerations
> described below may not apply to ALTO, so please feel free to
> ignore them if they make no sense.
> 
> Overall, the document does not lay out the transport requirements
> explicitly, and so it is hard for me to tell whether the proposed
> design is optimal or not.
>  In particular, it would be useful to understand the desired
> reliability vs.
> latency tradeoff, as well as the requirements for backward
> compatibility (e.g.
> need to operate over HTTP 1.x as well as HTTP/2 and HTTP/3).
> 
> There seems to be a requirement for the protocol to support HTTP
> 1.x as well as
> HTTP/2 and HTTP/3, but this is not stated explicitly, nor is it
> justified. In other WGs desiring to use the new capabilities of
> HTTP/3, a decision has sometimes been made to limit the level of
> backward compatibility (e.g. support for HTTP/3 and HTTP/2 only)
> in order to make it possible to take full advantage of the
> features of HTTP/3.  This decision is easier to make for a new
> protocol than for one which already has significant HTTP 1.x
> deployment. So if the transport approach used here is contrained
> by the existing HTTP/1.x deployments, it would be useful to say so
> up front.
> 
> Also, the requirements for reliability and latency are not
> explicitly laid out.
> The diagrams show incremental update N+1 always depending on
> update N.  Is this an inherent limitation imposed to meet a
> requirement, or is it a choice that could potentially be modified?
> For example, do bad things happen if a client were to obtain a
> coherent set of information at times N and N+2 but not at time
> N+1? Or would it be better to delay receipt of the N+2 info so as
> to
> N+allow for
> the retransmission of N+1 info?
> 
> There is a tradeoff between latency and reliability that can be
> made if layered coding can be permitted.  For example, if it is
> possible to modify the dependencies, a client wouldn't necessarily
> have to obtain every update (e.g.
> if the bandwidth was insufficient to allow them all to be
> delivered within the required time frame).
> 
> Are there circumstances where such a tradeoff would be desirable?
> As an example, there could be a base layer of updates where update
> N+2 depends on update N, and an extension layer (with higher
> update frequency) where update
> N+1 depends on update N.  The client could request both layers if
> it
> N+could
> handle the higher frequency, or just the base layer if it could
> not. A diagram describing this kind of two-layer dependency
> structure is here:
> https://www.w3.org/TR/webrtc-svc/#L1T2*
> 
> ALthough such an approach does have lower coding efficiency, it
> can potentially respond better to situations in which the client's
> bandwidth availability can vary substantially, by taking fuller
> advantage of HTTP/3, allowing the client to restore sync even if a
> "discardable" update were not delivered, as long as the stream of
> "non-discardable" updates could be delivered.
> 


_

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 erro

Re: [alto] WGLC for draft-ietf-alto-new-transport (Ends 28/03/2023)

2023-03-14 Thread mohamed.boucadair

Hi Luis,

Yes, you are right. The correct link is: 
https://datatracker.ietf.org/doc/html/draft-ietf-alto-new-transport-07.

Cheers,
Med

De : alto  De la part de LUIS MIGUEL CONTRERAS MURILLO
Envoyé : mardi 14 mars 2023 23:23
À : Qin Wu ; IETF ALTO 
Cc : ALTO Working Group 
Objet : Re: [alto] WGLC for draft-ietf-alto-new-transport (Ends 28/03/2023)

Hi Qin

The link provided redirects to 
https://datatracker.ietf.org/doc/html/draft-ietf-alto-oam-yang-06 instead of 
new transport draft. I assume the subject is correct and the WG LC is against 
new transport, correct? Just to be dure and reviewing the correct draft to 
answer this LC.

Thanks

Luis

De: alto mailto:alto-boun...@ietf.org>> En nombre de Qin 
Wu
Enviado el: martes, 14 de marzo de 2023 2:06
Para: IETF ALTO mailto:alto@ietf.org>>
CC: ALTO Working Group mailto:alto-cha...@ietf.org>>
Asunto: [alto] WGLC for draft-ietf-alto-new-transport (Ends 28/03/2023)


Hi, All

This message starts 2 weeks WGLC for 
https://datatracker.ietf.org/doc/html/draft-ietf-alto-new-transport-07.
 The call ends: 28/03/2023.



Please review and indicate your support or objection to proceed with the 
publication of this document.



Thank you.



Cheers,

Med & Qin




Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede 
contener información privilegiada o confidencial y es para uso exclusivo de la 
persona o entidad de destino. Si no es usted. el destinatario indicado, queda 
notificado de que la lectura, utilización, divulgación y/o copia sin 
autorización puede estar prohibida en virtud de la legislación vigente. Si ha 
recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente 
por esta misma vía y proceda a su destrucción.

The information contained in this transmission is confidential and privileged 
information intended only for the use of the individual or entity named above. 
If the reader of this message is not the intended recipient, you are hereby 
notified that any dissemination, distribution or copying of this communication 
is strictly prohibited. If you have received this transmission in error, do not 
read it. Please immediately reply to the sender that you have received this 
communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode 
conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa 
ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica 
notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização 
pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem 
por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e 
proceda a sua destruição

_

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

Re: [alto] WGLC for draft-ietf-alto-new-transport (Ends 28/03/2023)

2023-03-14 Thread mohamed.boucadair

Hi all,

WGLC comments can also be reported as github issues/PRs. Please use "WGLC"
label when filling your issues/PR.

FYI, the reported WGLC comments can be seen at:
https://github.com/ietf-wg-alto/draft-ietf-alto-new-transport/issues?q=is%3Aissue+is%3Aopen+label%3AWGLC.

Cheers,
Med

De : Qin Wu
Envoyé : mardi 14 mars 2023 02:06
À : IETF ALTO
Cc : ALTO Working Group ; BOUCADAIR Mohamed INNOV/NET

Objet : WGLC for draft-ietf-alto-new-transport (Ends 28/03/2023)

Hi, All

This message starts 2 weeks WGLC for
https://datatracker.ietf.org/doc/html/draft-ietf-alto-new-transport-07.
The call ends: 28/03/2023.

Please review and indicate your support or objection to proceed with the
publication of this document.

Thank you.

Cheers,

Med & Qin

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

Re: [alto] WGLC for draft-ietf-alto-oam-yang (Ends 26/03/2023)

2023-03-12 Thread mohamed.boucadair

Re-,

FWIW, issues/PRs may be also raised using the github repo. Please use "WGLC"
label when entering your items.

The current active WGLC comments can be seen at:
https://github.com/ietf-wg-alto/draft-ietf-alto-oam-yang/issues?q=is%3Aissue+is%3Aopen+label%3AWGLC

Cheers,
Med

De : BOUCADAIR Mohamed INNOV/NET
Envoyé : dimanche 12 mars 2023 19:23
À : alto@ietf.org; 'draft-ietf-alto-oam-y...@ietf.org'

Cc : alto-cha...@ietf.org
Objet : WGLC for draft-ietf-alto-oam-yang (Ends 26/03/2023)

Hi all,

This message starts the WGLC for
https://datatracker.ietf.org/doc/html/draft-ietf-alto-oam-yang-06. The call
ends: 26/03/2023.

Please review and indicate your support or objection to proceed with the
publication of this document.

Thank you.

Cheers,
Qin & Med

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

[alto] WGLC for draft-ietf-alto-oam-yang (Ends 26/03/2023)

2023-03-12 Thread mohamed.boucadair

Hi all,

This message starts the WGLC for 
https://datatracker.ietf.org/doc/html/draft-ietf-alto-oam-yang-06. The call 
ends: 26/03/2023.

Please review and indicate your support or objection to proceed with the 
publication of this document.

Thank you.

Cheers,
Qin & Med

_

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] draft-ietf-alto-oam-yang implementations

2023-03-03 Thread mohamed.boucadair

Hi all,

Can you please share details about any implementations you are aware of this 
draft? Thank you.

Cheers,
Med

_

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

Re: [alto] IPR Poll: draft-ietf-alto-new-transport

2023-03-03 Thread mohamed.boucadair

Hi all,

It seems that we have all replies expect from Lachlan and Lauren.

Lauren/Lachlan, we would appreciate if you can reply to this poll in a timely 
manner. Thanks.

Cheers,
Med

De : alto  De la part de kai...@scu.edu.cn
Envoyé : jeudi 2 mars 2023 09:10
À : Y. Richard Yang 
Cc : roland.sch...@telekom.de; draft-ietf-alto-new-transp...@ietf.org; 
alto@ietf.org
Objet : Re: [alto] IPR Poll: draft-ietf-alto-new-transport


Hi Med and all,



I am not aware of any IPR related to draft-ietf-alto-new-transport.



Best,

Kai



-Original Messages-
From:"Y. Richard Yang" mailto:y...@cs.yale.edu>>
Sent Time:2023-02-28 03:04:29 (Tuesday)
To: roland.sch...@telekom.de
Cc: 
draft-ietf-alto-new-transp...@ietf.org,
 alto@ietf.org
Subject: Re: [alto] IPR Poll: draft-ietf-alto-new-transport
Hi Med, all,

Same from me: I am not aware of any IPR related to 
draft-ietf-alto-new-transport.

Thanks,
Richard

On Mon, Feb 27, 2023 at 10:07 AM 
mailto:roland.sch...@telekom.de>> wrote:
Hi,

I am not aware of any IPR related to draft-ietf-alto-new-transport.

Best Regards

Roland


Von: mohamed.boucad...@orange.com 
mailto:mohamed.boucad...@orange.com>>
Gesendet: Montag, 27. Februar 2023 14:58
An: 
draft-ietf-alto-new-transp...@ietf.org
Cc: 'alto@ietf.org' mailto:alto@ietf.org>>
Betreff: IPR Poll: draft-ietf-alto-new-transport

Hi Authors,

Please reply to this email (with the WG mailing list cced) indicating whether 
you are aware of any IPR related to draft-ietf-alto-new-transport.

If you are aware of any, can you please confirm that all appropriate IPR 
disclosures required for full conformance with the provisions of BCP 78 and BCP 
79 have already been filed?

Thank you.

Cheers,
Qin & Med


_



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


--
--
 =
| Y. Richard Yang mailto:y...@cs.yale.edu>>   |
| Professor of Computer Science   |
| http://www.cs.yale.edu/~yry/|
 =

_

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] IPR poll: draft-ietf-alto-oam-yang

2023-02-27 Thread mohamed.boucadair

Hi Authors,

Please reply to this email (with the WG mailing list cced) indicating whether 
you are aware of any IPR related to draft-ietf-alto-oam-yang.

If you are aware of any, can you please confirm that all appropriate IPR 
disclosures required for full conformance with the provisions of BCP 78 and BCP 
79 have already been filed?

Thank you.

Cheers,
Qin & Med

_

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] IPR Poll: draft-ietf-alto-new-transport

2023-02-27 Thread mohamed.boucadair

Hi Authors,

Please reply to this email (with the WG mailing list cced) indicating whether 
you are aware of any IPR related to draft-ietf-alto-new-transport.

If you are aware of any, can you please confirm that all appropriate IPR 
disclosures required for full conformance with the provisions of BCP 78 and BCP 
79 have already been filed?

Thank you.

Cheers,
Qin & Med


_

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

Re: [alto] I-D Action: draft-ietf-alto-new-transport-05.txt

2023-02-08 Thread mohamed.boucadair

Hi Roland, Richard, Kai, and Lachlan, 

Thank you for preparing this revised version. 

Can you please share with the WG a summary/reasoning of major changes and a 
status of the pending issues for this spec? Thanks much for your effort. 

Cheers,
Med

> -Message d'origine-
> De : I-D-Announce  De la part de
> internet-dra...@ietf.org
> Envoyé : mardi 7 février 2023 00:29
> À : i-d-annou...@ietf.org
> Cc : alto@ietf.org
> Objet : I-D Action: draft-ietf-alto-new-transport-05.txt
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Application-Layer Traffic
> Optimization WG of the IETF.
> 
> Title   : ALTO Transport Information Publication
> Service
> Authors : Roland Schott
>   Y. Richard Yang
>   Kai Gao
>   Lachlan Keller
>   Filename: draft-ietf-alto-new-transport-05.txt
>   Pages   : 32
>   Date: 2023-02-06
> 
> Abstract:
>The ALTO base protocol [RFC7285] is based on HTTP/1.x, designed
> for
>the simple, sequential request-reply use case, in which an ALTO
>client requests a sequence of information resources, and the
> server
>sends the complete content of each information resource to the
> client
>one by one.  To support the use case that an ALTO client can
> monitor
>multiple resources at the same time and the ALTO server sends
> only
>their updates, the ALTO Working Group introduced ALTO/SSE
> [RFC8895],
>which defines a new, SSE-based multiplexing protocol on top of
>HTTP/1.x, to allow the server to concurrently, and
> incrementally push
>updates to the client whenever monitored network information
>resources change.  However, newer versions of HTTP (e.g.,
> HTTP/2
>[RFC7540]) already support concurrent, non-blocking transport
> of
>multiple streams in the same HTTP connection.  This document
>introduces the ALTO transport information publication service
> (TIPS),
>which allows the naming of (i.e., assigning resource
> identifiers to)
>individual incremental updates to multiple ALTO information
> resources
>and the distribution of the naming, enabling ALTO to take
> advantage
>of newer HTTP versions.  In particular, it gives an ALTO client
> the
>new capability to explicitly request (pull) a specific
> incremental
>update.  It also provides an ALTO server the new capability to
> push a
>specific incremental update using native HTTP/2 or HTTP/3
> server
>push.  This document defines TIPS as a service, independent of
> client
>pull or server push.  A companion document
>[draft-schott-alto-new-transport-push] defines the complete
> server-
>push ALTO transport based on ALTO TIPS.
> 
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-alto-new-transport/
> 
> There is also an HTML version available at:
> https://www.ietf.org/archive/id/draft-ietf-alto-new-transport-
> 05.html
> 
> A diff from the previous version is available at:
> https://author-tools.ietf.org/iddiff?url2=draft-ietf-alto-new-
> transport-05
> 
> 
> Internet-Drafts are also available by rsync at
> rsync.ietf.org::internet-drafts
> 
> 
> ___
> I-D-Announce mailing list
> i-d-annou...@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html or
> ftp://ftp.ietf.org/ietf/1shadow-sites.txt

_

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

Re: [alto] Presenting ALTO-related work at MOPS WG on Friday

2022-07-29 Thread mohamed.boucadair

Hi all,

The slides that are presented by Luis can be seen at:
https://datatracker.ietf.org/meeting/114/materials/slides-114-mops-exposure-of-telefonica-network-topology-through-alto-for-integration-with-telefonica-cdn/

Cheers,
Med

De : alto De la part de LUIS MIGUEL CONTRERAS MURILLO
Envoyé : lundi 25 juillet 2022 23:32
À : 'alto@ietf.org'
Objet : [alto] Presenting ALTO-related work at MOPS WG on Friday

Dear ALTOers,

For those interested, next Friday at MOPS WG I will have the opportunity to
present the work in Telefonica for the integration of ALTO as a way of exposing
topology information to Telefonica CDN.

The session is entitled "Exposure of Telefonica network topology through ALTO
for integration with Telefonica CDN"
(https://datatracker.ietf.org/meeting/114/materials/agenda-114-mops-02.txt).

Best regards

Luis

__
Luis M. Contreras

Transport & IP Networks
Systems and Network Global Direction
Telefónica I+D / CTIO unit / Telefónica

Distrito Telefónica, Edificio Sur 3, Planta 3
28050 Madrid
España / Spain

Mobile: +34 680 947 650
luismiguel.contrerasmuri...@telefonica.com

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede
contener información privilegiada o confidencial y es para uso exclusivo de la
persona o entidad de destino. Si no es usted. el destinatario indicado, queda
notificado de que la lectura, utilización, divulgación y/o copia sin
autorización puede estar prohibida en virtud de la legislación vigente. Si ha
recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente
por esta misma vía y proceda a su destrucción.

The information contained in this transmission is confidential and privileged
information intended only for the use of the individual or entity named above.
If the reader of this message is not the intended recipient, you are hereby
notified that any dissemination, distribution or copying of this communication
is strictly prohibited. If you have received this transmission in error, do not
read it. Please immediately reply to the sender that you have received this
communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode
conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa
ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica
notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização
pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem
por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e
proceda a sua destruição

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

Re: [alto] Cellular information exposure discussion (Fwd: New Version Notification for draft-huang-alto-mowie-for-network-aware-app-04.txt

2022-07-20 Thread mohamed.boucadair

Re-,

Thank you, Yixue.

BTW, as part of your SoA you may consider listing (analyzing?) some proposals
that were made in the past to address similar issues, e.g.,

*
https://datatracker.ietf.org/doc/html/draft-sprecher-mobile-tg-exposure-req-arch-03
*
https://datatracker.ietf.org/doc/html/draft-flinck-mobile-throughput-guidance-04

cheers,
Med

De : Lei Yixue
Envoyé : mercredi 20 juillet 2022 10:37
À : BOUCADAIR Mohamed INNOV/NET
Cc : Y. Richard Yang ; IETF ALTO ;
yanniszh...@tencent.com
Objet : Re: [alto] Cellular information exposure discussion (Fwd: New Version
Notification for draft-huang-alto-mowie-for-network-aware-app-04.txt

Dear Med and all,

Thanks for the review and comments which gives some very good hints. We will
analyze and incorporate in next version.

If other experts have any further comments, please provide over either v04 or
v04 plus Med's comments. We will take on board all comments together.

Thanks a lot!
Br, Yixue from Tencent

mailto:mohamed.boucad...@orange.com>>
于2022年7月20日周三 15:40写道：
Hi Eric, Richard, all,

Thank you for sharing these details.

FWIW, you may find some very few comments on the first part of the draft at:

* pdf:
https://github.com/boucadair/IETF-Drafts-Reviews/raw/master/draft-huang-alto-mowie-for-network-aware-app-04-rev%20Med.pdf
* doc:
https://github.com/boucadair/IETF-Drafts-Reviews/raw/master/draft-huang-alto-mowie-for-network-aware-app-04-rev%20Med.doc

Cheers,
Med

De : Eric mailto:kinderboy2...@gmail.com>>
Envoyé : mercredi 20 juillet 2022 04:13
À : Y. Richard Yang mailto:yang.r.y...@yale.edu>>
Cc : BOUCADAIR Mohamed INNOV/NET
mailto:mohamed.boucad...@orange.com>>; IETF ALTO
mailto:alto@ietf.org>>
Objet : Re: [alto] Cellular information exposure discussion (Fwd: New Version
Notification for draft-huang-alto-mowie-for-network-aware-app-04.txt

Hi Richard and Med,

This is Yixue from Tencent who works in 3GPP for 15 years but new to IETF.___^
. But actually from years ago, even in my Ph. D study, I like reading some
IETF and IRTF drafts and several years ago,I have noticed ALTO WG in IETF as
in Tencent my research and standard interests are focusing on how application
and network could coordinate.

Regarding to the Med's question on whether the proposed extensions are being
discussed in 3GPP, let me try to give a brief answer.

As we know, 3GPP has continuous efforts on network exposure even from 4G. In
5G, network exposure is a native feature and in Rel-17 and Rel-18 there are
particular interest on how network exposure is utilized to optimized advanced
interactive services (like cloud gaming, AR, VR etc). From our point of view,
the main technical reason is that for these application, there are more
challenges which require more collaboration between application layer and
network layer to overcome. Just as we summarized in MoWIE draft 04, 3GPP and
also ETSI are working on some mechanism to enable network exposure in a
step-wise approach.

Meanwhile, 3GPP is mainly focusing on standards within 5G system, in many
cases, there is inevitable case that the application servers may be deployed at
the data network outside 5G system gateway (i.e. UPF), to achieve end-to-end
application optimization, have some corresponding standard work in IETF is also
important from our view.

To be more specific, by doing some cellular information exposing work in 3GPP,
in addition to the parameters within 5G system, some 3GPP defined
functionalities like AF, NEF, can have some ALTO related functions to support
cellular network information exposure to applications. How application layer
utilize the exposed information to optimize user experience is not standardized
in 3GPP which I also think may be considered in IETF. I think this has been
reflected by C1~C3 which Richard has listed in previous e-mail.

Thanks a lot!
Br, Yixue from Tencent

Y. Richard Yang mailto:yang.r.y...@yale.edu>>
于2022年7月20日周三 04:02写道：
Hi Med,

There are some efforts in 3GPP; the mowie draft discussed related 3GPP efforts.
I will let Tencent team (Yannis, Yixue, Yuhang) to give more info. I do not
believe there are related efforts in W2; that is, shorten the feedback loop
from passthrough-bounce to direct send. Zili can give an update. I see that we
need coordination with 3GPP, and we will reach out to include those at 3GPP
with related efforts and include them in the email thread. Is this you would
suggest?

Thanks!
Richard

On Tue, Jul 19, 2022 at 12:19 PM
mailto:mohamed.boucad...@orange.com>> wrote:
Hi Richard,

Thanks for this information.

Just out of curiosity, are the proposed extensions currently discussed in the
3GPP?

Cheers,
Med

De : alto mailto:alto-boun...@ietf.org>> De la part de
Y. Richard Yang
Envoyé : mardi 19 juillet 2022 20:14
À : IETF ALTO mailto:alto@ietf.org>>
Objet : [alto] Cellular information exposure discussion (Fwd: New Version
Notification for draft-huang-alto-mowie-for-network-aware-app-04.txt

Re: [alto] Cellular information exposure discussion (Fwd: New Version Notification for draft-huang-alto-mowie-for-network-aware-app-04.txt

2022-07-20 Thread mohamed.boucadair

Hi Eric, Richard, all,

Thank you for sharing these details.

FWIW, you may find some very few comments on the first part of the draft at:

Cheers,
Med

De : Eric
Envoyé : mercredi 20 juillet 2022 04:13
À : Y. Richard Yang
Cc : BOUCADAIR Mohamed INNOV/NET ; IETF ALTO

Objet : Re: [alto] Cellular information exposure discussion (Fwd: New Version
Notification for draft-huang-alto-mowie-for-network-aware-app-04.txt

Hi Richard and Med,

Regarding to the Med's question on whether the proposed extensions are being
discussed in 3GPP, let me try to give a brief answer.

Thanks a lot!
Br, Yixue from Tencent

Y. Richard Yang mailto:yang.r.y...@yale.edu>>
于2022年7月20日周三 04:02写道：
Hi Med,

Thanks!
Richard

On Tue, Jul 19, 2022 at 12:19 PM
mailto:mohamed.boucad...@orange.com>> wrote:
Hi Richard,

Thanks for this information.

Just out of curiosity, are the proposed extensions currently discussed in the
3GPP?

Cheers,
Med

Hi ALTO WG,

During the weekly meeting today, the design team discussed about the document,
and suggested that the authors update the WG on a new version of the MOWIE
draft, which was uploaded last week and focuses on cellular network information
exposure to network-aware applications. The links to the new version and the
diff showing the updates can be found below. Any comments, feedback, or
interests in working together are welcome and greatly appreciated.

Using this email, we also want to include that there are two quite relevant
pieces of work:
W1. PBE-CC: Congestion Control via Endpoint-Centric, Physical-Layer Bandwidth
Measurements (https://arxiv.org/abs/2002.03475), by Yaxiong Xie, Prof.
Jamieson, and Prof. Rexford;
W2. Achieving Consistent Low Latency for Wireless Real-Time Communications with
the Shortest Control Loop (paper to be made public soon), by Zili, and Prof.
Mingwei and team.

It helps to use this email to point out a bigger picture of the problem space
and related work. One perspective is that the problem space consists of 3
components:
C1. What cellular-network information should be collected to be sent to the
appli

Re: [alto] Cellular information exposure discussion (Fwd: New Version Notification for draft-huang-alto-mowie-for-network-aware-app-04.txt

2022-07-19 Thread mohamed.boucadair

Hi Richard,

Thanks for this information.

Just out of curiosity, are the proposed extensions currently discussed in the 
3GPP?

Cheers,
Med

De : alto  De la part de Y. Richard Yang
Envoyé : mardi 19 juillet 2022 20:14
À : IETF ALTO 
Objet : [alto] Cellular information exposure discussion (Fwd: New Version 
Notification for draft-huang-alto-mowie-for-network-aware-app-04.txt


Hi ALTO WG,

During the weekly meeting today, the design team discussed about the document, 
and suggested that the authors update the WG on a new version of the MOWIE 
draft, which was uploaded last week and focuses on cellular network information 
exposure to network-aware applications. The links to the new version and the 
diff showing the updates can be found below. Any comments, feedback, or 
interests in working together are welcome and greatly appreciated.

Using this email, we also want to include that there are two quite relevant 
pieces of work:
W1. PBE-CC: Congestion Control via Endpoint-Centric, Physical-Layer Bandwidth 
Measurements (https://arxiv.org/abs/2002.03475), by Yaxiong Xie, Prof. 
Jamieson, and Prof. Rexford;
W2. Achieving Consistent Low Latency for Wireless Real-Time Communications with 
the Shortest Control Loop (paper to be made public soon), by Zili, and Prof. 
Mingwei and team.

It helps to use this email to point out a bigger picture of the problem space 
and related work. One perspective is that the problem space consists of 3 
components:
C1. What cellular-network information should be collected to be sent to the 
applications?
C2. How is the cellular information sent to the applications?
C3. How do the applications use the information?

It is important to note that the full exploration of the problem space is not 
included in the current charter. However, this is an important problem space 
and hence it helps  to keep track of the progress and potential impacts on ALTO.

For C1, the impact will be the list of performance metrics. For C3, the current 
ALTO charter does not include items to define application behaviors, but it can 
be a point of discussion related to deployment.

The most relevant component is C2. We discussed the following design points for 
C2:
D-broadcast: network broadcasts its state
D-pass-bounce: network marks its state on pass-through packets and the receiver 
bounces the state back to the sender
D-direct-send: network sends its state to app directly
Here by state it can be transformed state.

Current ALTO is designed as D-direct-send. Due to lacking of deployment of 
D-direct-send in cellular network, aforementioned W1 uses D-broadcast; the 
D-pass-bounce design need at least a round trip time and couples network 
feedback flow with data flow, leading to the aforementioned W2 work.

Many of us feel that the time is ready for introducing a highly efficient, 
flexible channel for network state exposure to applications, led by IETF, and 
the ALTO team can be a good starting point. As a first step, a systematic 
evaluation, which (1) surveys the design space and (2) introduces the use 
cases/benchmarking scenarios, can be a good starting point.

If there is time available in the coming 114 meeting, we can discuss more 
during the presentation. Otherwise, on-list discussion is a good starting 
point. We will follow up with more analysis on the list soon but use this email 
to get the conversation started.

Thanks,

Richard on behalf of Tuesday meeting team



-- Forwarded message -
From: mailto:internet-dra...@ietf.org>>
Date: Mon, Jul 11, 2022 at 2:14 PM
Subject: New Version Notification for 
draft-huang-alto-mowie-for-network-aware-app-04.txt
To: Y. Richard Yang mailto:yang.r.y...@yale.edu>>, Gang 
Li mailto:ligan...@chinamobile.com>>, Sabine 
Randriamasy 
mailto:sabine.randriam...@nokia-bell-labs.com>>,
 Yixue Lei mailto:yixue...@tencent.com>>, Yuhang Jia 
mailto:tony...@tencent.com>>, Yunbo Han 
mailto:yunbo...@tencent.com>>, Yunfei Zhang 
mailto:yanniszh...@tencent.com>>



A new version of I-D, draft-huang-alto-mowie-for-network-aware-app-04.txt
has been successfully submitted by Y. Richard Yang and posted to the
IETF repository.

Name:   draft-huang-alto-mowie-for-network-aware-app
Revision:   04
Title:  MoWIE for Network Aware Applications
Document date:  2022-07-11
Group:  Individual Submission
Pages:  25
URL:
https://www.ietf.org/archive/id/draft-huang-alto-mowie-for-network-aware-app-04.txt
Status: 
https://datatracker.ietf.org/doc/draft-huang-alto-mowie-for-network-aware-app/
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-huang-alto-mowie-for-network-aware-app
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-huang-alto-mowie-for-network-aware-app-04

Abstract:
   With the quick deployment of 5G networks in the world, cloud-based
   interactive applications (services) such as cloud gaming have gained
   substantial attention and are regarded as potential killer
   applications.  T

[alto] Some comments about draft-lcsr-alto-service-functions-01

2022-07-19 Thread mohamed.boucadair

Hi Luis, Sabine, and Xufeng,

Thank you for editing this draft.

FWIW, you may find some comments at:


  *   pdf: 
https://github.com/boucadair/IETF-Drafts-Reviews/raw/master/draft-lcsr-alto-service-functions-01-rev%20Med.pdf
  *   doc: 
https://github.com/boucadair/IETF-Drafts-Reviews/raw/master/draft-lcsr-alto-service-functions-01-rev%20Med.doc

Cheers,
Med

_

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] Some comments about draft-xing-alto-sdn-controller-aware-mptcp-mpquic

2022-07-19 Thread mohamed.boucadair

Hi Ziyang, all,

Thank you for the effort put into this document. Really cool to see concrete 
proposals that use ALTO to feed a network intelligence.

FWIW, you can find some comments to your draft at:


  *   pdf: 
https://github.com/boucadair/IETF-Drafts-Reviews/raw/master/draft-xing-alto-sdn-controller-aware-mptcp-mpquic-05-rev%20Med.pdf
  *   doc: 
https://github.com/boucadair/IETF-Drafts-Reviews/raw/master/draft-xing-alto-sdn-controller-aware-mptcp-mpquic-05-rev%20Med.doc

Hope this helps.

Cheers,
Med

_

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

Re: [alto] I-D Action: draft-ietf-alto-new-transport-00.txt

2022-06-22 Thread mohamed.boucadair

Hi all, 

FWIW, we requested an early artart review to seek for feedback, particularly 
about the handling of versioning. We indicated 06/07 as target deadline so that 
comments can be digested, and hopefully a revised version is made available 
before the next IETF meeting.

We prefer to have this review available early in the process to avoid late 
surprises. 

Cheers,
Med

> -Message d'origine-
> De : I-D-Announce  De la part de
> internet-dra...@ietf.org
> Envoyé : mercredi 22 juin 2022 09:58
> À : i-d-annou...@ietf.org
> Cc : alto@ietf.org
> Objet : I-D Action: draft-ietf-alto-new-transport-00.txt
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Application-Layer Traffic
> Optimization WG of the IETF.
> 
> Title   : ALTO/H2: The ALTO Protocol using HTTP/2
> Authors : Roland Schott
>   Y. Richard Yang
>   Kai Gao
>   Jingxuan Jensen Zhang
>   Filename: draft-ietf-alto-new-transport-00.txt
>   Pages   : 24
>   Date: 2022-06-22
> 
> Abstract:
>The ALTO base protocol [RFC7285] uses HTTP/1.x as the transport
>protocol and hence ALTO transport includes the limitations of
>HTTP/1.x.  ALTO/SSE [RFC8895] addresses some of the
> limitations, but
>is still based on HTTP/1.x.  This document introduces ALTO new
>transport, which provides the transport functions of ALTO/SSE
> on top
>of HTTP/2, for more efficient ALTO transport.
> 
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-alto-new-transport/
> 
> There is also an HTML version available at:
> https://www.ietf.org/archive/id/draft-ietf-alto-new-transport-
> 00.html
> 
> 
> Internet-Drafts are also available by rsync at
> rsync.ietf.org::internet-drafts
> 
> 
> ___
> I-D-Announce mailing list
> i-d-annou...@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html or
> ftp://ftp.ietf.org/ietf/1shadow-sites.txt

_

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] a separate document for HTTP/3 (was RE: WG adoption call for draft-schott-alto-new-transport-01)

2022-06-13 Thread mohamed.boucadair

Hi Adrian, 

Thank you for the review and comments. 

For the point about H3, we hope that at least common H2/H3 functionalities can 
be covered in this I-D.  

FWIW, we need to be careful about the versioning and keep in mind this part 
from RFC9205:

==
... Requiring a particular
   version of HTTP makes it difficult to use in these situations and
   harms interoperability.  Therefore, it is NOT RECOMMENDED that
   applications using HTTP specify a minimum version of HTTP to be used.

   However, if an application's deployment benefits from the use of a
   particular version of HTTP (for example, HTTP/2's multiplexing), this
   ought be noted.

   Applications using HTTP MUST NOT specify a maximum version, to
   preserve the protocol's ability to evolve.
==

The plan we had for the draft is to request an early artart review seeking 
specifically advice on the HTTP version matters. 

Cheers,
Med

> -Message d'origine-
> De : Adrian Farrel 
> Envoyé : dimanche 12 juin 2022 02:18
> À : alto@ietf.org
> Cc : alto-cha...@ietf.org
> Objet : Re: WG adoption call for draft-schott-alto-new-transport-
> 01
> 
> Hi,
> 
> I've read this draft and it is clearly in scope as it targets one
> of the WG's milestones. I think it is a reasonable starting point
> for this work and should be adopted. (I presume that a separate
> document will address the second half of the milestone, namely
> HTTP/3.)
> 
> 


_

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

Re: [alto] Murray Kucherawy's Discuss on draft-ietf-alto-cost-mode-04: (with DISCUSS and COMMENT)

2022-06-02 Thread mohamed.boucadair

Re-,

Deal!

As you can see at 
https://www.ietf.org/rfcdiff?url2=draft-ietf-alto-cost-mode-05, went with a 
more verbose text to insist on this + add a MUST for implementations.

Thanks.

Cheers,
Med

De : Murray S. Kucherawy 
Envoyé : jeudi 2 juin 2022 08:58
À : BOUCADAIR Mohamed INNOV/NET 
Cc : The IESG ; draft-ietf-alto-cost-m...@ietf.org; 
alto-cha...@ietf.org; alto@ietf.org; kai...@scu.edu.cn
Objet : Re: Murray Kucherawy's Discuss on draft-ietf-alto-cost-mode-04: (with 
DISCUSS and COMMENT)

On Wed, Jun 1, 2022 at 11:54 PM 
mailto:mohamed.boucad...@orange.com>> wrote:
[Med] That wording was on purpose. We could easily turn that text into the 
following:

NEW:
 If the definition of a cost mode does not indicate whether it
 applies to a subset of cost metrics, ALTO implementations
 MUST be prepared to accept that cost mode for any cost metric.

... but there is a high risk that this behavior will overlooked and thus the 
default mode will be the rule. This would have interoperability implications as 
it is likely that some modes can't be associated with all cost metrics.

The SHOULD is some sort of authors guideline to assess the applicability and 
record it.

Hi Mohamed,

Understood.  I suggest using "should" rather than "SHOULD", and then saying 
something like what you just said here to underscore why it's important for 
future documents to go into this.

-MSK

_

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

Re: [alto] Murray Kucherawy's Discuss on draft-ietf-alto-cost-mode-04: (with DISCUSS and COMMENT)

2022-06-01 Thread mohamed.boucadair

Hi Murray, 

Thanks for the review. 

Please see inline. 

Cheers,
Med

> -Message d'origine-
> De : Murray Kucherawy via Datatracker 
> Envoyé : jeudi 2 juin 2022 08:16
> À : The IESG 
> Cc : draft-ietf-alto-cost-m...@ietf.org; alto-cha...@ietf.org;
> alto@ietf.org; kai...@scu.edu.cn
> Objet : Murray Kucherawy's Discuss on draft-ietf-alto-cost-mode-
> 04: (with DISCUSS and COMMENT)
> 
> Murray Kucherawy has entered the following ballot position for
> draft-ietf-alto-cost-mode-04: 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-cost-mode/
> 
> 
> 
> --
> 
> DISCUSS:
> --
> 
> 
> Paul said:
> 
> > I think that SHOULD can be a MUST. Although one could question
> the 2119 usage
> as it seems to be a directive to a document author and not a
> protocol action.
> So I would also be okay with lowercasing this.
> 
> I'm ambivalent about the first sentence, but I concur strongly
> with the second;
> use of BCP 14 language to establish a requirement against some
> future document
> seems quite unconventional to me.  Can we talk about why this is
> necessary
> and/or appropriate?

[Med] That wording was on purpose. We could easily turn that text into the 
following:

NEW:
 If the definition of a cost mode does not indicate whether it
 applies to a subset of cost metrics, ALTO implementations
 MUST be prepared to accept that cost mode for any cost metric.

... but there is a high risk that this behavior will overlooked and thus the 
default mode will be the rule. This would have interoperability implications as 
it is likely that some modes can't be associated with all cost metrics. 

The SHOULD is some sort of authors guideline to assess the applicability and 
record it.  


_

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

Re: [alto] I-D Action: draft-ietf-alto-cost-mode-04.txt

2022-06-01 Thread mohamed.boucadair

Hi Martin, all, 

This version addresses the various IESG reviews.  

Cheers,
Med

> -Message d'origine-
> De : alto  De la part de internet-
> dra...@ietf.org
> Envoyé : jeudi 2 juin 2022 07:30
> À : i-d-annou...@ietf.org
> Cc : alto@ietf.org
> Objet : [alto] I-D Action: draft-ietf-alto-cost-mode-04.txt
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Application-Layer Traffic
> Optimization WG of the IETF.
> 
> Title   : A Cost Mode Registry for the
> Application-Layer Traffic Optimization (ALTO) Protocol
> Authors : Mohamed Boucadair
>   Qin Wu
>   Filename: draft-ietf-alto-cost-mode-04.txt
>   Pages   : 7
>   Date: 2022-06-01
> 
> Abstract:
>This document creates a new IANA registry for tracking cost
> modes
>supported by the Application-Layer Traffic Optimization (ALTO)
>Protocol.  Also, this document relaxes a constraint that was
> imposed
>by the ALTO specification on allowed cost mode values.
> 
>This document updates RFC 7285.
> 
> Editorial Note (To be removed by RFC Editor)
> 
>Please update RFC  statements within the document with the
> RFC
>number to be assigned to this document.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-alto-cost-mode/
> 
> There is also an htmlized version available at:
> https://datatracker.ietf.org/doc/html/draft-ietf-alto-cost-mode-04
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-alto-cost-mode-04
> 
> 
> Internet-Drafts are also available by rsync at
> rsync.ietf.org::internet-drafts
> 
> 
> ___
> alto mailing list
> alto@ietf.org
> https://www.ietf.org/mailman/listinfo/alto

_

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

Re: [alto] Paul Wouters' Discuss on draft-ietf-alto-cost-mode-03: (with DISCUSS and COMMENT)

2022-06-01 Thread mohamed.boucadair

Hi Paul,

Thank you for the review. 

Please see inline. 

Cheers,
Med

> -Message d'origine-
> De : Paul Wouters via Datatracker 
> Envoyé : jeudi 2 juin 2022 05:12
> À : 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 : Paul Wouters' Discuss on draft-ietf-alto-cost-mode-03:
> (with DISCUSS and COMMENT)
> 
> Paul Wouters has entered the following ballot position for
> draft-ietf-alto-cost-mode-03: 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-cost-mode/
> 
> 
> 
> --
> 
> DISCUSS:
> --
> 
> 
> Probably an easily answered issue, but I am not too familiar with
> ALTO.
> 
>  The string MUST be no more than 32 characters, and it MUST
> NOT contain
>  characters other than [...]
> 
> Are there implementations that already deployed a cost string with
> more than 32
> characters or characters not in this newly imposed set of
> characters?

[Med] No. 

 What
> should happen if that is in use? That is, is this protocol
> modification
> potentially breaking interoperability with older implementations?
> 
> 
> --
> 
> COMMENT:
> --
> 
> 
> While no fan of "patch RFCs", thank you for at least putting the
> OLD and NEW
> text in one document, so an implementer and reviewer doesn't have
> to switch
> between documents and get confused about what was read was the old
> doc or new
> doc.
> 
> That said, patching in the text "This document" feels a little
> weird. What RFC
> does "This document" then refer to? Perhaps change "This document
> defines two
> cost modes" to "Two cost modes are defined".

[Med] OK.

> 
>  Future documents that define a new cost mode SHOULD indicate
> 
> I think that SHOULD can be a MUST.

[Med] We don't use MUST here because we do have a default behavior specified in 
the sentence right after: "If not explicitly indicated, the new cost mode 
applies to all cost metrics."

_

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

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

2022-05-31 Thread mohamed.boucadair

Hi Roman,

I confirm. No designated expert is needed here. Thanks. 

Cheers,
Med

> -Message d'origine-
> De : Roman Danyliw via Datatracker 
> Envoyé : mardi 31 mai 2022 17:43
> À : 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 : Roman Danyliw's No Objection on draft-ietf-alto-cost-mode-
> 03: (with COMMENT)
> 
> Roman Danyliw 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:
> --
> 
> 
> Thank you to Stephen Farrell for the SECDIR review.
> 
> Section 4 specifies an assignment policy of “IETF Review.”  To
> double-check,
> you also do not want a designated expert too?
> 
> 


_

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

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

2022-05-31 Thread mohamed.boucadair

Re-,

Sure. Please use the same diff provided below to track the changes.

Thanks.

Cheers,
Med

De : Francesca Palombini 
Envoyé : mardi 31 mai 2022 15:24
À : BOUCADAIR Mohamed INNOV/NET ; The IESG 

Cc : draft-ietf-alto-cost-m...@ietf.org; alto-cha...@ietf.org; alto@ietf.org; 
kai...@scu.edu.cn
Objet : Re: Francesca Palombini's No Objection on draft-ietf-alto-cost-mode-03: 
(with COMMENT)

Thanks Med! This looks good, I think it still is missing a pointer to the 
requirements for the Identifier listed in Section 3.2 - I believe you need to 
include that in some way in the IANA Considerations section, to allow people to 
find the right restrictions on Identifiers strings when registering values. 
This can be done really easily:

OLD:
  Identifier:  The name of the ALTO cost mode.
NEW:
  Identifier:  The name of the ALTO cost mode. 
See section 3.2 for allowed encoding.

Or something like that.

Francesca

From: mohamed.boucad...@orange.com 
mailto:mohamed.boucad...@orange.com>>
Date: Tuesday, 31 May 2022 at 15:18
To: Francesca Palombini 
mailto:francesca.palomb...@ericsson.com>>, 
The IESG mailto:i...@ietf.org>>
Cc: 
draft-ietf-alto-cost-m...@ietf.org 
mailto:draft-ietf-alto-cost-m...@ietf.org>>,
 alto-cha...@ietf.org 
mailto:alto-cha...@ietf.org>>, 
alto@ietf.org mailto:alto@ietf.org>>, 
kai...@scu.edu.cn 
mailto:kai...@scu.edu.cn>>
Subject: RE: Francesca Palombini's No Objection on 
draft-ietf-alto-cost-mode-03: (with COMMENT)
Hi Francesca,

Thank you for the review.

The names of the fields are self-descriptive, but no problem to add some text 
as you can see in the proposal at: 
https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-45444731-1d0c46574a7af725&q=1&e=b3db017b-812a-4079-92bf-47431008fe46&u=https%3A%2F%2Ftinyurl.com%2Fcost-mode-latest

Added a note for the "priv" case so that it is easily available from the IANA 
registry itself.

Cheers,
Med

> -Message d'origine-
> De : Francesca Palombini via Datatracker 
> mailto:nore...@ietf.org>>
> Envoyé : mardi 31 mai 2022 14:27
> À : The IESG mailto:i...@ietf.org>>
> Cc : 
> draft-ietf-alto-cost-m...@ietf.org;
>  alto-cha...@ietf.org;
> alto@ietf.org; 
> kai...@scu.edu.cn; 
> kai...@scu.edu.cn
> Objet : Francesca Palombini's No Objection on draft-ietf-alto-
> cost-mode-03: (with COMMENT)
>
> Francesca Palombini 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:
> --
> 
>
> # ART AD Review of draft-ietf-alto-cost-mode-03
>
> cc @fpalombini
>
> Thank you for the work on this document.
>
> Many thanks to Jaime Jimenez for his ART ART review:
> https://mailarchive.ietf.org/arch/msg/art/AdWmf0LOQ2JPGOZRQWVqTczv
> lwA/, and
> thanks to the authors for addressing his comment.
>
> I only have one comment about the IANA section - I do not believe
> it rises as a
> DISCUSS, but I strongly think it should be addressed before
> publication.
>
> Francesca
>
> ## Comments
>
> ### IANA considerations
>
> Section 4:
> >   This document requests IANA to create a new subregistry
> entitled
> >   "ALTO Cost Modes" under the "Application-Layer Traffic
> Optimization
> >   (ALTO) Protocol" registry available at [ALTO].
>
> Please add a paragraph going over the different fields in the
> registry, listing
> them and providing a short description.
>
> In the definition for the "Identifier" field you should either
> repeat or point
> to the constraints defined in Section 3.2, including the fact that
> identifiers
> prefixed with "priv:" are reserved for Private Use (Section 4.1 of
> [RFC8126])
> (which I believe is more precise than just saying "_Cost modes_
> prefixed with
> "priv" are reserved ..." at the end of the section).
>
> ## 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.
>
> [ICMF]: 
> https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273a

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

2022-05-31 Thread mohamed.boucadair

Hi Francesca, 

Thank you for the review. 

The names of the fields are self-descriptive, but no problem to add some text 
as you can see in the proposal at: https://tinyurl.com/cost-mode-latest

Added a note for the "priv" case so that it is easily available from the IANA 
registry itself. 

Cheers,
Med

> -Message d'origine-
> De : Francesca Palombini via Datatracker 
> Envoyé : mardi 31 mai 2022 14:27
> À : 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 : Francesca Palombini's No Objection on draft-ietf-alto-
> cost-mode-03: (with COMMENT)
> 
> Francesca Palombini 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:
> --
> 
> 
> # ART AD Review of draft-ietf-alto-cost-mode-03
> 
> cc @fpalombini
> 
> Thank you for the work on this document.
> 
> Many thanks to Jaime Jimenez for his ART ART review:
> https://mailarchive.ietf.org/arch/msg/art/AdWmf0LOQ2JPGOZRQWVqTczv
> lwA/, and
> thanks to the authors for addressing his comment.
> 
> I only have one comment about the IANA section - I do not believe
> it rises as a
> DISCUSS, but I strongly think it should be addressed before
> publication.
> 
> Francesca
> 
> ## Comments
> 
> ### IANA considerations
> 
> Section 4:
> >   This document requests IANA to create a new subregistry
> entitled
> >   "ALTO Cost Modes" under the "Application-Layer Traffic
> Optimization
> >   (ALTO) Protocol" registry available at [ALTO].
> 
> Please add a paragraph going over the different fields in the
> registry, listing
> them and providing a short description.
> 
> In the definition for the "Identifier" field you should either
> repeat or point
> to the constraints defined in Section 3.2, including the fact that
> identifiers
> prefixed with "priv:" are reserved for Private Use (Section 4.1 of
> [RFC8126])
> (which I believe is more precise than just saying "_Cost modes_
> prefixed with
> "priv" are reserved ..." at the end of the section).
> 
> ## 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.
> 
> [ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
> [ICT]: https://github.com/mnot/ietf-comments
> 
> 


_

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

Re: [alto] Robert Wilton's Discuss on draft-ietf-alto-cost-mode-03: (with DISCUSS)

2022-05-31 Thread mohamed.boucadair

Hi Rob, 

FWIW, we added a NEW text to explain how the new modes can be discovered using 
legacy means: https://tinyurl.com/cost-mode-latest. 

Thanks for the review. 

Cheers,
Med

> -Message d'origine-
> De : Robert Wilton via Datatracker 
> Envoyé : mercredi 25 mai 2022 17:06
> À : 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 : Robert Wilton's Discuss on draft-ietf-alto-cost-mode-03:
> (with DISCUSS)
> 
> Robert Wilton has entered the following ballot position for
> draft-ietf-alto-cost-mode-03: 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-cost-mode/
> 
> 
> 
> --
> 
> DISCUSS:
> --
> 
> 
> Hi,
> 
> This is a "discuss" discuss, as in I'm not sure the document is
> wrong, but I
> thought that it would be helpful to flag this for further
> discussion.
> 
> In RFC 7285, cost-mode is defined as a field that MUST take one of
> two string
> values, either "numerical" or "ordinal".  I'm not really familiar
> with RFC
> 7285, and in particular, whether a receiver is required to
> explicitly check
> that the received data must take one of these two values, or
> whether a
> reasonable implementation could check for a single value, and if
> doesn't match
> that value assume that it must be the other value (since there are
> only two
> allowed values).  Obviously, moving to more than two values could
> then cause
> this assumption to break in existing implementations.  Was this
> issue
> considered and discussed by the WG?  It looks like alto does
> support a
> versioning mechanism (i.e., by defining new media types) that
> might allow the
> definition of this field to be upgraded in a safer way.  Was that
> approach
> considered?
> 
> Regards,
> Rob
> 
> 
> 
> 


_

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

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

2022-05-30 Thread 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

Re: [alto] Secdir last call review of draft-ietf-alto-cost-mode-03

2022-05-19 Thread mohamed.boucadair

Hi Stephen,

Thank you for the review. 

I confirm. The part you quoted from Section 6.1.2 is still valid as is. 

Cheers,
Med

> -Message d'origine-
> De : Stephen Farrell via Datatracker 
> Envoyé : jeudi 19 mai 2022 14:48
> À : sec...@ietf.org
> Cc : alto@ietf.org; draft-ietf-alto-cost-mode@ietf.org; last-
> c...@ietf.org
> Objet : Secdir last call review of draft-ietf-alto-cost-mode-03
> 
> Reviewer: Stephen Farrell
> Review result: Ready
> 
> This document seems ready to me.
> 
> I did have one question - RFC7285 says that servers MUST support
> one of the numeric or ordinal cost-modes. It wasn't entirely clear
> to me whether it's intended that that remain the case, but I
> assume it is, so that e.g. it'd be invalid to have a server that
> only supports some new "foo" cost mode. If that's the case, then
> this draft is fine. If something else was intended then I guess a
> bit more text on that would be needed.
> 


_

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

Re: [alto] I-D Action: draft-ietf-alto-cost-mode-03.txt

2022-05-16 Thread mohamed.boucadair

Hi all, 

This version fixes a bug in the html version and some nits reported in the 
directorate reviews received so far. 

Cheers,
Med

> -Message d'origine-
> De : I-D-Announce  De la part de
> internet-dra...@ietf.org
> Envoyé : mardi 17 mai 2022 08:26
> À : i-d-annou...@ietf.org
> Cc : alto@ietf.org
> Objet : I-D Action: draft-ietf-alto-cost-mode-03.txt
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Application-Layer Traffic
> Optimization WG of the IETF.
> 
> Title   : A Cost Mode Registry for the
> Application-Layer Traffic Optimization (ALTO) Protocol
> Authors : Mohamed Boucadair
>   Qin Wu
>   Filename: draft-ietf-alto-cost-mode-03.txt
>   Pages   : 6
>   Date: 2022-05-16
> 
> Abstract:
>This document creates a new IANA registry for tracking cost
> modes
>supported by the Application-Layer Traffic Optimization (ALTO)
>Protocol.  Also, this document relaxes a constraint that was
> imposed
>by the ALTO specification on allowed cost mode values.
> 
>This document updates RFC 7285.
> 
> Editorial Note (To be removed by RFC Editor)
> 
>Please update RFC  statements within the document with the
> RFC
>number to be assigned to this document.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-alto-cost-mode/
> 
> There is also an htmlized version available at:
> https://datatracker.ietf.org/doc/html/draft-ietf-alto-cost-mode-03
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-alto-cost-mode-03
> 
> 
> Internet-Drafts are also available by rsync at
> rsync.ietf.org::internet-drafts
> 
> 
> ___
> I-D-Announce mailing list
> i-d-annou...@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html or
> ftp://ftp.ietf.org/ietf/1shadow-sites.txt

_

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

Re: [alto] [IANA #1230654] [Errata Verified] RFC7285 (6876)

2022-05-15 Thread mohamed.boucadair

Hi Amanda, all,

The changes look good to me. Thank you for taking care of this.

Cheers,
Med

> -Message d'origine-
> De : Amanda Baber via RT 
> Envoyé : samedi 14 mai 2022 00:55
> À : rfc-edi...@rfc-editor.org
> Cc : y...@cs.yale.edu; w.ro...@alcatel-lucent.com;
> sprev...@cisco.com; shalu...@shlang.com;
> richard_wou...@cable.comcast.com; repe...@cisco.com;
> ral...@google.com; BOUCADAIR Mohamed INNOV/NET
> ; martin.h.d...@gmail.com; ietf-
> a...@skiesel.de; alto@ietf.org
> Objet : [IANA #1230654] [Errata Verified] RFC7285 (6876)
> 
> Hi,
> 
> The headers for the affected registries now read as follows:
> 
> ALTO Cost Metrics
> Registration Procedure(s): IETF Review
> Reference: [RFC7285][RFC Errata 6874]
> Note: Identifiers prefixed with 'priv:' are reserved for Private
> Use (see [RFC7285], Section 10.6).
> 
> ALTO Endpoint Property Types
> Registration Procedure(s): IETF Review
> Reference: [RFC7285][RFC Errata 6876]
> Note: Identifiers prefixed with 'priv:' are reserved for Private
> Use (see [RFC7285], Section 10.8.2).
> 
> The "priv:" registration has been removed from each registry.
> 
> thanks,
> 
> Amanda Baber
> IANA Operations Manager
> 
> On Fri May 13 20:48:24 2022, ietf-a...@skiesel.de wrote:
> > Hi,
> >
> > On Fri, May 13, 2022 at 07:58:06PM +, Amanda Baber via RT
> wrote:
> > > Hi all,
> > >
> > > This question relates to both 6874 and 6876:
> > >
> > > Should "priv:" be removed from the ALTO Cost Metrics and ALTO
> > > Endpoint Property Types registries? See
> > >
> > > https://www.iana.org/assignments/alto-protocol
> > >
> > > If so, should we add the note "Note: Identifiers prefixed with
> > > 'priv:'
> > > are reserved for Private Use (see RFC 7285, Section 10.8.2)"
> to the
> > > top of each registry?
> >
> > Please note the two different references to different sections
> of the
> > document for the two registries.
> >
> > Please add
> >
> > Note: Identifiers prefixed with 'priv:' are reserved for Private
> Use
> > (see RFC 7285, Section 10.6)
> >
> > to the ALTO Cost Metrics registry and
> >
> > Note: Identifiers prefixed with 'priv:' are reserved for Private
> Use
> > (see RFC 7285, Section 10.8.2)
> >
> > to the ALTO Endpoint Property Types registry.
> >
> > thanks
> > Sebastian


_

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

Re: [alto] Question on ANE name format

2022-05-12 Thread mohamed.boucadair

Hi Sabine, all,

I would go personally for option 1. Thanks.

Cheers,
Med

De : Randriamasy, Sabine (Nokia - FR/Paris-Saclay) 

Envoyé : lundi 9 mai 2022 18:20
À : IETF ALTO ; BOUCADAIR Mohamed INNOV/NET 
; Qin (Bill) Wu ; 
martin.h.d...@gmail.com; zaheduzzaman.sar...@ericsson.com
Cc : we...@wdroome.com; Jensen Zhang ; Kai Gao 
; 'Richard Yang' 
Objet : Question on ANE name format

Dear ALTO WG and chairs and area directors,

The document draft-ietf-alto-unified-props-new-24 
(https://datatracker.ietf.org/doc/html/draft-ietf-alto-unified-props-new-24.txt 
) has now entered AUTH48 and is on its way to be published as RFC 9240,  once 
it has been reviewed and approved by all coauthors.

In draft-ietf-alto-unified-props-new-24  - Section 10.9. Filtered Property Map 
for ANEs Example #5,  there is an issue, regarding the ANEs name format, on 
which we would like to have your thoughts and WG chair and area director 
guidance.
Two example ANEs are provided in  Section 10.9.: ".ane:dc45.srv9" and 
".ane:dc6.srv-cluster8".
That is, their ANE names are respectively: "dc45.srv9" and "dc6.srv-cluster8" 
and both include the '.' separator (U+002E).

- The ANE name format is specified in draft-ietf-alto-path-vector-25: 
https://datatracker.ietf.org/doc/html/draft-ietf-alto-path-vector-25.txt 
Section 6.1 ANE name.
"An ANE Name is encoded as a JSON string with the same format as that of the 
type PIDName (Section 10.1 of [RFC7285]) "

- In Section 10.1 of [RFC7285] https://datatracker.ietf.org/doc/html/rfc7285
"A PID Name is encoded as a JSON string. The string MUST be no more than 64 
characters, and it MUST NOT contain characters other than US- ASCII 
alphanumeric characters (U+0030-U+0039, U+0041-U+005A, and U+0061-U+007A), the 
hyphen ('-', U+002D), the colon (':', U+003A), the at sign ('@', code point 
U+0040), the low line ('_', U+005F), or the '.' separator (U+002E).
The '.' separator is reserved for future use and MUST NOT be used unless 
specifically indicated in this document, or an extension document."

Since Section 6.1 ANE name of draft-ietf-alto-path-vector-25 does not 
explicitly allow the '.' separator (U+002E), the example ANE names provided in 
Section 10.9.of draft-ietf-alto-unified-props-new-24 are illegal.

To solve this issue, three options have been identified:
-- OPTION 1: correct the examples in  Section 10.9. of  
draft-ietf-alto-unified-props-new-24, with for instance:
OLD
".ane:dc45.srv9" and ".ane:dc6.srv-cluster8"
NEW
".ane:dc45_srv9" and ".ane:dc6_srv-cluster8"  OR ".ane:dc45-srv9" and 
".ane:dc6-srvcluster8"

-- OPTION 2: relax the ANE name format in Section 6.1 ANE name of 
draft-ietf-alto-path-vector-25.
Given that PV is as well in the RFC Ed Queue, this may be too late or too 
complicated at this stage.  After all, an ANE name and a PID name are to be 
interpreted as a string. On the other hand, upon discussions with the PV 
co-authors, there is no  particular reason to forbid '.'.
The text of section 6.1 of draft-ietf-alto-path-vector-25 may be updated as 
follows:

OLD
An ANE Name is encoded as a JSON string with the same format as that
of the type PIDName (Section 10.1 of [RFC7285]).
The type ANEName is used in this document to indicate a string of
this format.

NEW
An ANE Name is encoded as a JSON string with the same format as that
of the type PIDName (Section 10.1 of [RFC7285]).
The type ANEName is used in this document to indicate a string of
this format.
This document allows to use the '.' separator (U+002E).

-- OPTION 3: correct the examples in  Section 10.9. of UP with for 
instance +  propose extensions on ANE name format in future use cases.

What do you recommend?
Thanks a lot in advance
Sabine and co-authors

_

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

Re: [alto] Artart last call review of draft-ietf-alto-cost-mode-02

2022-05-12 Thread mohamed.boucadair

Hi Jaime, 

Thank you for the careful review. 

Please see inline. 

Cheers,
Med

> -Message d'origine-
> De : Jaime Jimenez via Datatracker 
> Envoyé : mercredi 11 mai 2022 10:01
> À : a...@ietf.org
> Cc : alto@ietf.org; draft-ietf-alto-cost-mode@ietf.org; last-
> c...@ietf.org
> Objet : Artart last call review of draft-ietf-alto-cost-mode-02
> 
> Reviewer: Jaime Jimenez
> Review result: Ready with Nits
> 
> Dear all,
> 
> I am the assigned reviewer for the Applications and Real Time Area
> Review Team (ART-ART).
> 
> Nits/editorial comments:
> 
> One minor comment is that since this document sets a registry with
> a limited set of cost-modes (for now "numerical" and "ordinal")
> that require IANA registration anyways, why not assign some 8-bit
> codes ("0x0, 0x1") to save space on the wire.? 

[Med] We don't consider that because that would require changes to existing 
7285 implementations. 

Probably this has
> already been discussed somewhere in the WG, so I apologize if I am
> way off on this.
> 
> Another minor comment is that RFC7285 defines variations of a JSON
> they use in now few different locations in the document, section
> 10.1, section 10.6, section 10.8.2 and after this document is
> approved also on section 10.5. To make transparent to the that
> they are different I would consider writing a line on section 3.2
> saying that neither the '.' separator nor the the at sign ('@')
> are allowed.

[Med] I don't think such a note is needed as the text is clear about allowed 
characters. Thanks.  

> 
> There is an extra space on 3.2: U+0041 -U+005A Should be: U+0041-
> U+005A
> 

[Med] Fixed.

> There is a typo on 3.2: ('_', +005F)
> Should be: ('_', U+005F)
> 

[Med] Fixed


_

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

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

2022-05-09 Thread mohamed.boucadair

Hi Roni, 

Thank you for the review. It will be ACKed in the next iteration of the draft. 

Cheers,
Med

> -Message d'origine-
> De : Roni Even via Datatracker 
> Envoyé : samedi 7 mai 2022 13:39
> À : gen-...@ietf.org
> Cc : alto@ietf.org; draft-ietf-alto-cost-mode@ietf.org; last-
> c...@ietf.org
> Objet : Genart last call review of draft-ietf-alto-cost-mode-02
> 
> 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:
> 
> 


_

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

Re: [alto] Last Call: (A Cost Mode Registry for the Application-Layer Traffic Optimization (ALTO) Protocol) to Proposed Standard

2022-05-09 Thread mohamed.boucadair

Hi Ben, 

Thank you for the comment. 

I think that you got the reasoning for not including such an encouragement 
text. 

BTW, I expect that the main concern will be related to modifying modes so that 
cost metrics are erroneously interpreted. That risk falls under 15.1 of 7285.  

Cheers,
Med

> -Message d'origine-
> De : alto  De la part de Benjamin Kaduk
> Envoyé : dimanche 8 mai 2022 05:53
> À : last-c...@ietf.org
> Cc : alto@ietf.org; draft-ietf-alto-cost-m...@ietf.org
> Objet : Re: [alto] Last Call: 
> (A Cost Mode Registry for the Application-Layer Traffic
> Optimization (ALTO) Protocol) to Proposed Standard
> 
> On Fri, Apr 29, 2022 at 06:57:26AM -0700, The IESG wrote:
> >
> > The IESG has received a request from the Application-Layer
> Traffic
> > Optimization WG (alto) to consider the following document: - 'A
> Cost
> > Mode Registry for the Application-Layer Traffic Optimization
> >(ALTO) Protocol'
> >as Proposed Standard
> >
> > The IESG plans to make a decision in the next few weeks, and
> solicits
> > final comments on this action. Please send substantive comments
> to the
> > last-c...@ietf.org mailing lists by 2022-05-13. Exceptionally,
> > comments may be sent to i...@ietf.org instead. In either case,
> please
> > retain the beginning of the Subject line to allow automated
> sorting.
> 
> This document is meeting a real need by fleshing out an extension
> point for ALTO that was previously over-constrained and not
> actually usable for extensions.
> 
> The security considerations section currently just defers to the
> core ALTO procotol spec, RFC 7285.  This seems appropriate, as
> this document is just opening up the extension point, but we might
> also consider providing specific encouragement for authors of new
> cost modes to document considerations unique to that cost mode.
> Hopefully such documents would already provide comprehensive
> security considerations, though, so it does not seem strictly
> needed for us to say anything here.
> 
> -Ben
> 
> ___
> alto mailing list
> alto@ietf.org
> https://www.ietf.org/mailman/listinfo/alto

_

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

Re: [alto] Shepherd review for draft-ietf-alto-cost-mode-01

2022-04-18 Thread mohamed.boucadair

Hi Kai, 

I know that 7285 includes something similar, but the proposed text is redundant 
with the structure of the table in that section. I prefer to not include this 
text.

Thank you.

Cheers,
Med 

> -Message d'origine-
> De : kai...@scu.edu.cn 
> Envoyé : dimanche 17 avril 2022 16:08
> À : BOUCADAIR Mohamed INNOV/NET 
> Cc : alto@ietf.org; Qin Wu 
> Objet : Re: Re: [alto] Shepherd review for draft-ietf-alto-cost-
> mode-01
> 
> Hi Med,
> 
> Thanks for the quick update but I have one additional comment on
> the registry specification:
> I suggest adding the following paragraphs after the registry
> table:
> 
> NEW:
>Requests to add a new value to the registry MUST include the
>following information:
> 
>o  Identifier: The name of the ALTO cost mode.
> 
>o  Intended Semantics: A document defining a new cost mode must
>   indicate how costs should be interpreted (Section 6.1.2 of
> [RFC7285]).
>   For example, the "numerical" cost mode indicates the costs
> are
>   interpreted as values on which numerical operations can be
> applied.
> 
> Best,
> Kai
> 
> > -Original Messages-
> > From: mohamed.boucad...@orange.com
> > Sent Time: 2022-04-16 17:00:05 (Saturday) > To:
> "kai...@scu.edu.cn" , "alto@ietf.org"
>  > Cc: "Qin Wu"  >
> Subject: Re: [alto] Shepherd review for draft-ietf-alto-cost-mode-
> 01 > > Hi Kai, > > The changes are raisonnable.
> >
> > A new version that implements the changes edits is now
> online.
> >
> > Thanks.
> >
> > Cheers,
> > Med
> >
> > > -Message d'origine-
> > > De : kai...@scu.edu.cn  >
> > Envoyé : samedi 16 avril 2022 03:49 > > À :
> alto@ietf.org > > Cc : BOUCADAIR Mohamed INNOV/NET
> ; > > Qin Wu
>  > > Objet : Shepherd review for
> draft-ietf-alto-cost-mode-01 > > > > Dear WG and
> authors of draft-ietf-alto-cost-mode, > > > > I am
> posting this review of draft-ietf-alto-cost-mode-01 to the >
> > mailing list, as part of my shepherd write-up. Any comments
> and > > feedback are more than welcome!
> > >
> > > Best,
> > > Kai
> > >
> > > ===
> > >
> > > This draft extends the base ALTO protocol (RFC 7285) by
> relaxing > > the constraint on valid cost mode values and
> introducing a new > > IANA (sub-)registry to document new
> cost mode values. The > > motivation is clear and the
> proposed mechanism is clean. Most > > comments raised in
> Call for Adoption and WGLC are addressed in the > > latest
> revision except Dhruv's comment [1] on giving more detailed >
> > specifications of the contents in IANA registry. There are
> two > > remaining comments and I think the draft is ready
> for publication > > once they are addressed.
> > >
> > > Comments:
> > >
> > > Section 3.1, last paragraph: The paragraph says >
> >
> > >Future documents that define a new cost mode SHOULD
> indicate
> > > whether
> > >that new cost mode applies to all or a subset of cost
> metrics.
> > >
> > > In that case, it seems to me that the default behavior
> should be > > specified in case the applicability of the new
> cost mode is not > > indicated. Either the "SHOULD" keyword
> is replaced by "MUST" or an > > additional sentence is
> required, e.g., > > > > NEW:
> > > If not explicitly specified, the new cost mode
> applies to all
> > > cost metrics.
> > >
> > > Section 4:
> > >
> > > I also agree with Dhruv's comment that the contents of
> the "ALTO > > Cost Modes"
> > > registry should be better specified. While the initial
> entries set > > good examples of how to register a new cost
> mode, it can still be > > helpful if the format and content
> of each field are specified in > > more details, e.g., using
> similar specifications in Sections 14.2 > > and 14.3 of RFC
> 7285 (as suggested by Dhruv).
> > >
> > > I also suggest renaming the "Specification" field to
> "Intended > > Semantics", to be consistent with other ALTO
> registries (in RFC > > 7285 and in the unified property
> draft).
> > >
> > > [1]
> https://mailarchive.ietf.org/arch/msg/alto/B1agkfVtdu7tsad2-
> > > MzErQXMk44/
> >

_

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 hav

Re: [alto] Shepherd review for draft-ietf-alto-cost-mode-01

2022-04-16 Thread mohamed.boucadair

Hi Kai, 

The changes are raisonnable. 

A new version that implements the changes edits is now online. 

Thanks. 

Cheers,
Med

> -Message d'origine-
> De : kai...@scu.edu.cn 
> Envoyé : samedi 16 avril 2022 03:49
> À : alto@ietf.org
> Cc : BOUCADAIR Mohamed INNOV/NET ;
> Qin Wu 
> Objet : Shepherd review for draft-ietf-alto-cost-mode-01
> 
> Dear WG and authors of draft-ietf-alto-cost-mode,
> 
> I am posting this review of draft-ietf-alto-cost-mode-01 to the
> mailing list, as part of my shepherd write-up. Any comments and
> feedback are more than welcome!
> 
> Best,
> Kai
> 
> ===
> 
> This draft extends the base ALTO protocol (RFC 7285) by relaxing
> the constraint on valid cost mode values and introducing a new
> IANA (sub-)registry to document new cost mode values. The
> motivation is clear and the proposed mechanism is clean. Most
> comments raised in Call for Adoption and WGLC are addressed in the
> latest revision except Dhruv's comment [1] on giving more detailed
> specifications of the contents in IANA registry. There are two
> remaining comments and I think the draft is ready for publication
> once they are addressed.
> 
> Comments:
> 
> Section 3.1, last paragraph: The paragraph says
> 
>Future documents that define a new cost mode SHOULD indicate
> whether
>that new cost mode applies to all or a subset of cost metrics.
> 
> In that case, it seems to me that the default behavior should be
> specified in case the applicability of the new cost mode is not
> indicated. Either the "SHOULD" keyword is replaced by "MUST" or an
> additional sentence is required, e.g.,
> 
> NEW:
> If not explicitly specified, the new cost mode applies to all
> cost metrics.
> 
> Section 4:
> 
> I also agree with Dhruv's comment that the contents of the "ALTO
> Cost Modes"
> registry should be better specified. While the initial entries set
> good examples of how to register a new cost mode, it can still be
> helpful if the format and content of each field are specified in
> more details, e.g., using similar specifications in Sections 14.2
> and 14.3 of RFC 7285 (as suggested by Dhruv).
> 
> I also suggest renaming the "Specification" field to "Intended
> Semantics", to be consistent with other ALTO registries (in RFC
> 7285 and in the unified property draft).
> 
> [1] https://mailarchive.ietf.org/arch/msg/alto/B1agkfVtdu7tsad2-
> MzErQXMk44/

_

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

Re: [alto] IPR Check for draft-ietf-alto-cost-mode-01

2022-04-12 Thread mohamed.boucadair

Hi Kai, all,

I don't have any IPR nor I'm aware of any related to this draft.

Cheers,
Med

> -Message d'origine-
> De : alto  De la part de kai...@scu.edu.cn
> Envoyé : mardi 12 avril 2022 09:08
> Cc : alto@ietf.org
> Objet : [alto] IPR Check for draft-ietf-alto-cost-mode-01
> 
> Dear authors,
> 
> Please reply to this email (with the WG mailing list cc'ed)
> indicating whether you are aware of any IPR related to draft-ietf-
> alto-cost-mode.
> 
> If you are aware of any, can you please confirm that all
> appropriate IPR disclosures required for full conformance with the
> provisions of BCP 78 and BCP 79 have already been filed?
> 
> Thank you.
> 
> Best,
> Kai
> ___
> alto mailing list
> alto@ietf.org
> https://www.ietf.org/mailman/listinfo/alto

_

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

Re: [alto] WGLC for draft-ietf-alto-cost-mode-00

2022-04-11 Thread mohamed.boucadair

Hi Kai, all,

These RFCs are referring to Unicode in general, where several hyphens are 
supported.

RFC7285 points explicitly to US-ASCII alphanumeric characters, where U+002D is 
the only hyphen:
* There is no ambiguity about the intended behavior given that U+002D is 
provided
* Even if we reason about labels, there is also not ambiguity which hyphen is 
about

I don’t think there is an issue with RFC7285, but I would not object to an ** 
editorial ** errata.

That’s said, I’m for consistent use of labels and can fix this for the 
cost-mode I-D: 
https://github.com/boucadair/alto-cost-mode/blob/main/draft-ietf-alto-cost-mode.txt

Cheers,
Med

De : alto  De la part de kai...@scu.edu.cn
Envoyé : lundi 11 avril 2022 02:19
À : bill.wu=40huawei@dmarc.ietf.org
Cc : alto@ietf.org
Objet : Re: [alto] WGLC for draft-ietf-alto-cost-mode-00


Hi Qin, Qiao and all,



I searched for a few documents and it seems that many documents are referring 
to U+002D as hyphen-minus. It seems to me that we should use hyphen-minus.



https://datatracker.ietf.org/doc/html/rfc3490

https://datatracker.ietf.org/doc/html/rfc5890

https://datatracker.ietf.org/doc/html/rfc8551

https://datatracker.ietf.org/doc/html/rfc8771



Best,

Kai



-Original Messages-
From:"Qin Wu" 
mailto:bill.wu=40huawei@dmarc.ietf.org>>
Sent Time:2022-04-10 19:21:05 (Sunday)
To: "kai...@scu.edu.cn" 
mailto:kai...@scu.edu.cn>>, "Qiao Xiang" 
mailto:xiang...@gmail.com>>
Cc: "alto@ietf.org" mailto:alto@ietf.org>>
Subject: Re: [alto] WGLC for draft-ietf-alto-cost-mode-00
Hi, Kai and Qiao:
Is there any other RFCs which describe “hyphen” usages besides RFC7285?
Since this work is targeted to update RFC7285, there is a time window to 
improve RFC7285,
If “hyphen-minus” described in https://www.unicode.org/charts/PDF/U.pdf, is 
current best practice, I have no better reason to reject this request,:-)
The price is we should also update other sections related to cost metric and 
global endpoint properties with “hyphen” usage.

-Qin
发件人: alto [mailto:alto-boun...@ietf.org] 代表 
kai...@scu.edu.cn
发送时间: 2022年4月10日 15:57
收件人: Qiao Xiang mailto:xiang...@gmail.com>>
抄送: alto@ietf.org
主题: Re: [alto] WGLC for draft-ietf-alto-cost-mode-00


Hi Qiao and all,



Thanks for reviewing the document.



In RFC 7285, "hyphen" is used when defining PID, cost metric, etc. One option 
is to use the term consistently with existing RFCs.



Best,

Kai



-Original Messages-
From:"Qiao Xiang" mailto:xiang...@gmail.com>>
Sent Time:2022-04-09 18:04:36 (Saturday)
To: kai...@scu.edu.cn
Cc:
Subject: Re: [alto] WGLC for draft-ietf-alto-cost-mode-00
Hi Kai and all,

I have read the document and support the proceeding of its publication with one 
tiny suggested edit:

Section 3.2: the hyphen ('-', U+002D) -> the hyphen-minus ('-', U+002D)

This is to be consistent with the official name of this character in 
https://www.unicode.org/charts/PDF/U.pdf.


Best
Qiao





On Sat, Apr 9, 2022 at 9:53 AM mailto:kai...@scu.edu.cn>> 
wrote:

Hi Jordi,



Thanks for reviewing the document!



Best,

Kai


-Original Messages-
From:"Jordi Ros Giralt" mailto:j...@qti.qualcomm.com>>
Sent Time:2022-04-08 13:03:03 (Friday)
To: "kai...@scu.edu.cn" 
mailto:kai...@scu.edu.cn>>, 
"alto@ietf.org" mailto:alto@ietf.org>>
Cc:
Subject: Re: [alto] WGLC for draft-ietf-alto-cost-mode-00
Hi Kai,

I read this document and I support proceeding with its publication.

Thank you,
Jordi


From: alto mailto:alto-boun...@ietf.org>> on behalf of 
kai...@scu.edu.cn 
mailto:kai...@scu.edu.cn>>
Sent: Friday, March 25, 2022 1:46
To: alto@ietf.org mailto:alto@ietf.org>>
Subject: [alto] WGLC for draft-ietf-alto-cost-mode-00

WARNING: This email originated from outside of Qualcomm. Please be wary of any 
links or attachments, and do not enable macros.

Hi all,

As discussed during the ALTO session in IETF 113, the ALTO cost mode document 
is now adopted as a working group document. A new WG version 
(draft-ietf-alto-cost-mode-00) [1] has been submitted to replace the individual 
draft and address comments from the Call for Adoption.

To move forward, this message starts the WGLC for draft-ietf-alto-cost-mode-00. 
The WGLC will run till April 8, 2022 (two weeks from now).

As both WG chairs are co-authoring the document, I’m taking care of this call 
as part of my document shepherding. We would like to have 2-3 reviewers from 
the working group. Please review and indicate your support or objection to 
proceed with the publication of this document.

Thanks!

[1] https://datatracker.ietf.org/doc/draft-ietf-alto-cost-mode/.

Best,
Kai
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailm

Re: [alto] Call for adoption: draft-zhang-alto-oam-yang

2022-04-08 Thread mohamed.boucadair

Hi all,

This message concludes this call for adoption.

Given the fair amount of support and that no objection was made, the draft is 
adopted.

Authors, please submit the draft as draft-ietf-alto-oam-yang at your 
convenience. The -00 is pre-validated.

No need to reflect the comments from Qiufang in -00. These can be discussed and 
resolution integrated in future versions. Thanks.

Cheers,
Qin & Med

De : mohamed.boucad...@orange.com 
Envoyé : mercredi 23 mars 2022 14:45
À : alto@ietf.org; draft-zhang-alto-oam-y...@ietf.org
Cc : alto-cha...@ietf.org
Objet : Call for adoption: draft-zhang-alto-oam-yang

Hi all,

As discussed during the IETF#113 meeting, this message initiates the call for 
adoption of draft-zhang-alto-oam-yang to meet the following ALTO WG milestone:

==
Dec 2022ALTO OAM Document/YANG Model
==

Please reply to this message indicating your support or objection to adopt the 
document.

The call will run till 08 April 2022.

Thank you
Qin & Med

_

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

Re: [alto] [Editorial Errata Reported] RFC7285 (6876)

2022-04-07 Thread mohamed.boucadair

Hi Sebastien,

I can't act on the erratum to update the "Corrected Text" to reflect what we 
agreed together. 

I guess Martin or the RFC editor can make that update and then mark it as 
verified. Doing so would allow the corrected text to be seen as part of the 
rendered RFC version 
(https://www.rfc-editor.org/rfc/inline-errata/rfc7285.html). 

Cheers,
Med

> -Message d'origine-
> De : Sebastian Kiesel 
> Envoyé : jeudi 7 avril 2022 11:35
> À : BOUCADAIR Mohamed INNOV/NET 
> Cc : Chris Smiley ; martin.h.d...@gmail.com;
> Zaheduzzaman Sarker ;
> ral...@google.com; repe...@cisco.com; y...@cs.yale.edu;
> sprev...@cisco.com; w.ro...@alcatel-lucent.com;
> shalu...@shlang.com; richard_wou...@cable.comcast.com;
> alto@ietf.org; RFC Errata System 
> Objet : Re: [Editorial Errata Reported] RFC7285 (6876)
> 
> Hi Chris, Med, all,
> 
> how do we move on here?
> 
> my opinion is that the reported errata is not imperative to be
> recorded, but if we decide to do so, I would consider this as an
> editorial errata and I would really appreciate if we could add the
> proposed "Note: ..."
> sentence below the table (see quoted mail below), to make it
> absolutely clear that no policy or specification change is
> intended.
> 
> who needs to sign off on that errata?
> 
> (same for the other reported errata case)
> 
> Thanks
> Sebastian
> 
> 
> On Thu, Mar 10, 2022 at 12:21:19PM +,
> mohamed.boucad...@orange.com wrote:
> > Hi Sebastien, all,
> >
> > Works for me. Thanks.
> >
> > Cheers,
> > Med
> >
> > > -Message d'origine-
> > > De : Sebastian Kiesel  Envoyé : jeudi 10
> mars
> > > 2022 13:17 À : Chris Smiley  Cc :
> > > martin.h.d...@gmail.com; Zaheduzzaman Sarker
> > > ; BOUCADAIR Mohamed
> INNOV/NET
> > > ; ral...@google.com;
> > > repe...@cisco.com; y...@cs.yale.edu; sprev...@cisco.com;
> > > w.ro...@alcatel-lucent.com; shalu...@shlang.com;
> > > richard_wou...@cable.comcast.com; alto@ietf.org; RFC Errata
> System
> > >  Objet : Re: [Editorial Errata
> Reported]
> > > RFC7285 (6876)
> > >
> > > Hi Med,
> > >
> > > similar to the other case 6874, I think we should clarify that
> no
> > > policy change is intended, so:
> > >
> > >
> > > Type: Editorial
> > > Reported by: Mohamed BOUCADAIR 
> > >
> > > Section: 14.3
> > >
> > > Original Text
> > > -
> > >+++
> > >| Identifier | Intended Semantics |
> > >+++
> > >| pid| See Section 7.1.1  |
> > >| priv:  | Private use|
> > >+++
> > >
> > >   Table 4: ALTO Endpoint Property Types
> > >
> > >
> > > Corrected Text
> > > --
> > >+++
> > >| Identifier | Intended Semantics |
> > >+++
> > >| pid| See Section 7.1.1  |
> > >+++
> > >
> > >Note: Identifiers prefixed with "priv:" are
> > >reserved for Private Use (see Section
> 10.8.2.)
> > >
> > >   Table 4: ALTO Endpoint Property Types
> > >
> > >
> > > would that work for you?
> > >
> > > thanks
> > > Sebastian
> > >
> > > On Wed, Mar 09, 2022 at 01:23:35PM -0800, Chris Smiley wrote:
> > > >
> > > > Greetings,
> > > >
> > > > We are unable to verify this erratum that the submitter
> marked as
> > > editorial.
> > > > Please note that we have changed the “Type” of the following
> > > > errata report to “Technical”.  As Stream Approver, please
> review
> > > > and set the Status and Type accordingly (see the definitions
> at
> > > > https://www.rfc-editor.org/errata-definitions/).
> > > >
> > > > You may review the report at:
> > > > https://www.rfc-editor.org/errata/eid6876
> > > >
> > > > Please see https://www.rfc-editor.org/how-to-verify/ for
> further
> > > > information on how to verify errata reports.
> > > >
> > > > Further information on errata can be found at:
> > > > https://www.rfc-editor.org/errata.php.
> > > >
> > > > Thank you.
> > > >
> > > > RFC Editor/cs
> > > >
> > > >
> > > > > On Mar 8, 2022, at 10:21 PM, RFC Errata System  editor@rfc-
> > > editor.org> wrote:
> > > > >
> > > > > The following errata report has been submitted for
> RFC7285,
> > > > > "Application-Layer Traffic Optimization (ALTO) Protocol".
> > > > >
> > > > > --
> > > > > You may review the report below and at:
> > > > > https://www.rfc-editor.org/errata/eid6876
> > > > >
> > > > > --
> > > > > Type: Editorial
> > > > > Reported by: Mohamed BOUCADAIR
> 
> > > > >
> > > > > Section: 14.3
> > > > >
> > > > > Original Text
> > > > > -
> > > > >+++
> > > > >

Re: [alto] WGLC for draft-ietf-alto-cost-mode-00

2022-04-05 Thread mohamed.boucadair

Hi Peng,

Thank you for the comment.

Not sure what you meant by “optimization” of that section.


There are many cost metrics that were defined since then, including hopcount 
initially mentioned in 7285. See for example: 
https://datatracker.ietf.org/doc/html/draft-ietf-alto-performance-metrics#section-8.

Cheers,
Med

De : alto  De la part de liupeng...@outlook.com
Envoyé : mardi 5 avril 2022 17:27
À : kaigao 
Cc : alto 
Objet : Re: [alto] WGLC for draft-ietf-alto-cost-mode-00

Hi Kai,

I have read this document that has been discussed in the mailing list and is 
clear to optimize the mode issues, which could help to use Alto in more 
potential use cases. So I support the WGLC.

There is a question not for this document but I think might be related to it. 
This document updates the Section 6.1.2 of RFC7285. Is there any potential 
optimization possibility of Section 6.1.1 in the future? Since there is only 
the routingcost metric now.

Regards,
Peng

liupeng...@outlook.com

From: kaigao
Date: 2022-03-25 08:46
To: alto
Subject: [alto] WGLC for draft-ietf-alto-cost-mode-00
Hi all,
As discussed during the ALTO session in IETF 113, the ALTO cost mode document 
is now adopted as a working group document. A new WG version 
(draft-ietf-alto-cost-mode-00) [1] has been submitted to replace the individual 
draft and address comments from the Call for Adoption.

To move forward, this message starts the WGLC for draft-ietf-alto-cost-mode-00. 
The WGLC will run till April 8, 2022 (two weeks from now).

As both WG chairs are co-authoring the document, I’m taking care of this call 
as part of my document shepherding. We would like to have 2-3 reviewers from 
the working group. Please review and indicate your support or objection to 
proceed with the publication of this document.

Thanks!

[1] https://datatracker.ietf.org/doc/draft-ietf-alto-cost-mode/.
Best,
Kai
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

_

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

Re: [alto] Call for adoption: draft-zhang-alto-oam-yang

2022-04-04 Thread mohamed.boucadair

Hi all,

This is a reminder that this call for adoption is still running.

Cheers,
Qin & Med

De : mohamed.boucad...@orange.com 
Envoyé : mercredi 23 mars 2022 14:45
À : alto@ietf.org; draft-zhang-alto-oam-y...@ietf.org
Cc : alto-cha...@ietf.org
Objet : Call for adoption: draft-zhang-alto-oam-yang

Hi all,

As discussed during the IETF#113 meeting, this message initiates the call for 
adoption of draft-zhang-alto-oam-yang to meet the following ALTO WG milestone:

==
Dec 2022ALTO OAM Document/YANG Model
==

Please reply to this message indicating your support or objection to adopt the 
document.

The call will run till 08 April 2022.

Thank you
Qin & Med



_

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] IPR Poll for draft-zhang-alto-oam-yang

2022-03-29 Thread mohamed.boucadair

Hi all,

You are listed as a co-author of draft-zhang-alto-oam-yang currently under call 
for adoption in ALTO WG.

Please reply to this email (with the WG mailing list cced) indicating whether 
you are aware of any IPR related to draft-zhang-alto-oam-yang.

If you are aware of any, please confirm that all appropriate IPR disclosures 
required for full conformance with the provisions of BCP 78 and BCP 79 have 
already been field.

Cheers,
Qin & Med


_

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] Call for adoption: draft-zhang-alto-oam-yang

2022-03-23 Thread mohamed.boucadair

Hi all,

As discussed during the IETF#113 meeting, this message initiates the call for 
adoption of draft-zhang-alto-oam-yang to meet the following ALTO WG milestone:

==
Dec 2022ALTO OAM Document/YANG Model
==

Please reply to this message indicating your support or objection to adopt the 
document.

The call will run till 08 April 2022.

Thank you
Qin & Med

_

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

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

2022-03-21 Thread mohamed.boucadair

Hi Ben,

Thank you much for checking the updates and for all your effort to enhance IETF 
specs. That’s highly appreciated.  

One more revision is still needed before we declare this document ready to move 
forward: address a comment from Éric about TCP-centric metrics. -27 will be 
published very soon. 

Cheers,
Med

> -Message d'origine-
> De : Benjamin Kaduk via Datatracker 
> Envoyé : dimanche 20 mars 2022 21:43
> À : The IESG 
> Cc : draft-ietf-alto-performance-metr...@ietf.org; alto-cha...@ietf.org;
> alto@ietf.org; i...@j-f-s.de; i...@j-f-s.de
> Objet : Benjamin Kaduk's No Objection on draft-ietf-alto-performance-
> metrics-26: (with COMMENT)
> 
> Benjamin Kaduk 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:
> --
> 
> Thanks for the updates from -21 through -26, and my apologies to have
> taken so long to review the changes!
> 
> My previous discuss point about the "cur" operator of the "bw-utilized"
> metric is no longer relevant after the removal of that metric from this
> document.  I also appreciate the updated examples (including
> Content-Length); I seem to now get values that are off by one from
> what's
> currently in the -26, but given that the authors have consciously looked
> into the topic and I have low confidence in my own methodology, I will
> drop that as a Discuss point.
> 
> 


_

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

Re: [alto] Call for Adoption: draft-bw-alto-cost-mode-01

2022-03-17 Thread mohamed.boucadair

Hi Sabine,

Good catches and suggestions.

Fixed as you can see in 
https://github.com/boucadair/alto-cost-mode/commit/08dacba1ae6e108bdb8ce2f7a0402bf4f04144eb.

https://tinyurl.com/alto-cost-mode-latest provides the full diff.

Thank you.

Cheers,
Med

De : Randriamasy, Sabine (Nokia - FR/Paris-Saclay) 

Envoyé : jeudi 17 mars 2022 18:56
À : BOUCADAIR Mohamed INNOV/NET ; LUIS MIGUEL 
CONTRERAS MURILLO ; Dhruv Dhody 

Cc : alto-cha...@ietf.org; Kai Gao ; alto 
Objet : RE: [alto] Call for Adoption: draft-bw-alto-cost-mode-01

Hi Med,

I went through the v01 and the update on 
https://tinyurl.com/alto-cost-mode-latest and would have a couple of  questions 
& suggestions, listed below, to be discussed.
Cheers,
Sabine

---
In draft-bw-alto-cost-mode-01
---

- Section 3.1. Update to Section 6.1.2 of RFC7285
-– parag. 3, to better separate cost modes and values, how about the following 
change?
OLD
"NEW:
The cost mode   but additional values can be defined in the future."

NEW
"NEW:
The cost mode   but additional cost modes can be defined in the future."

--- Parag 4
“Cost modes are indicated in protocol messages as strings.”
As modes prefixed with "priv:" are allowed, maybe an encoding format is 
necessary. Something like:
  "The string MUST be no more than 32 characters, and it MUST NOT contain 
characters other than US- ASCII alphanumeric characters (U+0030-U+0039, U+0041 
-U+005A, and U+0061-U+007A), the hyphen ('-', U+002D), the colon (':', U+003A), 
or the low line ('_', +005F)."

To simplify, the set of allowed characters may be more restrictive, as long as 
it contains (':', U+003A).

---
In https://tinyurl.com/alto-cost-mode-latest
---
- Section 3.1 adds:
  "Future documents that define a new mode SHOULD indicate whether a new
defined cost mode apply to all or a subset of cost types."

This sentence is hard to parse since the cost mode is one of the 2 components 
of a cost type, the other one being cost metric (RFC 7285 Section 6.1).
So do you mean: "applies to all or a subset of cost metrics?"


From: alto mailto:alto-boun...@ietf.org>> On Behalf Of 
mohamed.boucad...@orange.com
Sent: Tuesday, March 8, 2022 10:16 AM
To: LUIS MIGUEL CONTRERAS MURILLO 
mailto:luismiguel.contrerasmuri...@telefonica.com>>;
 Dhruv Dhody mailto:dhruv.i...@gmail.com>>
Cc: alto-cha...@ietf.org; Kai Gao 
mailto:kai...@scu.edu.cn>>; alto 
mailto:alto@ietf.org>>
Subject: Re: [alto] Call for Adoption: draft-bw-alto-cost-mode-01

Hi Luis,
Re-, Dhruv,

Thank you for sharing your thoughts. I wasn’t against “enabling private use”, 
but was not sure that having a dedicated prefix will stop from using other 
values that match local templates (e.g., prefix with a PEN) and which would 
achieve the same objective.

I hear the consistency argument made bye Dhruv. That’s what I went with the 
changes that you can track at: https://tinyurl.com/alto-cost-mode-latest

Cheers,
Med

De : LUIS MIGUEL CONTRERAS MURILLO 
mailto:luismiguel.contrerasmuri...@telefonica.com>>
Envoyé : mardi 8 mars 2022 09:37
À : Dhruv Dhody mailto:dhruv.i...@gmail.com>>; BOUCADAIR 
Mohamed INNOV/NET 
mailto:mohamed.boucad...@orange.com>>
Cc : alto-cha...@ietf.org; Kai Gao 
mailto:kai...@scu.edu.cn>>; alto 
mailto:alto@ietf.org>>
Objet : RE: [alto] Call for Adoption: draft-bw-alto-cost-mode-01

Hi all,

I agree with Dhruv on the fact that enabling private use could be useful. I’m 
thinking on the fact of positioning ALTO as IETF Network Exposure Function (as 
described in draft-contreras-alto-ietf-nef-00) where some private (non-standard 
or experimental) information could be exposed among parties for specific 
purposes.

Best regards

Luis

De: alto mailto:alto-boun...@ietf.org>> En nombre de 
Dhruv Dhody
Enviado el: martes, 8 de marzo de 2022 8:09
Para: mohamed.boucad...@orange.com
CC: alto-cha...@ietf.org; Kai Gao 
mailto:kai...@scu.edu.cn>>; alto 
mailto:alto@ietf.org>>
Asunto: Re: [alto] Call for Adoption: draft-bw-alto-cost-mode-01

Hi Med,

On Tue, Mar 8, 2022 at 11:53 AM 
mailto:mohamed.boucad...@orange.com>> wrote:
Hi Dhruv,

Thank you for the comments.

We will be adding a “description” in the next iteration, however the details 
about the structure/etc should not be echoed in the table but be available in 
the pointer provided under “Specification”.


Dhruv: Maybe I was not clear. I meant to say the IANA sections in RFC 7285 
included a lot more text than what is there in this I-D. See 
https://datatracker.ietf.org/doc/html/rfc7285#section-14.2 and 
https://datatracker.ietf.org/doc/html/rfc7285#section-14.3. I was suggesting 
using a similar format and adding more text about this new registry as well.


I’m not sure a specific prefix for private use is needed, but I may be 
mistaken. When running experiments, the owners can

Re: [alto] [Editorial Errata Reported] RFC7285 (6876)

2022-03-10 Thread mohamed.boucadair

Hi Sebastien, all, 

Works for me. Thanks. 

Cheers,
Med

> -Message d'origine-
> De : Sebastian Kiesel 
> Envoyé : jeudi 10 mars 2022 13:17
> À : Chris Smiley 
> Cc : martin.h.d...@gmail.com; Zaheduzzaman Sarker
> ; BOUCADAIR Mohamed INNOV/NET
> ; ral...@google.com; repe...@cisco.com;
> y...@cs.yale.edu; sprev...@cisco.com; w.ro...@alcatel-lucent.com;
> shalu...@shlang.com; richard_wou...@cable.comcast.com; alto@ietf.org;
> RFC Errata System 
> Objet : Re: [Editorial Errata Reported] RFC7285 (6876)
> 
> Hi Med,
> 
> similar to the other case 6874, I think we should clarify that no policy
> change is intended, so:
> 
> 
> Type: Editorial
> Reported by: Mohamed BOUCADAIR 
> 
> Section: 14.3
> 
> Original Text
> -
>+++
>| Identifier | Intended Semantics |
>+++
>| pid| See Section 7.1.1  |
>| priv:  | Private use|
>+++
> 
>   Table 4: ALTO Endpoint Property Types
> 
> 
> Corrected Text
> --
>+++
>| Identifier | Intended Semantics |
>+++
>| pid| See Section 7.1.1  |
>+++
> 
>Note: Identifiers prefixed with "priv:" are
>reserved for Private Use (see Section 10.8.2.)
> 
>   Table 4: ALTO Endpoint Property Types
> 
> 
> would that work for you?
> 
> thanks
> Sebastian
> 
> On Wed, Mar 09, 2022 at 01:23:35PM -0800, Chris Smiley wrote:
> >
> > Greetings,
> >
> > We are unable to verify this erratum that the submitter marked as
> editorial.
> > Please note that we have changed the “Type” of the following errata
> > report to “Technical”.  As Stream Approver, please review and set the
> > Status and Type accordingly (see the definitions at
> > https://www.rfc-editor.org/errata-definitions/).
> >
> > You may review the report at:
> > https://www.rfc-editor.org/errata/eid6876
> >
> > Please see https://www.rfc-editor.org/how-to-verify/ for further
> > information on how to verify errata reports.
> >
> > Further information on errata can be found at:
> > https://www.rfc-editor.org/errata.php.
> >
> > Thank you.
> >
> > RFC Editor/cs
> >
> >
> > > On Mar 8, 2022, at 10:21 PM, RFC Errata System  editor.org> wrote:
> > >
> > > The following errata report has been submitted for RFC7285,
> > > "Application-Layer Traffic Optimization (ALTO) Protocol".
> > >
> > > --
> > > You may review the report below and at:
> > > https://www.rfc-editor.org/errata/eid6876
> > >
> > > --
> > > Type: Editorial
> > > Reported by: Mohamed BOUCADAIR 
> > >
> > > Section: 14.3
> > >
> > > Original Text
> > > -
> > >+++
> > >| Identifier | Intended Semantics |
> > >+++
> > >| pid| See Section 7.1.1  |
> > >| priv:  | Private use|
> > >+++
> > >
> > >   Table 4: ALTO Endpoint Property Types
> > >
> > >
> > > Corrected Text
> > > --
> > >+++
> > >| Identifier | Intended Semantics |
> > >+++
> > >| pid| See Section 7.1.1  |
> > >+++
> > >
> > >   Table 4: ALTO Endpoint Property Types
> > >
> > >
> > > Notes
> > > -
> > > priv: is not an identifier, but a prefix.
> > >
> > > Instructions:
> > > -
> > > This erratum is currently posted as "Reported". If necessary, please
> > > use "Reply All" to discuss whether it should be verified or
> > > rejected. When a decision is reached, the verifying party can log in
> > > to change the status and edit the report, if necessary.
> > >
> > > --
> > > RFC7285 (draft-ietf-alto-protocol-27)
> > > --
> > > Title   : Application-Layer Traffic Optimization (ALTO)
> Protocol
> > > Publication Date: September 2014
> > > Author(s)   : R. Alimi, Ed., R. Penno, Ed., Y. Yang, Ed., S.
> Kiesel, S. Previdi, W. Roome, S. Shalunov, R. Woundy
> > > Category: PROPOSED STANDARD
> > > Source  : Application-Layer Traffic Optimization
> > > Area: Transport
> > > Stream  : IETF
> > > Verifying Party : IESG
> > >
> >

__

Re: [alto] [Editorial Errata Reported] RFC7285 (6874)

2022-03-09 Thread mohamed.boucadair

Re-,

Works for me, thanks. 

Cheers,
Med

PS: The note is redundant with this text in 14.2, but that's OK as the note is 
intended to be echoed in the IANA registry:

   As specified in Section 10.6, identifiers prefixed with "priv:" are
   reserved for Private Use.

> -Message d'origine-
> De : Sebastian Kiesel 
> Envoyé : mercredi 9 mars 2022 11:28
> À : BOUCADAIR Mohamed INNOV/NET 
> Cc : Chris Smiley ; martin.h.d...@gmail.com;
> Zaheduzzaman Sarker ;
> ral...@google.com; repe...@cisco.com; y...@cs.yale.edu;
> sprev...@cisco.com; w.ro...@alcatel-lucent.com; shalu...@shlang.com;
> richard_wou...@cable.comcast.com; alto@ietf.org; RFC Errata System  edi...@rfc-editor.org>
> Objet : Re: [Editorial Errata Reported] RFC7285 (6874)
> 
> Hi Med,
> 
> On Wed, Mar 09, 2022 at 10:02:10AM +, mohamed.boucad...@orange.com
> wrote:
> > [Med] Looks good to me but with s/5226/8126 and removing "without a
> > need to register with IANA" as that is implied by "private use".
> >
> 
> what about:
> 
> > Corrected Text
> > --
> >
> >   +-+-+
> >   | Identifier  | Intended Semantics  |
> >   +-+-+
> >   | routingcost | See Section 6.1.1.1 |
> >   +-+-+
> >
> >   Note: Identifiers prefixed with "priv:" are
> >   reserved for Private Use (see Section 10.6)
> >
> >
> >Table 3: ALTO Cost Metrics
> 
> This would avoid consistency issues wrt. citing 5226 vs. 8126.
> 
> Thanks
> Sebastian

_

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

Re: [alto] [Editorial Errata Reported] RFC7285 (6874)

2022-03-09 Thread mohamed.boucadair

Re-,

Please see inline. 

Cheers,
Med

> -Message d'origine-
> De : Sebastian Kiesel 
> Envoyé : mercredi 9 mars 2022 10:47
> À : BOUCADAIR Mohamed INNOV/NET 
> Cc : Chris Smiley ; martin.h.d...@gmail.com;
> Zaheduzzaman Sarker ;
> ral...@google.com; repe...@cisco.com; y...@cs.yale.edu;
> sprev...@cisco.com; w.ro...@alcatel-lucent.com; shalu...@shlang.com;
> richard_wou...@cable.comcast.com; alto@ietf.org; RFC Errata System  edi...@rfc-editor.org>
> Objet : Re: [Editorial Errata Reported] RFC7285 (6874)
> 
> Hi Med,
> 
> On Wed, Mar 09, 2022 at 06:39:41AM +, mohamed.boucad...@orange.com
> wrote:
> > Hi Sebastien,
> >
> > "priv:" is not an identifier per se and as such it should not be
> > listed in that table. There is no change of the assignment policy in
> > the errata.
> 
> ok .. so no policy change intended. That's great, otherwise we would
> have to revise much more text.
> 
> 
> While it was maybe somewhat unfortunate to include the line in the table
> in the first place, I am worrying that removing it at this point in time
> could be interpreted as a policy change.
> 
> Maybe we should clarify that by adding a line right below the table:
> 
> OLD:
> 
> > Original Text
> > -
> >
> >   +-+-+
> >   | Identifier  | Intended Semantics  |
> >   +-+-+
> >   | routingcost | See Section 6.1.1.1 |
> >   | priv:   | Private use |
> >   +-+-+
> >
> >Table 3: ALTO Cost Metrics
> >
> > Corrected Text
> > --
> >
> >   +-+-+
> >   | Identifier  | Intended Semantics  |
> >   +-+-+
> >   | routingcost | See Section 6.1.1.1 |
> >   +-+-+
> >
> >   Note: Identifiers prefixed with "priv:"
> >   are reserved for Private Use [RFC5226]
> >   without a need to register with IANA.
> >
> >
> >Table 3: ALTO Cost Metrics
> 

[Med] Looks good to me but with s/5226/8126 and removing "without a need to 
register with IANA" as that is implied by "private use". 

RFC8126 says the following: 

   IANA does not record assignments from registries
   or ranges with this policy (and therefore there is no need for IANA
   to review them) and assignments are not generally useful for broad
   interoperability.  It is the responsibility of the sites making use
   of the Private Use range to ensure that no conflicts occur (within
   the intended scope of use). 

> 
> 
> If we are worried about consistency, wouldn't we have to update Table 4
> as well?

[Med] Indeed. This was reported in a separate erratum :-) 


  Keeping RFC 7285 consistent within the document is probably
> more important than compatibility with extensions that are specified
> some 8 years later.
> 
> Thanks,
> Sebastian
> 
> 
> 
> >
> > FWIW, the proposed changed was triggered by a comment "about
> consistency" we received for draft-bw-alto-cost-mode.
> >
> > As a Chair, I prefer that to be fixed in the original RFC rather than
> blinding echoing that same structure for every (new) ALTO registry.
> >
> > Cheers,
> > Med
> >
> > > -Message d'origine-
> > > De : Sebastian Kiesel  Envoyé : mercredi 9
> > > mars 2022 00:07 À : Chris Smiley  Cc :
> > > martin.h.d...@gmail.com; Zaheduzzaman Sarker
> > > ; BOUCADAIR Mohamed INNOV/NET
> > > ; ral...@google.com;
> > > repe...@cisco.com; y...@cs.yale.edu; sprev...@cisco.com;
> > > w.ro...@alcatel-lucent.com; shalu...@shlang.com;
> > > richard_wou...@cable.comcast.com; alto@ietf.org; RFC Errata System
> > >  Objet : Re: [Editorial Errata Reported]
> > > RFC7285 (6874)
> > >
> > > Hi,
> > >
> > > I am not sure whether this is an editorial erratum. Not even sure
> > > whether this issue is an erratum at all - or maybe a
> > > specification/policy change that, if desired, should be made through
> > > some consensus process that leads to an RFC updating RFC 7285.
> > >
> > > The original idea was to establish an IANA registry "ALTO Cost
> > > Metric Registry", which is initially populated with only one entry
> > > "routingcost".
> > > Furthermore, section 10.6. specifies that identifiers prefixed with
> > > "priv:" are reserved for Private Use without a need to register with
> > > IANA.
> > > So technically, the report is correct, "priv:" as such is not a cost
> > > metric. I think it is still valuable to have it in the table, as a
> > > reminder to IANA, not to register names starting with "priv:".
> > > Maybe we should have written "priv:*" along with a further
> > > explanation that the star means further characters, but I doubt that
> > > this would have added clarity.
> > >
> > > If the erratum report is just for cosmetic

Re: [alto] [Editorial Errata Reported] RFC7285 (6876)

2022-03-09 Thread mohamed.boucadair

Hi Dhruv,

I guess you also noticed that we don’t have such entry for the new created
subregistries (while there is a provision for priv prefix for those as well in
the spec):

*
https://www.iana.org/assignments/alto-protocol/alto-protocol.xhtml#alto-entity-domain-type
*
https://www.iana.org/assignments/alto-protocol/alto-protocol.xhtml#alto-entity-property-type

This is something we discussed and agreed with the authors when addressing the
IESG comments for draft-ietf-alto-unified-props-new.

As a reminder, some IESG members were concerned with listing priv: in the
registry. Please refer to the comments from Murray, in particular:

“For Sections 12.2 and 12.3, I suggest not including a registry entry for
"priv:" because that's not an identifier, but everything else is. It's fine to
leave in prose saying nothing can be registered using "priv:" as a prefix, as
those are meant to indicate private use.”

Having a note would sufficient to refer to the reserved prefix. Removing the
entry would be consistent with the newly created registry and aligned with the
intended usage.

Thank you.

Cheers,
Med

De : Dhruv Dhody
Envoyé : mercredi 9 mars 2022 09:26
À : BOUCADAIR Mohamed INNOV/NET
Cc : alto
Objet : Re: [alto] [Editorial Errata Reported] RFC7285 (6876)

Hi,

Does the erratum ask that we remove priv: from the IANA registry as well?

https://www.iana.org/assignments/alto-protocol/alto-protocol.xhtml#cost-metrics
https://www.iana.org/assignments/alto-protocol/alto-protocol.xhtml#endpoint-property-types

I think that would be unfortunate. Perhaps some text in the Intended Semantics
can be added to say it is a prefix!

Thanks!
Dhruv

On Wed, Mar 9, 2022 at 12:20 PM RFC Errata System
mailto:rfc-edi...@rfc-editor.org>> wrote:
The following errata report has been submitted for RFC7285,
"Application-Layer Traffic Optimization (ALTO) Protocol".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6876

--
Type: Editorial
Reported by: Mohamed BOUCADAIR
mailto:mohamed.boucad...@orange.com>>

Section: 14.3

Table 4: ALTO Endpoint Property Types

Corrected Text
--
+++
| Identifier | Intended Semantics |
+++
| pid| See Section 7.1.1 |
+++

Table 4: ALTO Endpoint Property Types

Notes
-
priv: is not an identifier, but a prefix.

Instructions:
-
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party
can log in to change the status and edit the report, if necessary.

--
RFC7285 (draft-ietf-alto-protocol-27)
--
Title : Application-Layer Traffic Optimization (ALTO) Protocol
Publication Date: September 2014
Author(s) : R. Alimi, Ed., R. Penno, Ed., Y. Yang, Ed., S. Kiesel, S.
Previdi, W. Roome, S. Shalunov, R. Woundy
Category: PROPOSED STANDARD
Source : Application-Layer Traffic Optimization
Area: Transport
Stream : IETF
Verifying Party : IESG

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

Re: [alto] [Editorial Errata Reported] RFC7285 (6874)

2022-03-08 Thread mohamed.boucadair

Hi Sebastien, 

"priv:" is not an identifier per se and as such it should not be listed in that 
table. There is no change of the assignment policy in the errata. 

FWIW, the proposed changed was triggered by a comment "about consistency" we 
received for draft-bw-alto-cost-mode.

As a Chair, I prefer that to be fixed in the original RFC rather than blinding 
echoing that same structure for every (new) ALTO registry. 

Cheers,
Med

> -Message d'origine-
> De : Sebastian Kiesel 
> Envoyé : mercredi 9 mars 2022 00:07
> À : Chris Smiley 
> Cc : martin.h.d...@gmail.com; Zaheduzzaman Sarker
> ; BOUCADAIR Mohamed INNOV/NET
> ; ral...@google.com; repe...@cisco.com;
> y...@cs.yale.edu; sprev...@cisco.com; w.ro...@alcatel-lucent.com;
> shalu...@shlang.com; richard_wou...@cable.comcast.com; alto@ietf.org;
> RFC Errata System 
> Objet : Re: [Editorial Errata Reported] RFC7285 (6874)
> 
> Hi,
> 
> I am not sure whether this is an editorial erratum. Not even sure
> whether this issue is an erratum at all - or maybe a
> specification/policy change that, if desired, should be made through
> some consensus process that leads to an RFC updating RFC 7285.
> 
> The original idea was to establish an IANA registry "ALTO Cost Metric
> Registry", which is initially populated with only one entry
> "routingcost".
> Furthermore, section 10.6. specifies that identifiers prefixed with
> "priv:" are reserved for Private Use without a need to register with
> IANA.
> So technically, the report is correct, "priv:" as such is not a cost
> metric. I think it is still valuable to have it in the table, as a
> reminder to IANA, not to register names starting with "priv:".
> Maybe we should have written "priv:*" along with a further explanation
> that the star means further characters, but I doubt that this would have
> added clarity.
> 
> If the erratum report is just for cosmetic reasons, removing a prefix
> from a table that should hold only complete names ... well ... I'd say
> this is not worth the effort, maybe even harmful. If, on the other hand,
> the intention is to deprecate the whole idea of having a part of the
> namespace for private use without IANA registration, this should IMO go
> through a broader consensuns process and not through an erratum.
> 
> Just my two cents, being one of the original authors.
> WG Chairs / AD, please advise.
> 
> thanks,
> Sebastian
> 
> 
> 
> 
> On Tue, Mar 08, 2022 at 01:39:12PM -0800, Chris Smiley wrote:
> >
> > Greetings,
> >
> > We are unable to verify this erratum that the submitter marked as
> editorial.
> > Please note that we have changed the “Type” of the following errata
> > report to “Technical”.  As Stream Approver, please review and set the
> > Status and Type accordingly (see the definitions at
> > https://www.rfc-editor.org/errata-definitions/).
> >
> > You may review the report at:
> > https://www.rfc-editor.org/errata/eid6874
> >
> > Please see https://www.rfc-editor.org/how-to-verify/ for further
> > information on how to verify errata reports.
> >
> > Further information on errata can be found at:
> > https://www.rfc-editor.org/errata.php.
> >
> > Thank you.
> >
> > RFC Editor/cs
> >
> >
> > > On Mar 8, 2022, at 12:50 AM, RFC Errata System  editor.org> wrote:
> > >
> > > The following errata report has been submitted for RFC7285,
> > > "Application-Layer Traffic Optimization (ALTO) Protocol".
> > >
> > > --
> > > You may review the report below and at:
> > > https://www.rfc-editor.org/errata/eid6874
> > >
> > > --
> > > Type: Editorial
> > > Reported by: Mohamed BOUCADAIR 
> > >
> > > Section: 14.2
> > >
> > > Original Text
> > > -
> > >
> > >   +-+-+
> > >   | Identifier  | Intended Semantics  |
> > >   +-+-+
> > >   | routingcost | See Section 6.1.1.1 |
> > >   | priv:   | Private use |
> > >   +-+-+
> > >
> > >Table 3: ALTO Cost Metrics
> > >
> > > Corrected Text
> > > --
> > >
> > >   +-+-+
> > >   | Identifier  | Intended Semantics  |
> > >   +-+-+
> > >   | routingcost | See Section 6.1.1.1 |
> > >   +-+-+
> > >
> > >Table 3: ALTO Cost Metrics
> > >
> > > Notes
> > > -
> > > priv: is not a cost metric but a prefix
> > >
> > > Instructions:
> > > -
> > > This erratum is currently posted as "Reported". If necessary, please
> > > use "Reply All" to discuss whether it should be verified or
> > > rejected. When a decision is reached, the verifying party can log in
> > > to change the status and edit the report, if necessary.
> > >
> > > -

Re: [alto] Call for Adoption: draft-bw-alto-cost-mode-01

2022-03-08 Thread mohamed.boucadair

Hi Luis,
Re-, Dhruv,

Thank you for sharing your thoughts. I wasn’t against “enabling private use”, 
but was not sure that having a dedicated prefix will stop from using other 
values that match local templates (e.g., prefix with a PEN) and which would 
achieve the same objective.

I hear the consistency argument made bye Dhruv. That’s what I went with the 
changes that you can track at: https://tinyurl.com/alto-cost-mode-latest

Cheers,
Med

De : LUIS MIGUEL CONTRERAS MURILLO 
Envoyé : mardi 8 mars 2022 09:37
À : Dhruv Dhody ; BOUCADAIR Mohamed INNOV/NET 

Cc : alto-cha...@ietf.org; Kai Gao ; alto 
Objet : RE: [alto] Call for Adoption: draft-bw-alto-cost-mode-01

Hi all,

I agree with Dhruv on the fact that enabling private use could be useful. I’m 
thinking on the fact of positioning ALTO as IETF Network Exposure Function (as 
described in draft-contreras-alto-ietf-nef-00) where some private (non-standard 
or experimental) information could be exposed among parties for specific 
purposes.

Best regards

Luis

De: alto mailto:alto-boun...@ietf.org>> En nombre de 
Dhruv Dhody
Enviado el: martes, 8 de marzo de 2022 8:09
Para: mohamed.boucad...@orange.com
CC: alto-cha...@ietf.org; Kai Gao 
mailto:kai...@scu.edu.cn>>; alto 
mailto:alto@ietf.org>>
Asunto: Re: [alto] Call for Adoption: draft-bw-alto-cost-mode-01

Hi Med,

On Tue, Mar 8, 2022 at 11:53 AM 
mailto:mohamed.boucad...@orange.com>> wrote:
Hi Dhruv,

Thank you for the comments.

We will be adding a “description” in the next iteration, however the details 
about the structure/etc should not be echoed in the table but be available in 
the pointer provided under “Specification”.


Dhruv: Maybe I was not clear. I meant to say the IANA sections in RFC 7285 
included a lot more text than what is there in this I-D. See 
https://datatracker.ietf.org/doc/html/rfc7285#section-14.2 and 
https://datatracker.ietf.org/doc/html/rfc7285#section-14.3. I was suggesting 
using a similar format and adding more text about this new registry as well.


I’m not sure a specific prefix for private use is needed, but I may be 
mistaken. When running experiments, the owners can just pick any value which 
does not conflict with a value in the registry + provide the semantic/behavior 
to ALTO nodes that are involved in the experiment.


Dhruv: Experiments sometimes leak into the wild and thus we discourage simply 
picking any value and opting for private use and experimental use values in the 
IANA registry. Further, consistency in the protocol extensions is a good thing 
to have, and thus using priv: makes sense to me! I was not in the room when RFC 
7285 was being developed. Maybe some of the OG participants from the WG could 
through some light on this as well :)

Thanks!
Dhruv


Cheers,
Med

De : Dhruv Dhody mailto:dhruv.i...@gmail.com>>
Envoyé : mardi 8 mars 2022 06:52
À : Kai Gao mailto:kai...@scu.edu.cn>>
Cc : alto mailto:alto@ietf.org>>; 
alto-cha...@ietf.org
Objet : Re: [alto] Call for Adoption: draft-bw-alto-cost-mode-01

Hi Kai,

Support adoption!

Should the IANA consideration section follow the format followed by RFC 7285 
which includes lot more details on the rationale, requested information, string 
format etc.

That also made me wonder if there is some benefit to also mark priv: for 
private use as done for some of the other ALTO registries.

Thanks!
Dhruv

On Mon, Mar 7, 2022 at 4:58 PM mailto:kai...@scu.edu.cn>> 
wrote:
Dear all,

I have been appointed to run the Call for Adoption of 
draft-bw-alto-cost-mode-01.

Following up with what has been proposed and agreed during the IESG review on 
draft-ietf-alto-path-vector [1], we are starting a call for adoption of the 
ALTO cost mode [2] document as a charter deliverable. It both helps push 
forward existing WG document and fits in the protocol maintenance item in the 
current charter.

The Call for Adoption will close on March 21 (2 weeks after the IETF submission 
deadline). Please post to the mailing list if you support or appose the 
adoption, or have any comments or suggestions.

[1] https://mailarchive.ietf.org/arch/msg/alto/WWoyJyM0PioBWM_rADYT-Z_I8t4/
[2] https://datatracker.ietf.org/doc/html/draft-bw-alto-cost-mode-01

Thanks!

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

_



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 et

Re: [alto] Call for Adoption: draft-bw-alto-cost-mode-01

2022-03-07 Thread mohamed.boucadair

Hi Dhruv,

Thank you for the comments.

We will be adding a “description” in the next iteration, however the details 
about the structure/etc should not be echoed in the table but be available in 
the pointer provided under “Specification”.

I’m not sure a specific prefix for private use is needed, but I may be 
mistaken. When running experiments, the owners can just pick any value which 
does not conflict with a value in the registry + provide the semantic/behavior 
to ALTO nodes that are involved in the experiment.

Cheers,
Med

De : Dhruv Dhody 
Envoyé : mardi 8 mars 2022 06:52
À : Kai Gao 
Cc : alto ; alto-cha...@ietf.org
Objet : Re: [alto] Call for Adoption: draft-bw-alto-cost-mode-01

Hi Kai,

Support adoption!

Should the IANA consideration section follow the format followed by RFC 7285 
which includes lot more details on the rationale, requested information, string 
format etc.

That also made me wonder if there is some benefit to also mark priv: for 
private use as done for some of the other ALTO registries.

Thanks!
Dhruv

On Mon, Mar 7, 2022 at 4:58 PM mailto:kai...@scu.edu.cn>> 
wrote:
Dear all,

I have been appointed to run the Call for Adoption of 
draft-bw-alto-cost-mode-01.

Following up with what has been proposed and agreed during the IESG review on 
draft-ietf-alto-path-vector [1], we are starting a call for adoption of the 
ALTO cost mode [2] document as a charter deliverable. It both helps push 
forward existing WG document and fits in the protocol maintenance item in the 
current charter.

The Call for Adoption will close on March 21 (2 weeks after the IETF submission 
deadline). Please post to the mailing list if you support or appose the 
adoption, or have any comments or suggestions.

[1] https://mailarchive.ietf.org/arch/msg/alto/WWoyJyM0PioBWM_rADYT-Z_I8t4/
[2] https://datatracker.ietf.org/doc/html/draft-bw-alto-cost-mode-01

Thanks!

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

_

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

Re: [alto] Call for Adoption: draft-bw-alto-cost-mode-01

2022-03-07 Thread mohamed.boucadair

Re-,

Good points, Adrian. These (except removing the pointer to Section 4.8 of 8126) 
will be fixed in the next version.

Thank you. 

Cheers,
Med

> -Message d'origine-
> De : Adrian Farrel 
> Envoyé : lundi 7 mars 2022 13:06
> À : kai...@scu.edu.cn; alto@ietf.org; alto-cha...@ietf.org
> Objet : RE: [alto] Call for Adoption: draft-bw-alto-cost-mode-01
> 
> Thanks Kai,
> 
> I had a quick look at the draft: it is blissfully short!
> 
> Looks to me that this document is needed and should be adopted.
> 
> Two small points in Section 4:
> 
> I think you should add a "description" to the registry for each cost
> mode.
> 
> Please don't use BCP14 language in the IANA section. So...
> OLD
>New values MUST be assigned after IETF Review (Section 4.8 of
>[RFC8126]).
> NEW
>The assignment policy for this registry is "IETF Review" [RFC8126].
> END
> 
> Thanks,
> Adrian
> -Original Message-
> From: alto  On Behalf Of kai...@scu.edu.cn
> Sent: 07 March 2022 11:28
> To: alto@ietf.org; alto-cha...@ietf.org
> Subject: [alto] Call for Adoption: draft-bw-alto-cost-mode-01
> 
> Dear all,
> 
> I have been appointed to run the Call for Adoption of draft-bw-alto-
> cost-mode-01.
> 
> Following up with what has been proposed and agreed during the IESG
> review on draft-ietf-alto-path-vector [1], we are starting a call for
> adoption of the ALTO cost mode [2] document as a charter deliverable. It
> both helps push forward existing WG document and fits in the protocol
> maintenance item in the current charter.
> 
> The Call for Adoption will close on March 21 (2 weeks after the IETF
> submission deadline). Please post to the mailing list if you support or
> appose the adoption, or have any comments or suggestions.
> 
> [1] https://mailarchive.ietf.org/arch/msg/alto/WWoyJyM0PioBWM_rADYT-
> Z_I8t4/
> [2] https://datatracker.ietf.org/doc/html/draft-bw-alto-cost-mode-01
> 
> Thanks!
> 
> Best,
> Kai
> ___
> alto mailing list
> alto@ietf.org
> https://www.ietf.org/mailman/listinfo/alto


_

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

Re: [alto] Call for Adoption: draft-bw-alto-cost-mode-01

2022-03-07 Thread mohamed.boucadair

Hi Kai, 

Thank you for taking care of the call. 

FWIW, I don't have any IPR related to this draft. 

Cheers,
Med

> -Message d'origine-
> De : alto  De la part de kai...@scu.edu.cn
> Envoyé : lundi 7 mars 2022 12:28
> À : alto@ietf.org; alto-cha...@ietf.org
> Objet : [alto] Call for Adoption: draft-bw-alto-cost-mode-01
> 
> Dear all,
> 
> I have been appointed to run the Call for Adoption of draft-bw-alto-
> cost-mode-01.
> 
> Following up with what has been proposed and agreed during the IESG
> review on draft-ietf-alto-path-vector [1], we are starting a call for
> adoption of the ALTO cost mode [2] document as a charter deliverable. It
> both helps push forward existing WG document and fits in the protocol
> maintenance item in the current charter.
> 
> The Call for Adoption will close on March 21 (2 weeks after the IETF
> submission deadline). Please post to the mailing list if you support or
> appose the adoption, or have any comments or suggestions.
> 
> [1] https://mailarchive.ietf.org/arch/msg/alto/WWoyJyM0PioBWM_rADYT-
> Z_I8t4/
> [2] https://datatracker.ietf.org/doc/html/draft-bw-alto-cost-mode-01
> 
> Thanks!
> 
> Best,
> Kai
> ___
> alto mailing list
> alto@ietf.org
> https://www.ietf.org/mailman/listinfo/alto

_

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

Re: [alto] [sfc] New Version Notification for draft-lachos-multi-domain-sfc-alto-00.txt

2018-07-03 Thread mohamed.boucadair

Dear Danny,

Thank you for sharing this draft.

My main comments about this draft are as follows:

· The SFC WG is currently scoped to one single administrative domain. 
Even for the work we have done about hierarchical SFC, the assumption is that 
sub-domains are managed by the same administrative entity.

· Before getting into protocol details about how to realize 
inter-domain service chains, it would be really valuable to identify and 
describe concrete uses cases which require SFs from distinct administrative 
domains + justify why topology visibility is required + paths have to be 
computed end-to-end and so on.

FWIW, you may find some additional comments at:

· .pdf: 
https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/draft-lachos-multi-domain-sfc-alto-00-rev%20Med.pdf

· .doc: 
https://github.com/boucadair/IETF-Drafts-Reviews/raw/master/draft-lachos-multi-domain-sfc-alto-00-rev%20Med.doc

Cheers,
Med

De : sfc [mailto:sfc-boun...@ietf.org] De la part de Danny Alex Lachos Perez
Envoyé : mardi 3 juillet 2018 01:35
À : internet-dra...@ietf.org; IETF ALTO; s...@ietf.org; nf...@irtf.org
Cc : qiao.xi...@cs.yale.edu; Christian Rodolfo E. Rothenberg; Y. Richard Yang
Objet : Re: [sfc] New Version Notification for 
draft-lachos-multi-domain-sfc-alto-00.txt

Dear WG members.

The main idea behalf this draft is to start a discussion (SFC, ALTO as well as 
other WGs) regarding if, how, and under what conditions ALTO can be useful to 
improve the multi-domain SFC process.

This version provides arguments why ALTO is a meaningful protocol in the 
context of SFC traversing different domains, and it presents use case examples 
about the how ALTO can be used to advertise and discover (abstract) topology, 
resource and service information from different domains, and then compute 
inter-domain service function paths.

Any comment, question, and suggestion from the WGs would be greatly appreciated.

Ss

Danny Lachos

On Mon, Jul 2, 2018 at 5:12 PM 
mailto:internet-dra...@ietf.org>> wrote:

A new version of I-D, draft-lachos-multi-domain-sfc-alto-00.txt
has been successfully submitted by Danny Alex Lachos Perez and posted to the
IETF repository.

Name:   draft-lachos-multi-domain-sfc-alto
Revision:   00
Title:  Multi-domain Service Function Chaining with ALTO
Document date:  2018-07-02
Group:  Individual Submission
Pages:  14
URL:
https://www.ietf.org/internet-drafts/draft-lachos-multi-domain-sfc-alto-00.txt
Status: 
https://datatracker.ietf.org/doc/draft-lachos-multi-domain-sfc-alto/
Htmlized:   
https://tools.ietf.org/html/draft-lachos-multi-domain-sfc-alto-00
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-lachos-multi-domain-sfc-alto


Abstract:
   Currently, Service Function Chaining (SFC) that span domains with
   different technology, administration or ownership are being defined
   by the SFC WG.  This document focuses on how the Application Layer
   Traffic Optimization (ALTO) protocol can be used to advertise and
   discover abstract topology, resource and service information from
   different domains, and then compute inter-domain service function
   paths.  Another important concern of this draft is to initiate a
   discussion (ALTO, SFC as well as other WGs) regarding if, how, and
   under what conditions ALTO can be useful to improve the multi-domain
   SFC process.





Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at 
tools.ietf.org.

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

72 matches

Mail list logo