Hi Rich,
below are my answers to your feedback on part 2
Thanks
Sabine
Richard Alimi a écrit :
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 protected]> wrote:
-----------------------------------------------------
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?
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 :)
- §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?
Yes. If it was unclear, feel free to provide alternate text to clarify it.
Replacing it with the sentence you propose below is fine.
If an ALTO server defines a property for an endpoint but no value, what
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 .. "
Yes, adding the term value clarifies the sentence.
Section 7.7.3.1.6 Example
An example of request/response with several properties would be good here.
Makes sense - we can add that.
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 ..."
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.
Section 8.1 ALTO ALTO Client Embedded in P2P Tracker
- §1 1st sentence "Many P2P currently-deployed P2P systems... ": ==> "Many
currently-deployed P2P systems... "
Ack.
Section 9.4 Mapping IPs to ASNs
- §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.
-----------------------------------------------------
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 ..."
Ack.
Thanks for the review!
Rich
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
_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto
