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

From: Martin Stiemerling <[email-masked]>
Date: Fri, 11 May 2012 09:30:50 +0200

Hi there,

An important note on the ALTO protocol as part of the WGLC:

The ALTO requirements have been discussed in the 2012-05-10 IESG 
telechat and one point raised which is actually of importance for the 
ALTO protocol is this:

There is/was a DISCUSS on the ALTO requirements about operations and 
management (OAM) of the ALTO protocol.
RFC 5706 (http://tools.ietf.org/html/rfc5706) gives an overview of 
points to be checked for new protocols.

However, we have not considered RFC 5706 (at least to my knowledge) in 
the ALTO protocol that discusses operations and management of the ALTO 
protocol.

The outcome of the IESG discussion is that the ALTO protocol must cover 
the aspect of OAM and discuss what is potentially needed and what is 
potentially not needed.

For instance:
- the support of logging at the server for failure detection is a 
potentially a good idea, though it might become touchy in the p2p use case.
- discussion of what clients are supposed to do when a server fails for 
various reasons. This is probably already covered in the current ALTO 
protocol draft.

Regards,

   Martin

-- 
IETF Transport Area Director

[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: David Harrington <[email-masked]>
Date: Fri, 11 May 2012 10:37:04 -0700

Hi,

As the author of rfc5706, and a long-time participant in the OPS area, let
me make some comments and provide some advice.

First, 
OAM and "Operations and Management" are not the same thing.
There is an RFC that discusses OAM terminology, and I recommend reading it
to understand the distinction (which still is NOT unambiguous).

Generally, 1) OAM happens inline as part of the protocol, 2) operations
includes consideration of the environment in which the protocol will
operate, and 3) management tends to be a combination of layer 7 protocols
that provide monitoring/management capabilities combined with
protocol-layer-specific information, such as MIB objects or ipfix
information elements or syslog structured data, etc. IETF management
protocols typically keep a clear distinction between the protocols used to
carry management information and the data models used to model the managed
functionality. 

Second, 
as the WG starts to consider how to address O&M requirements and/or OAM
requirements, I recommend starting with an understanding of the difference
between information models and data models, as described in RFC3444 (IIRC).

OPSAWG is doing a lot of work at making sure the information used by one
protocol can be correlated and/or translated between data models for use
with other management protocols.

I recommend developing a management-protocol-independent information
model, plus at least one management-protocol-specific data model (which
helps serve as a proof that the information model is viable).

Third,
The IETF currently has four main standards in the "management protocol
toolkit": SNMP (monitoring and tweaking), IPFIX (flow monitoring), Netconf
(configuration), and Syslog (logging). These are widely supported by
operators, and standard data models should be available so operators can
use these IETF management protocols to manage IETF protocols when possible.

Fourth,
RFC5706 discusses things to consider when developing a management
information model (and subsequent data models).
For example, for ALTO, an operator might want to be able to monitor what
sources are being used to gather physical network information, what
transform algorithms are being applied to the source data to produce ALTO
application-level information, and to monitor who is getting that
processed information from the ALTO server.
You might want to consider whether protocol errors are being detected
between the server and the data sources, or between the server and
specific consumers. This might be important to understand whether certain
sources or consumers are putting an unnecessary strain on the server, so a
server might choose to stop communicating with that error-generating
connection (and whether that decision should be standardized). That
infomation also might help detect why certain consumers might choose
non-optimal optimizations.

RFC5706 also discusses operational requirements. If BGP will be used to
gather source data, then BGP must be supported in the environment, and
that has operational considerations. Will all ALTO servers operate in BGP
environments? If an operator decides BP is not important to the physical
network they run, or choose not tp provide BGP data for security reasosn,
how will the ALTO environment be affected, and will this affect
interoperability across ALTO servers?

And so on ...

--
David Harrington
Internet Engineering Task Force (IETF)
[email-masked]
+1-603-828-1401

On 5/11/12 12:30 AM, "Martin Stiemerling" <[email-masked]>
wrote:

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

---

From: Sabine Randriamasy <[email-masked]>
Date: Fri, 11 May 2012 20:15:33 +0200

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.

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?

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

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.

- in 1st sentence: "... the peer selection process ... " ==> "peer" 
shoud be replaced by "connection endpoints such as peers"

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.

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.

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.
Also replace "informtion" ==> "information".

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

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.

Section 7.4 ALTO Errors
- §3 2nd sentence: "... information about the why a particular ...": i 
suggest to remove "the" => "... information about why a particular ..."

Section 7.4.1 Media Type
"... The media type for an Error Resource ...": does it mean "The media 
type for an ALTO Error Resource" ?

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.

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

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

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 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..*> ?
See also §7.7.3.1.3 Input Parameters, where encoding "EndpointProperty 
properties<1..*>" is used, because 'pid' MUST be available.

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

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... ". I also suggest 
to add that property 'pid' MUST be provided.

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..*>" ?

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

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

---

From: Sabine Randriamasy <[email-masked]>
Date: Sat, 12 May 2012 01:17:03 +0200

Hi all,

Below is Part II of my review of document 
"draft-ietf-alto-protocol-11.txt", starting at section 7.7.3.1.5 
included until end of document. I have put Part II on top of my previous 
e-mail with Part I, to have both gathered in 1 e-mail.

Thanks,
Sabine

Document: draft-ietf-alto-protocol-11.txt
Title: ALTO Protocol
Reviewer: Sabine Randriamasy
Review Date: May 11, 2012
Part II - starting section 7.7.3.1.5 included until end of document

-----------------------------------------------------
GENERAL COMMENTS ON THE DOCUMENT (Review Part II and Part I)
-----------------------------------------------------

This document is clear and well structured and provides enough 
information to specify and implement basic ALTO protocol transactions. 
Clarifications however are needed for some particular cases. The 
corresponding requests  are listed  in the  "Detailed  comments" section 
of Part I and Part II of this review.

Section 7.7.3.1.5 Response
- §3 describing InfoResourceEndpointProperty: last sentence "... 
property values encoded as JSON Strings". Encoding property values as 
JSON strings may be too restrictive. It may as well be a constant 
number, or an array. Why not a JSON Value?

- §5 "If the ALTO Server does not define a requested property for a 
particular endpoint, then it MUST omit it from the response for only 
that endpoint.": does this mean that the corresponding pair 
{"prop-type": prop-type-value} does not appear in the array of 
EndpointProperty objects associated to this endpoint?

If an ALTO server defines a property for an endpoint but no value, what 
happens? Is simply the prop-type-value omitted?

Section 7.7.3.1.6 Example
An example of request/response with several properties would be good here.

Section 7.7.4.1.5 Response
- § of description of member "EndpointCostMapData" sentence "An 
implementation of the
protocol in this document SHOULD assume that the cost is a JSONNumber 
... ": I suggest using "cost value" rather than "cost". Same for 
sentence "If the ALTO Server does not define a cost from ..."

Section 8 Use Cases
There should be a couple of sentences recalling that ALTO supports a 
wider range of applications, namely "those that have a choice in 
connection endpoints" as said in Abstract although the use cases focus 
on P2P.

Section 8.1 ALTO ALTO Client Embedded in P2P Tracker
- §1 1st sentence "Many P2P currently-deployed P2P systems... ": ==>  
"Many currently-deployed P2P systems... "

Section 9.4 Mapping IPs to ASNs
- §4: The mapping could also be done for Endpoints and ASN be an 
Endpoint Property.

NITS & TYPOS

Section 9.3
- §2 1st sentence "The protocol specified ... (i.e., the the Endpoint 
Cost Service) ... " ==> remove one of the 2 "the"

Section 10.1 application/alto-* Media Types
- item "Published specification", last part "... see Table 2for ..." : 
blank space needed ==> "... see Table 2 for ..."

-- 

---------------------------------------------------------
Sabine RANDRIAMASY 
Alcatel-Lucent Bell Labs France 
Centre de Villarceau
Route de Villejust - 91620 NOZAY - FRANCE

E-MAIL : [email-masked]
TEL: +33 (0)1 30 77 27 45 
         (On Net) 2 103 27 45
---------------------------------------------------------

---

From: Richard Alimi <[email-masked]>
Date: Sat, 12 May 2012 23:05:19 -0700

On Mon, Apr 23, 2012 at 6:47 PM, Songhaibin <[email-masked]> wrote:
> In general, this draft is in good shape.
>
> One randomly caught problem, in Section 5.1.2.2, the ordinal mode introduction, it says this cost mode is a ranking from a particular source to a set of destinations. But in Section 5.2, the introduction of cost map structure, the cost mode "ordinal" can be applied to m*n entries in the cost map. So I suggest to modify the previous section 5.1.2.2 to make them consistent.
>

Thanks for catching that. In fact, the sentence "If the Cost Mode is
'ordinal', the Path Cost of each communicating pair is relative to the
m*n entries" can probably just be removed.

Thanks,
Rich

> BR,
> -Haibin
>
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] On Behalf Of Enrico
>> Marocco
>> Sent: Monday, April 16, 2012 5:20 PM
>> To: [email-masked]
>> Subject: [alto] WGLC: draft-ietf-alto-protocol-11
>>
>>
>> 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.
>>
>> --
>> Ciao,
>> Enrico
>

---

From: Richard Alimi <[email-masked]>
Date: Sun, 13 May 2012 00:11:08 -0700

Oops - I replied to the Part 1 email separately. I'll keep this one
focused on Part 2 and trim the rest from the reply to avoid confusion.

On Fri, May 11, 2012 at 4:17 PM, Sabine Randriamasy
<[email-masked]> wrote:
> - §3 describing InfoResourceEndpointProperty: last sentence "... property
> values encoded as JSON Strings". Encoding property values as JSON strings
> may be too restrictive. It may as well be a constant number, or an array.
> Why not a JSON Value?

I don't have a problem with making this a JSON Value for extensibility
and adopting similar text that we did for cost values (basically,
those implementing the base specification should validate that they
are strings).  If someone feels like we shouldn't do that, then please
speak up soon :)

> particular endpoint, then it MUST omit it from the response for only that
> endpoint.": does this mean that the corresponding pair {"prop-type":
> prop-type-value} does not appear in the array of EndpointProperty objects
> associated to this endpoint?

Yes.  If it was unclear, feel free to provide alternate text to clarify it.

> happens? Is simply the prop-type-value omitted?

I would have considered this to be the same as not having the property
defined for that endpoint.  Would the following text make it more
clear?

"If the ALTO Server does not define a value for a requested property
for a particular endpoint, then it MUST omit it .. "

> An example of request/response with several properties would be good here.

Makes sense - we can add that.

> protocol in this document SHOULD assume that the cost is a JSONNumber ... ":
> I suggest using "cost value" rather than "cost". Same for sentence "If the
> ALTO Server does not define a cost from ..."

Sounds good to me.

>
>
> Section 8 Use Cases
> There should be a couple of sentences recalling that ALTO supports a wider
> range of applications, namely "those that have a choice in connection
> endpoints" as said in Abstract although the use cases focus on P2P.

Ack.

> - §1 1st sentence "Many P2P currently-deployed P2P systems... ": ==>  "Many
> currently-deployed P2P systems... "
>

Ack.

> - §4: The mapping could also be done for Endpoints and ASN be an Endpoint
> Property.
>

Yes  - that is also a possibility.  We can mention this.

> - §2 1st sentence "The protocol specified ... (i.e., the the Endpoint Cost
> Service) ... " ==> remove one of the 2 "the"
>
>
> - item "Published specification", last part "... see Table 2for ..." : blank
> space needed ==> "... see Table 2 for ..."

Ack.

Thanks for the review!
Rich

> Sabine RANDRIAMASY Alcatel-Lucent Bell Labs France Centre de Villarceau
> TEL: +33 (0)1 30 77 27 45         (On Net) 2 103 27 45

---

From: Richard Alimi <[email-masked]>
Date: Sun, 13 May 2012 00:13:11 -0700

adding alto WG back...

On Sat, May 12, 2012 at 11:59 PM, Richard Alimi <[email-masked]> wrote:
> On Fri, May 11, 2012 at 11:15 AM, Sabine Randriamasy
>> 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
>>
>> 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?
>
>>
>> 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.
>
>> - §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 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.
>
>>
>> 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.
>
>> - in 1st sentence: "... the peer selection process ... " ==> "peer" shoud be
>> replaced by "connection endpoints such as peers"
>
> Ack.
>
>>
>> Section 2.1 Terminology
>>
>> - 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.
>
>> - §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.
>
>>
>> - §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)
>
>> 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?
>
>>
>> Section 7.2.7 Parsing
>> 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".
>
> If that still isn't clear, do you have an alternate suggestion on the wording?
>
>>
>> Section 7.4 ALTO Errors
> Ack - thanks.
>> "... 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
>> 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 :)
>
>>
>> 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?
>
> Note to self: "empty array" -> "empty object" in this paragraph
>
>>
>>
>> Section 7.6.3 Example
>>
>> respectively to the Cost Type "routingcost" and "hopcount". Is it both modes
>> for each cost type?
>>
>>
> 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?
>
>> "This resource MUST be provided for at least the ’routingcost’ Cost Type and
>> ’numerical’ Cost Mode."
>> 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.
>
> Each cost-map endpoint need not support the routingcost type - an ALTO
> Service must do so.
>
> Do you mean "EndpointProperty prop-types<0..*>;" instead?
>
> This has a similar reasoning to the above for cost maps.
>
>> - 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... ".
>> 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.
> Agree. that should not explicitly mention numerical costs in the
> documentation for constraints.  Good catch.
>
>> - §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.
>
>>
>>
> Same as the response above, I believe.
>
>>
>>
>>
>> - §3: ".... be provided by the network ..." => I suggest ".... be provided
>> by the network operator ..." or any applicable term
>>
>>
>> - §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"
> Thanks!

---

From: Sebastian Kiesel <[email-masked]>
Date: Mon, 14 May 2012 08:14:51 +0200

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

---

From: Songhaibin <[email-masked]>
Date: Mon, 14 May 2012 09:24:39 +0000

Hi Rich,

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Richard Alimi
> Sent: Sunday, May 13, 2012 2:05 PM
> To: Songhaibin
> Cc: Enrico Marocco; [email-masked]
> Subject: Re: [alto] WGLC: draft-ietf-alto-protocol-11
> 
> > One randomly caught problem, in Section 5.1.2.2, the ordinal mode
> introduction, it says this cost mode is a ranking from a particular source to a set of
> destinations. But in Section 5.2, the introduction of cost map structure, the cost
> mode "ordinal" can be applied to m*n entries in the cost map. So I suggest to
> modify the previous section 5.1.2.2 to make them consistent.
> >
> 

I'm sorry that I have a different opinion here. The "ordinal" cost to entries in a matrix makes sense to me. I prefer to modify the definition in 5.1.2.2, the ranking can be from multiple sources to multiple destinations. Or is there special reason to limit it to 1*n?

BR,
-Haibin

---

From: Richard Alimi <[email-masked]>
Date: Tue, 15 May 2012 01:31:27 -0700

On Mon, May 14, 2012 at 2:24 AM, Songhaibin <[email-masked]> wrote:
> I'm sorry that I have a different opinion here.

No need to apologize :)

> The "ordinal" cost to entries in a matrix makes sense to me. I prefer to modify the definition in 5.1.2.2, the ranking can be from multiple sources to multiple destinations. Or is there special reason to limit it to 1*n?
>

As an author/editor, I will say that the intent was for them to be
relative to only the costs from the same source.  However, if the WG
believes that should not be he case, then please do say so.

To summarize the differences in semantics:
(a) The interpretation that an ordinal cost is relative to all other
entries in the cost map means a server could convey a policy like "I
would rather you send traffic from s1 -> d1 instead of from s2 -> d2"
(b) The interpretation that an ordinal cost is relative only to other
ordinal costs from that same source means you can't specify that
policy in an ordinal map.

The original thought was that (b) makes the protocol a bit simpler to
reason about and captures the major use cases for ordinal costs.
However, it has slightly less expressive power when it comes to
encoding policies.  It is certainly worth having the discussion as to
which way we should go.

Any other comments?

For completeness, note that we did have a discussion with regards to
whether costs had to be unique, and the decision was "no":
  http://www.ietf.org/mail-archive/web/alto/current/msg01064.html
(your question is different from that, though.)

Thanks,
Rich

---

From: Songhaibin <[email-masked]>
Date: Thu, 17 May 2012 22:04:10 +0000

________________________________________
From: [email-masked] [[email-masked]] on behalf of Richard Alimi [[email-masked]]
Sent: Tuesday, May 15, 2012 4:31 PM
To: Songhaibin
Cc: [email-masked]
Subject: Re: [alto] WGLC: draft-ietf-alto-protocol-11

No need to apologize :)

[Haibin] I only pretended to be. :)

Any other comments?

[Haibin] I can give a use case where "option (a)" is meaningful. I think other people might give other use cases too. Assume that in CDN interconnection scenario, there are several surrogates from downstream CDN that can be injected delegate contents from upstream CDN, and at the same time there are a few surrogates in the upstream CDN that can provide the content. It is better to query the ALTO server do decide a path from a particuplar surrogate of upstream CDN to a surrogate of downstream CDN. The ordinal costs applied to a m*n entries can be used for this decision.

Yes. I agree with this point.

-Haibin

Thanks,
Rich

---

From: Sabine Randriamasy <[email-masked]>
Date: Mon, 21 May 2012 17:11:53 +0200

Hi Rich,

> 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.
> overall network topology.
Yes, thanks
> 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.
*
> the Discussion section of this document and in the requirements
Ok
> 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.
> Do you instead mean ~real-time congestion control protocols?  If so,
yes, sorry for the confusing phrasing.
> know if anyone disagrees)
Ok
>   "an ALTO Client requests... "
yes
> 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
> Ack - I'll just avoid the extra 'ALTO' when updating the text :)
Ok :-)
> 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"
> 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".

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'.
> not authoritative as to what capabilities are supported.  See 7.6.3
Ok
> Each cost-map endpoint need not support the routingcost type - an ALTO
Ok
> 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
> This seems worth clarifying - I'll add a note to do that.
Thanks
> Same as the response above, I believe.
Yes, again, my confusion.

---

From: Sabine Randriamasy <[email-masked]>
Date: Mon, 21 May 2012 18:12:09 +0200

Hi Rich,

below are my answers to your feedback on part 2
Thanks
Sabine

> Yes.  If it was unclear, feel free to provide alternate text to clarify it.
Replacing it with the sentence you propose below is fine.
> for a particular endpoint, then it MUST omit it .. "
Yes, adding the term value clarifies the sentence.