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
