Subject: Re: [alto] PID Properties in ALTO

From: Ben Niven-Jenkins <[email-masked]>
Date: Tue, 7 Jun 2011 09:38:44 +0100

Rich,

Some questions inline.

On 27 May 2011, at 17:48, Richard Alimi wrote:

> Hi All,
> 
> Okay, third and final thread for discussion today :)  Another proposed
> extension to the ALTO protocol has been to associate properties (like
> we currently have with Endpoints) with PIDs.
> 
> A proposed use case in draft-penno-alto-cdn was to indicate what types
> of endpoints lived within a single PID. A more general mechanism to
> support this would be to allow properties to be associated with a PID
> as whole. In one light, this could be seen as an efficient way to
> query for the properties of all endpoints within a PID (in which
> membership in the PID determines the value of the property).

Would the properties of the PID be the intersection of the properties of all the End Points contained within the PID or is the semantic that only End Points with the exact same properties can be members of the PID?

> It could
> also be used to attach some semantic meaning to a PID (instead of
> being an opaque identifier) in particular deployments.
> One way to support this would be to provide an additional "PID
> Property" service, with a similar structure to the Endpoint Property
> Service. Basically, it would amount to defining a registry, allowing
> an ALTO Server to indicate its supported properties via capabilities,
> defining encodings for the request and response, etc.

What about the Network Map service? Would that return the PID properties along with the list of End Points contained in each PID?

> Thoughts about supporting this?

I can see use cases where having a property associated with a PID conveyed via a Network Map would be beneficial as an alternative to having structured PID names in order to convey that same information.

Ben

> 
> Thanks,
> Rich
> _______________________________________________
> alto mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/alto

---

From: Richard Alimi <[email-masked]>
Date: Wed, 8 Jun 2011 01:35:39 -0700

Hi Ben,

> Would the properties of the PID be the intersection of the properties of all the End Points contained within the PID or is the semantic that only End Points with the exact same properties can be me…

What I was thinking was that the protocol could would give the
messaging format for this, but not have any restrictions on the
relationship between endpoint properties and PID properties.  My
statement above was only an example of the benefit, and not
necessarily what needed to be done.  Other opinions are of course
welcome though :)

> What about the Network Map service? Would that return the PID properties along with the list of End Points contained in each PID?

That is one possibility. It could either be in the Network Map itself,
or a separate request.  I could imagine a client wishing to query
about properties but not the list of endpoints (which may be large),
so perhaps it makes sense to keep them separate.

> I can see use cases where having a property associated with a PID conveyed via a Network Map would be beneficial as an alternative to having structured PID names in order to convey that same inform…

Cool :)

Rich

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Mon, 13 Jun 2011 23:08:46 +0100

Rich,

> necessarily what needed to be done.  Other opinions are of course

Ok. I think the relationship does need to be defined somewhere but maybe it can be defined as part of the specification/registration of each PID property which would also provide more flexibility than a global rule.

> so perhaps it makes sense to keep them separate.

Ok. If it's a separate request I think it needs to include a "map-vtag" so that client's know which network map it corresponds to so they can tie the PID property list and network map together and ensure that the client's view of each resource doesn't get out of sync.

Ben

---

From: Richard Alimi <[email-masked]>
Date: Tue, 14 Jun 2011 21:34:33 -0700

Hi Ben,

> Ok. I think the relationship does need to be defined somewhere but maybe it can be defined as part of the specification/registration of each PID property which would also provide more flexibility t…

Sounds good to me.

> Ok. If it's a separate request I think it needs to include a "map-vtag" so that client's know which network map it corresponds to so they can tie the PID property list and network map together and…

Yes, good point.  We should indeed have the invariant in the protocol
that anything referencing a PID also needs the map-vtag as well.  This
is good example of where we need to be sure that is preserved.