Dear WG,
In the process to revise UP to address the comments and make the protocol
as clean as possible, the authors identify one technical issue which we
need WG opinions.
Specifically, it is related to response (Sec. 5.6) to a filtered property
map.
The related new text:
" The response MUST indicate an error, using ALTO protocol error handling,
as defined in Section 8.5 of [RFC7285], if the request is invalid.
Specifically, a Filtered Property Map request can be invalid as
follows:
o An entity address in "entities" in the request is invalid if:
* The domain of this entity is not defined in the "entity-domain-
types" capability of this resource in the IRD;
* The entity address is an invalid address in the entity domain.
A valid entity address is never an error, even if this Filtered
Property Map resource does not define any properties for it.
If an entity address in "entities" in the request is invalid, the
ALTO server MUST return an "E_INVALID_FIELD_VALUE" error defined
in Section 8.5.2 of [RFC7285], and the "value" field of the error
message SHOULD indicate this entity address.
o A property name in "properties" in the request is invalid if this
property name is not defined in the "property-types" capability of
this resource in the IRD.
It is not an error that the Filtered Property Map resource does
not define a requested property's value for a particular entity.
In this case, the ALTO server MUST omit that property from the
response for that endpoint.
If a property name in "properties" in the request is invalid, the
ALTO server MUST return an "E_INVALID_FIELD_VALUE" error defined
in Section 8.5.2 of [RFC7285]. The "value" field of the error
message SHOULD indicate the property name.
The response to a valid request is the same as for the property map
(see Section 4.6), except that it only includes the entities and
properties requested by the client.
It is important that the Filtered Property Map response MUST include
all inherited property values for the specified entities. A Full
Property Map may skip a property P for an entity A if P can be
derived using inheritance from another entitiy B. A Filtered
Property Map request may include only A but not B. In such a case,
the property B MUST be included in the response for A.
[QUESTION to WG: Need to make a decision.] It is possible that the
entities in
the response are different from the entities in the request.
Consider a request for property P of entity A (e.g.,
ipv4:192.0.2.0/31). Assume that P has value v1 for
A1=ipv4:192.0.2.0/32 and v2 for A2=ipv4:192.0.2.1/32. Then, the
response will include entities A1 and A2, instead of the request
entity A.
An alternative design is to not enforce this decomposition. The authors feel
that the current revision is better but is open to WG guidance.
Thanks!
Richard
On Fri, Jun 29, 2018 at 1:29 PM <[email protected]> wrote:
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Application-Layer Traffic Optimization WG
> of the IETF.
>
> Title : Unified Properties for the ALTO Protocol
> Authors : Wendy Roome
> Shiwei Dawn Chen
> Sabine Randriamasy
> Y. Richard Yang
> Jingxuan Jensen Zhang
> Filename : draft-ietf-alto-unified-props-new-04.txt
> Pages : 30
> Date : 2018-06-29
>
> Abstract:
> This document extends the Application-Layer Traffic Optimization
> (ALTO) Protocol [RFC7285] by generalizing the concept of "endpoint
> properties" to domains of other entities, and by presenting those
> properties as maps, similar to the network and cost maps in ALTO.
>
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-alto-unified-props-new/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-alto-unified-props-new-04
> https://datatracker.ietf.org/doc/html/draft-ietf-alto-unified-props-new-04
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-alto-unified-props-new-04
>
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> alto mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/alto
>
--
--
=====================================
| Y. Richard Yang <[email protected]> |
| Professor of Computer Science |
| http://www.cs.yale.edu/~yry/ |
=====================================
_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto
