Hi all, Several of us are reviewing the documents in the WG. Here is one common issue: We see that quite a few documents depend on encoding the types of the elements in a cost map. This is a complexity that the based protocol RFC7285 identifies and hence decided to make the type the generic type JSONValue. But in the spirit of being strong typed, a specific cost map needs an indication of the type. For those who need some review, please see:
- Cost Map response: https://tools.ietf.org/html/rfc7285#section-11.2.3.6 Requirements: media-type: application/alto-costmap+json meta: MUST include cost-type and dependent-tag of the network map data: "An implementation of the protocol in this document SHOULD assume that the cost is a JSONNumber and fail to parse if it is not, unless the implementation is using an extension to this document that indicates when and how costs of other data types are signaled." - Filtered Cost Map response: https://tools.ietf.org/html/rfc7285#section-11.3.2 Defined as the same as Cost Map. - Endpoint Cost Service: https://tools.ietf.org/html/rfc7285#section-11.5.1 media-type: application/alto-endpointcost+json meta: "The "meta" field of an endpoint cost response MUST include the "cost- type" field, to indicate the cost type used." The current definition of cost-type has two components: cost-mode and cost-metric, and cost-mode has two values defined: numerical and ordinal, both indicate a single number. At the same time, multiple active drafts ( https://datatracker.ietf.org/wg/alto/documents/) need compound types for the elements of a cost map: - [multi-cost] This draft is probably the one which we need to resolve the issue the most urgent. Assume that it uses the current alto-costmap+json media type, then it cannot satisfy the requirement of "meta" including cost-type. - [cost-calendar] Cost calendar requires a compound data type as well. - [fcs] fcs depends on multi-cost and hence can have an issue as well. - [path-vector] The current definition of path-vector needs a vector of network elements. - [te-metrics] It appears that this document is fine, but may need to watch on related consistency issues. The preceding is not a minor syntax/encoding issue. How to handle types is a basic problem. Conceptually, a cost map, as in the base protocol is param'ed type: Map< String, Map< String, ElemType > > (Note: Some may argue that String above should be typed identifier.) So far, we have defined ElemType to be JSONValue, and used the cost-type to indicate more specifics: if meta.cost-type.cost-mode == "numerical" ElemType is float else if meta.cost-type.mode == "ordinal" ElemType is non-negative int My personal feeling is that we may need to start to introduce new cost-mode values to allow generic types. For those who are PL experts, it is a good chance to chime in. It is an important issue that the WG may want to work together to achieve a consistent, extensible design. Cheers, Richard References: - [multi-cost] https://datatracker.ietf.org/doc/draft-ietf-alto-multi-cost/ - [cost-calendar] https://datatracker.ietf.org/doc/draft-randriamasy-alto-cost-calendar/ - [fcs] https://datatracker.ietf.org/doc/draft-gao-alto-fcs/ - [path-vector] https://datatracker.ietf.org/doc/draft-yang-alto-path-vector/ - [te-metrics] https://datatracker.ietf.org/doc/draft-wu-alto-te-metrics/
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
