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

["maqiufang (A)" <[e-mail]>]

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