Dear Vijay;
On Oct 10, 2008, at 5:31 PM, Vijay K. Gurbani wrote:
Marshall Eubanks wrote:
I support this moving forward. My reading of the room in Dublin was
that there was serious support for this and certainly a critical mass
to move forward.
Marshall: Thank you for your review. More inline.
Some comments in the charter below. This document clearly needs some
more work. As a overall comment, I think it is premature to discuss
ALTO "servers" and would keep the charter focused on describing the
ALTO "service."
In an earlier reply to Vidya I note that the charter does indeed
predominantly refer to "ALTO services" over "ALTO server".
Having said that, if I did not convince you through that
argument, then we can leave the "s/ALTO server/ALTO service"
discussion on the table.
I do not see consensus at this moment as to a central
service solution versus a distributed solution.
Agreed.
To me, this agreement answers the previous point. (Servers presupposes
the answer, service does not IMO.)
s/choose/choose the best peer or peers to exchange data with/
Unfortunately, in the Dublin BoF charter, we did state best peer
(we had termed it "optimal" peer). This was one reason for the
negative hums in the BoF because people have differing notion of
what an "optimal" (or best) peer is. Thus, we reverted to the
non-confrontational use of the phrase that you now see in the
charter.
OK, but is doesn't read well :
In
contrast to client/server architectures, P2P applications often have
a selection of peers and must choose.
There is a missing object. How about
must choose one or more peers from this selection.
?
- A request/response protocol for querying the ALTO service to
obtain information useful for peer selection, and a format for
requests and responses. The WG does not require intermediaries
between the ALTO
This is strange wording, as WG themselves are not protocols.
More fundamentally, is this a requirement?
No. We had some list discussion on whether or not to include
intermediaries, but the resolution of that discussion appeared
to be no (please see the few emails around the following
link: http://www.ietf.org/mail-archive/web/p2pi/current/
msg00635.html).
How about
s/The WG does not/In scope solutions do not/
- Can the ALTO service technically provide that information?
I think that what is meant here is "Can the ALTO service
realistically discover that information?"
OK.
- Is the ALTO service willing to obtain and divulge that
information?
Do computers have free will?
AI notwithstanding ;-) But point taken; we can attempt a
reword (if you have any suggestions, please throw them our way.)
Whose will ? This gets to a crucial difference between a central
server and a distributed system.
If it is a central server, then the owner of that server gets a vote
here, and maybe a veto.
It it is distributed service, then the owners of the peers will
ultimately decide this.
How about
- Is the ALTO service technically able to obtain that information, and
is the distribution of
that information allowed by the operators of that service ?
After these criteria are met, the generality of the data will be
What is meant by "the generality of the data" ?
considered for prioritizing standardization work, for example the
Hmmm ... since we are talking about prioritizing, maybe what is
meant is "importance" -- as in "importance of the service" --
may be a better fit. Comments?
WFM
number of operators and clients that are likely to be able to
provide or use that particular data. In any case, this WG will not
propose standards on how congestion is signaled, remediated, or
avoided, and
Does this mean that congestion is not an issue to consider ?
It is, but not in ALTO. That will be part of TANA.
ACK
If the closest peer to me was totally congested and had no available
bandwidth, isn't that something that I would want to know ?
will not deal with information representing instantaneous network
state.
What is meant by "information representing instantaneous network
state" ? Isn't this a protocol to share information about the state
of the network ? Or is this an attempt to separate network topology
from network performance ? But should network performance also be an
issue ?
By and large, it has been the case that that instantaneous
network characteristics -- like current link usage, congestion,
etc. -- are not be part of ALTO; they will be part of TANA.
Hence, congestion control was deemed out of scope.
OK. This WFM now.
What is an Internet coordinate system?
Things like IDMaps, GNP, Vivaldi, etc. Should we define this
term in the charter?
I was not aware of this work. Thanks for alerting me to it.
Regards
Marshall
Thanks, Marshall.
- vijay
--
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
Email: vkg(_at_){alcatel-lucent(_dot_)com,bell-labs.com,acm.org}
WWW: http://www.alcatel-lucent.com/bell-labs
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf