Hi all, In general, I support fully this. I have some minor suggestions/questions.
> o (Standards Track) Protocol extensions to convey a richer set of > attributes to allow applications to determine not only "where" to > connect but also "when" to connect. Such additional information > will be related both to endpoints (e.g. conveying server load and > cache geo-location information for CDN use cases) and to > endpoint-to-endpoint costs (e.g. bandwidth calendaring to represent > time-averaged cost values in datacenter networks). > > The working group will specify such extension in coordination with > other working groups that are also working on the related use cases > (e.g. cdni, i2rs, lmap). While I fully agree that the "when" to connect is a very important use case, I would prefer a definition that does not imply that "when" is the only novelty. Also, I think it would be better to start with examples that are related to (abstract) topology. For instance, what about: o (Standards Track) Protocol extensions to convey a richer set of attributes to allow applications an endpoint selection not only based on current network routing cost. This includes guidance not only "where" to connect but also "when" to connect. Such additional information will be related both to endpoints (e.g. conveying cache geo-location or server load information for CDN use cases) and to endpoint-to-endpoint costs (e.g. bandwidth calendaring to represent time-averaged cost values in datacenter networks). > o (Informational) A survey of techniques to formalize the structure > of a network graph (that can derived from a set of related ALTO > network and cost maps) in a format that would facilitate advanced > graph computation. Such survey will cover both models used in > popular open-source software (e.g. NetworkX, Blueprints) and models > being considered in other working groups (e.g. netmod, i2rs). Maybe s/Blueprints/tinkerpop blueprints/ ? "Blueprints" is not a very specific term. But perhaps we could just remove the examples - I think we already agree that neither NetworkX nor tinkerpop blueprints will completely address our needs. > After these criteria are met, the importance of the data will be > considered for prioritizing standardization work, for example the > number of operators and clients that are likely to be able to provide > or use that particular data. In any case, this WG will not propose > standards on how congestion is signaled, remediated, or avoided, and > will not deal with information representing instantaneous network > state. This sentence is already in the original charter. I am not a native speaker, and as a result I wonder about the semantics of "instantaneous", in particular regarding the up-to-dateness of the information. Example: If the ALTO server polls the routing topology routing rather frequently (e.g., via BGP-LS), the ALTO maps and guidance can be entirely up-to-date, in particular if routing changes only sporadically in a network. To me, at least in such a rather static cases, the ALTO maps would then represent the "instantaneous" routing state, because the ALTO maps are fully up-to-date. Obviously, since ALTO abstracts the maps, it doesn't represent the exact routing data - "up-to-date" here implies that the input data used to calculate the map has not changed, i.e., any new update and data retrieval would result in the same abstracted map. Wouldn't the phrasing "... and will not deal with information representing transient network state" be more appropriate? (Rapid changes are clearly a challenge for ALTO and out-of-scope.) Or, for instance, "... and clients must not assume that the information represents instantaneous network state"? (A client cannot know whether the ALTO information is really up-to-date.) > Milestones Do we really need separate deadlines for the WGLC? The current ALTO charter lists WGLCs as well, so this continues the current way of dealing with WGLC, but to me two milestones per planned document seem partly redundant. In TCPM we usually only have one milestone for a documents, unless special handling is needed. Just as a thought... Thanks Michael _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
