Thanks for framing specific areas for comment.
>
P Go Green! Print this email only when necessary. Thank you for helping Time
Warner Cable be environmentally responsible.
-----Original Message-----
> From: [email protected] [mailto:[email protected]] On Behalf
Of Enrico Marocco
> Sent: Wednesday, February 18, 2009 3:31 PM
> To: [email protected]
> Cc: [email protected]
> Subject: [alto] IETF74 - Current status and agenda requests
>
> Folks,
>
> As you can see on the DRAFT agenda for the SF meeting, the ALTO
working group is
> going to meet in a 2-hour session on Thu March 26 (expect the day to
change!). Since the
> first deadlines are approaching fast, the chairs would like to make
the best use of meeting
> time to make progress toward meeting them. Such deadlines concern the
following
> documents:
>
> + problem statement:
I can live with it. Some comments/questions:
The definition of resource is clunky. "Content" is very different from
a "server process"
like a relay server. I'd like to see these called out as separate but
equal definitions.
Figure 1 includes a "Super-peer (Tracker, proxy)". None of those terms
is defined in the
Definitions section, or in the description of the figure.
Section 4.2 is useful, but I wonder if it could be more explicit that
ALTO is not expected
to help choose among anycast instances, or among caches not defined in
the ALTO
service. That is, if I download from a web site using HTTP or FTP, and
the site
presents me with a list of servers, ALTO is not expected to help me
choose.
I'm having trouble visualizing the "ephemeral node" mentioned in 5.2,
but that may
be a lack of imagination on my part.
None of these is absolutely essential.
> + requirements: draft-kiesel-alto-reqs was discussed during the last
two
> meetings, but it seems there is still no fundamental agreement in
the
> WG about the approach the requirements document should adopt. The
> situation has now been stale since Minneapolis: if you want to
> contribute to this work and have an opinion, this is the very right
> time to let the group hear it;
It's close, but I'm not sure yet. I've missed previous discussions, so
please
forgive any retreads. .
In the introduction, an example using ALTO "to select a media relay
needed for
NAT traversal" is given. Great example, I want it, but I had to tilt
and squint
to see how NAT traversal could be content (it can't; it's definition #2
of
"resource".)
I think REQ#2 includes two separate requirements:
An ALTO client MUST be able to query information from the ALTO
service.
An ALTO server MUST provide guidance for selecting a resource
provider.
I need explicitness in REQ#4. The way I read REQ#17, the server must
include
authorization; as an ISP, I could refuse to authorize third parties
access to ALTO
data, or limit their access differently than customer-clients. I
probably want to do
that, to prevent malicious discovery from any random ALTO queriant. But
REQ#4
seems to say I MUST support queries from not-my-customer, on behalf of
my
customer, about what points are relatively close to my customer. Maybe
it just
says the *protocol* must support, and I can live with that, as long as
it's
understood that any given *server* may not allow queries from external
resource
directories.
I don't understand REQ#6. Does it mean the ALTO protocol must use a
congestion-aware transport, or does it mean whatever application makes
use of
ALTO guidance should use a congestion-aware protocol? If the former,
it's unclear.
If the latter (i.e., 'BT should use congestion control'), that's a good
idea, but not a
requirement of the ALTO protocol.
In REQ#7 I would like to include that ALTO MUST work if an empty
response
is received. In other words, the case where the ALTO server has no
clues to
offer. For this and following REQs, we probably need a term, like "No
information
available" or "No guidance" or "Null response" or "Empty response."
REQ#12 says that the required response to "I'm busy" is to act as if no
response
was received. REQ#9 says the client may retransmit if not response is
received.
I suggest REQ#12 should say "as if it had received an empty reply, i.e.,
no
guidance."
More later, but that's what I got from the two urgentish drafts.
Thanks,
Lee
This E-mail and any of its attachments may contain Time Warner
Cable proprietary information, which is privileged, confidential,
or subject to copyright belonging to Time Warner Cable. This E-mail
is intended solely for the use of the individual or entity to which
it is addressed. If you are not the intended recipient of this
E-mail, you are hereby notified that any dissemination,
distribution, copying, or action taken in relation to the contents
of and attachments to this E-mail is strictly prohibited and may be
unlawful. If you have received this E-mail in error, please notify
the sender immediately and permanently delete the original and any
copy of this E-mail and any printout.
_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto
