An alternative would be to use the dependency mechanism in the IRD. Then, if an ALTO Server provides two endpoint property services, it can explicitly define which network map the endpoint property service is for without needing resource IDs to be query parameters filled in by the client.
On Fri, Jul 26, 2013 at 1:32 PM, Y. Richard Yang <[email protected]> wrote: > Hi Wendy, > > Your cases do point out that it can be a better, more general solution > that filtering/some end point properties can include the resource id(s) in > the input parameter to indicate the base/scope. > > Regarding the encoding pid.network-map-resource-id, its syntax is not > conventional, because the operator "." typically is not used in this way, > and hence could be confusing. > > Richard > On Jul 26, 2013 3:04 PM, "Wendy Roome" <[email protected]> wrote: > >> Richard, >> >> That would work, although adding a "network map resource ID" parameter to >> the EPS resource begs the question of why doesn’t a filtered cost map >> resource have a similar parameter, as opposed to being bound to a specific >> network map. >> >> How about the following alternative: encode the network map name into the >> property name. Eg, >> >> "pid" means the endpoint's PID in the default network map (iff one >> is defined) >> "pid.network-map-resource-id" means return the endpoint's PID in >> that network map (iff it exists) >> >> A complication is that EPS must return the vtag when it returns a pid >> property, and it can only return one vtag for all pid properties. One >> solution is to restrict each EPS request to PIDs from a single network map. >> That's not elegant, but it's simple, and I don't think it would be a >> hardship for any client. >> >> - Wendy Roome >> >> From: "Y. Richard Yang" <[email protected]> >> Date: Fri, July 26, 2013 14:20 >> To: Wendy Roome <[email protected]> >> Cc: IETF ALTO <[email protected]> >> Subject: Re: [alto] Endpoint property service, network maps and the PID >> property >> >> Hi Wendy, >> >> On Jul 26, 2013 8:35 AM, "Wendy Roome" <[email protected]> >> wrote: >> > >> > Two questions. First, must an endpoint property service depend on a >> > network map? That is, can a server define one that doesn't "use" a >> > network map? After all, except for the PID, endpoint properties are >> tied >> > to the endpoint address, not the network map. >> >> Agree with your assessment. It depends on the property. Some examples not >> tied to a network map are Metered or not, subscribed bw, or rack number in >> a previous DC example. >> > >> > Second, "{10.3.1} Endpoint Property" says: >> > >> > "If an ALTO Server provides one or more Endpoint Property resources, >> then >> > at least one MUST provide the ¹pid¹ property." >> > >> > >> > What if there are several network maps? If a server provides that >> service >> > for one map, must it provide that for every map? >> > >> > One possible restatement is, >> > >> > "If an ALTO Server provides one or more Endpoint Property resources that >> > depend on a specific network map, then at least one of those resources >> > MUST provide the ¹pid¹ property for that network map." >> > >> > Another possibility is just drop that requirement altogether, and let >> the >> > server decide if it wants to offer the "pid" property. >> >> Good observation. The requirement of adding pid came from a previous >> review. Suppose we keep the requirement. I see your observed problem of >> multiple network maps, and if the request specifies only pid, which network >> map. Given that we will likely (1) require at least one network map, (2) >> specify one as default, then the response to a pid property query returns >> the result based on the default map. We should allow the pid query to >> include the resource id of a specific network map to handle the general >> case. Does this address the problem? >> >> Thanks! >> Richard >> > >> > - Wendy Roome >> > >> > >> > >> > >> > _______________________________________________ >> > alto mailing list >> > [email protected] >> > https://www.ietf.org/mailman/listinfo/alto >> > > _______________________________________________ > alto mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/alto > >
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
