Subject: [alto] Is there meeting minutes for ALTO, IETF 75?

From: "Y.J. Gu" <[email-masked]>
Date: Mon, 03 Aug 2009 16:22:46 +0800

Say hello everybody.
I did not attend the meeting, is there meeting minutes for ALTO?
Thank you.

Regards

Yingjie Gu

---

From: Enrico Marocco <[email-masked]>
Date: Mon, 3 Aug 2009 10:44:27 +0200

Attached are the raw notes we've received from on of the two note takers
(thanks Jan!). As soon as we receive notes from the other note taker,
we'll produce a digested version and will upload it on the proceedings page.

Enrico

Y.J. Gu wrote:
> _______________________________________________
> alto mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/alto
IETF-75 ALTO Session
Notes by Jan Seedorf
--------------------
--------------------

Jon Peterson presents the note well and agenda
----------------------------------------------
-- there are two related bar bofs this ietf: DECADE on Wednesday and PPSP on Thursday, problem statement doc is in last call, requirements draft was agreed to stay alive for a while, protocol proposals and survey proposals have merged since ietf-74

Sebastian Kiesel presents the alto-requirements draft
-----------------------------------------------------
-- draft has been adopted as WG item at ietf-74
-- there are three new terms replacing the "host location attribute" (see slides for details), several requirements can be expressed better with the new terms (examples on the slides), no comments on the new "host group descriptor requirements" Sebastian presented
-- there are different options regarding alto server discovery requirements (ALTO client finding "right" ALTO server, or ALTO client finding a near ALTO server and then redirection), Hannes: what do operators think on this issue, Hannes: Finding the access provider based on the IP address of the end host is complicated and error prone, Song Haibin: redirection might be good for load balancing but prefers first option, Rich Woundy: undecided, maybe a combination is best way to go, Rony Evan: why does there have to be a requirement either way?, Albert Tian: also thinks not necessary to have such requirements, second option seems more doable, ??: what means "right" ALTO server is not clear, David ?: some parts of the requirements doc are confusing, including this issue, Hannes: Nobody is going to read that document anyway after it is finished, Rich Alimi: worried about the trust issue in the second option when there is redirection between ALTO servers, Lars: probably the discovery requirement should be more general and not so detailed,
-- there are new security requirements regarding authentication of servers and clients, Lars: authentication between client and servers is probably not so important but data authentication (authenticating the information exchanged) is important, Ruediger: what kind of NAT is meant with the NAT traversal requirement?, 
-- general comments/discussion; David ?: are the new terms target of the query?, John ?: have you considered and anonymity server for privacy purposes?, further discussion referred to the mailing list

Reinaldo Penno presents the merged alto protocol draft
-----------------------------------------------------
-- the current draft is a merger of plenty initial protocol proposals (P4P, infoexport, ATTP, proxidor, ...), Reinaldo presents the contributions of the individual drafts which have now been merged together, Martin: what happened to the proxidor approach of sorting ip addresses in the server, abandoned? How did the merger happen exactly? answer: none,
-- Reinaldo explains the "my internet view" concept and other key concepts of the draft, there may be multiple costs between a pair of network locations, Lars: is the "my internet view" service specific? do several clients have to ask twice? answer: peers within the same group should have the same "my internet view", Lars: can you query information only related to yourself or also query information between two other peers?, answer: both possible, ??: costs are a critical issue, should the WG make certain cost types a requirement?, Wolfgang: does A really need to know the cost between B and C, and would any service provider actually reveal such information? answer: there are different types of cost, not only monetary costs
-- Rich Alimi presents some details of this protocol proposal: Rich presents use-cases, ALTO query types, Lars: we should think what information exchange actually makes sense, not everything is necessarily to be done via an ALTO-service; Rich explains network map, ??: returning a range of values is good for privacy, maybe this should enter the requirements in the future; Rich explains path rating and protocol message encoding (proposed is http + REST-ful API + XML encoding in bodies), Volker: there is lots of felxibility in the protocol, this means that clients and servers need to implement many options and maybe this should be implified, answer: this should be discussed; Rich presents use-cases in detail (see his slides); Rich aks WG if this should be adopted as WG item?
-- discussion: Stefano: supports adoption as WG; Lisa: this is probably the best REST-ful design she has seen in the ietf; Bertrand Mathieu: does not think it is a good merged document, has concerns that the information retrieved from ALTO is quite extensive; Jan Seedorf: has concerns with the workload for ALTO servers caused by queries with multiple source network locations, risk of easy DoS attacks, answer: the resulting answer matrices can be pre-computed and should not change that frequently
-- no hum on WG adoption, further discussion referred to the mailing list

Zoran Despotovic presents Feedback-based Client Prototol
--------------------------------------------------------
-- see slides for details
-- no questions nor comments regarding this proposal

Marco Tomsu presents the merged ALTO discovery protocol
-------------------------------------------------------
-- the current draft is mainly a merger without much new technical content, next steps are adopting the draft as a WG document
-- discussion: David ?: what is really the information needed? what does really need to be standardized? ??: are different versions considered for DHCP and in general? answer: yes;
-- no hum on adopting this draft as WG document

Zoran Despotovic presents BGP-based ALTO Service
------------------------------------------------
-- BGP can be the source for locaility information used by an ALTO-server, Zoran presents the relevant BGP attributes which could be used, 
-- discussion: David ?: thinks this is an interesting direction; Stefano: understand usefulness of BGP but finds the approach dangerous because it uses different semantics, may have impact on actual BGP use

---

From: "Y.J. Gu" <[email-masked]>
Date: Mon, 03 Aug 2009 17:32:18 +0800

Thank you, Enrico. 

Regards

Yingjie Gu

-----Original Message-----
From: Enrico Marocco [mailto:[email-masked]] 
Sent: Monday, August 03, 2009 4:44 PM
To: Y.J. Gu
Cc: 'alto'
Subject: Re: [alto] Is there meeting minutes for ALTO, IETF 75?

Attached are the raw notes we've received from on of the two note takers
(thanks Jan!). As soon as we receive notes from the other note taker, we'll
produce a digested version and will upload it on the proceedings page.

Enrico

---

From: Song Haibin <[email-masked]>
Date: Tue, 11 Aug 2009 17:06:36 +0800

Hi Matthias,

Good comments. See inline.
 
>From: [email-masked] [mailto:[email-masked]] On 
>Behalf Of Matthias Waehlisch
>Sent: Thursday, July 30, 2009 10:39 PM
>To: alto
>Subject: [alto] ALTO Server Discovery
>
>Hi Marco and Song,
>
>  I quickly gone through the draft and have the following questions and
>comments:
>
>  * What is the actual intention of the draft: Is it a problem 
>statement, requirement draft, or an aggregation of solutions 
>including suggestions for specific scenarios?
>

It is intended to describe using exsiting mechanisms for ALTO discovery.
However, you may need different mechanism in different scenarios. OTOH, the
ALTO discovery may partly depend on the framework of ALTO protocol, but we
don't have a working group item for ALTO protocol now. That's why we don't
go to deep details of each possible discovery mechanism at present.

>  Personally, I would prefer a decent description of the 
>problem space, which can be used to derive suggestions for 
>possible solutions.

We describe ALTO service deployment and ALTO discovery scenarios for that
purpose in section 3 and section 4.

> As far as I understand, ALTO does not want 
>to define a new discovery protocol - btw: 
>which is fine -, but rather describe the use of existing (service
>discovery) mechanisms in the context of ALTO (in the sense of 
>a Best Current Practice).

We don't want to invent a new unnecessary discovery protocol here.

>
>  * What is the problem of service discovery in the context of ALTO?
>
>  Some thoughts: The general service discovery problem includes:
>
>    (a) Service Advertisement/Locate Service Server: You need 
>to find an agent/server that is be aware of the service 
>location. In the ALTO case, you need to locate the ALTO 
>Discovery Server.
>   
>    (b) Service Request: You need to request the location of 
>the service. 
>In the ALTO case, you contact the ALTO Discovery Server to get 
>the location of the ALTO Service.
>
>    (c) Topology Sensitivity: The service discovery should 
>account for the current location of the service client. (I'm 
>not fully sure if this a general issue of service discovery, 
>at least you may need it for ALTO.) 
>

I agree. 

For (a)/(b), the question is who will be the ALTO Discovery Server. It may
be the DHCP server, DNS server... 

For (c), yes, that's why caching an ALTO server address previously used may
not work properly sometimes.

>  ALTO-specific issues might be:
>
>    o Uncontrolled end user domains: In general, end user 
>devices are not administrated by an ISP-instance. This 
>includes residential gateways, which may complicate, for 
>example, the activation of further technologies such as multicast.
>

Agree. We already gave some thoughts to RGs when using DHCP option for
getting the access domain name. It's true that some mechanism has its
limitations and the final mechanism will depend on the scenario.

>    o Proxy-based service requests: A tracker, for example, 
>initiates a service request on behalf of an ALTO Discovery Client. 
>

That's a typical case. There are two ways for ALTO discovery in this case,
the tracker discovers ALTO server for the requesting client, or the client
discovers its own ALTO server and sends to the app tracker.

>    o ...
>
>
>
>  Some specific comments on dedicated sections:
>
>  Section 3: Figure 1 should be moved to section 2, because it 
>is the reference case for the ALTO Service Discovery including 
>definition of symbols, e.g., "ooo".
>
>  Section 3.1, para. 1: "ALTO servers can be deployed in an 
>ISP-centric deployment or on the application level by 
>application providers [...]." - that's confusing. In general, 
>ALTO servers will be deployed on the application level/layer. 
>You should use a consistent terminology, e.g., ISP-centric and 
>application-centric.
>...
>  A third party, for example, can provide 
>information in both cases. 

It's true.

>Implications for the service discovery process are not presented. ... 
>Probably, you want to show (a) motivations to deploy an ISP- 
>or application-specific ALTO service, (b) implications for the 
>service discovery process.
>

Thanks, we will do that in the next version.

>  para. 3: What do you mean with "spanning different networks"?
>

It actually means the service is provided from the ALTO server to different
networks.

>  "[...] and provide an ALTO service to numerous application 
>clients." - this holds for ISP-specific ALTO services, as well.
>
>  Figure 3 does not show application-specific ALTO-servers. 
>You need a second ALTO server for application B.
>

Figure 3 means that some application community such as some distributed
coordiante system could provide the ALTO service to other clients, whatever
the specific application that client belongs to.

>
>  Section 3.2: The title seems misleading. Instead of 
>"Cross-domain vs. 
>Localized ALTO Server Discovery", I would suggest something like 
>"Inter-domain vs. Intra-domain ALTO Server Discovery".
>

Good suggestion.

>  1. para: "For cross domain scenarios [...]" - these 
>scenarios have not 
>been introduced.
>
>  "For cross domain scenarios, the ALTO service includes the 
>ALTO servers 
>provided by p2p application community as well as the ALTO 
>servers provided 
>by a third party [...]" - the categories are confusing. These are two 
>different issues, or not?:
>
>   (1) ALTO servers distributed over several domains vs. local servers
>   (2) ALTO servers provided by ISPs vs. P2P community.
>

Only the ALTO server that is provided by the p2p community or a third party
could serve multiple networks. The ALTO server provided by the ISP can not
serve the clients in another ISP's network because they have different
policy and different views. What we discussed here in the draft is the
former case. 

>  3. para.: "Each network operator may have its own traffic 
>optimization 
>policy based on his network topology [...]" - the optimization 
>policy is 
>probably not only based on the network topology.
>

You are right.

>  "Each of the ALTO servers may have a FQDN." - why is this assumption 
>specific to cross-domain scenarios?
>

We also have this assumption for intra-domain scenarios.

>  4. para.: "The ALTO client (e.g. the Tracker) must be able 
>to discover 
>and choose the ALTO server that has the information that is 
>specific to 
>those clients located within that network." - this seems like an 
>intermingled requirement:
>
>  (1) The ALTO Discovery Client must be able to discover an 
>ALTO Server 
>with respect to a specific scope, i.e., intra-domain or 
>inter-domain wide.
>  (2) The ALTO Client must be able to choose among several 
>ALTO servers. 
>?? I'm not sure if this should be performed by the ALTO Client 
>and not bt 
>the ALTO Discovery Client.
>

I'm not sure if the ALTO discovery client has to choose... Personally I
don't think so. 

>
>  Section 4.1: "Discovery Metrics" - the title is misleading. 
>Subsequent 
>subsections do not define any metrics.
>
>  Section 4.1.1, 2. para.: "In a hybrid model [...]" - what do 
>you mean 
>with "hybrid"? A combination of P2P and client-server technology?
>
It simply means the ALTO servers are discovered by the p2p application
clients separately, and then sent to the app tracker.

>  Section 4.1.2, 1. para.:  "The ALTO service could be provided in a 
>distributed and cooperative fashion by the Peers in an 
>overlay, or it can 
>be provided by a centralized entity (the ALTO Server) for a 
>given scope. 
>[...]" - I'm not really sure what you are talking about, and the 
>consequences for the discovery process. Both cases differ in 
>the way how 
>ALTO data is acquired and/or stored. But this is out of scope, 
>right? In 
>both cases, you need an entity that answer ALTO Queries. And 
>you need to 
>find the entity providing this service.
>

That's true. Here we want to give an introduction of these cases and then
say the discovery process may be different to them.

>  3. para: The perspective is a bit confusing: In this paragraph, you 
>discuss discovery mechanisms and judge their applicability to 
>the location 
>of the ALTO server ... It is more helpful to state the 
>different locations 
>of the ALTO server and the corresponding requirements for the 
>discovery 
>service.
>
>  "Multicast discovery generally works within a single LAN 
>only [...]" - 
>sure? Multicast exhibits an inter-domain deployment problem, 
>but there are 
>deployments within dedicated ISP-domains.
>

Thanks for your input. It's a general discussion here.

>  Section 4.2, 1. para.: "[...] one is the ALTO server 
>providing service 
>to the overall network, and the other is where the ALTO server is 
>providing service to the local network." - what do you mean 
>with "overall 
>network" and "local network"?
>

To the internet or to a single domain.

>  Section 4.2.1, 1. para.: Why is the statement in this 
>paragraph specific 
>to local ALTO services?
>

We may need to add another section for inter-domain ALTO service.

>  2. para.: "[...] or through its application tracker." - this 
>conflicts 
>with your statement in para. 1: "In p2p applications without a tracker 
>[...]".
>
There is no conflict because "p2p applications without a tracker" is not the
premise of all the text in section 4.2.1.

>  Section 4.2.2, 2. para.: The concrete example for a 
>discovery mechanism 
>is not very helpful at this point.
>
>  Section 5, 2. para.: The categories of the enumeration seem 
>not correct.
>
>  "Well known port" - that's the general problem to find the service 
>address. It's not specific to ports.
>
>  "IP address change" - you address the problem of caching?
>

Here it means the IP address of an ALTO server may change. It does not mean
you switch from one ALTO server to another.  We have considerations for
caching problem in the document. It is an implementation issue to solve it
(maybe in many ways).

>  "Mobile Scenarios" - this discussion should be moved to section 4. 
>
>  
>  I do not want to comment the different solutions ... But I have one 
>comment regarding the multicast approaches:
>
>  * You discuss that there is no wide multicast support at residential 
>gateways. That's probably not true - otherwise multicast related IPTV 
>services offered by several ISPs would not work. The RGs 
>probably do not 
>support multicast routing, but this is not required. I would 
>suspect that 
>several RGs support some kind of IGMP/MLD proxying (RFC4605).
>
>  * You should add anycast-based service discovery. It does 
>not introduce 
>specific requirements at RGs. It's suitable for ISP-centric discovery.
>

Thanks, we will consider it in the next revision.

>  * Why do you not mention RFC2608?
>
Sorry for missing that.

Thanks,
Haibin

---

From: "Y.J. Gu" <[email-masked]>
Date: Wed, 12 Aug 2009 17:51:45 +0800

I'm very glad that at last someone notice redistribution.

I'm not totally agree with some opinions in the draft.

--  "However, there is no mean for the peers to verify whether the
information provided is actually intended
   for their usage nor if the information is actually accurate at their
current topological position in the Internet "

Surely, it's very important to verify the usage and the origination of the
redistributed information.
I don't think accurate information needs to be redistributed.
Actually, there are kinds of general information that are suitable and
helpful to be redistributed.
E.g. kinds of cost between a particular PID and other PIDs is useful to all
the peers in the particular PID. 
What we should do is to guarantee that general information is redistributed
within the PID area(maybe multicast) or to guarantee that peer only request
its PID general information.

---"First of all does this require public/private key pair, where the public
key is known to each peer and a trusted third party is required.  These
requirements are possible to be fulfilled in certain deployments but are not
in the general Internet deployment case, which in turn limits the
applicability of this protocol.  Second, the receiving peer needs to contact
the ALTO server at least once to obtain the public key part, or it does need
to contact another server that provides the public key pair."

First, Redistribution can be an optional part of the protocol, ALTO server
can decide whether redistribution is adopted according to internet
environment. Second, peer can contact CA, instead of ALTO server, to obtain
a public key. In P2PSIP-reload, each peer owns a certificate and every peer
can contact the CA to authenticate the certificate of other peer. Reload
regards this an acceptable workload to CA. I think the frequence of
obtaining public key from ALTO server is much fewer than the authentication
in Reload. So that may be not a probolem.
Whatever, the real workload depends on how we design the redistribution
mechanism. 

Regards

Yingjie Gu

---

From: "Jan Seedorf" <[email-masked]>
Date: Wed, 12 Aug 2009 17:15:11 +0200

Dear Yingjie,

I think the problem of redistributed ALTO-information is not so easy, some comments below.

> its PID general information.
Agreed, there may be certain use-cases where redistribution may not be problematic. But consider the case where certain information provided by an ALTO-server is _relative_ to that ALTO-server's location in the network. If such information gets redistributed, an ALTO-client not being aware of the original ALTO-server's location may misinterpret this information. In other words, by redistributing guidance information, its original semantic might be disguised. I think this is the problem being addressed in Martin's draft and specifically in the quote above.

> Whatever, the real workload depends on how we design the redistribution
Indeed, a CA-hierarchy is the technical solution. However, practically it is not always the case that two hosts on the Internet share a trusted third party, and certainly there is no overall Internet-wide CA hierarchy trusted by all hosts. In P2PSIP-RELOAD, the assumption is that there is an enrollment server, i.e., a certificate authority which certifies identities in the P2P-network (DHT). In other words, any peer who wants to join the P2PSIP network has to enroll with this identity certification service. I do not think that is a reasonable assumption for ALTO and I think this was the point in the quote above.

 - Jan

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Y.J. Gu
> Sent: Mittwoch, 12. August 2009 11:52
> To: 'alto'
> Subject: [alto] [ALTO] Comments on [draft-stiemerling-alto-info-redist-
> 00]
>

---

From: Richard Alimi <[email-masked]>
Date: Wed, 12 Aug 2009 11:42:30 -0400

Hi Jan,

> Agreed, there may be certain use-cases where redistribution may not be
> problematic. But consider the case where certain information provided by an
> ALTO-server is _relative_ to that ALTO-server's location in the network. If
> such information gets redistributed, an ALTO-client not being aware of the
> original ALTO-server's location may misinterpret this information. In other
> words, by redistributing guidance information, its original semantic might
> be disguised. I think this is the problem being addressed in Martin's draft
> and specifically in the quote above.

The redistributed ALTO information should indicate the ALTO Server from which 
it originated, and the parameters that were supplied to request that 
information.  For example, when looking at a listing of the available ALTO 
information, an peer can look for the ALTO server it would have contacted 
otherwise (perhaps, hostname:port of the ALTO server), and grab the ALTO 
information pertaining to that server.

This "listing of available ALTO information" could be posted on a public 
website (available as direct downloads, torrent files, etc).  Another option 
would be to distribute via a DHT (a la Vuze's Distributed Tracker) where the 
key is hash("alto:<hostname>:<port>:networkmap").  Something similar could be 
used to request the full cost map: 
hash("alto:<hostname>:<port>:costmap:<costtype>")

To redistribute only a portion of the cost map (e.g., a row of the matrix from 
the perspective of a single PID), then the map could be stored at 
hash("alto:<hostname>:<port>:costmap:<costtype>:<pidname>").

-- 
Richard Alimi
Department of Computer Science
Yale University

---

From: "Y.J. Gu" <[email-masked]>
Date: Thu, 13 Aug 2009 11:56:28 +0800

Hi Jan,
See in line pls.

Regards

Yingjie Gu

> From: Jan Seedorf [mailto:[email-masked]] 
> Sent: Wednesday, August 12, 2009 11:15 PM
> To: Y.J. Gu; alto
> Subject: RE: [alto] [ALTO] Comments on 
> [draft-stiemerling-alto-info-redist-00]
> 
> Dear Yingjie,
> 

> Agreed, there may be certain use-cases where redistribution 
> may not be problematic. But consider the case where certain 
> information provided by an ALTO-server is _relative_ to that 
> ALTO-server's location in the network. If such information 
> gets redistributed, an ALTO-client not being aware of the 
> original ALTO-server's location may misinterpret this 
> information. In other words, by redistributing guidance 
> information, its original semantic might be disguised. I 
> think this is the problem being addressed in Martin's draft 

I think "Redistribution" should not be unlimited. 
First of all, not all information is redistributed. 
Second, redistributed information must include accurate ALTO SERVER
INFORMATION, e.g. network position or name, and what kind of information it
is, so that client can judge the usage of the information.
Last but not least, client must cognize his ALTO SERVER INFORMATION and
share a unified information description language among all clients, at least
those in one application swarm.
Richard Alimi gave excellent examples in his email. Of course, there maybe
other methods.
By this mean, client can find suitable redistributed information.

> Indeed, a CA-hierarchy is the technical solution. However, 
> practically it is not always the case that two hosts on the 
> Internet share a trusted third party, and certainly there is 
> no overall Internet-wide CA hierarchy trusted by all hosts. 
> In P2PSIP-RELOAD, the assumption is that there is an 
> enrollment server, i.e., a certificate authority which 
> certifies identities in the P2P-network (DHT). In other 
> words, any peer who wants to join the P2PSIP network has to 
> enroll with this identity certification service. I do not 
> think that is a reasonable assumption for ALTO and I think 
> this was the point in the quote above.
> 
>  - Jan

Instead of an overall trusted third party, a dedicated CA for a particular
network position, neither too small nor too big, will work. Applications can
make their clients cognize the dedicated CA as they notice clients about
dedicated ALTO servers.

---

From: "Jan Seedorf" <[email-masked]>
Date: Fri, 14 Aug 2009 11:27:18 +0200

Hi Richard,

> information.  
Right, this is important to prevent misinterpretation of redistributed ALTO information.

> For example, when looking at a listing of the available
> ALTO

Sorry, I am not completely following you: are you saying that such a "listing of available ALTO information" is redistributed ALTO information posted on a website? So someone could program an ALTO-grab-all-crawl-bot and post all information retrieved on a website, right? Clearly nobody can prevent something like that, that is why it is important that ALTO information is not only authenticated and its integrity protected (i.e., signed), but also that the digital signature contains an expiration time and the complete input variables for the generated ALTO information. Still, what if an ALTO server realizes it was misconfigured or something changes unexpectedly, than the ALTO server has no way of controlling its already redistributed, now "wrong" information. What do you think?

 - Jan

> Sent: Mittwoch, 12. August 2009 17:43
> To: [email-masked]
> Cc: Jan Seedorf
> Subject: Re: [alto] [ALTO] Comments on[draft-stiemerling-alto-info-
> redist-00]
> 
> Hi Jan,
> 
> > > Surely, it's very important to verify the usage and the origination
> of
> > > the
> > > E.g. kinds of cost between a particular PID and other PIDs is
> useful to
> > > all

---

From: "Jan Seedorf" <[email-masked]>
Date: Fri, 14 Aug 2009 11:46:08 +0200

Dear Yingjie,

> I think "Redistribution" should not be unlimited.
How do you want to limit redistribution in practice, i.e., how do you want to enforce such a limitation?

> those in one application swarm.
I agree, but in addition it is also very important that the redistributed ALTO information includes the input parameters which where the basis for generating the ALTO information.

> make their clients cognize the dedicated CA as they notice clients
Yes, that can work, but especially if you consider mobility of clients it will not always work.

Also, currently the WG is discussing ALTO discovery. That means that ALTO clients most probably will not have the location of ALTO servers "hardcoded" in their implementation. However, to boostrap a CA hierarchy of trust, the public key of a Root-CA needs to be available to the client. I do not believe in PKI set-up by users nor certificate management by users (think of certificate error messages in today's web-browsers, which btw have a certificate of a Root-CA hardcoded in their implementation).

All I am saying is that it works fine in theory but is not so easy in practice...

 - Jan

> From: Y.J. Gu [mailto:[email-masked]]
> Sent: Donnerstag, 13. August 2009 05:56
> To: Jan Seedorf; 'alto'
> Subject: RE: [alto] [ALTO] Comments on [draft-stiemerling-alto-info-
> redist-00]
> 
> Hi Jan,
> See in line pls.
> 
> Regards
> 
> Yingjie Gu
> 
> 
>