Re: [alto] WGLC: draft-ietf-alto-protocol-11

[Richard Alimi <[e-mail]>]

[ mistakenly dropped alto list from my reply...]

On Sun, Jul 1, 2012 at 10:05 PM, Richard Alimi <[e-mail]> wrote:
> On Mon, May 21, 2012 at 8:11 AM, Sabine Randriamasy
> <[e-mail]> wrote:
>>
>> Hi Rich,
>>
>>
>> Richard Alimi a écrit :
>>
>>> On Fri, May 11, 2012 at 11:15 AM, Sabine Randriamasy
>>> <[e-mail]> wrote:
>>>
>>>>
>>>> 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.
>>>>
>>>
>>>
>>> Yes - that sounds reasonable.  We'll do a search for the word 'peer'
>>> to see if a better term can be used, and also add a reminder in the
>>> use cases that P2P is not the only deployment setting.
>>>
>>>
>>>>
>>>> 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?
>>>>
>>>
>>>
>>> I don't recall this discussion - do you have a pointer?
>>>
>>> If I'm understanding the proposal correctly, I am concerned about how
>>> much duplicate information that would generate.  Is there an example
>>> RFC you could reference that does this?
>>>
>>
>> I remember there was a discussion on the list and also in Quebec that was on
>> specifying the features that the ALTO MUST have. My question here was rather
>> on the possibility listing the MUST identified in the doc. I don't have any
>> reference of RFC doing this and as it may generate duplicate information
>> then it seems preferable not to do it.
>
> Given the concern over a large amount of duplicate text in the draft,
> I'd like to leave such a list out unless there are others in the WG
> that feel strongly that we should have it.
>
>>
>>>
>>>>
>>>> -----------------------------------------------------
>>>> 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.
>>>>
>>>
>>>
>>> We can add something there. A better way to phrase this might be that
>>> a view only from the view of the endhosts makes it
>>> difficult/impossible to be aware of policies or properties of the
>>> overall network topology.
>>>
>>
>> Yes, thanks
>>
>>>
>>>>
>>>> - §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.
>>>>
>>>
>>>
>>> Just to be sure I understand, which specific tools were you thinking
>>> about here?  BGP looking glasses or whois?  Or others?
>>>
>>
>> I'd say both and other related such as *ClosestNode.com or others examples
>> you may have in mind.
>
> I think we can expand this sentence to mention some existing examples.
>  As far as arguing that there needs to be a standardized mechanism, I
> think the Problem Statement document should do that already.
>
>>
>> *
>>>
>>>
>>>>
>>>> - §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?
>>>>
>>>
>>>
>>> I would tend to keep the security/privacy issue out of the
>>> introduction when we are motivating the protocol.  These are
>>> requirements that should (I believe, anyways) already be handled in
>>> the Discussion section of this document and in the requirements
>>> document.
>>>
>>
>> Ok
>>
>>>
>>>>
>>>> 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.
>>>>
>>>
>>>
>>> I'll see what we can do to add a small hint in here without going into
>>> detail.
>>>
>>
>> Sure. It's just that 2 or 3 lines with basic Alto services would make the
>> reading more comfortable.
>>
>>>
>>>>
>>>> - in 1st sentence: "... the peer selection process ... " ==> "peer" shoud
>>>> be
>>>> replaced by "connection endpoints such as peers"
>>>>
>>>
>>>
>>> Ack.
>>>
>>>
>>>>
>>>> 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.
>>>>
>>>
>>>
>>> Ack - we'll add this.
>>>
>>>
>>>>
>>>> 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.
>>>>
>>>
>>>
>>> Do you instead mean ~real-time congestion control protocols?  If so,
>>> we can add a reminder.
>>>
>>
>> yes, sorry for the confusing phrasing.
>>
>>>
>>>>
>>>> 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.
>>>>
>>>
>>>
>>> Actually, I think the term can just be dropped at this point. (Let me
>>> know if anyone disagrees)
>>>
>>
>> Ok
>>
>>>
>>>>
>>>> Also replace "informtion" ==> "information".
>>>>
>>>
>>>
>>> Ack.
>>>
>>>
>>>>
>>>> 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."
>>>>
>>>
>>>
>>> Does changing it from
>>>   "an ALTO Client may request ... "
>>> to
>>>   "an ALTO Client requests... "
>>> clear this up?
>>>
>>
>> yes
>>
>>>
>>>>
>>>> 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.
>>>>
>>>
>>>
>>> The advice is common to any ALTO implementation, even one that is
>>> supporting an extension.  If an implementation is supporting an
>>> extension, then those fields are no longer "unknown".
>>>
>>
>> Ok
>>
>>> If that still isn't clear, do you have an alternate suggestion on the
>>> wording?
>>>
>>
>> We can leave the initial sentence
>>
>>>
>>>>
>>>> Section 7.4 ALTO Errors
>>>> - §3 2nd sentence: "... information about the why a particular ...": i
>>>> suggest to remove "the" => "... information about why a particular ..."
>>>>
>>>
>>>
>>> Ack - thanks.
>>>
>>>
>>>>
>>>> Section 7.4.1 Media Type
>>>> "... The media type for an Error Resource ...": does it mean "The media
>>>> type
>>>> for an ALTO Error Resource" ?
>>>>
>>>>
>>>
>>>
>>> Yes - we'll make that more precise.
>>>
>>>
>>>>
>>>> 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.
>>>>
>>>>
>>>
>>>
>>> Ack - I'll just avoid the extra 'ALTO' when updating the text :)
>>>
>>
>> Ok :-)
>>
>>>
>>>>
>>>> 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."
>>>>
>>>>
>>>
>>>
>>> Ack.
>>>
>>>
>>>>
>>>> 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."
>>>>
>>>
>>>
>>> Ack.
>>>
>>>
>>>>
>>>> - §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.
>>>>
>>>
>>>
>>> Each capability should have a default value documented in this
>>> specification - the text here is only indicating that the client
>>> should fall back to that value.  Does that answer the question?
>>>
>>
>> Yes. Then how about saying "or assume its default value that SHOULD be
>> documented in this specification"
>
> That sounds fine, but I'll just rephrase to say "or assume its default
> value which is documented in this specification."   I don't think
> normative language is needed there, since the instruction applies to
> the document authors/editors/WG and not the implementers.
>
>>
>>> Note to self: "empty array" -> "empty object" in this paragraph
>>>
>>>
>>>>
>>>> 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. says:
>>>    An ALTO Server MUST support all of the Cost Types listed here for
>>>    each of the listed Cost Modes.  Note that an ALTO Server may provide
>>>    multiple Cost Map Information Resources, each with different
>>>    capabilities.
>>>
>>> Does that answer both questions?
>>>
>>
>> If the conclusion of this text for the example IRD is that 'routingcost' and
>> 'hopcount' are each available for both 'numerical' and 'ordinal' mode, then,
>> as § 7.7.1.2.4 comes after the IRD example, I think that things would be
>> completely clear if § 7.6.3 would include an illustrative sentence like, "In
>> this example, the ALTO server provides the Endpoint Cost Service for Cost
>> Types 'routingcost' and 'hopcount', each available for both 'numerical' and
>> 'ordinal' mode".
>
> That sounds fine to me. We'll add a hint here.
>
>> As for my 2nd question, I understand that for the mentionned case, the IRD
>> then must include 2 URIs: one for 'routingcost' and the other for
>> 'hopcount'.
>>
>>>
>>>>
>>>> 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..*> ?
>>>>
>>>
>>>
>>> There are valid cases for them being empty. Specifically, this can
>>> happen if the server generating the Information Resource Directory is
>>> not authoritative as to what capabilities are supported.  See 7.6.3
>>> for an example.
>>>
>>
>> Ok
>>
>>> Each cost-map endpoint need not support the routingcost type - an ALTO
>>> Service must do so.
>>>
>>
>> Ok
>>
>>>
>>>>
>>>> See also §7.7.3.1.3 Input Parameters, where encoding "EndpointProperty
>>>> properties<1..*>" is used, because 'pid' MUST be available.
>>>>
>>>
>>>
>>> Do you mean "EndpointProperty prop-types<0..*>;" instead?
>>>
>>
>> Yes, the error is on my side, there was a confusion with §7.7.3.1.4
>> Capabilities.
>>
>>> This has a similar reasoning to the above for cost maps.
>>>
>>
>> Ok
>>
>>>
>>>>
>>>> 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".
>>>>
>>>
>>>
>>> Agree. that should not explicitly mention numerical costs in the
>>> documentation for constraints.  Good catch.
>>>
>>>
>>>>
>>>> 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... ".
>>>>
>>>
>>>
>>> Ack.
>>>
>>>
>>>>
>>>> I also suggest to add that
>>>> property 'pid' MUST be provided.
>>>>
>>>
>>>
>>> That is already noted in 7.7.3.1 right?  Note that a particular URI
>>> need not provide the 'pid' property - the ALTO Service as a whole
>>> needs to do so.
>>>
>>> This seems worth clarifying - I'll add a note to do that.
>>>
>>
>> Thanks
>>
>>>
>>>>
>>>> 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..*>" ?
>>>>
>>>
>>>
>>> Same as the response above, I believe.
>>>
>>
>> Yes, again, my confusion.
>>
>>>
>>>>
>>>> -----------------------------------------------------
>>>> 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 ..."
>>>>
>>>>
>>>
>>>
>>> Ack.
>>>
>>> Thanks!
>>> Rich
>>>
>>>
>>>>
>>>> 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
>>>>
>>
>>