[alto] alto-protocol-11 vs. alto-reqs-14

[Sebastian Kiesel <[e-mail]>]

Dear all,

I tried to match draft-ietf-alto-protocol-11.txt against
draft-ietf-alto-reqs-14.txt. Results see below.



A line

REQ. ARv14-X:   Full compliant : Y.Z

is to be read as:

The requirement X from draft-ietf-alto-reqs-14.txt
is fulfilled because of the mechanisms or rules specified 
in section Y.Z of draft-ietf-alto-protocol-11.txt



"There is no ..." is to be read as "I could not find ... in the document"



Thanks,
Sebastian



>    REQ.  ARv14-1: The ALTO service is provided by one or more ALTO
>    servers.  It may be queried by ALTO clients seeking guidance for
>    selecting appropriate resource providers.  ALTO clients and ALTO
>    servers MUST implement an ALTO client protocol.  An ALTO client
>    protocol MUST be able to transmit ALTO queries from an ALTO client to
>    an ALTO server, and it MUST be able to transmit the corresponding
>    ALTO replies from the ALTO server to the ALTO client.

REQ. ARv14-1:   Full compliant : 7.2

>    The detailed specification of an ALTO client protocol is out of the
>    scope of this document.  In fact, this document does not even assume
>    that there is only one single protocol specification.  However, this
>    document enumerates requirements for ALTO, to be considered when
>    specifying, assessing, or comparing protocols and implementations.
> 
> 3.1.2.  Host Group Descriptor Support
> 
>    The ALTO guidance is based on the evaluation of several resource
>    providers or groups of resource providers, considering one or more
>    rating criteria.  The resource providers or groups of resource
>    providers are characterized by means of host group descriptors.
> 
>    REQ.  ARv14-2: The ALTO client protocol MUST support the usage of
>    multiple host group descriptor types.

REQ. ARv14-2:   Full compliant : 7.5.3.1

>    REQ.  ARv14-3: ALTO clients and ALTO servers MUST clearly identify
>    the type of each host group descriptor sent in ALTO queries or
>    responses.

REQ. ARv14-3:   Full compliant : 7.5.3.2.3.

>    REQ.  ARv14-4: An ALTO client protocol MUST support the host group
>    descriptor types "IPv4 address prefix" and "IPv6 address prefix".
>    They can be used to specify the IP address of one host, or an IP
>    address range (in CIDR notation) containing all hosts in question.

REQ. ARv14-4:   Full compliant : 7.5.3.3.1., 7.5.3.3.2.

>    REQ.  ARv14-5: An ALTO client protocol MUST be extensible to enable
>    support of other host group descriptor types in future.  An ALTO
>    client protocol specification MUST define an appropriate procedure
>    for adding new host group descriptor types, e.g., by establishing an
>    IANA registry.

REQ. ARv14-5:   Partially compliant : 7.5.3.1 says: "Extension documents
    may define additional Address Types." but it does not define what
    kind of document is required (just an Internet-Draft, or
    Informational RFC, ...)

>    REQ.  ARv14-6: For host group descriptor types other than "IPv4
>    address prefix" and "IPv6 address prefix", the host group descriptor
>    type identification MUST be supplemented by a reference to a
>    facility, which can be used to translate host group descriptors of
>    that type to IPv4/IPv6 address prefixes, e.g., by means of a mapping
>    table or an algorithm.

REQ.  ARv14-6:   Partially compliant, with comment: In addition
    to IPv4/6 addresses/prefixes the document only defines one
    host group descriptor type, namely PIDs. The mapping mechanism
    from IP prefixes to PIDs ("Network Map") is described in 
    4. and 7.7.1.1.

    The document allows the definition of additional host group 
    descriptor types by means of extension documents (see ARv14-5),
    but it does not mention the mapping mechanism for them at all.

    I propose:
    1.) add a clarification in section 7.5.3.1 that the extension
    documents not only have to define new Address Types but also
    an appropriate mapping mechansim.

    2.) maybe we should spend a moment and think about whether
    the base protocol needs at least some basic infrastrucure (e.g.,
    pre-defined path names, or a standard algorithm to be execuded if a
    TypedEndpointAddr of unknown type is encountered, etc.) that
    makes defining such a mapping mechanism easier.

    3.) should section 9.4. stay in the document? It discusses 
    alternatives for mapping IP to ASN - if we can't decide that
    we want to specify exactly one of these alternatvies and add
    it to the base protocol, it is probably better to move the whole
    section to our deployment considerations document. 

>    REQ.  ARv14-7: Protocol functions for mapping other host group
>    descriptor types to IPv4/IPv6 address prefixes SHOULD be designed and
>    specified as part of an ALTO client protocol, and the corresponding
>    address mapping information SHOULD be made available by the same
>    entity that wants to use these host group descriptors within an ALTO
>    client protocol.  However, an ALTO server or an ALTO client MAY also
>    send a reference to an external mapping facility, e.g., a translation
>    table to be obtained via an alternative mechanism.

REQ.  ARv14-7:  see discussion of ARv14-6.

    Section 7.5.3.1. specifies the type 'AddressType' but no indication
    is given what to do if it is not one of the well-defined types given
    in this document. One might argue that this issue belongs to the
    "extension documents" and that therefore draft-ietf-alto-protocol-11
    is compliant to this requirement, but adding some base infrastrucure
    to the base protocol might be reasonable (see above).

>    REQ.  ARv14-8: An ALTO client protocol specification MUST define
>    mechanisms that can be used by the ALTO server to indicate that a
>    host group descriptor used by the ALTO client is of an unsupported
>    type, or that the indicated mapping mechanism could not be used.

REQ.  ARv14-8:  Compliant, with comment: E_JSON_VALUE_TYPE defined
    in 7.4.3. can be used, though it might be useful to define an
    own, less generic error message.
> 
>    REQ.  ARv14-9: An ALTO client protocol specification MUST define
>    mechanisms, which can be used by the ALTO client to indicate that a
>    host group descriptor used by the ALTO server is of an unsupported
>    type, or that the indicated mapping mechanism could not be used.

REQ.  ARv14-9:  Compliant, with comment: E_JSON_VALUE_TYPE defined
    in 7.4.3. can be used, though it might be useful to define an
    own, less generic error message.

> 3.1.3.  Rating Criteria Support
> 
>    REQ.  ARv14-10: An ALTO client protocol specification MUST define a
>    rating criterion that can be used to express and evaluate the
>    "relative operator's preference."  This is a relative measure, i.e.,
>    it is not associated with any unit of measurement.  A more-preferred
>    rating according to this criterion indicates that the application
>    should prefer the respective candidate resource provider over others
>    with less-preferred ratings (unless information from non-ALTO sources
>    suggests a different choice, such as transmission attempts suggesting
>    that the path is currently congested).  The operator of the ALTO
>    server does not have to disclose how and based on which data the
>    ratings are actually computed.  Examples could be: cost for peering
>    or transit traffic, traffic engineering inside the network, and other
>    policies.

REQ.  ARv14-10: Full compliant : 5.1.1.1

>    REQ.  ARv14-11: An ALTO client protocol MUST be extensible to enable
>    support of other rating criteria types in future.  An ALTO client
>    protocol specification MUST define an appropriate procedure for
>    adding new rating criteria types, e.g., by establishing an IANA
>    registry.

REQ.  ARv14-11:  Full compliant: 5.1.1., 10.2.

>    REQ.  ARv14-12: ALTO client protocol specifications MUST NOT define
>    rating criteria closely related to the instantaneous network
>    congestion state, i. e., rating criteria that have the primary aim to
>    serve as an alternative to established congestion control strategies,
>    such as using TCP-based transport.
> 
>       One design assumption for ALTO is that it is acceptable that the
>       host characteristics attributes, which are stored and processed in
>       the ALTO servers for giving the guidance, are updated rather
>       infrequently.  Typical update intervals may be several orders of
>       magnitude longer than the typical network-layer packet round-trip
>       time (RTT).  Therefore, ALTO cannot be a replacement for TCP-like
>       congestion control mechanisms.

REQ. ARv14-12:  Full compliant : no such attribute is defined in
    draft-ietf-alto-protocol-11

>    REQ.  ARv14-13: Applications using ALTO guidance MUST NOT rely solely
>    on the ALTO guidance to avoid causing network congestion.  Instead,
>    applications MUST use other appropriate means, such as TCP based
>    transport, to avoid causing excessive congestion.

REQ. ARv14-13:  Not applicable: This requirement is not about the
    ALTO Client Protocol (specification|implementation) itself,
    but about the application using it.

>    REQ.  ARv14-14: In the target-independent query mode, the ALTO query
>    message SHOULD allow the ALTO client to express which host
>    characteristics attributes should be returned.

REQ.  ARv14-14:  Full compliant: 7.7.2.2

>    REQ.  ARv14-15: In the target-aware query mode, the ALTO query
>    message SHOULD allow the ALTO client to express which rating criteria
>    should be considered by the server, as well as their relative
>    relevance for the specific application that will eventually make use
>    of the guidance.  The corresponding ALTO response message SHOULD
>    allow the ALTO server to express which rating criteria have been
>    considered when generating the response.

REQ.  ARv14-15:  Full compliant: 7.7.4.1.3, 7.7.4.1.5

>    REQ.  ARv14-16: An ALTO client protocol specification MUST define
>    mechanisms, which can be used by the ALTO client and the ALTO server
>    to indicate that a rating criteria used by the other party is of an
>    unsupported type.

REQ.  ARv14-16:  Full compliant: 7.4.3.

> 3.1.4.  Placement of Entities and Timing of Transactions
> 
>    With respect to the placement of ALTO clients, several modes of
>    operation exist:
> 
>    o  One mode of ALTO operation is that an ALTO client may be embedded
>       directly in the resource consumer, i.e., the application protocol
>       entity that will eventually initiate data transmission to/from the
>       selected resource provider(s) in order to access the desired
>       resource.  For example, an ALTO client could be integrated into
>       the peer of a P2P application that uses a distributed algorithm
>       such as "query flooding" for resource discovery.
> 
>    o  Another mode of operation is to integrate the ALTO client into a
>       third party such as a resource directory.  This third party may
>       issue ALTO queries to solicit preference on potential resource
>       providers, considering the respective resource consumer.  For
>       example, an ALTO client could be integrated into the tracker of a
>       tracker-based P2P application, in order to request ALTO guidance
>       on behalf of the peers contacting the tracker.
> 
>    REQ.  ARv14-17: An ALTO client protocol MUST support the mode of
>    operation in which the ALTO client is directly embedded in the
>    resource consumer.

REQ.  ARv14-17: Full Compliant: 8.2, 8.3

>    REQ.  ARv14-18: An ALTO client protocol MUST support the mode of
>    operation in which the ALTO client is embedded in a third party.
>    This third party performs queries on behalf of resource consumers.

REQ.  ARv14-18:  Full Compliant: 8.1

>    REQ.  ARv14-19: An ALTO client protocol MUST be designed in a way
>    that the ALTO service can be provided by an entity which is not the
>    operator of the underlying IP network.

REQ.  ARv12-19:  Full compliant: The ALTO protocol is based on HTTP
    (Sec.  6).  HTTP can be used to access servers anywhere in the 
    Internet, which are operated by arbitrary entities.  No additional
    single-domain or link-layer-coupled mechanisms (e.g. DHCP, IP
    multicasting/broadcasts, etc.) are mandatory.

>    REQ.  ARv14-20: An ALTO client protocol MUST be designed in a way
>    that different instances of the ALTO service operated by different
>    providers can coexist.

REQ.  ARv14-20:  Full compliant: The ALTO protocol is based on HTTP
    (Sec. 6). Servers operated by different entities can coexist.

    The ALTO server discovery mechanism, which is out of the scope of
    this document, may need additional mechanisms for selecting the
    desired ALTO server operator.

>    REQ.  ARv14-21: An ALTO client protocol specification MUST specify at
>    least one query mode, either the target-aware or the target-
>    independent query mode.

REQ.  ARv14-21:  Full compliant.  The target-independent query mode
    is implemented by the Network Map (7.7.1.1) and the Cost Map
    (7.7.1.2), which MUST be supported.

>    REQ.  ARv14-22: An ALTO client protocol specification SHOULD specify
>    both the target-aware and the target-independent query mode.  If an
>    ALTO client protocol specification specifies more than one query
>    mode, it MUST define at least one of these modes as REQUIRED to
>    implement by ALTO Clients and ALTO Servers.  Furthermore, it MUST
>    specify an appropriate protocol mechanism for negotiating between
>    ALTO Client and ALTO Server, which query mode to use.

REQ.  ARv14-22:  Full compliant.  The target-independent query mode MUST
    be supported (see ARv14-21). The target-aware query mode is
    implemented by the Endpoint Property Service, which MAY be provided
    by an ALTO server (7.7.3.1) and the Endpoint Cost Service, which MAY
    be provided by an ALTO server (7.7.4.1).


>    REQ.  ARv14-23: An ALTO client protocol SHOULD support version
>    numbering, TTL (time-to-live) attributes, and/or similar mechanisms
>    in ALTO transactions, in order to enable time validity checking for
>    caching, and to enable comparisons of multiple recommendations
>    obtained through redistribution.

REQ.  ARv14-23:  Partially compliant: Network Map Version Tag defined
    in 5.3.  TTL attribute defined in the underlying HTTP 
    ("expires"/"s-maxage" headers).

    There used to be an own section "8. Redistributable Responses"
    in draft-ietf-alto-protocol-10.txt, which has been removed in -11

    There is a reference to draft-gu-alto-redistribution-03, which
    has expired January 13, 2011, and which does not contain a
    specification of such protocol elements.

>    REQ.  ARv14-24: An ALTO client protocol SHOULD allow the ALTO server
>    to add information about appropriate modes of re-use to its ALTO
>    responses.  Re-use may include redistributing an ALTO response to
>    other parties, as well as using the same ALTO information in a
>    resource directory to improve the responses to different resource
>    consumers, within the specified lifetime of the ALTO response.  The
>    ALTO server SHOULD be able to express that
> 
>    o  no re-use should occur
> 
>    o  re-use is appropriate for a specific "target audience", i.e., a
>       set of resource consumers explicitly defined by a list of host
>       group descriptors.  The ALTO server MAY specify a "target
>       audience" in the ALTO response, which is only a subset of the
>       known actual "target audience", e.g., if required by operator
>       policies
> 
>    o  re-use is appropriate for any resource consumer that would send
>       (or cause a third party sending on behalf of it) the same ALTO
>       query (i.e., with the same query parameters, except for the
>       resource consumer ID, if applicable) to this ALTO server
> 
>    o  re-use is appropriate for any resource consumer that would send
>       (or cause a third party sending on behalf of it) the same ALTO
>       query (i.e., with the same query parameters, except for the
>       resource consumer ID, if applicable) to any other ALTO server,
>       which was discovered (using an ALTO discovery mechanism) together
>       with this ALTO server
> 
>    o  re-use is appropriate for any resource consumer that would send
>       (or cause a third party sending on behalf of it) the same ALTO
>       query (i.e., with the same query parameters, except for the
>       resource consumer ID, if applicable) to any ALTO server in the
>       whole network

REQ.  ARv14-24:  Partially compliant: first and last option supported
    by HTTP mechanisms. Second and third option relied on the now-removed
    section 8 of draft-ietf-alto-protocol-10

>    REQ.  ARv14-25: An ALTO client protocol MUST support the transport of
>    ALTO transactions even if the ALTO client is located in the private
>    address realm behind a network address translator (NAT).  There are
>    different types of NAT, see [RFC4787] and [RFC5382].

REQ.  ARv14-25:  Full compliant: The ALTO protocol is based on HTTP
    (Sec.  6).  Allowing HTTP traffic is one of the most basic requirements
    for all types of NAT. For detection of "public" IP address see 9.3.

> 3.1.5.  Protocol Extensibility
> 
>    REQ.  ARv14-26: An ALTO client protocol MUST include support for
>    adding protocol extensions in a non-disruptive, backward-compatible
>    way.

REQ.  ARv14-26:  Full compliant: 10.1


>    REQ.  ARv14-27: An ALTO client protocol MUST include protocol
>    versioning support, in order to clearly distinguish between
>    incompatible versions of the protocol.

REQ.  ARv14-27:  NOT compliant. There is no version field.
    7.6. states: "Future extensions or
    versions of the ALTO Protocol SHOULD be accomplished by extending
    existing media types or adding new media types, but retaining the
    same format for the Information Resource Directory."

    As workaround, one could define new media types such as
    alto-directory_v2_0+json   or
    alto2-directory+json

> 3.1.6.  Error Handling and Overload Protection
> 
>    REQ.  ARv14-28: An ALTO client protocol MUST use TCP based transport.

REQ.  ARv14-28:  Full compliant.  Protocol is based on HTTP (6.), which
    does not neccessarily run on top of TCP (see 1.4. of RFC 2616), but
    de-facto always does.


side note: IESG evaluation of the requirements document likely will
result in this requirement being changed to something like:

REQ.  ARv15-28 An ALTO client protocol MUST use a congestion-aware              
transport protocol, e.g., TCP.                                                  

but this will not cause any problem here.


>    REQ.  ARv14-29: An ALTO client protocol specification MUST specify
>    mechanisms, or detail how to leverage appropriate mechanisms provided
>    by underlying protocol layers, which can be used by an ALTO server to
>    inform clients about an impending or occurring overload situation,
>    and request them to throttle their query rate.
> 
>    In particular, a simple form of throttling is to let an ALTO server
>    answer a query with an error message advising the client to retry the
>    query later (e.g, using a protocol function such as HTTP's Retry-
>    After header ([RFC2616], section 14.37).  Another simple option is to
>    actually answer the query with the desired information, but adding an
>    indication that the ALTO client should not send further queries to
>    this ALTO server before an indicated period of time has elapsed.
> 
>    REQ.  ARv14-30: An ALTO client protocol specification MUST specify
>    mechanisms, or detail how to leverage appropriate mechanisms provided
>    by underlying protocol layers, which can be used by an ALTO server to
>    inform clients about an impending or occurring overload situation,
>    and redirect them to another ALTO server.
> 
>    REQ.  ARv14-31: An ALTO client protocol specification MUST specify
>    mechanisms, or detail how to leverage appropriate mechanisms provided
>    by underlying protocol layers, which can be used by an ALTO server to
>    inform clients about an impending or occurring overload situation,
>    and terminate the conversation with the ALTO client.
> 
>    REQ.  ARv14-32: An ALTO client protocol specification MUST specify
>    mechanisms, or detail how to leverage appropriate mechanisms provided
>    by underlying protocol layers, which can be used by an ALTO server to
>    inform clients about its inability to answer queries due to technical
>    problems or system maintenance, and advise them to retry the query
>    later.
> 
>    REQ.  ARv14-33: An ALTO client protocol specification MUST specify
>    mechanisms, or detail how to leverage appropriate mechanisms provided
>    by underlying protocol layers, which can be used by an ALTO server to
>    inform clients about its inability to answer queries due to technical
>    problems or system maintenance, and redirect them to another ALTO
>    server.
> 
>    REQ.  ARv14-34: An ALTO client protocol specification MUST specify
>    mechanisms, or detail how to leverage appropriate mechanisms provided
>    by underlying protocol layers, which can be used by an ALTO server to
>    inform clients about its inability to answer queries due to technical
>    problems or system maintenance, and terminate the conversation with
>    the ALTO client.

REQ.  ARv14-29..34:  Partially compliant: The protocol is based on HTTP,
    which features various appropriate protocol mechanisms (R-A header,
    3xx and 503 replies, etc.), but no specific guidance is provided
    when and how to use them in conjunction with the ALTO protocol.

> 3.2.  ALTO Server Discovery

REQ.  ARv14-35..42: not applicable to this document

> 3.3.  Security and Privacy
> 
>    REQ.  ARv14-43: An ALTO client protocol specification MUST specify
>    mechanisms for the authentication of ALTO servers, or how to leverage
>    appropriate mechanisms provided by underlying protocol layers.

REQ.  ARv14-43:  Full compliant: 7.2.5.

>    REQ.  ARv14-44: An ALTO client protocol specification MUST specify
>    mechanisms for the authentication of ALTO clients, or how to leverage
>    appropriate mechanisms provided by underlying protocol layers.
 
REQ.  ARv14-44:  Full compliant: 7.2.5.

>    REQ.  ARv14-45: An ALTO client protocol specification MUST specify
>    mechanisms for the encryption of messages, or how to leverage
>    appropriate mechanisms provided by underlying protocol layers.
 
REQ.  ARv14-45:  Full compliant: 7.2.5.

>    REQ.  ARv14-46: An ALTO client is not required to implement
>    mechanisms or to comply with rules that limit its ability to
>    redistribute information retrieved from the ALTO server to third
>    parties.

REQ.  ARv14-46: not applicable to this document. See also sec. 11.3.:
    "Digital Rights Management (DRM) techniques and legal agreements
    protecting ALTO information are outside of the scope of this
    document."

>    REQ.  ARv14-47: An ALTO client protocol MUST support different levels
>    of detail in queries and responses, in order to protect the privacy
>    of users, to ensure that the operators of ALTO servers and other
>    users of the same application cannot derive sensitive information.

REQ.  ARv14-47:  Full compliant.  Host Group Descriptors are always
    encoded as TypedEndpointAddr, which allows to use IP prefixes.
    Therefore it is possible to obfuscate the identity of candidate
    resource consumers, e.g., by specifying a broader address range
    (i.e., a shorter prefix length) than a group of hosts in question
    actually uses, or by zeroing-out or randomizing the last few bits of
    IP addresses.  However, there is the potential side effect of
    yielding inaccurate results.

>    REQ.  ARv14-48: An ALTO client protocol MAY include mechanisms that
>    can be used by the ALTO client when requesting guidance to specify
>    the resource (e.g., content identifiers) it wants to access.  An ALTO
>    server MUST provide adequate guidance even if the ALTO client prefers
>    not to specify the desired resource (e.g., keeps the data field
>    empty).  The mechanism MUST be designed in a way that the operator of
>    the ALTO server cannot easily deduce the resource identifier (e.g.,
>    file name in P2P file sharing) if the ALTO client prefers not to
>    specify it.

REQ.  ARv14-48:  Full compliant.  The optional ("MAY") feature is not
    defined and therefore, the MUST-statements do not apply.

>    REQ.  ARv14-49: An ALTO client protocol specification MUST specify
>    appropriate mechanisms for protecting the ALTO service against DoS
>    attacks, or how to leverage appropriate mechanisms provided by
>    underlying protocol layers.

REQ.  ARv14-49:  Partially compliant: The protocol is based on HTTP,
    and protecting HTTP-based services against different kinds of
    attacks, including DoS attacks, is a rather well-understood issue.
    However, no specific guidance is provided for ALTO over HTTP.


-- end --