Re: WGLC: draft-ietf-alto-protocol-11 - Part II + Part I
Sabine Randriamasy <Sabine.Randriamasy <at> alcatel-lucent.com>
2012-05-11 23:17:03 GMT
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
> alto <at> ietf.org
> 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 : Sabine.Randriamasy <at> alcatel-lucent.com
TEL: +33 (0)1 30 77 27 45
(On Net) 2 103 27 45
---------------------------------------------------------
RSS Feed