From nobody Mon Nov 2 14:04:24 2020 Return-Path: X-Original-To: alto@ietfa.amsl.com Delivered-To: alto@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3FAB3A0829 for ; Mon, 2 Nov 2020 14:04:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.397 X-Spam-Level: X-Spam-Status: No, score=-1.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URI_DOTEDU=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IsbC3Eu0MwjA for ; Mon, 2 Nov 2020 14:04:20 -0800 (PST) Received: from mail-lj1-f179.google.com (mail-lj1-f179.google.com [209.85.208.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6824E3A0822 for ; Mon, 2 Nov 2020 14:04:20 -0800 (PST) Received: by mail-lj1-f179.google.com with SMTP id i2so16785060ljg.4 for ; Mon, 02 Nov 2020 14:04:20 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=GH0I+HzZRH/3vEKZlY1glPgtbhVxaNfhvxR6+6Fv6TE=; b=LNDdeeB9pbLXGyp9ofveqFBAwXMR9brd2D8yC9yuLFZB9sRIqNZHTa04wU+CVKS7hB Zn3xYl/Oo4oxONKPQQLcdQkp6b77RvURLIdDtnXaRyaESEquycYIQhw8L80OtRkmzcB4 jiU3osxOI4RRE/pVkD5Gpg2WNzdSMBRAEZKxcHGS70XPEpV1xdt7cbQgIveyUA3FvATL mEELVIIiH+t3qBUSSDREDCCQhR+ZCtcbBQeL4uc94bhbnN/2xA4aipfKi6/e/sXOJBif S1G6f4m4X1ZdpYVGW4OZ1whL2eFracXhH4Z3vfgnl5FRHHPIsd61n49B9w43KEgZ02Vf mJ5w== X-Gm-Message-State: AOAM5337taXCIqbiBPJTgG97yBXHzJbj1NOx2Wtnx067WTt0Eslk87aL 5/3cvEXvKUAwXcvAjxaD97f463Yl0m/MIBUp/9c= X-Google-Smtp-Source: ABdhPJwwW5prEI570t3/15WBPAAWtHLBiVi86SSNCAJsLJ5NxfwSrcSP94L+BGHdZcN6fP9NPoYKOX9cCvpwVLUITh8= X-Received: by 2002:a2e:b5c1:: with SMTP id g1mr6970959ljn.305.1604354658420; Mon, 02 Nov 2020 14:04:18 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: "Y. Richard Yang" Date: Mon, 2 Nov 2020 17:04:06 -0500 Message-ID: To: LUIS MIGUEL CONTRERAS MURILLO Cc: "alto@ietf.org" Content-Type: multipart/alternative; boundary="000000000000824c4405b326ed0d" Archived-At: Subject: Re: [alto] Review of draft-ietf-alto-path-vector-11 X-BeenThere: alto@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Application-Layer Traffic Optimization \(alto\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2020 22:04:23 -0000 --000000000000824c4405b326ed0d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable H Luis, Thanks a lot for the wonderful review! As we upload the revision, here is a summary of the changes that we make. Please see inline to see if you are OK. After you approve, we will finalize all. On Sun, Oct 25, 2020 at 5:01 PM LUIS MIGUEL CONTRERAS MURILLO < luismiguel.contrerasmurillo@telefonica.com> wrote: > Hi all, > > > > I have performed a review of the draft, with comments as follows: > > > > /* Technical comments */ > > .- Section III Terminology =E2=80=93 Path Vector bullet. Please, rephrase= the > description, it is hard to understand, especially the second sentence. No= t > clear. > OLD Path Vector: A Path Vector, or an ANE Path Vector, is a JSON array of ANE Names. It conveys the information that the path between a source and a destination traverses the ANEs in the same order as they appear in the Path Vector. NEW Path Vector: A Path Vector, or an ANE Path Vector, is a JSON array of ANE Names. This extension (i.e., ALTO path vector extension) generalizes BGP path vector, where a standard BGP path vector specifies the sequence of autonomous systems from a source to a destination. In this extension, the path vector specifies the sequence of general ANEs computed according to a user request. .- Section 4.2 =E2=80=93 it refers to recent use cases, but it is not relev= ant how > recent are the use cases (in fact, for this, see my next comment). So I > would suggest to remove any reference to recent either in the title or th= e > text. Simply refer to use cases. > Very good point. We have removed the word "recent" in the title and the text. > .- Section 4.2 =E2=80=93 there is a reference to an expired I-D which las= t from > 2013 (so pretty old). I would suggest to remove such a reference since > somehow the potential use cases it refers should be present here. > Sounds good. Yes. Removed. > .- Section 5.1.3, 2nd paragraph =E2=80=93 =E2=80=9C=E2=80=A6 and the resp= onse must return and > only return the selected properties =E2=80=A6=E2=80=9D =E2=80=93 two comm= ents here: (1) must should > be MUST in this context?; (2) =E2=80=9C=E2=80=A6 and only return =E2=80= =A6=E2=80=9D =E2=80=93 probably redundant, > better either remove or rephrase as =E2=80=9CMUST/must only return=E2=80= =9D. > Good point. OLD "... and the response must return and only return the selected properties for the ANEs in the response." NEW "... and the response MUST include and only include the selected properties specified in the filter. " .- Figure 4 =E2=80=93 the figure shows two response messages, but some ques= tions > arise in this respect: (1) what happens if second response is not > received?; (2) what happens if only the second response is received? Is i= t > silently discarded?; (3) is there some expected timer for accounting > time-out in the responses? It is mentioned in bullet 2 that there could b= e > some processing among messages, so it can be assumed that some maximum > delay could happen between both responses. > Good point. OLD Specifically, the Path Vector extension requires the ALTO client to include the source and destination pairs and the requested ANE properties in a single request, and encapsulates both Path Vectors and properties associated with the ANEs in a single response, as shown in Figure 4. NEW Specifically, the Path Vector extension requires that (1) the ALTO client include the source and destination pairs and the requested ANE properties in a single request; (2) the ALTO server MUST return a single response with the Path Vectors followed by the properties associated with the ANEs in the Path Vectors, as shown in Figure 4. In addition, in 5.3.3, we add the specification on the essential completeness issue: OLD 5.3.3. Order of Part Message NEW 5.3.3. Order and Completeness of Part Message We add a sentence at the end of 5.3.3 The ALTO server MUST always send the complete response including both parts. The client should check the completeness of response and implementing a timeout mechanism to avoid hanging issues. .- Section 6.2.4, last paragraph - Hard to understand, not clear. Please, > rephrase/review. > OLD Specifically, the defining resource of ephemeral ANEs is the Property Map part of the multipart response. The defining resource of persistent ANEs is the Property Map on which standalone queries for properties of persistent ANEs are made. NEW Note that there are two types of ANEs (see Section 5.1.2): ephemeral ANEs and persistent ANEs. For ephemeral ANEs, the defining resource is the Property Map part of the multipart response; the defining resource of persistent ANEs is the Property Map on which standalone queries for properties of persistent ANEs are made. .- Section 6.4.2, Intended semantics text =E2=80=93 it is not clear the ass= ociation > of persistent to ephemeral. Why is this? What is the purpose? > .- Section 6.4.2, last paragraph =E2=80=93 The value of ephemeral is provid= ed, but > what would be the value of persistent one? > It looks that we need a bit more update. We will finalize the update shortly. > .- Section 9.3, 1st and past paragraph =E2=80=93 they seem inconsistent s= ince in > one hand the first claims incompatibility while the second claims > compatibility. Please, review them. > As SSE is finalized now, we will update this part shortly. > .- Section 9.4 =E2=80=93 When used with the calendar extension, should th= e ANE be > always persistent? I mean, same ANE for all the time views, otherwise cou= ld > not properly work. Please, clarify. > It should. We will update. > > > /* Editorial comments */ > > .- Section I Introduction, pag. 5, penultimate paragraph =E2=80=93 =E2=80= =9C=E2=80=A6 Path Vector > response involve two ALTO =E2=80=A6=E2=80=9D -> =E2=80=9C=E2=80=A6 Path V= ector response involves two ALTO > =E2=80=A6=E2=80=9D > Good catch. Fixed. > .- Section I Introduction, pag. 5, last paragraph =E2=80=93 =E2=80=9C=E2= =80=A6 the rest of the > document are organized =E2=80=A6=E2=80=9D -> =E2=80=9C=E2=80=A6 the rest = of the document is organized =E2=80=A6=E2=80=9D > Good catch. Fixed. > .- Section III Terminology stands that the document extends the > terminology used in RFC 7285 and in Unified Properties draft. This implie= s > some precedence in the edition of the documents as RFCs, if they finally > progress to that stage. So I would recommend to add a note for RFC Editor > mention that precedence (note to be remove once the document becomes a RF= C). > Good idea. Unified, which is newer, should have precedence. > .- Section 5.1 =E2=80=93 the text (2nd paragraph) auto-refers to section = 5.1. > Redundant, better to remove. > Fixed. > .- Section 5.2 =E2=80=93 1st paragraph =E2=80=93 correct -> correctly > Fixed. > .- Section 5.3, last sentence before Figure 4 =E2=80=93 =E2=80=9C=E2=80= =A6 the ANEs in a single > response =E2=80=A6=E2=80=9D -> =E2=80=9C=E2=80=A6 the ANEs in an addition= al response =E2=80=A6=E2=80=9D > Fixed. > .- Section 6.6 =E2=80=93 The second paragraph starts with NOTE; probably = better to > rephrase writing it as a normal paragraph. > Chaned to "Note that ..." > .- Section 9.2, last sentence =E2=80=93 =E2=80=9Ccompatible=E2=80=9D -> = =E2=80=9Ccompatibility=E2=80=9D > > > Good catch. Fixed. Thank you so so much!! Richard > Best regards > > > > Luis > > > > __________________________________ > > Luis M. Contreras > > > > Technology and Planning > > Transport, IP and Interconnection Networks > > Telef=C3=B3nica I+D / Global CTIO unit / Telef=C3=B3nica > > > > Distrito Telef=C3=B3nica, Edificio Sur 3, Planta 3 > > 28050 Madrid > > Espa=C3=B1a / Spain > > > > Skype (Lync): +34 91 312 9084 > > Mobile: +34 680 947 650 > > luismiguel.contrerasmurillo@telefonica.com > > > > > > ------------------------------ > > Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, > puede contener informaci=C3=B3n privilegiada o confidencial y es para uso > exclusivo de la persona o entidad de destino. Si no es usted. el > destinatario indicado, queda notificado de que la lectura, utilizaci=C3= =B3n, > divulgaci=C3=B3n y/o copia sin autorizaci=C3=B3n puede estar prohibida en= virtud de > la legislaci=C3=B3n vigente. Si ha recibido este mensaje por error, le ro= gamos > que nos lo comunique inmediatamente por esta misma v=C3=ADa y proceda a s= u > destrucci=C3=B3n. > > The information contained in this transmission is privileged and > confidential information intended only for the use of the individual or > entity named above. If the reader of this message is not the intended > recipient, you are hereby notified that any dissemination, distribution o= r > copying of this communication is strictly prohibited. If you have receive= d > this transmission in error, do not read it. Please immediately reply to t= he > sender that you have received this communication in error and then delete > it. > > Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinat=C3= =A1rio, > pode conter informa=C3=A7=C3=A3o privilegiada ou confidencial e =C3=A9 pa= ra uso exclusivo > da pessoa ou entidade de destino. Se n=C3=A3o =C3=A9 vossa senhoria o des= tinat=C3=A1rio > indicado, fica notificado de que a leitura, utiliza=C3=A7=C3=A3o, divulga= =C3=A7=C3=A3o e/ou > c=C3=B3pia sem autoriza=C3=A7=C3=A3o pode estar proibida em virtude da le= gisla=C3=A7=C3=A3o vigente. > Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique > imediatamente por esta mesma via e proceda a sua destrui=C3=A7=C3=A3o > _______________________________________________ > alto mailing list > alto@ietf.org > https://www.ietf.org/mailman/listinfo/alto > --=20 --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D | Y. Richard Yang | | Professor of Computer Science | | http://www.cs.yale.edu/~yry/ | =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --000000000000824c4405b326ed0d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
H Luis,

Thanks a lot f= or the wonderful review! As we upload the revision, here is a summary of th= e changes that we make. Please see inline to see if you are OK. After you a= pprove, we will finalize all.

On Sun, Oct 25, 2020 at 5:01 PM LUIS MIG= UEL CONTRERAS MURILLO <luismiguel.contrerasmurillo@telefonica.com> wrote:

Hi all,

=C2=A0

I have performed a review of the draft, with comment= s as follows:

=C2=A0

/* Technical comments */

.- Section III Terminology =E2=80=93 Path Vector bul= let. Please, rephrase the description, it is hard to understand, especially= the second sentence. Not clear.


NEW

Path Vector: A Path Vector, or an ANE Path= Vector, is a JSON array
=C2=A0 =C2=A0 =C2=A0 of ANE Names.=C2=A0 This= extension (i.e., ALTO path vector extension) generalizes
=C2=A0 =C2=A0= =C2=A0 BGP path vector, where a standard BGP path vector specifies the seq= uence of
=C2=A0 =C2=A0 =C2=A0 autonomous systems from a source to a des= tination. In this extension, the path
=C2=A0 =C2=A0 =C2=A0 vector speci= fies the sequence of general ANEs computed according to a user=C2=A0
=C2= =A0 =C2=A0 =C2=A0 request.

.- Section 4.2 =E2=80=93 it refers to recent use cas= es, but it is not relevant how recent are the use cases (in fact, for this,= see my next comment). So I would suggest to remove any reference to recent= either in the title or the text. Simply refer to use cases.


Very good po= int. We have removed the word "recent" in the title and the text.=

=C2=A0

=

.- Section 4.2 =E2=80=93 there is a reference to an = expired I-D which last from 2013 (so pretty old). I would suggest to remove= such a reference since somehow the potential use cases it refers should be= present here.


Sounds good.= Yes. Removed.
=C2=A0

<= /p>

.- Section 5.1.3, 2nd paragraph =E2=80=93= =E2=80=9C=E2=80=A6 and the response must return and only return the select= ed properties =E2=80=A6=E2=80=9D =E2=80=93 two comments here: (1) must shou= ld be MUST in this context?; (2) =E2=80=9C=E2=80=A6 and only return =E2=80= =A6=E2=80=9D =E2=80=93 probably redundant, better either remove or rephrase as =E2=80=9CMUST/must only return=E2=80=9D.

<= /div>

Good point.=C2=A0
OLD=C2=A0
=C2=A0 =C2=A0"... and the
=C2=A0 =C2=A0res= ponse must return and only return the selected properties for the
=C2=A0= =C2=A0ANEs in the response."

NEW
=C2=A0 "... and the<= /div>=C2=A0 =C2=A0response MUST include and only include the selected prope= rties specified in the filter. "

=

.- Figure 4 =E2=80=93 the figure shows two response = messages, but some questions arise in this respect: (1) what happens if sec= ond response is not received?; (2) what happens if only the second response= is received? Is it silently discarded?; (3) is there some expected timer for accounting time-out in the responses? It = is mentioned in bullet 2 that there could be some processing among messages= , so it can be assumed that some maximum delay could happen between both re= sponses.


Good point.
<= div>
OLD
=C2=A0 Specifically, the
=C2=A0 =C2=A0Path V= ector extension requires the ALTO client to include the source
=C2=A0 = =C2=A0and destination pairs and the requested ANE properties in a single=C2=A0 =C2=A0request, and encapsulates both Path Vectors and properties as= sociated
=C2=A0 =C2=A0with the ANEs in a single response, as shown = in Figure 4.

NEW

=C2=A0 S= pecifically, the
=C2=A0 =C2=A0Path Vector extension requires that (1) = the ALTO client include the source
=C2=A0 =C2=A0and destination pairs an= d the requested ANE properties in a single
=C2=A0 =C2=A0request; (2) the= ALTO server MUST return a single response with the Path Vectors followed b= y the
=C2=A0 =C2=A0properties associated with the ANEs in the Path Vect= ors, as shown in Figure 4.=C2=A0

In addition, in 5.3.3, we add the specificat= ion on the essential completeness issue:=C2=A0

OLD
5.3.3. Order of Part Messag= e=C2=A0

NEW
5.3.3. Order and Completeness of Part Message=C2=A0

We add a sentenc= e at the end of 5.3.3

=C2=A0 =C2=A0The ALTO server MUST always send = the complete response including both parts. The client should check the com= pleteness of response and implementing a timeout mechanism to avoid hanging= issues.


.- Section 6.2.4, last paragraph - Hard to understan= d, not clear. Please, rephrase/review.

OLD
=C2=A0 =C2=A0Specifically, the defining resource of ephe= meral ANEs is the Property
=C2=A0 =C2=A0Map part of the multipart resp= onse.=C2=A0 The defining resource of
=C2=A0 =C2=A0persistent ANEs is the= Property Map on which standalone queries for
=C2=A0 =C2=A0properties of= persistent ANEs are made.

NEW
=C2=A0 =C2= =A0Note that there are two types of ANEs (see Section 5.1.2):=C2=A0ephemera= l ANEs and
=C2=A0 =C2=A0persistent ANEs. For ephemeral ANEs, the defini= ng resource is the Property
=C2=A0 =C2=A0Map part of the multipart res= ponse; the defining resource of
=C2=A0 =C2=A0persistent ANEs is the Prop= erty Map on which standalone queries for
=C2=A0 =C2=A0properties of pers= istent ANEs are made.

.- Section 6.4.2, Intended semantics text =E2=80=93 = it is not clear the association of persistent to ephemeral. Why is this? Wh= at is the purpose?=C2=A0

.- Section 6.4.2, last paragraph =E2=80=93 The value= of ephemeral is provided, but what would be the value of persistent one?


It looks that we need a bit = more update. We will finalize the update shortly.
=C2=A0

.- Section 9.3, 1st and past paragraph = =E2=80=93 they seem inconsistent since in one hand the first claims incompa= tibility while the second claims compatibility. Please, review them.


As SSE is finalized now, we will = update this part shortly.
=C2=A0

<= /u>

.- Section 9.4 =E2=80=93 When used with the calendar= extension, should the ANE be always persistent? I mean, same ANE for all t= he time views, otherwise could not properly work. Please, clarify.


It should. We will update.
=C2=A0

=C2=A0

/* Editorial comments */

.- Section I Introduction, pag. 5, penultimate parag= raph =E2=80=93 =E2=80=9C=E2=80=A6 Path Vector response involve two ALTO =E2= =80=A6=E2=80=9D -> =E2=80=9C=E2=80=A6 Path Vector response involves two ALTO =E2=80=A6= =E2=80=9D


Good catch. Fixed= .
=C2=A0
<= div lang=3D"EN-US">

.- Section I Introduction, pag. 5, last paragraph = =E2=80=93 =E2=80=9C=E2=80=A6 the rest of the document are organized =E2=80= =A6=E2=80=9D -> =E2=80=9C=E2=80=A6 the rest of the document is organized= =E2=80=A6=E2=80=9D


Good ca= tch. Fixed.
=C2=A0

.- Section III Terminology stands that the document = extends the terminology used in RFC 7285 and in Unified Properties draft. T= his implies some precedence in the edition of the documents as RFCs, if the= y finally progress to that stage. So I would recommend to add a note for RFC Editor mention that precedence = (note to be remove once the document becomes a RFC).


Good idea. Unified, which is newer, should have p= recedence.=C2=A0
=C2=A0

.- Section 5.1 =E2=80=93 the text (2nd pa= ragraph) auto-refers to section 5.1. Redundant, better to remove.

=

Fixed.
=C2=A0

.- Section 5.2 =E2=80=93 1st paragraph = =E2=80=93 correct -> correctly


Fixed.
=C2=A0

.- Section 5.3, last sentence before Figure 4 =E2=80= =93 =E2=80=9C=E2=80=A6 the ANEs in a single response =E2=80=A6=E2=80=9D -&g= t; =E2=80=9C=E2=80=A6 the ANEs in an additional response =E2=80=A6=E2=80=9D=


Fixed.
=C2=A0

.- Section 6.6 =E2=80=93 The second paragraph starts= with NOTE; probably better to rephrase writing it as a normal paragraph.


Chaned=C2=A0to "Note th= at ..."
=C2=A0

.- Section 9.2, last sentence =E2=80=93 =E2=80=9Ccom= patible=E2=80=9D -> =E2=80=9Ccompatibility=E2=80=9D

=C2=A0


<= /div>
Good catch. Fixed.

Thank you so so much!= !

Richard
=C2=A0


Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, pu= ede contener informaci=C3=B3n privilegiada o confidencial y es para uso exc= lusivo de la persona o entidad de destino. Si no es usted. el destinatario = indicado, queda notificado de que la lectura, utilizaci=C3=B3n, divulgaci=C3=B3n y/o copia sin autorizaci=C3=B3= n puede estar prohibida en virtud de la legislaci=C3=B3n vigente. Si ha rec= ibido este mensaje por error, le rogamos que nos lo comunique inmediatament= e por esta misma v=C3=ADa y proceda a su destrucci=C3=B3n.

The information contained in this transmission is privileged and confidenti= al information intended only for the use of the individual or entity named = above. If the reader of this message is not the intended recipient, you are= hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If y= ou have received this transmission in error, do not read it. Please immedia= tely reply to the sender that you have received this communication in error= and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinat=C3=A1= rio, pode conter informa=C3=A7=C3=A3o privilegiada ou confidencial e =C3=A9= para uso exclusivo da pessoa ou entidade de destino. Se n=C3=A3o =C3=A9 vo= ssa senhoria o destinat=C3=A1rio indicado, fica notificado de que a leitura, utiliza=C3=A7=C3=A3o, divulga=C3=A7=C3=A3o e/ou c=C3=B3pia sem au= toriza=C3=A7=C3=A3o pode estar proibida em virtude da legisla=C3=A7=C3=A3o = vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique= imediatamente por esta mesma via e proceda a sua destrui=C3=A7=C3=A3o
_______________________________________________
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto


--
--=C2=A0
=C2=A0=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D
|= Y. Richard Yang <y= ry@cs.yale.edu> =C2=A0 |
| Professor of Computer Science =C2=A0 =C2=A0 =C2=A0 |
| http://www.cs.yale.edu/~yry/ =C2=A0 = =C2=A0 =C2=A0 =C2=A0|