Re: [alto] WGLC: draft-ietf-alto-protocol-11 - Part II + Part I

[Richard Alimi <[e-mail]>]

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
<[e-mail]> 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.

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

>
>
> 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
>> [e-mail]
>> 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 : [e-mail]
> TEL: [phone]         (On Net) 2 103 27 45
> ---------------------------------------------------------
>
> _______________________________________________
> alto mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/alto