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

[Sabine Randriamasy <[e-mail]>]

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