> From: Laird Popkin <laird at pando.com> > > Regarding: > > > > Req 8 recommends an action. I suggest " An overloaded ALTO server receiving > too many requests should be able to handle the problem e.g. it MAY silently > discard excess requests" > > > > LP: The only requirement (IMO) from the app side regarding ALTO availability > is that if ALTO cannot respond to a request that it should do so in an easily > identifiable way so that the app doesn't wait "forever" for a response that > it's not going to get. (e.g. reply with a 'busy' message, rather than silently > not responding) : well, the cause of the inability to respond may also prevent the ALTO server to send anything back... s. > > - Laird Popkin, CTO, Pando Networks > mobile: 646/465-0570 > > ----- Original Message ----- > From: "Roni Even" <ron.even.tlv at gmail.com> > To: alto at ietf.org > Sent: Thursday, November 13, 2008 1:03:49 PM (GMT-0500) America/New_York > Subject: [alto] Comments on draft-kiesel-alto-reqs-01 > > > > > Hi, > > I read the draft and have some comments on section 4.2. > > > > . > > > > > Req 9 is suggested a solution that should be in other document > > > > Req 10 I suggest that it should say that a client shall not overload the > server, the current text is normative text. > > > > Req 11 is normative text and not a requirement. > > > > Req 12 the first part " An ALTO server, which is operating close to its > capacity limit, SHOULD be able to inform clients about its impending overload > situation" is the requirement the rest is normative text. > > > > Thanks > > Roni Even > > > _______________________________________________ alto mailing list > alto at ietf.org https://www.ietf.org/mailman/listinfo/alto > _______________________________________________ > alto mailing list > alto at ietf.org > https://www.ietf.org/mailman/listinfo/alto _______________________________________________ alto mailing list alto at ietf.org https://www.ietf.org/mailman/listinfo/alto
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.