Hi, Jensen Please see my reply inline. From: Jensen Zhang [mailto:[email protected]] Sent: Tuesday, July 12, 2022 3:54 PM To: maqiufang (A) <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> 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) <[email protected]<mailto:[email protected]>> 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 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. Best Regards, Qiufang • 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? That is a very good point. In version -01, we have added additional parameters to configure if the data source is from the local YANG datastore or a remote RESTCONF server. Thanks, Jensen Best Regards, Qiufang
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
