On 05/09/2016 03:56 PM, Sebastian Kiesel wrote:
Hi Vijay,
all,
I started integrating Vijay's comments into the document.
Sebastian: Thank you for taking your time to do this. Below, I
only provide feedback on issues that we need to further resolve.
Consider all other issues not listed below to be resolved as reflected
in the diff that you attached (which was very helpful).
A couple of places in your feedback you noted that some input from
Hans may be needed. Can you please drive this to completion soon? If
Hans does not have the bandwidth, we will simply go with what we have
for those sections.
More inline.
- S2.1.1, bullet 2: s/to the queries to the/to satisfy the queries about a
particular/
these three bullets are copied verbatim from RFC 5693 and I am reluctant
to change the wording.
I believe my suggested revisions to bullet 2 adds minor clarifications
to the grammar of rfc5693. (I am fine with wordings of bullets 1 and 3,
so those are off the discussion here.) Now, reluctance to change the
wording in bullet 2 simply because it is copied from rfc5693 may be
justifiable if whoever read this I-D knew rfc5693 inside-out. In the
absence of such a case, I will contend that any clarity we add to the
specifications, however late, is always better.
That said, I will leave it to your sound judgment on what to do. I
will certainly not be offended if you decided not to include this
change, so no worries.
- S2.2.1, second paragraph: "4. Resource consumer (using the ALTO
guidance)".
Here, what context does the phrase "using the ALTO guidance"
impart? Does
not the ALTO client also uses the ALTO guidance? Is the guidance
provided
to a resource consumer different than the one provided to a
client? Where
have you made the distinction between an ALTO client and a resource
consumer? Later on in S3.2.2 you make a distinction by qualifyin an
application as a resource consumer; perhaps you can make this
distinction up
front.
See my thought on the terminology above ... When we combine the
terminology definitions of RFC 5693 with the ALTO core specification
RFC 7285, the outcome would IMO be:
An ALTO client is basically a HTTP client library, a JSON parser
library, and some data structures, which does not need guidance itself.
It is linked into the resource consumer (i.e., for example the specific
BitTorrent client process running on your computer), because the latter
needs the guidance.
OK, so this is good. How about imparting this definition in the I-D,
something like the following:
OLD: (S2.2.1)
An ALTO deployment involves four kinds of entities:
1. Source of topological information
2. ALTO server
3. ALTO client
4. Resource consumer (using the ALTO guidance)
NEW: (S2.2.1)
An ALTO deployment involves four kinds of entities:
1. Source of topological information
2. ALTO server
3. ALTO client
4. Resource consumer (using the ALTO guidance)
(We differentiate between an ALTO client and a Resource Consumer
as follows: an ALTO client will be composed of software implementing
a HTTP client library, a JSON parser library and some data
structures representing the ALTO maps. This library will be
linked in to a Resource Consumer, which could be thought of as
the process executing on a host communicating with an ALTO
server.)
- S2.2.1, sixth paragraph, item 1: s/network, or not/network.
Is the resulting sentence really a full sentence?
The deployment of ALTO can
differ depending on whether ALTO client and ALTO server
are operated within the same organization and/or network.
Good point, perhaps best to leave it as is.
- S2.2.1, sixth paragraph, item 2: s/clients, e.g., after/clients
only after/
that would change the example to the only case.
another example could be an internal network.
OK, leave it as is.
- S.2.2.1, last paragraph: s/if no ALTO servers can be found/in the
absence of
any ALTO server,/
the old wording also covers the case that there are ALTO servers around,
but the discovery mechanism fails.
OK, leave as is.
- S2.2.2, first paragraph, item 1: s/the client does not have to reveal/the
server does not have to reveal/
NACK. That is correct as is.
OK.
- S2.2.2, first paragraph, item 2: s/can be realized/is realized/
In ALTO, this approach can be realized by the Endpoint Cost Service
and other related services.
(e.g. the endpoint property service, the PID property service, ...)
OK.
- S2.2.3, item 1: s/REST- ful protocol/REST-ful protocol/
can't find that in the text. it is already REST-ful without a space after
the dash. Can you please check again?
My bad, not sure where I got that from. Never mind.
- S3.1.1, first paragraph: Insofar as you want to make a distinction
on an NSP
and an ISP, the distinction should be that while NSPs provide network
connectivity and routing in the network they manage, they must
depend on an
ISP to connect them to the Internet. Thus, an ISP may be an NSP but the
reverse is not true. I don't know whether you want to make this
distinction
or not, but thought I'd point it out.
There are different definitons of NSP around. Another common one would
be a "wholesale ISP" or what is usually called a Tier-1 carrier.
Or something like the IT department of a company, which does not only
provide bare Internet Connectivity, but also, say, file storage on
"network drives", etc.
I think the best thing to do would be to go through the whole section
and replace all occurences of ISP and NSP by network operator.
I will leave it to you to decide whether to do this or not.
- S3.1.5, first paragraph: s/, e.g.,//
why? "exposing network performance information" is only one thing
an alto server can do.
OK, leave as is.
- S3.2.4, first bullet under "Distance-related rating criteria:"
s/values, and the ALTO client will not be informed about the
nature of the
information./values.
why?
this sentence has two aspects:
- the server is free to chose how to compute the values, and
- the server does not even have to tell the client how he did it
both are important
OK, in that case, I would suggest
s/nature of the information./nature of the computation./
This makes it more direct that there are two aspects as you point
out above.
- S3.5.3, first paragraph: The key point here is that the cellular wireless
bandwidth is a constrained resource, normal wireless (IEEE 802.11)
is not as
much constrained as the cellular data network. My suggestion would be to
simply s/wireless bandwidth/cellular wireless bandwidth/
not sure why we need the distinction between 802.11 and cellular here.
both are less preferred than wireline.
we could do a four-tier example:
preference(true wireline clients) >
preference(wifi clients behind access points hooked up to the wireline
internet access by the paying customers) >
preference(wifi clients at access points operated by the ISP) >
preference(cellular clients)
but this goes way beyond what we need.
We don't need to do a four-tier example, but clearly you will agree that
the characteristics of the cellular bandwidth (of the kind provided by
an operator) are much different than those of WiFi bandwidth. The
resources in the former are scarcer than those in the latter. All this
said, I re-read the portion in question and perhaps the best thing to
do is to just leave it as is. So, much ado about nothing :-)
- S3.5.3, Figure 13: For the sake of completeness and symmetry, you should
specify the costs for the links that joins (PID 3, PID 1), as well as the
text that makes it costly for peers in PID 3 to get content from
PID 1, but
not as costly to get content from PID 2.
Who contributed this example? Hans? Can you do that?
Will need to close this soon. Can you please drive this to completion
with Hans?
- S3.6.1, Figure 15: What would be good is if the link weights in
this figure
were also reflected in Figure 14. That way, later on when one is
interpreting the hopcount cost map (Figure 20), it is easy to see
that the
path weight between R1->R3->R4->R9 is 40.
Who contributed this example? Hans? Can you do that?
Will need to close this soon. Can you please drive this to completion
with Hans?
- vijay
--
Vijay K. Gurbani, Bell Laboratories, Nokia Networks
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg@{bell-labs.com,acm.org} / [email protected]
Web: http://ect.bell-labs.com/who/vkg/ | Calendar: http://goo.gl/x3Ogq
_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto
