Re: [alto] RFC 9275 on An Extension for Application-Layer Traffic Optimization (ALTO): Path Vector

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

Hi Qin, Richard, all,
Big thanks to all people who contributed to the improvement of this document 
with their comments, review and guidance.
Best regards,
Sabine

From: alto  On Behalf Of Y. Richard Yang
Sent: Saturday, September 24, 2022 3:23 AM
To: Qin Wu 
Cc: IETF ALTO 
Subject: Re: [alto] RFC 9275 on An Extension for Application-Layer Traffic 
Optimization (ALTO): Path Vector

Hi Qin, all,

This is a good progress indeed. I share with you that many WG members including 
both the authors and many others have made contributions in the process. A big 
thank you!

Richard

On Fri, Sep 23, 2022 at 9:13 PM Qin Wu 
mailto:40huawei@dmarc.ietf.org>> wrote:
Congratulation to all authors and other people who contributed to this work all 
the way along!

-Qin (on behalf of chairs)
-邮件原件-
发件人: alto [mailto:alto-boun...@ietf.org] 代表 
rfc-edi...@rfc-editor.org
发送时间: 2022年9月24日 4:39
收件人: ietf-annou...@ietf.org; 
rfc-d...@rfc-editor.org
抄送: rfc-edi...@rfc-editor.org; 
drafts-update-...@iana.org; 
alto@ietf.org
主题: [alto] RFC 9275 on An Extension for Application-Layer Traffic Optimization 
(ALTO): Path Vector

A new Request for Comments is now available in online RFC libraries.


RFC 9275

Title:  An Extension for Application-Layer Traffic
Optimization (ALTO): Path Vector
Author: K. Gao,
Y. Lee,
S. Randriamasy,
Y. Yang,
J. Zhang
Status: Experimental
Stream: IETF
Date:   September 2022
Mailbox:kai...@scu.edu.cn,
younglee...@gmail.com,

sabine.randriam...@nokia-bell-labs.com,
y...@cs.yale.edu,

jingxuan.n.zh...@gmail.com
Pages:  54
Updates/Obsoletes/SeeAlso:   None

I-D Tag:draft-ietf-alto-path-vector-25.txt

URL:https://www.rfc-editor.org/info/rfc9275

DOI:10.17487/RFC9275

This document is an extension to the base Application-Layer Traffic 
Optimization (ALTO) protocol. It extends the ALTO cost map and ALTO property 
map services so that an application can decide to which
endpoint(s) to connect based not only on numerical/ordinal cost values but also 
on fine-grained abstract information regarding the paths. This is useful for 
applications whose performance is impacted by specific components of a network 
on the end-to-end paths, e.g., they may infer that several paths share common 
links and prevent traffic bottlenecks by avoiding such paths. This extension 
introduces a new abstraction called the "Abstract Network Element" (ANE) to 
represent these components and encodes a network path as a vector of ANEs. 
Thus, it provides a more complete but still abstract graph representation of 
the underlying network(s) for informed traffic optimization among endpoints.

This document is a product of the Application-Layer Traffic Optimization 
Working Group of the IETF.


EXPERIMENTAL: This memo defines an Experimental Protocol for the Internet 
community.  It does not specify an Internet standard of any kind. Discussion 
and suggestions for improvement are requested.
Distribution of this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  https://www.ietf.org/mailman/listinfo/ietf-announce
  https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see https://www.rfc-editor.org/search For 
downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk

Requests for special distribution should be addressed to either the author of 
the RFC in question, or to 
rfc-edi...@rfc-editor.org.  Unless 
specifically noted otherwise on the RFC itself, all RFCs are for unlimited 
distribution.


The RFC Editor Team
Association Management Solutions, LLC


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

Re: [alto] Missing the meeting today

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

Dear all
All my best of fast recovery to Kai for his back. I can't make it either, today 
due to other meetings. FYI I will be off next week and back on September 6th. 
Best regards,
Sabine

>-Original Message-
>From: alto  On Behalf Of kaigao
>Sent: Tuesday, August 9, 2022 1:01 PM
>To: Qin Wu ; alto ; Richard Yang
>; Jordi Ros Giralt ; LUIS MIGUEL
>CONTRERAS MURILLO ; Jensen
>Zhang 
>Subject: [alto] Missing the meeting today
>
>Dear all,
>
>I had a back surgery today and will take a rest for the next coming days. In
>that case, I will not be able to attend the meeting today. I will read the
>meeting notes once I get better. My apologies.
>
>Best,
>Kai
>___
>alto mailing list
>alto@ietf.org
>https://www.ietf.org/mailman/listinfo/alto

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

Re: [alto] WG adoption call for draft-schott-alto-new-transport-01

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

Hi all,

I have read this draft and support its adoption as a WG document. It is in good 
shape and next iterations will among others clarify the motivation (current 
shortcomings & advantages), in the introduction and positioning in the 
requirements section.
Best regards,
Sabine

From: alto  On Behalf Of Qin Wu
Sent: Tuesday, May 31, 2022 1:11 PM
To: alto@ietf.org
Subject: [alto] WG adoption call for draft-schott-alto-new-transport-01

Hi folks,

This begins a 2 week WG Adoption Call for the following draft:

https://datatracker.ietf.org/doc/draft-schott-alto-new-transport/

Please indicate your support or objections by June 15th, 2022.

Authors, please respond to the list indicating whether you are aware of any IPR 
that applies to this draft.

Thanks,

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

Re: [alto] Question on ANE name format

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

Hi Med,
Thanks for your feedback. Then we will go ahead for option 1

OLD
".ane:dc45.srv9" and ".ane:dc6.srv-cluster8"
NEW
".ane:dc45-srv9" and ".ane:dc6-srvcluster8"

Cheers,
Sabine

From: mohamed.boucad...@orange.com 
Sent: Thursday, May 12, 2022 2:40 PM
To: Randriamasy, Sabine (Nokia - FR/Paris-Saclay) 
; IETF ALTO ; 
martin.h.d...@gmail.com
Subject: RE: Question on ANE name format

Hi Sabine, all,

I would go personally for option 1. Thanks.

Cheers,
Med

De : Randriamasy, Sabine (Nokia - FR/Paris-Saclay) 
mailto:sabine.randriam...@nokia-bell-labs.com>>
Envoyé : lundi 9 mai 2022 18:20
À : IETF ALTO mailto:alto@ietf.org>>; BOUCADAIR Mohamed 
INNOV/NET mailto:mohamed.boucad...@orange.com>>; 
Qin (Bill) Wu mailto:bill...@huawei.com>>; 
martin.h.d...@gmail.com<mailto:martin.h.d...@gmail.com>; 
zaheduzzaman.sar...@ericsson.com<mailto:zaheduzzaman.sar...@ericsson.com>
Cc : we...@wdroome.com<mailto:we...@wdroome.com>; Jensen Zhang 
mailto:jen...@jensen-zhang.site>>; Kai Gao 
mailto:kai...@scu.edu.cn>>; 'Richard Yang' 
mailto:y...@cs.yale.edu>>
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 privilegi

Re: [alto] Question on ANE name format

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

Apologies, re-sending with Wendy and Richard in CC
Sabine

From: alto  On Behalf Of Randriamasy, Sabine (Nokia - 
FR/Paris-Saclay)
Sent: Monday, May 9, 2022 6:20 PM
To: IETF ALTO ; mohamed.boucad...@orange.com; Qin (Bill) Wu 
; martin.h.d...@gmail.com; zaheduzzaman.sar...@ericsson.com
Cc: Kai Gao ; Jensen Zhang 
Subject: [alto] 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
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

[alto] Question on ANE name format

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

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
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

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

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

+1,
Best regards
Sabine

From: alto  On Behalf Of Qiao Xiang
Sent: Thursday, April 7, 2022 11:17 AM
To: Luis M. Contreras 
Cc: roland.sch...@telekom.de; draft-zhang-alto-oam-y...@ietf.org; IETF ALTO 
; alto-cha...@ietf.org
Subject: Re: [alto] Call for adoption: draft-zhang-alto-oam-yang

Hi all,

I support the adoption of this draft.



Best
Qiao

On Thu, Apr 7, 2022 at 5:11 PM Luis M. Contreras 
mailto:contreras.i...@gmail.com>> wrote:
Hi all,

I support the adoption of this draft.

Best regards

Luis


El mié, 6 abr 2022 a las 18:30, 
mailto:roland.sch...@telekom.de>> escribió:
Hi,

I support the adoption of the draft as a good starting point for further work.

Best Regards

Roland



Von: mohamed.boucad...@orange.com 
mailto:mohamed.boucad...@orange.com>>
Gesendet: Montag, 4. April 2022 12:14
An: alto@ietf.org; 
draft-zhang-alto-oam-y...@ietf.org
Cc: alto-cha...@ietf.org
Betreff: RE: Call for adoption: draft-zhang-alto-oam-yang

Hi all,

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

Cheers,
Qin & Med

De : mohamed.boucad...@orange.com 
mailto: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


--
___
Luis M. Contreras
contreras.i...@gmail.com
luismiguel.contrerasmuri...@telefonica.com
Global CTIO unit / Telefonica
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto


--
Qiao Xiang
Professor, Xiamen University
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

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

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

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  On Behalf Of mohamed.boucad...@orange.com
Sent: Tuesday, March 8, 2022 10:16 AM
To: LUIS MIGUEL CONTRERAS MURILLO ; 
Dhruv Dhody 
Cc: alto-cha...@ietf.org; Kai Gao ; alto 
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 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 m

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

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

+1
And agree on the information to be added on the IANA registry cost mode 
entries. 
Best regards,
Sabine

>-Original Message-
>From: alto  On Behalf Of Qin Wu
>Sent: Monday, March 7, 2022 2:26 PM
>To: mohamed.boucad...@orange.com; kai...@scu.edu.cn; alto@ietf.org;
>alto-cha...@ietf.org
>Subject: Re: [alto] Call for Adoption: draft-bw-alto-cost-mode-01
>
>+1,
>For the record, I have no IPR related to this draft.
>
>-Qin
>-邮件原件-
>发件人: mohamed.boucad...@orange.com
>[mailto:mohamed.boucad...@orange.com]
>发送时间: 2022年3月7日 19:49
>收件人: kai...@scu.edu.cn; alto@ietf.org; alto-cha...@ietf.org
>主题: RE: [alto] Call for Adoption: draft-bw-alto-cost-mode-01
>
>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
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

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

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

Hello Ben,

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

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

Best regards,
Sabine

>-Original Message-
>From: Benjamin Kaduk via Datatracker 
>Sent: Thursday, December 2, 2021 12:00 AM
>To: The IESG 
>Cc: draft-ietf-alto-unified-props-...@ietf.org; alto-cha...@ietf.org;
>alto@ietf.org; Vijay Gurbani ;
>vijay.gurb...@gmail.com
>Subject: Benjamin Kaduk's Discuss on draft-ietf-alto-unified-props-new-21:
>(with DISCUSS and COMMENT)
>
>Benjamin Kaduk has entered the following ballot position for
>draft-ietf-alto-unified-props-new-21: Discuss
>
>When responding, please keep the subject line intact and reply to all email
>addresses included in the To and CC lines. (Feel free to cut this introductory
>paragraph, however.)
>
>
>Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/
>for more information about how to handle DISCUSS and COMMENT positions.
>
>
>The document, along with other ballot positions, can be found here:
>https://datatracker.ietf.org/doc/draft-ietf-alto-unified-props-new/
>
>
>
>--
>COMMENT:
>--
>
>I suggest noting somewhere early-ish that the (semi-)formal notation defined
>in Section 8.2 of RFC 7285 will be used.
>
[ [SR] ] Section 1.1 "Terminology" has been renamed "Terminology and notation" 
with the following appended paragraph   
"This document uses the semi-formal notation defined in Section 8.2 of RFC 
7285."

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

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

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

Re: [alto] Murray Kucherawy's No Objection on draft-ietf-alto-unified-props-new-21: (with COMMENT)

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

Thanks Murray,
Best regards,
Sabine

From: Murray S. Kucherawy 
Sent: Monday, February 28, 2022 10:57 PM
To: Randriamasy, Sabine (Nokia - FR/Paris-Saclay) 

Cc: The IESG ; draft-ietf-alto-unified-props-...@ietf.org; 
alto-cha...@ietf.org; alto@ietf.org; Vijay Gurbani 
Subject: Re: Murray Kucherawy's No Objection on 
draft-ietf-alto-unified-props-new-21: (with COMMENT)

Thanks!  Looks good to me.

On Mon, Feb 28, 2022 at 12:07 PM Randriamasy, Sabine (Nokia - FR/Paris-Saclay) 
mailto:sabine.randriam...@nokia-bell-labs.com>>
 wrote:
Hello Murray,

The V24 is up now, for your review
Thanks,
Sabine



The IETF datatracker status page for this draft is:

https://datatracker.ietf.org/doc/draft-ietf-alto-unified-props-new/



There is also an htmlized version available at:

https://datatracker.ietf.org/doc/html/draft-ietf-alto-unified-props-new-24



A diff from the previous version is available at:

https://www.ietf.org/rfcdiff?url2=draft-ietf-alto-unified-props-new-24



From: Murray S. Kucherawy mailto:superu...@gmail.com>>
Sent: Monday, February 28, 2022 4:09 PM
To: Randriamasy, Sabine (Nokia - FR/Paris-Saclay) 
mailto:sabine.randriam...@nokia-bell-labs.com>>
Cc: The IESG mailto:i...@ietf.org>>; 
draft-ietf-alto-unified-props-...@ietf.org<mailto:draft-ietf-alto-unified-props-...@ietf.org>;
 alto-cha...@ietf.org<mailto:alto-cha...@ietf.org>; 
alto@ietf.org<mailto:alto@ietf.org>; Vijay Gurbani 
mailto:vijay.gurb...@gmail.com>>
Subject: Re: Murray Kucherawy's No Objection on 
draft-ietf-alto-unified-props-new-21: (with COMMENT)

Thanks, those all sound like improvements to me.  If you let me know when -24 
is up, I can review it once more.

On Mon, Feb 28, 2022 at 6:38 AM Randriamasy, Sabine (Nokia - FR/Paris-Saclay) 
mailto:sabine.randriam...@nokia-bell-labs.com>>
 wrote:
Hello Murray,
Thank you very much for your review and guidance.
I apologize as I realized I have not integrated all of the related updates in 
the v23 that has been posted.
To avoid confusion for the other reviewers, please find inline our related 
proposed updates.
A v24 integrating these updates is ready to be posted.
We refer to V24 for comments that are reflected in the V24 to be posted.
Please let us know whether they meet your expectations.
Thanks,
Sabine and co-authors

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-alto-unified-props-new/
A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-alto-unified-props-new-23

>-Original Message-
>From: Murray Kucherawy via Datatracker 
>mailto:nore...@ietf.org>>
>Sent: Sunday, December 5, 2021 8:21 AM
>To: The IESG mailto:i...@ietf.org>>
>Cc: 
>draft-ietf-alto-unified-props-...@ietf.org<mailto:draft-ietf-alto-unified-props-...@ietf.org>;
> alto-cha...@ietf.org<mailto:alto-cha...@ietf.org>;
>alto@ietf.org<mailto:alto@ietf.org>; Vijay Gurbani 
>mailto:vijay.gurb...@gmail.com>>
>Subject: Murray Kucherawy's No Objection on draft-ietf-alto-unified-props-
>new-21: (with COMMENT)
>
>Murray Kucherawy has entered the following ballot position for
>draft-ietf-alto-unified-props-new-21: 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/blog/handling-iesg-ballot-positions/
>for more information about how to handle DISCUSS and COMMENT positions.
>
>
>The document, along with other ballot positions, can be found here:
>https://datatracker.ietf.org/doc/draft-ietf-alto-unified-props-new/
>
>
>
>--
>COMMENT:
>--
>
>I support Francesca's DISCUSS.
>
[ [SR] ] This issue has been solved in version 22 and you may refer to 
Francesca's feedback

>The shepherd writeup says:
>
>  The chair has received IPR declarations from Richard Yang, Sabine
>Randriamasy,
>  Jensen Zhang, Wendy Roome, and Kai Gao.  During the discussion of this I-D
>  in the working group, no IPR issues has been raised to the best of my
>  knowledge.
>
>Just to be clear, I presume what the chair actually received was affirmations 
>of
>compliance with BCP 78 and 79 from those people, and not declarations of the
>existence of IPR.
>
[ [SR] ] Indeed, the chairs have received in November 2020, from the authors a 
message saying "To the best of my knowledge, all IPR related to the Unified 
Properties document has been disclosed.". I am not aware of any existence of 
IPR related to this draft.  Maybe Med and Qin can confirm.

>The "Interoperability considerations&

Re: [alto] Murray Kucherawy's No Objection on draft-ietf-alto-unified-props-new-21: (with COMMENT)

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

Hello Murray,

The V24 is up now, for your review
Thanks,
Sabine



The IETF datatracker status page for this draft is:

https://datatracker.ietf.org/doc/draft-ietf-alto-unified-props-new/



There is also an htmlized version available at:

https://datatracker.ietf.org/doc/html/draft-ietf-alto-unified-props-new-24



A diff from the previous version is available at:

https://www.ietf.org/rfcdiff?url2=draft-ietf-alto-unified-props-new-24



From: Murray S. Kucherawy 
Sent: Monday, February 28, 2022 4:09 PM
To: Randriamasy, Sabine (Nokia - FR/Paris-Saclay) 

Cc: The IESG ; draft-ietf-alto-unified-props-...@ietf.org; 
alto-cha...@ietf.org; alto@ietf.org; Vijay Gurbani 
Subject: Re: Murray Kucherawy's No Objection on 
draft-ietf-alto-unified-props-new-21: (with COMMENT)

Thanks, those all sound like improvements to me.  If you let me know when -24 
is up, I can review it once more.

On Mon, Feb 28, 2022 at 6:38 AM Randriamasy, Sabine (Nokia - FR/Paris-Saclay) 
mailto:sabine.randriam...@nokia-bell-labs.com>>
 wrote:
Hello Murray,
Thank you very much for your review and guidance.
I apologize as I realized I have not integrated all of the related updates in 
the v23 that has been posted.
To avoid confusion for the other reviewers, please find inline our related 
proposed updates.
A v24 integrating these updates is ready to be posted.
We refer to V24 for comments that are reflected in the V24 to be posted.
Please let us know whether they meet your expectations.
Thanks,
Sabine and co-authors

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-alto-unified-props-new/
A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-alto-unified-props-new-23

>-Original Message-
>From: Murray Kucherawy via Datatracker 
>mailto:nore...@ietf.org>>
>Sent: Sunday, December 5, 2021 8:21 AM
>To: The IESG mailto:i...@ietf.org>>
>Cc: 
>draft-ietf-alto-unified-props-...@ietf.org<mailto:draft-ietf-alto-unified-props-...@ietf.org>;
> alto-cha...@ietf.org<mailto:alto-cha...@ietf.org>;
>alto@ietf.org<mailto:alto@ietf.org>; Vijay Gurbani 
>mailto:vijay.gurb...@gmail.com>>
>Subject: Murray Kucherawy's No Objection on draft-ietf-alto-unified-props-
>new-21: (with COMMENT)
>
>Murray Kucherawy has entered the following ballot position for
>draft-ietf-alto-unified-props-new-21: 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/blog/handling-iesg-ballot-positions/
>for more information about how to handle DISCUSS and COMMENT positions.
>
>
>The document, along with other ballot positions, can be found here:
>https://datatracker.ietf.org/doc/draft-ietf-alto-unified-props-new/
>
>
>
>--
>COMMENT:
>--
>
>I support Francesca's DISCUSS.
>
[ [SR] ] This issue has been solved in version 22 and you may refer to 
Francesca's feedback

>The shepherd writeup says:
>
>  The chair has received IPR declarations from Richard Yang, Sabine
>Randriamasy,
>  Jensen Zhang, Wendy Roome, and Kai Gao.  During the discussion of this I-D
>  in the working group, no IPR issues has been raised to the best of my
>  knowledge.
>
>Just to be clear, I presume what the chair actually received was affirmations 
>of
>compliance with BCP 78 and 79 from those people, and not declarations of the
>existence of IPR.
>
[ [SR] ] Indeed, the chairs have received in November 2020, from the authors a 
message saying "To the best of my knowledge, all IPR related to the Unified 
Properties document has been disclosed.". I am not aware of any existence of 
IPR related to this draft.  Maybe Med and Qin can confirm.

>The "Interoperability considerations" part of Section 12.1 doesn't seem to be a
>complete answer to the corresponding guidance in Section 6.2 of RFC 6838.
>
[ [SR] ] In V23, the content for this part has been set to "n/a" in sections 
12.1 and 12.2. Please note that Section 12.1 of V21 is now split in 2 sections 
(i) 12.1.  application/alto-propmap+json Media Type and (ii) 12.2.  
alto-propmapparams+json Media Type

>I'm bothered by the dangling SHOULD in Section 12.2.2.  If you're going to
>include that, I suggest including some guidance about when it would be
>legitimate to omit that information from a registration and still expect it to 
>go
>through.
>
[ [SR] ] V24 - (now Section 12.3.2 in v23-24) Agreed. Thanks for noticing this. 
In V24, to be consistent with Section 5.1.1, the SHOULD has bee

Re: [alto] I-D Action: draft-ietf-alto-unified-props-new-24.txt

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

Hello,

This version includes a few remaining updates, mostly editorial, upon the 
review of Murray Kurcherawy, that have been forgotten in V23.
A diff from the previous version V23 is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-alto-unified-props-new-24

The diffs between V22 and V23, upon the other IESG review comments can be seen 
at
https://www.ietf.org/rfcdiff?url2=draft-ietf-alto-unified-props-new-23.txt

With all our apologies.
Sabine

>-Original Message-
>From: alto  On Behalf Of internet-dra...@ietf.org
>Sent: Monday, February 28, 2022 8:59 PM
>To: i-d-annou...@ietf.org
>Cc: alto@ietf.org
>Subject: [alto] I-D Action: draft-ietf-alto-unified-props-new-24.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   : An ALTO Extension: Entity Property Maps
>Authors : Wendy Roome
>  Sabine Randriamasy
>  Y. Richard Yang
>  Jingxuan Jensen Zhang
>  Kai Gao
>   Filename: draft-ietf-alto-unified-props-new-24.txt
>   Pages   : 63
>   Date: 2022-02-28
>
>Abstract:
>   This document specifies an extension to the base Application-Layer
>   Traffic Optimization (ALTO) protocol that generalizes the concept of
>   "endpoint properties", which were so far tied to IP addresses, to
>   entities defined by a wide set of objects.  Further, these properties
>   are presented as maps, similar to the network and cost maps in the
>   base ALTO protocol.  While supporting the endpoints and related
>   endpoint property service defined in RFC7285, the ALTO protocol is
>   extended in two major directions.  First, from endpoints restricted
>   to IP addresses to entities covering a wider and extensible set of
>   objects; second, from properties on specific endpoints to entire
>   entity property maps.  These extensions introduce additional features
>   allowing entities and property values to be specific to a given
>   information resource.  This is made possible by a generic and
>   flexible design of entity and property types.
>
>
>The IETF datatracker status page for this draft is:
>https://datatracker.ietf.org/doc/draft-ietf-alto-unified-props-new/
>
>There is also an htmlized version available at:
>https://datatracker.ietf.org/doc/html/draft-ietf-alto-unified-props-new-24
>
>A diff from the previous version is available at:
>https://www.ietf.org/rfcdiff?url2=draft-ietf-alto-unified-props-new-24
>
>
>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

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

Re: [alto] Roman Danyliw's No Objection on draft-ietf-alto-unified-props-new-21: (with COMMENT)

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

Hello Roman,

Thanks a lot for your review and guidance. Please our proposed updates inline.
We hope they meet your expectations. 
Best regards,
Sabine

>-Original Message-
>From: Roman Danyliw via Datatracker 
>Sent: Wednesday, December 1, 2021 4:45 AM
>To: The IESG 
>Cc: draft-ietf-alto-unified-props-...@ietf.org; alto-cha...@ietf.org;
>alto@ietf.org; Vijay Gurbani ;
>vijay.gurb...@gmail.com
>Subject: Roman Danyliw's No Objection on draft-ietf-alto-unified-props-new-
>21: (with COMMENT)
>
>Roman Danyliw has entered the following ballot position for
>draft-ietf-alto-unified-props-new-21: 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/blog/handling-iesg-ballot-positions/
>for more information about how to handle DISCUSS and COMMENT positions.
>
>
>The document, along with other ballot positions, can be found here:
>https://datatracker.ietf.org/doc/draft-ietf-alto-unified-props-new/
>
>
>
>--
>COMMENT:
>--
>
>Thank you to Paul Wouters for the SECDIR review.
>
>** Section 3.1.  This section provides a list of examples of entities, but 
>doesn’t
>cite a few of them.  For example: -- as = should be 
>[I-D.ietf-alto-cdni-request-
>routing-alto] -- country = should be [I-D.ietf-alto-cdni-request-routing-alto] 
>--
>network flow = ? -- routing element = ?
>
[ [SR] ] We now refer to [I-D.ietf-alto-cdni-request-routing-alto]  for AS and 
COUNTRYCODE domains. 
After the list we propose to add the following text
NEW
Some of the example entities listed above are already documented as ALTO 
entities. The other examples are provided for illustration as potential 
entities.

>** Section 3.2.1
>   An entity domain type
>   MUST be registered at the IANA, as specified in section
>   Section 12.2.2 and similarly to an ALTO address type.
>
>Per the text in Section 12.2.2, it doesn’t appear that a binding to an ALTO
>address type is required.  For example neither pid or priv have an “ALTO
>address type”.
>
[ [SR] ] Indeed, no binding to ALTO address type is mandatory for an ALTO 
entity domain type. 
As the text "and similarly to an ALTO address type" seems to introduce 
confusion and is not really useful at this stage, we have dropped it.

>** Section 4.6
>   Besides, it is also necessary to inform a Client about which
>   associations of specific resources and entity domain types are
>   allowed, because it is not possible to prevent a Server from exposing
>   inappropriate associations.  An informed Client will just ignore
>   inappropriate associations exposed by a Server and avoid error-prone
>   transactions with the Server.
>
>-- Editorial, s/Besides, it is also/It is also/
>
[ [SR] ] as per other review comments, we rephrased the paragraph as follows
OLD
   Besides, it is also necessary to inform a Client about which
   associations of specific resources and entity domain types are
   allowed, because it is not possible to prevent a Server from exposing
   inappropriate associations.  ... 
NEW
   Besides, it is not possible to prevent a Server from mistakenly
   exposing inappropriate associations of information resources and
   entity domain types.  To prevent failures due to invalid queries, it
   is necessary to inform the Client about which associations are
   allowed.  ...

>-- What does it mean that it’s “necessary to inform a Client about which
>associations”?  I was under the impression that this section was documenting
>the IRD capability behavior which is triggered by the client.  If so, the 
>client “is
>asking” in this interaction model rather than being “informed”.
>
[ [SR] ] This section means to help the Client to retrieve entities on which to 
query properties and also to prevent query failures, by detecting beforehand 
when an association exposed in the IRD is not valid and will therefore not 
yield any value. See also the response below.  

>-- What is meant by “it is not possible to prevent a Server from exposing
>inappropriate associations”?  Is it envisioned that the Server might respond
>with an associations which isn’t self-consistent with another part of the
>property map?
>
[ [SR] ] It is envisioned that the Server might my mistake expose an invalid 
association and that cannot be prevented. Please see our abovementioned update 
on section 4.6

>** Section 4.6
>For example, the association "costmap3.pid" is not allowed for the
>   following reason: although a cost map exposes PID identifiers, it
>   does not define the set of addresses included in this PID.
>
>I don’t follow what this example is trying to demonstrate – in that, how is it
>related to the what’s supported in the IRD capability.  From the explanation, 
>it
>appears that a costmap and a pid can never be 

Re: [alto] Murray Kucherawy's No Objection on draft-ietf-alto-unified-props-new-21: (with COMMENT)

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

Hello Murray,
Thank you very much for your review and guidance.
I apologize as I realized I have not integrated all of the related updates in 
the v23 that has been posted. 
To avoid confusion for the other reviewers, please find inline our related 
proposed updates.
A v24 integrating these updates is ready to be posted. 
We refer to V24 for comments that are reflected in the V24 to be posted.
Please let us know whether they meet your expectations.  
Thanks,
Sabine and co-authors

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-alto-unified-props-new/
A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-alto-unified-props-new-23

>-Original Message-
>From: Murray Kucherawy via Datatracker 
>Sent: Sunday, December 5, 2021 8:21 AM
>To: The IESG 
>Cc: draft-ietf-alto-unified-props-...@ietf.org; alto-cha...@ietf.org;
>alto@ietf.org; Vijay Gurbani 
>Subject: Murray Kucherawy's No Objection on draft-ietf-alto-unified-props-
>new-21: (with COMMENT)
>
>Murray Kucherawy has entered the following ballot position for
>draft-ietf-alto-unified-props-new-21: 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/blog/handling-iesg-ballot-positions/
>for more information about how to handle DISCUSS and COMMENT positions.
>
>
>The document, along with other ballot positions, can be found here:
>https://datatracker.ietf.org/doc/draft-ietf-alto-unified-props-new/
>
>
>
>--
>COMMENT:
>--
>
>I support Francesca's DISCUSS.
>
[ [SR] ] This issue has been solved in version 22 and you may refer to 
Francesca's feedback

>The shepherd writeup says:
>
>  The chair has received IPR declarations from Richard Yang, Sabine
>Randriamasy,
>  Jensen Zhang, Wendy Roome, and Kai Gao.  During the discussion of this I-D
>  in the working group, no IPR issues has been raised to the best of my
>  knowledge.
>
>Just to be clear, I presume what the chair actually received was affirmations 
>of
>compliance with BCP 78 and 79 from those people, and not declarations of the
>existence of IPR.
>
[ [SR] ] Indeed, the chairs have received in November 2020, from the authors a 
message saying "To the best of my knowledge, all IPR related to the Unified 
Properties document has been disclosed.". I am not aware of any existence of 
IPR related to this draft.  Maybe Med and Qin can confirm.

>The "Interoperability considerations" part of Section 12.1 doesn't seem to be a
>complete answer to the corresponding guidance in Section 6.2 of RFC 6838.
>
[ [SR] ] In V23, the content for this part has been set to "n/a" in sections 
12.1 and 12.2. Please note that Section 12.1 of V21 is now split in 2 sections 
(i) 12.1.  application/alto-propmap+json Media Type and (ii) 12.2.  
alto-propmapparams+json Media Type

>I'm bothered by the dangling SHOULD in Section 12.2.2.  If you're going to
>include that, I suggest including some guidance about when it would be
>legitimate to omit that information from a registration and still expect it to 
>go
>through.
>
[ [SR] ] V24 - (now Section 12.3.2 in v23-24) Agreed. Thanks for noticing this. 
In V24, to be consistent with Section 5.1.1, the SHOULD has been replaced with 
MUST.

>The second-last paragraph in Section 12.3 appears to be broken.
>
[ [SR] ] in V24, the "It" has been removed, thanks

>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.
>
[ [SR] ] the "priv" entry has been removed from Table 2 and Table 3 in v23
>[I-D.gao-alto-fcs] has expired.  What's the plan here?  It's an informative
>reference.
>
[ [SR] ] in V23 the reference has been removed

>I had the same thought as Ben did about the use of "GET-mode" and "POST-
>mode".
>
[ [SR] ] in v23, we updated item 3  of parag 5 as follows 
OLD
The former is a GET-mode resource that
  returns the property values for all entities in one or more entity
  domains, and is analogous to a network map or a cost map in
  Section 11.2 of [RFC7285].  The latter is a POST-mode resource
  that returns... 
NEW
The former a resource that is requested using the HTTP GET method,
  returns the property values for all entities in one or more entity
  domains, and is analogous to a network map or a cost map in
  Section 11.2 of [RFC7285].  The latter is a resource 
  that is requested using the HTTP POST method, returns...

>It's a pity that the referenced documents didn't use ABNF, because it seems
>like Sections 5.1.1 and 5.

Re: [alto] Francesca Palombini's Discuss on draft-ietf-alto-unified-props-new-21: (with DISCUSS and COMMENT)

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

there is a mapping of ALTO entity domain types
   "ipv4" and "ipv6", to ALTO address types "ipv4" and "ipv6".
   Properties defined on "ipv4" and "ipv6" endpoints should be re-usable
   on "ipv4" and "ipv6" entities.  Forbidding the usage of ":" in a non-
   private entity property type identifier would not allow to use
   properties previously defined on "ipv4" and "ipv6" endpoints because
   their identifiers would be invalid.


From: Francesca Palombini 
Sent: Tuesday, January 25, 2022 3:01 PM
To: Randriamasy, Sabine (Nokia - FR/Paris-Saclay) 
; The IESG 
Cc: alto-cha...@ietf.org; draft-ietf-alto-unified-props-...@ietf.org; 
alto@ietf.org; Vijay Gurbani 
Subject: Re: Francesca Palombini's Discuss on 
draft-ietf-alto-unified-props-new-21: (with DISCUSS and COMMENT)

Hi Sabine,

Thanks for addressing my review. I have cleared my DISCUSS (and kept the one 
COMMENT while waiting for the update), I believe the IANA section looks good 
now, and thanks for the clarifications, they did help me.

Francesca

From: iesg mailto:iesg-boun...@ietf.org>> on behalf of 
Randriamasy, Sabine (Nokia - FR/Paris-Saclay) 
mailto:sabine.randriam...@nokia-bell-labs.com>>
Date: Tuesday, 25 January 2022 at 14:50
To: Francesca Palombini 
mailto:francesca.palomb...@ericsson.com>>, 
The IESG mailto:i...@ietf.org>>
Cc: alto-cha...@ietf.org<mailto:alto-cha...@ietf.org> 
mailto:alto-cha...@ietf.org>>, 
draft-ietf-alto-unified-props-...@ietf.org<mailto:draft-ietf-alto-unified-props-...@ietf.org>
 
mailto:draft-ietf-alto-unified-props-...@ietf.org>>,
 alto@ietf.org<mailto:alto@ietf.org> mailto:alto@ietf.org>>, 
Vijay Gurbani mailto:vijay.gurb...@gmail.com>>
Subject: RE: Francesca Palombini's Discuss on 
draft-ietf-alto-unified-props-new-21: (with DISCUSS and COMMENT)
Dear Francesca and Alexeï,

We have posted a revision that addresses the DISCUSS points raised in 
Francesca's review. In particular, regarding the IANA registration, we would 
like to have the feedback of Alexeï.
It is available here.
We also addressed the COMMENTS of Francesca's review, except the one on the 
"priv:" prefix for entity domain types and property types. This COMMETN will be 
addressed in the next revision, where we plan to add a seperate section for 
private use entity domain types and property types.
Please see inline for our proposed updates.

We look forward to having your feedback,
best regards,
Sabine

>-Original Message-
>From: Francesca Palombini via Datatracker 
>mailto:nore...@ietf.org>>
>Sent: Wednesday, December 1, 2021 7:36 PM
>To: The IESG mailto:i...@ietf.org>>
>Cc: 
>draft-ietf-alto-unified-props-...@ietf.org<mailto:draft-ietf-alto-unified-props-...@ietf.org>;
> alto-cha...@ietf.org<mailto:alto-cha...@ietf.org>;
>alto@ietf.org<mailto:alto@ietf.org>; Vijay Gurbani 
>mailto:vijay.gurb...@gmail.com>>;
>vijay.gurb...@gmail.com<mailto:vijay.gurb...@gmail.com>
>Subject: Francesca Palombini's Discuss on draft-ietf-alto-unified-props-new-
>21: (with DISCUSS and COMMENT)
>
>Francesca Palombini has entered the following ballot position for
>draft-ietf-alto-unified-props-new-21: Discuss
>
>
>
>--
>DISCUSS:
>--
>
>Thank you for the work on this document.
>
>Many thanks to Spencer Dawkins for his thoughtful review:
>https://mailarchive.ietf.org/arch/msg/art/BcZimefF1WXXgcmg0qjc3P__EGg/ ,
>and thanks to the authors for addressing it.
>
>I have two blocking comments, and some non blocking comments (to which I
>would still appreciate answers) below.
>
>Francesca
>
>1. -
>
>Media type registration
>
>FP: I haven't seen the media type being reviewed by the media-type mailing
>list, as requested by RFC 6838. Before progressing the document, I would
>really appreciate the authors to post the registrations to the media-type
>mailing list for review.
>
[ [SR] ] We have updated the IANA sections 12.1 and 12.2  accordingly, under 
the guidance that Alexeï provided for CDNI and this draft.

>2. -
>
>Sections 4.6.1, 12.2.2 and 12.3
>
>FP: The use of the term "unique" when referred to media types and entity
>domains (or properties) is confusing - it makes it sound as if the authors mean
>that each different entity domain (or property) is to be associated with a
>different unique media type, which doesn't seem to be the intent. As this is
>related to the media type registration, I believe this should be clarified and
>possibly checked with the media type experts (so it would be good to copy
>paste 

Re: [alto] I-D Action: draft-ietf-alto-unified-props-new-23.txt

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

Hello,

This revision addresses the review comments of Erick, Francesca, Roman and 
Benjamin. 
Great thanks to all for these thorough reviews and suggestions.
We will formally respond to each reviewer e-mail inline on the list, but to 
gain time, will first send the updates that were made as an attachment.
Best regards,
Sabine and co-authors

>-Original Message-
>From: alto  On Behalf Of internet-dra...@ietf.org
>Sent: Saturday, February 26, 2022 3:27 AM
>To: i-d-annou...@ietf.org
>Cc: alto@ietf.org
>Subject: [alto] I-D Action: draft-ietf-alto-unified-props-new-23.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   : An ALTO Extension: Entity Property Maps
>Authors : Wendy Roome
>  Sabine Randriamasy
>  Y. Richard Yang
>  Jingxuan Jensen Zhang
>  Kai Gao
>   Filename: draft-ietf-alto-unified-props-new-23.txt
>   Pages   : 63
>   Date: 2022-02-25
>
>Abstract:
>   This document specifies an extension to the base Application-Layer
>   Traffic Optimization (ALTO) protocol that generalizes the concept of
>   "endpoint properties", which were so far tied to IP addresses, to
>   entities defined by a wide set of objects.  Further, these properties
>   are presented as maps, similar to the network and cost maps in the
>   base ALTO protocol.  While supporting the endpoints and related
>   endpoint property service defined in RFC7285, the ALTO protocol is
>   extended in two major directions.  First, from endpoints restricted
>   to IP addresses to entities covering a wider and extensible set of
>   objects; second, from properties on specific endpoints to entire
>   entity property maps.  These extensions introduce additional features
>   allowing entities and property values to be specific to a given
>   information resource.  This is made possible by a generic and
>   flexible design of entity and property types.
>
>
>The IETF datatracker status page for this draft is:
>https://datatracker.ietf.org/doc/draft-ietf-alto-unified-props-new/
>
>There is also an htmlized version available at:
>https://datatracker.ietf.org/doc/html/draft-ietf-alto-unified-props-new-23
>
>A diff from the previous version is available at:
>https://www.ietf.org/rfcdiff?url2=draft-ietf-alto-unified-props-new-23
>
>
>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

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

Re: [alto] Erik Kline's No Objection on draft-ietf-alto-unified-props-new-21: (with COMMENT)

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

Hello Erick,

Thank you very much for your review and apologies for coming back to you so 
late.
Please fine inline, answers and proposed updates upon your comments.
We look forward to having your feedback on our proposals.
Best regards,
Sabine and co-authors

>-Original Message-
>From: Erik Kline via Datatracker 
>Sent: Tuesday, November 30, 2021 1:56 AM
>To: The IESG 
>Cc: draft-ietf-alto-unified-props-...@ietf.org; alto-cha...@ietf.org;
>alto@ietf.org; Vijay Gurbani ;
>vijay.gurb...@gmail.com
>Subject: Erik Kline's No Objection on draft-ietf-alto-unified-props-new-21:
>(with COMMENT)
>
>Erik Kline has entered the following ballot position for
>draft-ietf-alto-unified-props-new-21: 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/blog/handling-iesg-ballot-positions/
>for more information about how to handle DISCUSS and COMMENT positions.
>
>
>The document, along with other ballot positions, can be found here:
>https://datatracker.ietf.org/doc/draft-ietf-alto-unified-props-new/
>
>
>
>--
>COMMENT:
>--
>
>[S4.2, nit]
>
>* s/relatively to/relative to/, I think
[ [SR] ] thanks, we have corrected all the occurences
>
>[S4.3, nit]
>
>* s/be be/be/
[ [SR] ] thanks, we have corrected
>
>[S4.4.2, comment]
>
>* I think the last sentence of the paragraph might be trying to say
>  "may or may not inherit the property P...", because the inheritance
>  rules for the property lowercase-must be defined?  Also: lowercase must?
[ [SR] ] Would the proposed update clarify the text?
==>
OLD 
For instance, if a property P is defined only for the entity set
   identified by address block "ipv4:192.0.1.0/24", the entity set
   identified by "ipv4:192.0.1.0/30" and thus included in the former
   set, may inherit the property P value from set "ipv4:192.0.1.0/24".

NEW
For instance, suppose a property P is defined only for the entity set
   defined by address block "ipv4:192.0.1.0/24".  We know that entity
   set "ipv4:192.0.1.0/30" is included in "ipv4:192.0.1.0/24".
   Therefore, the entities of "ipv4:192.0.1.0/30" may inherit the value
   of property P from set "ipv4:192.0.1.0/24", if an inheritance rule 
from "ipv4" CIDR blocks to included "ipv4" CIDR blocks, is specified.
>
>[S6.1.2.2, comment]
>
>* I gather there is no value to allowing link-local scope identifiers to
>  appear here.  The current text does not support such a thing, but perhaps
>  consider whether or not to explicitly note that "%25", "%eth0" are
>  invalid.  Maybe it doesn't need an explicit mention, though.
[ [SR] ] We propose to leave text as it is and not mention those invalid 
identifiers.
>
>[S6.1.3, question]
>
>* Can this "undef" behavior be used to explicitly undefine an inherited
>  property?
[ [SR] ] yes. This is reflected by item 1. Would the following be clearer?
OLD
"If that entity would inherit a value for that property, then the
  ALTO server MUST return a "null" value for that property.  In this
  case, the ALTO client MUST recognize a "null" value as "no value"
  and "do not apply the inheritance rules for this property."
NEW
"If entity X would inherit a value for property P, and if the ALTO server 
decides to 
say that "X has no value for P", then the 
  ALTO server MUST return a "null" value for that property on X.  In this
  case, the ALTO client MUST recognize a "null" value as "no value"
  and interpret it as "do not apply the inheritance rules for this property 
on X."
>
>  For example, can "v4" be replaced with some "null" indicator in Figure 1
>  such that "ipv4:192.0.2.0/32" in Figure 2 becomes "(not defined)"?
[ [SR] ] As per item 1, if "v4" is replaced by "null", then ipv4:192.0.2.0/32 
gets the value "null" as well.
>
>  If there is no such mechanism, should there be?
[ [SR] ] we believe such a mechanism, that decides to *not* apply inheritance 
rules of a property P on a particular entity X that would otherwise inherit the 
value of P is covered by item 1.
>
>

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

Re: [alto] [media-types] Application/alto-* Media Types Registration Request for second document draft-ietf-alto-unified-props-new

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

Hi Alexey,
Thank you for the confirmation,
Best regards,
Sabine

From: Alexey Melnikov 
Sent: Wednesday, February 2, 2022 12:35 PM
To: Randriamasy, Sabine (Nokia - FR/Paris-Saclay) 
; Qin Wu 
; media-ty...@ietf.org; Francesca 
Palombini 
Cc: draft-ietf-alto-unified-props-new@ietf.org; alto@ietf.org
Subject: Re: [media-types] Application/alto-* Media Types Registration Request 
for second document draft-ietf-alto-unified-props-new


Hi Sabine,
On 25/01/2022 13:55, Randriamasy, Sabine (Nokia - FR/Paris-Saclay) wrote:
Hello Alexey,
We have posted a revision v22 that addresses the DISCUSS points raised in 
Francesca's review. In particular, regarding the IANA registration, we would 
like to have your feedback.
It is available at 
https://datatracker.ietf.org/doc/draft-ietf-alto-unified-props-new/

We have updated the IANA sections 12.1 and 12.2  accordingly, under the 
guidance you provided for CDNI and this draft.

Just to confirm: the IANA registration related changes in v22 look good to me.

Best Regards,

Alexey

We look forward to having your feedback,
best regards,
Sabine and co-authors,


From: Alexey Melnikov 
<mailto:alexey.melni...@isode.com>
Sent: Tuesday, December 14, 2021 9:24 PM
To: Qin Wu 
<mailto:bill.wu=40huawei@dmarc.ietf.org>;
 media-ty...@ietf.org<mailto:media-ty...@ietf.org>
Cc: 
draft-ietf-alto-unified-props-new@ietf.org<mailto:draft-ietf-alto-unified-props-new@ietf.org>;
 alto@ietf.org<mailto:alto@ietf.org>; Francesca Palombini 
<mailto:francesca.palomb...@ericsson.com>
Subject: Re: [media-types] Application/alto-* Media Types Registration Request 
for second document draft-ietf-alto-unified-props-new

Hi Qin,

The comments I’ve sent on the other registration apply to this one as well.

Best Regards,

Alexey
On 03/12/2021 11:33, Qin Wu wrote:
Hello,
Here is the registration request of application/alto-* Media Types defined in 
section 12.1 of draft-ietf-alto-unified-props-new:
https://datatracker.ietf.org/doc/draft-ietf-alto-unified-props-new/
https://www.ietf.org/archive/id/draft-ietf-alto-unified-props-new-21.txt

I’ve included the details below.

Note that this document has already entered into IESG review phase. Francesca 
Palombini kindly reminds us and the authors of this draft to
send the media type registrations to the media-type mailing list for review 
before the document moves forward. Thanks Francesca.

-Qin (on behalf of chairs)
12.1.  application/alto-* Media Types

   This document updates the IANA Media Types Registry by registering
   two additional ALTO media types, listed in Table 1.

 +=+=+===+
 | Type| Subtype | Specification |
 +=+=+===+
 | application | alto-propmap+json   | Section 7.1   |
 +-+-+---+
 | application | alto-propmapparams+json | Section 8.3   |
 +-+-+---+

   Table 1: Additional ALTO Media Types.

   Type name:
  application

   Subtype name:
  This document registers multiple subtypes, as listed in Table 1.

   Required parameters:
  n/a

   Optional parameters:
  n/a

   Encoding considerations:
  Encoding considerations are identical to those specified for the
  "application/json" media type.  See [RFC8259].

   Security considerations:
  Security considerations related to the generation and consumption
  of ALTO Protocol messages are discussed in Section 15 of
  [RFC7285].

   Interoperability considerations:
  This document specifies formats of conforming messages and the
  interpretation thereof.

   Published specification:
  This document is the specification for these media types; see
  Table 1 for the section documenting each media type.

   Applications that use this media type:
  ALTO servers and ALTO clients either stand alone or are embedded
  within other applications.

   Additional information:
  Magic number(s):  n/a

  File extension(s):  This document uses the mime type to refer to
 protocol messages and thus does not require a file extension.

  Macintosh file type code(s):  n/a

   Person & email address to contact for further information:
  See Authors' Addresses section.

   Intended usage:
  COMMON

   Restrictions on usage:
  n/a

   Author:
  See Authors' Addresses section.

   Change controller:
  Internet Engineering Task Force (mailto:i...@ietf.org).





___

media-types mailing list

media-ty...@ietf.org<mailto:media-ty...@ietf.org>

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

Re: [alto] Benjamin Kaduk's No Objection on draft-ietf-alto-unified-props-new-22: (with COMMENT)

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

HI Benjamin,

Thanks for your further feedback on this version 22.
Please see responses inline.
Best regards,
Sabine & co-authors

>-Original Message-
>From: Benjamin Kaduk via Datatracker 
>Sent: Friday, January 28, 2022 5:25 AM
>To: The IESG 
>Cc: draft-ietf-alto-unified-props-...@ietf.org; alto-cha...@ietf.org;
>alto@ietf.org; Vijay Gurbani ;
>vijay.gurb...@gmail.com
>Subject: Benjamin Kaduk's No Objection on draft-ietf-alto-unified-props-new-
>22: (with COMMENT)
>
>Benjamin Kaduk has entered the following ballot position for
>draft-ietf-alto-unified-props-new-22: 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/blog/handling-iesg-ballot-positions/
>for more information about how to handle DISCUSS and COMMENT positions.
>
>
>The document, along with other ballot positions, can be found here:
>https://datatracker.ietf.org/doc/draft-ietf-alto-unified-props-new/
>
>
>
>--
>COMMENT:
>--
>
>Thanks for the updates in the -22 to resolve my previous Discuss!
>
>I have a couple new comments on the -22, and I will include below that my
>ballot comments from the -21 (unchanged, so some of them, most notably for
>section 10.x, will no longer apply).
>
>=== new comments on the -22 ===
>
>Section 4.6.1
>
>   A defining information resource for an entity domain D is the
>   information resource where entities of D are defined.  That is, all
>   [...]
>   allocated by the IANA.  This is useful for entity domain types that
>   are by essence domain-specific, such as the "pid" domain type.  It is
>
>Thanks for adding all the examples and clarification here (most of which I
>elided)!  With all that new text, I'd suggest adding a couple words around 
>"This
>is useful" to bring us back to the core concept of defining information
>resource, perhaps as "The defining information resource is useful".
>
[ [SR] ] Thanks, we will update accordingly

>Section 8.6
>
>   The filtered property map response MUST include all the inherited
>   property values for the requested entities and all the entities which
>   are able to inherit property values from the requested entities.  To
>   achieve this goal, the ALTO server MAY follow two rules:
>
>In light of the other edits and discussion, I think this "MAY" might be fine in
>lowercase.
>
[ [SR] ] upon discussion, we will prefer to maintain the normative language 
here as it take precedence over the ones used in the two bullets. Also, that 
language is consistent with the ones used in:
" For the sake of response compactness, the ALTO server SHOULD obey the
   following rule: "

>=== old comments on the -21, unchanged ===
>
>I suggest noting somewhere early-ish that the (semi-)formal notation defined
>in Section 8.2 of RFC 7285 will be used.
>
>Section 1
>
>   properties.  Furthermore, recent ALTO use cases show that properties
>   of entities such as network flows [RFC7011] and routing elements
>   [RFC7921] are also useful.  Such cases are documented in
>   [I-D.gao-alto-fcs].  The current EPS however is restricted to
>
>This is probably more relevant as a comment on draft-gao-alto-fcs than this
>document, but putting the ALTO server in a position to know about individual
>flows seems like a big privacy risk, especially in the face of pervasive
>monitoring (per RFC 7258).  It's not really clear that this is actually a good 
>idea
>to do, and thus whether we want to mention it here.
>
>Section 3.2.2
>
>There seems to be an unfortunate risk of conflation of parsing as ((entity
>domain) name) vs (entity (domain name)), with domain name being the
>widely-used term (see, e.g., RFC 8499).  Could we find some alternate
>terminology that doesn't suffer from this potential confusion?
>
>Section 4.4
>
>   For some domain types, entities can be grouped in a set and be
>   defined by the identifier of this set.  This is the case for domain
>
>>From a mathematical/set-theoretic perspective, this statement is
>trivially true for all domain types; that's just how sets work.  I think what 
>we
>want to say here is that they can be efficiently grouped by utilizing an
>underlying structure for the entities in the given domain type.  That might
>become, for example, "For some domain types, there is an underlying
>structure that allows entities to efficiently be grouped into a set and be
>defined by the identifier of this set".
>
>Section 4.6
>
>   Besides, it is also necessary to inform a Client about which
>   associations of specific resources and entity domain types are
>   allowed, because it is not possible to prevent a Server from exposing
>   inappropriate associations.  [...]
>
>This reasoning is a bit hard for me to follow.  It's not possible to prevent a
>server from ex

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

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

Hi Benjamin,

Thanks a lot, no worries. Please find my responses inline.
Best regards,
Sabine

>-Original Message-
>From: Benjamin Kaduk 
>Sent: Friday, January 28, 2022 5:23 AM
>To: Randriamasy, Sabine (Nokia - FR/Paris-Saclay)
>
>Cc: The IESG ; draft-ietf-alto-unified-props-...@ietf.org;
>alto-cha...@ietf.org; alto@ietf.org; Vijay Gurbani 
>Subject: Re: Benjamin Kaduk's Discuss on draft-ietf-alto-unified-props-new-
>21: (with DISCUSS and COMMENT) - DISCUSS + COMMENTS on section
>
>Hi Sabine, all,
>
>Thanks for posting the -22, and my apologies for not having responded earlier
>to the thread -- there were a lot of things going on for me.
>I'm happy to say that the changes have addressed my discuss points, and I will
>go update my ballot position shortly.
>
>A few remaining notes inline...
>
>On Tue, Jan 25, 2022 at 01:34:06PM +, Randriamasy, Sabine (Nokia -
>FR/Paris-Saclay) wrote:
>> Hello Benjamin,
>>
>> We have posted a revision that addresses the DISCUSS points raised in your
>review, together with the related COMMENTS on section 10.
>> Please see inline the e-mail below for the proposed updates.
>> The other comments will be addressed in a next revision.
>> Again thank you for your thorough review and guidance.
>> Best regards,
>> Sabine and co-authors
>>
>>
>> >-Original Message-
>> >From: Randriamasy, Sabine (Nokia - FR/Paris-Saclay)
>> >
>> >Sent: Tuesday, December 21, 2021 3:23 PM
>> >To: Benjamin Kaduk ; The IESG 
>> >Cc: draft-ietf-alto-unified-props-...@ietf.org; alto-cha...@ietf.org;
>> >alto@ietf.org; Vijay Gurbani 
>> >Subject: RE: Benjamin Kaduk's Discuss on draft-ietf-alto-unified-props-
>new-21:
>> >(with DISCUSS and COMMENT) - DISCUSS + COMMENTS on section
>> >
>> >Hello Benjamin,
>> >
>> >Thank you very much for your thorough review and guidance.
>> >The present e-mail addresses your DISCUSS points and COMMENTS on
>> >section 10, as they relate to a DISCUSS point.
>> >Please see the responses inline.
>> >The other COMMENTS and NITS will be addressed in a separate e-mail.
>> >
>> >Best regards,
>> >Sabine, Jensen, Kai, Richard
>> >
>> >>-Original Message-
>> >>From: Benjamin Kaduk via Datatracker 
>> >>Sent: Thursday, December 2, 2021 12:00 AM
>> >>To: The IESG 
>> >>Cc: draft-ietf-alto-unified-props-...@ietf.org;
>> >>alto-cha...@ietf.org; alto@ietf.org; Vijay Gurbani
>> >>; vijay.gurb...@gmail.com
>> >>Subject: Benjamin Kaduk's Discuss on draft-ietf-alto-unified-props-new-
>21:
>> >>(with DISCUSS and COMMENT)
>> >>
>> >>Benjamin Kaduk has entered the following ballot position for
>> >>draft-ietf-alto-unified-props-new-21: Discuss
>> >>
>> >>When responding, please keep the subject line intact and reply to
>> >>all email addresses included in the To and CC lines. (Feel free to
>> >>cut this introductory paragraph, however.)
>> >>
>> >>
>> >>Please refer to
>> >>https://www.ietf.org/blog/handling-iesg-ballot-positions/
>> >>for more information about how to handle DISCUSS and COMMENT
>> >positions.
>> >>
>> >>
>> >>The document, along with other ballot positions, can be found here:
>> >>https://datatracker.ietf.org/doc/draft-ietf-alto-unified-props-new/
>> >>
>> >>
>> >>
>> >>
>> >>--
>> >>DISCUSS:
>> >>
>> >>--
>> >>
>> >>(1) Section 8.6 seems to have some conflicting requirements.  The
>> >>filtered property map response "MUST include all the inherited
>> >>property values for the requested entities and all the entities
>> >>which are able to inherit property values from the requested
>> >>entities."  We then go on to say that to do this, the server MAY
>> >>follow three rules, that themselves include SHOULD-level guidance,
>> >>but don't say how the MUST is achieved if the SHOULDs or MAY are
>> >>ignored.  I was expecting to see a construction of the form "SHOULD do X,
>but if not, MUST do Y".
>> >>
>> >[ [SR] ]
>> >Indeed the requirements need to set clear rules. We propose to update
>> >the text as follows:
>>

Re: [alto] Francesca Palombini's Discuss on draft-ietf-alto-unified-props-new-21: (with DISCUSS and COMMENT)

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

Hi Francesca,
Thanks a lot for your feedback. We will proceed with the next revision.
Best regards,
Sabine & co-authors

From: Francesca Palombini 
Sent: Tuesday, January 25, 2022 3:01 PM
To: Randriamasy, Sabine (Nokia - FR/Paris-Saclay) 
; The IESG 
Cc: alto-cha...@ietf.org; draft-ietf-alto-unified-props-...@ietf.org; 
alto@ietf.org; Vijay Gurbani 
Subject: Re: Francesca Palombini's Discuss on 
draft-ietf-alto-unified-props-new-21: (with DISCUSS and COMMENT)

Hi Sabine,

Thanks for addressing my review. I have cleared my DISCUSS (and kept the one 
COMMENT while waiting for the update), I believe the IANA section looks good 
now, and thanks for the clarifications, they did help me.

Francesca

From: iesg mailto:iesg-boun...@ietf.org>> on behalf of 
Randriamasy, Sabine (Nokia - FR/Paris-Saclay) 
mailto:sabine.randriam...@nokia-bell-labs.com>>
Date: Tuesday, 25 January 2022 at 14:50
To: Francesca Palombini 
mailto:francesca.palomb...@ericsson.com>>, 
The IESG mailto:i...@ietf.org>>
Cc: alto-cha...@ietf.org<mailto:alto-cha...@ietf.org> 
mailto:alto-cha...@ietf.org>>, 
draft-ietf-alto-unified-props-...@ietf.org<mailto:draft-ietf-alto-unified-props-...@ietf.org>
 
mailto:draft-ietf-alto-unified-props-...@ietf.org>>,
 alto@ietf.org<mailto:alto@ietf.org> mailto:alto@ietf.org>>, 
Vijay Gurbani mailto:vijay.gurb...@gmail.com>>
Subject: RE: Francesca Palombini's Discuss on 
draft-ietf-alto-unified-props-new-21: (with DISCUSS and COMMENT)
Dear Francesca and Alexeï,

We have posted a revision that addresses the DISCUSS points raised in 
Francesca's review. In particular, regarding the IANA registration, we would 
like to have the feedback of Alexeï.
It is available here.
We also addressed the COMMENTS of Francesca's review, except the one on the 
"priv:" prefix for entity domain types and property types. This COMMETN will be 
addressed in the next revision, where we plan to add a seperate section for 
private use entity domain types and property types.
Please see inline for our proposed updates.

We look forward to having your feedback,
best regards,
Sabine

>-Original Message-
>From: Francesca Palombini via Datatracker 
>mailto:nore...@ietf.org>>
>Sent: Wednesday, December 1, 2021 7:36 PM
>To: The IESG mailto:i...@ietf.org>>
>Cc: 
>draft-ietf-alto-unified-props-...@ietf.org<mailto:draft-ietf-alto-unified-props-...@ietf.org>;
> alto-cha...@ietf.org<mailto:alto-cha...@ietf.org>;
>alto@ietf.org<mailto:alto@ietf.org>; Vijay Gurbani 
>mailto:vijay.gurb...@gmail.com>>;
>vijay.gurb...@gmail.com<mailto:vijay.gurb...@gmail.com>
>Subject: Francesca Palombini's Discuss on draft-ietf-alto-unified-props-new-
>21: (with DISCUSS and COMMENT)
>
>Francesca Palombini has entered the following ballot position for
>draft-ietf-alto-unified-props-new-21: Discuss
>
>
>
>--
>DISCUSS:
>--
>
>Thank you for the work on this document.
>
>Many thanks to Spencer Dawkins for his thoughtful review:
>https://mailarchive.ietf.org/arch/msg/art/BcZimefF1WXXgcmg0qjc3P__EGg/ ,
>and thanks to the authors for addressing it.
>
>I have two blocking comments, and some non blocking comments (to which I
>would still appreciate answers) below.
>
>Francesca
>
>1. -
>
>Media type registration
>
>FP: I haven't seen the media type being reviewed by the media-type mailing
>list, as requested by RFC 6838. Before progressing the document, I would
>really appreciate the authors to post the registrations to the media-type
>mailing list for review.
>
[ [SR] ] We have updated the IANA sections 12.1 and 12.2  accordingly, under 
the guidance that Alexeï provided for CDNI and this draft.

>2. -
>
>Sections 4.6.1, 12.2.2 and 12.3
>
>FP: The use of the term "unique" when referred to media types and entity
>domains (or properties) is confusing - it makes it sound as if the authors mean
>that each different entity domain (or property) is to be associated with a
>different unique media type, which doesn't seem to be the intent. As this is
>related to the media type registration, I believe this should be clarified and
>possibly checked with the media type experts (so it would be good to copy
>paste the relevant text in the email to the media-type mailing list).
>
[ [SR] ] the text has been hopefully clarified as follows:

--- section 4.6.1: parag 3, item 5.
OLD
its media type is unique and equal to the one that is specified
  for the defining information resource of an entity domain type
NEW
its media type is equal to the one that is specified
  for the defining information resource of the en

Re: [alto] [media-types] Application/alto-* Media Types Registration Request for second document draft-ietf-alto-unified-props-new

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

Hello Alexey,
We have posted a revision v22 that addresses the DISCUSS points raised in 
Francesca's review. In particular, regarding the IANA registration, we would 
like to have your feedback.
It is available at 
https://datatracker.ietf.org/doc/draft-ietf-alto-unified-props-new/

We have updated the IANA sections 12.1 and 12.2  accordingly, under the 
guidance you provided for CDNI and this draft.

We look forward to having your feedback,
best regards,
Sabine and co-authors,


From: Alexey Melnikov 
Sent: Tuesday, December 14, 2021 9:24 PM
To: Qin Wu ; media-ty...@ietf.org
Cc: draft-ietf-alto-unified-props-new@ietf.org; alto@ietf.org; Francesca 
Palombini 
Subject: Re: [media-types] Application/alto-* Media Types Registration Request 
for second document draft-ietf-alto-unified-props-new

Hi Qin,

The comments I’ve sent on the other registration apply to this one as well.

Best Regards,

Alexey
On 03/12/2021 11:33, Qin Wu wrote:
Hello,
Here is the registration request of application/alto-* Media Types defined in 
section 12.1 of draft-ietf-alto-unified-props-new:
https://datatracker.ietf.org/doc/draft-ietf-alto-unified-props-new/
https://www.ietf.org/archive/id/draft-ietf-alto-unified-props-new-21.txt

I’ve included the details below.

Note that this document has already entered into IESG review phase. Francesca 
Palombini kindly reminds us and the authors of this draft to
send the media type registrations to the media-type mailing list for review 
before the document moves forward. Thanks Francesca.

-Qin (on behalf of chairs)
12.1.  application/alto-* Media Types

   This document updates the IANA Media Types Registry by registering
   two additional ALTO media types, listed in Table 1.

 +=+=+===+
 | Type| Subtype | Specification |
 +=+=+===+
 | application | alto-propmap+json   | Section 7.1   |
 +-+-+---+
 | application | alto-propmapparams+json | Section 8.3   |
 +-+-+---+

   Table 1: Additional ALTO Media Types.

   Type name:
  application

   Subtype name:
  This document registers multiple subtypes, as listed in Table 1.

   Required parameters:
  n/a

   Optional parameters:
  n/a

   Encoding considerations:
  Encoding considerations are identical to those specified for the
  "application/json" media type.  See [RFC8259].

   Security considerations:
  Security considerations related to the generation and consumption
  of ALTO Protocol messages are discussed in Section 15 of
  [RFC7285].

   Interoperability considerations:
  This document specifies formats of conforming messages and the
  interpretation thereof.

   Published specification:
  This document is the specification for these media types; see
  Table 1 for the section documenting each media type.

   Applications that use this media type:
  ALTO servers and ALTO clients either stand alone or are embedded
  within other applications.

   Additional information:
  Magic number(s):  n/a

  File extension(s):  This document uses the mime type to refer to
 protocol messages and thus does not require a file extension.

  Macintosh file type code(s):  n/a

   Person & email address to contact for further information:
  See Authors' Addresses section.

   Intended usage:
  COMMON

   Restrictions on usage:
  n/a

   Author:
  See Authors' Addresses section.

   Change controller:
  Internet Engineering Task Force (mailto:i...@ietf.org).




___

media-types mailing list

media-ty...@ietf.org

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

Re: [alto] Francesca Palombini's Discuss on draft-ietf-alto-unified-props-new-21: (with DISCUSS and COMMENT)

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

Dear Francesca and Alexeï,

We have posted a revision that addresses the DISCUSS points raised in 
Francesca's review. In particular, regarding the IANA registration, we would 
like to have the feedback of Alexeï.
It is available here. 
We also addressed the COMMENTS of Francesca's review, except the one on the 
"priv:" prefix for entity domain types and property types. This COMMETN will be 
addressed in the next revision, where we plan to add a seperate section for 
private use entity domain types and property types. 
Please see inline for our proposed updates.

We look forward to having your feedback,
best regards,
Sabine

>-Original Message-
>From: Francesca Palombini via Datatracker 
>Sent: Wednesday, December 1, 2021 7:36 PM
>To: The IESG 
>Cc: draft-ietf-alto-unified-props-...@ietf.org; alto-cha...@ietf.org;
>alto@ietf.org; Vijay Gurbani ;
>vijay.gurb...@gmail.com
>Subject: Francesca Palombini's Discuss on draft-ietf-alto-unified-props-new-
>21: (with DISCUSS and COMMENT)
>
>Francesca Palombini has entered the following ballot position for
>draft-ietf-alto-unified-props-new-21: Discuss
>
>
>
>--
>DISCUSS:
>--
>
>Thank you for the work on this document.
>
>Many thanks to Spencer Dawkins for his thoughtful review:
>https://mailarchive.ietf.org/arch/msg/art/BcZimefF1WXXgcmg0qjc3P__EGg/ ,
>and thanks to the authors for addressing it.
>
>I have two blocking comments, and some non blocking comments (to which I
>would still appreciate answers) below.
>
>Francesca
>
>1. -
>
>Media type registration
>
>FP: I haven't seen the media type being reviewed by the media-type mailing
>list, as requested by RFC 6838. Before progressing the document, I would
>really appreciate the authors to post the registrations to the media-type
>mailing list for review.
>
[ [SR] ] We have updated the IANA sections 12.1 and 12.2  accordingly, under 
the guidance that Alexeï provided for CDNI and this draft.

>2. -
>
>Sections 4.6.1, 12.2.2 and 12.3
>
>FP: The use of the term "unique" when referred to media types and entity
>domains (or properties) is confusing - it makes it sound as if the authors mean
>that each different entity domain (or property) is to be associated with a
>different unique media type, which doesn't seem to be the intent. As this is
>related to the media type registration, I believe this should be clarified and
>possibly checked with the media type experts (so it would be good to copy
>paste the relevant text in the email to the media-type mailing list).
>
[ [SR] ] the text has been hopefully clarified as follows:

--- section 4.6.1: parag 3, item 5.
OLD
its media type is unique and equal to the one that is specified
  for the defining information resource of an entity domain type
NEW
its media type is equal to the one that is specified
  for the defining information resource of the entity domain type of D
NEW

--- section 12.3 .2 (was 12.2.2  in version 21), parag 3, item 5
OLD
... 
The authorized
media type of a defining information resources MUST be unique and
MUST be specified in the document defining the entity domain type.
When an entity domain type allows combinations with defining
resources, this MUST be indicated here, together with the
authorized media type for the defining resources
 
NEW
... 
For each entity domain type, the potential defining information resources 
have one common media type. This unique common media type is specific to 
the entity domain type and MUST be specified. 
...

--- Section 12.4, parag 6, item 3
OLD
... 
The media type of the possibly used defining information resource MUST be 
unique and MUST be specified here, as well as in the document that defines the 
property type
...
NEW
... 
For each property type, the potential defining information resources have one 
common media type. This unique common media type is specific to the property 
type and MUST be specified. 
...
>
>--
>COMMENT:
>--
>
>3. -
>
>   identifier.  In this case, inheritance rules must specify how
>   entities in "subsets" inherit property values from their "superset".
>   For instance, if a property P is defined only for the entity set
>   identified by address block "ipv4:192.0.1.0/24", the entity set
>   identified by "ipv4:192.0.1.0/30" and thus included in the former
>   set, may inherit the property P value from set "ipv4:192.0.1.0/24".
>
>FP: Are the sets inverted  in the paragraph above? (should it be
>"ipv4:192.0.1.0/24" inherits from "ipv4:192.0.1.0/30")
>
[ [SR] ] They are not. Is the wording below clearer? 

OLD
 For instance, if a property P is defined only for the entity set
   identified by address block "ipv4:192.0.1.0/24", the entity set
   identified by "ipv4:192.0.1.0/30" and thus included 

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

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

Hello Benjamin,

We have posted a revision that addresses the DISCUSS points raised in your 
review, together with the related COMMENTS on section 10. 
Please see inline the e-mail below for the proposed updates. 
The other comments will be addressed in a next revision. 
Again thank you for your thorough review and guidance. 
Best regards,
Sabine and co-authors


>-Original Message-
>From: Randriamasy, Sabine (Nokia - FR/Paris-Saclay)
>
>Sent: Tuesday, December 21, 2021 3:23 PM
>To: Benjamin Kaduk ; The IESG 
>Cc: draft-ietf-alto-unified-props-...@ietf.org; alto-cha...@ietf.org;
>alto@ietf.org; Vijay Gurbani 
>Subject: RE: Benjamin Kaduk's Discuss on draft-ietf-alto-unified-props-new-21:
>(with DISCUSS and COMMENT) - DISCUSS + COMMENTS on section
>
>Hello Benjamin,
>
>Thank you very much for your thorough review and guidance.
>The present e-mail addresses your DISCUSS points and COMMENTS on section
>10, as they relate to a DISCUSS point.
>Please see the responses inline.
>The other COMMENTS and NITS will be addressed in a separate e-mail.
>
>Best regards,
>Sabine, Jensen, Kai, Richard
>
>>-Original Message-
>>From: Benjamin Kaduk via Datatracker 
>>Sent: Thursday, December 2, 2021 12:00 AM
>>To: The IESG 
>>Cc: draft-ietf-alto-unified-props-...@ietf.org; alto-cha...@ietf.org;
>>alto@ietf.org; Vijay Gurbani ;
>>vijay.gurb...@gmail.com
>>Subject: Benjamin Kaduk's Discuss on draft-ietf-alto-unified-props-new-21:
>>(with DISCUSS and COMMENT)
>>
>>Benjamin Kaduk has entered the following ballot position for
>>draft-ietf-alto-unified-props-new-21: Discuss
>>
>>When responding, please keep the subject line intact and reply to all
>>email addresses included in the To and CC lines. (Feel free to cut this
>>introductory paragraph, however.)
>>
>>
>>Please refer to
>>https://www.ietf.org/blog/handling-iesg-ballot-positions/
>>for more information about how to handle DISCUSS and COMMENT
>positions.
>>
>>
>>The document, along with other ballot positions, can be found here:
>>https://datatracker.ietf.org/doc/draft-ietf-alto-unified-props-new/
>>
>>
>>
>>--
>>DISCUSS:
>>--
>>
>>(1) Section 8.6 seems to have some conflicting requirements.  The
>>filtered property map response "MUST include all the inherited property
>>values for the requested entities and all the entities which are able
>>to inherit property values from the requested entities."  We then go on
>>to say that to do this, the server MAY follow three rules, that
>>themselves include SHOULD-level guidance, but don't say how the MUST is
>>achieved if the SHOULDs or MAY are ignored.  I was expecting to see a
>>construction of the form "SHOULD do X, but if not, MUST do Y".
>>
>[ [SR] ]
>Indeed the requirements need to set clear rules. We propose to update the
>text as follows:
>OLD
>...
>To achieve this goal, the ALTO server MAY follow three rules:
>
>   *  If a property for a requested entity is inherited from another
>  entity not included in the request, the response SHOULD include
>  this property for the requested entity.  For example, A full
>  property map may skip a property P for an entity A (e.g.,
>  ipv4:192.0.2.0/31) if P can be derived using inheritance from
>  another entity B (e.g., ipv4:192.0.2.0/30).  A filtered property
>  map request may include only A but not B.  In such a case, the
>  property P SHOULD be included in the response for A.
>
>   *  If there are entities covered by a requested entity but having
>  different values for the requested properties, the response SHOULD
>  include all those entities and the different property values for
>  them.  For example, considering a request for property P of entity
>  A (e.g., ipv4:192.0.2.0/31), if P has value v1 for
>  A1=ipv4:192.0.2.0/32 and v2 for A2=ipv4:192.0.2.1/32, then, the
>  response SHOULD include A1 and A2.
>
>   *  If an entity identifier in the response is already covered by
>  other entities identifiers in the same response, it SHOULD be
>  removed from the response, for the sake of compactness.  In the
>  previous example, the entity A = ipv4:192.0.2.0/31 SHOULD be
>  removed because A1 and A2 cover all the addresses in A.
>NEW
>...
>To achieve this goal, the ALTO server MUST follow two rules:
>
>   *  If a property for a requested entity is inherited from another
>  entity not included in the request, the re

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

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

Hello Benjamin,

Thank you very much for your thorough review and guidance. 
The present e-mail addresses your DISCUSS points and COMMENTS on section 10, as 
they relate to a DISCUSS point.
Please see the responses inline.
The other COMMENTS and NITS will be addressed in a separate e-mail.

Best regards,
Sabine, Jensen, Kai, Richard

>-Original Message-
>From: Benjamin Kaduk via Datatracker 
>Sent: Thursday, December 2, 2021 12:00 AM
>To: The IESG 
>Cc: draft-ietf-alto-unified-props-...@ietf.org; alto-cha...@ietf.org;
>alto@ietf.org; Vijay Gurbani ;
>vijay.gurb...@gmail.com
>Subject: Benjamin Kaduk's Discuss on draft-ietf-alto-unified-props-new-21:
>(with DISCUSS and COMMENT)
>
>Benjamin Kaduk has entered the following ballot position for
>draft-ietf-alto-unified-props-new-21: Discuss
>
>When responding, please keep the subject line intact and reply to all email
>addresses included in the To and CC lines. (Feel free to cut this introductory
>paragraph, however.)
>
>
>Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/
>for more information about how to handle DISCUSS and COMMENT positions.
>
>
>The document, along with other ballot positions, can be found here:
>https://datatracker.ietf.org/doc/draft-ietf-alto-unified-props-new/
>
>
>
>--
>DISCUSS:
>--
>
>(1) Section 8.6 seems to have some conflicting requirements.  The filtered
>property map response "MUST include all the inherited property values for
>the requested entities and all the entities which are able to inherit property
>values from the requested entities."  We then go on to say that to do this, the
>server MAY follow three rules, that themselves include SHOULD-level
>guidance, but don't say how the MUST is achieved if the SHOULDs or MAY are
>ignored.  I was expecting to see a construction of the form "SHOULD do X, but
>if not, MUST do Y".
>
[ [SR] ] 
Indeed the requirements need to set clear rules. We propose to update the text 
as follows:
OLD 
... 
To achieve this goal, the ALTO server MAY follow three rules:

   *  If a property for a requested entity is inherited from another
  entity not included in the request, the response SHOULD include
  this property for the requested entity.  For example, A full
  property map may skip a property P for an entity A (e.g.,
  ipv4:192.0.2.0/31) if P can be derived using inheritance from
  another entity B (e.g., ipv4:192.0.2.0/30).  A filtered property
  map request may include only A but not B.  In such a case, the
  property P SHOULD be included in the response for A.

   *  If there are entities covered by a requested entity but having
  different values for the requested properties, the response SHOULD
  include all those entities and the different property values for
  them.  For example, considering a request for property P of entity
  A (e.g., ipv4:192.0.2.0/31), if P has value v1 for
  A1=ipv4:192.0.2.0/32 and v2 for A2=ipv4:192.0.2.1/32, then, the
  response SHOULD include A1 and A2.

   *  If an entity identifier in the response is already covered by
  other entities identifiers in the same response, it SHOULD be
  removed from the response, for the sake of compactness.  In the
  previous example, the entity A = ipv4:192.0.2.0/31 SHOULD be
  removed because A1 and A2 cover all the addresses in A.
NEW
... 
To achieve this goal, the ALTO server MUST follow two rules:

   *  If a property for a requested entity is inherited from another
  entity not included in the request, the response MUST include
  this property for the requested entity.  For example, A full
  property map may skip a property P for an entity A (e.g.,
  ipv4:192.0.2.0/31) if P can be derived using inheritance from
  another entity B (e.g., ipv4:192.0.2.0/30).  A filtered property
  map request may include only A but not B.  In such a case, the
  property P MUST be included in the response for A.

   *  If there are entities covered by a requested entity but having
  different values for the requested properties, the response MUST
  include all those entities and the different property values for
  them.  For example, considering a request for property P of entity
  A (e.g., ipv4:192.0.2.0/31), if P has value v1 for
  A1=ipv4:192.0.2.0/32 and v2 for A2=ipv4:192.0.2.1/32, then, the
  response MUST include A1 and A2.

For the sake of response compactness, the ALTO Server SHOULD obey the following 
rule:

   *  If an entity identifier in the response is already covered by
  other entities identifiers in the same response, it SHOULD be
  removed from the response.  In the
  previous example, the entity A = ipv4:192.0.2.0/31 SHOULD be
  removed because A1 and A2 cover all the addresses in A.


>(2) Many of the examples in Sections 10.X d

Re: [alto] New chair!

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

Welcome, bienvenue Med, looking forward to working with you,
Great thanks to Jan for his service as ALTO chair
Best regards,
Sabine

From: alto  On Behalf Of kai...@scu.edu.cn
Sent: Tuesday, December 7, 2021 2:46 PM
To: LUIS MIGUEL CONTRERAS MURILLO 
Cc: IETF ALTO ; Qin Wu 
Subject: Re: [alto] New chair!


Welcome Med! Looking forward to working with you!



Thanks Jan!



Best,

Kai



-Original Messages-
From:"LUIS MIGUEL CONTRERAS MURILLO" 
mailto:luismiguel.contrerasmuri...@telefonica.com>>
Sent Time:2021-12-07 21:31:06 (Tuesday)
To: "Qin Wu" 
mailto:bill.wu=40huawei@dmarc.ietf.org>>,
 "Martin Duke" mailto:martin.h.d...@gmail.com>>, "IETF 
ALTO" mailto:alto@ietf.org>>
Cc:
Subject: Re: [alto] New chair!
Congrats Med!

and thanks Jan for your work along these past years.

Best regards

Luis

De: alto mailto:alto-boun...@ietf.org>> En nombre de Qin 
Wu
Enviado el: martes, 7 de diciembre de 2021 14:25
Para: Martin Duke mailto:martin.h.d...@gmail.com>>; 
IETF ALTO mailto:alto@ietf.org>>
Asunto: Re: [alto] New chair!

Welcome Med! Wonderful to have you.
Thanks all the other volunteers, look forward to continue to work with you as a 
team.
And also express my thanks to Jan, in advance, for his service as ALTO chair.

-Qin
发件人: alto [mailto:alto-boun...@ietf.org] 代表 Martin Duke
发送时间: 2021年12月7日 1:57
收件人: IETF ALTO mailto:alto@ietf.org>>
主题: [alto] New chair!

Hello ALTO,

I'd like to welcome Mohamed Boucadair, of Orange, as the new ALTO chair. This 
frees Jan to step down at his convenience. When he chooses to do so, we'll 
thank him properly.

Mohamed has not been intimately involved with ALTO, but he will bring 
significant IETF experience and an operator's perspective to the role. Thanks 
for serving, Mohamed!

I'd also like to thank the other candidates. We were blessed with several 
volunteers who all would have done a fine job, and it was hard to pick from 
them.

Martin



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 privileged and confidential 
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] IESG evaluation results

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

Hi Martin,

Thanks a lot for this feedback. The authors of unified-props are preparing 
responses with a focus on the DISCUSSES. The intent is to address the DISCUSSES 
in separate dedicated e-mails and come back with later e-mails on the comments.

Sabine

From: alto  On Behalf Of Martin Duke
Sent: Friday, December 3, 2021 7:22 PM
To: IETF ALTO 
Subject: [alto] IESG evaluation results

The IESG ballot did not go particularly well.

Not enough ADs read the drafts to advance any of the documents, which is 
unfortunate and reflects poorly on the IESG. However, there are numerous useful 
and straightforward reviews, DISCUSS and otherwise, that we can immediately 
address.

To the extent that author resources are limited, I suggest you focus on 
resolving issues on unified-props, as this is the prerequisite for others and 
the changes are straightforward. I will nag the ADs to move forward with 
reviews and clearing DISCUSSES, starting with this draft.

There are two DISCUSSes that are worthy of some, well, discussion:

1) I believe that Roman's suggestion that path-vector move to Experimental is 
valid, as to my knowledge there is not a lot of experience with obscuring 
network details. I see no normative references to this draft, so this would not 
create problems down the road.

2) We will have to do something about performance-metrics. In the telechat, we 
agreed that metrics collection is out of scope. However, more precise 
definitions of these metrics are in scope. I would suggest finding RFCs in the 
ippm WG stream that contain useful definitions and using those.

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

Re: [alto] Éric Vyncke's No Objection on draft-ietf-alto-unified-props-new-20: (with COMMENT)

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

Bonjour Éric,
Thanks a lot for your feedback,
Best regards,
Sabine

>-Original Message-
>From: Eric Vyncke (evyncke) 
>Sent: Friday, November 26, 2021 3:11 PM
>To: Randriamasy, Sabine (Nokia - FR/Paris-Saclay)
>; The IESG 
>Cc: draft-ietf-alto-unified-props-...@ietf.org; alto-cha...@ietf.org;
>alto@ietf.org; Vijay Gurbani 
>Subject: Re: Éric Vyncke's No Objection on draft-ietf-alto-unified-props-new-
>20: (with COMMENT)
>
>Bonjour Sabine,
>
>Thank you for revision -21, it addresses all my previous non-blocking
>comments.
>
>Have a nice WE!
>
>Regards
>
>-éric
>
>On 26/11/2021, 14:57, "Randriamasy, Sabine (Nokia - FR/Paris-Saclay)"
> wrote:
>
>Hello Éric,
>
>A new version has been posted to address your comments.
>We hope the updates meet your expectation and will like to have your
>feedback.
>Best regards,
>Sabine and co-authors
>
>The IETF datatracker status page for this draft is:
>https://datatracker.ietf.org/doc/draft-ietf-alto-unified-props-new/
>
>There is also an htmlized version available at:
>https://datatracker.ietf.org/doc/html/draft-ietf-alto-unified-props-new-21
>
>A diff from the previous version is available at:
>    https://www.ietf.org/rfcdiff?url2=draft-ietf-alto-unified-props-new-21
>
>
>>-Original Message-
>>From: Randriamasy, Sabine (Nokia - FR/Paris-Saclay)
>>
>>Sent: Thursday, November 25, 2021 2:29 PM
>>To: Éric Vyncke ; The IESG 
>>Cc: draft-ietf-alto-unified-props-...@ietf.org; alto-cha...@ietf.org;
>>alto@ietf.org; Vijay Gurbani 
>>Subject: RE: Éric Vyncke's No Objection on draft-ietf-alto-unified-props-
>new-
>>20: (with COMMENT)
>>
>>Hello Éric,
>>
>>Thanks a lot for your review and comments.
>>Please find our answers inline.
>>A version 21 is under edition and will integrate the changes upon your
>>feedback.
>>
>>Best regards,
>>Sabine and co-authors
>>
>>>-Original Message-
>>>From: Éric Vyncke via Datatracker 
>>>Sent: Monday, November 22, 2021 11:01 AM
>>>To: The IESG 
>>>Cc: draft-ietf-alto-unified-props-...@ietf.org; alto-cha...@ietf.org;
>>>alto@ietf.org; Vijay Gurbani ;
>>>vijay.gurb...@gmail.com
>>>Subject: Éric Vyncke's No Objection on draft-ietf-alto-unified-props-new-
>20:
>>>(with COMMENT)
>>>
>>>Éric Vyncke has entered the following ballot position for
>>>draft-ietf-alto-unified-props-new-20: 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/blog/handling-iesg-ballot-positions/
>>>for more information about how to handle DISCUSS and COMMENT
>>positions.
>>>
>>>
>>>The document, along with other ballot positions, can be found here:
>>>https://datatracker.ietf.org/doc/draft-ietf-alto-unified-props-new/
>>>
>>>
>>>
>>>--
>>>COMMENT:
>>>--
>>>
>>>Thank you for the work put into this document.
>>>
>>>Please find below some non-blocking COMMENT points (but replies
>would
>>>be appreciated even if only for my own education), and some nits.
>>>
>>>Special thanks to Vijay Gurbani for the shepherd's extended write-up
>>>about the WG consensus (even if not using the usual template).
>>>
>>>While the document supports clearly the two address families (IPv4 and
>>>IPv6), I can only regret that the vast majority of examples are for IPv4.
>>>
>>>I hope that this helps to improve the document,
>>>
>>>Regards,
>>>
>>>-éric
>>>
>>>== COMMENTS ==
>>>
>>>While the documents is very detailed, I would have preferred to have a
>>>generic introduction of the concepts at the beginning. It also seems to
>>>me that part of the text is repetitive.
>>
>>[ [SR] ] The Introduction indeed, lists features such as entity, en

Re: [alto] Éric Vyncke's No Objection on draft-ietf-alto-unified-props-new-20: (with COMMENT)

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

Hello Éric,

A new version has been posted to address your comments. 
We hope the updates meet your expectation and will like to have your feedback.
Best regards,
Sabine and co-authors

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-alto-unified-props-new/

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-alto-unified-props-new-21

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-alto-unified-props-new-21


>-Original Message-
>From: Randriamasy, Sabine (Nokia - FR/Paris-Saclay)
>
>Sent: Thursday, November 25, 2021 2:29 PM
>To: Éric Vyncke ; The IESG 
>Cc: draft-ietf-alto-unified-props-...@ietf.org; alto-cha...@ietf.org;
>alto@ietf.org; Vijay Gurbani 
>Subject: RE: Éric Vyncke's No Objection on draft-ietf-alto-unified-props-new-
>20: (with COMMENT)
>
>Hello Éric,
>
>Thanks a lot for your review and comments.
>Please find our answers inline.
>A version 21 is under edition and will integrate the changes upon your
>feedback.
>
>Best regards,
>Sabine and co-authors
>
>>-Original Message-
>>From: Éric Vyncke via Datatracker 
>>Sent: Monday, November 22, 2021 11:01 AM
>>To: The IESG 
>>Cc: draft-ietf-alto-unified-props-...@ietf.org; alto-cha...@ietf.org;
>>alto@ietf.org; Vijay Gurbani ;
>>vijay.gurb...@gmail.com
>>Subject: Éric Vyncke's No Objection on draft-ietf-alto-unified-props-new-20:
>>(with COMMENT)
>>
>>Éric Vyncke has entered the following ballot position for
>>draft-ietf-alto-unified-props-new-20: 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/blog/handling-iesg-ballot-positions/
>>for more information about how to handle DISCUSS and COMMENT
>positions.
>>
>>
>>The document, along with other ballot positions, can be found here:
>>https://datatracker.ietf.org/doc/draft-ietf-alto-unified-props-new/
>>
>>
>>
>>--
>>COMMENT:
>>--
>>
>>Thank you for the work put into this document.
>>
>>Please find below some non-blocking COMMENT points (but replies would
>>be appreciated even if only for my own education), and some nits.
>>
>>Special thanks to Vijay Gurbani for the shepherd's extended write-up
>>about the WG consensus (even if not using the usual template).
>>
>>While the document supports clearly the two address families (IPv4 and
>>IPv6), I can only regret that the vast majority of examples are for IPv4.
>>
>>I hope that this helps to improve the document,
>>
>>Regards,
>>
>>-éric
>>
>>== COMMENTS ==
>>
>>While the documents is very detailed, I would have preferred to have a
>>generic introduction of the concepts at the beginning. It also seems to
>>me that part of the text is repetitive.
>
>[ [SR] ] The Introduction indeed, lists features such as entity, entity domain
>and its type, resource specific entity domain, Filtered/Property map, that are
>introduced at high level w.r.t. how they address the limitations of the current
>protocol.
>
>The generic  introduction of the concepts is provided right after the
>Introduction, in the 4 pages Section 3. "Basic Features of the Entity Property
>Map Extension". Section 3, in its introduction, also references a table that
>summarizes all the features introduced by this extension, in the paragraph
>below:
>"The Entity Property Maps extension described in this document introduces a
>number of features that are summarized in Appendix A, where Table 4 lists
>the features and references the sections in this document that give a high-
>level and normative description thereof."
>
>Do you think it would be helpful to move this paragraph to Section
>1.Introduction, just before its last paragraph?
>>
>>-- Section 3.1 --
>>I am a little puzzled by the use of "TCP/IP network flow" as it mixes up 
>>layers.
>>Also, the "associated 5-tuple" is redundant because TCP has always 6 as
>>protocol so it is not really a 5-tuple as one is constant.
>>
>[ [SR] ] We propose to update item 5 as follows:
>OLD
>a TCP network flow, that is identified by a TCP 5-Tuple specifying its source
>and destination addresses and port numbers and the utilized protocol, NEW a

Re: [alto] Éric Vyncke's No Objection on draft-ietf-alto-unified-props-new-20: (with COMMENT)

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

Hello Éric,

Thanks a lot for your review and comments. 
Please find our answers inline.
A version 21 is under edition and will integrate the changes upon your feedback.

Best regards, 
Sabine and co-authors

>-Original Message-
>From: Éric Vyncke via Datatracker 
>Sent: Monday, November 22, 2021 11:01 AM
>To: The IESG 
>Cc: draft-ietf-alto-unified-props-...@ietf.org; alto-cha...@ietf.org;
>alto@ietf.org; Vijay Gurbani ;
>vijay.gurb...@gmail.com
>Subject: Éric Vyncke's No Objection on draft-ietf-alto-unified-props-new-20:
>(with COMMENT)
>
>Éric Vyncke has entered the following ballot position for
>draft-ietf-alto-unified-props-new-20: 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/blog/handling-iesg-ballot-positions/
>for more information about how to handle DISCUSS and COMMENT positions.
>
>
>The document, along with other ballot positions, can be found here:
>https://datatracker.ietf.org/doc/draft-ietf-alto-unified-props-new/
>
>
>
>--
>COMMENT:
>--
>
>Thank you for the work put into this document.
>
>Please find below some non-blocking COMMENT points (but replies would be
>appreciated even if only for my own education), and some nits.
>
>Special thanks to Vijay Gurbani for the shepherd's extended write-up about
>the WG consensus (even if not using the usual template).
>
>While the document supports clearly the two address families (IPv4 and IPv6),
>I can only regret that the vast majority of examples are for IPv4.
>
>I hope that this helps to improve the document,
>
>Regards,
>
>-éric
>
>== COMMENTS ==
>
>While the documents is very detailed, I would have preferred to have a
>generic introduction of the concepts at the beginning. It also seems to me that
>part of the text is repetitive.

[ [SR] ] The Introduction indeed, lists features such as entity, entity domain 
and its type, resource specific entity domain, Filtered/Property map, that are 
introduced at high level w.r.t. how they address the limitations of the current 
protocol. 

The generic  introduction of the concepts is provided right after the 
Introduction, in the 4 pages Section 3. "Basic Features of the Entity Property 
Map Extension". Section 3, in its introduction, also references a table that 
summarizes all the features introduced by this extension, in the paragraph 
below:
"The Entity Property Maps extension described in this document
introduces a number of features that are summarized in Appendix A,
where Table 4 lists the features and references the sections in this
document that give a high-level and normative description thereof." 

Do you think it would be helpful to move this paragraph to Section 
1.Introduction, just before its last paragraph?
>
>-- Section 3.1 --
>I am a little puzzled by the use of "TCP/IP network flow" as it mixes up 
>layers.
>Also, the "associated 5-tuple" is redundant because TCP has always 6 as
>protocol so it is not really a 5-tuple as one is constant.
>
[ [SR] ] We propose to update item 5 as follows:
OLD
a TCP network flow, that is identified by a TCP 5-Tuple
specifying its source and destination addresses and port numbers
and the utilized protocol,
NEW
a TCP/UDP network flow, that is identified by a TCP/UDP 5-tuple 
specifying its source and destination addresses and port numbers and the IP 
protocol

>-- Section 4.6.1 --
>The use of "ane" is done before its explanation later in section 4.6.2.
>
[ [SR] ] As citing "ane" does not add anything to understand the point, we 
propose to remove it. 
We propose to update sentence in parag 2 as follows:
OLD
...
This is useful for entity domain types that are by essence domain-specific, 
such as "pid" and "ane" domain types.
...
NEW
...
This is useful for entity domain types that are by essence domain-specific, 
such as the "pid" domain type.
...

>-- Section 5.1.3 --
>"net1.ipv6:2001:db8::1/48" is probably not an address block as it is a /128
>address.
[ [SR] ] Thanks for catching this typo. We propose to replace 
"net1.ipv6:2001:db8::1/48" with "net1.ipv6:2001:db8::/48".
>
>-- Section 10.4 (and possibly others) -- Please use RFC 5398 when using ASN in
>examples.
>
[ [SR] ] following section  "4. IANA Considerations" of 
https://www.rfc-editor.org/rfc/pdfrfc/rfc5398.txt.pdf,
we will use either of the 64496 - 64511 and 65536 - 65551 blocks reserved by 
IANA for documentation purposes. 

Example ASN numbers 12345 and 12346 will be replaced with 65543, 65544

>-- Section 10.9 --
>Is the JSON reply valid ?
>
[ [SR] ] Indeed, the property values are not to be exposed with their units, 
thanks a lot for this catch. 
The units will be removed and the reply will look like:
OLD
.
{"storage-capacity" : 4 Gbytes, "cpu" : 500 Cores},
.

Re: [alto] Meeting Info for Nov 23, 2021

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

Hi Kai and all,
We may also want to allow some time to discuss the review of Erick Vyncke on 
Unified properties and Performance metrics.
Best regards,
Sabine

From: alto  On Behalf Of kai...@scu.edu.cn
Sent: Monday, November 22, 2021 4:32 PM
To: alto-weekly-meet...@googlegroups.com; alto@ietf.org
Subject: [alto] Meeting Info for Nov 23, 2021


Dear all,



This is a friendly reminder that we will have the ALTO weekly meeting at 9:00 
am US EST (3:00 pm CET and 10:00 pm Beijing Time) on Tuesday, November 23, 2021.



Agenda:



- Design sessions for new charter items:

  - ALTO new transport

  - ALTO OAM



Bridge:



https://yale.zoom.us/my/yryang



If anyone wants to present or lead the discussion of other topics, please feel 
free to let me know.



Best,

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

[alto] FW: I-D Action: draft-ietf-alto-unified-props-new-20.txt

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

Dear ALTO WG and reviewers,

This new version 20 fixes some typos in version 19, among which many may appear 
as errors. 
In particular, I had an issue with the  markups and many "" 
disappeared. 
I also removed the "" from the EntityDomainName (5.1.2) and EntityPropertyName 
formats (5.2.2)

To see the significant diffs with the previous version, please diff 
https://www.ietf.org/archive/id/draft-ietf-alto-unified-props-new-18.txt
and 
https://www.ietf.org/archive/id/draft-ietf-alto-unified-props-new-20.txt 

If you have already started reviewing version 19, please accept my apologies.
Thanks,
Sabine

-Original Message-
From: alto  On Behalf Of internet-dra...@ietf.org
Sent: Tuesday, October 26, 2021 1:49 AM
To: i-d-annou...@ietf.org
Cc: alto@ietf.org
Subject: [alto] I-D Action: draft-ietf-alto-unified-props-new-20.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 Extension: Entity Property Maps
Authors : Wendy Roome
  Sabine Randriamasy
  Y. Richard Yang
  Jingxuan Jensen Zhang
  Kai Gao
Filename: draft-ietf-alto-unified-props-new-20.txt
Pages   : 61
Date: 2021-10-25

Abstract:
   This document specifies an extension to the base Application-Layer
   Traffic Optimization (ALTO) Protocol that generalizes the concept of
   "endpoint properties", which were so far tied to IP addresses, to
   entities defined by a wide set of objects.  Further, these properties
   are presented as maps, similar to the network and cost maps in the
   base ALTO protocol.  While supporting the endpoints and related
   endpoint property service defined in RFC7285, the protocol is
   extended in two major directions.  First, from endpoints restricted
   to IP addresses to entities covering a wider and extensible set of
   objects; second, from properties on specific endpoints to entire
   entity property maps.  These extensions introduce additional features
   allowing entities and property values to be specific to a given
   information resource.  This is made possible by a generic and
   flexible design of entity and property types.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-alto-unified-props-new/

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-alto-unified-props-new-20

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-alto-unified-props-new-20


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


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

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

Re: [alto] [Last-Call] Artart last call review of draft-ietf-alto-unified-props-new-18

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

Hello Spencer and Mike,

Thanks a lot for your comments and guidance.
Please see inline how your comments have been addressed,
starting with the ones from Mike and continuing with the 2nd feedback from 
Spencer.
We hope the updates meet your expectations and look forward to having your 
feedback,
Best regards,
Sabine and co-authors

From: Mike Bishop 
Sent: Wednesday, September 15, 2021 4:27 AM
To: Spencer Dawkins at IETF ; Jensen Zhang 

Cc: a...@ietf.org; IETF ALTO ; last-c...@ietf.org; 
draft-ietf-alto-unified-props-new@ietf.org
Subject: Re: [Last-Call] Artart last call review of 
draft-ietf-alto-unified-props-new-18

> If the first paraphrase is more correct, the BCP 14 language would be "MAY", 
> but "is allowed to" or "can" are often used.

If I can jump in, I think there is a slight distinction between the two. In my 
experience, a BCP 14 MAY has an implicit MUST to it -- if one party MAY take an 
action, the other parties MUST allow for that possibility and handle it 
gracefully, even if that counterpart isn't always written down.

If it's merely a possibility that exists, with no obligation on other parties, 
then the sentence is a statement of fact and "can" is more appropriate. It's 
also a statement if the ability follows from an explicitly stated MUST on some 
other party.

Here, if one party MAY omit records, the other party MUST NOT assume those 
records will be present.

I don't pretend to know this draft well enough to suggest which it is in this 
case, however.
[ [SR] ] To make sure a Client knows what to to, we have opted for the 
following revision:
OLD
For efficiency, the ALTO server SHOULD omit property values that are inherited
rather than explicitly defined. If a client needs inherited values, the client
SHOULD use the entity domain's inheritance rules to deduce those values.

NEW
The ALTO server MAY omit property values that are inherited rather than
explicitly defined, in order to achieve more compact encoding. As a consequence,
the ALTO Client MUST NOT assume inherited property values will all be present.
If the Client needs inherited values, it MUST use the entity domain's 
inheritance rules to deduce those values.

Sent from Nine


From: Spencer Dawkins at IETF 
mailto:spencerdawkins.i...@gmail.com>>
Sent: Tuesday, September 14, 2021 9:14 PM
To: Jensen Zhang
Cc: a...@ietf.org; IETF ALTO; 
last-c...@ietf.org; 
draft-ietf-alto-unified-props-new@ietf.org
Subject: Re: [Last-Call] Artart last call review of 
draft-ietf-alto-unified-props-new-18

Hi, Jensen,

On Tue, Sep 14, 2021 at 7:11 AM Jensen Zhang 
mailto:jingxuan.n.zh...@gmail.com>> wrote:
Hi Spencer,

Many thanks for your review. Please see my responses inline.

Thanks,
Jensen


On Wed, Sep 8, 2021 at 4:41 AM Spencer Dawkins via Datatracker 
mailto:nore...@ietf.org>> wrote:
Reviewer: Spencer Dawkins
Review result: Ready with Issues

I'm sorry for running late on this review, and please don't be concerned about
the length - it includes a lot of draft text as part of the comments.

Do The Right Thing, of course.

In this text,

   At first, a map of endpoint properties might seem impractical,
   because it could require enumerating the property value for every
   possible endpoint.  However, in practice, it is highly unlikely that
   properties will be defined for every endpoint address.  It is much
   more likely that properties may be defined for only a subset of
   endpoint addresses, and the specification of properties uses an
   aggregation representation to allow enumeration.  This is
   particularly true if blocks of endpoint addresses with a common
   prefix (e.g., a CIDR) have the same value for a property.  Entities
   in other domains may very well allow aggregated representation and
   hence be enumerable as well.

I wonder if it's worth saying anything about the likely effect of doing
something "highly unlikely", or perhaps something a bit more likely, like
defining properties for a sufficiently large subset of endpoints to cause a
problem.

Very good suggestion. How about the following revised text:

NEW:

   [...] However, in practice, the number of endpoint addresses involved by
   an ALTO server can be quite large. To avoid enumerating a large number
   of endpoint addresses inefficiently, the ALTO server usually only defines
   properties for a sufficiently large subset of endpoints and uses an 
aggregation
   representation to reference endpoints to allow efficient enumeration. [...]

This works better for me.
[ [SR] ] done



You might make an editing pass through the document looking for occurrences of
"domain name" that (I think) refer to entity domain names, such as

   *  if an entity is an endpoint with example routable IPv4 address
  "192.0.2.14", its identifier is associated with domain name "ipv4"
  and is "ipv4:192.0.2.14",

Re: [alto] I-D Action: draft-ietf-alto-unified-props-new-19.txt

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

Dear ALTO WG,

The version below addresses the reviews received from our AD Martin Duke, the 
IANA with Sabrina Tanamal, the OPSDIR Scott Bradner, the ARTDIR Spencer Dawkins 
and the SECDIR Paul Wouters. 
Great thanks to all of you for your review, insight and valuable guidance. This 
v19 It has been edited upon your feedback to our proposed updates. We hope all 
the issues have been solved. 
Until the submission deadline, I will:
- Detail to Spencer and Mike Bishop how their comments have been addressed,
- look-up occurrences of "domain name" where "entity" should be inserted,
- wait for your further feedback. 

Thanks,
Sabine

>-Original Message-
>From: alto  On Behalf Of internet-dra...@ietf.org
>Sent: Monday, October 25, 2021 7:03 PM
>To: i-d-annou...@ietf.org
>Cc: alto@ietf.org
>Subject: [alto] I-D Action: draft-ietf-alto-unified-props-new-19.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 Extension: Entity Property Maps
>Authors : Wendy Roome
>  Sabine Randriamasy
>  Y. Richard Yang
>  Jingxuan Jensen Zhang
>  Kai Gao
>   Filename: draft-ietf-alto-unified-props-new-19.txt
>   Pages   : 61
>   Date: 2021-10-25
>
>Abstract:
>   This document specifies an extension to the base Application-Layer
>   Traffic Optimization (ALTO) Protocol that generalizes the concept of
>   "endpoint properties", which were so far tied to IP addresses, to
>   entities defined by a wide set of objects.  Further, these properties
>   are presented as maps, similar to the network and cost maps in the
>   base ALTO protocol.  While supporting the endpoints and related
>   endpoint property service defined in RFC7285, the protocol is
>   extended in two major directions.  First, from endpoints restricted
>   to IP addresses to entities covering a wider and extensible set of
>   objects; second, from properties on specific endpoints to entire
>   entity property maps.  These extensions introduce additional features
>   allowing entities and property values to be specific to a given
>   information resource.  This is made possible by a generic and
>   flexible design of entity and property types.
>
>
>The IETF datatracker status page for this draft is:
>https://datatracker.ietf.org/doc/draft-ietf-alto-unified-props-new/
>
>There is also an htmlized version available at:
>https://datatracker.ietf.org/doc/html/draft-ietf-alto-unified-props-new-19
>
>A diff from the previous version is available at:
>https://www.ietf.org/rfcdiff?url2=draft-ietf-alto-unified-props-new-19
>
>
>Internet-Drafts are also available by anonymous FTP at:
>ftp://ftp.ietf.org/internet-drafts/
>
>
>___
>alto mailing list
>alto@ietf.org
>https://www.ietf.org/mailman/listinfo/alto

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

Re: [alto] Update RFC7285 for unified property new draft

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

Hi Sebastian and Qin,
Thanks for the suggestion and clarifications. I will update the beginning of 
the abstract as follows:

This document specifies an extension to the Application-Layer Traffic 
Optimization (ALTO) Protocol that generalizes the concept of "endpoint 
properties", which were so far tied to IP addresses, to entities defined by a 
wide set of objects. 
Further, these properties are presented as maps, similar to the network and 
cost maps in the base ALTO protocol.  
While supporting the endpoints and related endpoint property service defined in 
RFC7285, the protocol is extended in two major directions. 


Sabine


>-Original Message-
>From: Qin Wu 
>Sent: Wednesday, October 20, 2021 3:36 AM
>To: Sebastian Kiesel ; Randriamasy, Sabine (Nokia -
>FR/Paris-Saclay) 
>Cc: alto-chairs ; draft-ietf-alto-unified-props-
>new@ietf.org; alto@ietf.org
>Subject: RE: [alto] Update RFC7285 for unified property new draft
>
>Hi, Sebastian and Sabine:
>-邮件原件-
>发件人: alto [mailto:alto-boun...@ietf.org] 代表 Sebastian Kiesel
>发送时间: 2021年10月20日 4:07
>收件人: Randriamasy, Sabine (Nokia - FR/Paris-Saclay)
>
>抄送: alto-chairs ; Qin Wu ;
>draft-ietf-alto-unified-props-new@ietf.org; alto@ietf.org
>主题: Re: [alto] Update RFC7285 for unified property new draft
>
>Hi Sabine,
>
>I agree that "specifies an optional extension" may be considered redundant
>and a bit overly explicit.  Once the RFC is published without the "updates" 
>tag,
>a first sentence "This document specifies an extension to the Application-
>Layer Traffic Optimization (ALTO) Protocol, which ..." will be enough that the
>reader can understand the significance of the document and its relation to
>RFC 7285.
>In the meantime, the document shepherd may answer reviewer's questions
>about why we chose not to tag the document with "updates" :)
>
>[Qin Wu] Good suggestion, we will see how to reflect this in the shepherd
>write-up.
>
>please allow me one more comment about the new first sentence:
>
>> This document specifies an [optional] extension to the
>> Application-Layer Traffic Optimization (ALTO) Protocol, which
>> generalizes the concept of "endpoint properties" to entities defined
>> by a wide set of objects, instead of only IP addresses.
>
>is a bit difficult for me to read because of two "switches" between old and
>new: generalize [old] to [new] instead of [old]
>
>maybe:
>
>This document specifies an extension to the Application-Layer Traffic
>Optimization (ALTO) Protocol that generalizes the concept of "endpoint
>properties", which were so far tied to IP addresses, to entities defined by a
>wide set of objects.
>
>[Qin Wu] :Good wording, I think we are in agreement on this issue, thank for
>helping close this issue.
>Thanks
>Sebastian
>
>
>On Tue, Oct 19, 2021 at 05:49:37PM +, Randriamasy, Sabine (Nokia -
>FR/Paris-Saclay) wrote:
>> Hi Qin and Sebastian,
>>
>> Thanks for the discussion. I agree with your conclusions and do not see the
>need to indicate "updates" and definitely not "obsoletes".
>>
>> This extension does not oppose entities against endpoints. Therefore it does
>not intend to replace endpoints with entities but adds entities and other
>related features to the existing ones. Both are useful, as some use cases can
>live with the base protocol.
>>
>> Actually, I suspect the term "limitations" used in the Introduction was
>probably misleading, and the wording should be revised.  The purpose of the
>Introduction is to list a number of cases for which a protocol extension is
>beneficial. For instance, use cases:
>> (i) that involve entities in other domains than "ipv4" and "ipv6", or
>> (ii) that use several or many information resources relatively to
>> which entities are defined, or (iii)  where clients would be better off 
>> fetching
>with a GET, a whole property map, that covers a moderate number of
>aggregated sets of entities instead of querying the properties with POST
>requests enumerating all the individual entities.
>> The purpose of the extensions listed in the Introduction is to support such
>use cases.
>>
>> Other use cases can perfectly live with the base protocol. For backwards
>compatibility, this extension supports RFC7285 services when they are
>sufficient for the Client needs in ALTO information.  The example IRD in
>section 10.3 also indicates a "legacy-endpoint-property" property map.
>>
>> Last, borrowing from Sebastian, I propose the rewording below for the
>abstract. The term "optiona

Re: [alto] [Last-Call] Secdir last call review of draft-ietf-alto-unified-props-new-18

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

Hello Paul, 
Thanks a lot for your feedback. You will see the updates in version 19
Best regards,
Sabine

>-Original Message-
>From: Paul Wouters 
>Sent: Tuesday, October 19, 2021 8:48 PM
>To: Randriamasy, Sabine (Nokia - FR/Paris-Saclay)
>
>Cc: sec...@ietf.org; draft-ietf-alto-unified-props-new@ietf.org;
>alto@ietf.org; last-c...@ietf.org
>Subject: Re: [Last-Call] Secdir last call review of 
>draft-ietf-alto-unified-props-
>new-18
>
>On Tue, 19 Oct 2021, Randriamasy, Sabine (Nokia - FR/Paris-Saclay) wrote:
>
>> Thanks a lot for your review. A new version is under edition to address your
>comments.
>> Please see inline how we plan to address them. Can you let us know
>whether the proposed updates meet your expectations?
>
>That looks good, thanks!
>
>>> appropriate to refer to RFC 7285 for the Security Considerations, as
>>> is done in this document.
>> [ [SR] ]
>> [ [SR] ] Do you mean we should keep the security section of this document
>as it is or should we shorten it?
>
>I meant it is good as is.
>
>>> While extensions to a protocol don't necessitate an Updates: clause,
>>> in this case I think it should because the document addresses
>>> shortcomings in the original protocol. That is, new implementations
>>> are expected to really require implementing this new document as part
>>> of the "core specification". Thus implementers reading 7285 should
>>> really be warned to also read (and
>>> implement) this document.
>>
>> [ [SR] ] we do not oppose entities against endpoints therefore this
>> extension does not intend to replace endpoints by entities. Both are
>> useful, as some use cases can live with the base protocol. A
>> discussion thread has just started on this point and we will like to
>> have your conclusions on the exposed points of view
>
>An RFC update does not mean "do not implement what was in the older one".
>Update really means that one should read (and ideally implement) both
>documents to get the updated picture of what the IETF believes should be
>implemented. If this is just an optional extension, then Update: is not needed.
>But if it modifies the previous document to clarify or extend in a way that is
>core to the protocol, it should probably Update: the previous RFC so
>implementers know there is more to take into account than just that core
>older document.
>
>>> The IANA considerations are quite verbose. Usually, this section only
>>> contains
>
>> [ [SR] ] We have identified some paragraphs and text that are more
>considerations than specifications:
>
>Thanks. I think it will look better. Generally, think of this Section as 
>something
>only the IANA operator will read to actually perform the registry updates and
>that any other reader will skip the section entirely.
>
>Paul

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

Re: [alto] Update RFC7285 for unified property new draft

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

Hi Qin and Sebastian,

Thanks for the discussion. I agree with your conclusions and do not see the 
need to indicate "updates" and definitely not "obsoletes". 

This extension does not oppose entities against endpoints. Therefore it does 
not intend to replace endpoints with entities but adds entities and other 
related features to the existing ones. Both are useful, as some use cases can 
live with the base protocol.

Actually, I suspect the term "limitations" used in the Introduction was 
probably misleading, and the wording should be revised.  The purpose of the 
Introduction is to list a number of cases for which a protocol extension is 
beneficial. For instance, use cases:
(i) that involve entities in other domains than "ipv4" and "ipv6", 
or (ii) that use several or many information resources relatively to which 
entities are defined,
or (iii)  where clients would be better off fetching with a GET, a whole 
property map, that covers a moderate number of aggregated sets of entities 
instead of querying the properties with POST requests enumerating all the 
individual entities.
The purpose of the extensions listed in the Introduction is to support such use 
cases. 

Other use cases can perfectly live with the base protocol. For backwards 
compatibility, this extension supports RFC7285 services when they are 
sufficient for the Client needs in ALTO information.  The example IRD in 
section 10.3 also indicates a "legacy-endpoint-property" property map.  

Last, borrowing from Sebastian, I propose the rewording below for the abstract. 
The term "optional" is made optional since I feel most of the extensions are 
optional as long as the base protocol is still useful for given use cases. 

OLD
   This document extends the base Application-Layer Traffic Optimization
   (ALTO) Protocol by generalizing the concept of "endpoint properties"
   to entities defined by a wide set of objects, instead of only IP
   addresses.  Further, these properties are presented as maps, similar
   to the network and cost maps in the base ALTO protocol.  The protocol
   is extended in two major directions.  

NEW
This document specifies an [optional] extension to the Application-Layer 
Traffic Optimization (ALTO) Protocol, which generalizes the concept of 
"endpoint properties" to entities defined by a wide set of objects, instead of 
only IP addresses. 
Further, these properties are presented as maps, similar to the network and 
cost maps in the base ALTO protocol.  
While supporting the endpoints and related endpoint property service defined in 
RFC7285, the protocol is extended in two major directions.  

Thanks in advance for your feedback,
Sabine


>-Original Message-
>From: Qin Wu 
>Sent: Tuesday, October 19, 2021 3:59 AM
>To: Sebastian Kiesel 
>Cc: alto-chairs ; alto@ietf.org; draft-ietf-alto-unified-
>props-new@ietf.org; mirja.kuehlew...@ericsson.com
>Subject: RE: [alto] Update RFC7285 for unified property new draft
>
>Thanks Sebastian for proposed change, it looks good and I believe it address
>comments raised in the directorate review.
>Authors of unified proper new drafts, please share your view on this. Thanks!
>
>-Qin
>-邮件原件-
>发件人: Sebastian Kiesel [mailto:ietf-a...@skiesel.de]
>发送时间: 2021年10月18日 17:02
>收件人: Qin Wu 
>抄送: alto-chairs ; alto@ietf.org; draft-ietf-alto-unified-
>props-new@ietf.org; mirja.kuehlew...@ericsson.com
>主题: Re: [alto] Update RFC7285 for unified property new draft
>
>Hi Qin, all,
>
>I think one option, as draft-kuehlewind-update-tag is not a BCP yet, would be
>NOT to add "updates: RFC 7285" to draft-ietf-alto-unified-props and instead
>slightly reword the first sentence of the abstract, maybe:
>
>old:
>
>This document extends the base Application-Layer Traffic Optimization
>(ALTO) Protocol by generalizing the concept of "endpoint properties" to
>entities defined by a wide set of objects, instead of only IP addresses.
>
>new:
>
>This document specifies an optional extension to the Application-Layer Traffic
>Optimization (ALTO) Protocol, which generalizes the concept of "endpoint
>properties" to entities defined by a wide set of objects, instead of only IP
>addresses.
>
>
>so it would be even clearer that it is a purely optional extension and that we 
>as
>the ALTO community, when we talk about "the ALTO protocol" in the
>foreseeable future, we still mean RFC 7285 and NOT necessarily always the
>combination of RFC 7285 and the RFC-to-be.
>
>thanks,
>Sebastian
>
>
>On Mon, Oct 18, 2021 at 04:13:01AM +, Qin Wu wrote:
>> Hi, Sebastian:
>> Good to hear your feedback on this issue, see my reply inline below.
>> -邮件原件-
>> 发件人: alto [mailto:alto-boun...@ietf.org] 代表 Sebastian Kiesel
>> 发送时间: 2021年10月17日 20:34
>> 收件人: Qin Wu 
>> 抄送: alto-chairs ; alto@ietf.org;
>> draft-ietf-alto-unified-props-new@ietf.org
>> 主题: Re: [alto] Update RFC7285 for unified property new draft
>>
>> Hi Qin, all,
>>
>> I think "obsoletes" is definitively not adequate in this situation

Re: [alto] Secdir last call review of draft-ietf-alto-unified-props-new-18

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

Hello Paul,

Thanks a lot for your review. A new version is under edition to address your 
comments. 
Please see inline how we plan to address them. Can you let us know whether the 
proposed updates meet your expectations? 
Best regards,
Sabine and co-authors

>-Original Message-
>From: Paul Wouters via Datatracker 
>Sent: Wednesday, September 15, 2021 11:37 PM
>To: sec...@ietf.org
>Cc: alto@ietf.org; draft-ietf-alto-unified-props-new@ietf.org; last-
>c...@ietf.org
>Subject: Secdir last call review of draft-ietf-alto-unified-props-new-18
>
>Reviewer: Paul Wouters
>Review result: Has Nits
>
>I have reviewed this document as part of the security directorate's  ongoing
>effort to review all IETF documents being processed by the  IESG.  These
>comments were written primarily for the benefit of the security area
>directors.
>Document editors and WG chairs should treat these comments just like any
>other last call comments.
>
>The summary of the review is Has Nits
>
>This document extends RFC 7285 (the ALTO protocol) with some new
>registries and values. As such, there is no real change to the protocol, only 
>to
>the possible information conveyed via the ALTO protocol. Therefor it is
>appropriate to refer to RFC 7285 for the Security Considerations, as is done in
>this document.
[ [SR] ] 
[ [SR] ] Do you mean we should keep the security section of this document as it 
is or should we shorten it?
>
>While extensions to a protocol don't necessitate an Updates: clause, in this
>case I think it should because the document addresses shortcomings in the
>original protocol. That is, new implementations are expected to really require
>implementing this new document as part of the "core specification". Thus
>implementers reading 7285 should really be warned to also read (and
>implement) this document.

[ [SR] ] we do not oppose entities against endpoints therefore this extension 
does not intend to replace endpoints by entities. Both are useful, as some use 
cases can live with the base protocol. A discussion thread has just started on 
this point and we will like to have your conclusions on the exposed points of 
view
>
>The IANA considerations are quite verbose. Usually, this section only contains
>the minimal information for an IANA operator to read to implement the
>requested changes. In this case there is lots of text on justifying things that
>are better omitted or written out in another section.
[ [SR] ] 
[ [SR] ] We have identified some paragraphs and text that are more 
considerations than specifications:
-- 12.2.2.  ALTO Entity Domain Type Registration Process
- para 3 item 5 "Media type of defining information resource:" removed 
redundant text. 
- para 3 item 6 "Knowing the media type..." removed

--- 12.3.  ALTO Entity Property Type Registry
- para 4: removed last sentence
- para 4 - item 2 removed last sentence

>
>The new IANA registries do not all seem to allow for private use registrations?
>This means technically any new value cannot be tested unless by violating the
>RFC. At least, that is my reading but I'm a little confused by it.
[ [SR] ] 
[ [SR] ] we agree, all new IANA registries should allow for private 
registrations. 
While this has been done for entoty property types in section 5.2.1, we will  
add private use for Entity Domain Types, and plan to update the document 
accordingly as follows.

-- Section 5.1.1.  Entity Domain Type -  paragraph 4, 
borrowing from RFC 7285.  

OLD
   . Each entity domain type
   MUST be registered with the IANA, following the procedure specified
   in Section 12.2.2 of this document. 

NEW
.  Entity domain type identifiers prefixed with "priv:" are reserved for 
Private Use
[RFC5226] without a need to register with IANA.

All other entity domain types appearing in an HTTP request or
response with an "application/alto-*" media type 
 MUST be registered with the IANA, following the procedure 
specified  in Section 12.2.2 of this document.

 For an endpoint domain type identifier with the "priv:" prefix, an additional
string (e.g., company identifier or random string) MUST follow (i.e.,
"priv:" only is not a valid entity domain type identifier) to reduce potential 
collisions.  
A Private Use entity domain type identifier and its associated internal 
specification MUST apply to all property maps  of an IRD. 
.

-- Section 5.1.2.  Entity Domain Name
The 3rd paragraph will be modified as follows:

OLD
   Each entity domain is identified by a unique entity domain name which
   is a string of the following format:

   EntityDomainName ::= [ [ ResourceID ] '.' ] EntityDomainType

   Where the presence and construction of component:

   "[ [ ResourceID ] '.' ]"

   depends on the category of entity domain.

NEW
   Each entity domain is identified by a unique entity domain name which
   is a string of the following format:

   EntityDomainName ::= [ [ ResourceID ] '.' ] [ "priv:" ] Enti

Re: [alto] I-D Action: draft-ietf-alto-unified-props-new-18.txt

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

Hi Martin,

Thanks for your feedback and further comments.
Please see inline. I will see to prepare the updates for the newt iterations of 
the document.
Best regards,
Sabine

From: Martin Duke 
Sent: Thursday, August 12, 2021 10:33 PM
To: Randriamasy, Sabine (Nokia - FR/Paris-Saclay) 

Cc: IETF ALTO 
Subject: Re: [alto] I-D Action: draft-ietf-alto-unified-props-new-18.txt

Hi Sabine,

Minor comments that aren't blocking last call:

(7) Eliminate the commas around "for the Client"

(8.3) Isn't " The client wants all properties values on all the entities," the 
use case for the (unfiltered) property map?
[ [SR] ] It is indeed, we may mention that in the next versions.  If it adds 
something, we may also say that some Clients may prefer to systematically make 
filtered property map queries.

(8.3) s/Sever/Server

On Thu, Aug 12, 2021 at 8:38 AM Randriamasy, Sabine (Nokia - FR/Paris-Saclay) 
mailto:sabine.randriam...@nokia-bell-labs.com>>
 wrote:
Hello Martin and ALTO WG,

Thanks again Martin for your thorough review and discussions that allowed to 
improve the document and enrich the capabilities of this extension.

This new version addresses the comments in the AD review and is available at
https://datatracker.ietf.org/doc/html/draft-ietf-alto-unified-props-new-18
You may check the diffs here
https://www.ietf.org/rfcdiff?url2=draft-ietf-alto-unified-props-new-18

The main updates:
- remove unused and unclear terms and clarifies text in many places,
- Filtered Property Map (FPM) queries now allow empty lists of entities and 
properties. Empty lists are interpreted as representing the full set of 
entities and properties.
- put tables and text in coherency in IANA sections 12.2 and 12.3. Though due 
to lack of space, only added a column "mapping to ALTO address type" in Table 
2.  Some text on the security issue item referring to relevant sections was 
added in the introduction of section 12.2 and 12.3

The key updates were added in section 8 "Filtered Property Map". (FPM)
They address the question on: how a Client can obtain the list of entityIDs 
that can be used as input to a FPM without having to download a full property 
map. The FPM query input format and response have been updated accordingly.
- In Section 8: a paragraph explains why this is useful for a Client
- In section 8.3 Accept Input Parameters: the format of query object 
ReqFilteredPropertyMap is revised and explained to support this. The property 
member is optional.
- In section 8.6 Filtered Property Map Response:
--- an error case is added when input member "entities" is absent
--- text explains how, when the "property" member is absent in the query, the 
Server returns an empty value for the queried entities.

We hope the updates are meeting the review expectations.
Thanks,
Sabine and authors

>-Original Message-
>From: alto mailto:alto-boun...@ietf.org>> On Behalf Of 
>internet-dra...@ietf.org<mailto:internet-dra...@ietf.org>
>Sent: Thursday, August 12, 2021 4:45 PM
>To: i-d-annou...@ietf.org<mailto:i-d-annou...@ietf.org>
>Cc: alto@ietf.org<mailto:alto@ietf.org>
>Subject: [alto] I-D Action: draft-ietf-alto-unified-props-new-18.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 Extension: Entity Property Maps
>Authors : Wendy Roome
>  Sabine Randriamasy
>  Y. Richard Yang
>  Jingxuan Jensen Zhang
>  Kai Gao
>   Filename: draft-ietf-alto-unified-props-new-18.txt
>   Pages   : 60
>   Date: 2021-08-12
>
>Abstract:
>   This document extends the base Application-Layer Traffic Optimization
>   (ALTO) Protocol by generalizing the concept of "endpoint properties"
>   to entities defined by a wide set of objects, instead of only IP
>   addresses.  Further, these properties are presented as maps, similar
>   to the network and cost maps in the base ALTO protocol.  The protocol
>   is extended in two major directions.  First, from endpoints
>   restricted to IP addresses to entities covering a wider and
>   extensible set of objects; second, from properties on specific
>   endpoints to entire entity property maps.  These extensions introduce
>   additional features allowing entities and property values to be
>   specific to a given information resource.  This is made possible by a
>   generic and flexible design of entity and property types.
>
>
>The IETF datatracker status page for this draft is:
>https://datatracker.ietf.org/doc/draft-ietf-alto-unified-props-new/
>
>There is also an htmlized version

Re: [alto] I-D Action: draft-ietf-alto-unified-props-new-18.txt

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

Hello Martin and ALTO WG,

Thanks again Martin for your thorough review and discussions that allowed to 
improve the document and enrich the capabilities of this extension. 

This new version addresses the comments in the AD review and is available at
https://datatracker.ietf.org/doc/html/draft-ietf-alto-unified-props-new-18
You may check the diffs here
https://www.ietf.org/rfcdiff?url2=draft-ietf-alto-unified-props-new-18

The main updates:
- remove unused and unclear terms and clarifies text in many places,
- Filtered Property Map (FPM) queries now allow empty lists of entities and 
properties. Empty lists are interpreted as representing the full set of 
entities and properties. 
- put tables and text in coherency in IANA sections 12.2 and 12.3. Though due 
to lack of space, only added a column "mapping to ALTO address type" in Table 
2.  Some text on the security issue item referring to relevant sections was 
added in the introduction of section 12.2 and 12.3 

The key updates were added in section 8 "Filtered Property Map". (FPM)
They address the question on: how a Client can obtain the list of entityIDs 
that can be used as input to a FPM without having to download a full property 
map. The FPM query input format and response have been updated accordingly. 
- In Section 8: a paragraph explains why this is useful for a Client 
- In section 8.3 Accept Input Parameters: the format of query object 
ReqFilteredPropertyMap is revised and explained to support this. The property 
member is optional.
- In section 8.6 Filtered Property Map Response: 
--- an error case is added when input member "entities" is absent 
--- text explains how, when the "property" member is absent in the query, the 
Server returns an empty value for the queried entities. 

We hope the updates are meeting the review expectations.
Thanks,
Sabine and authors 

>-Original Message-
>From: alto  On Behalf Of internet-dra...@ietf.org
>Sent: Thursday, August 12, 2021 4:45 PM
>To: i-d-annou...@ietf.org
>Cc: alto@ietf.org
>Subject: [alto] I-D Action: draft-ietf-alto-unified-props-new-18.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 Extension: Entity Property Maps
>Authors : Wendy Roome
>  Sabine Randriamasy
>  Y. Richard Yang
>  Jingxuan Jensen Zhang
>  Kai Gao
>   Filename: draft-ietf-alto-unified-props-new-18.txt
>   Pages   : 60
>   Date: 2021-08-12
>
>Abstract:
>   This document extends the base Application-Layer Traffic Optimization
>   (ALTO) Protocol by generalizing the concept of "endpoint properties"
>   to entities defined by a wide set of objects, instead of only IP
>   addresses.  Further, these properties are presented as maps, similar
>   to the network and cost maps in the base ALTO protocol.  The protocol
>   is extended in two major directions.  First, from endpoints
>   restricted to IP addresses to entities covering a wider and
>   extensible set of objects; second, from properties on specific
>   endpoints to entire entity property maps.  These extensions introduce
>   additional features allowing entities and property values to be
>   specific to a given information resource.  This is made possible by a
>   generic and flexible design of entity and property types.
>
>
>The IETF datatracker status page for this draft is:
>https://datatracker.ietf.org/doc/draft-ietf-alto-unified-props-new/
>
>There is also an htmlized version available at:
>https://datatracker.ietf.org/doc/html/draft-ietf-alto-unified-props-new-18
>
>A diff from the previous version is available at:
>https://www.ietf.org/rfcdiff?url2=draft-ietf-alto-unified-props-new-18
>
>
>Internet-Drafts are also available by anonymous FTP at:
>ftp://ftp.ietf.org/internet-drafts/
>
>
>___
>alto mailing list
>alto@ietf.org
>https://www.ietf.org/mailman/listinfo/alto

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

Re: [alto] New wikipedia page

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

Hello Martin,

Great thanks for this initiative, the page is very informative, synthetic and 
pleasant to read. With the ALTO WG contributors, we will be more than happy to 
update it. Before doing so, if you think it makes sense, we plan to draft the 
potential additions on a wiki page, to ensure WG consensus and approval from 
the WG chairs and AD. We will proceed with collaborative editing and use the 
datatracker facilities. And indeed, we aim at keeping it concise and focused on 
mature work.
Best regards,
Sabine

From: alto  On Behalf Of Martin Duke
Sent: Friday, July 2, 2021 8:46 PM
To: IETF ALTO 
Subject: [alto] New wikipedia page

Hello ALTO,

When reviewing ALTO documents I find myself constantly re-reading large 
sections of RFC 7285. To stop repeating this step, I cleaned up my notes and 
made a Wikipedia page.

https://en.wikipedia.org/wiki/ALTO_(protocol)

While I think it's a mistake to put immature internet drafts on the wiki page, 
please feel free to improve the page, while keeping it relatively concise.

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

Re: [alto] Moving unified-props version 17 ahead

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

Hi Vijay,

Great thanks for your review. We will integrate your proposed updates in 
further versions that we will submit upon AD review.
Best regards,
Sabine

From: Vijay Gurbani 
Sent: Tuesday, June 15, 2021 5:29 PM
To: draft-ietf-alto-unified-props-...@ietf.org
Cc: IETF ALTO 
Subject: Moving unified-props version 17 ahead

Authors: I have reviewed version -17 against my chair reviews of the draft.

I will be submitting version -17 to IESG shortly.  In the meantime, here are 
residual comments from version -17 and discussion from the chair review that 
you can incorporate during AUTH48.

- S3.2.1: s/registered at the IANA,/registered with IANA,/

- Discussion around Section 4.7.1, the resolution was:
  > [ [SR] ] (Sabine) *
  > Actually we removed 4.7.1 and the text of 4.7 (not the title yet).
  > Most of the text of 4.7 was moved to 4.6.1 last paragraph, as 4.7
  > "looked" too small.  However, even if the text of 4.7 is short, it
  > is important, as it introduces fields that must be specified at
  > the IANA, as specified in section 12.3.  So we may just put the text
  > back in 4.7, if you think it is better.

  I think current S4.7 is fine, the length of a section should not
  dictate whether or not a content is in a section, the content should.

- Discussion around Section 4.3.3, the resolution was:
  > [ [SR] ] (sabine)  *
  > the text has been updated and uses  "subsets" (upper level) and
  > "superset" (lower level). [...] Therefore, we would rather use:
  > supersets (upper levels), subsets (lower levels) [...]

  That is fine as long as you define your intention before hand,
  which you are doing now.

- S5.1.1: s/with the IANA/with IANA/

- S11: s/at the IANA/from IANA/

Thank you all for your hard work.

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

Re: [alto] I-D Action: draft-ietf-alto-unified-props-new-17.txt

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

Dear Vijay,

A new version 17 of the "ALTO Extension: Entity Property Maps" has been 
uploaded and hopefully addresses the pending review comments.
It can be found at the link below, by clicking on the number "16" on the ALTO 
status pages.
https://tools.ietf.org/html/draft-ietf-alto-unified-props-new-17
Below is a digest of the updates and we look forward to having your feedback.
A detailed "diff" can be sent if you wish. 

Best regards,
Sabine & co-authors
=
updates in draft-ietf-alto-unified-props-new-17
=
Previous V16 was submitted to address Vijay's review of v15
This V17 addresses remaining issues on V15 review

Main update is the addition of a substantial Section 11. Security 
Considerations. 
The other updates are as follows:  

- Defined terminology nomenclature used in 4.4.  Entity Hierarchy and Property 
Inheritance
--- related (small) edits in subsections 

- In Section 4.7 Defining Information Resource for Resource-Specific Property 
Values
text was clarified and moved back from 4.6.1 to 4.7. Section 4.7.1 (of V15) 
with examples was merged with 4.7 

- Clarified text on defining information resources in sections 4.6 and 4.7, as 
review reflects it was unclear
--- added example in 4.6.2 of entity domain types that do  not have a defining 
resource
--- Clarified text in related IANA sections 12.2.2 and 12.3

- Added normative "MUST" wherever needed 
--- section 4.3.  Resource-Specific Entity Property Value
--- 4.6.1.  Defining Information Resource and its Media Type
--- sections 12.2.2 and 12.3 on item "Media type of defining information 
resource"
- Replaced lower case "must" with other words where convenient

- Rewording
---  Clarified sentence distinguishes domain name and domain type in 3.2.1 
--- Added introduction sentence in Section 4 Advanced Features... 
- Typos and nits in sections  5.1.2, 8.6

- Added normative and informative references

>-Original Message-
>From: alto  On Behalf Of internet-dra...@ietf.org
>Sent: Friday, April 16, 2021 8:54 PM
>To: i-d-annou...@ietf.org
>Cc: alto@ietf.org
>Subject: [alto] I-D Action: draft-ietf-alto-unified-props-new-17.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 Extension: Entity Property Maps
>Authors : Wendy Roome
>  Sabine Randriamasy
>  Y. Richard Yang
>  Jingxuan Jensen Zhang
>  Kai Gao
>   Filename: draft-ietf-alto-unified-props-new-17.txt
>   Pages   : 59
>   Date: 2021-04-16
>
>Abstract:
>   This document extends the base Application-Layer Traffic Optimization
>   (ALTO) Protocol by generalizing the concept of "endpoint properties"
>   as applied to endpoints as defined by IP addresses to endpoints
>   defined by a wider set of objects.  Further, these properties are
>   presented as maps, similar to the network and cost maps in the base
>   ALTO protocol.  The protocol is extended in two major directions.
>   First, from endpoints restricted to IP addresses to entities covering
>   a wider and extensible set of objects; second, from properties on
>   specific endpoints to entire entity property maps.  These extensions
>   introduce additional features allowing entities and property values
>   to be specific to a given information resource.  This is made
>   possible by a generic and flexible design of entity and property
>   types.
>
>
>The IETF datatracker status page for this draft is:
>https://datatracker.ietf.org/doc/draft-ietf-alto-unified-props-new/
>
>There are also htmlized versions available at:
>https://tools.ietf.org/html/draft-ietf-alto-unified-props-new-17
>https://datatracker.ietf.org/doc/html/draft-ietf-alto-unified-props-new-17
>
>A diff from the previous version is available at:
>https://www.ietf.org/rfcdiff?url2=draft-ietf-alto-unified-props-new-17
>
>
>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.
>
>Internet-Drafts are also available by anonymous FTP at:
>ftp://ftp.ietf.org/internet-drafts/
>
>
>___
>alto mailing list
>alto@ietf.org
>https://www.ietf.org/mailman/listinfo/alto

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

Re: [alto] Chair review of unified-props (Part 2 of 2)

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

Hello Vijay,

Thank you for your review of Entity Property Maps. As promised, please find 
inline the answers from Jensen and myself on how your comments have been 
addressed, prefixed respectively by “[jensen]” and “(sabine)”.
Responses on sections 9.3 and 11, with “*”, request further feedback from 
you.
Thanks,
Sabine


From: Vijay Gurbani 
Sent: Wednesday, January 27, 2021 5:28 PM
To: draft-ietf-alto-unified-props-...@ietf.org
Cc: IETF ALTO 
Subject: Chair review of unified-props (Part 2 of 2)

Chair review from Section 5 - end (inclusive).

Please go through the Major review points, they require some attention.

This concludes my review of this document.  Overall a well-written document
covering a range of important extensions to ALTO.

Major:

- S5.1.1: "The '.' separator MUST NOT be used unless specifically indicated in a
further extension document." ==> I don't understand this.  If the '.' must not
be used, then this should be an absolute condition (MUST NOT is the normative
strength in the sentence).  If this document allows the '.' to be used in a
further extension document, then this is a relative --- not absolute ---
condition, and thus a normative SHOULD NOT seem to be better.  However, as
currently written, this sentence seems rather wishy-washy.  Either say '.' is
out of bounds or say it is not, it seems weird to say that this document does
not use it, but others can.

One way to achieve this is to replace that sentence with:

  The '.' separator is not used by this document, however, future
  extensions may use it.  For the purpose of this document, the
  strings "ipv4", "ipv6", and "pid" are valid entity domain
  types, while "ipv4.anycast", and "pid.local" are invalid.

However, even then, I am not sure if the above is correct.  Later, in S5.1.2,
you go on to say that "Note that the '.' separator is not allowed in
EntityDomainType and hence there is no ambiguity on whether an entity domain
name refers to a resource-agnostic entity domain or a resource-specific entity
domain."  Thus it seems to me that future extensions could run into trouble if
they allow '.' in the EntityDomainType.

This needs to be resolved before publication.
[ [SR] ] [Jensen] Thanks for noticing this bug. The '.' separator is not 
allowed even in an extension document.
The paragraph has been revised to the following:

   An entity domain has a type, which is uniquely identified by a string
   that MUST be no more than 64 characters, and 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), or the low line ('_', U+005F).


- S5.1.2, last paragraph: "Note that the resource ID format defined in Section
10.1 of [RFC7285]..." ==> Section 10.1 of RFC 7285 defines "PID Name", not
"Resource ID", which is defined in the next section.  Please clarify.
[ [SR] ] [Jensen] New paragraph rephrasing now:
   Note also that Section 10.1 of [RFC7285] specifies the format of the PID 
Name which is
   the format of the resource ID including the following specification: ...


- S9.1: "...it is RECOMMENDED that the EPS be deprecated in favour of ..." ==>
This is very important: If this draft is recommending a change in RFC 7285, then
the status of this draft must say "Updates: 7285" at the top of the draft (it
currently does not).  This will cause the RFC Editor to enter a "Updated by:
RFC" in the masthead of RFC7285.

Further, I presume that since this update is a recommendation, the processing
rules of property map and filtered property map are distinct enough that legacy
ALTO servers and clients will continue operations?  Please advise.
[ [SR] ] [Jensen]  We do not intend to update RFC7285 to deprecate EPS.
This recommendation is more like suggesting that the new ALTO servers that 
support UP
should also provide the EPS to be backwards compatible with legacy clients.
Since the keyword "RECOMMENDED" has a specific meaning, let's not use this 
keyword here.
The paragraph has been changed as follows:
NEW
Since the Property Map and the Filtered Property Map defined in this
   document provide a functionality that covers the Endpoint Property
   Service (EPS) defined in Section 11.4 of [RFC7285], ALTO servers may
   prefer to provide Property Map and Filtered Property Map in place of
   EPS.  However, for the legacy endpoint properties, it is recommended
   that ALTO servers also provide EPS so that legacy clients can still
   be supported.


- S9.3: What does "little or no impact on other previously defined properties"
mean?  Again, this appears wishy-washy for a standards document.  Either we know
that there is some impact, and we document what the impact is, or we state that
there is no impact.  But saying "little or no impact" is not helpful.  Please
state where there is impact and whether this impact will cause backwards
compatibility problems.

I note that S12.2.1 further expands on this "little or no impact".  Perhaps a
seco

Re: [alto] Chair review of unified-props (Part 1 of 2)

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

Hello Vijay,

Thank you for your review of Entity Property Maps. As promised, please find 
inline the answers from Jensen and myself on how your comments have been 
addressed, prefixed respectively by “[jensen]” and “(sabine)”.
Responses on sections 4.7.1 and 4.4.3, with “*” request further feedback 
from you.
Thanks,
Sabine

From: Vijay Gurbani 
Sent: Tuesday, January 26, 2021 5:06 PM
To: draft-ietf-alto-unified-props-...@ietf.org
Cc: IETF ALTO 
Subject: Chair review of unified-props (Part 1 of 2)

All: My apologies for the late start on the chair reviews of the documents I am 
shepherding.  However, I have started the review.

Below is the first (of two parts) review of unified-props.  This review 
includes all sections from Abstract to Section 4.7.1 (inclusive).

Please let me know if you have any questions.  I will post the second part 
tomorrow.

Chair review from Abstract - Section 4.7.1 (inclusive).

Major:

- Abstract: "...by generalizing the concept of "endpoint properties" to generic
type of entities..." ==> Note that the antecedent ("endpoint properties") and
the consequent ("type of entities") do not match.  Perhaps better to say: "...by
generalizing the concept of "endpoint properties" as applied to endpoints
defined by IP addresses to endpoints a wider set of objects..."

More concretely:

OLD:
This document extends the base Application-Layer Traffic Optimization
(ALTO) Protocol by generalizing the concept of "endpoint properties"
to generic types of entities, and by presenting those properties as
maps, similar to the network and cost maps in the base ALTO protocol.

NEW:
This document extends the base Application-Layer Traffic Optimization
(ALTO) Protocol by generalizing the concept of "endpoint properties"
as applied to endpoints as defined by IP addresses to endpoints defined
by a wider set of objects.  Further, these properties are presented
as maps, similar to the network and cost maps in the base ALTO protocol.
[ [SR] ] [Jensen] It looks good to me. Done.


- S3.2.1: "An entity domain type is expected to be registered at the IANA" ==>
you mean "MUST be registered with IANA"?  Or "SHOULD be registered with IANA"?
Best to use normative language here, unless you have a specific reason not
to.
[ [SR] ] [Jensne] We changed "is expected to" to "MUST". Thanks for pointing it 
out.
I don't see any reason not to do it.

- S3.2.2: What does this mean: "As a consequence, entities in such
domains may be defined in a resource handling this domain type but
not in other resources handling this same domain type."?  I am unable to
parse this, I think you are saying that of all the resources handling a
particular domain type, the entity must be defined in only one of them.  If
so, perhaps best to reword; something like:
   OLD:
   As a consequence, entities in such domains may be defined in a
   resource handling this domain type but not in other resources handling
   this same domain type.
   NEW:
   As a consequence, of all the resources defining a particular domain
   type, the entity must be defined in only one resource.
[ [SR] ] (Sabine)
the point is rather to say that a domain can contain entities defined 
relatively to an information resource. In this case, the domain needs to have a 
name that ensures that the entities of the domain can all be retrieved and that 
with no ambiguities.
For instance: we may have 2 domains, "netmap1.pid" = {"mypidP", "mypidB", 
"mypidS"} and  "netmap2.pid" = {"mypidP", "mypidB", "mypidL"} . "mypidP" may or 
may not point to the same addresses in "netmap1" and "netmap2". This is not 
problematic as long as, when the Client queries "mypidP" defined in "netmap1" 
or "netmap2", it gets what is defined in these network maps for "mypidP".
The text has been rephrased in this direction. Please let us know if it is 
clear enough.

- S4.2.2, first paragraph: Is this example valid?  From my experience, ASN's
contain IPv4 addresses defined by a CIDR block.  I think it is highly unlikely
that a service provider will define a CIDR block 
(192.0.1.0/24) and have that
block span ASNs, but perhaps I am mistaken.  Perhaps someone from network
operations may want to look at this example and bless it, or if you are sure
that networks are architected in such a manner, then we can let it stay.
[ [SR] ] (Sabine)
Agree. Property "ASN" has been replaced with dummy property value "P".


- S4.6.2: "When an ANE has a persistent identifier, say, "entity-4", the
latter", here what do you mean by "latter"?  In this sentence, I do not see two
things that can be characterized as "former" and "latter"...?
[ [SR] ] [Jensen] New sentence: "An ANE may have a persistent identifier, say, 
"entity-4",
that is provided by the Server as a value of the "persistent-entity-id" 
property of this ANE."
(sabine)
the following sentence was also clarified as follows:
OLD
Further properties may be queried on an ANE with a persistent entity ID.
NEW
Further properties may then be queried on an 

Re: [alto] ALTO Draft ReCharter WG review - extensible set of policy attributes(Internet mail)

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

Hello Chunchan,

Thanks for the clarification. If I understand well:
- the cloud gaming server (CGS) needs notifications on QoS CHANGE information. 
This change would be conveyed by an ALTO Server that abstracts NEF information 
to the ALTO Client in the CGS.
- only QoS CHANGES upon e.g. exceeding some hysteresis threshold are useful 
because Continuous QoS information is needless and causes signaling overhead. 
These changes should be reported to the CGS immediately. To this end, ALTO 
extended pub/sub is needed.
- regarding the pace of the notification, I would have a question: Your e-mail 
says “the cloud gaming server does need the real-time QUICK QOS CHANGE 
information” and later specifies “Quick QoS Change notification should not be 
too frequent, the QUICK QoS change notification should be minutes level”.
So what frequency does the term “real-time” in the 1rst sentence cover? Maybe I 
missed something. Definitely minute-level notification is achievable, given the 
limited size of the topology covered by ALTO in this case.

Another question:
- the number of possible QoS values Qi are quite limited and this “volatile” 
and light information would be conveyed with a given channel, say the channel 
“Ve” mentioned earlier by Richard.
- The longer term costs and properties reflecting QoS impacting KPIs such as 
latency L and throughput T would then be conveyed via ALTO channel “Vs” in an 
asynchronous way
-  would the values of these costs and properties be made dependent on the 
values of Qi?

Thanks,
Sabine



From: chunshxiong(熊春山) 
Sent: Friday, March 12, 2021 7:38 AM
To: Y. Richard Yang ; Randriamasy, Sabine (Nokia - 
FR/Paris-Saclay) 
Cc: alto-cha...@ietf.org; alto-...@ietf.org; Qin Wu ; IETF 
ALTO 
Subject: RE: [alto] ALTO Draft ReCharter WG review - extensible set of policy 
attributes(Internet mail)

Hello all,

@Randriamasy, Sabine (Nokia - 
FR/Paris-Saclay)<mailto:sabine.randriam...@nokia-bell-labs.com>,  You say “An 
ALTO Server cannot provide real-time information".
I almost agree with your point.

But I want the ALTO Server to support very quick notification information to 
the ALTO Client, if there is a quick change as provided in my other email.

I think one goal of ALTO Server is not to  provide very frequent notification 
to the ALTO Client, but If there is some quick or big change, the ALTO Server 
needs very quickly notify the ALTO Client, just this, not repeated and 
continuous notify. I think this quick notification is very helpful for the 
cloud gaming server to adaptive change the coding scheme. But the cloud gaming 
does not need the ALTO server to repeated notify the current network bitrates. 
Cloud gaming server needs the change information not the status information. 
For the cloud gaming sever can “intelligently” detect the slow change 
information, but it is very hard for the gaming server to detect the quick 
change in short time (because there is buffer in the client and Server), in 
such case, if the ALTO server can provide such quick (QoS) change information 
to the cloud gaming server, the cloud gaming server can quickly change its 
coding scheme.

So, Yes, the cloud gaming server does NOT need the real-time QoS information, 
but the cloud gaming server does need the real-time QUICK QOS CHANGE 
information.

But, this Quick QoS change (e.g. Alternative QoS profile) is defined to trigger 
the cloud server to make some changes(e.g. encoding scheme change).  It should 
be avoid to define a  QUICK QOS change that does not trigger the cloud server 
to make any changes. So the real-time frequently reporting the current QOS to 
the cloud server is really not needed,  this repeated and continuous 
reporting/notification only creates a lot of message loads and no help for the 
cloud gaming server.

Also this Quick QoS Change notification should not be too frequent, the QUICK 
QoS change notification should be minutes level, i.e. one notification per one 
minute. In some cases, it is possible that the notification can be several 
notifications per one minutes, but the average rate should be less than one 
notification per one minute.


BRs,
Chunshan Xiong

From: alto mailto:alto-boun...@ietf.org>> On Behalf Of 
Y. Richard Yang
Sent: Friday, March 12, 2021 5:29 AM
To: Randriamasy, Sabine (Nokia - FR/Paris-Saclay) 
mailto:sabine.randriam...@nokia-bell-labs.com>>
Cc: alto-cha...@ietf.org<mailto:alto-cha...@ietf.org>; 
alto-...@ietf.org<mailto:alto-...@ietf.org>; Qin Wu 
mailto:bill...@huawei.com>>; IETF ALTO 
mailto:alto@ietf.org>>
Subject: Re: [alto] ALTO Draft ReCharter WG review - extensible set of policy 
attributes(Internet mail)

Hi Sabine, Qin,

Good discussions.

I support the use cases of the design direction. One suggestion is to look at 
the design in a slightly abstract, general framework. In particular, the 
abstract framework looks like this to me:

- Ve: A set of "volatile" (ephemeral) variables; Ve tends to be

Re: [alto] ALTO Draft ReCharter WG review - extensible set of policy attributes

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

Hi Richard,

Thanks for your thoughts. This is definitely the path we want to take together 
with a flexible design to encode and represent information carried by Ve.
Meet you virtually at the ALTO session
Cheers,
Sabine

From: Y. Richard Yang 
Sent: Thursday, March 11, 2021 10:29 PM
To: Randriamasy, Sabine (Nokia - FR/Paris-Saclay) 

Cc: Qin Wu ; IETF ALTO ; 
alto-cha...@ietf.org; alto-...@ietf.org
Subject: Re: [alto] ALTO Draft ReCharter WG review - extensible set of policy 
attributes

Hi Sabine, Qin,

Good discussions.

I support the use cases of the design direction. One suggestion is to look at 
the design in a slightly abstract, general framework. In particular, the 
abstract framework looks like this to me:

- Ve: A set of "volatile" (ephemeral) variables; Ve tends to be small, 
fast-changing data;
- Vs: Another set of records that are stable and indexed by the ephemeral 
variables; Vs can be large, but stable data.

There are two channels from the network to the application:
- Channel 1 for Ve
- Channel 2 for Vs

This definitely is a generic framework supported by some existing use cases 
including what you presented.

In the general framework, Channel 1 can be ALTO or protocol specific. Since it 
is short and needs low latency, it is more likely to be protocol specific and 
embedded in some other protocol such as even data path protocols (5G, ECN bits 
in IP); channel 2 is ALTO.

A couple of points to be considered when conducting further design:
- One thing we learned from SSE is the consistency between these two channels 
(or more, as Ve can be carried by multiple channels, etc), and
- Document additional use cases beyond the demonstrated use cases.

Looking forward to talking to you (virtually) f2f tomorrow.

Richard

On Thu, Mar 11, 2021 at 5:01 AM Randriamasy, Sabine (Nokia - FR/Paris-Saclay) 
mailto:sabine.randriam...@nokia-bell-labs.com>>
 wrote:
Hi Qin,

Please see inline,
Thanks
Sabine

From: Qin Wu mailto:bill...@huawei.com>>
Sent: Thursday, March 11, 2021 9:32 AM
To: Randriamasy, Sabine (Nokia - FR/Paris-Saclay) 
mailto:sabine.randriam...@nokia-bell-labs.com>>;
 IETF ALTO mailto:alto@ietf.org>>
Cc: alto-cha...@ietf.org<mailto:alto-cha...@ietf.org>; 
alto-...@ietf.org<mailto:alto-...@ietf.org>
Subject: RE: ALTO Draft ReCharter WG review - extensible set of policy 
attributes

Hi, Sabine:
发件人: Randriamasy, Sabine (Nokia - FR/Paris-Saclay) 
[mailto:sabine.randriam...@nokia-bell-labs.com]
发送时间: 2021年3月11日 1:55
收件人: Qin Wu mailto:bill...@huawei.com>>; IETF ALTO 
mailto:alto@ietf.org>>
抄送: alto-cha...@ietf.org<mailto:alto-cha...@ietf.org>; 
alto-...@ietf.org<mailto:alto-...@ietf.org>
主题: RE: ALTO Draft ReCharter WG review - extensible set of policy attributes

Hello ALTO WG,

Regarding the proposed work item on “Protocol extensions to support a richer 
and extensible set of policy attributes in ALTO information update request and 
response” (GPE for short) , I would like to add the following:

This work item can be useful, among others, to allow a UE getting cellular 
network KPIs from an ALTO Server, to figure out for example whether the cell is 
congested, or which cell to choose.

An ALTO Server cannot provide real-time information. With the proposed 
extensions, it can indicate a number of real-time network parameters against 
which ALTO cost values can be modulated.

[Qin]: Yes, the current ALTO server can only provide non-real time or near real 
time information, performance metrics work allows ALTO server expose 
performance data. If ALTO protocol is extended to support pub sub mechanism,
Providing real time information will not be an issue.

But I agree in many cases, providing real time information is not necessary, 
e.g., cloud gaming use case provided Tencent and china mobile, their case is 
different from your proposed case, they will use cloud gaming server as ALTO 
client to get needed information.
[ [SR] ] indeed, an ALTO client (AOC for short) can be beneficially integrated 
with a cloud gaming server (CGS for short) . In that case, the ALTO information 
provided by the ALTO Server (AOS for short) can be made aware of given specific 
parameters captured by the CGS at a different pace. This may speed up the 
process as well.

These parameters are received by UEs directly from the network and not from 
ALTO. The UE receives an array of ALTO cell KPI values that each depend on the 
value of a parameter. The UE can pick the  ALTO value corresponding to the 
value of the real-time parameter received from the network. Thus, the UE 
modulates the received ALTO values in real-time.

[Qin]: your case is UE centric solution, UE gets network KPI from ALTO server 
and get real time parameter from another data source in the Network, what is 
not clear is how real time parameter is correlated with Network KPI information 
within UE.
Also the interface between UE and RAN is not in the scope of ALTO work, I think.

Re: [alto] I-D Action: draft-ietf-alto-unified-props-new-16.txt

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

Hi Vijay,

Thanks again for your revision of version 15.
I still owe to you and the WG an inline response by Jensen and myself to your 
comments.
For the moment, I have the attached text file that integrates them with your 
comments.
Most of your comments were hopefully correctly addressed and we still have 
thoughts on comments regarding sections:
4.7.1, 4.4.3, 9.3, 11.
I will send an “integrated” response tomorrow to the list.
Thanks,
Sabine


From: Vijay Gurbani 
Sent: Saturday, February 27, 2021 9:18 PM
To: Randriamasy, Sabine (Nokia - FR/Paris-Saclay) 

Cc: alto@ietf.org
Subject: Re: [alto] I-D Action: draft-ietf-alto-unified-props-new-16.txt

Dear Sabine: Thank you.  I will look over the changes and move the draft ahead.
I plan to do so next week.
- vijay

On Mon, Feb 22, 2021 at 6:49 PM Randriamasy, Sabine (Nokia - FR/Paris-Saclay) 
mailto:sabine.randriam...@nokia-bell-labs.com>>
 wrote:
Dear all,

This version 16 addresses most of Vijay's review comments part 1 and 2.
We will come back in a few days with details on how the comments have been 
addressed.
Thanks,
Sabine

>-Original Message-
>From: alto mailto:alto-boun...@ietf.org>> On Behalf Of 
>internet-dra...@ietf.org<mailto:internet-dra...@ietf.org>
>Sent: Tuesday, February 23, 2021 1:01 AM
>To: i-d-annou...@ietf.org<mailto:i-d-annou...@ietf.org>
>Cc: alto@ietf.org<mailto:alto@ietf.org>
>Subject: [alto] I-D Action: draft-ietf-alto-unified-props-new-16.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 extension: Entity Property Maps
>Authors : Wendy Roome
>  Sabine Randriamasy
>  Y. Richard Yang
>  Jingxuan Jensen Zhang
>  Kai Gao
>   Filename: draft-ietf-alto-unified-props-new-16.txt
>   Pages   : 57
>   Date: 2021-02-22
>
>Abstract:
>   This document extends the base Application-Layer Traffic Optimization
>   (ALTO) Protocol by generalizing the concept of "endpoint properties"
>   as applied to endpoints as defined by IP addresses to endpoints
>   defined by a wider set of objects.  Further, these properties are
>   presented as maps, similar to the network and cost maps in the base
>   ALTO protocol.  The protocol is extended in two major directions.
>   First, from endpoints restricted to IP addresses to entities covering
>   a wider and extensible set of objects; second, from properties on
>   specific endpoints to entire entity property maps.  These extensions
>   introduce additional features allowing entities and property values
>   to be specific to a given information resource.  This is made
>   possible by a generic and flexible design of entity and property
>   types.
>
>
>The IETF datatracker status page for this draft is:
>https://datatracker.ietf.org/doc/draft-ietf-alto-unified-props-new/
>
>There are also htmlized versions available at:
>https://tools.ietf.org/html/draft-ietf-alto-unified-props-new-16
>https://datatracker.ietf.org/doc/html/draft-ietf-alto-unified-props-new-16
>
>A diff from the previous version is available at:
>https://www.ietf.org/rfcdiff?url2=draft-ietf-alto-unified-props-new-16
>
>
>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<http://tools.ietf.org>.
>
>Internet-Drafts are also available by anonymous FTP at:
>ftp://ftp.ietf.org/internet-drafts/
>
>
>___
>alto mailing list
>alto@ietf.org<mailto:alto@ietf.org>
>https://www.ietf.org/mailman/listinfo/alto

___
alto mailing list
alto@ietf.org<mailto:alto@ietf.org>
https://www.ietf.org/mailman/listinfo/alto
=== Chair review of unified-props (Part 1 of 2) ===

Major:

- Abstract: "...by generalizing the concept of "endpoint properties" to generic
type of entities..." ==> Note that the antecedent ("endpoint properties") and
the consequent ("type of entities") do not match.  Perhaps better to say: "...by
generalizing the concept of "endpoint properties" as applied to endpoints
defined by IP addresses to endpoints a wider set of objects..."

More concretely:

OLD:
This document extends the base Application-Layer Traffic Optimization
(ALTO) Protocol by generalizing the concept of "endpoint properties"
to generic types of entities, and by presenting those properties as
maps, similar to the network and cost maps in the base ALTO protocol.

NEW:
Th

Re: [alto] ALTO Draft ReCharter WG review - extensible set of policy attributes

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

Hi Qin,

To my knowledge, ALTO is not expected to provide real-time information.
On the other hand is it very useful to convey abstracted information covering 
cellular networks and beyond, starting with edge.
So an ALTO Server may want to approach real-time information but cannot commit 
to it.
This all depends on the covered network scope and level of network information 
aggregation or abstraction and other factors that may be looked at within the 
scope of the ALTO operation automation WI.
To help an ALTO Client needing near-instant information, the ALTO Server may 
indicate the available levels of information “freshness” or  length of validity 
intervals with policy attributes that can be used by the Client in its ALTO 
request.

Sabine


From: Qin Wu 
Sent: Thursday, March 11, 2021 11:41 AM
To: Randriamasy, Sabine (Nokia - FR/Paris-Saclay) 
; IETF ALTO 
Cc: alto-cha...@ietf.org; alto-...@ietf.org
Subject: RE: ALTO Draft ReCharter WG review - extensible set of policy 
attributes

Sabine:
Thanks for your clarification, I want to make sure the ALTO clients can express 
to the ALTO sever that they want real time data or not real time data. Also 
Alto server can express that the returned  information is real time or not real 
time in the response message to the ALTO clients.
Are these covered by your case as well?

_Qin
发件人: Randriamasy, Sabine (Nokia - FR/Paris-Saclay) 
[mailto:sabine.randriam...@nokia-bell-labs.com]
发送时间: 2021年3月11日 18:01
收件人: Qin Wu mailto:bill...@huawei.com>>; IETF ALTO 
mailto:alto@ietf.org>>
抄送: alto-cha...@ietf.org<mailto:alto-cha...@ietf.org>; 
alto-...@ietf.org<mailto:alto-...@ietf.org>
主题: RE: ALTO Draft ReCharter WG review - extensible set of policy attributes

Hi Qin,

Please see inline,
Thanks
Sabine

From: Qin Wu mailto:bill...@huawei.com>>
Sent: Thursday, March 11, 2021 9:32 AM
To: Randriamasy, Sabine (Nokia - FR/Paris-Saclay) 
mailto:sabine.randriam...@nokia-bell-labs.com>>;
 IETF ALTO mailto:alto@ietf.org>>
Cc: alto-cha...@ietf.org<mailto:alto-cha...@ietf.org>; 
alto-...@ietf.org<mailto:alto-...@ietf.org>
Subject: RE: ALTO Draft ReCharter WG review - extensible set of policy 
attributes

Hi, Sabine:
发件人: Randriamasy, Sabine (Nokia - FR/Paris-Saclay) 
[mailto:sabine.randriam...@nokia-bell-labs.com]
发送时间: 2021年3月11日 1:55
收件人: Qin Wu mailto:bill...@huawei.com>>; IETF ALTO 
mailto:alto@ietf.org>>
抄送: alto-cha...@ietf.org<mailto:alto-cha...@ietf.org>; 
alto-...@ietf.org<mailto:alto-...@ietf.org>
主题: RE: ALTO Draft ReCharter WG review - extensible set of policy attributes

Hello ALTO WG,

Regarding the proposed work item on “Protocol extensions to support a richer 
and extensible set of policy attributes in ALTO information update request and 
response” (GPE for short) , I would like to add the following:

This work item can be useful, among others, to allow a UE getting cellular 
network KPIs from an ALTO Server, to figure out for example whether the cell is 
congested, or which cell to choose.

An ALTO Server cannot provide real-time information. With the proposed 
extensions, it can indicate a number of real-time network parameters against 
which ALTO cost values can be modulated.

[Qin]: Yes, the current ALTO server can only provide non-real time or near real 
time information, performance metrics work allows ALTO server expose 
performance data. If ALTO protocol is extended to support pub sub mechanism,
Providing real time information will not be an issue.

But I agree in many cases, providing real time information is not necessary, 
e.g., cloud gaming use case provided Tencent and china mobile, their case is 
different from your proposed case, they will use cloud gaming server as ALTO 
client to get needed information.
[ [SR] ] indeed, an ALTO client (AOC for short) can be beneficially integrated 
with a cloud gaming server (CGS for short) . In that case, the ALTO information 
provided by the ALTO Server (AOS for short) can be made aware of given specific 
parameters captured by the CGS at a different pace. This may speed up the 
process as well.

These parameters are received by UEs directly from the network and not from 
ALTO. The UE receives an array of ALTO cell KPI values that each depend on the 
value of a parameter. The UE can pick the  ALTO value corresponding to the 
value of the real-time parameter received from the network. Thus, the UE 
modulates the received ALTO values in real-time.

[Qin]: your case is UE centric solution, UE gets network KPI from ALTO server 
and get real time parameter from another data source in the Network, what is 
not clear is how real time parameter is correlated with Network KPI information 
within UE.
Also the interface between UE and RAN is not in the scope of ALTO work, I think.
[ [SR] ] definitely, the scope of the extension restricts to exchanges between 
AOS and AOC. The UE may have some agent that gathers and relates the RAN 
indicators and the AL

Re: [alto] ALTO Draft ReCharter WG review - extensible set of policy attributes

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

Hi Qin,

Please see inline,
Thanks
Sabine

From: Qin Wu 
Sent: Thursday, March 11, 2021 9:32 AM
To: Randriamasy, Sabine (Nokia - FR/Paris-Saclay) 
; IETF ALTO 
Cc: alto-cha...@ietf.org; alto-...@ietf.org
Subject: RE: ALTO Draft ReCharter WG review - extensible set of policy 
attributes

Hi, Sabine:
发件人: Randriamasy, Sabine (Nokia - FR/Paris-Saclay) 
[mailto:sabine.randriam...@nokia-bell-labs.com]
发送时间: 2021年3月11日 1:55
收件人: Qin Wu mailto:bill...@huawei.com>>; IETF ALTO 
mailto:alto@ietf.org>>
抄送: alto-cha...@ietf.org<mailto:alto-cha...@ietf.org>; 
alto-...@ietf.org<mailto:alto-...@ietf.org>
主题: RE: ALTO Draft ReCharter WG review - extensible set of policy attributes

Hello ALTO WG,

Regarding the proposed work item on “Protocol extensions to support a richer 
and extensible set of policy attributes in ALTO information update request and 
response” (GPE for short) , I would like to add the following:

This work item can be useful, among others, to allow a UE getting cellular 
network KPIs from an ALTO Server, to figure out for example whether the cell is 
congested, or which cell to choose.

An ALTO Server cannot provide real-time information. With the proposed 
extensions, it can indicate a number of real-time network parameters against 
which ALTO cost values can be modulated.

[Qin]: Yes, the current ALTO server can only provide non-real time or near real 
time information, performance metrics work allows ALTO server expose 
performance data. If ALTO protocol is extended to support pub sub mechanism,
Providing real time information will not be an issue.

But I agree in many cases, providing real time information is not necessary, 
e.g., cloud gaming use case provided Tencent and china mobile, their case is 
different from your proposed case, they will use cloud gaming server as ALTO 
client to get needed information.
[ [SR] ] indeed, an ALTO client (AOC for short) can be beneficially integrated 
with a cloud gaming server (CGS for short) . In that case, the ALTO information 
provided by the ALTO Server (AOS for short) can be made aware of given specific 
parameters captured by the CGS at a different pace. This may speed up the 
process as well.

These parameters are received by UEs directly from the network and not from 
ALTO. The UE receives an array of ALTO cell KPI values that each depend on the 
value of a parameter. The UE can pick the  ALTO value corresponding to the 
value of the real-time parameter received from the network. Thus, the UE 
modulates the received ALTO values in real-time.

[Qin]: your case is UE centric solution, UE gets network KPI from ALTO server 
and get real time parameter from another data source in the Network, what is 
not clear is how real time parameter is correlated with Network KPI information 
within UE.
Also the interface between UE and RAN is not in the scope of ALTO work, I think.
[ [SR] ] definitely, the scope of the extension restricts to exchanges between 
AOS and AOC. The UE may have some agent that gathers and relates the RAN 
indicators and the ALTO information and passes the relevant costs to the 
application client. Again this agent is out of scope of ALTO.

This use-case is illustrated in the slides presented at the previous IETF 109 
ALTO WG meeting, see (1), slide 4. A preliminary design with example IRD and 
ALTO request and response can be found in slides 7 and 8.

Any feedback is more than welcome,
(1)  
https://datatracker.ietf.org/meeting/109/materials/slides-109-alto-proposed-recharter-item-general-alto-protocol-extensions-00
Thanks,
Sabine



From: alto mailto:alto-boun...@ietf.org>> On Behalf Of 
Qin Wu
Sent: Monday, February 22, 2021 2:51 PM
To: IETF ALTO mailto:alto@ietf.org>>
Cc: alto-cha...@ietf.org<mailto:alto-cha...@ietf.org>; 
alto-...@ietf.org<mailto:alto-...@ietf.org>
Subject: [alto] ALTO Draft ReCharter WG review

Hi, :
We have requested one hour session for ALTO WG meeting in the upcoming IETF 
110, which is arranged on Friday, March 12, 14:30-15:30(UTC).
The goal is to boil down ALTO recharter and have consensus on charter contents 
in IETF 110.
To get this goal, an updated inline draft charter text for ALTO has just been 
posted to this list,

This charter has received a couple of rounds of informal review from WG 
members, chairs and our Ads from brief to deep thorough, 5 new chartered items 
have been listed.
We would like to solicit feedback on these new chartered items and your use 
case, deployment, idea corresponding to these new chartered items.
Sharing your past deployment story will also be appreciated.


The ALTO working group was established in 2008 to devise a request/response 
protocol to allow a host to benefit from a server that is more cognizant of the 
network infrastructure than the host is.

The working group has developed an HTTP-based protocol and recent work has 
reporte

Re: [alto] ALTO Draft ReCharter WG review - extensible set of policy attributes

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

Hello ALTO WG,

Regarding the proposed work item on "Protocol extensions to support a richer 
and extensible set of policy attributes in ALTO information update request and 
response" (GPE for short) , I would like to add the following:

This work item can be useful, among others, to allow a UE getting cellular 
network KPIs from an ALTO Server, to figure out for example whether the cell is 
congested, or which cell to choose.

An ALTO Server cannot provide real-time information. With the proposed 
extensions, it can indicate a number of real-time network parameters against 
which ALTO cost values can be modulated.

These parameters are received by UEs directly from the network and not from 
ALTO. The UE receives an array of ALTO cell KPI values that each depend on the 
value of a parameter. The UE can pick the  ALTO value corresponding to the 
value of the real-time parameter received from the network. Thus, the UE 
modulates the received ALTO values in real-time.

This use-case is illustrated in the slides presented at the previous IETF 109 
ALTO WG meeting, see (1), slide 4. A preliminary design with example IRD and 
ALTO request and response can be found in slides 7 and 8.

Any feedback is more than welcome,
(1)  
https://datatracker.ietf.org/meeting/109/materials/slides-109-alto-proposed-recharter-item-general-alto-protocol-extensions-00
Thanks,
Sabine



From: alto  On Behalf Of Qin Wu
Sent: Monday, February 22, 2021 2:51 PM
To: IETF ALTO 
Cc: alto-cha...@ietf.org; alto-...@ietf.org
Subject: [alto] ALTO Draft ReCharter WG review

Hi, :
We have requested one hour session for ALTO WG meeting in the upcoming IETF 
110, which is arranged on Friday, March 12, 14:30-15:30(UTC).
The goal is to boil down ALTO recharter and have consensus on charter contents 
in IETF 110.
To get this goal, an updated inline draft charter text for ALTO has just been 
posted to this list,

This charter has received a couple of rounds of informal review from WG 
members, chairs and our Ads from brief to deep thorough, 5 new chartered items 
have been listed.
We would like to solicit feedback on these new chartered items and your use 
case, deployment, idea corresponding to these new chartered items.
Sharing your past deployment story will also be appreciated.


The ALTO working group was established in 2008 to devise a request/response 
protocol to allow a host to benefit from a server that is more cognizant of the 
network infrastructure than the host is.

The working group has developed an HTTP-based protocol and recent work has 
reported large-scale deployment of ALTO based solutions supporting applications 
such as content distribution networks (CDN).

ALTO is now proposed as a component for cloud-based interactive applications, 
large-scale data analytics, multi-cloud SD-WAN deployment, and distributed
computing. In all these cases, exposing network information such as abstract 
topologies and network function deployment location helps applications.

To support these emerging uses, extensions are needed, and additional 
functional and architectural features need to be considered as follows:

o Protocol extensions to support a richer and extensible set of policy 
attributes in ALTO information update request and response. Such policy 
attributes may indicate information dependency (e.g., ALTO path-cost/QoS 
properties with dependency on real-time network  indications), optimization 
criteria (e.g., lowest latency/throughput network performance objective), and 
constraints (e.g., relaxation bound of optimization criteria, domain or network 
node to be traversed, diversity and redundancy of paths).

o Protocol extensions for facilitating operational automation tasks and 
improving transport efficiency. In particular, extensions to provide "pub/sub" 
mechanisms to allow the client to request and receive a diverse types (such as 
event-triggered/sporadic, continuous), continuous, customized feed of 
publisher-generated information. Efforts developed in other working groups such 
as MQTT Publish / Subscribe Architecture, WebSub, Subscription to YANG 
Notifications will be considered, and issues such as scalability (e.g., using 
unicast or broadcast/multicast, and periodicity of object updates) should be 
considered.

o The working group will investigate the configuration, management, and 
operation of ALTO systems and may develop suitable data models.

o Extensions to ALTO services to support multi-domain settings. ALTO is 
currently specified for a single ALTO server in a single administrative domain, 
but a network may consist of
multiple domains and the potential information sources may not be limited to a 
certain domain. The working group will investigate extending the ALTO framework 
to (1) specify multi-ALTO-server protocol flow and usage guidelines when an 
ALTO service involves network paths spanning multiple domains with multiple

Re: [alto] I-D Action: draft-ietf-alto-unified-props-new-16.txt

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

Hi Vijay,

Thanks a lot. In the meantime, we will provide you with inline responses to 
your review and considerations on review comments that need further discussions.
Thanks,
Sabine

From: Vijay Gurbani 
Sent: Saturday, February 27, 2021 9:18 PM
To: Randriamasy, Sabine (Nokia - FR/Paris-Saclay) 

Cc: alto@ietf.org
Subject: Re: [alto] I-D Action: draft-ietf-alto-unified-props-new-16.txt

Dear Sabine: Thank you.  I will look over the changes and move the draft ahead.
I plan to do so next week.
- vijay

On Mon, Feb 22, 2021 at 6:49 PM Randriamasy, Sabine (Nokia - FR/Paris-Saclay) 
mailto:sabine.randriam...@nokia-bell-labs.com>>
 wrote:
Dear all,

This version 16 addresses most of Vijay's review comments part 1 and 2.
We will come back in a few days with details on how the comments have been 
addressed.
Thanks,
Sabine

>-Original Message-
>From: alto mailto:alto-boun...@ietf.org>> On Behalf Of 
>internet-dra...@ietf.org<mailto:internet-dra...@ietf.org>
>Sent: Tuesday, February 23, 2021 1:01 AM
>To: i-d-annou...@ietf.org<mailto:i-d-annou...@ietf.org>
>Cc: alto@ietf.org<mailto:alto@ietf.org>
>Subject: [alto] I-D Action: draft-ietf-alto-unified-props-new-16.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 extension: Entity Property Maps
>Authors : Wendy Roome
>  Sabine Randriamasy
>  Y. Richard Yang
>  Jingxuan Jensen Zhang
>  Kai Gao
>   Filename: draft-ietf-alto-unified-props-new-16.txt
>   Pages   : 57
>   Date: 2021-02-22
>
>Abstract:
>   This document extends the base Application-Layer Traffic Optimization
>   (ALTO) Protocol by generalizing the concept of "endpoint properties"
>   as applied to endpoints as defined by IP addresses to endpoints
>   defined by a wider set of objects.  Further, these properties are
>   presented as maps, similar to the network and cost maps in the base
>   ALTO protocol.  The protocol is extended in two major directions.
>   First, from endpoints restricted to IP addresses to entities covering
>   a wider and extensible set of objects; second, from properties on
>   specific endpoints to entire entity property maps.  These extensions
>   introduce additional features allowing entities and property values
>   to be specific to a given information resource.  This is made
>   possible by a generic and flexible design of entity and property
>   types.
>
>
>The IETF datatracker status page for this draft is:
>https://datatracker.ietf.org/doc/draft-ietf-alto-unified-props-new/
>
>There are also htmlized versions available at:
>https://tools.ietf.org/html/draft-ietf-alto-unified-props-new-16
>https://datatracker.ietf.org/doc/html/draft-ietf-alto-unified-props-new-16
>
>A diff from the previous version is available at:
>https://www.ietf.org/rfcdiff?url2=draft-ietf-alto-unified-props-new-16
>
>
>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<http://tools.ietf.org>.
>
>Internet-Drafts are also available by anonymous FTP at:
>ftp://ftp.ietf.org/internet-drafts/
>
>
>___
>alto mailing list
>alto@ietf.org<mailto:alto@ietf.org>
>https://www.ietf.org/mailman/listinfo/alto

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

Re: [alto] I-D Action: draft-ietf-alto-unified-props-new-16.txt

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

Dear all,

This version 16 addresses most of Vijay's review comments part 1 and 2. 
We will come back in a few days with details on how the comments have been 
addressed.
Thanks,
Sabine 

>-Original Message-
>From: alto  On Behalf Of internet-dra...@ietf.org
>Sent: Tuesday, February 23, 2021 1:01 AM
>To: i-d-annou...@ietf.org
>Cc: alto@ietf.org
>Subject: [alto] I-D Action: draft-ietf-alto-unified-props-new-16.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 extension: Entity Property Maps
>Authors : Wendy Roome
>  Sabine Randriamasy
>  Y. Richard Yang
>  Jingxuan Jensen Zhang
>  Kai Gao
>   Filename: draft-ietf-alto-unified-props-new-16.txt
>   Pages   : 57
>   Date: 2021-02-22
>
>Abstract:
>   This document extends the base Application-Layer Traffic Optimization
>   (ALTO) Protocol by generalizing the concept of "endpoint properties"
>   as applied to endpoints as defined by IP addresses to endpoints
>   defined by a wider set of objects.  Further, these properties are
>   presented as maps, similar to the network and cost maps in the base
>   ALTO protocol.  The protocol is extended in two major directions.
>   First, from endpoints restricted to IP addresses to entities covering
>   a wider and extensible set of objects; second, from properties on
>   specific endpoints to entire entity property maps.  These extensions
>   introduce additional features allowing entities and property values
>   to be specific to a given information resource.  This is made
>   possible by a generic and flexible design of entity and property
>   types.
>
>
>The IETF datatracker status page for this draft is:
>https://datatracker.ietf.org/doc/draft-ietf-alto-unified-props-new/
>
>There are also htmlized versions available at:
>https://tools.ietf.org/html/draft-ietf-alto-unified-props-new-16
>https://datatracker.ietf.org/doc/html/draft-ietf-alto-unified-props-new-16
>
>A diff from the previous version is available at:
>https://www.ietf.org/rfcdiff?url2=draft-ietf-alto-unified-props-new-16
>
>
>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.
>
>Internet-Drafts are also available by anonymous FTP at:
>ftp://ftp.ietf.org/internet-drafts/
>
>
>___
>alto mailing list
>alto@ietf.org
>https://www.ietf.org/mailman/listinfo/alto

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

Re: [alto] Chair review of path-vector-13 (Part 2 of 2)

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

Hi Vijay,

Thanks a lot for your Part 1 and 2 thorough reviews and wise guidance.
We will get back with our proposed responses and updates.
Best regards,
Sabine


From: Vijay Gurbani 
Sent: Wednesday, February 10, 2021 5:23 PM
To: draft-ietf-alto-path-vec...@ietf.org
Cc: IETF ALTO 
Subject: Chair review of path-vector-13 (Part 2 of 2)

Dear Authors: This part concludes my chair review of path-vector, an important 
ALTO extension.  Thank you for your work on this document.  I hope the comments 
in this part and the first part help position the document better.

Chair review from Section 7 to the end of the document.
Part 2 of 2.

Global comment: Please turn all "Content-Length: [TBD]" into "Content-Length: 
XXX", where "XXX" is the computed content length.

Major:

- S7.1.3: When you first get into JSON object declarations, you should point 
the reader to S8.2 of RFC7285, where the semantics related to the syntax used 
to declare ALTO JSON objects is defined.  This will help new implementers who
pick up this manuscript and need to understand where the declaration syntax, 
and previously declared JSON ALTO objects, like ReqFilteredCostMap, reside.

- S8.3: I think the ALTO response deserves a longer explanation here.  Let me 
see if I understand correctly: the cost map returns two properties: NET1 and 
AGGR.  On NET1, the max reservable bandwidth is 50 Gb (or GB?), i.e., inside 
the NET1 abstraction of Figure 5, the max reservable bandwidth is much higher 
than the link bandwidth.  For the AGGR (BTW, what does AGGR stand for?  Minimum 
aggregate bandwidth?), the max reservable bandwidth is 10 Gbps, which is the 
bandwidth of L1.  Yes?  Please expand the explanation in the document to be as 
explicit as you can.

Further, my suggestion would be to show the NET1 and AGGR from source 2.3.4.5 
to destination 4.5.6.1, because that will necessarily include traversing two 
links, L1 and L2.  What would be the AGGR there?

- S9.2: I am not sure what the prescription here is.  Whatever it is, it needs 
to be (a) explicit, and (b) stronger.  Current text says that this document 
does not "specify" the use of path vector cost type with RFC 8189.  Why does it 
not specify this?  Is it because such integration is not possible?  In which 
case, the document should say so.  Or is it because the authors have not 
studied whether such integration makes sense and can be supported in a backward 
compatible manner?  If so, well, say so.  Or is it because such integration is 
not possible at all?  If so, say so.  This is a protocol document, we need to 
be as unambiguous as possible.  (S9.3 is a good example of drawing a line in 
the sand.)

- S10.2: Not sure why the MAY is normative here.  This paragraph should be 
re-written in its entirety; it reads more like a draft set of notes than 
something well thought out.

- S11, last paragraph: I am not sure what "intolerable increment of the 
server-side storage" means here.  Isn't the issue more along the lines of 
spending CPU cycles doing path computation rather than storage requirements? 
Conflating "storage" here does not seem to be warranted, but perhaps I am 
mistaken.  Please advise.

Further, the text says, "To avoid this risk, authenticity and authorization of 
this ALTO service may need to be better protected." ==> I am unsure how this 
helps.  The ALTO server has no means to authenticate the client, nor does it 
have any means to know whether the client is authorized to send it a request.  
Consequently, the best it can do to protect itself is to monitor client 
behaviour and stop accepting requests if the client misbehaves (sends same 
requests frequently, sends requests with small deltas frequently, or it can ask 
the client to solve some puzzle before submitting a request, etc.).  But 
generally, this class of resource exhaustion attacks are hard to defend 
against, and I am not sure that we will come up with something that is 
definitely prescriptive here.  But we should structure the discussion such that 
it appears that we have thought of the issues here.

Minor:

- S7.1.6, bullet item "The Unified Property Map part MUST also include 
"Resource-Id" and "Content-Type" in its header." ==> Doesn't the unified-props 
I-D already mandate this?  If so, why repeat it here?

- S9: I would suggest changing the title to "Compatibility with other ALTO 
extensions"

- S10.1, paragraph 3: I would suggest the following re-write for this paragraph:

"In practice, developing a bespoke language for general-purpose boolean tests 
can be a complex undertaking, and it is conceivable that there are some 
existing implementations already (the authors have not done an exhaustive 
search to determine whether there are such implementations).  One avenue to 
develop such a language may be to explore extending current query languages 
like XQuery or JSONiq and integrating these with ALTO."

(Please provide references for XQuery and JSONiq.)

Nits:

- S8.1: s/The example ALTO server provides/

Re: [alto] Chair review of unified-props (Part 2 of 2)

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

Hi Vijay,

Thanks a lot again for part 2 of your review.
We will pay particular attention to your major points,
that indeed require to update the specifications.
Best regards,
Sabine


From: Vijay Gurbani 
Sent: Wednesday, January 27, 2021 5:28 PM
To: draft-ietf-alto-unified-props-...@ietf.org
Cc: IETF ALTO 
Subject: Chair review of unified-props (Part 2 of 2)

Chair review from Section 5 - end (inclusive).

Please go through the Major review points, they require some attention.

This concludes my review of this document.  Overall a well-written document
covering a range of important extensions to ALTO.

Major:

- S5.1.1: "The '.' separator MUST NOT be used unless specifically indicated in a
further extension document." ==> I don't understand this.  If the '.' must not
be used, then this should be an absolute condition (MUST NOT is the normative
strength in the sentence).  If this document allows the '.' to be used in a
further extension document, then this is a relative --- not absolute ---
condition, and thus a normative SHOULD NOT seem to be better.  However, as
currently written, this sentence seems rather wishy-washy.  Either say '.' is
out of bounds or say it is not, it seems weird to say that this document does
not use it, but others can.

One way to achieve this is to replace that sentence with:

  The '.' separator is not used by this document, however, future
  extensions may use it.  For the purpose of this document, the
  strings "ipv4", "ipv6", and "pid" are valid entity domain
  types, while "ipv4.anycast", and "pid.local" are invalid.

However, even then, I am not sure if the above is correct.  Later, in S5.1.2,
you go on to say that "Note that the '.' separator is not allowed in
EntityDomainType and hence there is no ambiguity on whether an entity domain
name refers to a resource-agnostic entity domain or a resource-specific entity
domain."  Thus it seems to me that future extensions could run into trouble if
they allow '.' in the EntityDomainType.

This needs to be resolved before publication.

- S5.1.2, last paragraph: "Note that the resource ID format defined in Section
10.1 of [RFC7285]..." ==> Section 10.1 of RFC 7285 defines "PID Name", not
"Resource ID", which is defined in the next section.  Please clarify.

- S9.1: "...it is RECOMMENDED that the EPS be deprecated in favour of ..." ==>
This is very important: If this draft is recommending a change in RFC 7285, then
the status of this draft must say "Updates: 7285" at the top of the draft (it
currently does not).  This will cause the RFC Editor to enter a "Updated by:
RFC" in the masthead of RFC7285.

Further, I presume that since this update is a recommendation, the processing
rules of property map and filtered property map are distinct enough that legacy
ALTO servers and clients will continue operations?  Please advise.

- S9.3: What does "little or no impact on other previously defined properties"
mean?  Again, this appears wishy-washy for a standards document.  Either we know
that there is some impact, and we document what the impact is, or we state that
there is no impact.  But saying "little or no impact" is not helpful.  Please
state where there is impact and whether this impact will cause backwards
compatibility problems.

I note that S12.2.1 further expands on this "little or no impact".  Perhaps a
second order look at S9.3 is in order before publication to document the impacts
on previously defined properties.

- S10: Please fill in all of the "###" for "Content-Length: ###" in all
examples.

- S11: Did anyone in the WG do a threat analysis of the information exposed by
the property maps related to, say, domain type "ane"?  As the example in S10.9
demonstrates, there is a lot of information in the returned response that will
be of interest to malicious actors.

I note that there is a blanket paragraph in this section ("A particular
fundamental ... URI to provide the information.") that appears to address such a
scenario, but I don't see a well thought out threat-model that drives the
discussion in this section.  At the very least, the authors should spend some
time thinking about the information in the property maps and how it may be used
if it fell in the hands of a malicious actor.  If after reflection they come to
the conclusion that the second blanket paragraph outlines a mitigation strategy
that suffices, then that is fine.  Just wanted to make sure that the authors
have spent some time here.

Minor:

- S5.1.3, last paragraph: I think you should append the following sentence to
the paragraph:

  Such equivalences should be established by the object represented
  by DomainTypeSpecificEntityID, for example, [RFC5952] establishes
  equivalence for IPv6 addresses, while [RFC4632] does so for IPv4
  addresses.

Nits:

- Please run idnits; currently, it is reporting 3 errors having to do with using
obsoleted references (RFCs 5226 and 7159) and a downref (RFC 7921).

Thanks,

- vijay
__

Re: [alto] Chair review of unified-props (Part 1 of 2)

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

Hi Vijay,

Great thanks for your thorough review and guidance.
We will attend to your comments and get back with our proposed updates.
Best regards,
Sabine

From: Vijay Gurbani 
Sent: Tuesday, January 26, 2021 5:06 PM
To: draft-ietf-alto-unified-props-...@ietf.org
Cc: IETF ALTO 
Subject: Chair review of unified-props (Part 1 of 2)

All: My apologies for the late start on the chair reviews of the documents I am 
shepherding.  However, I have started the review.

Below is the first (of two parts) review of unified-props.  This review 
includes all sections from Abstract to Section 4.7.1 (inclusive).

Please let me know if you have any questions.  I will post the second part 
tomorrow.

Chair review from Abstract - Section 4.7.1 (inclusive).

Major:

- Abstract: "...by generalizing the concept of "endpoint properties" to generic
type of entities..." ==> Note that the antecedent ("endpoint properties") and
the consequent ("type of entities") do not match.  Perhaps better to say: "...by
generalizing the concept of "endpoint properties" as applied to endpoints
defined by IP addresses to endpoints a wider set of objects..."

More concretely:

OLD:
This document extends the base Application-Layer Traffic Optimization
(ALTO) Protocol by generalizing the concept of "endpoint properties"
to generic types of entities, and by presenting those properties as
maps, similar to the network and cost maps in the base ALTO protocol.

NEW:
This document extends the base Application-Layer Traffic Optimization
(ALTO) Protocol by generalizing the concept of "endpoint properties"
as applied to endpoints as defined by IP addresses to endpoints defined
by a wider set of objects.  Further, these properties are presented
as maps, similar to the network and cost maps in the base ALTO protocol.

- S3.2.1: "An entity domain type is expected to be registered at the IANA" ==>
you mean "MUST be registered with IANA"?  Or "SHOULD be registered with IANA"?
Best to use normative language here, unless you have a specific reason not
to.

- S3.2.2: What does this mean: "As a consequence, entities in such
domains may be defined in a resource handling this domain type but
not in other resources handling this same domain type."?  I am unable to
parse this, I think you are saying that of all the resources handling a
particular domain type, the entity must be defined in only one of them.  If
so, perhaps best to reword; something like:
   OLD:
   As a consequence, entities in such domains may be defined in a
   resource handling this domain type but not in other resources handling
   this same domain type.
   NEW:
   As a consequence, of all the resources defining a particular domain
   type, the entity must be defined in only one resource.

- S4.2.2, first paragraph: Is this example valid?  From my experience, ASN's
contain IPv4 addresses defined by a CIDR block.  I think it is highly unlikely
that a service provider will define a CIDR block 
(192.0.1.0/24) and have that
block span ASNs, but perhaps I am mistaken.  Perhaps someone from network
operations may want to look at this example and bless it, or if you are sure
that networks are architected in such a manner, then we can let it stay.

- S4.6.2: "When an ANE has a persistent identifier, say, "entity-4", the
latter", here what do you mean by "latter"?  In this sentence, I do not see two
things that can be characterized as "former" and "latter"...?

- S4.7.1: This subsection appears as an afterthought; it is not "defining
resource media-types" as much as simply "listing resource media-types".  It does
not appear to be comprehensive since it only includes two examples, which leads
me to think that perhaps these examples are best put in parts of the text that
refer to these property types.  Furthermore, the media type for property "pid"
is already defined in RFC7285, so if you want to give an example here, simply
refer to RFC7285 for it.  And, the media type "alto-cdnifci+json" is defined in
draft-ietf-alto-cdni-request-routing-alto, not in this section.  My advice would
be to remove this subsection, I don't think it is comprehensive and just adds to
the confusion.

Minor:
- S3.1: in the bullet items, please be consistent when using "IPv4 or IPv6"
versus "ipv4 or ipv6".  Both forms are used, best to choose one and be
consistent in the section.  (I recognize that lower case "ipv4" and "ipv6" are
used elsewhere in the document to define entity domains, that is okay; just be
consistent in S3.1.)

- S3.1, last bullet item: What os a "routable network node"?  Is a network node
that performs the routing function (a router)?  or is it a network node that is
the recipient of a packet routed to it (an endpoint)?

- S4.4.3: s/sets in the upper level./subsets./
Rationale: "Upper level" of a set consists of elements that are subsets. Since
you are using set theory here, perhaps best to use nomenclature in that
domain.  (You may edit it as "subsets (upper levels)." if that helps.

- S4.4.3: S

[alto] FW: I-D Action: draft-ietf-alto-unified-props-new-15.txt

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

Dear Vijay, Jan and Qin

The new version 15 below fully addresses the review comments and now includes a 
"navigation table" listing the new features and the section describing them. 
This table stressed the need to change some section titles for more coherency.
Additionally, upon discussions with Qin,  Wendy and co-authors, the document 
title has now been changed to "ALTO extension: Entity Property Maps". 
The document section titles and text have been updated to harmonize with the 
document title. 
Other minor updates have been added to further address the need for 
clarification reflected in the reviews. 

The updates done on v14 to produce v15 are listed in the attached text file 
"v15-updates-2611.txt". 

We feel the document is now ready for WG chair review and look forward to 
getting review feedback. 

Thanks,
Sabine, Jensen, Richard, Kai

-Original Message-
From: alto  On Behalf Of internet-dra...@ietf.org
Sent: Thursday, November 26, 2020 8:15 PM
To: i-d-annou...@ietf.org
Cc: alto@ietf.org
Subject: [alto] I-D Action: draft-ietf-alto-unified-props-new-15.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 extension: Entity Property Maps
Authors : Wendy Roome
  Sabine Randriamasy
  Y. Richard Yang
  Jingxuan Jensen Zhang
  Kai Gao
Filename: draft-ietf-alto-unified-props-new-15.txt
Pages   : 57
Date: 2020-11-26

Abstract:
   This document extends the base Application-Layer Traffic Optimization
   (ALTO) Protocol by generalizing the concept of "endpoint properties"
   to generic types of entities, and by presenting those properties as
   maps, similar to the network and cost maps in the base ALTO protocol.
   The protocol is extended in two major directions.  First, from
   endpoints restricted to IP addresses to entities covering a wider and
   extensible set of objects; second, from properties on specific
   endpoints to entire entity property maps.  These extensions introduce
   additional features allowing entities and property values to be
   specific to a given information resource.  This is made possible by a
   generic and flexible design of entity and property types.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-alto-unified-props-new/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-alto-unified-props-new-15
https://datatracker.ietf.org/doc/html/draft-ietf-alto-unified-props-new-15

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-alto-unified-props-new-15


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.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


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

---
UPDATES
---

-- Document title: changed  
ALTO extension: Entity Property Maps
Can also be ALTO Entity Property Maps for more simplicity

Harmonized Section titles and text with new document title. 

-- Terminology
Section 2. Terminology
added: This document uses the following terms and abbreviations, that will be 
further defined in the document.
  While this document introduces the feature "entity property map", it will use 
both the term "property map"  
  and "entity property map" to refer to this feature.
added: EPM 

-- "feature navigation table" and related text

3.  Basic Features of the Unified Property Extension
has a new last paragraph mentioning the section (Annex A) providing the  
navigation table (4)

The Entity Property Maps extension described in this document
   introduces a number of features that are summarized in 
   , where 
lists the features and references 
   the sections in this document that give a high-level and normative
   description thereof. 

Annex A: table is as follows (with real xrefs)

 

Entity  3.1 5.1.3 
Entity domain (ED)  3.2
ED type 3.2.1   5.1.1 
ED name 3.2.2   5.1.2
Entity property (EP) type   3.3 5.2, 5.2.1, 5.2.2, 5.2.3,  
Entity property map 3.4 7, 8
resource-specific ED name   4.2 5.1.2, 5.1.2.1
resource-specific EP value  4.3 5.2.3
defining information resource   4.6,12.2.2, 
4.7 12.3


-- Errors and warnings
Abstract: removed [references] and replaced by text 
Added text of e-mail sent to Wendy, Qin a

Re: [alto] Unified properties terminology clarification

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

Hi Wendy and Qin,

Along your lines, my take is that this document extends the protocol in two 
major directions:
- from endpoints restricted to IP addresses to entities covering a wider and 
extensible set of objects,
- from properties on specific endpoints to entire entity property maps.
The document introduces additional features allowing entities and property 
values to be specific to a given information resource. This is made possible by 
a generic and flexible design of entity and property types.

So we may entitle the document w.r.t. the two major evolutions.
Do you think that the title  “ALTO extension: entity property maps” is suitable?
@ Richard and Kai: what is your opinion?

Thanks,
Sabine


From: alto  On Behalf Of Wendy Roome
Sent: Thursday, November 19, 2020 5:19 PM
To: Qin Wu ; alto@ietf.org
Subject: Re: [alto] Unified properties terminology clarification

Hi, Qin!

I'm Wendy Roome, and I wrote the original version of this draft. I stopped 
being active in this group after I retired in 2017, but I can describe the 
motivation for the title.

Back then, we had "costs" between pairs of "entities," and we were expanding 
the concept of "entities" to include more than just PIDs & IP addresses. We 
also had GET requests to return entire maps, and POST requests to return a 
filtered subset.

We also had a property service, but it was very restricted: it only applied to 
endpoints, it could not be extended, and it only allowed POST requests for 
specific endpoints rather than GET requests for an entire set. Furthermore, 
when I implemented the protocol, I suspected that many "properties" would 
really be associated with CIDRs or PIDs, rather than individual endpoints, and 
the endpoints would inherit those properties.

My goals were to make "properties" as extensible as costs, to provide the same 
choice of GET-mode for complete maps and POST requests for subsets, and to 
define an inheritance mechanism. That is, I wanted to "unify" properties and 
costs. Hence the original title. If that name no longer fits, by all means 
change it!

- Wendy Roome

From: alto mailto:alto-boun...@ietf.org>> on behalf of 
Qin Wu mailto:bill...@huawei.com>>
Date: Thu, November 19, 2020 at 07:33
To: "alto@ietf.org" mailto:alto@ietf.org>>
Subject: [alto] Unified properties terminology clarification

Hi, Sabine:
Follow up our discussion in today’s ALTO session, one issue I raised is about 
the terminology we used in the unified properties draft. I feel the term 
“unified properties” lacks clarity and causes a little bit confusion to people 
who are familiar with this draft, that is on is unified property break existing 
protocol or component such as
Endpoint property, I am wondering if we can change the term into property Map, 
so the title will be changed into “ALTO extension: Property Map” , which is 
also align with the title of Path vector draft, Does this make sense?
As you mentioned, this was discussed in the past, can you remind me the history 
discussion why the current name is picked. Thanks in advance, hope we can 
resolve this as soon as possible.

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

Re: [alto] ALTO recharter: proposed item - General ALTO protocol extensions

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

Hi Luis,

Thanks a lot for your feedback, please see inline
Best regards,
Sabine

From: LUIS MIGUEL CONTRERAS MURILLO 
Sent: Tuesday, November 17, 2020 11:41 PM
To: Randriamasy, Sabine (Nokia - FR/Paris-Saclay) 
; IETF ALTO 
Subject: RE: ALTO recharter: proposed item - General ALTO protocol extensions

Hi Sabine,

Some few comments, that have been actually mentioned by me during this weekly 
ALTO regular call.

.- I think the General Protocol Extension item for re-charter is a good place 
holder for maintenance and improvements of current protocol. For instance, I 
think that aspects such as the use of BGP communities (see 
draft-contreras-alto-bgp-communities) fits well in some item like this.
[ [SR] ] agree, there may be other necessary "general extensions". The proposed 
item does not mean to be restrictive.

.- Regarding the text itself, I do foresee use cases that could apply e.g. 
indications of SLA characteristics for discriminating the information 
retrieved. For instance, applications tolerant to the delay (e.g. database 
backups) could receive different information from those time critical.
[ [SR] ] agree, SLA and delay tolerant applications are mentioned in the 
presentation.

Hope this is aligned with your view.

Best regards,

Luis

De: alto mailto:alto-boun...@ietf.org>> En nombre de 
Randriamasy, Sabine (Nokia - FR/Paris-Saclay)
Enviado el: lunes, 16 de noviembre de 2020 18:36
Para: IETF ALTO mailto:alto@ietf.org>>
Asunto: Re: [alto] ALTO recharter: proposed item - General ALTO protocol 
extensions

Hello,

Please find below a revision of the proposed definition paragraph.
This WG item is further detailed in the Google doc available here (page 19/25):
https://docs.google.com/document/d/1qP9jf-CMXvNiEE3YAnApTczAE4QkBW23Q1Eg99uOaEQ/edit

Thanks,
Sabine


General protocol extensions to convey a richer set of attributes allowing to 
determine not only "where" and "when" to connect but also under which 
conditions. Such additional information will be related both to entities (e.g. 
conveying time-averaged server load in data center supported applications) and 
to path costs (e.g. ALTO path cost value depending on conditions such as 
real-time network indications or SLA or policy or access-type or indicator 
type).

The working group will specify such extension in coordination with both other 
ALTO working group items and IETF working groups that have a focus on the 
related use cases.  The scope of extensions is not limited to those identified 
by the WIs and WGs, but is limited by the criteria set out below.
--------------------


From: Randriamasy, Sabine (Nokia - FR/Paris-Saclay) 
mailto:sabine.randriam...@nokia-bell-labs.com>>
Sent: Monday, November 16, 2020 6:16 PM
To: Randriamasy, Sabine (Nokia - FR/Paris-Saclay) 
mailto:sabine.randriam...@nokia-bell-labs.com>>;
 IETF ALTO mailto:alto@ietf.org>>
Subject: RE: ALTO recharter: proposed item - General ALTO protocol extensions

Dear all,

The paragraph below is proposed to define the WG item on "general protocol 
extensions".
As the purpose of this work item is also to support other WG items that may 
need these extensions, your feedback again is more than welcome.
Thanks,
Sabine

General protocol extensions to convey a richer set of cost attributes allowing 
to determine not only "where" and "when" to connect but also under which 
conditions. Such additional information will be related both to entities (e.g. 
conveying time-averaged (cache storage capacities and)  server load in data 
center supported applications) and to ALTO path costs (e.g. ALTO path cost 
value depending on conditions such as real-time network indications or SLA or 
policy or access-type or indicator type).

The working group will specify such extension in coordination with both other 
ALTO working group items and IETF working groups that have a focus on the 
related use cases.  The scope of extensions is not limited to those identified 
by the WIs and WGs, but is limited by the criteria set out below.
----------------

From: alto mailto:alto-boun...@ietf.org>> On Behalf Of 
Randriamasy, Sabine (Nokia - FR/Paris-Saclay)
Sent: Tuesday, November 10, 2020 7:24 PM
To: IETF ALTO mailto:alto@ietf.org>>
Subject: [alto] ALTO recharter: proposed item - General ALTO protocol extensions

Dear all,

Please find below a WG item proposal for "general ALTO protocol extensions", on 
which your feedback and suggestions will be more than welcome.
Thanks,
Sabine

-- Context: the current ALTO charter
o Extends the path cost values in several directions:
  - single to array of several cost metrics => allows apps to 
decide upon several metrics and make decision compromise
  - single cost value to array if time dependent cost values => 
allow apps

Re: [alto] ALTO recharter: proposed item - General ALTO protocol extensions

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

Hi Qin,

Thanks a lot for your feedback,
The text and slide deck presenting the proposed re-charter item hopefully 
address your comments.
Please see inline.
Best regards,
Sabine

From: Qin Wu 
Sent: Tuesday, November 17, 2020 4:33 AM
To: Randriamasy, Sabine (Nokia - FR/Paris-Saclay) 
; IETF ALTO 
Subject: RE: ALTO recharter: proposed item - General ALTO protocol extensions

Hi, Sabine:
Thanks for the update on the proposed item.
See my comments inline.
发件人: alto [mailto:alto-boun...@ietf.org] 代表 Randriamasy, Sabine (Nokia - 
FR/Paris-Saclay)
发送时间: 2020年11月17日 1:16
收件人: Randriamasy, Sabine (Nokia - FR/Paris-Saclay) 
mailto:sabine.randriam...@nokia-bell-labs.com>>;
 IETF ALTO mailto:alto@ietf.org>>
主题: Re: [alto] ALTO recharter: proposed item - General ALTO protocol extensions

Dear all,

The paragraph below is proposed to define the WG item on “general protocol 
extensions”.
As the purpose of this work item is also to support other WG items that may 
need these extensions, your feedback again is more than welcome.
Thanks,
Sabine

General protocol extensions to convey a richer set of cost attributes allowing 
to determine not only "where" and "when" to connect but also under which 
conditions. Such additional information will be related both to entities (e.g. 
conveying time-averaged (cache storage capacities and)  server load in data 
center supported applications) and to ALTO path costs (e.g. ALTO path cost 
value depending on conditions such as real-time network indications or SLA or 
policy or access-type or indicator type).

The working group will specify such extension in coordination with both other 
ALTO working group items and IETF working groups that have a focus on the 
related use cases.  The scope of extensions is not limited to those identified 
by the WIs and WGs, but is limited by the criteria set out below.


From: alto mailto:alto-boun...@ietf.org>> On Behalf Of 
Randriamasy, Sabine (Nokia - FR/Paris-Saclay)
Sent: Tuesday, November 10, 2020 7:24 PM
To: IETF ALTO mailto:alto@ietf.org>>
Subject: [alto] ALTO recharter: proposed item - General ALTO protocol extensions

Dear all,

Please find below a WG item proposal for “general ALTO protocol extensions”, on 
which your feedback and suggestions will be more than welcome.
Thanks,
Sabine

-- Context: the current ALTO charter
o Extends the path cost values in several directions:
  - single to array of several cost metrics => allows apps to 
decide upon several metrics and make decision compromise
  - single cost value to array if time dependent cost values => 
allow apps to determine when to connect
o Extends endpoints to entities on which properties are defined
[Qin]:Good, I believe you talk about Path vector, ALTO cost calendar, and 
unified properties which provide a good basis for any new work.
[ [SR] ] indeed
-- Basic Issues
+++  Issue 1: Some path cost values may depend on "contextual parameters" such 
as access type, SLA, policy or other indicators provided by network. In 
particular:
  - There may be different possible paths between source and 
destination, where some paths may or may not meet Application QoE or policy 
constraints. The Applications would like to see which path is most suitable.
  - Contextual parameters may be available at frequencies that are 
different from ALTO information frequency. For example, Cost on PID-Cell1 may 
differ, depending on some real-time network parameter value.
[Qin]: I see this contextual parameter as path constraints,  besides access 
type, SLA, policy, I think end to end latency, packet loss can also see as path 
constraints, which can help select a connection path to meet network 
performance requirements.
[ [SR] ] I think constraints on end to end performance metrics such as latency 
and packet loss may be better supported with filtering constraints on queries 
for path costs. “Contextual parameters” are rather used to “detail” cost values 
wrt the value of a contextual parameter. The expression “Contextual parameters” 
may be indeed ambiguous and is now named “cost attributes” in the proposed 
paragraph, to better distinguish with constraints on metrics.
Also I think the specific intermediate network elements, transit administrative 
domain traversed by the flow identified by source destination pair can also be 
seen as contextual parameter, e.g.,  we have two end to end paths, we can have 
contextual parameter like:
route the path through transit domain A, route the path not through transit 
domain B.
[ [SR] ] this corresponds to the case where several possible paths are 
possible. A context parameter Ptd representing transit domains may indeed be 
used to prevent using a path with prohibitive costs. For instance, 
Cost(Spid,Dpid) = moderate for Ptd = A and very high for Ptd = B.
Such a case should be considered in the

Re: [alto] I-D Action: draft-ietf-alto-unified-props-new-14.txt

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

Hi Vijay,
Thank you for your suggestion. We will prepare the table and upload a v15.
Best regards,
Sabine

From: Vijay Gurbani 
Sent: Tuesday, November 17, 2020 11:58 PM
To: Randriamasy, Sabine (Nokia - FR/Paris-Saclay) 

Cc: alto@ietf.org
Subject: Re: [alto] I-D Action: draft-ietf-alto-unified-props-new-14.txt

Please put the table in the end.  You can have a forward reference to the table 
at the beginning of the I-D to let people know.

I will like to perform a chair/shepherd review on a version that close to being 
a final one.

Thanks.

On Tue, Nov 17, 2020 at 1:15 PM Randriamasy, Sabine (Nokia - FR/Paris-Saclay) 
mailto:sabine.randriam...@nokia-bell-labs.com>>
 wrote:
Dear all,

Version 13 - draft-ietf-alto-unified-props-new-13.txt posted on Nov 2nd 
addresses the review comments of Danny and most comments of Luis. This version 
14 addresses pending comments of the review provided by Luis. The only 
unresolved comment by Luis is providing a table listing the protocol extensions 
and pointing to the relevant sections in the text. Given that the extensions 
are defined progressively, we need to figure out where to place the table in 
the document (beginning or end). Any suggestion is welcome.

I will send separate e-mails to Danny and Luis, to describe how their review 
comments were addressed. Great thanks again to both for the thorough review.
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] Review for draft-ietf-alto-unified-props-new-12

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

Dear Luis,

Thanks a lot for your review. Your comments have been addressed partly in v13 
and v14, except providing a table listing the protocol extensions. I have 
attached a text file that lists your review comments and indicates where they 
were addressed in v13 and v14.
The description text of updates made specifically in V14 starts with  "> IN 
V14".
Please let me know whether the updates meet your expectations.

Best regards,
Sabine


From: alto  On Behalf Of LUIS MIGUEL CONTRERAS MURILLO
Sent: Monday, October 12, 2020 10:44 PM
To: 'alto@ietf.org' 
Subject: [alto] Review for draft-ietf-alto-unified-props-new-12

Dear all,

Please, find here below the review for the Unified Properties draft.

/* General comments */
.- Section 2 - Requirements language - as general comment, the usage of words 
such as MUST, MAY, etc should be reviewed in all of the occurrences in the 
text. In some of them they do not appear in capital letters, so not clear if 
this statements apply or not. Examples of this are: "must" in 2nd paragraph of 
section 3.2; "must" in 2nd paragraph of section 4.1; "may" in 1st paragraph of 
section 4.3; etc.
.- References to the need of registering some items at IANA - it is not clear 
to me if this can be left as it is or if some values have to be proposed in the 
draft, or at least marked in the text with the idea of substituting such marks 
by values once IANA register the items. If that is the case, it would be 
advisable to include (maybe as an annex) a summary table compiling all the 
items that are expected to be registered. Would it not be part of section 12?
.- Along the text it is frequent to find references to other sections before or 
afterwards. Acknowledging that this could be necessary, it would help the 
reader to have some summary table (or any other way, like a figure) where the 
different aspects could be listed beforehand, in such a way that the reader can 
use it as a kind of map for navigating through the document. I understand it is 
not easy, so take it as a suggestion for making the document more readable. For 
instance, some way of showing the relationship among terms in the Terminology 
section.
.- Section 3 presents the basic features of the unified properties while the 
advanced ones are in section 4. How these extensions co-exist? Are they 
incremental? What is the reason from presenting them in separate sections? Is 
it possible to have the basic ones without the advanced features?
.- Both Section 10 and Appendix A present examples. Would not make sense to 
move all he examples either to one place or the other?

/* Particular comments */
.- Section 1 - Introduction, page 4, 2nd paragraph - "... recent ALTO use cases 
show ..." -> it would be good to be more explicit by listing the use cases that 
are being referred to.
.- Section 1 - Introduction, page 5, 1st bullet - fix reference for [REF 
path-vector]
.- Section 1 - Introduction, page 5, 3rd bullet - "... POST-mode... that 
returns ..." -> would not be "sets" instead of "returns"?
.- Section 1 - Introduction, page 5, 1st paragraph - "extensible" -> 
"augmentable" ??
.- Section 1.1 - Terminology - fix the text marked as TBC
.- Section 2 - Requirements language, 1st paragraph - fix the text marked as 
TODO.
.- Section 3, 1st paragraph - The reference to the assumption of familiarity 
with ALTO protocol is redundant with the last sentence of section 1 (just 
before section 1.1 title)
.- Section 3, 1st paragraph - "... ALTO Entities, entities for short" -> "... 
ALTO Entities, or entities for short"
.- Section 3.2.2, 1st paragraph - the sentence "An entity domain name ..." is 
hard to understand. Please, revisit and simplify (maybe shortening or dividing 
it).
.- Section 3.3, 1st paragraph - "Simularly" -> "Similarly"
.- Section 3.3, bullets in page 9 - is there any inventory of registered types? 
Are only those provided here as examples?
.- Section 4.2, penultimate paragraph - "Example resource specific..." -> 
"Example of resource specific..."
.- Section 4.4, 2nd paragraph - it would be interesting to perform queries and 
marking properties that could exclude or filter the entities. For instance to 
get a list of entities compliant with some property but excluding those that 
are compliant with another one.
.- Section 4.4.3, 1st paragraph - "... inherits no more than one property ..." 
<- why not more than one?
.- Section 4.4.3, 1st paragraph, last sentence - how is it applied? It would be 
interesting to add some example.
.- Section 4.5, 1st paragraph - "Therefore an ALTO server ... specifies the 
properties ..." <- how this advertisement is made?
.- Section 4.5, 2nd paragraph - expand IRD as first occurrence in the text.
.- Section 4.5, 2nd bullet - "... a list of the names ..." <- names or types?
.- Section 4.6, 1st paragraph - "To this end, he ..." -> "To this end, the ..."
.- Section 4.6, 1st paragraph - "The syntax of the entity domain identifier ... 
allows the client to infer ..." -> would it not 

Re: [alto] I-D Action: draft-ietf-alto-unified-props-new-14.txt

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

Dear all,

Version 13 - draft-ietf-alto-unified-props-new-13.txt posted on Nov 2nd 
addresses the review comments of Danny and most comments of Luis. This version 
14 addresses pending comments of the review provided by Luis. The only 
unresolved comment by Luis is providing a table listing the protocol extensions 
and pointing to the relevant sections in the text. Given that the extensions 
are defined progressively, we need to figure out where to place the table in 
the document (beginning or end). Any suggestion is welcome. 

I will send separate e-mails to Danny and Luis, to describe how their review 
comments were addressed. Great thanks again to both for the thorough review. 

Best regards,
Sabine

>-Original Message-
>From: alto  On Behalf Of internet-dra...@ietf.org
>Sent: Tuesday, November 17, 2020 12:55 PM
>To: i-d-annou...@ietf.org
>Cc: alto@ietf.org
>Subject: [alto] I-D Action: draft-ietf-alto-unified-props-new-14.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   : Unified properties for the ALTO protocol
>Authors : Wendy Roome
>  Sabine Randriamasy
>  Y. Richard Yang
>  Jingxuan Jensen Zhang
>  Kai Gao
>   Filename: draft-ietf-alto-unified-props-new-14.txt
>   Pages   : 53
>   Date: 2020-11-17
>
>Abstract:
>   This document extends the Application-Layer Traffic Optimization
>   (ALTO) Protocol [RFC7285] by generalizing the concept of "endpoint
>   properties" to generic types of entities, and by presenting those
>   properties as maps, similar to the network and cost maps in
>   [RFC7285].
>
>
>
>The IETF datatracker status page for this draft is:
>https://datatracker.ietf.org/doc/draft-ietf-alto-unified-props-new/
>
>There are also htmlized versions available at:
>https://tools.ietf.org/html/draft-ietf-alto-unified-props-new-14
>https://datatracker.ietf.org/doc/html/draft-ietf-alto-unified-props-new-14
>
>A diff from the previous version is available at:
>https://www.ietf.org/rfcdiff?url2=draft-ietf-alto-unified-props-new-14
>
>
>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.
>
>Internet-Drafts are also available by anonymous FTP at:
>ftp://ftp.ietf.org/internet-drafts/
>
>
>___
>alto mailing list
>alto@ietf.org
>https://www.ietf.org/mailman/listinfo/alto

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

Re: [alto] ALTO recharter: proposed item - General ALTO protocol extensions

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

Hello,

Please find below a revision of the proposed definition paragraph.
This WG item is further detailed in the Google doc available here (page 19/25):
https://docs.google.com/document/d/1qP9jf-CMXvNiEE3YAnApTczAE4QkBW23Q1Eg99uOaEQ/edit

Thanks,
Sabine


General protocol extensions to convey a richer set of attributes allowing to 
determine not only "where" and "when" to connect but also under which 
conditions. Such additional information will be related both to entities (e.g. 
conveying time-averaged server load in data center supported applications) and 
to path costs (e.g. ALTO path cost value depending on conditions such as 
real-time network indications or SLA or policy or access-type or indicator 
type).

The working group will specify such extension in coordination with both other 
ALTO working group items and IETF working groups that have a focus on the 
related use cases.  The scope of extensions is not limited to those identified 
by the WIs and WGs, but is limited by the criteria set out below.
----


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

Sent: Monday, November 16, 2020 6:16 PM
To: Randriamasy, Sabine (Nokia - FR/Paris-Saclay) 
; IETF ALTO 
Subject: RE: ALTO recharter: proposed item - General ALTO protocol extensions

Dear all,

The paragraph below is proposed to define the WG item on "general protocol 
extensions".
As the purpose of this work item is also to support other WG items that may 
need these extensions, your feedback again is more than welcome.
Thanks,
Sabine

General protocol extensions to convey a richer set of cost attributes allowing 
to determine not only "where" and "when" to connect but also under which 
conditions. Such additional information will be related both to entities (e.g. 
conveying time-averaged (cache storage capacities and)  server load in data 
center supported applications) and to ALTO path costs (e.g. ALTO path cost 
value depending on conditions such as real-time network indications or SLA or 
policy or access-type or indicator type).

The working group will specify such extension in coordination with both other 
ALTO working group items and IETF working groups that have a focus on the 
related use cases.  The scope of extensions is not limited to those identified 
by the WIs and WGs, but is limited by the criteria set out below.


From: alto mailto:alto-boun...@ietf.org>> On Behalf Of 
Randriamasy, Sabine (Nokia - FR/Paris-Saclay)
Sent: Tuesday, November 10, 2020 7:24 PM
To: IETF ALTO mailto:alto@ietf.org>>
Subject: [alto] ALTO recharter: proposed item - General ALTO protocol extensions

Dear all,

Please find below a WG item proposal for "general ALTO protocol extensions", on 
which your feedback and suggestions will be more than welcome.
Thanks,
Sabine

-- Context: the current ALTO charter
o Extends the path cost values in several directions:
  - single to array of several cost metrics => allows apps to 
decide upon several metrics and make decision compromise
  - single cost value to array if time dependent cost values => 
allow apps to determine when to connect
o Extends endpoints to entities on which properties are defined

-- Basic Issues
+++  Issue 1: Some path cost values may depend on "contextual parameters" such 
as access type, SLA, policy or other indicators provided by network. In 
particular:
  - There may be different possible paths between source and 
destination, where some paths may or may not meet Application QoE or policy 
constraints. The Applications would like to see which path is most suitable.
  - Contextual parameters may be available at frequencies that are 
different from ALTO information frequency. For example, Cost on PID-Cell1 may 
differ, depending on some real-time network parameter value.

+++ Issue 2: Some entities may have properties whose values change over time. 
For instance, ANEs may have time-varying properties on cloud or networking 
resources

-- Potential solution(s)
+++  To address issue 1 and related : extend cost attributes towards 
conditional values and parameters allowing a better interpretation of the 
received values
- Extension from single cost value to array of values dependent on context 
parameters:
allowing applications to make context-dependent decisions,
allowing also to combine information generated with different time dynamics, 
(freshness)
See examples on 
https://datatracker.ietf.org/doc/slides-98-alto-alto-cost-context/

+++  To address issue 2:
- ALTO Property Calendars to extend a single property value to an array of 
time-dependent property values

-- Remaining issues to be addressed
- How to define cost value attributes?
- How to achieve a light and flexible design?
- How to modera

Re: [alto] ALTO recharter: proposed item - General ALTO protocol extensions

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

Dear all,

The paragraph below is proposed to define the WG item on "general protocol 
extensions".
As the purpose of this work item is also to support other WG items that may 
need these extensions, your feedback again is more than welcome.
Thanks,
Sabine

General protocol extensions to convey a richer set of cost attributes allowing 
to determine not only "where" and "when" to connect but also under which 
conditions. Such additional information will be related both to entities (e.g. 
conveying time-averaged (cache storage capacities and)  server load in data 
center supported applications) and to ALTO path costs (e.g. ALTO path cost 
value depending on conditions such as real-time network indications or SLA or 
policy or access-type or indicator type).

The working group will specify such extension in coordination with both other 
ALTO working group items and IETF working groups that have a focus on the 
related use cases.  The scope of extensions is not limited to those identified 
by the WIs and WGs, but is limited by the criteria set out below.
----

From: alto  On Behalf Of Randriamasy, Sabine (Nokia - 
FR/Paris-Saclay)
Sent: Tuesday, November 10, 2020 7:24 PM
To: IETF ALTO 
Subject: [alto] ALTO recharter: proposed item - General ALTO protocol extensions

Dear all,

Please find below a WG item proposal for "general ALTO protocol extensions", on 
which your feedback and suggestions will be more than welcome.
Thanks,
Sabine

-- Context: the current ALTO charter
o Extends the path cost values in several directions:
  - single to array of several cost metrics => allows apps to 
decide upon several metrics and make decision compromise
  - single cost value to array if time dependent cost values => 
allow apps to determine when to connect
o Extends endpoints to entities on which properties are defined

-- Basic Issues
+++  Issue 1: Some path cost values may depend on "contextual parameters" such 
as access type, SLA, policy or other indicators provided by network. In 
particular:
  - There may be different possible paths between source and 
destination, where some paths may or may not meet Application QoE or policy 
constraints. The Applications would like to see which path is most suitable.
  - Contextual parameters may be available at frequencies that are 
different from ALTO information frequency. For example, Cost on PID-Cell1 may 
differ, depending on some real-time network parameter value.

+++ Issue 2: Some entities may have properties whose values change over time. 
For instance, ANEs may have time-varying properties on cloud or networking 
resources

-- Potential solution(s)
+++  To address issue 1 and related : extend cost attributes towards 
conditional values and parameters allowing a better interpretation of the 
received values
- Extension from single cost value to array of values dependent on context 
parameters:
allowing applications to make context-dependent decisions,
allowing also to combine information generated with different time dynamics, 
(freshness)
See examples on 
https://datatracker.ietf.org/doc/slides-98-alto-alto-cost-context/

+++  To address issue 2:
- ALTO Property Calendars to extend a single property value to an array of 
time-dependent property values

-- Remaining issues to be addressed
- How to define cost value attributes?
- How to achieve a light and flexible design?
- How to moderate additional Server workload and ALTO traffic increase?

-- Who will work on it, rough planning
+++  Extensions may go in standalone documents and/or extend existing ones, eg 
ALTO performance metrics
+++ Contributors: Sabine and any other interested people
+++ Plans for IETF 110:
  -  Reactivation and update of related existing ALTO drafts
  -  First draft for ALTO Property Calendars
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] Any implementations of unified-props, alto-cdni, path-vector

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

Hi Vijay,

To my knowledge,

- there is no implementation of Unified Properties that reflects the latest 
design updates, defined in 2019 and 2020,
- I am not aware of any implementation of Path Vector.

Best regards,
Sabine

From: alto  On Behalf Of Vijay Gurbani
Sent: Wednesday, November 11, 2020 5:57 PM
To: IETF ALTO 
Subject: [alto] Any implementations of unified-props, alto-cdni, path-vector

All: I am the shepherd for the three drafts identified in the subject.

As I prepare the shepherd writeup, I will like to document if there are any 
implementations of these three drafts that the WG members are aware of.  These 
implementations can be private (a few individuals working on the drafts), or be 
more formal with a GitHub repository and a larger community.

If any WG member is aware of implementations, please let me know.  Please drop 
me an email (or  post on the list) with the details as you know them.  I would 
like to kindly ask you to do this as soon as possible --- preferably by the end 
of this week --- to allow me to prepare the shepherd writeup.

Thank you.

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

Re: [alto] Welcome Qin Wu

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

Hello Qin,

Welcome as a new chair for ALTO. Looking forward to working with you.
All the best,
Sabine

From: alto  On Behalf Of Martin Duke
Sent: Tuesday, November 10, 2020 4:48 AM
To: IETF ALTO 
Subject: [alto] Welcome Qin Wu

Hello ALTO,

I'm pleased to welcome Qin Wu as the newest working group chair, effective 
immediately. Qin is and active participant in ALTO and an experienced chair.

We will have three chairs at IETF 109. Shortly afterwards, one of the current 
chairs will step down. As we complete the current milestones, I will appoint a 
second chair to free both Jan and Vijay to move on to other things.

See you next week,
Martin
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

[alto] ALTO recharter: proposed item - General ALTO protocol extensions

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

Dear all,

Please find below a WG item proposal for "general ALTO protocol extensions", on 
which your feedback and suggestions will be more than welcome.
Thanks,
Sabine

-- Context: the current ALTO charter
o Extends the path cost values in several directions:
  - single to array of several cost metrics => allows apps to 
decide upon several metrics and make decision compromise
  - single cost value to array if time dependent cost values => 
allow apps to determine when to connect
o Extends endpoints to entities on which properties are defined

-- Basic Issues
+++  Issue 1: Some path cost values may depend on "contextual parameters" such 
as access type, SLA, policy or other indicators provided by network. In 
particular:
  - There may be different possible paths between source and 
destination, where some paths may or may not meet Application QoE or policy 
constraints. The Applications would like to see which path is most suitable.
  - Contextual parameters may be available at frequencies that are 
different from ALTO information frequency. For example, Cost on PID-Cell1 may 
differ, depending on some real-time network parameter value.

+++ Issue 2: Some entities may have properties whose values change over time. 
For instance, ANEs may have time-varying properties on cloud or networking 
resources

-- Potential solution(s)
+++  To address issue 1 and related : extend cost attributes towards 
conditional values and parameters allowing a better interpretation of the 
received values
- Extension from single cost value to array of values dependent on context 
parameters:
allowing applications to make context-dependent decisions,
allowing also to combine information generated with different time dynamics, 
(freshness)
See examples on 
https://datatracker.ietf.org/doc/slides-98-alto-alto-cost-context/

+++  To address issue 2:
- ALTO Property Calendars to extend a single property value to an array of 
time-dependent property values

-- Remaining issues to be addressed
- How to define cost value attributes?
- How to achieve a light and flexible design?
- How to moderate additional Server workload and ALTO traffic increase?

-- Who will work on it, rough planning
+++  Extensions may go in standalone documents and/or extend existing ones, eg 
ALTO performance metrics
+++ Contributors: Sabine and any other interested people
+++ Plans for IETF 110:
  -  Reactivation and update of related existing ALTO drafts
  -  First draft for ALTO Property Calendars
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] Meeting info for Oct 3, 2020

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

Dear all,

Thanks for the fruitful discussions.
There is a draft re-chartering topic proposal in 
https://docs.google.com/document/d/1qP9jf-CMXvNiEE3YAnApTczAE4QkBW23Q1Eg99uOaEQ/edit
 

 , page 16 and entitled “General protocol extensions - to convey a richer set 
of cost attributes” on which your feedback would be welcome.
This is an initial version that likely needs further precision or clarity at 
some points upon your comments.

Thanks,
Sabine

From: alto  On Behalf Of kai...@scu.edu.cn
Sent: Tuesday, November 3, 2020 3:31 AM
To: alto@ietf.org; alto-weekly-meet...@googlegroups.com
Subject: Re: [alto] Meeting info for Oct 3, 2020


Dear all,



I'm terribly sorry. The date should be Nov 3, 2020.



My apologies.



Best,

Kai



-Original Messages-
From:kai...@scu.edu.cn
Sent Time:2020-11-03 08:57:54 (Tuesday)
To: alto@ietf.org, 
"alto-weekly-meet...@googlegroups.com"
 
mailto:alto-weekly-meet...@googlegroups.com>>
Cc:
Subject: [alto] Meeting info for Oct 3, 2020

Dear all,



As IETF 109 is approaching, we will have a weekly meeting at 9:00 am US EST on 
Oct 3, 2020.



NOTE: The US has also started daylight saving, the time is 3:00 pm Central 
European Time and 10:00 pm Beijing China Time.



Agenda:



1. Current Status and Presentations of WG documents

2. Progress of drafts related to recharter items



As we just have the cut-off of IETF submissions, the meeting can be short. If 
anyone wants to present or lead a discussion, please let me know.



Bridge: https://yale.zoom.us/my/yryang



Best,

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

Re: [alto] Meeting Info for Oct 20, 2020

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

Hi Kai,

Thanks  a lot for the agenda. Maybe we can add:
- where we stand with respect to WG Leader applications as requested by Martin.
Thanks,
Sabine

From: alto  On Behalf Of kai...@scu.edu.cn
Sent: Monday, October 19, 2020 4:46 PM
To: alto@ietf.org; alto-weekly-meet...@googlegroups.com
Subject: [alto] Meeting Info for Oct 20, 2020


Hi everyone,



We will have the ALTO weekly meeting at 9:00 am US EST on Oct 20, 2020.



The agenda of this week is as follows:



1. Responses for the WG document reviews

2. Discussion on rechartering items



If anyone wants to give a presentation or propose another topic, please let me 
know.



Bridge: https://yale.zoom.us/my/yryang



Best,

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

Re: [alto] Review for draft-ietf-alto-unified-props-new-12

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

Hi Luis,

Great thanks for this thorough review. Your comments will be attended in the 
next iteration of the draft.
Best regards,
Sabine & co-authors

From: alto  On Behalf Of LUIS MIGUEL CONTRERAS MURILLO
Sent: Monday, October 12, 2020 10:44 PM
To: 'alto@ietf.org' 
Subject: [alto] Review for draft-ietf-alto-unified-props-new-12

Dear all,

Please, find here below the review for the Unified Properties draft.

/* General comments */
.- Section 2 - Requirements language - as general comment, the usage of words 
such as MUST, MAY, etc should be reviewed in all of the occurrences in the 
text. In some of them they do not appear in capital letters, so not clear if 
this statements apply or not. Examples of this are: "must" in 2nd paragraph of 
section 3.2; "must" in 2nd paragraph of section 4.1; "may" in 1st paragraph of 
section 4.3; etc.
.- References to the need of registering some items at IANA - it is not clear 
to me if this can be left as it is or if some values have to be proposed in the 
draft, or at least marked in the text with the idea of substituting such marks 
by values once IANA register the items. If that is the case, it would be 
advisable to include (maybe as an annex) a summary table compiling all the 
items that are expected to be registered. Would it not be part of section 12?
.- Along the text it is frequent to find references to other sections before or 
afterwards. Acknowledging that this could be necessary, it would help the 
reader to have some summary table (or any other way, like a figure) where the 
different aspects could be listed beforehand, in such a way that the reader can 
use it as a kind of map for navigating through the document. I understand it is 
not easy, so take it as a suggestion for making the document more readable. For 
instance, some way of showing the relationship among terms in the Terminology 
section.
.- Section 3 presents the basic features of the unified properties while the 
advanced ones are in section 4. How these extensions co-exist? Are they 
incremental? What is the reason from presenting them in separate sections? Is 
it possible to have the basic ones without the advanced features?
.- Both Section 10 and Appendix A present examples. Would not make sense to 
move all he examples either to one place or the other?

/* Particular comments */
.- Section 1 - Introduction, page 4, 2nd paragraph - "... recent ALTO use cases 
show ..." -> it would be good to be more explicit by listing the use cases that 
are being referred to.
.- Section 1 - Introduction, page 5, 1st bullet - fix reference for [REF 
path-vector]
.- Section 1 - Introduction, page 5, 3rd bullet - "... POST-mode... that 
returns ..." -> would not be "sets" instead of "returns"?
.- Section 1 - Introduction, page 5, 1st paragraph - "extensible" -> 
"augmentable" ??
.- Section 1.1 - Terminology - fix the text marked as TBC
.- Section 2 - Requirements language, 1st paragraph - fix the text marked as 
TODO.
.- Section 3, 1st paragraph - The reference to the assumption of familiarity 
with ALTO protocol is redundant with the last sentence of section 1 (just 
before section 1.1 title)
.- Section 3, 1st paragraph - "... ALTO Entities, entities for short" -> "... 
ALTO Entities, or entities for short"
.- Section 3.2.2, 1st paragraph - the sentence "An entity domain name ..." is 
hard to understand. Please, revisit and simplify (maybe shortening or dividing 
it).
.- Section 3.3, 1st paragraph - "Simularly" -> "Similarly"
.- Section 3.3, bullets in page 9 - is there any inventory of registered types? 
Are only those provided here as examples?
.- Section 4.2, penultimate paragraph - "Example resource specific..." -> 
"Example of resource specific..."
.- Section 4.4, 2nd paragraph - it would be interesting to perform queries and 
marking properties that could exclude or filter the entities. For instance to 
get a list of entities compliant with some property but excluding those that 
are compliant with another one.
.- Section 4.4.3, 1st paragraph - "... inherits no more than one property ..." 
<- why not more than one?
.- Section 4.4.3, 1st paragraph, last sentence - how is it applied? It would be 
interesting to add some example.
.- Section 4.5, 1st paragraph - "Therefore an ALTO server ... specifies the 
properties ..." <- how this advertisement is made?
.- Section 4.5, 2nd paragraph - expand IRD as first occurrence in the text.
.- Section 4.5, 2nd bullet - "... a list of the names ..." <- names or types?
.- Section 4.6, 1st paragraph - "To this end, he ..." -> "To this end, the ..."
.- Section 4.6, 1st paragraph - "The syntax of the entity domain identifier ... 
allows the client to infer ..." -> would it not be better to follow some rule 
instead of inferring if it is resource specific or not?
.- Section 4.6, last paragraph - is it necessary to have always a Defining 
Information Resource for each entity domain?
.- Section 4.6.1, page 16, paragraph "A fundamental attribute ..."- I don't 
understand th

[alto] Please fill the Doodle for the ALTO weekly meetings

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

Dear all,

As you have seen in Kai's e-mail last Monday, there is a Doodle poll ongoing to 
find a suitable time for the ALTO weekly syn-up meetings.
The reason is that the current slot on Wednesday 15-16h CET is not suitable for 
many people.
Thanks a lot to those who already filled it.
Please fill in the poll at the link hereby:  
https://doodle.com/poll/e39rpsm9sr7s4mgi

Thanks a lot and best regards,
Sabine


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

Re: [alto] Status of alto-unified-props: Not encouraging?

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

Hi Vijay,

Thank you for the reminder. A new version 13 is under edition and addresses the 
review of Danny. It will also address the second review comments once they will 
be available.

Thanks,
Sabine

From: alto  On Behalf Of Vijay Gurbani
Sent: Friday, September 25, 2020 4:59 PM
To: IETF ALTO 
Subject: [alto] Status of alto-unified-props: Not encouraging?

All: The unified-properties draft is now done with its WGLC.  (In fact, it is 
well past done.  WGLC ended on Aug 7, 2020 [0].)

I will be shepherding this draft, however, I see a problem with it.

I note that the draft only received one WGLC review , and this was from Danny 
[1].  My understanding from list discussion [2] is that Luis was to provide a 
second review, but I do not see the second WGLC review.  If I am mistaken, 
please let me know and I will apologize profusely.  In the event that there has 
not been a second WGLC review ...

If a second review is provided, please be advised that the draft will not move 
ahead.  Since other drafts have a dependency on this draft, a lack of movement 
of unified-properties implies that progress of dependent drafts stops as well.

I will kindly request Luis to provide a WGLC no later than Oct 09, two weeks 
from now.  If other list members want to review the draft in addition to Luis, 
please let Jan and me know.  We do need one more quality review for 
unified-properties to move ahead.  If a second review is not provided by Oct 
09, the chairs will take this as advice that the work is no longer important to 
the WG, and the WG will have to decide on the fate of dependent documents.

@Authors: It looks like Danny's comments have not yet been incorporated in a 
new revision.  Danny reviewed version -12 and that appears to be the latest 
version in the IETF archives.  Please notify the WG on your plans to update the 
draft based on Danny's comments.

[0] https://mailarchive.ietf.org/arch/msg/alto/jhPmZR4UKpiIwA_tC2s9b9YZ8Mk/
[1] https://mailarchive.ietf.org/arch/msg/alto/YVaCXE7IgXOqWpq-17GV-gbiYwo/
[2] https://mailarchive.ietf.org/arch/msg/alto/b0xwfQUVnYp_o58tJO32MF9p42I/

Thanks,

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

Re: [alto] ALTO Weekly Meeting Info for Sep. 09, 2020

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

Dear all,

I would like to add the following topic, regarding WG documents to finalize
- ALTO Calendar RFC editor questions: answer to question N°6-C
- Unified property review status
These 2 topics would only take a couple of minutes but need to be addressed to 
finalize the WG documents.

Thanks,
Sabine

From: alto-weekly-meet...@googlegroups.com 
 On Behalf Of Jensen Zhang
Sent: Tuesday, September 8, 2020 10:12 PM
To: IETF ALTO ; alto-weekly-meet...@googlegroups.com
Subject: ALTO Weekly Meeting Info for Sep. 09, 2020

Dear ALTOers,

Just a friendly reminder that we will continue our weekly meeting this 
Wednesday (Sep-09) at 9:00 am - 10:00 am US ET.

The draft agenda*:

  *   Finalize the draft write-up for WG rechertering
  *   Open discussion slots
Meeting bridge: https://yale.zoom.us/my/yryang

*If you have any other agenda items to be discussed, please feel free to post.

Talk to you then.

Best regards,
Jensen
--
You received this message because you are subscribed to the Google Groups 
"alto-weekly-meeting" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to 
alto-weekly-meeting+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/alto-weekly-meeting/CAAbpuyq62458%2BOU-BA6irxPKnHPwQKTQ9mmogzNdd5qLZy0u_A%40mail.gmail.com.
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] WGLC for draft-ietf-alto-unified-props-new-12

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

Hi Danny,

Great thanks for your review.
Best regards,
Sabine


From: alto  On Behalf Of Danny Alex Lachos Perez
Sent: Friday, August 7, 2020 8:40 PM
To: IETF ALTO 
Subject: Re: [alto] WGLC for draft-ietf-alto-unified-props-new-12


Dear UP authors

I have performed the review of this draft (-12).
See my comments in the attached file (search for '[DANNY]')
Most of them are about clarity, consistency, and format issues

Best regards,

Danny Lachos


On Fri, Jul 17, 2020 at 2:01 PM Jan Seedorf 
mailto:i...@j-f-s.de>> wrote:
Dear all,

after a discussion with Vijay on how to move forward with the pending
documents, we decided to start a WGLC for the unified properties
document now. Thus, this email starts a WGLC for
draft-ietf-alto-unified-props-new-12. The WGLC will run from today, Fri,
July 17, 2020, to Fri, August 7, 2020.

We would like to have two individual reviews of this document as part of
the WGLC. Please send us an email if you are willing review the draft as
part of WGLC.

  - Vijay and Jan

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

Re: [alto] ALTO in IEEE Communications Standards Magazine

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

Indeed, great thanks for the reference and excellent overview. Already started 
to disseminate them.
Cheers,
Sabine


From: alto  On Behalf Of Y. Richard Yang
Sent: Tuesday, July 28, 2020 8:07 PM
To: Vijay Gurbani 
Cc: IETF ALTO 
Subject: Re: [alto] ALTO in IEEE Communications Standards Magazine

Vijay, Jan,

An excellent update to a general audience on ALTO, from its beginning, to its 
finished work, to its to-be-finished work, and then the interesting future 
directions! I will link it to my home page as well :-)

Richard

On Tue, Jul 28, 2020 at 10:48 AM Vijay Gurbani 
mailto:vijay.gurb...@gmail.com>> wrote:
All: Recently, Jan and I were invited to present the state of ALTO in IEEE 
Communications Magazine.  Please see Page 9 of the June 2020 issue [1] for 
ALTO-related news.  (The content is available without a paywall.)

[1] https://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=9139037

Thanks.
___
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/|
 =
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] Note takers and Jabber scribe

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

Hi Vijay,

Unless somebody else already volunteered, I can be the second note taker
Cheers,
Sabine


From: alto  On Behalf Of Vijay Gurbani
Sent: Sunday, July 26, 2020 1:29 AM
To: Qiao Xiang 
Cc: IETF ALTO 
Subject: Re: [alto] Note takers and Jabber scribe

Excellent.  Thank you!

On Fri, Jul 24, 2020 at 10:33 PM Qiao Xiang 
mailto:xiang...@gmail.com>> wrote:
Hi Vijay,

I'd be glad to be a note taker.


Best
Qiao

On Fri, Jul 24, 2020 at 10:04 PM Vijay Gurbani 
mailto:vijay.gurb...@gmail.com>> wrote:
All: If you are willing to take notes, please send Jan and me an email.  We 
will need two note takers and one Jabber scribe..

Thank you.

- vijay
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto
--
Qiao Xiang
Postdoctoral Fellow,
Department of Computer Science,
Yale University
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] Are we on track to release the I-Ds ...

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

Hi Vijay,

Yes, the Unified Properties draft will be posted today
Thanks,
Sabine


From: alto  On Behalf Of Vijay Gurbani
Sent: Monday, July 13, 2020 11:32 PM
To: IETF ALTO 
Subject: [alto] Are we on track to release the I-Ds ...

Dear Authors of path-vector, unified-props, and performance-metrics: Are we on 
track to release the I-Ds by the end of today so we can start WGLC?

Please advise.

Thanks,

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

Re: [alto] Proposed update in PV on Persistent Entities

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

Hi Jensen, Kai and all,

Additonal propositions for updates on the PV have been added in
https://docs.google.com/document/d/1aqm4xjFDlcTfz_UdpBJnCV9fu49hSGUctJdEshpAqOk/edit
see < July 13 >

The purpose is to
- explain that ANE domains are intrinsically resource specific
- explain that this applies only for domains of persistent ANEs
- harmonize with the IANA section

Thanks,
Sabine


From: alto  On Behalf Of Randriamasy, Sabine (Nokia - 
FR/Paris-Saclay)
Sent: Sunday, July 12, 2020 9:00 PM
To: kai...@scu.edu.cn; 'Richard Yang' ; Jensen Zhang 

Cc: IETF ALTO 
Subject: [alto] Proposed update in PV on Persistent Entities

Hi Kai, Jensen, Richard,

I have documented an update proposal for the Path Vector draft in
https://docs.google.com/document/d/1aqm4xjFDlcTfz_UdpBJnCV9fu49hSGUctJdEshpAqOk/edit

The update proposes text and example (to be edited as necessary) for section 
"5.3.2. ANE Property: Persistent Entities".
Please look up "July 12".
The section number is as per intermediate version draft-ietf-alto-path-vector-11

If something's wrong, you may add comments in the google doc and drop an e-mail.

Best regards,
Sabine




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

[alto] Proposed update in PV on Persistent Entities

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

Hi Kai, Jensen, Richard,

I have documented an update proposal for the Path Vector draft in
https://docs.google.com/document/d/1aqm4xjFDlcTfz_UdpBJnCV9fu49hSGUctJdEshpAqOk/edit

The update proposes text and example (to be edited as necessary) for section 
"5.3.2. ANE Property: Persistent Entities".
Please look up "July 12".
The section number is as per intermediate version draft-ietf-alto-path-vector-11

If something's wrong, you may add comments in the google doc and drop an e-mail.

Best regards,
Sabine



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

Re: [alto] Finishing milestones: Status of drafts?

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

Dear Vijay, Jan and all,

Here are some updates regarding the Unified Property and Path Vector drafts.

Upon discussions during our weekly ALTO syncup calls,  have adapted the 
Path-Vector (PV) design so as to enable standalone Property queries on 
particular ANEs.

Up to now, the PV draft says:  "the scope of an ANE Name is limited to the Path 
Vector response."  One reason is that an (ALTO) Client is not necessarily 
interested in details on ANEs on a path but only needs to know their existence 
and impact on the connection performance.

While ANEs returned by a PV response do not exist beyond this response, some of 
them may represent entities that are persistent because it is useful for 
Servers and Clients to occasionally query properties without caring about the 
path that traverses them. In this case, they have a persistent ID that can be 
registered in a property map, together with properties.

When a  Client wants to query such properties on a persistent ANE, it needs 2 
informations:
- persistent ID of the ANE,
- Name of the Property map defining properties on this ANE.
These 2 informations are assembled so as to form an entity ID format with the 
format specified in the Unified Property (UP) draft and that can be directly 
utilized for entity property queries.

The updates to support such a functionality are being integrated in both PV and 
UP draft.

Additionally, the UP draft introduces the field of  "defining resource"  in the 
specification of entity domains and registrations at the IANA. The "defining 
resource" specifies where an entity is being defined and applies to all entity 
domains.

We plan to submit an updated version by July 13th  on which we will request a 
WGLC.

Thanks,
Sabine


From: alto  On Behalf Of Vijay Gurbani
Sent: Thursday, July 2, 2020 5:42 AM
To: IETF ALTO 
Subject: [alto] Finishing milestones: Status of drafts?

Folks: There are three drafts that we need to progress: path vector, 
performance metrics, and unified properties.

Jan and I will like to get a clear idea from the authors of each of these 
documents as to where things stand.

The WG list has been rather silent on progress on the drafts.  For unified 
properties, Sabine had posted an email on Jun-10, but there has not been 
anything else on that draft since.

Performance metrics saw some action on the WG list on May-17, but that is it.

I don't see anything for path vector.

Can we kindly have the authors of the draft please put forward where they are 
and whether the work is done enough to start WGLC on them..  Please do so ASAP.

Thanks,

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

Re: [alto] ALTO Meeting Info for Jun. 10, 2020 - Unified Properties

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

Dear all,

A digest of the discussions and decisions on the Unified Property updates can 
be found here:
https://docs.google.com/document/d/1aqm4xjFDlcTfz_UdpBJnCV9fu49hSGUctJdEshpAqOk/edit
Look up JUNE 10.

We had a great and thorough discussion with Richard, Kai, Jensen in particular, 
on those updates related to the Path Vector extension and that are supporting 
cases of ANEs on which to further query properties off-line independently of a 
path vector transaction.
Your feedback and proposals are more than welcome.
 Thanks,
Sabine


From: Randriamasy, Sabine (Nokia - FR/Paris-Saclay)
Sent: Wednesday, June 10, 2020 3:08 PM
To: Danny Alex Lachos Perez ; IETF ALTO ; 
alto-weekly-meet...@googlegroups.com
Subject: RE: ALTO Meeting Info for Jun. 10, 2020

Dear all,

For some comments and updates for the Unified Properties draft please look up
https://docs.google.com/document/d/1aqm4xjFDlcTfz_UdpBJnCV9fu49hSGUctJdEshpAqOk/edit

Thanks,
Sabine

From: 
alto-weekly-meet...@googlegroups.com<mailto:alto-weekly-meet...@googlegroups.com>
 
mailto:alto-weekly-meet...@googlegroups.com>>
 On Behalf Of Danny Alex Lachos Perez
Sent: Tuesday, June 9, 2020 9:17 PM
To: IETF ALTO mailto:alto@ietf.org>>; 
alto-weekly-meet...@googlegroups.com<mailto:alto-weekly-meet...@googlegroups.com>
Subject: ALTO Meeting Info for Jun. 10, 2020

Dear all,

Just a friendly reminder that we will have our weekly meeting this Wednesday 
(Jun-10) at 9:00 am US ET.

Agenda*:

  *   WG documents status
  *   NAI Workshop
*If people have other agenda items, please feel free to post.

Bridge link: https://yale.zoom.us/my/yryang

Best regards,

Danny Lachos
--
You received this message because you are subscribed to the Google Groups 
"alto-weekly-meeting" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to 
alto-weekly-meeting+unsubscr...@googlegroups.com<mailto:alto-weekly-meeting+unsubscr...@googlegroups.com>.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/alto-weekly-meeting/CAEDarXKmgyr4a9FV7DE0v%2BnyNCtArF%2BFamszV%3DMJtBF%2BoKR4bw%40mail.gmail.com<https://groups.google.com/d/msgid/alto-weekly-meeting/CAEDarXKmgyr4a9FV7DE0v%2BnyNCtArF%2BFamszV%3DMJtBF%2BoKR4bw%40mail.gmail.com?utm_medium=email&utm_source=footer>.
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] ALTO Meeting Info for Jun. 10, 2020

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

Dear all,

For some comments and updates for the Unified Properties draft please look up
https://docs.google.com/document/d/1aqm4xjFDlcTfz_UdpBJnCV9fu49hSGUctJdEshpAqOk/edit

Thanks,
Sabine

From: alto-weekly-meet...@googlegroups.com 
 On Behalf Of Danny Alex Lachos Perez
Sent: Tuesday, June 9, 2020 9:17 PM
To: IETF ALTO ; alto-weekly-meet...@googlegroups.com
Subject: ALTO Meeting Info for Jun. 10, 2020

Dear all,

Just a friendly reminder that we will have our weekly meeting this Wednesday 
(Jun-10) at 9:00 am US ET.

Agenda*:

  *   WG documents status
  *   NAI Workshop
*If people have other agenda items, please feel free to post.

Bridge link: https://yale.zoom.us/my/yryang

Best regards,

Danny Lachos
--
You received this message because you are subscribed to the Google Groups 
"alto-weekly-meeting" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to 
alto-weekly-meeting+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/alto-weekly-meeting/CAEDarXKmgyr4a9FV7DE0v%2BnyNCtArF%2BFamszV%3DMJtBF%2BoKR4bw%40mail.gmail.com.
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] ALTO Meeting Info for May. 27, 2020

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

Dear all,

Please look up the “UP reviews” doc below for progress, discussions and 
remaining TODOs on the draft
https://docs.google.com/document/d/1aqm4xjFDlcTfz_UdpBJnCV9fu49hSGUctJdEshpAqOk/edit
Thanks,
Sabine

From: alto-weekly-meet...@googlegroups.com 
 On Behalf Of LUIS MIGUEL CONTRERAS 
MURILLO
Sent: Wednesday, May 27, 2020 2:28 PM
To: IETF ALTO ; alto-weekly-meet...@googlegroups.com; Danny Alex 
Lachos Perez 
Subject: Re: ALTO Meeting Info for May. 27, 2020

Hi all
I'm afraid It Will not possible for me to attend today. Maybe I can join at the 
very last parte
Apologies
Luis
Obtener Outlook para Android


From: 
alto-weekly-meet...@googlegroups.com
 
mailto:alto-weekly-meet...@googlegroups.com>>
 on behalf of Danny Alex Lachos Perez 
mailto:dlachos...@gmail.com>>
Sent: Tuesday, May 26, 2020 7:14:30 PM
To: IETF ALTO mailto:alto@ietf.org>>; 
alto-weekly-meet...@googlegroups.com
 
mailto:alto-weekly-meet...@googlegroups.com>>
Subject: ALTO Meeting Info for May. 27, 2020

Dear all,

Just a friendly reminder that we will have our weekly meeting this Wednesday 
(May-27) at 9:00 am US ET.

Agenda*:

  *   WG documents status
  *   NAI Workshop
* If people have other agenda items, please feel free to post.

Bridge link: https://yale.zoom.us/my/yryang

Best regards,

Danny Lachos
--
You received this message because you are subscribed to the Google Groups 
"alto-weekly-meeting" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to 
alto-weekly-meeting+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/alto-weekly-meeting/CAEDarXKVqGGBwVQ2BLQ68K5RWWejCRvq_2A3qqc-yFxoHHyCyA%40mail.gmail.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 privileged and confidential 
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
--
You received this message because you are subscribed to the Google Groups 
"alto-weekly-meeting" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to 
alto-weekly-meeting+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/alto-weekly-meeting/VI1PR0601MB215747FC70EF62994C6801709EB10%40VI1PR0601MB2157.eurprd06.prod.outlook.com.
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] Welcome your comments on new draft-huang-alto-mowie-for-network-aware-app(Internet mail)

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

Hello Chunchan,

Thanks a lot for your responses. Please see additional comments inline.
Hoping the message gets through the ALTO mailing list as well,
Best regards,
Sabine


From: chunshxiong(熊春山) 
Sent: Thursday, May 7, 2020 11:27 AM
To: alto@ietf.org
Cc: Randriamasy, Sabine (Nokia - FR/Paris-Saclay) 
; Y. Richard Yang 
Subject: RE: Re: [alto] Welcome your comments on new 
draft-huang-alto-mowie-for-network-aware-app(Internet mail)

Hello Sabine,

Please see my response inline.

It seems that there is something wrong from the alto wg mailing list. I include 
you and Richard in CC and hope you can receive the email directly. And  I will 
write an email to the alto chairmans.

BRs,
Chunshan Xiong

From: Randriamasy, Sabine (Nokia - FR/Paris-Saclay) 
mailto:sabine.randriam...@nokia-bell-labs.com>>
Sent: Tuesday, May 5, 2020 2:45 AM
To: chunshxiong(熊春山) mailto:chunshxi...@tencent.com>>
Cc: 'Richard Yang' mailto:y...@cs.yale.edu>>
Subject: FW: [alto] Welcome your comments on new 
draft-huang-alto-mowie-for-network-aware-app(Internet mail)

Hello Chunshan,

Please see my response in the e-mail below. I initially have put the ALTO WG 
mailing list in Cc but my e-mail has been rejected.
We may want to let the WG chairs know about this. In the meantime, we can 
continue our discussion off-line and bring it back to the ALTO mailing list 
when the issue is solved.

Best regards,
Sabine


From: Randriamasy, Sabine (Nokia - FR/Paris-Saclay)
Sent: Monday, May 4, 2020 8:41 PM
To: chunshxiong(熊春山) mailto:chunshxi...@tencent.com>>; 
；alto@ietf.org<mailto:alto@ietf.org>
Subject: RE: [alto] Welcome your comments on new 
draft-huang-alto-mowie-for-network-aware-app

Hello Chunshan,

Thanks for your responses,
Please see inline,
Best regards,
Sabine


From: chunshxiong(熊春山) mailto:chunshxi...@tencent.com>>
Sent: Monday, April 27, 2020 1:26 PM
To: Randriamasy, Sabine (Nokia - FR/Paris-Saclay) 
mailto:sabine.randriam...@nokia-bell-labs.com>>;
 ；alto@ietf.org<mailto:alto@ietf.org>
Subject: RE: [alto] Welcome your comments on new 
draft-huang-alto-mowie-for-network-aware-app

Hello Sebine,

Thanks a lot for your comments.

Please check my responses inline...

BRs,
Chunshan Xiong

From: Randriamasy, Sabine (Nokia - FR/Paris-Saclay) 
mailto:sabine.randriam...@nokia-bell-labs.com>>
Sent: Tuesday, April 21, 2020 11:19 AM
To: chunshxiong(熊春山) mailto:chunshxi...@tencent.com>>; 
alto@ietf.org<mailto:alto@ietf.org>
Subject: RE: [alto] Welcome your comments on new 
draft-huang-alto-mowie-for-network-aware-app(Internet mail)

Hello Chunshan Xiong,

Thanks a lot for bringing these 5G use cases to the ALTO WG, and for the 
comprehensive description of related experiments. Indeed apps such as Low Delay 
Live Show are getting highly important in the current context of confinement, 
where classes are all getting virtual and interactive. The challenges faced by 
networks are an additional motivation to further optimize traffic  for such 
applications.

I would like to initiate discussions on section 5  "Standardization 
Considerations of MoWIE as an Extension to ALTO", where  some key 
considerations are provided.

1 - Regarding item "Network information selection and binding consideration": 
indeed, a flexible mechanism deciding which metrics an ALTO client should query 
will allow to support a variety of applications and contexts,  that may each 
require a particular set of metrics.  Such a mechanism, that prepares input to 
ALTO Client requests,  will use the IRD information, starting with the list of 
available cost metrics.
- Did you identify particular IRD features that need to be added or upgraded to 
support flexibility for ALTO Client requests?
[Chunshan Xiong] currently, based on my understanding, the validity time (or 
freshness time) of the network information is needed.
[ [SR] ]  The ALTO Performance Cost Metrics extension that is being specified 
indeed, does not mandate to provide such information. There is a discussion on 
information “freshness”, for metrics that impact the QoE and whose values 
change at a significant frequency and in an unpredictable way. For future 
extensions, it may be interesting to start a discussion on the pros, the cons, 
the how to convey such a freshness property in a reliable and light way.
[Chunshan Xiong] Thanks to provide these background information, I think the 
validity time information is an important parameter and needs to be considered, 
also I agree with you that more discussion are needed to reflect this new 
character.

- What type of flexibility is otherwise missing in ALTO information resources?
[Chunshan Xiong] Now the wireless network (e.g. through NWDAF and other 
devices) can collect wireless link and network information for radio station 
and other types of network elements, and also supports applications to access 
these information through a standard interface. Our Server ap

Re: [alto] Welcome your comments on new draft-huang-alto-mowie-for-network-aware-app

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

Hello Chunshan Xiong,

Thanks a lot for bringing these 5G use cases to the ALTO WG, and for the 
comprehensive description of related experiments. Indeed apps such as Low Delay 
Live Show are getting highly important in the current context of confinement, 
where classes are all getting virtual and interactive. The challenges faced by 
networks are an additional motivation to further optimize traffic  for such 
applications.

I would like to initiate discussions on section 5  "Standardization 
Considerations of MoWIE as an Extension to ALTO", where  some key 
considerations are provided.

1 - Regarding item "Network information selection and binding consideration": 
indeed, a flexible mechanism deciding which metrics an ALTO client should query 
will allow to support a variety of applications and contexts,  that may each 
require a particular set of metrics.  Such a mechanism, that prepares input to 
ALTO Client requests,  will use the IRD information, starting with the list of 
available cost metrics.
- Did you identify particular IRD features that need to be added or upgraded to 
support flexibility for ALTO Client requests?
- What type of flexibility is otherwise missing in ALTO information resources?

2 - In item "Compact network information encoding consideration": the 
processing overhead due to frequent updates especially for cellular networks 
raises a key point regarding future ALTO extensions. Definitely, ALTO is 
currently not meant to provide information at such a frequency.

- A first aspect to investigate in the ALTO WG may be requirements for reliable 
cellular network information. In particular: at which frequency does an 
application need to update network information?  In which extent can cellular 
network information be aggregated over time and still be reliable for an 
application? All this considering several applications and  several metrics.

- Another consideration on this item: very frequent network information 
updates, if predicable may be conveyed in Calendars with SSE updates for 
unexpected changes, but this is still near real time.  One way around is to 
investigate extensions that may combine ALTO information with "conditional" 
real-time information, obtained with other means. A first attempt in this 
direction is proposed in “ALTO Contextual Cost Values” [1]  where ALTO  
Calendar values are further interpreted with real-time parameter values 
acquired by other means. This is preliminary work and does not directly provide 
real-time cellular values but we may look at what can be extended in the 
design, to support cases for very frequent network information updates.

I look forward to hearing your presentation at the interim meeting.
Best regards,
Sabine

[1] https://tools.ietf.org/id/draft-randriamasy-alto-cost-context-03.txt


From: alto  On Behalf Of chunshxiong(???)
Sent: Tuesday, March 10, 2020 2:35 AM
To: alto@ietf.org
Subject: [alto] Welcome your comments on new 
draft-huang-alto-mowie-for-network-aware-app

Hello all,

A new alto draft 
https://datatracker.ietf.org/doc/draft-huang-alto-mowie-for-network-aware-app/ 
is submitted.

In this paper, we uses the network information of Mobile and Wireless 
Information Exposure (MoWIE) to adapt key control knobs such as media codec 
scheme, encapsulation and application logical function to improve the QoE. We 
provide some detailed testing and evaluations. And we discuss how MoWIE can be 
a systematic extension of the ALTO protocol, to expose more lower-layer and 
finer grain network dynamics.
We spend a lot of time and testing to produce this paper, welcome your comments 
and we will update the testing and improve the paper based on your comments.

BRs,
Chunshan Xiong
Tencent

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

Re: [alto] Considerations about More Flexible ALTO Query/Filter

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

Hi Jensen,

Thank you for bringing these considerations.
Do you have examples of filters or constraints that you would like to add to 
queries for Unified Properties or Path Vector and that cannot be achieved with 
the current ALTO design?
Also, do you have examples that illustrate the limitations of NoSQLs or 
document-oriented databases wrt ALTO? And examples for option1 and option2.

Thanks,
Sabine


From: alto  On Behalf Of Jensen Zhang
Sent: Friday, March 27, 2020 3:28 AM
To: IETF ALTO 
Subject: [alto] Considerations about More Flexible ALTO Query/Filter

Hi all,

I'm considering the extension to the current ALTO information resource query.

Currently, ALTO can only support the very simple query (e.g., Filtered Network 
Map, Filtered Cost Map). Although Filtered Cost Map supports the test 
constraint, it is very limited and cannot be applied to some new ALTO 
extensions (e.g., path vector and unified properties).

So far, as I know, most of NoSQLs or document-oriented databases (e.g., MongoDB 
[1], PostgreSQL [2], ElasticSearch [3]) have JSON query support. I think we can 
leverage them to query ALTO information resources. However, all of them have a 
clear limitation when applied to ALTO: the query statement must specify the 
concrete field names. But all of ALTO information resources use non-fixed 
fields (e.g., PIDName in Network Map, src and dst TypedEndpointAddr in ECS).

To extend the current ALTO query, I can think about two options:

Option 1: we define a conversation between the ALTO JSON schema and some other 
schema using fixed fields (e.g., the JSON schema defined by YANG model [4]). 
Then the client can use the JSON query languages in existing database systems 
to query the later schema, but the ALTO server transfers the result to the 
former (ALTO) schema and returns it. In the backend, most of the ALTO 
implementations should be based on those database systems. So this option can 
be acceptable in practice.

Option 2: we use some more flexible JSON query language (e.g., JSONiq [5]), or 
define a new query language for ALTO specific. This option can be more valuable 
if we want to design a new database system for ALTO.

Looking forward to seeing more comments and discussions from WG.

[1] https://docs.mongodb.com/manual/tutorial/query-documents/
[2] https://www.postgresqltutorial.com/postgresql-json/
[3] 
https://www.elastic.co/guide/en/elasticsearch/reference/current/query-dsl.html
[4] 
https://tools.ietf.org/html/draft-shi-alto-yang-model-03
[5] http://jsoniq.org/

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

Re: [alto] Draft agenda for IETF 107 virtual interim

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

Hello Vijay,

Thank you for this information. So the target submission deadline would be 
April 7th .
Thanks,
Sabine

From: Vijay Gurbani 
Sent: Friday, March 20, 2020 3:16 PM
To: Randriamasy, Sabine (Nokia - FR/Paris-Saclay) 

Cc: IETF ALTO 
Subject: Re: [alto] Draft agenda for IETF 107 virtual interim

Dear Sabine: I am no aware of any specific deadline, however, as always, please 
make sure that your draft has been submitted at least two weeks before our 
virtual meeting date to give the WG some time to look at it.

Thanks,

- vijay

On Fri, Mar 20, 2020 at 6:19 AM Randriamasy, Sabine (Nokia - FR/Paris-Saclay) 
mailto:sabine.randriam...@nokia-bell-labs.com>>
 wrote:
Hi Vijay,

Thanks a lot for the agenda. As the ID submission tool was re-opened pursuant 
to the F2F IETF107 cancellation, is there any new deadline to submit new 
versions for the drafts to be presented?
Thanks,
Sabine


From: alto mailto:alto-boun...@ietf.org>> On Behalf Of 
Vijay Gurbani
Sent: Thursday, March 19, 2020 5:37 PM
To: IETF ALTO mailto:alto@ietf.org>>
Subject: [alto] Draft agenda for IETF 107 virtual interim

All: The draft agenda for the virtual interim is at 
https://datatracker.ietf.org/doc/agenda-interim-2020-alto-01-alto-01/

If anyone sent Jan and me an agenda request that is not reflected in the 
agenda, please let us know.

Thanks,

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

Re: [alto] Draft agenda for IETF 107 virtual interim

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

Hi Vijay,

Thanks a lot for the agenda. As the ID submission tool was re-opened pursuant 
to the F2F IETF107 cancellation, is there any new deadline to submit new 
versions for the drafts to be presented?
Thanks,
Sabine


From: alto  On Behalf Of Vijay Gurbani
Sent: Thursday, March 19, 2020 5:37 PM
To: IETF ALTO 
Subject: [alto] Draft agenda for IETF 107 virtual interim

All: The draft agenda for the virtual interim is at 
https://datatracker.ietf.org/doc/agenda-interim-2020-alto-01-alto-01/

If anyone sent Jan and me an agenda request that is not reflected in the 
agenda, please let us know.

Thanks,

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

Re: [alto] Alexey Melnikov's No Objection on draft-ietf-alto-cost-calendar-19: (with COMMENT)

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

Hi Alexey and Francesca,

Thanks again for your review and guidance. Your comments have been addressed as 
described in the responses inline. 
A new version v21 has been posted and is available here, hoping it meets your 
expectations.
https://tools.ietf.org/html/draft-ietf-alto-cost-calendar-21   

Best regards,
Sabine

>-Original Message-
>From: Alexey Melnikov via Datatracker 
>Sent: Thursday, March 5, 2020 2:03 PM
>To: The IESG 
>Cc: draft-ietf-alto-cost-calen...@ietf.org; alto-cha...@ietf.org; 
>alto@ietf.org;
>Vijay Gurbani ; vijay.gurb...@nokia.com;
>francesca.palomb...@ericsson.com
>Subject: Alexey Melnikov's No Objection on draft-ietf-alto-cost-calendar-19:
>(with COMMENT)
>
>Alexey Melnikov has entered the following ballot position for
>draft-ietf-alto-cost-calendar-19: No Objection
>
>--
>COMMENT:
>--
>
>This version is an improvement over the one I reviewed earlier.
>
>*
>*
>* Note, that I am conducting an experiment when people aspiring to be*
>* Area Directors get exposed to AD work ("AD shadowing experiment"). *
>* As a part of this experiment they get to review documents on IESG  *
>* telechats according to IESG Discuss criteria document and their*
>* comments get relayed pretty much verbatim to relevant editors/WGs. *
>* As an AD I retain responsibility in defending their position when  *
>* I agree with it.   *
>* Recipients of these reviews are encouraged to reply to me directly *
>* about perceived successes or failures of this experiment.  *
>*
>*
>
>The following comments were provided by Francesca Palombini
>. My comments are marked with
>[[Alexey:]] below.
>
>Francesca would have balloted *DISCUSS* on this document. She wrote:
>
>DISCUSS
>
>* "The encoding format for object CalendarAttributes, using JSON
>   [RFC8259], is as follows:"
>JSON is used, right. I know 7285 is normatively reference but the draft is 
>missing
>either here or in the introduction part of the spec (e.g. terminology) to 
>explicitly
>point to Section 8.2 of 7285 Notation, as that is used here.
>
[ [SR] ]  Yes, done. Section 3.3 now starts with:
- NEW
The present document uses the notations defined in Section "8.2
   Notation" of [RFC7285].
- END

>COMMENT
>
>* "However, like for any schedule, unexpected network
>   incidents may require the current ALTO Calendar to be updated and re-
>   sent to the ALTO Clients needing it.  The "ALTO Incremental Updates
>   Using Server-Sent Events (SSE)" Service
>   [I-D.ietf-alto-incr-update-sse] can be used to update the calendar
>   faster if supported by both the Server and the Client."
>
>   If the "ALTO Incremental Updates Using Server-Sent Events (SSE)" Service is
>   not used, and updates are required, what should be used instead?
>   (draft-ietf-alto-incr-update-sse is indeed informational reference)
>
[ [SR] ] draft-ietf-alto-incr-update-sse is now a normative reference, with 
RECOMMENDED use 

>* "with one value one per time interval," remove second "one"
>
[ [SR] ] Done, thanks

>* "Specifically, an
>   implementation of this extension MUST parse the "number-of-intervals"
>   attribute of the "calendar-attributes" in an IRD entry announcing a
>   service providing Cost Calendar."
>   Please ref to where "calendar-attrinutes" is defined.
>
[ [SR] ] the expression is now "Calendar attributes", as introduced in Section 
3.2


>* "Calendared" is used in the text. I would either rephrase or explain in the
>terminology what this is supposed to mean.
>
[ [SR] ] the following definition was added in section 1.2 Terminology
- NEW
Calendared: this adjective qualifies information resources providing Cost 
Calendars 
  and information on costs that are provided in the form of a Cost 
Calendar.
- END

>* Section 3 - "This section gives a non-normative overview of the design. "
>That is not true, as 3.3.2 at least contains normative text (as it should).
>
[ [SR] ] Yes, indeed, the text was changed as follows:
- NEW
This section gives a high-level overview of the design.  
It assumes the reader is familiar with the ALTO protocol [RFC7285] and 
its Multi-Cost ALTO extension [RFC8189].
- END

>* "multiple
>   appearances of a cost type name in the CalendarAttributes object of
>   the "calendar-attributes" member MUST cause the ALTO Client to ignore
>   any occurrences of this name beyond the first encountered occurrence."
>   This worries me as occurrences can be re-ordered (by  intermediaries) I am
>   not sure ignoring further occurrences and keep the processing is the best
>   idea... This should at least have some security considerations.
>
[[SR]] I agree there should be some guidance for the Client in this case. T

[alto] FW: Benjamin Kaduk's No Objection on draft-ietf-alto-cost-calendar-20: (with COMMENT)

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

Hi Benjamin,

Thanks again for your review and guidance. Your comments have been addressed as 
described in the responses inline. 
A new version v21 has been posted and is available here, hoping it meets your 
expectations.
https://tools.ietf.org/html/draft-ietf-alto-cost-calendar-21  

Best regards,
Sabine 

-Original Message-
From: Randriamasy, Sabine (Nokia - FR/Paris-Saclay) 
 
Sent: Wednesday, March 11, 2020 7:18 PM
To: Benjamin Kaduk ; The IESG 
Cc: draft-ietf-alto-cost-calen...@ietf.org; alto-cha...@ietf.org; 
alto@ietf.org; Vijay Gurbani ; vijay.gurb...@nokia.com
Subject: RE: Benjamin Kaduk's No Objection on draft-ietf-alto-cost-calendar-20: 
(with COMMENT)

Hello Benjamin,

Thanks again for your review. A version v21 is under edition to finish 
addressing all the review comments. 
Please see inline for my responses to your comments. 

Best regards,
Sabine

>-Original Message-
>From: Benjamin Kaduk via Datatracker 
>Sent: Tuesday, March 10, 2020 1:21 AM
>To: The IESG 
>Cc: draft-ietf-alto-cost-calen...@ietf.org; alto-cha...@ietf.org; 
>alto@ietf.org; Vijay Gurbani ; 
>vijay.gurb...@nokia.com
>Subject: Benjamin Kaduk's No Objection on draft-ietf-alto-cost-calendar-20:
>(with COMMENT)
>
>Benjamin Kaduk has entered the following ballot position for
>draft-ietf-alto-cost-calendar-20: No Objection
>
>
>--
>COMMENT:
>--
>
>Thanks for adding text about the incompatibility of constraints with 
>the calendar functionality.  I would suggest further clarifying that 
>this reflects a limitation of this method or reduction in functionality 
>when compared to RFC
>7285 (and 8189), but do not insist upon it.
>
[[SR]] Most of your text was used, thanks, and added to the text on constraints 
in section 3.3:
- NEW
As providing the constraint functionality in conjunction 
   with the Calendar functionality is not feasible for the reasons described 
above, 
   the two features are mutually exclusive. The absence of constraints on 
   Filtered Cost Map and Endpoint Cost Map Calendars 
   reflects a divergence from the non-calendared information resources defined 
in 
and extended in , 
that support optional constraints.
- END

>[comments from -19 preserved for posterity]
>
>Section 1
>
>   In this document, an "ALTO Cost Calendar" is specified in terms of
>   information resources capabilities that are applicable to time-
>
>nit: "information resources capabilities" has two plurals.  Either make 
>"resources" possessive ("resources'") or just use "resource".
[ [SR] ] done thanks

>Section 1.1
>
>I'm not sure how much *archival* value there is in the current 
>discussion of SENSE and Unicorn.
>
[ [SR] ] Text was changed to be less project-centric and instead focusing on 
the motivating use-case. 
Reference [I-D.xiang-alto-multidomain-analytics] was changed to an archived 
journal paper [Unicorn-fgcs].

>Section 3.1
>
>   sent to the ALTO Clients needing it.  The "ALTO Incremental Updates
>   Using Server-Sent Events (SSE)" Service
>   [I-D.ietf-alto-incr-update-sse] can be used to update the calendar
>   faster if supported by both the Server and the Client.
>
>nit(?): faster than what?
>
[ [SR] ] the text has been changed as follows in v20:
NEW
The "ALTO Incremental Updates
   Using Server-Sent Events (SSE)" Service
   [I-D.ietf-alto-incr-update-sse] can be used to directly update the
   Calendar upon value changes, if supported by both the Server and the
   Client. END
>
>Section 3.3
>
>   The present document extends the definition of a legacy cost map
>   given in [RFC7285] to allow a cost entry to be an array of values,
>   with one value one per time interval, instead of being just one
>   number.  Therefore the implementor of this extension MUST consider
>   that a cost entry is an array of values.  Specifically, an
>
>nit: this is not quite true, strictly speaking -- the cost entry is 
>only an array when the cost calendar functionality is active, which is 
>not a subset of when the extension is implemented.
>Also, if the cost entry is definitively an array, then this would be 
>replacing the definition, not extending it.
>
[ [SR] ] Would the following text be better?
NEW
The present document extends the
   definition of a legacy cost map given in [RFC7285] to allow a cost
   entry to be an array of values, with one value one per time interval, 
instead of
   being just one number, when the Cost Calendar functionality is activated on 
this cost.
   Therefore the implementor of this extension MUST consider that a cost entry 
is an array of values
   if this cost has been queried 

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

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

Hello Roman,

Thanks again for your review. Your comments have been addressed as proposed in 
our responses inline.
A new version has been posted and is available here and we hope it meets your 
expectations.
https://tools.ietf.org/html/draft-ietf-alto-cost-calendar-21

Best regards,
Sabine and Richard

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

Sent: Tuesday, March 3, 2020 2:40 PM
To: Y. Richard Yang ; Roman Danyliw 
Cc: The IESG ; draft-ietf-alto-cost-calen...@ietf.org; 
alto-cha...@ietf.org; IETF ALTO ; Vijay Gurbani 
; Gurbani, Vijay (Nokia - US) 
Subject: RE: Roman Danyliw's No Objection on draft-ietf-alto-cost-calendar-19: 
(with COMMENT)

Hello Roman,

Thanks a lot for your review. Please see inline for the text in section 4.1
Best regards,
Sabine


From: Y. Richard Yang mailto:y...@cs.yale.edu>>
Sent: Tuesday, March 3, 2020 5:58 AM
To: Roman Danyliw mailto:r...@cert.org>>
Cc: The IESG mailto:i...@ietf.org>>; 
draft-ietf-alto-cost-calen...@ietf.org<mailto:draft-ietf-alto-cost-calen...@ietf.org>;
 alto-cha...@ietf.org<mailto:alto-cha...@ietf.org>; IETF ALTO 
mailto:alto@ietf.org>>; Vijay Gurbani 
mailto:vijay.gurb...@gmail.com>>; Gurbani, Vijay 
(Nokia - US) mailto:vijay.gurb...@nokia.com>>
Subject: Re: Roman Danyliw's No Objection on draft-ietf-alto-cost-calendar-19: 
(with COMMENT)

Dear Roman,

Thank you so much for the review. Please see below.

On Mon, Mar 2, 2020 at 6:16 PM Roman Danyliw via Datatracker 
mailto:nore...@ietf.org>> wrote:
Roman Danyliw has entered the following ballot position for
draft-ietf-alto-cost-calendar-19: 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/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-alto-cost-calendar/



--
COMMENT:
--

A few minor comments:

Section 1.1.  The role of the text describing the SENSE project isn’t clear.
I’m not sure it will age will when in an RFC

Good suggestion. To make the description aging slightly better, here is a 
revision.

OLD:

   A potential use case is the SENSE project, see [SENSE-sdn-e2e-net],

   who is implementing smart network services to dynamically build end-

   to-end virtual guaranteed networks across administrative domains,

   with no manual intervention.  The initial SENSE services include

   informing applications on the availability of bandwidth resources or

   feasibility of some requested Time-Bandwidth-Product (TBP) during a

   specific time period.  ALTO Calendars can support these services if

   the Calendar start date and duration cover the period of interest of

   the requesting applications.



   The need of future scheduling of large scale traffic that can be

   addressed by the ALTO protocol is also motivated by Unicorn, a

   unified resource orchestration framework for multi-domain, geo-

   distributed data analytics, see [I-D.xiang-alto-multidomain-analytics].

New (instead of project centric, switch to use centric, also some small

rewording):

   A potential use case is implementing smart network services that

   allow applications to dynamically build end-to-end, virtual networks,

   to satisfy given demands, with no manual intervention. For

   example, data-transfer automation applications may need a network

   service to determine on the availability of bandwidth resources,

   to decide when to transfer their data sets. The SENSE project

   [SENSE-sdn-e2e-net] supports such applications by requiring that

   a network provides services such as the Time-Bandwidth-Product (TBP)

   service, which informs applications of bandwidth availability during

   a specific time period. ALTO Calendars can support this service if the

   Calendar start date and duration cover the period of interest of the

   requesting application.

   The need of future scheduling of large scale traffic that can be

   addressed by the ALTO protocol is also motivated by Unicorn, a

   unified resource orchestration framework for multi-domain, geo-

   distributed data analytics, see [I-D.xiang-alto-multidomain-analytics].

 -> Change I-D.xiang-alto-multidomain-analytics to an archived  journal 
paper.

Section 3.  Thanks for providing an overview with the section.  Given that this
section is non-normative, how should the implementers use the text with RFC2119
words -- is it there just for emphasis?

Very good catch. How about the following revision of the first paragraph of 
Section 3:

OLD:

   This section gives a non-normative overview of the de

Re: [alto] ALTO Interim in lieu of IETF 107

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

Hi Vijay,

Thanks for the information. I can do slots 0 and 1. 2 would also do, with a 
lower preference though.
Cheers,
Sabine


From: alto  On Behalf Of Vijay Gurbani
Sent: Friday, March 13, 2020 6:59 PM
To: IETF ALTO 
Subject: [alto] ALTO Interim in lieu of IETF 107

All: The IESG has been working on coming up with a virtual interim schedule for 
WGs that would have met in Vancouver.  As the original schedule avoided WG and 
RG conflicts to the maximum extent possible, the virtual interim schedule has 
been created so that working groups and research groups can be reasonably sure 
that most participants will not have a conflict with another IETF interim 
meeting on the same day.

For ALTO, IESG has suggested Tue, Apr 21.  We will plan to hold a virtual 
interim on that day.  While we can decide another day besides the IESG 
suggested one, I would hesitate to do so for a variety of reasons, the most 
important of which is that we will have to ensure that our chosen day does not 
conflict with other WGs, BoFs, and RGs, that WG list members may be interested 
in.  Thus, it seems safe to stay with the IESG suggested date of Apr 21, as 
that date has honored all of the WG/RG conflicts with ALTO.

What we need to do soon (48 hours or so) is to agree on a specific time for Apr 
21 so Jan and I can set the wheels in motion to schedule the virtual interim on 
Apr 21.

Here are the options, please reply with your preferred option on the list.  Jan 
and I will collect all of the responses we receive by Sunday night, and choose 
the one that is most frequent by Mon AM.  I know Europe has not yet changed 
their clocks, so I will leave the times below in US Central time zone (which is 
now on daylight savings time).  So please adjust accordingly for your locale.  
All times are for Apr 21, 2020.

0. 5:00am - 7:00am US Central
1. 7:00am - 9:00am US Central
2. 9:00am - 11:00am US Central
3. 11:00am - 1:00pm US Central
4. 1:00pm - 3:00pm US Central
5. 3:00pm - 5:00pm US Central
6. 5:00pm - 7:00 pm US central *
7. 7:00pm - 9:00pm US central *
8. 9:00pm - 11:00pm US Central  *

* I will not be able to make these timeslots as they overlap with the class I 
teach.

Thank you,

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

Re: [alto] Agenda requests

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

Hi Vijay,

I would like to request the following slot:

Length of presentation time: 15 mins
Name of presenter: Sabine Randriamasy
Related I-D: draft-ietf-alto-cost-calendar-21

draft-ietf-alto-cost-calendar-21 will be submitted next Monday at the latest

Thanks,
Sabine



From: alto  On Behalf Of Vijay Gurbani
Sent: Thursday, March 12, 2020 3:31 PM
To: IETF ALTO 
Subject: [alto] Agenda requests

All:

By now, I am sure everyone knows that the Vancouver meeting has been cancelled. 
 The IESG will provide some clarity soon on when the various working groups can 
meet virtually.

Just so we keep the momentum going, please send me and Jan your agenda 
requests; so far we have only received two agenda requests (one from Hans 
Siedel and one from Chunshan Xiong).  We will like to put together an agenda in 
anticipation for a virtual meeting..  Please send me and Jan your agenda 
requests by end of the day Friday.  As usual, precedence will be given to WG 
chartered items.

In your agenda request, please indicate:

Length of presentation time:
Name of presenter:
Related I-D:

Thank you,

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

Re: [alto] Benjamin Kaduk's No Objection on draft-ietf-alto-cost-calendar-20: (with COMMENT)

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

Hello Benjamin and all,

Sorry, I mistakenly clicked the "Send" button and I still need to address a 
couple of comments.
In the meantime however, I'll be happy to have your feedback on the proposed 
updates.

Best regards,
Sabine
 

>-Original Message-
>From: Randriamasy, Sabine (Nokia - FR/Paris-Saclay)
>Sent: Wednesday, March 11, 2020 7:18 PM
>To: Benjamin Kaduk ; The IESG 
>Cc: draft-ietf-alto-cost-calen...@ietf.org; alto-cha...@ietf.org; 
>alto@ietf.org;
>Vijay Gurbani ; vijay.gurb...@nokia.com
>Subject: RE: Benjamin Kaduk's No Objection on draft-ietf-alto-cost-calendar-20:
>(with COMMENT)
>
>Hello Benjamin,
>
>Thanks again for your review. A version v21 is under edition to finish 
>addressing
>all the review comments.
>Please see inline for my responses to your comments.
>Best regards,
>Sabine
>
>>-Original Message-
>>From: Benjamin Kaduk via Datatracker 
>>Sent: Tuesday, March 10, 2020 1:21 AM
>>To: The IESG 
>>Cc: draft-ietf-alto-cost-calen...@ietf.org; alto-cha...@ietf.org;
>>alto@ietf.org; Vijay Gurbani ;
>>vijay.gurb...@nokia.com
>>Subject: Benjamin Kaduk's No Objection on draft-ietf-alto-cost-calendar-20:
>>(with COMMENT)
>>
>>Benjamin Kaduk has entered the following ballot position for
>>draft-ietf-alto-cost-calendar-20: 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/iesg/statement/discuss-criteria.html
>>for more information about IESG DISCUSS and COMMENT positions.
>>
>>
>>The document, along with other ballot positions, can be found here:
>>https://datatracker.ietf.org/doc/draft-ietf-alto-cost-calendar/
>>
>>
>>
>>--
>>COMMENT:
>>--
>>
>>Thanks for adding text about the incompatibility of constraints with
>>the calendar functionality.  I would suggest further clarifying that
>>this reflects a limitation of this method or reduction in functionality
>>when compared to RFC
>>7285 (and 8189), but do not insist upon it.
>>
>>[comments from -19 preserved for posterity]
>>
>>Section 1
>>
>>   In this document, an "ALTO Cost Calendar" is specified in terms of
>>   information resources capabilities that are applicable to time-
>>
>>nit: "information resources capabilities" has two plurals.  Either make
>>"resources" possessive ("resources'") or just use "resource".
>[ [SR]   ] done thanks
>>
>>Section 1.1
>>
>>I'm not sure how much *archival* value there is in the current
>>discussion of SENSE and Unicorn.
>[ [SR]   ] Text changed to be less project-centric ans instead focusing on 
>the
>motivating use-case.
>Reference [I-D.xiang-alto-multidomain-analytics] was changed to an archived
>journal paper.
>>
>>Section 3.1
>>
>>   sent to the ALTO Clients needing it.  The "ALTO Incremental Updates
>>   Using Server-Sent Events (SSE)" Service
>>   [I-D.ietf-alto-incr-update-sse] can be used to update the calendar
>>   faster if supported by both the Server and the Client.
>>
>>nit(?): faster than what?
>[ [SR]   ] the text has been changed as follows in v20:
>NEW
>The "ALTO Incremental Updates
>   Using Server-Sent Events (SSE)" Service
>   [I-D.ietf-alto-incr-update-sse] can be used to directly update the
>   Calendar upon value changes, if supported by both the Server and the
>   Client. END
>>
>>Section 3.3
>>
>>   The present document extends the definition of a legacy cost map
>>   given in [RFC7285] to allow a cost entry to be an array of values,
>>   with one value one per time interval, instead of being just one
>>   number.  Therefore the implementor of this extension MUST consider
>>   that a cost entry is an array of values.  Specifically, an
>>
>>nit: this is not quite true, strictly speaking -- the cost entry is
>>only an array when the cost calendar functionality is active, which is
>>not a subset of when the extension is implemented.
>>Also, if the cost entry is definitively an array, then this would be
>>replacing the definition, not extending it.
>[ [SR]   ] Would the following text be better?
>NEW
>The present document extends the
>   definition of a legacy cost map given in  to 

Re: [alto] Benjamin Kaduk's No Objection on draft-ietf-alto-cost-calendar-20: (with COMMENT)

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

Hello Benjamin,

Thanks again for your review. A version v21 is under edition to finish 
addressing all the review comments. 
Please see inline for my responses to your comments. 
Best regards,
Sabine

>-Original Message-
>From: Benjamin Kaduk via Datatracker 
>Sent: Tuesday, March 10, 2020 1:21 AM
>To: The IESG 
>Cc: draft-ietf-alto-cost-calen...@ietf.org; alto-cha...@ietf.org; 
>alto@ietf.org;
>Vijay Gurbani ; vijay.gurb...@nokia.com
>Subject: Benjamin Kaduk's No Objection on draft-ietf-alto-cost-calendar-20:
>(with COMMENT)
>
>Benjamin Kaduk has entered the following ballot position for
>draft-ietf-alto-cost-calendar-20: 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/iesg/statement/discuss-criteria.html
>for more information about IESG DISCUSS and COMMENT positions.
>
>
>The document, along with other ballot positions, can be found here:
>https://datatracker.ietf.org/doc/draft-ietf-alto-cost-calendar/
>
>
>
>--
>COMMENT:
>--
>
>Thanks for adding text about the incompatibility of constraints with the
>calendar functionality.  I would suggest further clarifying that this reflects 
>a
>limitation of this method or reduction in functionality when compared to RFC
>7285 (and 8189), but do not insist upon it.
>
>[comments from -19 preserved for posterity]
>
>Section 1
>
>   In this document, an "ALTO Cost Calendar" is specified in terms of
>   information resources capabilities that are applicable to time-
>
>nit: "information resources capabilities" has two plurals.  Either make
>"resources" possessive ("resources'") or just use "resource".
[ [SR]   ] done thanks
>
>Section 1.1
>
>I'm not sure how much *archival* value there is in the current discussion of
>SENSE and Unicorn.
[ [SR]   ] Text changed to be less project-centric ans instead focusing on 
the motivating use-case. 
Reference [I-D.xiang-alto-multidomain-analytics] was changed to an archived 
journal paper.
>
>Section 3.1
>
>   sent to the ALTO Clients needing it.  The "ALTO Incremental Updates
>   Using Server-Sent Events (SSE)" Service
>   [I-D.ietf-alto-incr-update-sse] can be used to update the calendar
>   faster if supported by both the Server and the Client.
>
>nit(?): faster than what?
[ [SR]   ] the text has been changed as follows in v20:
NEW 
The "ALTO Incremental Updates
   Using Server-Sent Events (SSE)" Service
   [I-D.ietf-alto-incr-update-sse] can be used to directly update the
   Calendar upon value changes, if supported by both the Server and the
   Client. END
>
>Section 3.3
>
>   The present document extends the definition of a legacy cost map
>   given in [RFC7285] to allow a cost entry to be an array of values,
>   with one value one per time interval, instead of being just one
>   number.  Therefore the implementor of this extension MUST consider
>   that a cost entry is an array of values.  Specifically, an
>
>nit: this is not quite true, strictly speaking -- the cost entry is only an 
>array
>when the cost calendar functionality is active, which is not a subset of when
>the extension is implemented.
>Also, if the cost entry is definitively an array, then this would be replacing 
>the
>definition, not extending it.
[ [SR]   ] Would the following text be better?
NEW 
The present document extends the
   definition of a legacy cost map given in  to allow a 
cost
   entry to be an array of values, with one value one per time interval, 
instead of
   being just one number, when the Cost Calendar functionality is activated on 
this cost.
   Therefore the implementor of this extension MUST consider that a cost entry 
is an array of values
   if this cost has been queried as a Calendar. END

>
>   implementation of this extension MUST parse the "number-of-intervals"
>   attribute of the "calendar-attributes" in an IRD entry announcing a
>   service providing Cost Calendar.  The implementation then will know
>   that a cost entry of the service will be an array of values, and the
>   expected size of the array is that specified by the "number-of-
>   intervals" attribute.
>
>Is it a protocol error if the cost entry is a scalar or an array of different 
>size
>than expected?  Where do we specify error handling for those cases?
>
>   To realize an ALTO Calendar, this document extends: the IRD and the
>   ALTO requests and responses for Cost Calendars.
>
>nit: no colon needed.
[ [SR]   ] done, thanks
>
>   o  it allows an ALTO Server to offer Calendar capabilities on a cost
>  type, with attributes values adapted to each information resource.
>
>I'm not entirely sure what this is intending to say.  Is the idea that this is 
>a
>general mechanism that could be applied to capabilities of all cost t

Re: [alto] Benjamin Kaduk's No Objection on draft-ietf-alto-cost-calendar-20: (with COMMENT)

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

Hello Benjamin,

All right, thanks for your suggestion. I will insert such a text.
Best regards,
Sabine


>-Original Message-
>From: Benjamin Kaduk 
>Sent: Wednesday, March 11, 2020 2:24 AM
>To: Randriamasy, Sabine (Nokia - FR/Paris-Saclay) bell-labs.com>
>Cc: The IESG ; draft-ietf-alto-cost-calen...@ietf.org; alto-
>cha...@ietf.org; alto@ietf.org; Vijay Gurbani ;
>vijay.gurb...@nokia.com
>Subject: Re: Benjamin Kaduk's No Objection on draft-ietf-alto-cost-calendar-20:
>(with COMMENT)
>
>Hi Sabine,
>
>On Tue, Mar 10, 2020 at 09:40:13AM +, Randriamasy, Sabine (Nokia -
>FR/Paris-Saclay) wrote:
>> Hello Benjamin,
>>
>> Thank you for your review and feedback. As you saw, in draft-ietf-alto-cost-
>calendar-20, there are still comments from v19 that will be addressed in the
>next update.
>
>I'm happy to hear that :)
>
>> I would have a question : in your sentence " I would suggest further 
>> clarifying
>that this reflects a limitation of this method or reduction in functionality 
>when
>compared to RFC 7285 (and 8189), but do not insist upon it.", what does "this
>method" refer to? Is the idea that using constraints is less efficient with
>Calendars that with RFC 7285 and 8189? If yes I will propose a sentence to
>reflect this idea.
>
>"This method" is ALTO Cost Calendars in general.  So, I was thinking something
>like adding a sentence at the end of Section 3.3 to say "The absence of
>constraints on filtered cost map and endpoint cost map calendars reflects a
>divergence from the non-calendared functionality defined in RFC
>7285 and updated by RFC 8189; providing the constraint functionality in
>conjunction with calendar functionality is not feasible for the reasons 
>described
>above, so the two features are mutually exclusive."
>
>I am sure you can come up with a more elegant phrasing than I just wrote on
>the fly.
>
>Thanks,
>
>Ben
>
>> Best regards,
>> Sabine
>>
>>
>> -Original Message-
>> From: Benjamin Kaduk via Datatracker 
>> Sent: Tuesday, March 10, 2020 1:21 AM
>> To: The IESG 
>> Cc: draft-ietf-alto-cost-calen...@ietf.org; alto-cha...@ietf.org;
>> alto@ietf.org; Vijay Gurbani ;
>> vijay.gurb...@nokia.com
>> Subject: Benjamin Kaduk's No Objection on
>> draft-ietf-alto-cost-calendar-20: (with COMMENT)
>>
>> Benjamin Kaduk has entered the following ballot position for
>> draft-ietf-alto-cost-calendar-20: 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/iesg/statement/discuss-criteria.html
>> for more information about IESG DISCUSS and COMMENT positions.
>>
>>
>> The document, along with other ballot positions, can be found here:
>> https://datatracker.ietf.org/doc/draft-ietf-alto-cost-calendar/
>>
>>
>>
>> --
>> COMMENT:
>> --
>>
>> Thanks for adding text about the incompatibility of constraints with the
>calendar functionality.  I would suggest further clarifying that this reflects 
>a
>limitation of this method or reduction in functionality when compared to RFC
>7285 (and 8189), but do not insist upon it.
>>
>> [comments from -19 preserved for posterity]
>>
>> Section 1
>>
>>In this document, an "ALTO Cost Calendar" is specified in terms of
>>information resources capabilities that are applicable to time-
>>
>> nit: "information resources capabilities" has two plurals.  Either make
>"resources" possessive ("resources'") or just use "resource".
>>
>> Section 1.1
>>
>> I'm not sure how much *archival* value there is in the current discussion of
>SENSE and Unicorn.
>>
>> Section 3.1
>>
>>sent to the ALTO Clients needing it.  The "ALTO Incremental Updates
>>Using Server-Sent Events (SSE)" Service
>>[I-D.ietf-alto-incr-update-sse] can be used to update the calendar
>>faster if supported by both the Server and the Client.
>>
>> nit(?): faster than what?
>>
>> Section 3.3
>>
>>The present document extends the definition of a legacy cost map
>>given in [RFC7285] to allow a cost entry to be an array of values,
>>with one value one per time int

Re: [alto] Benjamin Kaduk's No Objection on draft-ietf-alto-cost-calendar-20: (with COMMENT)

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

Hello Benjamin,

Thank you for your review and feedback. As you saw, in 
draft-ietf-alto-cost-calendar-20, there are still comments from v19 that will 
be addressed in the next update.

I would have a question : in your sentence " I would suggest further clarifying 
that this reflects a limitation of this method or reduction in functionality 
when compared to RFC 7285 (and 8189), but do not insist upon it.", what does 
"this method" refer to? Is the idea that using constraints is less efficient 
with Calendars that with RFC 7285 and 8189? If yes I will propose a sentence to 
reflect this idea.

Best regards,
Sabine


-Original Message-
From: Benjamin Kaduk via Datatracker  
Sent: Tuesday, March 10, 2020 1:21 AM
To: The IESG 
Cc: draft-ietf-alto-cost-calen...@ietf.org; alto-cha...@ietf.org; 
alto@ietf.org; Vijay Gurbani ; vijay.gurb...@nokia.com
Subject: Benjamin Kaduk's No Objection on draft-ietf-alto-cost-calendar-20: 
(with COMMENT)

Benjamin Kaduk has entered the following ballot position for
draft-ietf-alto-cost-calendar-20: 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/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-alto-cost-calendar/



--
COMMENT:
--

Thanks for adding text about the incompatibility of constraints with the 
calendar functionality.  I would suggest further clarifying that this reflects 
a limitation of this method or reduction in functionality when compared to RFC 
7285 (and 8189), but do not insist upon it.

[comments from -19 preserved for posterity]

Section 1

   In this document, an "ALTO Cost Calendar" is specified in terms of
   information resources capabilities that are applicable to time-

nit: "information resources capabilities" has two plurals.  Either make 
"resources" possessive ("resources'") or just use "resource".

Section 1.1

I'm not sure how much *archival* value there is in the current discussion of 
SENSE and Unicorn.

Section 3.1

   sent to the ALTO Clients needing it.  The "ALTO Incremental Updates
   Using Server-Sent Events (SSE)" Service
   [I-D.ietf-alto-incr-update-sse] can be used to update the calendar
   faster if supported by both the Server and the Client.

nit(?): faster than what?

Section 3.3

   The present document extends the definition of a legacy cost map
   given in [RFC7285] to allow a cost entry to be an array of values,
   with one value one per time interval, instead of being just one
   number.  Therefore the implementor of this extension MUST consider
   that a cost entry is an array of values.  Specifically, an

nit: this is not quite true, strictly speaking -- the cost entry is only an 
array when the cost calendar functionality is active, which is not a subset of 
when the extension is implemented.
Also, if the cost entry is definitively an array, then this would be replacing 
the definition, not extending it.

   implementation of this extension MUST parse the "number-of-intervals"
   attribute of the "calendar-attributes" in an IRD entry announcing a
   service providing Cost Calendar.  The implementation then will know
   that a cost entry of the service will be an array of values, and the
   expected size of the array is that specified by the "number-of-
   intervals" attribute.

Is it a protocol error if the cost entry is a scalar or an array of different 
size than expected?  Where do we specify error handling for those cases?

   To realize an ALTO Calendar, this document extends: the IRD and the
   ALTO requests and responses for Cost Calendars.

nit: no colon needed.

   o  it allows an ALTO Server to offer Calendar capabilities on a cost
  type, with attributes values adapted to each information resource.

I'm not entirely sure what this is intending to say.  Is the idea that this is 
a general mechanism that could be applied to capabilities of all cost types (as 
opposed to, e.g., making a new cost mode for "calendar of numerical" that would 
need many new types to support different types of calendar)?

Section 3.3.2

   The ALTO protocol extensions for Cost Calendars have been defined so
   as to ensure that Calendar capable ALTO Servers can provide legacy

nit: hyphenate "Calendar-capable" (and similarly throughout).  I see that 
"calendar-aware" is already hyphenated, which is good.

   ALTO Clients with legacy information resources as well.  That is, a
   legacy ALTO Client can request resources and receive responses as
   specified in [RFC7285].

Should we say anything about Calendar-aware ALTO Clients being able to get 
use

Re: [alto] Alexey Melnikov's No Objection on draft-ietf-alto-cost-calendar-19: (with COMMENT)

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

Hello Alexey and Francesca,

Thanks a lot for your review and feedback. We will get back to you shortly with 
our proposals to address your comments.
Best regards,
Sabine


-Original Message-
From: Alexey Melnikov via Datatracker  
Sent: Thursday, March 5, 2020 2:03 PM
To: The IESG 
Cc: draft-ietf-alto-cost-calen...@ietf.org; alto-cha...@ietf.org; 
alto@ietf.org; Vijay Gurbani ; 
vijay.gurb...@nokia.com; francesca.palomb...@ericsson.com
Subject: Alexey Melnikov's No Objection on draft-ietf-alto-cost-calendar-19: 
(with COMMENT)

Alexey Melnikov has entered the following ballot position for
draft-ietf-alto-cost-calendar-19: 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/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-alto-cost-calendar/



--
COMMENT:
--

This version is an improvement over the one I reviewed earlier.

**
* Note, that I am conducting an experiment when people aspiring to be*
* Area Directors get exposed to AD work ("AD shadowing experiment"). *
* As a part of this experiment they get to review documents on IESG  *
* telechats according to IESG Discuss criteria document and their*
* comments get relayed pretty much verbatim to relevant editors/WGs. *
* As an AD I retain responsibility in defending their position when  *
* I agree with it.   *
* Recipients of these reviews are encouraged to reply to me directly *
* about perceived successes or failures of this experiment.  *
**

The following comments were provided by Francesca Palombini 
. My comments are marked with [[Alexey:]] 
below.

Francesca would have balloted *DISCUSS* on this document. She wrote:

DISCUSS

* "The encoding format for object CalendarAttributes, using JSON
   [RFC8259], is as follows:"
JSON is used, right. I know 7285 is normatively reference but the draft is 
missing either here or in the introduction part of the spec (e.g. terminology) 
to explicitly point to Section 8.2 of 7285 Notation, as that is used here.

COMMENT

* "However, like for any schedule, unexpected network
   incidents may require the current ALTO Calendar to be updated and re-
   sent to the ALTO Clients needing it.  The "ALTO Incremental Updates
   Using Server-Sent Events (SSE)" Service
   [I-D.ietf-alto-incr-update-sse] can be used to update the calendar
   faster if supported by both the Server and the Client."

   If the "ALTO Incremental Updates Using Server-Sent Events (SSE)" Service is
   not used, and updates are required, what should be used instead?
   (draft-ietf-alto-incr-update-sse is indeed informational reference)

* "with one value one per time interval," remove second "one"

* "Specifically, an
   implementation of this extension MUST parse the "number-of-intervals"
   attribute of the "calendar-attributes" in an IRD entry announcing a
   service providing Cost Calendar."
   Please ref to where "calendar-attrinutes" is defined.

* "Calendared" is used in the text. I would either rephrase or explain in the 
terminology what this is supposed to mean.

* Section 3 - "This section gives a non-normative overview of the design. "
That is not true, as 3.3.2 at least contains normative text (as it should).

* "multiple
   appearances of a cost type name in the CalendarAttributes object of
   the "calendar-attributes" member MUST cause the ALTO Client to ignore
   any occurrences of this name beyond the first encountered occurrence."
   This worries me as occurrences can be re-ordered (by  intermediaries) I am
   not sure ignoring further occurrences and keep the processing is the best
   idea... This should at least have some security considerations.

* "A cost type name MUST NOT appear more than once in the
   "calendar-attributes" member of a resource entry;"
   Sounds to me like this should say MUST appear only once. What if it appears
   0 times?

*"   o  "cost-type-names":

  *  An array of one or more elements indicating the cost-type-names
 in the IRD entry to which the capabilities apply."
  Please do not use the parameter "cost-type-names" to describe the parameter
  itself  ("indicating the cost-type-names")

* "This field is an array of 1 to N boolean values, where N is the
   number of requested metrics."
   I could not find in 7285 that more than one metric can be requested. Could
   you confirm and point to a ref?

* In the Filtered Map