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.
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 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 a écrit :
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.
_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto
--
---------------------------------------------------------
Sabine RANDRIAMASY
Alcatel-Lucent Bell Labs France
Centre de Villarceau
Route de Villejust - 91620 NOZAY - FRANCE
E-MAIL : [email protected]
TEL: +33 (0)1 30 77 27 45
(On Net) 2 103 27 45
---------------------------------------------------------
_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto
