![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
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 theALTO "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.
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.
- 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 ALTOThis 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).
- 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.)
After these criteria are met, the generality of the data will beWhat 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?
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, andDoes this mean that congestion is not an issue to consider ?
It is, but not in ALTO. That will be part of TANA.
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.
What is an Internet coordinate system?
Things like IDMaps, GNP, Vivaldi, etc. Should we define this
term in the charter?
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.com,bell-labs.com,acm.org}
WWW: http://www.alcatel-lucent.com/bell-labs
_______________________________________________
Ietf mailing list
Ietf at ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.