[alto] Comments on draft-ietf-alto-new-transport-08

[maqiufang (A)]

Hi, all

Notice that Jordi was asking for volunteers to review ALTO WG documents, I 
tried to spend some time reviewing this ALTO new transport document and my 
comments are following.
Note that some of my questions/comments may be due to my not fully 
understanding of this document(sorry!)...

Sec.1 Introduction
Specifically, this document specifies the
   following:

   *  Extensions to the ALTO Protocol to create, update, or remove an
  incrementally changing network information resource.
So I thought that the ALTO client can request to create and delete a TIPS view, 
and also query the content of the TIPS or receive push updates. But I am not 
sure how the ALTO protocol could be extended to allow the client to update that 
view. I thought ALTO is a network information exposure protocol, the capability 
to update a network information resource sounds surprising to me.


Sec.2.1 Transport Requirements
s/direct/directly

Sec.2.2 TIPS Terminology

* In the definition of Updates graph, the authors mention that:
  A static network information resource (e.g., Cost Map,
  Network Map) may need only a single updates graph. A dynamic
  network information resource (e.g., Filtered Cost Map) may create
  an updates graph (within a new TIPS view) for each unique filter
  request.

How to understand cost map and network map as static network information 
resource? I don't see the 7285 making that distinction, I think the cost map 
information could be dynamically changing. Maybe you mean something else I 
failed to get, but I don't think there exists static network information 
resource on a time span.



* The definition of snapshot/incremental update is a full/partial 
replacement of resource contained within an updates graph, but the word 
"replacement" sounds quite strange to me. Why it is a replacement? Could you 
clarify a little bit more? Or maybe you want to use generation/creation?



* The definition for ID#i-#j:

  Denotes the update item (op, data) on a specific edge in the
  updates graph to transition from version at node i to version at
  node j, where i and j are the respective sequence numbers of the
  nodes the edge connects.
  What's the abbreviation for op, operation? I don't see this field in the 
ALTO message. The update item is defined as either a snapshot or incremental 
update, I don't know how this is related to (op,data).



* The text below Information Resource Directory(IRD)

Figure 4 shows an example illustrating the TIPS abstraction.  Each

ALTO client (Client 1, Client 2, or Client 3) maintains a single HTTP

connection with the ALTO server.

s/Figure 4/Figure 1?  Also note that you described this figure as the TIPS 
abstraction, but the figure 1 title is "ALTO Transport Information".



* Regarding Figure 1, I found that description of information resource 
#2 is lost, is this intentional? Maybe add some description for resource #2 to 
communicate the intent? Or simply remove it and rename resource#3 to resource#2.



* Note that you also refer to network Map as static resource here, see 
my similar comments above.


* Above Figure 1: tvi/ug = incremental updates graph associated with tsi
s/tsi/tvi?

Sec.3.1 Basic Data Model of Updates Graph

* Mandatory incremental updates and optional incremental updates are 
mentioned in the explanation of Figure 2, but I never see this defined, so what 
is mandatory/optional incremental updates? What is the difference between 
mandatory and optional ones? Maybe point to some reference here, or clarify in 
the document.


Sec.3.2 Resource Location Schema

* I guess I don't really understand what is a location schema. Maybe 
add a reference or more text for clarity.

* At the very beginning of this section:

To access each individual update in an updates graph, consider the

   model represented as a "virtual" file system (adjacency list)...

In my opinion, it is not a real file system. The file system is a tree 
structure, each non-root node has and only has one parent, but in figure 3, for 
example, node 103 has both 0 and 102 as parents node, fine for a directed 
acyclic graph, but not a file  structure. Maybe I am wrong, but please check 
that.

* It is not easy to understand your figure 3. At first I was struggling 
to understand what the indentation means for each number, and what the shortcut 
means. Then I've got some understanding which I am not sure is correct. Maybe 
you want to add more explanation for this figure.


Sec.3.3 Updates Graph Modification Invariants

* Sorry, but I guess I still don't understand what the title means, 
what is the modification invariant?

* You mentioned in the last paragraph that a server might compact a 
resource's update graph to save space, and [105,106] are valid set for server 
to save. But then what if a client requests content from 101 to 105? Doesn't 
th

Re: [alto] Proposed Agenda for Interims #2-5

[maqiufang (A)]

Thank you Jordi for doing the proofreading, much appreciated. I’ve uploaded a 
new version (https://www.ietf.org/archive/id/draft-xie-alto-lmap-02.txt) with 
your annotations incorporated. And also see repo 
https://github.com/QiufangMa/alto-lmap for this document. Happy to work with 
you and receive your further comments via either Github or mailing list.

Yes, I would be glad to present during next Tuesday’s ALTO weekly meeting, 
thank you for arranging this!

Best Regards,
Qiufang

From: Jordi Ros Giralt [mailto:j...@qti.qualcomm.com]
Sent: Friday, May 5, 2023 10:15 PM
To: maqiufang (A) ; 
luismiguel.contrerasmuri...@telefonica.com
Cc: IETF ALTO ; draft-xie-alto-l...@ietf.org
Subject: Re: [alto] Proposed Agenda for Interims #2-5

Hi Qiufang,

Thank you for reviving your ALTO/LMAP draft and for incorporating the LMAP data 
source in the ALTO data sources document.

I agree with Luis and your comments below.

I did a pass on your draft and made some annotations, see the attached doc. 
Would you be able to generate an updated version and push it to the 
datatracker? If your draft is in a github repo, I can propose the changes and 
issue a pull request for your review. Otherwise, feel free to take the feedback 
from the attached doc.

Also, we apologize that during the interim meeting we could not cover all the 
material. Would you be able to present your ALTO/LMAP slide deck during the 
next ALTO meeting on Tuesday next week at 9am EST? I am happy to add it into 
the meeting's agenda.

Thanks,
Jordi on behalf of ALTO

From: alto mailto:alto-boun...@ietf.org>> on behalf of 
maqiufang (A) 
mailto:maqiufang1=40huawei@dmarc.ietf.org>>
Sent: Thursday, May 4, 2023 4:10
To: 
luismiguel.contrerasmuri...@telefonica.com<mailto:luismiguel.contrerasmuri...@telefonica.com>
 
mailto:luismiguel.contrerasmuri...@telefonica.com>>
Cc: IETF ALTO mailto:alto@ietf.org>>; 
draft-xie-alto-l...@ietf.org<mailto:draft-xie-alto-l...@ietf.org> 
mailto:draft-xie-alto-l...@ietf.org>>
Subject: Re: [alto] Proposed Agenda for Interims #2-5


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

Hi, Luis



Thank you for getting back to me! Please see my reply inline.

From: LUIS MIGUEL CONTRERAS MURILLO 
mailto:luismiguel.contrerasmuri...@telefonica.com>>
Sent: Sunday, April 30, 2023 1:15 AM
To: maqiufang (A) mailto:maqiufa...@huawei.com>>; Jensen 
Zhang mailto:jingxuan.n.zh...@gmail.com>>; 
kai...@scu.edu.cn<mailto:kai...@scu.edu.cn>
Cc: IETF ALTO mailto:alto@ietf.org>>; 
xie...@chinatelecom.cn<mailto:xie...@chinatelecom.cn>; 
wang...@chinatelecom.cn<mailto:wang...@chinatelecom.cn>
Subject: RE: [alto] Proposed Agenda for Interims #2-5



Hi Qiufang,



Thanks for pointing this out.



I think what you propose makes sense. Probably details should be clarified in 
terms of how PIDs defined for the measurement agents could correlate with 
conventional PIDs, i.e., those representing IP address pools. Some ideas come 
to my mind that probably we could discuss.

[Qiufang] Good. I think you are right that we need to clarify how measurement 
agents is correlated with conventional PIDs, and How to represent ALTO cost map 
using LMAP results, given that the LMAP results is based on specific 
measurement agent located in particular endpoint or network device, while ALTO 
cost map is cost metric between aggregation of endpoints. Would appreciate your 
ideas and happy to have further discussion with you.



But yes, I see this interesting to contemplate to understand what kind of 
extensions could be derived from this scenario, certainly interesting for 
network operations.

[Qiufang] Happy to know that you’re interested in this work. Currently we are 
also trying to explore what kinds of extensions could be derived from this. 
Answers to this might dependent on whether the LMAP details(e.g., 
measurement/report agent location, report schedule info) need to be organized 
into ALTO information and exposed to ALTO clients and to what extent.



Thanks for commenting and good to see this reported in the compilation sheet.

[Qiufang] Thank you!

Best regards



Luis



Best Regards,

Qiufang



De: maqiufang (A) mailto:maqiufa...@huawei.com>>
Enviado el: miércoles, 26 de abril de 2023 11:12
Para: LUIS MIGUEL CONTRERAS MURILLO 
mailto:luismiguel.contrerasmuri...@telefonica.com>>;
 Jensen Zhang mailto:jingxuan.n.zh...@gmail.com>>; 
kai...@scu.edu.cn<mailto:kai...@scu.edu.cn>
CC: IETF ALTO mailto:alto@ietf.org>>; 
xie...@chinatelecom.cn<mailto:xie...@chinatelecom.cn>; 
wang...@chinatelecom.cn<mailto:wang...@chinatelecom.cn>
Asunto: RE: [alto] Proposed Agenda for Interims #2-5



Hi, Luis and all



Thanks for this effort. Jensen and Kai, I think your proposals make sense to 
me, maybe could be reflected on the sh

Re: [alto] Proposed Agenda for Interims #2-5

[maqiufang (A)]

Hi, Luis

Thank you for getting back to me! Please see my reply inline.
From: LUIS MIGUEL CONTRERAS MURILLO 
mailto:luismiguel.contrerasmuri...@telefonica.com>>
Sent: Sunday, April 30, 2023 1:15 AM
To: maqiufang (A) mailto:maqiufa...@huawei.com>>; Jensen 
Zhang mailto:jingxuan.n.zh...@gmail.com>>; 
kai...@scu.edu.cn<mailto:kai...@scu.edu.cn>
Cc: IETF ALTO mailto:alto@ietf.org>>; 
xie...@chinatelecom.cn<mailto:xie...@chinatelecom.cn>; 
wang...@chinatelecom.cn<mailto:wang...@chinatelecom.cn>
Subject: RE: [alto] Proposed Agenda for Interims #2-5

Hi Qiufang,

Thanks for pointing this out.

I think what you propose makes sense. Probably details should be clarified in 
terms of how PIDs defined for the measurement agents could correlate with 
conventional PIDs, i.e., those representing IP address pools. Some ideas come 
to my mind that probably we could discuss.
[Qiufang] Good. I think you are right that we need to clarify how measurement 
agents is correlated with conventional PIDs, and How to represent ALTO cost map 
using LMAP results, given that the LMAP results is based on specific 
measurement agent located in particular endpoint or network device, while ALTO 
cost map is cost metric between aggregation of endpoints. Would appreciate your 
ideas and happy to have further discussion with you.

But yes, I see this interesting to contemplate to understand what kind of 
extensions could be derived from this scenario, certainly interesting for 
network operations.
[Qiufang] Happy to know that you’re interested in this work. Currently we are 
also trying to explore what kinds of extensions could be derived from this. 
Answers to this might dependent on whether the LMAP details(e.g., 
measurement/report agent location, report schedule info) need to be organized 
into ALTO information and exposed to ALTO clients and to what extent.

Thanks for commenting and good to see this reported in the compilation sheet.
[Qiufang] Thank you!
Best regards

Luis

Best Regards,
Qiufang

De: maqiufang (A) mailto:maqiufa...@huawei.com>>
Enviado el: miércoles, 26 de abril de 2023 11:12
Para: LUIS MIGUEL CONTRERAS MURILLO 
mailto:luismiguel.contrerasmuri...@telefonica.com>>;
 Jensen Zhang mailto:jingxuan.n.zh...@gmail.com>>; 
kai...@scu.edu.cn<mailto:kai...@scu.edu.cn>
CC: IETF ALTO mailto:alto@ietf.org>>; 
xie...@chinatelecom.cn<mailto:xie...@chinatelecom.cn>; 
wang...@chinatelecom.cn<mailto:wang...@chinatelecom.cn>
Asunto: RE: [alto] Proposed Agenda for Interims #2-5

Hi, Luis and all

Thanks for this effort. Jensen and Kai, I think your proposals make sense to 
me, maybe could be reflected on the shared spreadsheet?

I’ve Just added one more potential data source to the spreadsheet: LMAP 
(Large-Scale Measurement of Broadband Performance, RFC7594) network measurement 
results. That said, ALTO server can simply work as the LMAP collector and 
accept the report from the measurement agent which performs the measurement 
tasks as instructed by the LMAP controller.

PS. There is a draft 
(https://www.ietf.org/archive/id/draft-xie-alto-lmap-00.txt) related to that, 
the authors plan to revive it very soon.

Best Regards,
Qiufang

From: alto [mailto:alto-boun...@ietf.org] On Behalf Of Jensen Zhang
Sent: Wednesday, April 26, 2023 8:29 AM
To: kai...@scu.edu.cn<mailto:kai...@scu.edu.cn>
Cc: IETF ALTO mailto:alto@ietf.org>>; Qin Wu 
mailto:bill...@huawei.com>>
Subject: Re: [alto] Proposed Agenda for Interims #2-5

Hi Luis and all,

Thanks for this useful collection of data sources. Besides the data sources 
listed in this collection, I am wondering if the following kinds of data 
sources can also be considered:

1. Prefix information, e.g., internet routing registry (IRR). It provides route 
and provider related information attached to IP prefixes. It may be helpful for 
network/property map generation, or locating the network domain in multidomain 
settings.

2. Data plane information, e.g., routing and forwarding tables read from BGP 
looking glass server or other OAM tools. Although I see the "IETF TE Network 
topology" source can already provide routing information, it may focus on the 
control plane, e.g., routing policy, not the data plane.

3. Telemetry information, e.g., traceroute. It can get both routing and 
performance information. It may have some overlap with the performance metrics.

Looking forward to seeing more discussions on this topic.

Best,
Jensen

On Tue, Apr 25, 2023 at 10:55 PM mailto:kai...@scu.edu.cn>> 
wrote:

Hi Luis and all,



Thanks for the effort. The information is really useful and comprehensive. I 
think it lays a very good foundation to discuss and proceed with potential ALTO 
extensions.



With the rationale that, in my opinion, sets the expectations for each data 
source, I am wondering whether it is beneficial to discuss gaps and constraints 
as well.



For example, I used to work 

Re: [alto] Proposed Agenda for Interims #2-5

[maqiufang (A)]

Hi, Luis and all

Thanks for this effort. Jensen and Kai, I think your proposals make sense to 
me, maybe could be reflected on the shared spreadsheet?

I’ve Just added one more potential data source to the spreadsheet: LMAP 
(Large-Scale Measurement of Broadband Performance, RFC7594) network measurement 
results. That said, ALTO server can simply work as the LMAP collector and 
accept the report from the measurement agent which performs the measurement 
tasks as instructed by the LMAP controller.

PS. There is a draft 
(https://www.ietf.org/archive/id/draft-xie-alto-lmap-00.txt) related to that, 
the authors plan to revive it very soon.

Best Regards,
Qiufang

From: alto [mailto:alto-boun...@ietf.org] On Behalf Of Jensen Zhang
Sent: Wednesday, April 26, 2023 8:29 AM
To: kai...@scu.edu.cn
Cc: IETF ALTO ; Qin Wu 
Subject: Re: [alto] Proposed Agenda for Interims #2-5

Hi Luis and all,

Thanks for this useful collection of data sources. Besides the data sources 
listed in this collection, I am wondering if the following kinds of data 
sources can also be considered:

1. Prefix information, e.g., internet routing registry (IRR). It provides route 
and provider related information attached to IP prefixes. It may be helpful for 
network/property map generation, or locating the network domain in multidomain 
settings.

2. Data plane information, e.g., routing and forwarding tables read from BGP 
looking glass server or other OAM tools. Although I see the "IETF TE Network 
topology" source can already provide routing information, it may focus on the 
control plane, e.g., routing policy, not the data plane.

3. Telemetry information, e.g., traceroute. It can get both routing and 
performance information. It may have some overlap with the performance metrics.

Looking forward to seeing more discussions on this topic.

Best,
Jensen

On Tue, Apr 25, 2023 at 10:55 PM mailto:kai...@scu.edu.cn>> 
wrote:

Hi Luis and all,



Thanks for the effort. The information is really useful and comprehensive. I 
think it lays a very good foundation to discuss and proceed with potential ALTO 
extensions.



With the rationale that, in my opinion, sets the expectations for each data 
source, I am wondering whether it is beneficial to discuss gaps and constraints 
as well.



For example, I used to work on providing ALTO maps using SDN, or more 
precisely, using Open Daylight. Open Daylight has very good (among the best 
AFAIK) YANG support and the topology models were already support a few years 
back. One problem, however, was that using the topology information alone 
cannot generate high-precision network map or cost map: you still need to know 
where the hosts are attached and what is the routing. Thus, it has to be 
combined with other data sources, for example, host tracker in the SDN case or 
BGP/BGP-LS in provider networks, or be limited to specific networks, for 
example, those using link state routing protocols.



I am not saying that the document should summarize the gaps and/or constraints 
of all the data sources. Rather, I feel that the topic might be a useful input 
to the interim meeting and to future ALTO extensions.



Best,

Kai



-Original Messages
From:"LUIS MIGUEL CONTRERAS MURILLO" 
mailto:luismiguel.contrerasmuri...@telefonica.com>>
Sent Time:2023-04-18 06:23:51 (Tuesday)
To: "mohamed.boucad...@orange.com" 
mailto:mohamed.boucad...@orange.com>>, "IETF 
ALTO" mailto:alto@ietf.org>>
Cc: "Qin Wu" mailto:bill...@huawei.com>>
Subject: Re: [alto] Proposed Agenda for Interims #2-5
Hi Med, Qin, WG,

In order to provide inputs for:


* interim #3: Deployment Catalysts

• Proposals to fix the integration complexity and integration with data 
sources

Jordi and I have been working on collecting some references that we consider as 
potential data sources of relevance for the WG and possible integration with 
ALTO. We have collected those inputs here: 
https://docs.google.com/spreadsheets/d/1P4GrhQz_t17jIWg-3b1ycldhBWEEgIAAUZe2vjeO_1U/edit#gid=0

Please, feel free to access and check, all of you should be able to add/drop 
comments as well (let me know in case you need some permission for that). In 
the table we cover potential data sources, the rationale for considering them, 
existing reference work, as well as impacts on current ALTO. We hope this could 
be a basis for discussion for interim #3, but also to trigger discussions on 
the mailing list so we as WG can go to the interim with a more clear notion of 
the data sources and their implications.

Thanks

Best regards

Luis


De: alto mailto:alto-boun...@ietf.org>> En nombre de 
mohamed.boucad...@orange.com
Enviado el: martes, 4 de abril de 2023 8:58
Para: IETF ALTO mailto:alto@ietf.org>>
CC: Qin Wu mailto:bill...@huawei.com>>
Asunto: [alto] Proposed Agenda for Interims #2-5

Hi all,

Please find below the proposed agenda for the forthcoming interims

* interim #2: WGLC follow-

Re: [alto] IPR poll: draft-ietf-alto-oam-yang

[maqiufang (A)]

Hi,
No, I am not aware of any IPR applied to this document.

Best Regards,
Qiufang

From: mohamed.boucad...@orange.com [mailto:mohamed.boucad...@orange.com]
Sent: Monday, February 27, 2023 9:58 PM
To: draft-ietf-alto-oam-y...@ietf.org
Cc: 'alto@ietf.org' 
Subject: IPR poll: draft-ietf-alto-oam-yang

Hi Authors,

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

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

Thank you.

Cheers,
Qin & Med

_



Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.



This message and its attachments may contain confidential or privileged 
information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete 
this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.

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

Re: [alto] I-D Action: draft-ietf-alto-oam-yang-03.txt

[maqiufang (A)]

Hi, Jensen

BTW. There seems to exist some revision inconsistence warnings:
libyang warn: File name 
"ietf-alto-st...@2022-07-11.yang" does 
not match module revision "2023-02-10".
libyang warn: File name 
"ietf-a...@2022-10-24.yang" does not match 
module revision "2023-02-10".

Could it be caused by the local cache? I don't see the warnings reported by the 
datatracker.
[Qiufang] I think it is because you are using 
ietf-a...@2022-07-11.yang as file name, while 
the revision in the yang module is “2023-02-10”. It’s just a minor issue, the 
file-name should be updated to 
x...@2023-02-10.yang, e.g.,
 file "ietf-a...@2023-02-10.yang"
   module ietf-alto {
 …
  revision "2023-02-10" {
   …
}
…

Best Regards,
Qiufang

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

Re: [alto] I-D Action: draft-ietf-alto-oam-yang-03.txt

[maqiufang (A)]

Hi, Jensen, all

I have reviewed the new version today, and following are some of my further 
comments:
Regarding sec.5.4.3, I am not sure if the authentication choice is needed.
A grouping named alto-server-listen-stack-grouping is defined in the document 
and uses http-server-parameters and tls-server-parameters grouping definition, 
I think the authentication is already specified inside the grouping (with 
conformance to sec.8.3.5 in RFC7285.
If the connection is based on the http, following are some related client 
authentication configuration (expended by http-server-parameters grouping):
| | |  +--rw client-authentication! {client-auth-supported}?
| | | +--rw users {local-users-supported}?
| | |+--rw user* [user-id]
| | |   +--rw user-idstring
| | |   +--rw (auth-type)
| | |  +--:(basic)
| | | +--rw basic {basic-auth}?
| | |+--rw user-id?string
| | |+--rw password?   ianach:crypt-hash
If the connection is based on the https, following are some related 
authentication configuration (expended by tls-server-parameters grouping):
|  |  +--rw client-authentication! {client-auth-supported}?
|  |  |  +--rw ca-certs! {client-auth-x509-cert}?
|  |  |  |  +--rw (local-or-truststore)
|  |  |  | +--:(local) {local-definitions-supported}?
|  |  |  | |  +--rw local-definition
|  |  |  | | +--rw certificate* [name]
|  |  |  | |+--rw name  
string
|  |  |  | |+--rw cert-data 
trust-anchor-cert-cms
|  |  |  | |+---n certificate-expiration 
{certificate-expiration-notification}?
|  |  |  | |   +-- expiration-date
yang:date-and-time
|  |  |  | +--:(truststore) 
{central-truststore-supported,certificates}?
|  |  |  |+--rw truststore-reference?   
ts:certificate-bag-ref
|  |  |  +--rw ee-certs! {client-auth-x509-cert}?
|  |  |  |  +--rw (local-or-truststore)
|  |  |  | +--:(local) {local-definitions-supported}?
|  |  |  | |  +--rw local-definition
|  |  |  | | +--rw certificate* [name]
|  |  |  | |+--rw name  
string
|  |  |  | |+--rw cert-data 
trust-anchor-cert-cms
|  |  |  | |+---n certificate-expiration 
{certificate-expiration-notification}?
|  |  |  | |   +-- expiration-date
yang:date-and-time
|  |  |  | +--:(truststore) 
{central-truststore-supported,certificates}?
|  |  |  |+--rw truststore-reference?   
ts:certificate-bag-ref
|  |  |  +--rw raw-public-keys! 
{client-auth-raw-public-key}?
|  |  |  |  +--rw (local-or-truststore)
|  |  |  | +--:(local) {local-definitions-supported}?
|  |  |  | |  +--rw local-definition
|  |  |  | | +--rw public-key* [name]
|  |  |  | |+--rw name string
|  |  |  | |+--rw public-key-format
identityref
|  |  |  | |+--rw public-key   binary
|  |  |  | +--:(truststore) 
{central-truststore-supported,public-keys}?
|  |  |  |+--rw truststore-reference?   
ts:public-key-bag-ref
|  |  |  +--rw tls12-psks?empty 
{client-auth-tls12-psk}?
|  |  |  +--rw tls13-epsks?   empty 
{client-auth-tls13-epsk}?
So what are we expecting to define this authentication choice?

If there is only one client-id leaf needed inside client list, then why not 
directly define the client as leaf-list? Or would we like future extension to 
the client list definition?

BTW. There seems to exist some revision inconsistence warnings:
libyang warn: File name "ietf-alto-st...@2022-07-11.yang" does not match module 
revision "2023-02-10".
libyang warn: File name "ietf-a...@2022-10-24.yang" does not match module 
revision "2023-02-10".

Best Regards,
Qiufang

From: alto [mailto:alto-boun...@ietf.org] On Behalf Of Jensen Zhang
Sent: Friday, February 17, 2023 12:30 AM
To: alto@ietf.org
Subject: Re: [alto] I-D Action: draft-ietf-alto-oam-yang-03.txt

Hi ALTOers,

The revision -03 of draft-ietf-alto-oam-yang has been uploaded. In this new 
revision, the authors fix

Re: [alto] Comments on data source configuration in alto-oam

[maqiufang (A)]

Hi, Jensen

My understanding is that, if we’d like to take reactive mode (e.g., periodic 
push from yang datastore [1]) as an example,  ALTO-server receives stream of 
updates from a specified YANG datastore at a fixed interval without needing to 
poll. Suppose the publisher supports RESTCONF as transport mechanism, either a 
“initiate” or a “listen” container (defined in rcc:restconf-client-app-grouping 
[2]) can be configured to ask the ALTO-server which works as a RESTCONF-client 
here, to initiate connections to publisher (i.e., to establish dynamic 
subscription or configured subscription [3] to the RESTCONF-server) or just 
listen and wait for a call-home[4] connection (i.e., to receive configured 
subscription as a YANG-push receiver).

I have provided an example as attached, I am using a call-home connection as 
exmaple here, so that the alto-server only needs to listen on a specified port 
and wait for the periodic arrival of stream network topology data. Besides, the 
example yang file is also updated as attached according to our discussion in 
last Tuesday-night meeting.

[1] https://datatracker.ietf.org/doc/html/rfc8641
[2] https://datatracker.ietf.org/doc/draft-ietf-netconf-restconf-client-server/
[3] https://datatracker.ietf.org/doc/html/rfc8639
[4] https://datatracker.ietf.org/doc/rfc8071/


Best Regards,
Qiufang
From: Jensen Zhang [mailto:jingxuan.n.zh...@gmail.com]
Sent: Friday, January 20, 2023 10:56 AM
To: maqiufang (A) 
Cc: alto@ietf.org; draft-ietf-alto-oam-y...@ietf.org
Subject: Re: [alto] Comments on data source configuration in alto-oam

Hi Qiufang,

I am preparing the new revision in the GitHub repo [1]. I am going to merge 
your proposed updates on the "data-source" part. I hope we can have an example 
in the appendix to show how to use the new reactive mode. Do you have any 
references or suggestions?

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

Cheers,
Jensen


On Tue, Jan 17, 2023 at 4:46 PM Jensen Zhang 
mailto:jingxuan.n.zh...@gmail.com>> wrote:
Hi Qiufang,

Many thanks for your deep review. See my feedback inline.

On Tue, Jan 17, 2023 at 11:23 AM maqiufang (A) 
mailto:maqiufa...@huawei.com>> wrote:
Hi, all

I had a chance to take a deeper look at this -02 version  — not the other 
parts, but only the YANG model related to the data-source configuration, which 
I believe is the section 5.3.1 and Appendix A.1 in the current draft. Following 
are some contributor thoughts:

• I like the idea that we only define a very general list now and leave 
the parameters specific to each data source to be extended in future, while I 
am not convinced that the update-policy choice defined here is proper. My 
intuition is that for reactive mode, the alto server waits data feed without 
needing to poll. It could receive data as soon as it changes, but periodic 
collection could also be another mode.

I don't fully understand the feed-interval property in reactive mode. The 
data-source list actually configures a list of data source listeners in the 
ALTO server. Should this property be configured by the data source side, 
instead of the ALTO server side? Do you have any example of how the 
feed-interval is used by a concrete data source listener?


I question whether a Boolean type of reactive leaf is sufficient, and what if a 
false value is configured here? I would rather use an empty type.

Make sense. I like this change.


• I would like the update-policy choice to be defined outside 
data-source list (but not very strong feeling), it is not the property of 
data-source itself, but how the alto server get data from data-source.

If we move update-policy outside, could someone configure a data source without 
configuring its update-policy? If so, how does the ALTO server decide how to 
get data updates?

That said, my suggested data-source tree diagram is following:

…

 +--rw data-source* [source-id]

 |  +--rw source-id  string

 |  +--rw source-typeidentityref

 |  +--rw (source-params)?

 +--rw data-update-policy* [source-id]

 |  +--rw source-id-> ../../data-source/source-id

 |  +--rw (update-policy)?

 | +--:(reactive)

 | |  +--rw (reactive-mode)?

 | | +--:(on-change)

 | | |  +--rw on-changeempty

 | | +--:(period)

 | |+--rw feed-intervaluint32

 | +--:(proactive)

 |+--rw poll-interval  uint32

…

• Regarding the Appendix part, it seems to me that some parameters are 
still missing. The following tree diagram for a yang-datastore source example 
could be for the authors’ reference:

module: example-ietf-alto-data-source

  augment /alto:alto-server/alto:data-source/alto:source-params:

+--:(yang-datastore)

   +--rw source-server

  +--rw name?   inet:domain-name

  +--rw datastore   identityref

 

[alto] Comments on data source configuration in alto-oam

[maqiufang (A)]

Hi, all

I had a chance to take a deeper look at this -02 version  - not the other 
parts, but only the YANG model related to the data-source configuration, which 
I believe is the section 5.3.1 and Appendix A.1 in the current draft. Following 
are some contributor thoughts:

* I like the idea that we only define a very general list now and leave 
the parameters specific to each data source to be extended in future, while I 
am not convinced that the update-policy choice defined here is proper. My 
intuition is that for reactive mode, the alto server waits data feed without 
needing to poll. It could receive data as soon as it changes, but periodic 
collection could also be another mode. I question whether a Boolean type of 
reactive leaf is sufficient, and what if a false value is configured here? I 
would rather use an empty type.

* I would like the update-policy choice to be defined outside 
data-source list (but not very strong feeling), it is not the property of 
data-source itself, but how the alto server get data from data-source.
That said, my suggested data-source tree diagram is following:

...

 +--rw data-source* [source-id]

 |  +--rw source-id  string

 |  +--rw source-typeidentityref

 |  +--rw (source-params)?

 +--rw data-update-policy* [source-id]

 |  +--rw source-id-> ../../data-source/source-id

 |  +--rw (update-policy)?

 | +--:(reactive)

 | |  +--rw (reactive-mode)?

 | | +--:(on-change)

 | | |  +--rw on-changeempty

 | | +--:(period)

 | |+--rw feed-intervaluint32

 | +--:(proactive)

 |+--rw poll-interval  uint32

...

* Regarding the Appendix part, it seems to me that some parameters are 
still missing. The following tree diagram for a yang-datastore source example 
could be for the authors' reference:

module: example-ietf-alto-data-source

  augment /alto:alto-server/alto:data-source/alto:source-params:

+--:(yang-datastore)

   +--rw source-server

  +--rw name?   inet:domain-name

  +--rw datastore   identityref

  +--rw target-paths* [name]

  |  +--rw name string

  |  +---u yp:selection-filter-types

  +--rw protocol*   identityref

  +--rw restconf

  |  +---u rcc:restconf-client-app-grouping

  +--rw netconf

 +---u ncc:netconf-client-app-grouping

The difference between *conf-client-app-grouping and 
*conf-client-listen-stack-grouping is that the former also supports initiating 
connections to servers proactively, which I believe is the more common case.

All related YANG modules are attached.

Best Regards,
Qiufang


example-ietf-alto-data-source.yang
Description: example-ietf-alto-data-source.yang


ietf-alto@2022-10-24.yang
Description: ietf-alto@2022-10-24.yang
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] Some comments on ietf-alto module defined in draft-ietf-alto-oam-yang-00

[maqiufang (A)]

Hi, Jensen

 [significant snipping]

• For networkmap case, I don’t really understand “is-default” parameter 
defined here. If there are multiple network maps as the ALTO server resource, 
it would be good to allow to specify a default network map to interact with 
simple ALTO client which may only support to use single network map. Since I 
don’t see any network map list node in this model, so how to specify a default 
one? Any misunderstanding?
I am not sure I get your concern. Do you concern that "is-default" parameter 
may conflict with "filtered" parameter?
[Qiufang]No, sorry for being unclear. I have no concern that the “is-default” 
parameter may conflict with “filtered” parameter. I am curious how this 
parameter works. We allow an ALTO server to define multiple network maps and 
then specify a default one here, right? Then how to figure out a default 
network map if the operator just simply configure “is-default” to be true or 
false inside a “alto-network-params” container?
Besides, you are using a choice/case statement for ALTO information service, 
only one of the choice’s cases can be true and visible in the data tree, they 
could not co-exist at all. Does this mean that ALTO server can only be 
configured and provide s single resource?

I still do not get it. The "alto-networkmap-params" container is inside the 
choice/case of "resource-params/networkmap" which is inside the "resource" 
list. The ALTO server can be configured to provide multiple resources, but each 
resource can only be one of the cases in the "resource-params" choice.
Why you thought that "ALTO server can only be configured and provide s single 
resource"?
You have defined a “resource” list node to allow multiple resource 
configuration, so that would be okay! Thanks for your clarification, my bad for 
failing to notice that…
But the "is-default" parameter may still lead to some issues. When multiple 
network map resources have "is-default" configured to be true, the ALTO server 
needs to only choose one of them as the default. Do you have any suggestions to 
avoid this?
Yes, indeed. IMHO in one way we can just state in the description that this 
parameter can only be true for a single network map. If this parameter for 
multiple network map resources are configured as true, the server MUST choose 
one of them as default and ignore others. Another way is that we can just move 
this parameter out of the resource list, and change it to “default-network-map” 
with a resource-id type.

• For endpointprop case, should the leaf-list data node “prop-types” be 
the type of an arbitrary “string”? I think we should list the set of possible 
values here and allow it to be extensible.
Yes, they should be defined in the same way as the "cost-mode" and 
"cost-metric" are. Either IANA maintained or identityref.


• For proactive data source update policy, should the start and end 
time be allowed to configure here? Generally I think you can define the 
poll-interval as “mandatory true”, and start/end time as optional.
Interesting proposal. Shouldn't the update process be started once the YANG 
node is written, and be stopped once the YANG node is deleted? Could you have 
any examples for other monitoring tools that use the start and end time to 
control the data polling?
[Qiufang] If no start and end time configured, my understanding is that the 
network information fetch from the data source should be triggered once the 
“poll-interval” configuration is manipulated, and yes, stopped once the YANG 
node is deleted. But do we need to ensure that the ALTO server will not execute 
the data fetching forever even if the operator lose the connection with ALTO 
server? YANG-PUSH[RFC8639, RFC8641] has similar “anchor-time” and “stop-time” 
parameters, it’s a pub/sub mode, though, not a polling mechanism.

Thanks for sharing the YANG-PUSH example. But I think the "anchor-time" and 
"stop-time" in YANG-PUSH are different from the start and end time here.

"anchor-time" seems not to be expected to indicate when the push update starts, 
but to indicate an anchor point to make the push update align with in each 
period.
And "stop-time" is only used in the RPC.

Actually, I do still worry about adding start and end time to the data source 
polling. Because the expected behavior for our case is that each configured 
data source should be active and reflect the latest data. Consider an ALTO 
information resource attaches a data source that is already expired by its 
"stop-time", this ALTO information resource should be also expired. But the 
ALTO client cannot aware of this. It will lead to many potential issues.
Sure, make sense to me. Do we equate "poll-interval" parameter with the 
frequency at which ALTO information is refreshed?

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

Re: [alto] Some comments on ietf-alto module defined in draft-ietf-alto-oam-yang-00

[maqiufang (A)]

Hi, Jensen
Please see my reply inline.

From: Jensen Zhang [mailto:jingxuan.n.zh...@gmail.com]
Sent: Tuesday, July 12, 2022 3:54 PM
To: maqiufang (A) mailto:maqiufa...@huawei.com>>
Cc: 
draft-ietf-alto-oam-y...@ietf.org<mailto:draft-ietf-alto-oam-y...@ietf.org>; 
alto@ietf.org<mailto:alto@ietf.org>
Subject: Re: [alto] Some comments on ietf-alto module defined in 
draft-ietf-alto-oam-yang-00

Hi Qiufang,

Many thanks for your comments again.

On Mon, Jul 11, 2022 at 4:14 PM maqiufang (A) 
mailto:maqiufa...@huawei.com>> wrote:
Hi, all

I have reviewed the draft-ietf-alto-oam-yang-00 draft today, and have got some 
comments regarding ietf-alto YANG module defined in the draft.

Please feel free to reject/accept them:

• The “hostname” parameter, the type of this leaf is defined as 
inet:host, just a reminder that the inet:host in RFC 6991(and also in 
rfc6991-bis) is an union of inet:ip-address and inet:host-name. Is the authors’ 
intention here to also cover a type of ip-address? Or you just want to define 
it as inet:host-name?
Good point. Actually, "hostname" may not be helpful for the server setup. In 
version -01, we replace it with a more comprehensive "listen" parameter.
[Qiufang] Sure, I notice that you are trying to define some underlying protocol 
related configurations, which is good from my perspective. Since the WG is 
working on the ALTO protocol using HTTP/2, I wonder if a parameter to 
configure/indicate which HTTP version used by ALTO protocol is needed.

• the new type of cost-mode is defined as enumeration, which is 
unscalable (unless you want IANA to maintain it). Since additional cost modes 
may be defined in the future, “identityref” should be used here instead of an 
enumeration.

• The new type of cost-metric is defined as string, this is not proper 
from my perspective. All of the possible cost metrics defined in “ALTO Cost 
Metrics” IANA registry should be given, maybe an “identityref” type should also 
be used here?
You are right. Actually, this is still an open discussion. We are still 
debating whether we should move "cost-mode" and "cost-metric" to IANA 
maintained model or use "identityref". Here is the related thread [1]. It would 
be great if you could share your opinion.

[1] https://mailarchive.ietf.org/arch/msg/alto/auHDq8Ud1AFxL8KpA3kzHzwfEAA/
[Qiufang] I am not an expert on this, but it seems that we already have 
requested two “ALTO Cost Modes” and “ALTO Cost Metrics” new registries in the 
other two WG items, my intuition is that it would be awkward if the WG have to 
augment the existing module whenever a new cost mode/metric type is registered 
(otherwise there will be an inconsistent issue). IMHO it will be cheaper if we 
just create two IANA-maintained modules and state in the IANA consideration 
that whenever there is a new cost mode/metric is added to the “ALTO Cost 
Metrics/Modes” registry, then IANA must also update the modules itself.

• For networkmap case, I don’t really understand “is-default” parameter 
defined here. If there are multiple network maps as the ALTO server resource, 
it would be good to allow to specify a default network map to interact with 
simple ALTO client which may only support to use single network map. Since I 
don’t see any network map list node in this model, so how to specify a default 
one? Any misunderstanding?
I am not sure I get your concern. Do you concern that "is-default" parameter 
may conflict with "filtered" parameter?
[Qiufang]No, sorry for being unclear. I have no concern that the “is-default” 
parameter may conflict with “filtered” parameter. I am curious how this 
parameter works. We allow an ALTO server to define multiple network maps and 
then specify a default one here, right? Then how to figure out a default 
network map if the operator just simply configure “is-default” to be true or 
false inside a “alto-network-params” container?
Besides, you are using a choice/case statement for ALTO information service, 
only one of the choice’s cases can be true and visible in the data tree, they 
could not co-exist at all. Does this mean that ALTO server can only be 
configured and provide s single resource?

• For endpointprop case, should the leaf-list data node “prop-types” be 
the type of an arbitrary “string”? I think we should list the set of possible 
values here and allow it to be extensible.
Yes, they should be defined in the same way as the "cost-mode" and 
"cost-metric" are. Either IANA maintained or identityref.


• For proactive data source update policy, should the start and end 
time be allowed to configure here? Generally I think you can define the 
poll-interval as “mandatory true”, and start/end time as optional.
Interesting proposal. Shouldn't the update process be started once the YANG 
node is written, and be stopped once the YANG node i

[alto] Some comments on ietf-alto module defined in draft-ietf-alto-oam-yang-00

[maqiufang (A)]

Hi, all

I have reviewed the draft-ietf-alto-oam-yang-00 draft today, and have got some 
comments regarding ietf-alto YANG module defined in the draft.

Please feel free to reject/accept them:

* The "hostname" parameter, the type of this leaf is defined as 
inet:host, just a reminder that the inet:host in RFC 6991(and also in 
rfc6991-bis) is an union of inet:ip-address and inet:host-name. Is the authors' 
intention here to also cover a type of ip-address? Or you just want to define 
it as inet:host-name?

* the new type of cost-mode is defined as enumeration, which is 
unscalable (unless you want IANA to maintain it). Since additional cost modes 
may be defined in the future, "identityref" should be used here instead of an 
enumeration.

* The new type of cost-metric is defined as string, this is not proper 
from my perspective. All of the possible cost metrics defined in "ALTO Cost 
Metrics" IANA registry should be given, maybe an "identityref" type should also 
be used here?

* For networkmap case, I don't really understand "is-default" parameter 
defined here. If there are multiple network maps as the ALTO server resource, 
it would be good to allow to specify a default network map to interact with 
simple ALTO client which may only support to use single network map. Since I 
don't see any network map list node in this model, so how to specify a default 
one? Any misunderstanding?

* For endpointprop case, should the leaf-list data node "prop-types" be 
the type of an arbitrary "string"? I think we should list the set of possible 
values here and allow it to be extensible.

* For proactive data source update policy, should the start and end 
time be allowed to configure here? Generally I think you can define the 
poll-interval as "mandatory true", and start/end time as optional.

* Regarding the yang-datastore data source, are the authors referring 
to the xpath in the local ALTO server(which works as a restconf server here) 
datastore? Can it be a datastore inside any remote RESTCONF/NETCONF server?


Best Regards,
Qiufang

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

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

[maqiufang (A)]

Hi, all

I support the adoption of this draft which I believe provides a good starting 
point.

The following are some comments, apologizes if I’ve missed something.

1.   I still don't see any statistics related to R2 and R4 defined in 
Sec4.2. IMO it is important to record statistics related to server failures.

2.   The following performance statistics of the alto server may be 
considered, or just clarified to be out of scope:

· Total number of queries received

· Total number of successful/error responses

· Number of queries processed per second

· Average response time

· Usage of system resources such as CPU, memory, and storage

· Connection statistics

3.   Should HTTP-server related configuration be in our scope(e.g., 
cache-control, Retry-After)?

Best Regards,
Qiufang Ma
From: alto [mailto:alto-boun...@ietf.org] On Behalf Of Randriamasy, Sabine 
(Nokia - FR/Paris-Saclay)
Sent: Thursday, April 7, 2022 9:54 PM
To: Qiao Xiang ; 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

+1,
Best regards
Sabine

From: alto mailto:alto-boun...@ietf.org>> On Behalf Of 
Qiao Xiang
Sent: Thursday, April 7, 2022 11:17 AM
To: Luis M. Contreras 
mailto:contreras.i...@gmail.com>>
Cc: roland.sch...@telekom.de; 
draft-zhang-alto-oam-y...@ietf.org; 
IETF ALTO mailto:alto@ietf.org>>; 
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

[alto] Comments on draft-zhang-alto-oam-yang-01

[maqiufang (A)]

Hi, authors,

Thanks for writing this draft.
As Adrian mentioned, there is no YANG code in this document.
I tried to work it out according to the given YANG tree diagram. Please refer 
to the attachment, which I hope can help to make this work more complete.

In general, I think the scope still needs to clean up, i.e., what is in the 
scope, what is not in the scope. The relation between objectives and 
requirements are not clear. I think requirements should completely align with 
section 16 of RFC7285.
Requirements in Section 3.2 and Section 3.4 of RFC7971 should also be 
considered.

Here are few detailed comments:
1.Section 4
The requirements are only selected from section 16.1, section 16.2.2, section 
16.2.4, section 16.2.5, section 16.2.6, what about other sections?
Do we need to configure granularity of the topology map and cost map?
e.g., configure default two PIDs, default cost between source PID and dst PID?
How filter service is modelled? How do we set filter input as empty?
How do we model network information from other entities such as geo-location, 
or round trip time measurement?

How do we model using other protocol such as IGP BGP to collect information and 
fed into ALTO server

How do we provide monitoring information to service provider? E.g., monitoring 
correctness, responsive of ALTO server
How do we allow disable ALTO guidance for a portion of ALTO client by time, 
geographical region or other criteria?
2.Section 4
How logging and fault management is modelled in this draft?
Should we configure ALTO server to provide logging service? E.g., using syslog
Do we need to define control module to provide logging or fault management?
You might reference rfc8194 for example
3.Section 4.1 said:
"
Data model for performance monitoring for operation purpose
"
OAM or FCAPS should comprise of not only performance monitoring, but also fault 
management, security management, configuration management?
Do we leave fault management beyond scope of this document?
4.Section 4.1 said:
"
   *  Data structures for how to store/deliver ALTO information
  resources (e.g., network map, cost map, property map).
   *  Specific algorithms for ALTO information resource generation.
   *  Data structures for how to store information collected from data sources.

"
What is the relationship between bullet 1 and Bullet 3?
5.Section 4.2 title
What is the relation between requirements and Objectives?
6.Section 5.1
s/ adminstrated/administrated
7.Section 5.3
s/resoruce/resource
s/ altorithms/algorithm


Best Regards,
Qiufang Ma


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