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. > · 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/ > · 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? > · 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? > · 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
