Hi Rich,
Richard Alimi a écrit :
On Mon, May 21, 2012 at 8:11 AM, Sabine Randriamasy
<[email protected]> wrote:
Hi Rich,
Richard Alimi a écrit :
On Fri, May 11, 2012 at 11:15 AM, Sabine Randriamasy
<[email protected]> 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.
Sure, I think we have agreed upon this.
-----------------------------------------------------
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.
thanks
As far as arguing that there needs to be a standardized mechanism, I
think the Problem Statement document should do that already.
Ok. I figured 2-4 lines could help but don't want to overload the text.
So refering to the pb statement is fine.
*
- §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.
Ok
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.
Thanks
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
[email protected]
https://www.ietf.org/mailman/listinfo/alto
_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto
