Hi Qiufang, On Wed, Jul 13, 2022 at 9:48 AM maqiufang (A) <[email protected]> wrote:
> Hi, Jensen > > Please see my reply inline. > > > > *From:* Jensen Zhang [mailto:[email protected] > <[email protected]>] > *Sent:* Tuesday, July 12, 2022 3:54 PM > *To:* maqiufang (A) <[email protected]> > *Cc:* [email protected]; [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]> > 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. > Thanks for your suggestion. I think the HTTP version should be covered in this model. But we need to take care and have more discussions with other coauthors of the draft-ietf-alto-new-transport document on which parameters should be considered. > · 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. > Thanks for sharing your opinion. We will take care of your comments in the next revision. > · 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"? 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? > · 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. Best, Jensen > > > 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
