Hi Richard and all,
I have some thoughts about capabilities definition in property map.
Currently, the capabilities is defined like this:
object {
DomainName domain-types<1..*>;
PropertyName prop-types<1..*>;
} PropertyMapCapabilities
It looks all good for IRD example in 7.3 in [EPM] because “ipv4” and “ipv6”
are all belong to Internet Address Domain. But I think this capabilities
definition does not expose the relationship between domain types and
property types. Different domain types may have different set of property
types and a same property name in different domain type may have different
meanings (section 2.5 in [EPM]).
Let us consider the following example, a client receives a IRD information
from a ALTO server,
“my-property-map”: {
…
“capabilities”: {
“domain-types”: [ “ipv4”, “pid” ],
“prop-types” : [ “country”, “state”, “property-only-for-domain-
type-pid”]
}
…
}
and this client may construct its filter property map request like below
since it does not know property “property-only-for-pid” is only for domain
type pid.
{
“entities”: [ “ipv4:192.0.2.0/26”, “ipv4:192.0.2.0/28” ],
“properties”: [ “property-only-for-domain-type-pid”]
}
Responses of this request will be always empty, while this client never
knows that it construct a meaningless request.
One potential solution is that we can define capabilities as a map, domain
-> {properties}.
object {
DomainName domain-types<1..*>;
DomainPropertyTypes domain-prop-types<1..*>;
} PropertyMapCapabilities
object {
[JSONString domain-type];
PropertyName prop-types<1..*>;
} DomainPropertyTypes;
The IRD information in above example can be modified like this:
“my-property-map”: {
…
“capabilities”: {
“domain-types”: [ “ipv4”, “pid” ],
“prop-types” : [
[“country”, “state”], // ipv4->{properties}
[“country”, “state”, “pid-specified-property”]] //
pid->{properties}
}
…
}
With additional information of the relationship between domain types and
properties types, the client will not send meaningless request any more. :)
Bests,
Shawn Lin
[EPM] https://datatracker.ietf.org/doc/html/draft-roome-alto-
unified-props-new
On Wed, Mar 29, 2017 at 4:21 AM, Y. Richard Yang <[email protected]> wrote:
> Dear all,
>
> As multiple discussions, we feel that the unified properties draft (),
> although not a working group draft, can be an important piece to help
> finish several remaining working items.
>
> For those who are not tracking the document, the design might appear to be
> simple: it is after all just a simple key-value map. When conducting a real
> design, many issues, many quite general, however, appear. Hence the design
> can benefit from good feedback from the good talents of this group. The
> objective of this email is to make clear the salient points of the current
> design. We will go over and discuss them Friday during the WG session.
>
> D1. The goal is to provide properties to entities.
>
> D2. Each entity must have an entity name to be identified. An entity name
> is a typed (domained) string, in a format of <domain>:<name>, e.g.,
> "ipv4:192.1.1.1", "pid:myid1", "ane:myane111". The <domain> provides
> essentially the type of the name.
>
> D3. There are essentially three types of domains: global, per-resource,
> per-query (dynamic):
>
> D3.1 ipv4 and ipv6 are global, in that they are not dependent on
> particular resources;
>
> D3.2 pid depends on a particular network map resource;
>
> D3.3 ane (abstract network element) may depend on a particular query of an
> ALTO resource. So far we cannot handle such case well. There can be
> multiple design options, but each adds more complexity.
>
> D4. Aggregation of entities is allowed, to improve scalability. Hence, an
> entity name may be either an individual entity or a set. An example is an
> IP prefix.
>
> D4.1 An implication of 4. is that we need to handle property inheritance.
> Multi-inheritance is tricky, as OOP multi-inheritance demonstrated. So far
> longest prefix matching (LPM) avoids the problem. But we need to decide if
> we want to have a spec on future design of this aspect.
>
> D5. Property names are in a global namespace, to enforce global,
> consistent usage of property names.
>
> It is not a long list but contains many interesting design points.
>
> Looking forward to good discussions soon!
>
> Richard
>
>
>
> _______________________________________________
> alto mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/alto
>
>
_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto
