Subject: Re: [alto] WGLC: draft-ietf-alto-protocol-11

From: Richard Alimi <[email-masked]>
Date: Sun, 1 Jul 2012 22:08:34 -0700

[ mistakenly dropped alto list from my reply...]

On Sun, Jul 1, 2012 at 10:05 PM, Richard Alimi <[email-masked]> wrote:
> On Mon, May 21, 2012 at 8:11 AM, Sabine Randriamasy
> <[email-masked]> wrote:
>>
>> Hi Rich,
>>
>>
>> Richard Alimi a écrit :
>>
>>> On Fri, May 11, 2012 at 11:15 AM, Sabine Randriamasy
>>> <[email-masked]> wrote:
>>>
>>>>
>>>> Hi all,
>>>>
>>>> Below is my review of document "draft-ietf-alto-protocol-11.txt". At
>>>> least
>>>> Part I, until section 7.7.3.1.5 included. I will send Part II in a couple
>>>> of
>>>> hours.
>>>>
>>>> Thanks,
>>>> Sabine
>>>>
>>>>
>>>> ===============================================================================================
>>>>
>>>>
>>>> Document: draft-ietf-alto-protocol-11.txt
>>>> Title: ALTO Protocol
>>>> Reviewer: Sabine Randriamasy
>>>> Review Date: May 11, 2012
>>>> Part I
>>>>
>>>> -----------------------------------------------------
>>>> GENERAL COMMENTS
>>>> -----------------------------------------------------
>>>>
>>>> This document seems geared towards P2P applications, although the
>>>> abstract
>>>> mentions CDN and "those that have a choice in connection endpoints". In
>>>> some
>>>> places, see detailed comments, "peer" should be replaced by "endpoints"
>>>> when
>>>> referring to a content location. In Section 8 Use Cases, some text should
>>>> be
>>>> added to recall this.
>>>>
>>>
>>>
>>> Yes - that sounds reasonable.  We'll do a search for the word 'peer'
>>> to see if a better term can be used, and also add a reminder in the
>>> use cases that P2P is not the only deployment setting.
>>>
>>>
>>>>
>>>> There was a discussion on whether to specify the MUST of the protocol. Is
>>>> it
>>>> possible to have a section listing the MUST of the protocol specified in
>>>> this document?
>>>>
>>>
>>>
>>> I don't recall this discussion - do you have a pointer?
>>>
>>> If I'm understanding the proposal correctly, I am concerned about how
>>> much duplicate information that would generate.  Is there an example
>>> RFC you could reference that does this?
>>>
>>
>> I remember there was a discussion on the list and also in Quebec that was on
>> specifying the features that the ALTO MUST have. My question here was rather
>> on the possibility listing the MUST identified in the doc. I don't have any
>> reference of RFC doing this and as it may generate duplicate information
>> then it seems preferable not to do it.
>
> Given the concern over a large amount of duplicate text in the draft,
> I'd like to leave such a list out unless there are others in the WG
> that feel strongly that we should have it.
>
>>
>>>
>>>>
>>>> -----------------------------------------------------
>>>> DETAILED COMMENTS
>>>> -----------------------------------------------------
>>>>
>>>> Section 1.1 Background and Problem Statement
>>>>
>>>> A couple of additional explanations would help better positioning and
>>>> motivating ALTO. For example:
>>>>
>>>> - § 1 after 1st sentence "Today, network information available to
>>>> applications is mostly from
>>>> the view of endhosts.": I suggest to add 1 or 2 sentences on what is
>>>> wrong
>>>> with this, e.g. the fact that overlay based endpoint choice leads to
>>>> uselessly use expensive links and lower performance due to too long
>>>> paths.
>>>>
>>>
>>>
>>> We can add something there. A better way to phrase this might be that
>>> a view only from the view of the endhosts makes it
>>> difficult/impossible to be aware of policies or properties of the
>>> overall network topology.
>>>
>>
>> Yes, thanks
>>
>>>
>>>>
>>>> - §1, 2nd sentence "There is no clear mechanism to convey information
>>>> about
>>>> the network (e.g., preferences) to applications": could be specified by
>>>> saying that some sparse tools may exist but there is a need to have a
>>>> generic and standardized mechanism accessible to all.
>>>>
>>>
>>>
>>> Just to be sure I understand, which specific tools were you thinking
>>> about here?  BGP looking glasses or whois?  Or others?
>>>
>>
>> I'd say both and other related such as *ClosestNode.com or others examples
>> you may have in mind.
>
> I think we can expand this sentence to mention some existing examples.
>  As far as arguing that there needs to be a standardized mechanism, I
> think the Problem Statement document should do that already.
>
>>
>> *
>>>
>>>
>>>>
>>>> - §2last sentence "The mechanism should include abstractions to achieve
>>>> concise, flexible network information expression.": is it the only
>>>> motivation for abstraction or does abstraction also serve other purposes
>>>> such as security/privacy for ISPs?
>>>>
>>>
>>>
>>> I would tend to keep the security/privacy issue out of the
>>> introduction when we are motivating the protocol.  These are
>>> requirements that should (I believe, anyways) already be handled in
>>> the Discussion section of this document and in the requirements
>>> document.
>>>
>>
>> Ok
>>
>>>
>>>>
>>>> Section 1.3.1 Service Providers
>>>> This section is hard to understand without a hint on what kind of
>>>> information is provided by ALTO. I suggest to add a sentence including
>>>> abstracted network maps, asociated costs between the locations of the map
>>>> or
>>>> specific properties or access costs to these locations.
>>>>
>>>
>>>
>>> I'll see what we can do to add a small hint in here without going into
>>> detail.
>>>
>>
>> Sure. It's just that 2 or 3 lines with basic Alto services would make the
>> reading more comfortable.
>>
>>>
>>>>
>>>> - in 1st sentence: "... the peer selection process ... " ==> "peer" shoud
>>>> be
>>>> replaced by "connection endpoints such as peers"
>>>>
>>>
>>>
>>> Ack.
>>>
>>>
>>>>
>>>> Section 2.1 Terminology
>>>>
>>>> - in §2: the term "Endpoint" should be added
>>>> - a first section "2.1.X Endpoint" should be inserted before section
>>>> 2.1.1
>>>> Endpoint Address to better introduce Endpoint Adress and Network Location
>>>> mentioning "Endpoint" with no prior definition.
>>>>
>>>
>>>
>>> Ack - we'll add this.
>>>
>>>
>>>>
>>>> Section 2.2 ALTO Service and Protocol Scope
>>>> - §3 "... The ALTO Information provided by the ALTO Server can be updated
>>>> dynamically based on network conditions ...": a sentence would be good
>>>> here
>>>> to recall that ALTO does by no means replace real time network
>>>> performance
>>>> measurement services.
>>>>
>>>
>>>
>>> Do you instead mean ~real-time congestion control protocols?  If so,
>>> we can add a reminder.
>>>
>>
>> yes, sorry for the confusing phrasing.
>>
>>>
>>>>
>>>> Section 3 Protocol Structure
>>>> - §3 3rd sentence "ALTO-Core provides the Map Service, which provides the
>>>> core ALTO informtion to
>>>> clients". The term "ALTO-Core" should be introduced ans besides it does
>>>> not
>>>> appear again in the document.
>>>>
>>>
>>>
>>> Actually, I think the term can just be dropped at this point. (Let me
>>> know if anyone disagrees)
>>>
>>
>> Ok
>>
>>>
>>>>
>>>> Also replace "informtion" ==> "information".
>>>>
>>>
>>>
>>> Ack.
>>>
>>>
>>>>
>>>> Section 4 Network Map
>>>> - §2: "The Network Location endpoint property": i suggest "The Network
>>>> Location Endpoint Property"
>>>>
>>>>
>>>> Section 7.2.1 Discovering Information Resources
>>>> - §1 "To discover available resources, an ALTO Client may request the
>>>> Information Resource Directory": what are other means? There seem to be a
>>>> contradiction with Section 6.2 Protocol design where item "o Information
>>>> Resource Directory" says that "This directory is the single entry point
>>>> to
>>>> an ALTO Service."
>>>>
>>>
>>>
>>> Does changing it from
>>>   "an ALTO Client may request ... "
>>> to
>>>   "an ALTO Client requests... "
>>> clear this up?
>>>
>>
>> yes
>>
>>>
>>>>
>>>> Section 7.2.7 Parsing
>>>> - last sentence "ALTO implementations MUST ignore...": i suggest an
>>>> insertion: "base protocol ALTO implementations MUST ignore...", or if it
>>>> has
>>>> been previously defined, the term "ALTO-core" could be used here.
>>>>
>>>
>>>
>>> The advice is common to any ALTO implementation, even one that is
>>> supporting an extension.  If an implementation is supporting an
>>> extension, then those fields are no longer "unknown".
>>>
>>
>> Ok
>>
>>> If that still isn't clear, do you have an alternate suggestion on the
>>> wording?
>>>
>>
>> We can leave the initial sentence
>>
>>>
>>>>
>>>> Section 7.4 ALTO Errors
>>>> - §3 2nd sentence: "... information about the why a particular ...": i
>>>> suggest to remove "the" => "... information about why a particular ..."
>>>>
>>>
>>>
>>> Ack - thanks.
>>>
>>>
>>>>
>>>> Section 7.4.1 Media Type
>>>> "... The media type for an Error Resource ...": does it mean "The media
>>>> type
>>>> for an ALTO Error Resource" ?
>>>>
>>>>
>>>
>>>
>>> Yes - we'll make that more precise.
>>>
>>>
>>>>
>>>> Section 7.4.2
>>>> - 1st sentence "An Error Resource has the format:": is the answer to my
>>>> previous question is yes, then "An ALTO ALTO Error Resource has the
>>>> format:"
>>>> reads easier.
>>>>
>>>>
>>>
>>>
>>> Ack - I'll just avoid the extra 'ALTO' when updating the text :)
>>>
>>
>> Ok :-)
>>
>>>
>>>>
>>>> Section 7.4.3 Error Codes
>>>> - §2 last sentence: "... Table 1in the HTTP response." : blank space is
>>>> needed after "1" ==> "... Table 1 in the HTTP response."
>>>>
>>>>
>>>
>>>
>>> Ack.
>>>
>>>
>>>>
>>>> Section 7.6.2 Encoding
>>>> - §3 1st sentence "Any URI ... the format of an Information Resource
>>>> Directory.": i suggest to append "request" ==> "Any URI ... the format of
>>>> an
>>>> Information Resource Directory request."
>>>>
>>>
>>>
>>> Ack.
>>>
>>>
>>>>
>>>> - §4 - item "capabilities": i didin't understand the sentence "or assume
>>>> its
>>>> default value", although the protocol is not expected to guide the ALTO
>>>> Client's behavior.
>>>>
>>>
>>>
>>> Each capability should have a default value documented in this
>>> specification - the text here is only indicating that the client
>>> should fall back to that value.  Does that answer the question?
>>>
>>
>> Yes. Then how about saying "or assume its default value that SHOULD be
>> documented in this specification"
>
> That sounds fine, but I'll just rephrase to say "or assume its default
> value which is documented in this specification."   I don't think
> normative language is needed there, since the instruction applies to
> the document authors/editors/WG and not the implementers.
>
>>
>>> Note to self: "empty array" -> "empty object" in this paragraph
>>>
>>>
>>>>
>>>> Section 7.6.3 Example
>>>>
>>>> In the first IRD example the last URI called
>>>> "http://alto.example.com/endpointcost/lookup" includes the following
>>>> capabilities:
>>>>
>>>> "cost-modes" : [ "ordinal", "numerical" ],
>>>> "cost-types" : [ "routingcost", "hopcount" ]
>>>>
>>>> In the second example listing URIs available in a subdomain, we have the
>>>> same capabilities for the URI called
>>>> "http://custom.alto.example.com/costmap/filtered"
>>>>
>>>> There is a need for the ALTO Server to disambiguate this encoding. As an
>>>> ALTO client, I don't know how to figure what Cost Mode is applied
>>>> respectively to the Cost Type "routingcost" and "hopcount". Is it both
>>>> modes
>>>> for each cost type?
>>>>
>>>>
>>>> Also, as a server, how do I encode that for example "routingcost" is
>>>> available in both "ordinal" and "numerical" modes and "hopcount" in
>>>> "numerical" only? I guess separate URIs would be the way...
>>>>
>>>
>>>
>>> Section 7.7.1.2.4. says:
>>>    An ALTO Server MUST support all of the Cost Types listed here for
>>>    each of the listed Cost Modes.  Note that an ALTO Server may provide
>>>    multiple Cost Map Information Resources, each with different
>>>    capabilities.
>>>
>>> Does that answer both questions?
>>>
>>
>> If the conclusion of this text for the example IRD is that 'routingcost' and
>> 'hopcount' are each available for both 'numerical' and 'ordinal' mode, then,
>> as § 7.7.1.2.4 comes after the IRD example, I think that things would be
>> completely clear if § 7.6.3 would include an illustrative sentence like, "In
>> this example, the ALTO server provides the Endpoint Cost Service for Cost
>> Types 'routingcost' and 'hopcount', each available for both 'numerical' and
>> 'ordinal' mode".
>
> That sounds fine to me. We'll add a hint here.
>
>> As for my 2nd question, I understand that for the mentionned case, the IRD
>> then must include 2 URIs: one for 'routingcost' and the other for
>> 'hopcount'.
>>
>>>
>>>>
>>>> Section 7.7.1.2.4 Capabilities
>>>>
>>>> - Object CostMapCapability has member "CostType cost-types<0..*>;". the
>>>> description says: "If not present, this member MUST be interpreted as an
>>>> empty array." On the other hand, Section 7.7.1.2 Cost Map in its §1 says
>>>> "This resource MUST be provided for at least the ’routingcost’ Cost Type
>>>> and
>>>> ’numerical’ Cost Mode."
>>>> So would "CostType cost-types<1..*>" be more consistent?
>>>> Likewise, as the 'numerical' mode MUST be available, why not have
>>>> CostMode
>>>> cost-modes<1..*> ?
>>>>
>>>
>>>
>>> There are valid cases for them being empty. Specifically, this can
>>> happen if the server generating the Information Resource Directory is
>>> not authoritative as to what capabilities are supported.  See 7.6.3
>>> for an example.
>>>
>>
>> Ok
>>
>>> Each cost-map endpoint need not support the routingcost type - an ALTO
>>> Service must do so.
>>>
>>
>> Ok
>>
>>>
>>>>
>>>> See also §7.7.3.1.3 Input Parameters, where encoding "EndpointProperty
>>>> properties<1..*>" is used, because 'pid' MUST be available.
>>>>
>>>
>>>
>>> Do you mean "EndpointProperty prop-types<0..*>;" instead?
>>>
>>
>> Yes, the error is on my side, there was a confusion with §7.7.3.1.4
>> Capabilities.
>>
>>> This has a similar reasoning to the above for cost maps.
>>>
>>
>> Ok
>>
>>>
>>>>
>>>> Section 7.7.2.2.3 Input Parameters
>>>> - item "constraints" use term "numerical cost". Onthe other hand, Section
>>>> 7.7.2.4.4 Capabilities in its item "cost-constraints" says (last
>>>> sentence)
>>>> "... constraints may not have the intended effect for cost maps with the
>>>> ’ordinal’ Cost Mode... ".
>>>> Although it intuitively make more sens to have constraints on numerical
>>>> values, one may imagine that for some reasons an application clien may
>>>> look
>>>> for alternative paths that have a poorer rank but not worse that a given
>>>> value and accordingly encode a constraint on 'ordinal' costs.
>>>> Therefore, I suggest to use term "cost value" instead of "numerical
>>>> cost".
>>>>
>>>
>>>
>>> Agree. that should not explicitly mention numerical costs in the
>>> documentation for constraints.  Good catch.
>>>
>>>
>>>>
>>>> Section 7.7.3.1.3 Input Parameters
>>>> - §1 2nd sentence: "... data format of input parameteres...": typo ==>
>>>> "...
>>>> data format of input parameters..."
>>>> - item "properties": "List of endpoint properties to returned... " i
>>>> suggest
>>>> "List of endpoint properties to be returned... ".
>>>>
>>>
>>>
>>> Ack.
>>>
>>>
>>>>
>>>> I also suggest to add that
>>>> property 'pid' MUST be provided.
>>>>
>>>
>>>
>>> That is already noted in 7.7.3.1 right?  Note that a particular URI
>>> need not provide the 'pid' property - the ALTO Service as a whole
>>> needs to do so.
>>>
>>> This seems worth clarifying - I'll add a note to do that.
>>>
>>
>> Thanks
>>
>>>
>>>>
>>>> Section 7.7.3.1.4 Capabilities
>>>> - object "EndpointPropertyCapability;" has a member "EndpointProperty
>>>> prop-types<0..*>". As 'pid' MUST be provided why not encode as
>>>> "EndpointProperty prop-types<1..*>" ?
>>>>
>>>
>>>
>>> Same as the response above, I believe.
>>>
>>
>> Yes, again, my confusion.
>>
>>>
>>>>
>>>> -----------------------------------------------------
>>>> NITS
>>>> -----------------------------------------------------
>>>>
>>>> Abstract
>>>> - §3: ".... be provided by the network ..." => I suggest ".... be
>>>> provided
>>>> by the network operator ..." or any applicable term
>>>>
>>>>
>>>> Section 1.1 Background and Problem Statement
>>>> - 2nd sentence "... about the network ..." => I suggest "... about the
>>>> network infrastructure ..."
>>>>
>>>>
>>>> Section 2.1 Terminology
>>>> - the typography should be harmonized between "endpoint address" and
>>>> "Endpoint Address".
>>>>
>>>> Section 2.2 ALTO Service and Protocol Scope
>>>>
>>>> - §1 last sentence: "... deployment scenario and discovery mechanism ..."
>>>> ==> I suggest to complete as follows "... ALTO deployment scenario and
>>>> ALTO
>>>> service discovery mechanism ..."
>>>> - §2 1st sentence: "... the overall system architecture ..." ==> I
>>>> suggest
>>>> "the overall ALTO system architecture"
>>>> - §4 last sentence: "... figure for completeness but outside ..." ==> I
>>>> suggest "... figure for completeness but are outside ..."
>>>>
>>>>
>>>> Section 3 Protocol Structure
>>>> - §3: i suggest to replace "functionality" by "functionalities"
>>>>
>>>>
>>>> Section 3.1.1 Map Service
>>>> - §1: replace "endpoints" by "Endpoints"
>>>>
>>>>
>>>> Section 7.4 ALTO Errors
>>>> - §3 2nd sentence: "... information about the why a particular ...": i
>>>> suggest to remove "the" => "... information about why a particular ..."
>>>>
>>>>
>>>
>>>
>>> Ack.
>>>
>>> Thanks!
>>> Rich
>>>
>>>
>>>>
>>>> Enrico Marocco a écrit :
>>>>
>>>>
>>>>>
>>>>> The chairs would like to declare a Working Group Last Call for
>>>>> draft-ietf-alto-protocol-11, ending Friday May 11th.
>>>>>
>>>>> Please do review the latest version of the draft, and send any comments
>>>>> to the list before the expiry of WGLC so we can get this document ready
>>>>> for the IESG.
>>>>>
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> alto mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/alto
>>>>
>>
>>

---

From: Richard Alimi <[email-masked]>
Date: Sun, 1 Jul 2012 23:38:57 -0700

Thank you very much Sebastian for putting this together!

There are few responses inline for the ones that were not fully
compliant.  I either made an attempt to indicate why the protocol is
the way it is for the benefit of others (or to open up discussion), or
raised a question on how we can resolve it.

On Sun, May 13, 2012 at 11:14 PM, Sebastian Kiesel <[email-masked]> wrote:
> 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, ...)

It needs something more than just an I-D since that is a pretty low bar.

Do people think a registry is needed for this?  If not, perhaps we can
just make this more explicit that it needs to be a standards-track
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.

At least in the initial discussions of ALTO, there was mention about
using these for addresses other than IP addresses, such as e.164
numbers.  That said, I haven't seen any concrete use cases for
anything other than IP addresses or things that can map to IP
addresses.

I don't intend to start a debate on the requirements document at this
stage, but I'm a bit hesitant to say that extensions MUST do this.  I
completely agree that those proposing extensions should be thinking
about this, but tend to think that MUST is too strong.  How about
extending 7.5.3.1 to state "extension documents defining a new Address
Type SHOULD also document a mechanism to map addresses of the new type
to IPv4 and/or IPv6 addresses prefixes."

>
>     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.

Do you have any thoughts on what this might look like?

>     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.

Moving this to the deployment considerations document sounds reasonable to me.

>>    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).

Agree that we should resolve this.  We can leave resolving this to
discussion 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.

I tend to think it's best to leave this one as partially compliant for
now, and leave the additional expiration field for when there is an
extension to support redistribution (the section that was removed in
-11).  Any disagreement with that?

>
>>    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

Yeah - I'm personally okay with this current state, since we
consciously removed the section on Redistribution and left that for an
extension.

>
>>    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

The use of JSON and Section 7.2.7 also helps with extensions.

>>    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

Yeah.  There was a discussion when going to the REST-ful approach
about whether we wanted any explicit version numbers or not.  The idea
was that we didn't need an ALTO version number exposed to applications
if we used media types appropriately.  Using media types like you
suggested is certainly one approach.

>> 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.

We also had a discussion about this in the protocol overhaul for
making it REST-ful.  The guidance we received there was to not repeat
details from RFC2616.  I'm not sure I see much utility in adding
specifics in the ALTO protocol document, since it would basically
amount to saying "If you think you are overloaded, you are free to
return a 503."  Then, if we were to add that, people would ask "you
gave me guidance on using 503, but you didn't tell me when I should or
should not use chunked transfer encoding.. how about that??"  The idea
was that the statements in Section 7.2, as well as some intelligence
on behalf of implementers on how to apply RFC2616, would answer all of
these questions.

>> 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.

Agree. See comment above.

> -- end --

---

From: Martin Stiemerling <[email-masked]>
Date: Mon, 2 Jul 2012 17:05:47 +0200

[writing with no Area Director hat on, i.e., as a random community member]
Hi Richard, all,

On 07/02/2012 08:38 AM, Richard Alimi wrote:
[...]

> It needs something more than just an I-D since that is a pretty low bar.

You can specify 'protocol specification' or 'expert review' as the bar 
for an extension.
See also RFC 5226 for a discussion of this:
http://tools.ietf.org/html/rfc5226

> just make this more explicit that it needs to be a standards-track

There should be a registry where you can add additional address types. 
Otherwise it is really hard to get new address types in a clean way into 
the protocol.
A registry allows also to keep track about all existing address types 
(out of the ALTO protocol and what comes later on).

> to IPv4 and/or IPv6 addresses prefixes."

A SHOULD is fine, as it implies that people must say why they are not 
specifying a mapping mechanism.

> Do you have any thoughts on what this might look like?

An appropriate error message with a path name delivered through this 
would good. However, this is just a proposal.

> Moving this to the deployment considerations document sounds reasonable to me.

+1

>>>     table to be obtained via an alternative mechanism.

[...]

> -11).  Any disagreement with that?

Not from my side.

> consciously removed the section on Redistribution and left that for an

If we allow to be partially compliant, we should at least note that the 
missing points are part of a future redistribution mechanism and 
therefore not specified in the current ALTO protocol.

> suggested is certainly one approach.

Irrespectively of what mechanisms is being used, this protocol needs 
versioning support. However, I'm not sure that media-types are the best 
way forward for this.
What would be a different approach when using media types?

> on behalf of implementers on how to apply RFC2616, would answer all of

That is not a good way of specifying things. There is no need to say how 
a 503 response looks like, but it is definitely good to say when an ALTO 
protocol must reply with such a code. "intelligence ...of implementers" 
will cause ALTO protocol implementations that do not interoperate.

> Agree. See comment above.

Give at least guidance where to read on to protect against such threads. 
Otherwise this specification is incomplete.

   Martin

-- 
[email-masked]

NEC Laboratories Europe - Network Research Division NEC Europe Limited
Registered Office: NEC House, 1 Victoria Road, London W3 6BL
Registered in England 283

---

From: Martin Stiemerling <[email-masked]>
Date: Mon, 2 Jul 2012 17:17:35 +0200

Adding something to my last email, after an offline discussion with 
Sebastian:

[...]
> specifying a mapping mechanism.

Thinking twice about it:
The requirements are actually crisp about that: The MUST document such a 
mapping. Therefore we should have it this way in the protocol.
Such an extension is sort of useless, at least by today's measures, if 
there is no mapping mechanism to IPV4/IPv6 addresses.

   Martin

---

From: Sabine Randriamasy <[email-masked]>
Date: Mon, 2 Jul 2012 17:20:32 +0200

Hi Rich,

> that feel strongly that we should have it.
Sure, I think we have agreed upon this.
> I think we can expand this sentence to mention some existing examples.
thanks
> think the Problem Statement document should do that already.
Ok. I figured 2-4 lines could help but don't want to overload the text. 
So refering to the pb statement is fine.
Ok
Thanks

---

From: Sebastian Kiesel <[email-masked]>
Date: Mon, 2 Jul 2012 17:27:46 +0200

Hi Rich,

I need some more time to comment on the other issues, but let me write
about one thing before I forget it again :)

> to IPv4 and/or IPv6 addresses prefixes."

I propose to write in 7.5.3.1:

"Extension documents may define additional Address Types and the 
corresponding mechanisms to map these adresses from/to IPv4/IPv6
addresses/prefixes."

That way you neither have to contradict nor reinforce the requirements
document.

Thanks,
Sebastian

---

From: Sebastian Kiesel <[email-masked]>
Date: Mon, 2 Jul 2012 17:43:59 +0200

Sabine, Rich,

> >> abstract mentions CDN and "those that have a choice in connection
> >> endpoints". In some places, see detailed comments, "peer" should be
> >> replaced by "endpoints" when referring to a content location. In
> >> Section 8 Use Cases, some text should be added to recall this.
> >

In RFC 5693 we have defined the term "resource provider" (and many more,
maybe we should check the protocol draft again for correct usage of the
ALTO terminology?).

Btw. "Content Location" would IMO not be general enough, as we could use
ALTO also, e.g., to find a "good" media relay for VoIP NAT traversal.

Thanks
Sebastian

---

From: Richard Alimi <[email-masked]>
Date: Mon, 2 Jul 2012 11:09:51 -0700

> maybe we should check the protocol draft again for correct usage of the

For the specific point about use of the word "peer", when looking
through the -11 version, the primary use is in section 8 where we are
explicitly talking about p2p use cases. That use seems fine to me.
There are a couple of places where 'peer' may be somewhat limiting
(e.g., section 11.2) and should be changed.

We can certainly do an inventory on terminology to see if anything
else from RFC5693 should be applied.  I'm pretty sure it won't just be
substituting "endpoints" with either "resource consumer" or "resource
provider" though, since that depends quite a bit on how the
application uses ALTO information, and what the costs actually
represent. That is, we can't simply say that that a resource consumer
is choosing a resource provider.  It's conceivable that the resource
provider could be doing the choosing in a push-based protocol.  As a
slightly more interesting example, what if I also wanted to try and
reduce latency for ACKs in the opposite direction to protect myself
against asymmetric routing - then then I'd be querying a latency map
for the cost from the resource consumer to the resource provider.   In
the ALTO Protocol we try to simply express these as costs between
endpoints. It's an application-level concern about who does the
choosing, and making sure they are using the costs appropriately.

All that said, I think we do need to improve the protocol draft to
explicitly say how "endpoint" relates to "resource consumer" and
"resource provider" which is mentioned in other documents.  How about
the following:

Add this to Section 2.1.1:
  "An Endpoint Address is typically either the address of a Resource
Provider or Resource Consumer."

Add change this text in Section 5:
  "Each Path Cost is the end-to-end cost from the source to the destination."
to instead read:
  "Each Path Cost is the end-to-end cost from the source to the
destination.  For example, if the cost is expected correlated with
throughput, a typical application concerned with bulk data transfer
may use the Resource Provider as the source, and Resource Consumer as
the destination."

> ALTO also, e.g., to find a "good" media relay for VoIP NAT traversal.

Agree.

---

From: Richard Alimi <[email-masked]>
Date: Mon, 2 Jul 2012 11:35:05 -0700

> [writing with no Area Director hat on, i.e., as a random community member]

Good to have you back :)

> You can specify 'protocol specification' or 'expert review' as the bar for
> an extension.
> Otherwise it is really hard to get new address types in a clean way into the
> protocol.
> A registry allows also to keep track about all existing address types (out
> of the ALTO protocol and what comes later on).

Right - okay. We'll add an Address Type registry.  That said, it'd be
really nice to point to an existing registry. I think we'd need the
following for such a registry:
(1) A textual string for an address type itself
(2) A specification (preferably a pointer to one) for how to serialize
and deserialize a textual address of that type.
(3) (maybe, depending on the result of the discussion below) a
statement of how an address type can be mapped into IPv4/v6 addresses.

However, when browsing through the available IANA registries I didn't
see one that really matched those requirements.  Does anyone have a
better option before we go about defining our own?

> specifying a mapping mechanism.

I'll save my reply for your later followup.

> An appropriate error message with a path name delivered through this would
> good. However, this is just a proposal.
>
>
>>
> missing points are part of a future redistribution mechanism and therefore
> not specified in the current ALTO protocol.

Sounds good to me.  We can add a note here.

> versioning support. However, I'm not sure that media-types are the best way
> forward for this.

Do you mean a different approach *than* using media types?  One other
option would be to revert revert back to what we had before, which is
have an explicit field in each and every response.

Here's one pointer to mailing list discussions about protocol
versioning and media types:
  http://www.mail-archive.com/[email-masked]/msg00609.html
I'll note that our AD at the time (Lisa) was one of the people
suggesting we use content negotiation to provide protocol versioning.

My preference would be to not re-hash the merits of protocol
versioning unless we think there is a clear technical advantage over
what we have now.

> That is not a good way of specifying things. There is no need to say how a
> 503 response looks like, but it is definitely good to say when an ALTO
> protocol must reply with such a code. "intelligence ...of implementers" will
> cause ALTO protocol implementations that do not interoperate.

If we want to make revisions here, can you give some guidance on where
we should recommend certain usage of HTTP and where we shouldn't?
Should it be just additional text to ensure that we satisfy the
requirements on overload control, or additional guidance on how to to
employ other parts of HTTP such as transfer encoding, caching, when to
use redirects, etc?

---

From: Richard Alimi <[email-masked]>
Date: Mon, 2 Jul 2012 11:41:15 -0700

> That way you neither have to contradict nor reinforce the requirements

This sounds good to me.  Depending on what we do with a registry, it
may make sense to put this as one of the criteria for adding a new
entry instead.

---

From: Sebastian Kiesel <[email-masked]>
Date: Mon, 2 Jul 2012 22:22:19 +0200

Hi Rich,

On Mon, Jul 02, 2012 at 11:09:51AM -0700, Richard Alimi wrote:
> represent. 

> That is, we can't simply say that that a resource consumer
> is choosing a resource provider.

I would exactly say this. 

Or maybe, to be more precise: A resource consumer chooses - or asks a
third party to choose on behalf of it - one or several resource
providers from a set of candidate resource providers (and ALTO is
consulted in order to improve that decision).

However, it it is important that resource is not neccessarily a file or
content stream. Therefore, the above sentence does not imply that most
of the data flows from the resource provider(s) to the resource consumer!
Because we might have independent control and data connections
it would also be too simplistic to say the resource consumer
is the "connection/flow initiator", though most of the time this is true.

> It's conceivable that the resource
> provider could be doing the choosing in a push-based protocol.

If we have a push-based protocol, where one could send some
kind of information to one of several "sinks", I'd say that the
(ALTO-/RFC5693-)resources are these sinks, and the "pusher"
is the resource consumer, which consumes the sink-resource.

> As a
> endpoints. 

ack.

> It's an application-level concern about who does the

Each application uses its own terminology and has specific ideas on who
assumes the roles of "client", "server", "peer", ...
My understanding of the ALTO terminology is that we can use it to
describe the (ALTO-relevant) features of an arbitrary protocol in
a uniform way. And in particular, I would describe the general
ALTO problem as:

We have 1 resource consumer and N candidate resource providers.
We want to have data flows between the resource consumer and
M < N resource providers. Therefore, we need to choose M out of N,
and ALTO is supposed to help on that decision.

> Provider or Resource Consumer."

Is it always the address of exactly one host (either r.prov. or r.cons.)?
Otherwise, the already defined term "host group descriptor" might make
sense?

> may use the Resource Provider as the source, and Resource Consumer as

change "a typical application concerned with bulk data transfer"
to "a typical application concerned with bulk data retrieval", then
we have one of the most important use cases as an example - though
the example does not reflect the full complexity of that issue ...

  S.

---

From: "Y. Richard Yang" <[email-masked]>
Date: Tue, 3 Jul 2012 15:15:48 +0800

Hi Sebastian, Rich,

On Tuesday, July 3, 2012, Sebastian Kiesel wrote:
For example, the resource consumer may not ask, as
> consulted in order to improve that decision).

Using your good reasoning below, even the preceding sentence may have
subtlety: "ask" may imply some messages, but the app may not have a
message. How about remove "ask"?

> > Provider or Resource Consumer."

Suppose we want to simplify the definition by removing "address" from the
the above.
Then we have "An Endpoint is typically either a Resource Provider or
Resource
Consumer." How does this read? What is an atypical case?

> destination."
> Agree on the subtlety. Instead of an example in the definition,  how about
a
short discussion paragraph starting as "Each application has its
interpretation
on who assumes the role of ... and hence how to utilize Path Cost provided
by ALTO. For example, ..."

-yry

> [email-masked] <javascript:;>

---

From: Sabine Randriamasy <[email-masked]>
Date: Tue, 3 Jul 2012 17:35:56 +0200

Hi Sebastian, Rich, Richard

Y. Richard Yang a écrit :
> Suppose we want to simplify the definition by removing "address" from 
> the the above. 
This reads clear. An ALTO Endpoint covers both Consumer and Provider. 
Resources pushers and sinks are implicitely mapped onto source and 
destination in the ALTO Cost Maps, that thus also support asymetrical 
traffic cases. 
Would this point fit in the Endpoint definition section planned before 
current Section 2.1.1 Endpoint address ?
>     Otherwise, the already defined term "host group descriptor" might make
I agree with this question as Section 2.1.3 Network Location says:  
"denoting a single endpoint or
group of endpoints". Section 5 may address this question this with some 
additonal text.
Section 5 currently says:

"An ALTO Cost Map defines Path Costs pairwise amongst sets of source
and destination Network Locations. Each Path Cost is the end-to-end
cost from the source to the destination."

How about adding a sentence like:

"The Path Cost between Network Locations grouping several Endpoints 
(opt: and represented by their PID) is provided by The ALTO Cost Map 
Service. The ALTO protocol additonally MAY provide Path Costs between 
individual Endpoints (opt: represented by their address) via the ALTO 
Endpoint Cost Service."
> Agree on the subtlety. Instead of an example in the definition,  how 
> about a 
yes, and again say that the application must be aware that the roles 
that they have set are to be mapped with the roles of source and 
destination implicitely encoded in the ALTO Cost Maps.

Re-adding a comment from Sebastian yesterday, I have the following :

Sebastian: "Btw. "Content Location" would IMO not be general enough, as we could use
ALTO also, e.g., to find a "good" media relay for VoIP NAT traversal."

It may be interesting to consider other cases such as media relays. Wouldn't it be worth adding such a use case to be discussed in either the ALTO or i2aex WG? Do you have one in mind? 

Sabine

---

From: Martin Stiemerling <[email-masked]>
Date: Tue, 3 Jul 2012 21:46:13 +0200

>> [writing with no Area Director hat on, i.e., as a random community member]

Thanks, finally there is time again for ALTO :)

> better option before we go about defining our own?

We need to create our own registry for this, which isn't a big deal. 
Just write this up in the IANA considerations section.

[...]

> versioning unless we think there is a clear technical advantage over

Let me go through the old email thread to see what happened back then.

[...]

> employ other parts of HTTP such as transfer encoding, caching, when to

I would describe only mechanisms which are required by the protocol (or 
by the requirements). The protocol spec must say: return a 503 if 
overloaded, for instance. I do not see the need to specify how ALTO is 
using each and every feature of HTTP, but it should be clear how 
functionality required by the ALTO protocol is mapped to the underlying 
HTTP protocol.

Thanks,

   Martin

-- 
IETF Transport Area Director

---

From: Martin Stiemerling <[email-masked]>
Date: Tue, 3 Jul 2012 21:50:00 +0200

> may make sense to put this as one of the criteria for adding a new

Sebastian's text is good.
Not sure what you are saying with the registry -- probably too late for me

   Martin

---

From: Martin Stiemerling <[email-masked]>
Date: Tue, 3 Jul 2012 22:02:14 +0200

Sabine,

On 07/03/2012 05:35 PM, Sabine Randriamasy wrote:
[...]

>> about a short discussion paragraph starting as "Each application has
>> its interpretation
> It may be interesting to consider other cases such as media relays.
> Wouldn't it be worth adding such a use case to be discussed in either
> the ALTO or i2aex WG? Do you have one in mind?

There are probably other use cases just around the corner.

However, we should use all energy to finalize the ALTO protocol spec 
right now.

   Martin

---

From: Richard Alimi <[email-masked]>
Date: Sun, 8 Jul 2012 10:09:36 -0700

On Tue, Jul 3, 2012 at 12:46 PM, Martin Stiemerling
<[email-masked]> wrote:
>>> for
>>> the
>>> (out
> We need to create our own registry for this, which isn't a big deal. Just
> write this up in the IANA considerations section.

Sounds good to me.

>>> way
>>> will
> I would describe only mechanisms which are required by the protocol (or by
> the requirements). The protocol spec must say: return a 503 if overloaded,
> for instance. I do not see the need to specify how ALTO is using each and
> every feature of HTTP, but it should be clear how functionality required by
> the ALTO protocol is mapped to the underlying HTTP protocol.

Okay - we'll add some text for overload control.

Thanks,
Rich

---

From: Richard Alimi <[email-masked]>
Date: Sun, 8 Jul 2012 21:58:53 -0700

>> and ALTO is supposed to help on that decision.

I agree that this is a good way to state the common use case.

> Consumer." How does this read? What is an atypical case?

Removing address sounds good to me.  One of the suggestions elsewhere
on the list was to add 'Endpoint' as a term, so I put this text in
that new section.

> Agree on the subtlety. Instead of an example in the definition,  how about a

Thank you Sebastian and Richard for the suggestions.  How about the
following paragraph added to Section 5 just after paragraph 2:

  Each application may independently determine how the Resource Consumer
  and Resource Provider are designated as the source or destination, and hence
  how to utilize the Path Cost provided by ALTO.  For example,
  if the cost is expected to be correlated with throughput, a typical
  application concerned with bulk data retrieval may use the Resource Provider
  as the source, and Resource Consumer as the destination.

Thanks,
Rich

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Mon, 9 Jul 2012 06:34:35 +0100

Rich, Colleagues,

Some comments from me inline...

> consciously removed the section on Redistribution and left that for an

It's a while since I looked at ALTO in detail so my memory of various aspects is a little hazy but I wonder if the HTTP Vary header can help us here?

> suggested is certainly one approach.

Using media types along with HTTP conneg gives the advantage that the client can specified a prioritised list of versions (of media-types) that it supports in its requests and the server can respond appropriately (including an appropriate error response if it cannot serialise the response in the requested media-type version(s), e.g. because it needs to use a higher versioned media-type than the client supports).

The other advantage is that the protocol machinery to do the negotiation already exists in HTTP and we do not need to redefine ALTO specific protocol machinery to perform the same function.

The downside is we end up minting new media-types for incompatible changes between ALTO versions, but minting a new media-type is "cheap".

Ben

---

From: Richard Alimi <[email-masked]>
Date: Sun, 8 Jul 2012 22:41:16 -0700

> It's a while since I looked at ALTO in detail so my memory of various aspects is a little hazy but I wonder if the HTTP Vary header can help us here?

It may help with parts of it, but note that some of these requirements
depend on ALTO-layer information and not HTTP headers.  Additionally,
the redistribution mechanism was also designed for sending ALTO
resources via non-HTTP protocols.

---

From: "Y. Richard Yang" <[email-masked]>
Date: Mon, 9 Jul 2012 22:52:31 +0800

>   as the source, and Resource Consumer as the destination.
Looks good to me.

Thanks!

Richard