[alto] Past ALTO Interop events

[Vijay Gurbani]

All: Richard recently asked about past ALTO interops; I dug some
information out that I thought may be of interest to some of you, if for
nothing else than to walk down memory lanes.

1. We have had 3 ALTO interop events:
 (a) Interop I was held in 2011, IETF 81 in Quebec City; info in chair
slides at https://www.ietf.org/proceedings/81/slides/alto-0.pdf
 (b) Interop II was held in 2013, IETF 85 in Atlanta; info in chair
slides at https://www.ietf.org/proceedings/85/slides/slides-85-alto-0.pdf
 (c) Interop III was held in in 105, IETF 93 in Prague; info in chair
slides at https://www.ietf.org/proceedings/93/slides/slides-93-alto-11.pdf.


2. Related I-Ds:
(a) 2013 interop:
https://www.ietf.org/archive/id/draft-gurbani-alto-interop-cases-02.txt
(b) 2015 interop:
https://www.ietf.org/archive/id/draft-roome-alto-interop-ietf93-01.txt

Enjoy reliving the moments :-)

- vijay
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

[alto] Jabber scribes and note takers

[Vijay Gurbani]

All: At IETF 111, we only have 1 hour.

To use the hour most effectively, it will be great if we can get the Jabber
scribe and note takers squared away.  For those of you wishing to volunteer
for the roles (1 Jabber scribe, 2 note takers), please send email to the
ALTO chairs.  We will be eternally grateful.

See you on Thu.

- vijay
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

[alto] All WG items now submitted for publication to IESG

[Vijay Gurbani]

All: Just a quick note --- all the remaining four items are now out of the
WG and into the hands of our AD and IESG.

On behalf of Jan and Bill, thank you all for getting this work done.

Thanks,

- vijay
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

[alto] Publication has been requested for draft-ietf-alto-cdni-request-routing-alto-16

[Vijay Gurbani via Datatracker]

Vijay Gurbani has requested publication of 
draft-ietf-alto-cdni-request-routing-alto-16 as Proposed Standard on behalf of 
the ALTO working group.

Please verify the document's state at 
https://datatracker.ietf.org/doc/draft-ietf-alto-cdni-request-routing-alto/


___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

[alto] Publication has been requested for draft-ietf-alto-path-vector-14

[Vijay Gurbani via Datatracker]

Vijay Gurbani has requested publication of draft-ietf-alto-path-vector-14 as 
Proposed Standard on behalf of the ALTO working group.

Please verify the document's state at 
https://datatracker.ietf.org/doc/draft-ietf-alto-path-vector/


___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

[alto] Moving path-vector-14 ahead

[Vijay Gurbani]

Dear Authors: I am moving path-vector ahead based on the revised version
(-14) that addresses my comments from the chair reviews [1,2].

Thank you for your time and attention to the draft.

With respect to my comment in S6.4 in my chair review [1]:
> - S6.4: Why have a mini Security Considerations paragraphs in the
subsections
> of S6.4, [...]

You replied:
> [PV] The reason of having mini security consideration paragraphs in
Section
> 6.4 is because the document defines two properties in Section 6.4 and the
> Unified Property document asks for security consideration when defining
> a new property. However, for cost type definition, such a paragraph is
> not formally required so we do not include one.

That is okay, I guess.  Although I think that you could define a subsection
in the normal Security Considerations section and have a forward reference
from S6.4 to that subsection.  You do not need to do this for the draft
to proceed right now, but do be prepared to justify your decision
when the IESG reviews the draft if they bring up this point.

[1] https://mailarchive.ietf.org/arch/msg/alto/0V-LL8dk5LRvO2zQ0F6hUYwYi-g/
[2] https://mailarchive.ietf.org/arch/msg/alto/6oYr0rjU9ZB_gG9muNLGrJknvPM/

- vijay
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

[alto] Publication has been requested for draft-ietf-alto-unified-props-new-17

[Vijay Gurbani via Datatracker]

Vijay Gurbani has requested publication of draft-ietf-alto-unified-props-new-17 
as Proposed Standard on behalf of the ALTO working group.

Please verify the document's state at 
https://datatracker.ietf.org/doc/draft-ietf-alto-unified-props-new/


___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

[alto] Moving unified-props version 17 ahead

[Vijay Gurbani]

Authors: I have reviewed version -17 against my chair reviews of the draft.

I will be submitting version -17 to IESG shortly.  In the meantime, here
are residual comments from version -17 and discussion from the chair review
that you can incorporate during AUTH48.

- S3.2.1: s/registered at the IANA,/registered with IANA,/

- Discussion around Section 4.7.1, the resolution was:
  > [ [SR] ] (Sabine) *
  > Actually we removed 4.7.1 and the text of 4.7 (not the title yet).
  > Most of the text of 4.7 was moved to 4.6.1 last paragraph, as 4.7
  > "looked" too small.  However, even if the text of 4.7 is short, it
  > is important, as it introduces fields that must be specified at
  > the IANA, as specified in section 12.3.  So we may just put the text
  > back in 4.7, if you think it is better.

  I think current S4.7 is fine, the length of a section should not
  dictate whether or not a content is in a section, the content should.

- Discussion around Section 4.3.3, the resolution was:
  > [ [SR] ] (sabine)  *
  > the text has been updated and uses  "subsets" (upper level) and
  > "superset" (lower level). [...] Therefore, we would rather use:
  > supersets (upper levels), subsets (lower levels) [...]

  That is fine as long as you define your intention before hand,
  which you are doing now.

- S5.1.1: s/with the IANA/with IANA/

- S11: s/at the IANA/from IANA/

Thank you all for your hard work.

- vijay
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] I-D Action: draft-ietf-alto-unified-props-new-17.txt

[Vijay Gurbani]

Dear Sabine: Excellent. I will start to wrap up the post-chair review
process next week on this and path-vector so they can be sent to IESG.

Have a nice weekend.

On Fri, Apr 16, 2021, 2:05 PM Randriamasy, Sabine (Nokia - FR/Paris-Saclay)
 wrote:

> Dear Vijay,
>
> A new version 17 of the "ALTO Extension: Entity Property Maps" has been
> uploaded and hopefully addresses the pending review comments.
> It can be found at the link below, by clicking on the number "16" on the
> ALTO status pages.
> https://tools.ietf.org/html/draft-ietf-alto-unified-props-new-17
> Below is a digest of the updates and we look forward to having your
> feedback.
> A detailed "diff" can be sent if you wish.
>
> Best regards,
> Sabine & co-authors
> =
> updates in draft-ietf-alto-unified-props-new-17
> =
> Previous V16 was submitted to address Vijay's review of v15
> This V17 addresses remaining issues on V15 review
>
> Main update is the addition of a substantial Section 11. Security
> Considerations.
> The other updates are as follows:
>
> - Defined terminology nomenclature used in 4.4.  Entity Hierarchy and
> Property Inheritance
> --- related (small) edits in subsections
>
> - In Section 4.7 Defining Information Resource for Resource-Specific
> Property Values
> text was clarified and moved back from 4.6.1 to 4.7. Section 4.7.1 (of
> V15) with examples was merged with 4.7
>
> - Clarified text on defining information resources in sections 4.6 and
> 4.7, as review reflects it was unclear
> --- added example in 4.6.2 of entity domain types that do  not have a
> defining resource
> --- Clarified text in related IANA sections 12.2.2 and 12.3
>
> - Added normative "MUST" wherever needed
> --- section 4.3.  Resource-Specific Entity Property Value
> --- 4.6.1.  Defining Information Resource and its Media Type
> --- sections 12.2.2 and 12.3 on item "Media type of defining information
> resource"
> - Replaced lower case "must" with other words where convenient
>
> - Rewording
> ---  Clarified sentence distinguishes domain name and domain type in 3.2.1
> --- Added introduction sentence in Section 4 Advanced Features...
> - Typos and nits in sections  5.1.2, 8.6
>
> - Added normative and informative references
>
> >-Original Message-
> >From: alto  On Behalf Of internet-dra...@ietf.org
> >Sent: Friday, April 16, 2021 8:54 PM
> >To: i-d-annou...@ietf.org
> >Cc: alto@ietf.org
> >Subject: [alto] I-D Action: draft-ietf-alto-unified-props-new-17.txt
> >
> >
> >A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> >This draft is a work item of the Application-Layer Traffic Optimization
> WG of
> >the IETF.
> >
> >Title   : ALTO Extension: Entity Property Maps
> >Authors : Wendy Roome
> >  Sabine Randriamasy
> >  Y. Richard Yang
> >  Jingxuan Jensen Zhang
> >  Kai Gao
> >   Filename: draft-ietf-alto-unified-props-new-17.txt
> >   Pages   : 59
> >   Date: 2021-04-16
> >
> >Abstract:
> >   This document extends the base Application-Layer Traffic Optimization
> >   (ALTO) Protocol by generalizing the concept of "endpoint properties"
> >   as applied to endpoints as defined by IP addresses to endpoints
> >   defined by a wider set of objects.  Further, these properties are
> >   presented as maps, similar to the network and cost maps in the base
> >   ALTO protocol.  The protocol is extended in two major directions.
> >   First, from endpoints restricted to IP addresses to entities covering
> >   a wider and extensible set of objects; second, from properties on
> >   specific endpoints to entire entity property maps.  These extensions
> >   introduce additional features allowing entities and property values
> >   to be specific to a given information resource.  This is made
> >   possible by a generic and flexible design of entity and property
> >   types.
> >
> >
> >The IETF datatracker status page for this draft is:
> >https://datatracker.ietf.org/doc/draft-ietf-alto-unified-props-new/
> >
> >There are also htmlized versions available at:
> >https://tools.ietf.org/html/draft-ietf-alto-unified-props-new-17
> >
> https://datatracker.ietf.org/doc/html/draft-ietf-alto-unified-props-new-17
> >
> >A diff from the previous version is available at:
> >https://www.ietf.org/rfcdiff?url2=draft-ietf-alto-unified-props-new-17
> >
> >
> >Please note that it may take a couple of minutes from the time of
> submission
> >until the htmlized version and diff are available at tools.ietf.org.
> >
> >Internet-Drafts are also available by anonymous FTP at:
> >ftp://ftp.ietf.org/internet-drafts/
> >
> >
> >___
> >alto mailing list
> >alto@ietf.org
> >https://www.ietf.org/mailman/listinfo/alto
>
___
alto mailing list
alto@ietf.org

[alto] Shepherd write up for cdni-request-routing-alto

[Vijay Gurbani]

All: The shepherd writeup for CDNI is below.  Jan and I will be moving the
CNDI draft, path-vector, and unified-props as a cluster.  Please let me
know if you have any questions on the shepherd writeup.  Thanks.

1. Summary

Vijay K. Gurbani is the document shepherd for
draft-ietf-alto-cdni-request-routing-alto. Martin Duke is the responsible
Area Director.

RFC 8008 defines the semantics for the CDNI Footprint & Capabilities
Advertisement Interface (FCI). This document specifies a concrete protocol
for the CDNI FCI using the ALTO protocol. A new ALTO service called the
"CDNI Advertisement Service" which conveys JSON objects of media type
"application/alto-cdni+json" is defined. This service can convey CDNI FCI
Base Advertisement Objects as defined in RFC8008 to ALTO clients via the
ALTO protocol.

This document is targeted as a Standards Track document (Proposed
Standard). This designation is appropriate as the document contains
normative behaviour and message formats that should be adhered to by the
communicating entities in order to realize the extension.

2. Review and Consensus
The “ALTO Service for CDNI FCI” had been added as a new ALTO WG milestone
in 2017, following an agreement between the CDNI WG and the ALTO WG to
finalise the ALTO service for conveying (i.e. transporting) CDNI FCI
objects in the ALTO WG. draft-ietf-alto-cdni-request-routing-alto has a
long history and had been iterated and presented multiple times in the CDNI
WG prior to 2017 (see draft-seedorf-cdni-request-routing-alto).

The document is well-known in the ALTO working group and has been presented
many times. The approach is agreed upon and no objections have been raised
during the WGLC on draft-ietf-alto-cdni-request-routing-alto-09 in February
2020. All comments from the individual reviews during the WGLC have since
been addressed and the document has been polished further multiple times
since the WGLC (now in draft-ietf-alto-cdni-request-routing-alto-13).

In summary, there is clear consensus for
draft-ietf-alto-cdni-request-routing-alto in the ALTO WG, and it provides a
very useful extension needed also by the CDNI WG to convey CDNI FCI objects
defined in RFC8008. A WGLC has successfully been passed, and extensive
reviews were provided by various members of the WG and have all been
addressed.

3. Intellectual Property
The shepherd confirms that each author has stated to him that to the best
of his/her (i.e. the author’s) knowledge, all IPR related to this document
has been disclosed.

4. Other Points
Note any downward references (see RFC 3967) and whether they appear in the
DOWNREF Registry (
http://trac.tools.ietf.org/group/iesg/trac/wiki/DownrefRegistry), as these
need to be announced during Last Call.

All normative references are ok (with respect to RFC 3967) as they are all
towards documents with standards-level “Proposed Standards”, “Internet
Standard”, or “BCP”.
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

[alto] Status of chartered WG items

[Vijay Gurbani]

All: Since we have only one hour on Fri for our meeting, I am summarizing
the status of the existing chartered items on the list.  Hopefully, we can
spend no more than 2s on the corresponding chair slides in the meeting
tomorrow.

draft-ietf-alto-unified-props-new and draft-ietf-alto-path-vector have been
reviewed by me (as chair and shepherd).  The shepherd writeup has been
shared on the mailing list for each of these.  The token is with me as the
shepherd to make sure all comments are attended to in the revisions and
then move them to IESG.  I should do this after the current IETF.

draft-ietf-alto-performance-metrics is being shephereded by Jan. IPR check
has been done and I believe that Jan needs to complete the shepherd writeup
and draft review.  Version -15 was released on 2021-02-04 and addresses
comments and issues from WGLC.

draft-ietf-alto-cdni-request-routing-alto is ready to go and I will be
posting the shepherd writeup on the list next week.  The draft is ready and
mature and has been socialized broadly.

unified-props, path-vector, and cdni-request-routing will be moved ahead as
a cluster since the latter two have a dependency on unified-props.

To save time during tomorrow's meeting, please post to the list if you have
any questions.

Thanks,

- vijay
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

[alto] Jabber monitor and note takers needed

[Vijay Gurbani]

All: ALTO WG meeting is on Fri.

Please send an email to the chairs if you would like to volunteer for
taking notes and monitoring Jabber.

Thanks,

- vijay
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] New Version Notification for draft-ietf-alto-path-vector-14.txt

[Vijay Gurbani]

Dear Kai: Thank you.  I will look at the changes and move the draft ahead.
I will try to do so next week, but may spill over into the week after.
Thanks.


On Mon, Feb 22, 2021 at 9:20 PM  wrote:

> Dear all,
>
> This is the latest revision of the path vector document. In this revision,
> we have addressed all the comments in the chair review [1-4] and fixed most
> of the issues raised by IDNits [5] (note that the TBD issue is fixed as
> mentioned in [4]).
>
> There are a few warnings reported by IDNits on the use of example IPv4
> addresses, which will be fixed once the submission tool is made available
> again.
>
> Best,
> Kai
>
> [1]
> https://mailarchive.ietf.org/arch/msg/alto/0V-LL8dk5LRvO2zQ0F6hUYwYi-g/
> (responses to chair review 1/2)
> [2]
> https://mailarchive.ietf.org/arch/msg/alto/23HfNwNPoYwZqKfwWw6UaAqOLVI/
> (follow-up on chair review 1/2)
> [3]
> https://mailarchive.ietf.org/arch/msg/alto/Chw-HZl9nt4tsMTyYvFJ_IcQtX8/
> (responses to chair review 2/2)
> [4]
> https://mailarchive.ietf.org/arch/msg/alto/8jhyV8Hvm-kyYJTLZ5Y3UA8-OaU/
> (follow-up on chair review 2/2)
> [5]
> https://mailarchive.ietf.org/arch/msg/alto/bUb0sLGjwlXfxiGSc1g_3En9QVA/
>
>  -Original Messages-
>  From: internet-dra...@ietf.org
>  Sent Time: 2021-02-23 07:57:59 (Tuesday)
>  To: "J. Zhang" , "Y. Yang" <
> y...@cs.yale.edu>, "Jingxuan Jensen Zhang" ,
> "Kai Gao" , "Sabine Randriamasy" <
> sabine.randriam...@nokia-bell-labs.com>, "Yang Richard Yang" <
> y...@cs.yale.edu>, "Young Lee" 
>  Cc:
>  Subject: New Version Notification for
> draft-ietf-alto-path-vector-14.txt
> 
> 
>  A new version of I-D, draft-ietf-alto-path-vector-14.txt
>  has been successfully submitted by Kai Gao and posted to the
>  IETF repository.
> 
>  Name:  draft-ietf-alto-path-vector
>  Revision:  14
>  Title: ALTO Extension: Path Vector
>  Document date: 2021-02-22
>  Group: alto
>  Pages: 51
>  URL:
> https://www.ietf.org/archive/id/draft-ietf-alto-path-vector-14.txt
>  Status:
> https://datatracker.ietf.org/doc/draft-ietf-alto-path-vector/
>  ;
> Html:
> https://www.ietf.org/archive/id/draft-ietf-alto-path-vector-14.html
>  Htmlized:
> https://tools.ietf.org/html/draft-ietf-alto-path-vector-14
>  ;
> Diff:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-alto-path-vector-14
>  ;
>
>  Abstract:
> This document is an extension to the base Application-Layer Traffic
> Optimization (ALTO) protocol.  It extends the ALTO Cost Map service
> and ALTO Property Map service so that the application can decide
> which endpoint(s) to connect based on not only numerical/ordinal
> cost
> values but also details of the paths.  This is useful for
> applications whose performance is impacted by specified components
> of
> a network on the end-to-end paths, e.g., they may infer that
> several
> paths share common links and prevent traffic bottlenecks by
> avoiding
> such paths.  This extension introduces a new abstraction called
> Abstract Network Element (ANE) to represent these components and
> encodes a network path as a vector of ANEs.  Thus, it provides a
> more
> complete but still abstract graph representation of the underlying
> network(s) for informed traffic optimization among endpoints.
> 
> 
>
> 
> 
>  Please note that it may take a couple of minutes from the time of
> submission
>  until the htmlized version and diff are available at tools.ietf.org.
> 
>  The IETF Secretariat
> 
>  sabine.randriam...@nokia-bell-labs.com> jingxuan.n.zh...@gmail.com>
> ___
> alto mailing list
> alto@ietf.org
> https://www.ietf.org/mailman/listinfo/alto
>
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] I-D Action: draft-ietf-alto-unified-props-new-16.txt

[Vijay Gurbani]

Dear Sabine: Thank you.  I will look over the changes and move the draft
ahead.
I plan to do so next week.
- vijay

On Mon, Feb 22, 2021 at 6:49 PM Randriamasy, Sabine (Nokia -
FR/Paris-Saclay)  wrote:

> Dear all,
>
> This version 16 addresses most of Vijay's review comments part 1 and 2.
> We will come back in a few days with details on how the comments have been
> addressed.
> Thanks,
> Sabine
>
> >-Original Message-
> >From: alto  On Behalf Of internet-dra...@ietf.org
> >Sent: Tuesday, February 23, 2021 1:01 AM
> >To: i-d-annou...@ietf.org
> >Cc: alto@ietf.org
> >Subject: [alto] I-D Action: draft-ietf-alto-unified-props-new-16.txt
> >
> >
> >A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> >This draft is a work item of the Application-Layer Traffic Optimization
> WG of the
> >IETF.
> >
> >Title   : ALTO extension: Entity Property Maps
> >Authors : Wendy Roome
> >  Sabine Randriamasy
> >  Y. Richard Yang
> >  Jingxuan Jensen Zhang
> >  Kai Gao
> >   Filename: draft-ietf-alto-unified-props-new-16.txt
> >   Pages   : 57
> >   Date: 2021-02-22
> >
> >Abstract:
> >   This document extends the base Application-Layer Traffic Optimization
> >   (ALTO) Protocol by generalizing the concept of "endpoint properties"
> >   as applied to endpoints as defined by IP addresses to endpoints
> >   defined by a wider set of objects.  Further, these properties are
> >   presented as maps, similar to the network and cost maps in the base
> >   ALTO protocol.  The protocol is extended in two major directions.
> >   First, from endpoints restricted to IP addresses to entities covering
> >   a wider and extensible set of objects; second, from properties on
> >   specific endpoints to entire entity property maps.  These extensions
> >   introduce additional features allowing entities and property values
> >   to be specific to a given information resource.  This is made
> >   possible by a generic and flexible design of entity and property
> >   types.
> >
> >
> >The IETF datatracker status page for this draft is:
> >https://datatracker.ietf.org/doc/draft-ietf-alto-unified-props-new/
> >
> >There are also htmlized versions available at:
> >https://tools.ietf.org/html/draft-ietf-alto-unified-props-new-16
> >
> https://datatracker.ietf.org/doc/html/draft-ietf-alto-unified-props-new-16
> >
> >A diff from the previous version is available at:
> >https://www.ietf.org/rfcdiff?url2=draft-ietf-alto-unified-props-new-16
> >
> >
> >Please note that it may take a couple of minutes from the time of
> submission
> >until the htmlized version and diff are available at tools.ietf.org.
> >
> >Internet-Drafts are also available by anonymous FTP at:
> >ftp://ftp.ietf.org/internet-drafts/
> >
> >
> >___
> >alto mailing list
> >alto@ietf.org
> >https://www.ietf.org/mailman/listinfo/alto
>
> ___
> alto mailing list
> alto@ietf.org
> https://www.ietf.org/mailman/listinfo/alto
>
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

[alto] Chair review of path-vector-13 (Part 2 of 2)

[Vijay Gurbani]

Dear Authors: This part concludes my chair review of path-vector, an
important ALTO extension.  Thank you for your work on this document.  I
hope the comments in this part and the first part help position the
document better.

Chair review from Section 7 to the end of the document.
Part 2 of 2.

Global comment: Please turn all "Content-Length: [TBD]" into
"Content-Length: XXX", where "XXX" is the computed content length.

Major:

- S7.1.3: When you first get into JSON object declarations, you should
point the reader to S8.2 of RFC7285, where the semantics related to the
syntax used to declare ALTO JSON objects is defined.  This will help new
implementers who
pick up this manuscript and need to understand where the declaration
syntax, and previously declared JSON ALTO objects, like ReqFilteredCostMap,
reside.

- S8.3: I think the ALTO response deserves a longer explanation here.  Let
me see if I understand correctly: the cost map returns two properties: NET1
and AGGR.  On NET1, the max reservable bandwidth is 50 Gb (or GB?), i.e.,
inside the NET1 abstraction of Figure 5, the max reservable bandwidth is
much higher than the link bandwidth.  For the AGGR (BTW, what does AGGR
stand for?  Minimum aggregate bandwidth?), the max reservable bandwidth is
10 Gbps, which is the bandwidth of L1.  Yes?  Please expand the explanation
in the document to be as explicit as you can.

Further, my suggestion would be to show the NET1 and AGGR from source
2.3.4.5 to destination 4.5.6.1, because that will necessarily include
traversing two links, L1 and L2.  What would be the AGGR there?

- S9.2: I am not sure what the prescription here is.  Whatever it is, it
needs to be (a) explicit, and (b) stronger.  Current text says that this
document does not "specify" the use of path vector cost type with RFC
8189.  Why does it not specify this?  Is it because such integration is not
possible?  In which case, the document should say so.  Or is it because the
authors have not studied whether such integration makes sense and can be
supported in a backward compatible manner?  If so, well, say so.  Or is it
because such integration is not possible at all?  If so, say so.  This is a
protocol document, we need to be as unambiguous as possible.  (S9.3 is a
good example of drawing a line in the sand.)

- S10.2: Not sure why the MAY is normative here.  This paragraph should be
re-written in its entirety; it reads more like a draft set of notes than
something well thought out.

- S11, last paragraph: I am not sure what "intolerable increment of the
server-side storage" means here.  Isn't the issue more along the lines of
spending CPU cycles doing path computation rather than storage
requirements? Conflating "storage" here does not seem to be warranted, but
perhaps I am mistaken.  Please advise.

Further, the text says, "To avoid this risk, authenticity and authorization
of this ALTO service may need to be better protected." ==> I am unsure how
this helps.  The ALTO server has no means to authenticate the client, nor
does it have any means to know whether the client is authorized to send it
a request.  Consequently, the best it can do to protect itself is to
monitor client behaviour and stop accepting requests if the client
misbehaves (sends same requests frequently, sends requests with small
deltas frequently, or it can ask the client to solve some puzzle before
submitting a request, etc.).  But generally, this class of resource
exhaustion attacks are hard to defend against, and I am not sure that we
will come up with something that is definitely prescriptive here.  But we
should structure the discussion such that it appears that we have thought
of the issues here.

Minor:

- S7.1.6, bullet item "The Unified Property Map part MUST also include
"Resource-Id" and "Content-Type" in its header." ==> Doesn't the
unified-props I-D already mandate this?  If so, why repeat it here?

- S9: I would suggest changing the title to "Compatibility with other ALTO
extensions"

- S10.1, paragraph 3: I would suggest the following re-write for this
paragraph:

"In practice, developing a bespoke language for general-purpose boolean
tests can be a complex undertaking, and it is conceivable that there are
some existing implementations already (the authors have not done an
exhaustive search to determine whether there are such implementations).
One avenue to develop such a language may be to explore extending current
query languages like XQuery or JSONiq and integrating these with ALTO."

(Please provide references for XQuery and JSONiq.)

Nits:

- S8.1: s/The example ALTO server provides/Assume that an ALTO server
provides/

- S9.1: s/conducting any incompatibility./incurring any incompatibility
problems./

- S11: s/requires additional considerations/requires additional scrutiny/

-S11: s/authenticity and authorization/authentication and authorization/

Thank you!
___
alto mailing list
alto@ietf.org

[alto] Chair review of path-vector-13 (Part 1 of 2)

[Vijay Gurbani]

Chair review from beginning of document to the end of S6.6.
Part 1 of 2.

Major:
- S4.1, below Figure 2:  Note that we do not have "availbw" defined in ALTO
as a current cost metric, so it is not a good idea to use it here without
qualifying it further.  If used as is, it creates confusion.  My advice
would be to either qualify the use of "availbw" as a hypothetical cost
metric, or choose an actual cost metric from the performance-metric draft
and restate the example.

- S4.1, "Case 1": I don't see how the "application will obtain 150 Mbps at
most."  Consider that the bottleneck bandwidth is 100 Mbps, as that is the
bandwidth of the most constrained link.  Once traffic leaves sw5, it can
get no more than 100 Mbps on the remaining links.  So, I don't understand
how the "application will obtain 150 Mbps at most."?  Perhaps I am missing
something?

- S4.2.3: This paragraph, especially the second sentence onwards needs to
be re-written to better flesh out the need.  Currently it says, "While both
approaches...", however, it is not clear that there are two approaches
being delineated from each other here.  It needs more edits so it reads
better. (Some nits in this paragraph appear in the Nits section trying to
tease out the language.)

- S5.1.3: When Section 5 begins, it says that "This section gives a
non-normative overview of the Path Vector extension."  However, in S5.1.3,
there is a normative "MUST".  (Same problem in S5.3, there are many "MUST"s
there, and in Section 5.3.3 there are "RECOMMENDED" and "SHOULD NOT".)

Generally, I am a bit hesitant that certain subsections of Section 5 ---
Section 5.3.2 in particular --- appear to contain normative behaviour, and
this should be specified in a normative section, or do NOT start Section 5
by saying that this section gives a non-normative overview, and make this a
normative section. I understand this is a major comment, so please think
how you want to handle this carefully.

- S5.3.2: Not sure I follow the logic in the first paragraph.  As Fig. 4
showed, there is one PV request, and if ALTO SSE extension is being used,
presumably, it will contain the "client-id".  If the response contains a
Path Vector resource, shouldn't that "client-id" simply apply to it?  I am
sure I am missing something here as you have thought about this more than
me; perhaps you could add a simple example to make the problem more
explicit.

- S6.4: Why have a mini Security Considerations paragraphs in the
subsections of S6.4, but not in the subsections of S6.3 and S6.5?  I am not
saying that you remove the mini Security Considerations paragraphs, but if
there are security considerations worth pointing out in S6.4, I suspect
that there are security considerations worth pointing out in S6.3 and S6.5?
 (One such security consideration is listed below in S6.5.1.)

- S6.4.2: "The persistent entity ID property is the entity identifier of
the persistent ANE which an ephemeral ANE presents (See Section 5.1.2 for
details)." ==> I am not sure what this means? Why is an ephemeral ANE
presenting a persistent entity identifier?  Is it important that you are
defining an ephemeral ANE and associating it with persistent entities?  If
so, then please make this clear as there is a lot of ambiguity in this
section.

- S6.5.1: What is the effect if the ALTO server chooses to obfuscate the
path vector, causing the client to experience sub-optimal routing.  The
client does not know that the server has obfuscated the path vector, so it
MUST interpret the path vector as given to it by the ALTO server.  This
raises the question whether such obfuscation, because it is
indistinguishable from a non-obfuscated response, creates an attack on the
client?  (Would a mini Security Consideration paragraph be appropriate
here?)  Clearly, since ALTO assumes that the server is trusted to some
degree, the issue becomes (a) can the client, by repeated querying, figure
out that it is being duped on occasion?  (b) what does it then do?

Minor:

- S1, paragraph 3: Why would "job completion time" be shared by bottleneck
network links?  On first glance, job completion time is a function of the
compute resources on the host not network links, but on further reflection,
  job completion time could also be a function of the network links on the
host if the data needs to be marshalled to the job (process) in order for
it to complete.  If so, then perhaps reword as:

 OLD:
 For example, job completion time, which is an important QoE metric for a
large-scale data analytics application, is impacted by shared bottleneck
links inside the carrier network.

 NEW:
 For example, job completion time, which is an important QoE metric  for a
large-scale data analytics application, is impacted by shared  bottleneck
links inside the carrier network as link capacity may  impact the rate of
data input/output to the job.

- S5.1.1: "Thus they must follow the mechanisms specified in the
[i-D.ietf-alto-unified-props-new]." ==> Here, it may help to point 

[alto] Next steps on unified-properties

[Vijay Gurbani]

Dear Authors: I have submitted my chair review of unified-props [1,2].
Please address the comments, holding any further list discussion as
appropriate.  As soon as a new version is released, I can move the draft
out of the WG.  The shepherd writeup was shared with the WG earlier [3].

Thanks,

- vijay

[1] https://mailarchive.ietf.org/arch/msg/alto/7ZCGFIoT9OnZBNYOzUONbI53IxM/
[2] https://mailarchive.ietf.org/arch/msg/alto/cBBx_uQpGQh9bkIne0YoXjdRIes/
[3] https://mailarchive.ietf.org/arch/msg/alto/Ov3f3HGPwRm09nnubXgLi-MiZRI/
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

[alto] Chair review of unified-props (Part 2 of 2)

[Vijay Gurbani]

Chair review from Section 5 - end (inclusive).

Please go through the Major review points, they require some attention.

This concludes my review of this document.  Overall a well-written document
covering a range of important extensions to ALTO.

Major:

- S5.1.1: "The '.' separator MUST NOT be used unless specifically indicated
in a
further extension document." ==> I don't understand this.  If the '.' must
not
be used, then this should be an absolute condition (MUST NOT is the
normative
strength in the sentence).  If this document allows the '.' to be used in a
further extension document, then this is a relative --- not absolute ---
condition, and thus a normative SHOULD NOT seem to be better.  However, as
currently written, this sentence seems rather wishy-washy.  Either say '.'
is
out of bounds or say it is not, it seems weird to say that this document
does
not use it, but others can.

One way to achieve this is to replace that sentence with:

  The '.' separator is not used by this document, however, future
  extensions may use it.  For the purpose of this document, the
  strings "ipv4", "ipv6", and "pid" are valid entity domain
  types, while "ipv4.anycast", and "pid.local" are invalid.

However, even then, I am not sure if the above is correct.  Later, in
S5.1.2,
you go on to say that "Note that the '.' separator is not allowed in
EntityDomainType and hence there is no ambiguity on whether an entity
domain
name refers to a resource-agnostic entity domain or a resource-specific
entity
domain."  Thus it seems to me that future extensions could run into trouble
if
they allow '.' in the EntityDomainType.

This needs to be resolved before publication.

- S5.1.2, last paragraph: "Note that the resource ID format defined in
Section
10.1 of [RFC7285]..." ==> Section 10.1 of RFC 7285 defines "PID Name", not
"Resource ID", which is defined in the next section.  Please clarify.

- S9.1: "...it is RECOMMENDED that the EPS be deprecated in favour of ..."
==>
This is very important: If this draft is recommending a change in RFC 7285,
then
the status of this draft must say "Updates: 7285" at the top of the draft
(it
currently does not).  This will cause the RFC Editor to enter a "Updated by:
RFC" in the masthead of RFC7285.

Further, I presume that since this update is a recommendation, the
processing
rules of property map and filtered property map are distinct enough that
legacy
ALTO servers and clients will continue operations?  Please advise.

- S9.3: What does "little or no impact on other previously defined
properties"
mean?  Again, this appears wishy-washy for a standards document.  Either we
know
that there is some impact, and we document what the impact is, or we state
that
there is no impact.  But saying "little or no impact" is not helpful.
Please
state where there is impact and whether this impact will cause backwards
compatibility problems.

I note that S12.2.1 further expands on this "little or no impact".  Perhaps
a
second order look at S9.3 is in order before publication to document the
impacts
on previously defined properties.

- S10: Please fill in all of the "###" for "Content-Length: ###" in all
examples.

- S11: Did anyone in the WG do a threat analysis of the information exposed
by
the property maps related to, say, domain type "ane"?  As the example in
S10.9
demonstrates, there is a lot of information in the returned response that
will
be of interest to malicious actors.

I note that there is a blanket paragraph in this section ("A particular
fundamental ... URI to provide the information.") that appears to address
such a
scenario, but I don't see a well thought out threat-model that drives the
discussion in this section.  At the very least, the authors should spend
some
time thinking about the information in the property maps and how it may be
used
if it fell in the hands of a malicious actor.  If after reflection they
come to
the conclusion that the second blanket paragraph outlines a mitigation
strategy
that suffices, then that is fine.  Just wanted to make sure that the authors
have spent some time here.

Minor:

- S5.1.3, last paragraph: I think you should append the following sentence
to
the paragraph:

  Such equivalences should be established by the object represented
  by DomainTypeSpecificEntityID, for example, [RFC5952] establishes
  equivalence for IPv6 addresses, while [RFC4632] does so for IPv4
  addresses.

Nits:

- Please run idnits; currently, it is reporting 3 errors having to do with
using
obsoleted references (RFCs 5226 and 7159) and a downref (RFC 7921).

Thanks,

- vijay
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

[alto] Chair review of unified-props (Part 1 of 2)

[Vijay Gurbani]

All: My apologies for the late start on the chair reviews of the documents
I am shepherding.  However, I have started the review.

Below is the first (of two parts) review of unified-props.  This review
includes all sections from Abstract to Section 4.7.1 (inclusive).

Please let me know if you have any questions.  I will post the second part
tomorrow.

Chair review from Abstract - Section 4.7.1 (inclusive).

*Major*:

- Abstract: "...by generalizing the concept of "endpoint properties" to
generic
type of entities..." ==> Note that the antecedent ("endpoint properties")
and
the consequent ("type of entities") do not match.  Perhaps better to say:
"...by
generalizing the concept of "endpoint properties" as applied to endpoints
defined by IP addresses to endpoints a wider set of objects..."

More concretely:

OLD:
This document extends the base Application-Layer Traffic Optimization
(ALTO) Protocol by generalizing the concept of "endpoint properties"
to generic types of entities, and by presenting those properties as
maps, similar to the network and cost maps in the base ALTO protocol.

NEW:
This document extends the base Application-Layer Traffic Optimization
(ALTO) Protocol by generalizing the concept of "endpoint properties"
as applied to endpoints as defined by IP addresses to endpoints defined
by a wider set of objects.  Further, these properties are presented
as maps, similar to the network and cost maps in the base ALTO protocol.

- S3.2.1: "An entity domain type is expected to be registered at the IANA"
==>
you mean "MUST be registered with IANA"?  Or "SHOULD be registered with
IANA"?
Best to use normative language here, unless you have a specific reason not
to.

- S3.2.2: What does this mean: "As a consequence, entities in such
domains may be defined in a resource handling this domain type but
not in other resources handling this same domain type."?  I am unable to
parse this, I think you are saying that of all the resources handling a
particular domain type, the entity must be defined in only one of them.  If
so, perhaps best to reword; something like:
   OLD:
   As a consequence, entities in such domains may be defined in a
   resource handling this domain type but not in other resources handling
   this same domain type.
   NEW:
   As a consequence, of all the resources defining a particular domain
   type, the entity must be defined in only one resource.

- S4.2.2, first paragraph: Is this example valid?  From my experience, ASN's
contain IPv4 addresses defined by a CIDR block.  I think it is highly
unlikely
that a service provider will define a CIDR block (192.0.1.0/24) and have
that
block span ASNs, but perhaps I am mistaken.  Perhaps someone from network
operations may want to look at this example and bless it, or if you are sure
that networks are architected in such a manner, then we can let it stay.

- S4.6.2: "When an ANE has a persistent identifier, say, "entity-4", the
latter", here what do you mean by "latter"?  In this sentence, I do not see
two
things that can be characterized as "former" and "latter"...?

- S4.7.1: This subsection appears as an afterthought; it is not "defining
resource media-types" as much as simply "listing resource media-types".  It
does
not appear to be comprehensive since it only includes two examples, which
leads
me to think that perhaps these examples are best put in parts of the text
that
refer to these property types.  Furthermore, the media type for property
"pid"
is already defined in RFC7285, so if you want to give an example here,
simply
refer to RFC7285 for it.  And, the media type "alto-cdnifci+json" is
defined in
draft-ietf-alto-cdni-request-routing-alto, not in this section.  My advice
would
be to remove this subsection, I don't think it is comprehensive and just
adds to
the confusion.

*Minor*:
- S3.1: in the bullet items, please be consistent when using "IPv4 or IPv6"
versus "ipv4 or ipv6".  Both forms are used, best to choose one and be
consistent in the section.  (I recognize that lower case "ipv4" and "ipv6"
are
used elsewhere in the document to define entity domains, that is okay; just
be
consistent in S3.1.)

- S3.1, last bullet item: What os a "routable network node"?  Is a network
node
that performs the routing function (a router)?  or is it a network node
that is
the recipient of a packet routed to it (an endpoint)?

- S4.4.3: s/sets in the upper level./subsets./
Rationale: "Upper level" of a set consists of elements that are subsets.
Since
you are using set theory here, perhaps best to use nomenclature in that
domain.  (You may edit it as "subsets (upper levels)." if that helps.

- S4.4.3: Similarly, "lower level" is "superset".

*Nits*:
- S1: s/which is also not globally/that may not be globally/

- S3.2.2: s/A PID is defined relatively to a network map./A PID is defined
relative to a network map./

- S3.4: s/thus conveying values of all property values/thus conveying all
  property values/

- S4.3: s/So that if/Thus, if/

- S4.5: s/ALTO 

Re: [alto] Shepherd writeup for path-vector (draft)

[Vijay Gurbani]

Dear Kai: Happy new year.

I am in the process of doing a chair review of path-vector and
unified-props.  My suggestion is that the nits can be addressed after I
post my chair review on the mailing list.
I am reviewing unified-props this week, so I will get to path-vector next
week.
Thanks,
- vijay

On Tue, Jan 12, 2021 at 5:39 AM  wrote:

>
> Hi Vijay,
>
>
> How do you do? We have fixed most of the IDNits errors/warnings with a new
> revision -14. The remaining warnings are:
>
>
> 1. IDNits identifes [TBD] as references but we are using them in examples
> as placeholders for content length values.
>
> 2. IDNits thinks the version of
> [I-D.yang-alto-deliver-functions-over-networks] is -00 but the latest
> version as we used in the draft is -01.
>
>
> How do you suggest we proceed here? Do you think we can submit -14 right
> now? Or we should wait for your review on -13?
>
>
> Thanks!
>
>
> Best,
>
> Kai
>
>
> -Original Messages-
> *From:*kai...@scu.edu.cn
> *Sent Time:*2021-01-12 17:46:53 (Tuesday)
> *To:* "Qin Wu" 
> *Cc:* "IETF ALTO" 
> *Subject:* Re: [alto] Shepherd writeup for path-vector (draft)
>
> Hi Qin,
>
>
> Thanks for the notification! I will fix the IDNits errors as soon as possible.
>
> Best,
> Kai
>
> 2021-01-12 09:45:08"Qin Wu" wrote:
>
> Hi, authors of path-vector:
>
> I haven’t seen you addressed IDnits errors raised by Vijay below:
>
>
> https://www6.ietf.org/tools/idnits?url=https://www.ietf.org/archive/id/draft-ietf-alto-path-vector-13.txt
>
> Please reply to Vijay and confirm whether there are anything missing or
> open issues which haven’t been closed.
>
>
>
> -Qin (With chair hat on)
>
> *发件人:* alto [mailto:alto-boun...@ietf.org] *代表 *Vijay Gurbani
> *发送时间:* 2020年12月2日 1:36
> *收件人:* IETF ALTO 
> *主题:* [alto] Shepherd writeup for path-vector (draft)
>
>
>
> All: I have started the shepherd review of path-vector  The review is
> below.
>
> The token is with me to do a chair/shepherd review of the draft.  With the
> semester coming to a close and grading to do, etc., I have reserved the
> week starting Dec-16 to do the shepherd review of the draft.
>
>
>
> In the meantime, please go through the draft shepherd writeup and let me
> know if I have erred anywhere.
>
>
>
> Thanks,
>
>
>
> - vijay
>
>
> -
>
> Shepherd writeup for draft-ietf-alto-path-vector-13
>
> 1. Summary.
>
> The document shepherd is Vijay K. Gurbani, and the responsible area
> director is Martin Duke.
>
> The document is a Standards Track document, targeted as a Proposed
> Standard.  The WG has chosen the requested publication type since this
> draft extends the base ALTO protocol in a normative manner.  Specifically,
> the document seeks to extend the base ALTO protocol (RFC 7285) to provide
> the concept of "Abstract Network Elements" (ANE).  ANEs are an abstraction
> of physical network components --- routers, etc. --- that handle (switch)
> packets.  An application whose performance may be impacted by a particular
> traversal path in the network may wish to consult the ANEs to determine an
> optimized path to the destination.
>
> This draft is a major conceptual advance in the abstractions provided by
> the base ALTO protocol.
>
> 2. Review and consensus.
> This work is mature.  It started off as an individual submission in March
> 2015, and was adopted as a WG deliverable in May 2017.  A detailed review
> of this draft was provided early on by Sabine Randriamasy [1,2,3] shortly
> after it was adopted.  Version -04 was further reviewed by Danny Perez [4]
> and Qiao Xiang [5] in 2018, and the work progressed appreciably between
> 2018 and 2019, resulting in the release of -09 in November 2019.
>
> A WGLC was initiated on Sep-28-2020, and a review was provided by Qiao
> Xiang [6] and Luis Contreras [7] on version -11.  Version -12 included the
> comments from Qiao and Luis, with version -13 following with some minor
> revisions.
>
> Earlier versions of path-vector have been implemented (without the
> integration of unified-props); the implementation was used in a super
> computing conference demonstration for OpenFlow-based networks [8].  The
> latest version of path-vector is being implemented and will be open-sourced
> on GitHub [9].
>
> The shepherd has an action item to review version -13.
>
> 3. Intellectual property
> All of the authors have confirmed with the shephered that they are not
> aware of any IPR filed with respect to the draft.
>
> 4. Other points
> IDNits rep

[alto] Shepherd writeup for path-vector (draft)

[Vijay Gurbani]

All: I have started the shepherd review of path-vector  The review is below.

The token is with me to do a chair/shepherd review of the draft.  With the
semester coming to a close and grading to do, etc., I have reserved the
week starting Dec-16 to do the shepherd review of the draft.

In the meantime, please go through the draft shepherd writeup and let me
know if I have erred anywhere.

Thanks,

- vijay
-
Shepherd writeup for draft-ietf-alto-path-vector-13

1. Summary.

The document shepherd is Vijay K. Gurbani, and the responsible area
director is Martin Duke.

The document is a Standards Track document, targeted as a Proposed
Standard.  The WG has chosen the requested publication type since this
draft extends the base ALTO protocol in a normative manner.  Specifically,
the document seeks to extend the base ALTO protocol (RFC 7285) to provide
the concept of "Abstract Network Elements" (ANE).  ANEs are an abstraction
of physical network components --- routers, etc. --- that handle (switch)
packets.  An application whose performance may be impacted by a particular
traversal path in the network may wish to consult the ANEs to determine an
optimized path to the destination.

This draft is a major conceptual advance in the abstractions provided by
the base ALTO protocol.

2. Review and consensus.
This work is mature.  It started off as an individual submission in March
2015, and was adopted as a WG deliverable in May 2017.  A detailed review
of this draft was provided early on by Sabine Randriamasy [1,2,3] shortly
after it was adopted.  Version -04 was further reviewed by Danny Perez [4]
and Qiao Xiang [5] in 2018, and the work progressed appreciably between
2018 and 2019, resulting in the release of -09 in November 2019.

A WGLC was initiated on Sep-28-2020, and a review was provided by Qiao
Xiang [6] and Luis Contreras [7] on version -11.  Version -12 included the
comments from Qiao and Luis, with version -13 following with some minor
revisions.

Earlier versions of path-vector have been implemented (without the
integration of unified-props); the implementation was used in a super
computing conference demonstration for OpenFlow-based networks [8].  The
latest version of path-vector is being implemented and will be open-sourced
on GitHub [9].

The shepherd has an action item to review version -13.

3. Intellectual property
All of the authors have confirmed with the shephered that they are not
aware of any IPR filed with respect to the draft.

4. Other points
IDNits reports 1 error, 7 warnings, and 2 comments.

[1] https://mailarchive.ietf.org/arch/msg/alto/IQ0WwgWewFKJkvzZSIQRhkiN-hc/
[2] https://mailarchive.ietf.org/arch/msg/alto/4wa_kXE4GUrigZ33TBCVVuwBuiw/
[3] https://mailarchive.ietf.org/arch/msg/alto/GGroJgfL5XGuH1ydWOLmISCPMKY/
[4] https://mailarchive.ietf.org/arch/msg/alto/HSGkZ2o4JvneiiYiVSGcCZjDVSQ/
[5] https://mailarchive.ietf.org/arch/msg/alto/qnIBXzFEiYxMDm9kvHLH53qbn_Y/
[6] https://mailarchive.ietf.org/arch/msg/alto/uwFNjekGcc3zMdSKleHU7eIdsW4/
[7] https://mailarchive.ietf.org/arch/msg/alto/D5jkRGws2c75paw6yP8_5_40ViY/
[8] https://github.com/openalto/mercator-setup
[9] https://github.com/openalto/sextant
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] FW: I-D Action: draft-ietf-alto-unified-props-new-15.txt

[Vijay Gurbani]

Dear Sabine: thanks. I have the draft on my list of review items for next
week. Will get back to you. Thanks.

On Thu, Nov 26, 2020, 1:31 PM Randriamasy, Sabine (Nokia - FR/Paris-Saclay)
 wrote:

> Dear Vijay, Jan and Qin
>
> The new version 15 below fully addresses the review comments and now
> includes a "navigation table" listing the new features and the section
> describing them. This table stressed the need to change some section titles
> for more coherency.
> Additionally, upon discussions with Qin,  Wendy and co-authors, the
> document title has now been changed to "ALTO extension: Entity Property
> Maps".
> The document section titles and text have been updated to harmonize with
> the document title.
> Other minor updates have been added to further address the need for
> clarification reflected in the reviews.
>
> The updates done on v14 to produce v15 are listed in the attached text
> file "v15-updates-2611.txt".
>
> We feel the document is now ready for WG chair review and look forward to
> getting review feedback.
>
> Thanks,
> Sabine, Jensen, Richard, Kai
>
> -Original Message-
> From: alto  On Behalf Of internet-dra...@ietf.org
> Sent: Thursday, November 26, 2020 8:15 PM
> To: i-d-annou...@ietf.org
> Cc: alto@ietf.org
> Subject: [alto] I-D Action: draft-ietf-alto-unified-props-new-15.txt
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Application-Layer Traffic Optimization WG
> of the IETF.
>
> Title   : ALTO extension: Entity Property Maps
> Authors : Wendy Roome
>   Sabine Randriamasy
>   Y. Richard Yang
>   Jingxuan Jensen Zhang
>   Kai Gao
> Filename: draft-ietf-alto-unified-props-new-15.txt
> Pages   : 57
> Date: 2020-11-26
>
> Abstract:
>This document extends the base Application-Layer Traffic Optimization
>(ALTO) Protocol by generalizing the concept of "endpoint properties"
>to generic types of entities, and by presenting those properties as
>maps, similar to the network and cost maps in the base ALTO protocol.
>The protocol is extended in two major directions.  First, from
>endpoints restricted to IP addresses to entities covering a wider and
>extensible set of objects; second, from properties on specific
>endpoints to entire entity property maps.  These extensions introduce
>additional features allowing entities and property values to be
>specific to a given information resource.  This is made possible by a
>generic and flexible design of entity and property types.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-alto-unified-props-new/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-alto-unified-props-new-15
> https://datatracker.ietf.org/doc/html/draft-ietf-alto-unified-props-new-15
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-alto-unified-props-new-15
>
>
> Please note that it may take a couple of minutes from the time of
> submission until the htmlized version and diff are available at
> tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
>
> ___
> alto mailing list
> alto@ietf.org
> https://www.ietf.org/mailman/listinfo/alto
>
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] Review of draft-ietf-alto-path-vector-11

[Vijay Gurbani]

Dear Kai: Thank you.  I will perform a chair review of -13 as part of the
shepherd writeup.
Thanks,
- vijay

On Thu, Nov 19, 2020 at 3:47 AM  wrote:

> Hi Jan, Vijay and Qin,
>
>
> As we discussed in the ALTO meeting today, -12 has addressed the comments
> of both Qiao and Luis but the revision proposed by Richard was not
> integrated. Also, Qin mentioned that a shorter and more concise abstract is
> expected.
>
>
> I have integrated the revisions of Richard and written a new abstract as
> below. Could you please take a look and see if the abstract makes sense? If
> it does, I will upload -13 once the submit tool is available.
>
>
> Thanks for the comments and looking forward to your feedback!
>
>
> Best,
>
> Kai
>
>
> --
>
>The performance of many applications, such as large-scale data
>transfers and/or mobile applications, depends on the properties of
>different components of networks.  Thus, such information is useful
>to help clients better determine the choices of delivering traffic,
>e.g., by avoiding shared bottlenecks.  This document extends the base
>Application-Layer Traffic Optimization (ALTO) protocol with a graph
>representation format using path vectors.  It 1) complements existing
>path-based ALTO cost map representation with the ability to specify
>components of networks for a source and a destination, and 2) uses
>the ALTO property map to associate these components to their
>properties.  Together, this extension provides a more complete but
>still abstract representation of networks for informed traffic
>optimization among endpoints.
>
>
> 2020-11-03 06:04:06"'Richard Yang'" wrote:
>
> 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.contrerasmuri...@telefonica.com> wrote:
>
>> Hi all,
>>
>>
>>
>> I have performed a review of the draft, with comments as follows:
>>
>>
>>
>> /* Technical comments */
>>
>> .- Section III Terminology – Path Vector bullet. Please, rephrase the
>> description, it is hard to understand, especially the second sentence. Not
>> 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 – it refers to recent use cases, 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 point. We have removed the word "recent" in the title and the
> text.
>
>
>
>> .- Section 4.2 – 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.
>
>
>> .- Section 5.1.3, 2nd paragraph – “… and the response must return and
>> only return the selected properties …” – two comments here: (1) must should
>> be MUST in this context?; (2) “… and only return …” – probably redundant,
>> better either remove or rephrase as “MUST/must only return”.
>>
>
> 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 – the figure shows two response messages, but some questions
>> arise in this respect: (1) what happens if second 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 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
>

Re: [alto] I-D Action: draft-ietf-alto-unified-props-new-14.txt

[Vijay Gurbani]

Please put the table in the end.  You can have a forward reference to the
table at the beginning of the I-D to let people know.

I will like to perform a chair/shepherd review on a version that close to
being a final one.

Thanks.

On Tue, Nov 17, 2020 at 1:15 PM Randriamasy, Sabine (Nokia -
FR/Paris-Saclay)  wrote:

> Dear all,
>
> Version 13 - draft-ietf-alto-unified-props-new-13.txt posted on Nov 2nd
> addresses the review comments of Danny and most comments of Luis. This
> version 14 addresses pending comments of the review provided by Luis. The
> only unresolved comment by Luis is providing a table listing the protocol
> extensions and pointing to the relevant sections in the text. Given that
> the extensions are defined progressively, we need to figure out where to
> place the table in the document (beginning or end). Any suggestion is
> welcome.
>
> I will send separate e-mails to Danny and Luis, to describe how their
> review comments were addressed. Great thanks again to both for the thorough
> review.
>
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

[alto] Minute takers and Jabber scribe

[Vijay Gurbani]

All: In preparation of our meeting on Thu, can we kindly have a couple
people volunteer for note takers and a Jabber scribe?

Please send an email to the chairs to indicate your willingness.

Thank you in advance.

- vijay
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] Any implementations of unified-props, alto-cdni, path-vector

[Vijay Gurbani]

Dear Jensen: Thank you, this is excellent information.  You don't have to
hurry up your release schedule due to my query.  I just want to document
the implementations that are in the path of progress, or have been
implemented (even on older releases of the I-Ds).

Also, thanks to Richard, Sabine, Wendy for getting back to me on
implementations as well.

I think I have all I need for the shepherd writeups.

Cheers,

- vijay

On Thu, Nov 12, 2020 at 9:18 PM Jensen Zhang 
wrote:

> Hi Vijay,
>
> Sorry for my late reply.
>
> I want to mention that Kai and I are implementing the latest version of
> these three documents. The implementation will be open-source on GitHub
> [1]. But it is still in progress. We may have a release by the next IETF.
>
> As Richard mentioned, we have an implementation for a very early version
> of the path vector document [2]. It is only for OpenFlow-based networks.
> And we didn't integrate unified properties.
>
> I remember Danny also has an implementation of the unified properties
> document.
>
> [1] https://github.com/openalto/sextant
> [2] https://github.com/openalto/mercator-setup
>
> Best,
> Jensen
>
>
> On Fri, Nov 13, 2020 at 5:30 AM Wendy Roome  wrote:
>
>> Vijay,
>>
>>
>>
>> My server did support PID properties and allowed endpoints to inherit
>> them, and had a “get-all-props” extension.
>>
>>
>>
>> But it didn’t implement the current version.
>>
>>
>>
>>- Wendy
>>
>>
>>
>> *From: *alto  on behalf of "Y. Richard Yang" <
>> y...@cs.yale.edu>
>> *Date: *Thu, November 12, 2020 at 12:58
>> *To: *"Randriamasy, Sabine (Nokia - FR/Paris-Saclay)" <
>> sabine.randriam...@nokia-bell-labs.com>
>> *Cc: *IETF ALTO 
>> *Subject: *Re: [alto] Any implementations of unified-props, alto-cdni,
>> path-vector
>>
>>
>>
>> Hi Vijay,
>>
>>
>>
>> - I believe that there was an implementation of unified properties by
>> Wendy Roome. But it is for an earlier version, not the latest one which we
>> just posted.
>>
>>
>>
>> - I understand that there was an implementation of path vector used in
>> super computing demonstration; but it was for an earlier version of path
>> vector without the integration of unified properties.
>>
>>
>>
>> Richard
>>
>>
>>
>> On Thu, Nov 12, 2020 at 12:43 PM Randriamasy, Sabine (Nokia -
>> FR/Paris-Saclay)  wrote:
>>
>> Hi Vijay,
>>
>>
>>
>> To my knowledge,
>>
>>
>>
>> - there is no implementation of Unified Properties that reflects the
>> latest design updates, defined in 2019 and 2020,
>>
>> - I am not aware of any implementation of Path Vector.
>>
>>
>>
>> Best regards,
>>
>> Sabine
>>
>>
>>
>> *From:* alto  *On Behalf Of *Vijay Gurbani
>> *Sent:* Wednesday, November 11, 2020 5:57 PM
>> *To:* IETF ALTO 
>> *Subject:* [alto] Any implementations of unified-props, alto-cdni,
>> path-vector
>>
>>
>>
>> All: I am the shepherd for the three drafts identified in the subject.
>>
>>
>>
>> As I prepare the shepherd writeup, I will like to document if there are
>> any implementations of these three drafts that the WG members are aware
>> of.  These implementations can be private (a few individuals working on the
>> drafts), or be more formal with a GitHub repository and a larger community.
>>
>>
>>
>> If any WG member is aware of implementations, please let me know.  Please
>> drop me an email (or  post on the list) with the details as you know them.
>> I would like to kindly ask you to do this as soon as possible ---
>> preferably by the end of this week --- to allow me to prepare the shepherd
>> writeup.
>>
>>
>>
>> Thank you.
>>
>>
>>
>> - vijay
>>
>> ___
>> alto mailing list
>> alto@ietf.org
>> https://www.ietf.org/mailman/listinfo/alto
>>
>> --
>>
>> Richard
>>
>> ___ alto mailing list
>> alto@ietf.org https://www.ietf.org/mailman/listinfo/alto
>> ___
>> alto mailing list
>> alto@ietf.org
>> https://www.ietf.org/mailman/listinfo/alto
>>
> ___
> alto mailing list
> alto@ietf.org
> https://www.ietf.org/mailman/listinfo/alto
>
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

[alto] Input to NomCom

[Vijay Gurbani]

All: Please see the email below from Barbara Stark, 2020 NomCom chair, and
provide any input that you can.  Thank you.

NomCom is considering nominees for AD positions, IETF Chair, IAB, LLC
Board, and IETF Trust. We need more input from the community both on
specific nominees and on over-arching topics regarding what the community
wants from these specific groups and wants from its leadership in general.
We need *your* input.

** Deadline for community feedback is Friday November 20. **

We've paid attention to discussions on the ietf list. Issues raised there
have been brought up in interviews.

We've also asked questions of nominees based on feedback received, and
based on the "Topics" that people said were important.
We're listening to you.

But most of the input to date has come from a few consistently vocal
people. We need to hear from more of you.

I scheduled our office hours during the 2 weeks before next week's IETF,
because IETF week is so busy. We have one more left (18:00-19:00 UTC
November 11). No-one but NomCom members showed up for our first 3. ☹ If
there is demand for more office hours, I'll schedule them; but this really
doesn't seem to be the preferred format for input.

Most input is coming in as either
 - email to nomco...@ietf.org
 - feedback on https://datatracker.ietf.org/nomcom/2020/feedback/
On the feedback page, the specific nominees are all listed at the top.
General Topics are at the bottom.
We pay attention to all the comments we get through these channels.

I'll also try to hang out in Gather.Town during IETF breaks next week.
I'm not going to have a specific NomCom area in Gather.Town, because it was
really lonely hanging out there during IETF 108.
But please feel free to hunt me down and bend my ear -- on NomCom issues or
just to chat.
I miss seeing all of y'all!
Barbara

Barbara Stark
NomCom 2020 Chair
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

[alto] Any implementations of unified-props, alto-cdni, path-vector

[Vijay Gurbani]

All: I am the shepherd for the three drafts identified in the subject.

As I prepare the shepherd writeup, I will like to document if there are any
implementations of these three drafts that the WG members are aware of.
These implementations can be private (a few individuals working on the
drafts), or be more formal with a GitHub repository and a larger community.

If any WG member is aware of implementations, please let me know.  Please
drop me an email (or  post on the list) with the details as you know them.
I would like to kindly ask you to do this as soon as possible ---
preferably by the end of this week --- to allow me to prepare the shepherd
writeup.

Thank you.

- vijay
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] Welcome Qin Wu

[Vijay Gurbani]

Dear Qin: Welcome to the C(hair)-suite :-) Jan and I are looking forward to
working with you during IETF 109.
Thanks,
- vijay

On Wed, Nov 11, 2020 at 3:35 AM Qin Wu  wrote:

> Hi, Martin, et al :
>
> Thank for having me.  Jan and Vijay, I am happy to come back to ALTO team
> and help deliver the existing work on the table and in the meanwhile, work
> together with you senior chairs to drive new work discussion.
>
> Look forward to working with you soon next week, thanks!
>
>
>
> -Qin
>
> *发件人:* Y. Richard Yang [mailto:y...@cs.yale.edu]
> *发送时间:* 2020年11月11日 12:47
> *收件人:* Martin Duke ; Qin Wu 
> *抄送:* IETF ALTO 
> *主题:* Re: [alto] Welcome Qin Wu
>
>
>
> Thanks a lot for choosing a wonderful chair for ALTO, Martin!
>
>
>
> Qin: It is wonderful to have you and work with your guidance!
>
>
>
> Richard
>
>
>
> On Mon, Nov 9, 2020 at 10:48 PM Martin Duke 
> wrote:
>
> Hello ALTO,
>
>
>
> I'm pleased to welcome Qin Wu as the newest working group chair, effective
> immediately. Qin is and active participant in ALTO and an experienced chair.
>
>
>
> We will have three chairs at IETF 109. Shortly afterwards, one of the
> current chairs will step down. As we complete the current milestones, I
> will appoint a second chair to free both Jan and Vijay to move on to other
> things.
>
>
>
> See you next week,
>
> Martin
>
> ___
> alto mailing list
> alto@ietf.org
> https://www.ietf.org/mailman/listinfo/alto
>
>
>
>
> --
>
> --
>
>  =
>
> | Y. Richard Yang|
>
> | Professor of Computer Science   |
>
> | http://www.cs.yale.edu/~yry/|
>
>  =
> ___
> alto mailing list
> alto@ietf.org
> https://www.ietf.org/mailman/listinfo/alto
>
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

[alto] IETF 109 ALTO draft agenda

[Vijay Gurbani]

All: In IETF 109, we will like to focus on the re-chartering process.  To
that extent, Jan and I have presented our thoughts on this in [1].

The draft agenda presented here is in line with [1], with the majority of
time being devoted to the charter discussion.

IETF 109 ALTO agenda. (*Draft*)
30 mins - Chair slides.  (This will include the status of each open WG
agenda deliverable from the chair's point of view, including any high
priority issues that the draft authors must attend to.)
90 mins - Charter discussions. (Please see [1] for structuring the
discussion.)

[1] https://mailarchive.ietf.org/arch/msg/alto/f7y2jh4qjAtZKbyPbk2pLr7wEOU/

Please let Jan and me know of any concerns or changes to the draft agenda.

Thanks.
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

[alto] IMPORTANT: Suggestions for IETF 109 ALTO meeting

[Vijay Gurbani]

All: We plan to devote most of the time during our IETF 109 slot to charter
discussions.

Approaching the rechartering discussion in the manner we did during IETF
108 was not very conducive as most of the time was spent in 10 - 16 slide
shows. The WG decided that we will hold a virtual interim to make progress
towards 3-5 items that can be chartered under a new charter.  Clearly a
virtual interim did not happen, but work towards winnowing down the charter
items has been going on in the Wed meeting that a subset of the WG
organizes weekly.

The intent of the meeting slot in IETF 109 will be to make progress towards
rechartering, which concretely implies that we have some charter text to
discuss and that this includes 3-5 milestones that the rechartered WG will
decide to pursue.

Writing a charter text is an art form, so my advice to the Wed meeting
group will be to devote the remaining meetings to come up with a candidate
charter text.  It won't be perfect, but it will be a starting point to host
discussions on re-chartering during IETF 109.  Please make sure that you
have 3-5 deliverables in the charter along with reasonable milestones.
Each piece of work that goes into a charter should have some thoughts
behind it, or some candidate drafts.

I don't expect IETF 109 to be the end of charter discussion, but rather it
will be the first formal introduction of the WG to the charter and should
kick off the process to arrive at a charter that has consensus of all
relevant parties involved.

Please let Jan and me know if there are any questions.

Thanks,

- vijay
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

[alto] Status of WGLC reviews --- need one more reviewer for path-vector

[Vijay Gurbani]

All: This is my view of WGLC reviews for unified-props,
performance-metrics, and path-vector.  I will like the authors of each
draft to read the status below and respond.

unified-props: Needed one more review, which was provided by Luis.  Given
the previous review by Danny, this draft now needs a revision to address
comments raised.  (Thanks, Luis and Danny.)
Authors, please advise on next steps.

performance-metrics: WGLC ended Oct 12.  Has three reviews: Danny, Jensen,
and Kai (thanks!).
Authors, please advise on next steps.

path-vector: WGLC ended Oct 12.  Has only one review by Qiao (thanks!).
Need a second review for this work to progress.  Anyone wants to volunteer?

Thanks,

- vijay
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

[alto] Need reviewers for path-vector

[Vijay Gurbani]

All: We have volunteers reviewing unified-props (Luis), performance-metrics
(Danny, Kai, and Jensen).  We need reviewers for path-vector.  I have not
seen anyone volunteer yet, please do.  (If you have volunteered and I
missed it, please send me and Jan an email.)

Thanks,

- vijay
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] WGLC for draft-ietf-alto-performance-metrics-12

[Vijay Gurbani]

Dear Kai: Excellent!  Thank you.

On Tue, Sep 29, 2020 at 7:30 PM  wrote:

> Hi Vijay,
>
>
> I can also review the performance metrics document.
>
>
> Best,
>
> Kai
>
>
> -----Original Messages-
> *From:*"Vijay Gurbani" 
> *Sent Time:*2020-09-30 02:53:35 (Wednesday)
> *To:* "Danny Alex Lachos Perez" 
> *Cc:* "IETF ALTO" 
> *Subject:* Re: [alto] WGLC for draft-ietf-alto-performance-metrics-12
>
> Dear Danny: Excellent, and thank you for your time on this.
>
> We still need one more reviewer for performance-metrics and two for
> path-vector.
>
> All: Please step up.
>
> Thank you.
>
>
> On Tue, Sep 29, 2020 at 8:32 AM Danny Alex Lachos Perez <
> dlachos...@gmail.com> wrote:
>
>> Hello Jan & Vijay
>>
>> I will review the Performance Metrics document.
>>
>> Best regards,
>>
>> Danny Lachos
>>
>>
>> On Mon, Sep 28, 2020 at 1:42 PM Jan Seedorf  wrote:
>>
>>> Dear all,
>>>
>>> as discussed during the ALTO session at IETF-108, we are moving forward
>>> with all the remaining milestones.
>>>
>>> Thus, this email starts a WGLC for
>>> draft-ietf-alto-performance-metrics-12. The WGLC will run two weeks, so
>>> from today, Monday, September 28, until Monday, Oktober 12, 2020.
>>>
>>> We would like to have two individual reviews of this document as part of
>>> the WGLC. Please send us an email if you are willing review the draft as
>>> part of WGLC. We really need these reviews to make progress.
>>>
>>>   - Vijay and Jan
>>>
>>> ___
>>> alto mailing list
>>> alto@ietf.org
>>> https://www.ietf.org/mailman/listinfo/alto
>>>
>> ___
>> alto mailing list
>> alto@ietf.org
>> https://www.ietf.org/mailman/listinfo/alto
>>
>
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] WGLC for draft-ietf-alto-performance-metrics-12

[Vijay Gurbani]

Dear Danny: Excellent, and thank you for your time on this.

We still need one more reviewer for performance-metrics and two for
path-vector.

All: Please step up.

Thank you.


On Tue, Sep 29, 2020 at 8:32 AM Danny Alex Lachos Perez <
dlachos...@gmail.com> wrote:

> Hello Jan & Vijay
>
> I will review the Performance Metrics document.
>
> Best regards,
>
> Danny Lachos
>
>
> On Mon, Sep 28, 2020 at 1:42 PM Jan Seedorf  wrote:
>
>> Dear all,
>>
>> as discussed during the ALTO session at IETF-108, we are moving forward
>> with all the remaining milestones.
>>
>> Thus, this email starts a WGLC for
>> draft-ietf-alto-performance-metrics-12. The WGLC will run two weeks, so
>> from today, Monday, September 28, until Monday, Oktober 12, 2020.
>>
>> We would like to have two individual reviews of this document as part of
>> the WGLC. Please send us an email if you are willing review the draft as
>> part of WGLC. We really need these reviews to make progress.
>>
>>   - Vijay and Jan
>>
>> ___
>> alto mailing list
>> alto@ietf.org
>> https://www.ietf.org/mailman/listinfo/alto
>>
> ___
> alto mailing list
> alto@ietf.org
> https://www.ietf.org/mailman/listinfo/alto
>
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] Interested in reviewing unified-props? And other drafts as well

[Vijay Gurbani]

On Mon, Sep 28, 2020 at 10:48 AM LUIS MIGUEL CONTRERAS MURILLO <
luismiguel.contrerasmuri...@telefonica.com> wrote:

> Hi Vijay,
>
>
>
> My apologies for my lack of responsiveness, I have had a number of
> subsequent events impeding me to concentrate on this.
>
>
>
> My answer is yes, and I take October 9th as hard deadline for providing
> my review. Is that correct?
>
>
Dear Luis: Thank you for getting back to me with an affirmative response.
Yes, Oct 9 is the hard deadline.

I appreciate your time and attention to moving this work forward.

Ciao,

- vijay
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

[alto] Interested in reviewing unified-props? And other drafts as well

[Vijay Gurbani]

Dear Luis: Are you still interested in reviewing unified-props?  If so, can
you please let Jan and me know as soon as possible?  The draft needs an
in-depth WGLC review by Oct. 9.

All: Since my posting asking for volunteers to review unified-props [1], I
have received no offers.  Considering that we have performance-metrics
draft and the path-vector draft that need to be reviewed for WGLC, the lack
of review volunteers do not bode well.

One logical conclusion that can be drawn if we do not get any review offers
is that the WG does not have the energy to finish existing work.  This begs
the question on why recharter ALTO if we cannot meet the current deadlines.

A subset of you are organizing weekly meetings to further the work on
drafts and re-chartering.  My advice would be that effort spent on those
meetings should be redirected (or at least shared) with reviewing existing
drafts so we can finish up the work and get ready for re-chartering.

[1] https://mailarchive.ietf.org/arch/msg/alto/cWi2YNk6odQ_hL-0oF9GRxKyYqs/

Cheers,

- vijay
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] Status of alto-unified-props: Not encouraging?

[Vijay Gurbani]

Dear Sabine: Thank you for your note.  I think it is very important that
the WG participates in the reviews to finish this piece of work.  Absent
such robust participation, I am at a loss on how we can progress this work.

I will really like an identified reviewer (if not Luis) to let the chairs
know so we can help facilitate the work.

Thank you.

On Fri, Sep 25, 2020 at 10:28 AM Randriamasy, Sabine (Nokia -
FR/Paris-Saclay)  wrote:

> Hi Vijay,
>
>
>
> Thank you for the reminder. A new version 13 is under edition and
> addresses the review of Danny. It will also address the second review
> comments once they will be available.
>
>
>
> Thanks,
>
> Sabine
>
>
>
> *From:* alto  *On Behalf Of *Vijay Gurbani
> *Sent:* Friday, September 25, 2020 4:59 PM
> *To:* IETF ALTO 
> *Subject:* [alto] Status of alto-unified-props: Not encouraging?
>
>
>
> All: The unified-properties draft is now done with its WGLC.  (In fact, it
> is well past done.  WGLC ended on Aug 7, 2020 [0].)
>
> I will be shepherding this draft, however, I see a problem with it.
>
> I note that the draft only received one WGLC review , and this was from
> Danny [1].  My understanding from list discussion [2] is that Luis was to
> provide a second review, but I do not see the second WGLC review.  If I am
> mistaken, please let me know and I will apologize profusely.  In the event
> that there has not been a second WGLC review ...
>
> If a second review is provided, please be advised that the draft will not
> move ahead.  Since other drafts have a dependency on this draft, a lack of
> movement of unified-properties implies that progress of dependent drafts
> stops as well.
>
> I will kindly request Luis to provide a WGLC no later than Oct 09, two
> weeks from now.  If other list members want to review the draft in addition
> to Luis, please let Jan and me know.  We do need one more quality review
> for unified-properties to move ahead.  If a second review is not provided
> by Oct 09, the chairs will take this as advice that the work is no longer
> important to the WG, and the WG will have to decide on the fate of
> dependent documents.
>
> @Authors: It looks like Danny's comments have not yet been incorporated in
> a new revision.  Danny reviewed version -12 and that appears to be the
> latest version in the IETF archives.  Please notify the WG on your plans to
> update the draft based on Danny's comments.
>
> [0]
> https://mailarchive.ietf.org/arch/msg/alto/jhPmZR4UKpiIwA_tC2s9b9YZ8Mk/
> [1]
> https://mailarchive.ietf.org/arch/msg/alto/YVaCXE7IgXOqWpq-17GV-gbiYwo/
> [2]
> https://mailarchive.ietf.org/arch/msg/alto/b0xwfQUVnYp_o58tJO32MF9p42I/
>
> Thanks,
>
> - vijay
>
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

[alto] Status of alto-unified-props: Not encouraging?

[Vijay Gurbani]

All: The unified-properties draft is now done with its WGLC.  (In fact, it
is well past done.  WGLC ended on Aug 7, 2020 [0].)

I will be shepherding this draft, however, I see a problem with it.

I note that the draft only received one WGLC review , and this was from
Danny [1].  My understanding from list discussion [2] is that Luis was to
provide a second review, but I do not see the second WGLC review.  If I am
mistaken, please let me know and I will apologize profusely.  In the event
that there has not been a second WGLC review ...

If a second review is provided, please be advised that the draft will not
move ahead.  Since other drafts have a dependency on this draft, a lack of
movement of unified-properties implies that progress of dependent drafts
stops as well.

I will kindly request Luis to provide a WGLC no later than Oct 09, two
weeks from now.  If other list members want to review the draft in addition
to Luis, please let Jan and me know.  We do need one more quality review
for unified-properties to move ahead.  If a second review is not provided
by Oct 09, the chairs will take this as advice that the work is no longer
important to the WG, and the WG will have to decide on the fate of
dependent documents.

@Authors: It looks like Danny's comments have not yet been incorporated in
a new revision.  Danny reviewed version -12 and that appears to be the
latest version in the IETF archives.  Please notify the WG on your plans to
update the draft based on Danny's comments.

[0] https://mailarchive.ietf.org/arch/msg/alto/jhPmZR4UKpiIwA_tC2s9b9YZ8Mk/
[1] https://mailarchive.ietf.org/arch/msg/alto/YVaCXE7IgXOqWpq-17GV-gbiYwo/
[2] https://mailarchive.ietf.org/arch/msg/alto/b0xwfQUVnYp_o58tJO32MF9p42I/

Thanks,

- vijay
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

[alto] Implementation status

[Vijay Gurbani]

All: I want to draw your attention to RFC 7942.  It talks about an optional
section called "Implementation Considerations".  This section lists any
known implementation of the protocol and contact people, etc.  For some of
the ALTO drafts, it may not be a bad idea to include such a section.  RFC
7942 [1] provides more information on the structure and expectations of
this section.

[1] https://tools.ietf.org/html/rfc7942

Thanks,

- vijay
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

[alto] IETF 108 meeting minutes (draft)

[Vijay Gurbani]

All: The meeting minutes are now available at
https://www.ietf.org/proceedings/108/minutes/minutes-108-alto-00

Please let Jan and me know if there are any changes to be made.

Thanks.
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

[alto] ALTO in IEEE Communications Standards Magazine

[Vijay Gurbani]

All: Recently, Jan and I were invited to present the state of ALTO in IEEE
Communications Magazine.  Please see Page 9 of the June 2020 issue [1] for
ALTO-related news.  (The content is available without a paywall.)

[1] https://ieeexplore.ieee.org/stamp/stamp.jsp?tp==9139037

Thanks.
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] Note takers and Jabber scribe

[Vijay Gurbani]

Dear Sabine: Excellent.  Thank you both.

On Sun, Jul 26, 2020 at 9:51 AM Randriamasy, Sabine (Nokia -
FR/Paris-Saclay)  wrote:

> Hi Vijay,
>
>
>
> Unless somebody else already volunteered, I can be the second note taker
>
> Cheers,
>
> Sabine
>
>
>
>
>
> *From:* alto  *On Behalf Of *Vijay Gurbani
> *Sent:* Sunday, July 26, 2020 1:29 AM
> *To:* Qiao Xiang 
> *Cc:* IETF ALTO 
> *Subject:* Re: [alto] Note takers and Jabber scribe
>
>
>
> Excellent.  Thank you!
>
>
>
> On Fri, Jul 24, 2020 at 10:33 PM Qiao Xiang  wrote:
>
> Hi Vijay,
>
>
>
> I'd be glad to be a note taker.
>
>
>
>
>
> Best
>
> Qiao
>
>
>
> On Fri, Jul 24, 2020 at 10:04 PM Vijay Gurbani 
> wrote:
>
> All: If you are willing to take notes, please send Jan and me an email.
> We will need two note takers and one Jabber scribe..
>
>
>
> Thank you.
>
>
>
> - vijay
>
> ___
> alto mailing list
> alto@ietf.org
> https://www.ietf.org/mailman/listinfo/alto
>
> --
>
> Qiao Xiang
> Postdoctoral Fellow,
>
> Department of Computer Science,
>
> Yale University
>
>
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] Note takers and Jabber scribe

[Vijay Gurbani]

Excellent.  Thank you!

On Fri, Jul 24, 2020 at 10:33 PM Qiao Xiang  wrote:

> Hi Vijay,
>
> I'd be glad to be a note taker.
>
>
> Best
> Qiao
>
> On Fri, Jul 24, 2020 at 10:04 PM Vijay Gurbani 
> wrote:
>
>> All: If you are willing to take notes, please send Jan and me an email.
>> We will need two note takers and one Jabber scribe..
>>
>> Thank you.
>>
>> - vijay
>> ___
>> alto mailing list
>> alto@ietf.org
>> https://www.ietf.org/mailman/listinfo/alto
>>
> --
> Qiao Xiang
> Postdoctoral Fellow,
> Department of Computer Science,
> Yale University
>
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

[alto] NomCom during IETF 108

[Vijay Gurbani]

All: NomCom will be holding some office hours next week. If you want to
stop by and talk with them (just to say Hi, ask about NomCom, ask about
being a nominee for the various I* positions, etc.), they woud love to see
and hear from you.

The date and times (which are also posted on the IETF 108 Agenda) are:

Monday, July 27, 16:00-17:00 UTC WebEx:
https://ietf.webex.com/ietf/j.php?MTID=m13c41ae118e538b6d25efb25d41307ee
Tuesday, July 28, 09:30-10:30 UTC WebEx:
https://ietf.webex.com/ietf/j.php?MTID=m6132b48c3eac5469a41043ce55dada20
Thursday, July 30, 20:00-21:00 UTC WebEx:
https://ietf.webex.com/ietf/j..php?MTID=mf7ce451931e35818fd7b3bf44abd1026

Thanks.
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

[alto] ALTO Meeting Details

[Vijay Gurbani]

All: The ALTO WG will meet on Mon at 1410-1550 UTC.

Here are some salient links:

IETF agenda: https://datatracker.ietf.org/meeting/108/agenda/

ALTO agenda: https://www.ietf.org/proceedings/108/agenda/agenda-108-alto-00

ALTO WG Meetecho video stream:
https://meetings.conf.meetecho.com/ietf108/?group=alto==1

ALTO WG audio stream: http://mp3.conf.meetecho.com/ietf/ietf1088.m3u

Etherpad for notetakers: https://codimd.ietf.org/notes-ietf-108-alto

Cheers,

- vijay
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

[alto] Note takers and Jabber scribe

[Vijay Gurbani]

All: If you are willing to take notes, please send Jan and me an email.  We
will need two note takers and one Jabber scribe.

Thank you.

- vijay
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

[alto] Upload slides (PDF)

[Vijay Gurbani]

All: The ALTO session is scheduled on Mon, next week.

Please upload the slides through the meeting manager.  As before, as long
as you have a datatracker account, you should be able to upload the slides
by yourself.

I would advise to put some sort of version number on the title slide just
so you can track the slides if you upload multiple versions.

See you on Mon.  Have a great weekend, all.

- vijay
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

[alto] Re-chartering guidance

[Vijay Gurbani]

All: As you may have noticed from the ALTO agenda, the last hour of our
meeting time is devoted to re-chartering discussion.

At issue is how to best use that time?

I laid out the two approaches on how to use this time in [1], and
subsequent to that, Jan, Martin, and I have had a quick chat on providing
some guidance to the principals so the hour can be used in the most optimal
manner.

To summarize [1], here are the two ways: One, have individual speakers talk
about their specific pieces of work, and then have a recharter discussion
that tries to weave in all of the presentations.  Or two, have one
presenter present a coherent rechartering discussion that includes works
from others, and then lead the larger discussion.  The former approach has
been used in the past during BoFs, but may not be as applicable to us here
for reasons enunciated in [2].

This leaves the second option: have a discussion leader who will summarize
existing threads of work being sought in a recharter, and drive the
discussion forward.  We think this is the best way to move forward on
rechartering discussion.

Therefore, here is a concrete proposal:

- Choose one person to lead the discussion.  (Call him or her the
discussion leader.  I note that a subset of you have started a Google doc
[3] that starts collecting potential recharter discussion items.)

- The discussion leader leads the discussion, and everyone who wants to
contribute a presentation that will have impact on the rechartering
discussion should produce 1 slide (and 1 slide only, no title slide, just a
single slide that includes architecture, results, and discussions on their
specific work item for rechartering).  The creators of this 1-slide send it
to the discussion leader [4].

- The creator of the slide may come up to the mic and speak to their slide
for 1 minute (and 1 minute only).  This limit will be enforced by the
chairs (apologies in advance).

- The remaining time after a series of 1 minute presentations will be left
for the broader discussion on rechartering.

We hope that this provides some structure and guidance to the rechartering
discussions.  Please let Jan and me know if you have any questions, and
please let us know who the discussion leader will be.

[1] https://mailarchive.ietf.org/arch/msg/alto/rmBGzkM6hPPXLs1r5ngplxe-7ak/
[2] We eschew the BoF approach primarily driven by time constraints:
consider that I counted at least 11 drats that were identified possible
recharter discussion, and a separate request for a 20 minute slot.
Assuming we allocate 5 minutes to each draft, we are looking at 55 minutes
already!  Not to mention the 20 minute slot.  Therefore, allocating time
for presentations will not be possible if we want to devote most of the
time to discussing the recharter.
[3]
https://docs.google.com/document/d/1qP9jf-CMXvNiEE3YAnApTczAE4QkBW23Q1Eg99uOaEQ/edit
[4] While I do not relish being the creator of these 1 minute slides, I
have found them to be very effective at focusing on the main message itself
instead of meandering around.  Consider these the equivalent of an
"elevator pitch".

Thanks,

- vijay
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] Draft IETF 108 ALTO agenda

[Vijay Gurbani]

Richard, all: There are generally two approaches for discussions that
involve chartering a working group or rechartering one.  (This is based on
my impressions, of course, so any errors are mine.)  One way to do this is
to have individual speaking slots where interested folks make a pitch on
specific work items that will eventually be related to the (re)charter,
plus some time for an open discussion.  The second way to do this ---
perhaps this way makes more sense for a recharter than an initial BOF that
seeks to charter and establish a WG --- is to have one narrator drive the
reasons for (re)chartering, and have an open discussion.

Right now, while the latter seems to make sense from my perspective, I
don't know what the thoughts of my co-chair or the AD are.  Jan, Martin,
and I will huddle and try to figure out how to provide some order to the
hour-long discussion slot we have.  Once we have clarity among the three of
us, we can provide further guidance.  In the meantime, any thoughts you or
others may have on how to shape up the hour-long charter slot, please post
to the list.

Thanks,

- vijay




On Wed, Jul 15, 2020 at 9:59 AM Y. Richard Yang  wrote:

> Hi Vijay,
>
> Making a single bulk slot instead of many small presentations for the
> discussion makes a lot of sense. It is a good agenda.
>
> Richard
>
> On Wed, Jul 15, 2020 at 10:54 AM Vijay Gurbani 
> wrote:
>
>> All: The draft agenda is at [1].  Please note that requests for
>> presentations of non-WG items were not honored since we will like to
>> provide the bulk of the second hour to the recharter discussion.
>>
>> Please let Jan and me know of any changes to the agenda.  Thanks.
>>
>> [1] https://datatracker.ietf.org/meeting/108/materials/agenda-108-alto-00
>> ___
>> alto mailing list
>> alto@ietf.org
>> https://www.ietf.org/mailman/listinfo/alto
>>
>
>
> --
> --
>  =
> | Y. Richard Yang|
> | Professor of Computer Science   |
> | http://www.cs.yale.edu/~yry/|
>  =
>
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

[alto] Draft IETF 108 ALTO agenda

[Vijay Gurbani]

All: The draft agenda is at [1].  Please note that requests for
presentations of non-WG items were not honored since we will like to
provide the bulk of the second hour to the recharter discussion.

Please let Jan and me know of any changes to the agenda.  Thanks.

[1] https://datatracker.ietf.org/meeting/108/materials/agenda-108-alto-00
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] Reminder: Agenda requests due by Tue CoB (US time)

[Vijay Gurbani]

ACK

On Tue, Jul 14, 2020 at 10:05 AM  wrote:

> Hi Vijay,
>
>
> I want to request a slot for path vector:
>
>
> Name of draft: draft-ietf-alto-path-vector-11
> Name of presenter: Kai Gao/Sabine Randriamasy
> Presentation time requested: 10 min
> Link to I-D: https://datatracker.ietf.org/doc/draft-ietf-alto-path-vector/
>
> Thanks!
>
>
> Best,
>
> Kai
>
>
> -Original Messages-
> *From:*"Vijay Gurbani" 
> *Sent Time:*2020-07-14 05:33:23 (Tuesday)
> *To:* "IETF ALTO" 
> *Cc:*
> *Subject:* [alto] Reminder: Agenda requests due by Tue CoB (US time)
>
> All: We have not received any agenda requests so far; if you have sent us
> one, please remind us (and accept our apologies).
>
> Please see [1] for agenda request format.
>
> Thanks,
>
> - vijay
>
> [1]
> https://mailarchive.ietf.org/arch/msg/alto/QsicOrADB6gqMhNc3hMrPNxXY18/
>
>
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] Reminder: Agenda requests due by Tue CoB (US time)

[Vijay Gurbani]

Dear Richard, as you saw my previous response, this is TBD.
I will chat with Jan and Martin and send out some guidance on the mailing
list on how to structure the rechartering discussion slot.
Thanks,
- vijay

On Tue, Jul 14, 2020 at 5:47 AM Y. Richard Yang  wrote:

> Hi Vijay, Jan,
>
> A question regarding the one-hour block for the recharter discussions. I
> see three types of slots:
> 1. A talk with a clear focus which may result in one particular chartered
> item (e.g., motivation and initial ideas for adding a specific alto
> extension);
> 2. A more broad-scoped talk which may result in multiple items (e.g.,
> extending alto to cellular networks/coordination with 3gpp on related
> network exposure functions);
> 3. Open mic for broad discussions.
>
> I assume that there will be a type 3 slot which we do not need to request.
>
> Any preference/recommendation on type 1 vs type 2?
>
> Thanks a lot!
>
> Richard
>
> On Mon, Jul 13, 2020 at 5:35 PM Vijay Gurbani 
> wrote:
>
>> All: We have not received any agenda requests so far; if you have sent us
>> one, please remind us (and accept our apologies).
>>
>> Please see [1] for agenda request format.
>>
>> Thanks,
>>
>> - vijay
>>
>> [1]
>> https://mailarchive.ietf.org/arch/msg/alto/QsicOrADB6gqMhNc3hMrPNxXY18/
>> ___
>> alto mailing list
>> alto@ietf.org
>> https://www.ietf.org/mailman/listinfo/alto
>>
> --
> Richard
>
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

[alto] Reminder: Agenda requests due by Tue CoB (US time)

[Vijay Gurbani]

All: We have not received any agenda requests so far; if you have sent us
one, please remind us (and accept our apologies).

Please see [1] for agenda request format.

Thanks,

- vijay

[1] https://mailarchive.ietf.org/arch/msg/alto/QsicOrADB6gqMhNc3hMrPNxXY18/
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

[alto] Are we on track to release the I-Ds ...

[Vijay Gurbani]

Dear Authors of path-vector, unified-props, and performance-metrics: Are we
on track to release the I-Ds by the end of today so we can start WGLC?

Please advise.

Thanks,

- vijay
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] ALTO Meeting Info for Jul. 08, 2020

[Vijay Gurbani]

All: Based on the status that Richard sent out of the three drafts (unified
properties, path vector, performance metrics), I will request the authors
to indicate to the WG whether these drafts are ready for WGLC when the new
versions appear in the IETF archives.

Assuming that they are, Jan and I will like to start identifying potential
WGLC reviewers for these drafts.  Please send Jan and me an email on
whether you will be interested in an in-depth WGLC, and if so, for which
particular draft(s).

Thanks,

- vijay

On Wed, Jul 8, 2020 at 11:02 PM Y. Richard Yang  wrote:

> Hi all,
>
> One very helpful feedback that we received is to provide an update to the
> WG on each weekly meeting, and here it is for today.
>
> - The team went over the 3 WG documents (UP, PV, and metrics) and
> confirmed that they will be submitted before the cut-off on Monday.
>
> - The team then spent around 30 min to go over some meeting summaries
> between Richard and those of the functional networking, which is being
> prepared as an item for the recharter. The functional networking (FN) work
> is making excellent progress, and a demo of the prototype was shown. In
> particular, the framework includes a resource layer and a functions layer.
> The team discussed the nice matching of the design with that of the CDNi WG
> document. Examples of functions/services include voice recognition, image
> detection,  Luis would be available to meet with the FN team on Friday
> or next early week.
>
> - The team then spent about an hour on the SIGCOMM'20 Network Application
> Integration/CoDesign paper by Sabine, Luis and Kai, which allows a
> high-level description of tasks and then provides an automatic translation
> from high level tasks to low-level APIs including ALTO. The team can share
> the paper with the WG by early next week when it is finished.
>
> Cheers,
> Richard
>
>
>
>
>
>
> On Tue, Jul 7, 2020 at 2:02 PM Danny Alex Lachos Perez <
> dlachos...@gmail.com> wrote:
>
>> Dear all,
>>
>> Just a friendly reminder that we will have our weekly meeting this
>> Wednesday (*Jul-08*) at *9:00 am US ET*.
>>
>> Agenda*:
>>
>>- WG documents status
>>- Progress on topics related to WG rechartering
>>- NAI Workshop
>>
>> *If people have other agenda items, please feel free to post.
>>
>> Bridge link: https://yale.zoom.us/my/yryang
>>
>> Best regards,
>>
>> Danny Lachos
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "alto-weekly-meeting" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to alto-weekly-meeting+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/alto-weekly-meeting/CAEDarXKw37rCx5EmdcfKwR49u2yQ0uRHRdPHQV4C-Ngkrb6y7A%40mail.gmail.com
>> 
>> .
>>
>
> ___
> alto mailing list
> alto@ietf.org
> https://www.ietf.org/mailman/listinfo/alto
>
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

[alto] Agenda requests for ALTO 108

[Vijay Gurbani]

All: The ALTO session is scheduled on Mon, Jul 27 @ 14:10-15:50 UTC.  We
have 100 minutes for the session.

We will like to structure the session such that approximately half of the
time is devoted to re-charter discussions and the remaining half to the
status of WG drafts.  Accordingly, please send Jan and me your agenda
requests in the following format:

Name of draft:
Name of presenter:
Presentation time requested:
Link to I-D:

After we have accommodated the working group drafts, we will allocate time
for individual drafts.

Please send us the agenda requests by the end of the day (US Central time),
July 14.

Thank you.
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] Question regarding voluntary nature of ALTO clients

[Vijay Gurbani]

Generally, the answer to the question of how a protocol is policed (or
enforced) is that it isn't (policed or enforced).  There is no "protocol
police" that will impose punitive measures on non-behaving clients.

Also generally speaking, well-behaving clients will have an automatic
incentive to continue to behave well since doing so benefits them in some
manner (shorter latencies, shorter download time, etc.).  Similarly, for
the server to disseminate bogus information (as you point in your email)
implies that the entire system will be unused since clients will not prefer
to use guidance that provides sub-optimal performance.  So from a
cost-effort point of view, the system reaches an equilibrium, whether or
not this is a unique Nash equilibrium or there are multiple Nash equilibria
is subject for an academic paper.  Clearly, if a client (or server) pursues
a dominant strategy and is greedy at all times, the value of the overall
system decreases.

Cheers,

- vijay

On Tue, Jul 7, 2020 at 1:44 PM Paulo Edgar Mendes Caldas <
a79...@alunos.uminho.pt> wrote:

> Good morning,
>
> I am currently doing investigative work regarding the ALTO protocol for my
> master's degree. I've been getting acquainted with the ALTO protocol and
> the problems it tries to solve via reading of the RFCs and drafts that have
> been published, but I've struggled to find a question to the following -
> does the ALTO system as a whole have a plan on how to guarantee that the
> clients act in good faith with the information they receive?
>
>  In particular, consider that a P2P application wishes to have ALTO
> guidance to pick between a number of potential number of peers, and thus
> queries for a multi-cost map for the pairs (source_pid, destination_pid)
> whose throughput and one-way-delay values are within a certain criteria. Is
> there anything preventing said client to then not prefer the pair whose
> routing cost is lowest? It would make sense that the ALTO server would
> prefer that the client would "be kind" and cooperate with the ISP and use
> the information in a way that is mutually beneficial, but what if the
> client only cares about client performance?
>
> I can only imagine one of the following solutions - there being some
> incentive mechanism, restricting the information to trustworthy partners,
> or deliberately manipulating non-routing-cost metric values to steer
> clients into a certain choice. The latter seems problematic as it breaks
> the transparency in layer cooperation and might damage the entire reason
> the system was created to begin with.
>
> Is there any work done in regards to ensuring client cooperative behavior?
>
> Kind regards,
>
> Paulo Caldas
> ___
> alto mailing list
> alto@ietf.org
> https://www.ietf.org/mailman/listinfo/alto
>
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] Finishing milestones: Status of drafts?

[Vijay Gurbani]

On Thu, Jul 2, 2020 at 1:01 PM Y. Richard Yang  wrote:

> Hi Vijay, Jan,
>
> Let me give some update on the performance metrics. [...] We will upload
> an update by the end of next week before the July 13 deadline.Do
>

Dear Richard: Thanks.  Do you think that the draft will be ready for WGLC
on Jul 13?  If not, what do you think is holding it up?

Thanks,

- vijay
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] Finishing milestones: Status of drafts?

[Vijay Gurbani]

On Thu, Jul 2, 2020 at 11:30 AM Randriamasy, Sabine (Nokia -
FR/Paris-Saclay)  wrote:

> Dear Vijay, Jan and all,
>
>
>
> Here are some updates regarding the Unified Property and Path Vector
> drafts.
>
>
> [...] We plan to submit an updated version by July 13th  on which we will
> request a WGLC.
>
>
Dear Sabine: OK, thanks.  Please do make sure that the draft is out by the
date indicated, or a couple of days earlier, so we can schedule a WGLC.
FYI: the ALTO meeting is scheduled for Mon, Jul 27.

Thanks,

- vijay
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

[alto] Finishing milestones: Status of drafts?

[Vijay Gurbani]

Folks: There are three drafts that we need to progress: path vector,
performance metrics, and unified properties.

Jan and I will like to get a clear idea from the authors of each of these
documents as to where things stand.

The WG list has been rather silent on progress on the drafts.  For unified
properties, Sabine had posted an email on Jun-10, but there has not been
anything else on that draft since.

Performance metrics saw some action on the WG list on May-17, but that is
it.

I don't see anything for path vector.

Can we kindly have the authors of the draft please put forward where they
are and whether the work is done enough to start WGLC on them.  Please do
so ASAP.

Thanks,

- vijay
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

[alto] Fwd: Nomcom 2020-2021 Second Call For Volunteers

[Vijay Gurbani]

All: Please see the email below from Barbara Stark, the 2020 Nomcom chair.
Nomcom is seeking volunteers.  If you have never served on a Nomcom before,
this is a good time to do so.  Thanks.

-- Forwarded message -
From: STARK, BARBARA H 
Date: Wed, Jun 10, 2020 at 4:51 PM
Subject: Fwd: Nomcom 2020-2021 Second Call For Volunteers
To: wgcha...@ietf.org 


Hi fellow chairs,
Would you mind sending this announcement on to your WGs and impress on them
how important it is? Especially if the WG’s AD is up for selection.
Thx,
Barbara


Begin forwarded message:

*From:* NomCom Chair 2020 
*Date:* June 10, 2020 at 1:55:21 PM CDT
*To:* IETF Announcement List 
*Cc:* "i...@ietf.org" 
*Subject:* *Nomcom 2020-2021 Second Call For Volunteers*

This is the second sending of the call for volunteers for the 2020-2021
NomCom.

I wanted to mention a few updates from the previous email (sent 2 weeks
ago):
- I've fixed the URL at the bottom of the email to point to
https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_nomcom_2020_=DwIDaQ=LFYZ-o9_HUMeMTSQicvjIg=LoGzhC-8sc8SY8Tq4vrfog=ZsNIRqCxjDeOYYDNalOSHcuwQG23wBJtxzmEnsbPBtI=NgIu-7Ij0nEdsFcbJOLcl2M56RxyREhLAtcaHLatD34=
 instead of /2019/. This was a test to see if anyone was paying attention.
Apparently, some people were. ;)
- The IETF 108 registration form includes a checkbox that will let you
volunteer. You can use this instead of emailing me, when you register for
IETF 108.
- I currently have 39 volunteers. Last year had 149. I need more volunteers!
-
The IETF NomCom appoints people to fill the open slots on the LLC, IETF
Trust, the IAB, and the IESG.

Ten voting members for the NomCom are selected in a verifiably random way
from a pool of volunteers. The more volunteers, the better chance we have
of choosing a random yet representative cross section of the IETF
population.

The details of the operation of the NomCom can be found in BCP 10 (RFC
8713). RFC 3797 details the selection algorithm.

Special for this year (and only this year), we also have RFC 8788 (one-off
update to RFC 8713 / BCP 10) to tell us who is eligible to volunteer:

 Members of the IETF community must have attended at least three of
 the last five in-person IETF meetings in order to volunteer.

 The five meetings are the five most recent in-person meetings that
 ended prior to the date on which the solicitation for NomCom
 volunteers was submitted for distribution to the IETF community.
 Because no IETF 107 in-person meeting was held, for the 2020-2021
 Nominating Committee those five meetings are IETFs
   102 [Montreal, Canada; July 2018],
   103 [Bangkok, Thailand; November 2018],
   104 [Prague, Czech Republic; March 2019],
   105 [Montreal, Canada; July 2019], and
   106 [Singapore; November 2019].

Keep in mind that eligibility is based on in-person attendance at the five
listed meetings. You can check your eligibility at:
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_registration_nomcom.py=DwIDaQ=LFYZ-o9_HUMeMTSQicvjIg=LoGzhC-8sc8SY8Tq4vrfog=ZsNIRqCxjDeOYYDNalOSHcuwQG23wBJtxzmEnsbPBtI=7_9x9PPoUIajJs2AnUFYg0KnEg8gkD3Jnwf1v079EQo=
..

If you qualify, please volunteer. Before you decide to volunteer, please
remember that anyone appointed to this NomCom will not be considered as a
candidate for any of the positions that the 2020 - 2021 NomCom is
responsible for filling.

People commonly volunteer by ticking the box on IETF registration forms.
The IETF 106 form did not ask whether people were willing to volunteer.
IETF 107 did ask, but all those registrations were canceled. I have asked
the Secretariat if it is possible to get the list if volunteers from
canceled IETF 107 registrations. If that list is available, I will contact
all who are verified as eligible. But given the uncertainty of this
process, I would encourage people to volunteer directly (see the bottom of
this email for instructions). Thank you for volunteering!

The list of people and posts whose terms end with the March 2021 IETF
meeting, and thus the positions for which this NomCom is responsible, are

IETF Trust:
   Joel Halpern

LLC:
   Maja Andjelkovic

IAB:
   Jari Arkko
   Jeff Tantsura
   Mark Nottingham
   Stephen Farrell
   Wes Hardaker
   Zhenbin Li

IESG:
   Alissa Cooper, IETF Chair/GEN AD
   Alvaro Retana, RTG AD
   Barry Leiba, ART AD
   Deborah Brungard, RTG AD
   Éric Vyncke, INT AD
   Magnus Westerlund, TSV AD
   Roman Danyliw, SEC AD
   Warren Kumari, OPS AD

All appointments are for 2 years. The Routing area has 3 ADs and the
General area has 1; all other areas have 2 ADs. Thus, all areas (that have
more than one AD) have at least one continuing AD.

The primary activity for this NomCom will begin in July 2020 and should be
completed in January 2021.  The NomCom will have regularly scheduled
conference calls to ensure progress. There will 

[alto] IETF 108 to occur online

[Vijay Gurbani]

Folks: FYI...

Begin forwarded message:

*From: *IETF Chair 
*Subject: **IETF 108 will be an online meeting*
*Date: *May 14, 2020 at 4:07:47 PM CDT
*To: *IETF-Announce , irtf-annou...@irtf.org, IETF <
i...@ietf.org>
*Reply-To: *IETF 

The Internet Engineering Steering Group (IESG), the IETF LLC Board of
Directors, and the Internet Research Task Force (IRTF) Chair have decided
to replace the in-person IETF 108 Madrid meeting with an online meeting.
This decision is based on the IETF Executive Director’s recommendation,
which was made after conducting an assessment of local conditions using the
criteria set out in the assessment framework [1] developed with community
input.

The recommendation and full assessment are available at:
https://www.ietf.org/media/documents/IETF_108_Madrid_go_no-go_assessment.pdf

The online IETF 108 meeting will take place 27-31 July from 11:00 to 16:00
UTC each day. The end time of 16:00 UTC is approximate; some days may be
shorter depending on scheduling. These time blocks were chosen based on the
survey feedback [2] we received.

Further details about the online meeting will be shared as they become
available.

Sincerely,
Alissa Cooper, IETF Chair
Colin Perkins, IRTF Chair
Jason Livingood, IETF LLC Board Chair

[1]
https://www.ietf.org/blog/assessment-criteria-decision-personvirtual-ietf-108/?
[2]
https://www.ietf.org/media/documents/survey-planning-possible-online-meetings-responses.pdf
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

[alto] Draft minutes for ALTO 107 meeting

[Vijay Gurbani]

All: The draft minutes from Tuesday's alto meeting are in [1].  Also in [1]
is the YouTube URL to the WebEx recording.

Please let me and Jan know if you have any questions on the minutes.

Thanks to Qiao Xiang and Sabine Randriamasy for taking notes.

[1]
https://datatracker.ietf.org/meeting/interim-2020-alto-01/materials/minutes-interim-2020-alto-01-202004210700

Have a nice weekend.
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

[alto] Thank you all for a successful meeting

[Vijay Gurbani]

We ran a bit over.

Note takers, please send Jan and me your notes.  The Etherpad that contains
the running commentary (or notes?) from the meeting is at [1] if that will
help jog your memory.

Thanks, and stay safe.

[1]
https://etherpad.ietf.org:9009/p/notes-ietf-interim-2020-alto-01?useMonospaceFont=true
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

[alto] Note takers for tomorrow's meeting

[Vijay Gurbani]

All: We need two note takers for tomorrow's meeting.  Please send an email
to Jan and me if you would like to volunteer.

Since the meeting is entirely online and only accessible through WebEx, we
can probably monitor the WebEx chat instead of having to monitor an
additional Jabber session.  So, one of the chairs can monitor the chat
session, but we do need note takers.

Thanks,

- vijay
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

[alto] Slides for tomorrow's meeting

[Vijay Gurbani]

All: Please upload the PDF slides for tomorrow's meeting.  So far we only
have a couple of slides.
If you have a datatracker account, you can upload the slides yourself.

Thanks,

- vijay
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

[alto] Draft agenda updated and PDFs for meeting next week

[Vijay Gurbani]

All: The draft agenda for the ALTO virtual has been updated; please see [1].

Also, please start uploading the PDFs for the meeting.  If you have a
datatracker account, you should be able to upload the PDF yourself.  If you
don't please send the PDF to me and Jan.

[1] https://datatracker.ietf.org/doc/agenda-interim-2020-alto-01-alto-01/

See you all on Tue next week.

Cheers,

- vijay
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

[alto] WebEx information for ALTO Virtual IETF 107

[Vijay Gurbani]

All: Here is the information for our upcoming ALTO virtual meeting next
week.

ALTO IETF 107 Virtual Interim
Hosted by ALTO Working Group
7:00 AM - 9:00 AM Tuesday, Apr 21 2020 Central Time (US & Canada)

Meeting Information

Meeting link:
https://ietf.webex.com/ietf/j.php?MTID=md74897741106039a070365f7b72476cf
Meeting number: 615 339 406
Password: 968MVfnsKCz

Join by video system
Dial 615339...@ietf.webex.com
You can also dial 173.243.2.68 and enter your meeting number.

Join by phone
1-650-479-3208 Call-in number (US/Canada)
1-877-668-4493 Call-in toll free number (US/Canada)
Access code: 615 339 406
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] Draft agenda for IETF 107 virtual interim

[Vijay Gurbani]

Dear Sabine: I am no aware of any specific deadline, however, as always,
please make sure that your draft has been submitted at least two weeks
before our virtual meeting date to give the WG some time to look at it.

Thanks,

- vijay

On Fri, Mar 20, 2020 at 6:19 AM Randriamasy, Sabine (Nokia -
FR/Paris-Saclay)  wrote:

> Hi Vijay,
>
>
>
> Thanks a lot for the agenda. As the ID submission tool was re-opened
> pursuant to the F2F IETF107 cancellation, is there any new deadline to
> submit new versions for the drafts to be presented?
>
> Thanks,
>
> Sabine
>
>
>
>
>
> *From:* alto  *On Behalf Of *Vijay Gurbani
> *Sent:* Thursday, March 19, 2020 5:37 PM
> *To:* IETF ALTO 
> *Subject:* [alto] Draft agenda for IETF 107 virtual interim
>
>
>
> All: The draft agenda for the virtual interim is at
> https://datatracker.ietf.org/doc/agenda-interim-2020-alto-01-alto-01/
>
>
>
> If anyone sent Jan and me an agenda request that is not reflected in the
> agenda, please let us know.
>
>
>
> Thanks,
>
>
>
> - vijay
>
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

[alto] Draft agenda for IETF 107 virtual interim

[Vijay Gurbani]

All: The draft agenda for the virtual interim is at
https://datatracker.ietf.org/doc/agenda-interim-2020-alto-01-alto-01/

If anyone sent Jan and me an agenda request that is not reflected in the
agenda, please let us know.

Thanks,

- vijay
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] ALTO Interim in lieu of IETF 107

[Vijay Gurbani]

All: Thanks for expressing your preference on the list.

The tally I get from the responses is below, and from this, Option 1 seems
to be the best.  We will go ahead and schedule an interim for Apr 21, 2020
7:00 AM US Central.

Option 1 (7:00am US Central / 5:00am US Pacific).  That option had 7 votes.

The next highest (6 votes) are for 9:00am US Central / 7:00am US Pacific
Time and 11:00am US Central / 9:00am US Pacific.

Thanks,

- vijay


*From:* alto  *On Behalf Of *Vijay Gurbani

> *Sent:* Friday, March 13, 2020 6:59 PM
> *To:* IETF ALTO 
> *Subject:* [alto] ALTO Interim in lieu of IETF 107
>
>
>
> All: The IESG has been working on coming up with a virtual interim
> schedule for WGs that would have met in Vancouver.  As the original
> schedule avoided WG and RG conflicts to the maximum extent possible, the
> virtual interim schedule has been created so that working groups and
> research groups can be reasonably sure that most participants will not have
> a conflict with another IETF interim meeting on the same day.
>
>
>
> For ALTO, IESG has suggested Tue, Apr 21.  We will plan to hold a virtual
> interim on that day.  While we can decide another day besides the IESG
> suggested one, I would hesitate to do so for a variety of reasons, the most
> important of which is that we will have to ensure that our chosen day does
> not conflict with other WGs, BoFs, and RGs, that WG list members may be
> interested in.  Thus, it seems safe to stay with the IESG suggested date of
> Apr 21, as that date has honored all of the WG/RG conflicts with ALTO.
>
>
>
> What we need to do soon (48 hours or so) is to agree on a specific time
> for Apr 21 so Jan and I can set the wheels in motion to schedule the
> virtual interim on Apr 21.
>
>
>
> Here are the options, please reply with your preferred option on the
> list.  Jan and I will collect all of the responses we receive by Sunday
> night, and choose the one that is most frequent by Mon AM.  I know Europe
> has not yet changed their clocks, so I will leave the times below in US
> Central time zone (which is now on daylight savings time).  So please
> adjust accordingly for your locale.  All times are for Apr 21, 2020.
>
>
>
> 0. 5:00am - 7:00am US Central
>
> 1. 7:00am - 9:00am US Central
>
> 2. 9:00am - 11:00am US Central
>
> 3. 11:00am - 1:00pm US Central
>
> 4. 1:00pm - 3:00pm US Central
>
> 5. 3:00pm - 5:00pm US Central
>
> 6. 5:00pm - 7:00 pm US central *
>
> 7. 7:00pm - 9:00pm US central *
>
> 8. 9:00pm - 11:00pm US Central  *
>
>
>
> * I will not be able to make these timeslots as they overlap with the
> class I teach.
>
>
>
> Thank you,
>
>
>
> - vijay
>
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

[alto] ALTO Interim in lieu of IETF 107

[Vijay Gurbani]

All: The IESG has been working on coming up with a virtual interim schedule
for WGs that would have met in Vancouver.  As the original schedule avoided
WG and RG conflicts to the maximum extent possible, the virtual interim
schedule has been created so that working groups and research groups can be
reasonably sure that most participants will not have a conflict with
another IETF interim meeting on the same day.

For ALTO, IESG has suggested Tue, Apr 21.  We will plan to hold a virtual
interim on that day.  While we can decide another day besides the IESG
suggested one, I would hesitate to do so for a variety of reasons, the most
important of which is that we will have to ensure that our chosen day does
not conflict with other WGs, BoFs, and RGs, that WG list members may be
interested in.  Thus, it seems safe to stay with the IESG suggested date of
Apr 21, as that date has honored all of the WG/RG conflicts with ALTO.

What we need to do soon (48 hours or so) is to agree on a specific time for
Apr 21 so Jan and I can set the wheels in motion to schedule the virtual
interim on Apr 21.

Here are the options, please reply with your preferred option on the list.
Jan and I will collect all of the responses we receive by Sunday night, and
choose the one that is most frequent by Mon AM.  I know Europe has not yet
changed their clocks, so I will leave the times below in US Central time
zone (which is now on daylight savings time).  So please adjust accordingly
for your locale.  All times are for Apr 21, 2020.

0. 5:00am - 7:00am US Central
1. 7:00am - 9:00am US Central
2. 9:00am - 11:00am US Central
3. 11:00am - 1:00pm US Central
4. 1:00pm - 3:00pm US Central
5. 3:00pm - 5:00pm US Central
6. 5:00pm - 7:00 pm US central *
7. 7:00pm - 9:00pm US central *
8. 9:00pm - 11:00pm US Central  *

* I will not be able to make these timeslots as they overlap with the class
I teach.

Thank you,

- vijay
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

[alto] Agenda requests

[Vijay Gurbani]

All:

By now, I am sure everyone knows that the Vancouver meeting has been
cancelled.  The IESG will provide some clarity soon on when the various
working groups can meet virtually.

Just so we keep the momentum going, please send me and Jan your agenda
requests; so far we have only received two agenda requests (one from Hans
Siedel and one from Chunshan Xiong).  We will like to put together an
agenda in anticipation for a virtual meeting.  Please send me and Jan your
agenda requests by end of the day Friday.  As usual, precedence will be
given to WG chartered items.

In your agenda request, please indicate:

Length of presentation time:
Name of presenter:
Related I-D:

Thank you,

- vijay
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

[alto] IETF 107 in person cancelled

[Vijay Gurbani]

All: You may have heard already, IETF 107 has been cancelled, see [1].

The IESG is working on an alternative all-virtual agenda for the week of
March 21-27 with a limited schedule adapted to accommodate the time zones
of as many participants as possible.

In the meantime, please continue sending Jan and me your agenda requests as
the IESG figures out the next steps for an all-virtual agenda.

[1]
https://mailarchive.ietf.org/arch/msg/ietf-announce/XenAlx4Nw6Jmg69QpXRUOwbzsXY/

Thanks,

- vijay
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] Secdir last call review of draft-ietf-alto-cost-calendar-17

[Vijay Gurbani]

Dear Richard: I will suggest a couple of minor modifications:

New paragraph:

>
>   The operator should be should be cognizant that the preceding mechanisms
>do not address all security risks. In particular, they will not help in
>the case of “malicious clients” possessing valid credentials to
>authenticate. The threat here can be that legitimate clients have
>become subverted by an attacker and are now ‘bots’ being asked to
>participate in a DDoS attack. The Calendar information would be valuable
>information for when to persecute a DDoS attack. A mechanism such as
>a monitoring system that detects abnormal behaviors may still be
> needed."
>

Suggested changes:
  The operator should be should be cognizant that the preceding mechanisms
   do not address all security risks. In particular, they will not help in
   the case of “malicious clients” possessing valid authentication
credentials.
   The threat here is that legitimate clients have become subverted by an
attacker
   and are now ‘bots’ being asked to participate in a DDoS attack. The
Calendar
   information now becomes valuable in knowing exactly when to perpetrate a
DDoS
  attack.  A mechanism such as a monitoring system that detects abnormal
  behaviors may still be needed.

Cheers,

- vijay

[ Trimmed the Cc list to avoid email explosion on a minor change. ]
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

[alto] WGLC over for CDNI

[Vijay Gurbani]

All: The WGLC [1] for the ALTO CDNI draft is now over.  The draft received
two reviews [2,3] during the WGLC period.  The authors are requested to
prepare a revision based on the reviews.  The draft can move ahead once the
revision is submitted.

[1] https://mailarchive.ietf.org/arch/msg/cdni/gjpYSELvH2SprFSoBCD2QbrlU00/
[2] https://mailarchive.ietf.org/arch/msg/cdni/-gaZKrUBnC43RyMOeaf_MtdiLa8/
[3] https://mailarchive.ietf.org/arch/msg/cdni/keqftt-bvNZQZxHQBSADlJVkIg8/

Thanks,

- vijay
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

[alto] Publication has been requested for draft-ietf-alto-incr-update-sse-19

[Vijay Gurbani via Datatracker]

Vijay Gurbani has requested publication of draft-ietf-alto-incr-update-sse-19 
as Proposed Standard on behalf of the ALTO working group.

Please verify the document's state at 
https://datatracker.ietf.org/doc/draft-ietf-alto-incr-update-sse/

___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] draft-ietf-alto-incr-update-sse and IDNITS

[Vijay Gurbani]

Dear Richard: Thank you.  It looks good.  Let me continue the draft's
movement ahead.  Thanks for an expeditious turnaround.
Cheers,
- vijay

On Thu, Feb 13, 2020 at 1:03 PM Y. Richard Yang  wrote:

> Dear Vijay,
>
> We have taken a pass of the draft to fix the IDNITS warnings. A new
> version is posted:
> https://datatracker.ietf.org/doc/draft-ietf-alto-incr-update-sse/
>
> Thank you so much!
> Richard
>
>
> On Mon, Feb 10, 2020 at 12:39 PM Vijay Gurbani 
> wrote:
>
>> Authors: I am done with the shepherd writeup of this draft, I will post
>> the writeup in a separate email.
>>
>> However, on running IDNITS, I see a number of problems.  Two that need
>> fixing are:
>> 1) Please divide the references into INFORMATIVE and NORMATIVE.
>> 2) From idnits: -- Found something which looks like a code comment -- if
>> you have code
>>  sections in the document, please surround them with ''
>> and
>>  '' lines.
>>
>> and there are a few other warnings.
>>
>> Can you please fix IDNITS warnings and errors and generate a new
>> version?  As soon as you do so, I will press the button to send to IESG.
>>
>> Thanks,
>>
>> - vijay
>>
>
>
> --
> --
>  =
> | Y. Richard Yang|
> | Professor of Computer Science   |
> | http://www.cs.yale.edu/~yry/|
>  =
>
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

[alto] Shepherd writeup for SSE

[Vijay Gurbani]

Folks: The shepherd writeup of SSE is below.  As soon as the authors have
worked the IDNITS bugs, I will move the draft ahead.  In the meantime, if
anything in the shepherd's writeup need changing, please let me know.

Cheers,

- vijay
--
1. Summary

The document shepherd is Vijay K. Gurbani. The responsible Area Director is
Mirja Kuehlewind.

This document allows the base ALTO protocol (RFC 7785) to fetch resources
that
have changed in a more optimized manner.

In base ALTO, a client must periodically re-fetch resources that have
changed.
Some resources served by an ALTO server (network maps, for instance) may be
quite large, while the changes to the resources may be fairly localized,
and can
be served in an optimal manner (sending diffs, for instance) instead of
having
the client fetch the entire updated resource.

This document adds the capability of sending localized diffs in ALTO.

This document is targeted as a Standards Track document (Proposed Standard).
This designation is appropriate as the document contains normative behaviour
and message formats that should be adhered to by the communicating entities
in order to realize the extension.

2. Review and Consensus

ALTO incremental updates is a well known work to the ALTO working group.
The
initial work on this started in October 2014; the working group adopted the
work
in May 2015 [1], after which it has gone through about 19 revisions to the
current
version.  The work is fairly mature and the design tradeoffs in coming up
with an
equitable solution to the problem described above are well documented in the
draft.

The first WGLC on version -02 of the draft was held on Jul-2016 [2] and was
reviewed by Mingming Chen and Sebastial Kiesel.  However, it was pointed out
[3] after the WGLC ended that the draft could be made far more general if it
supported additional incremental update encoding options.  The draft,
therefore,
continued its journey within the WG instead of being sent out to the IESG.
At
IETF 99, a hum was taken on whether we should proceed to WGLC on version -07
[4], but the hum did not reach any hard conclusion and the work proceeded
in the
WG.

In an interim ALTO meeting held on Dec-18-2017, the authors indicated that
they
were still working on the draft [5].  A second WGLC was held on Jun-20-2018
[6],
and was reviewed by three WG members (Dawn Chan, Kerim Gokarslan and
Isabelle
Carson).  Pursuant to the WGLC, version -11 was released with updates,
shortly
followed by version -13.  It was determined that version -13 had some
substantive changes in it that it may help in further review from the WG
[7].
Between 2018 and the issuance of a third WGLC on Nov-14-2019 [8], work
progressed on the document.  The third WGLC resulted in review of the work
by
Jensen Zhang and me.

There is one known implementation of this draft, this implementation is
related
to a paper titled "Steering Hyper-Giant's Traffic at Scale",  published in
the
proceedings of ACM CoNEXT 2019 [9].  This implementation implements the JSON
merge patch feature, with the general JSON patch being on their roadmap
[10].

[1] https://mailarchive.ietf.org/arch/msg/alto/1nLabIj25PJz3M0SOuXAAdLlSBs
[2] https://mailarchive.ietf.org/arch/msg/alto/mnuzhFkDTBDTuRMSDIV2GKXk96A
[3] https://mailarchive.ietf.org/arch/msg/alto/XgvZXhr0PsqAU8CGfEwel1ClIBM
[4] https://mailarchive.ietf.org/arch/msg/alto/t_xHbbGE2g51LqI8cfnyIkwt0J4
[5]
https://datatracker.ietf.org/meeting/interim-2017-alto-01/materials/minutes-interim-2017-alto-01-201712180600/
[6] https://mailarchive.ietf.org/arch/msg/alto/NNrG6P7MjRW1GwYbIJFUDi1089k
[7] https://mailarchive.ietf.org/arch/msg/alto/T8NOGMtb_kRrxJtsE0ToosR-JC4
[8] https://mailarchive.ietf.org/arch/msg/alto/hHM_bC1CfwygcxTTm96zBbj7gmo
[9] https://mailarchive.ietf.org/arch/msg/alto/h7QJRu47NbTvfcnW2fveFqCBRdw
[10] https://mailarchive.ietf.org/arch/msg/alto/9IOwXNAxqKp_CwKUPsu54W4lB08

3. Intellectual Property

The entire author team has confirmed conformance with BCP 78/79 with the
shepherd.

4. Other Points
IDNITS reports problems.  Sending these to the author team.  Waiting an
updated
version.
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

[alto] draft-ietf-alto-incr-update-sse and IDNITS

[Vijay Gurbani]

Authors: I am done with the shepherd writeup of this draft, I will post the
writeup in a separate email.

However, on running IDNITS, I see a number of problems.  Two that need
fixing are:
1) Please divide the references into INFORMATIVE and NORMATIVE.
2) From idnits: -- Found something which looks like a code comment -- if
you have code
 sections in the document, please surround them with '' and
 '' lines.

and there are a few other warnings.

Can you please fix IDNITS warnings and errors and generate a new version?
As soon as you do so, I will press the button to send to IESG.

Thanks,

- vijay
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] RFC 8686 vs. RFC 6708

[Vijay Gurbani]

Congratulations!!  We should let Enrico know :-)

On Thu, Feb 6, 2020, 4:23 PM Sebastian Kiesel  wrote:

> Dear ALTO WG,
>
> RFC 8686 "ALTO Cross-Domain Server Discovery"
> (was: draft-ietf-alto-xdom-disc-06) has just been published.
>
> Thanks to all contributors, reviewers, and all others who helped
> to make that happen!
>
>
>
> *looking in my closet for that old and dusty hat that I haven't worn in
> a long time, the one with the "ALTO requirements document editor" badge*
>
> Ladies and gentlemen,
>
> almost 12 years after the IETF P2PI workshop and the subsequent
> inception of the ALTO working group, the RFC editor has published
> RFC 8686 today. This specification, called "ALTO Cross-Domain Server
> Discovery" addresses requirements 33, 35, and 36 from RFC 6708,
> the ALTO Requirements document published in 2012. These were the last
> outstanding requirements, in other words: we have reached our initial
> goals (and of course various additional ones that emerged later).
> A big thank you to everyone who contributed! Looking forward to see many
> new ALTO use cases and protocol extensions.
>
> Thanks,
> Sebastian
>
> - Forwarded message from rfc-edi...@rfc-editor.org -
>
> Date: Thu,  6 Feb 2020 14:06:49 -0800 (PST)
> From: rfc-edi...@rfc-editor.org
> To: ietf-annou...@ietf.org, rfc-d...@rfc-editor.org
> Cc: drafts-update-...@iana.org, alto@ietf.org, rfc-edi...@rfc-editor.org
> Subject: [alto] RFC 8686 on Application-Layer Traffic Optimization (ALTO)
> Cross‑Domain Server Discovery
>
> A new Request for Comments is now available in online RFC libraries.
>
>
> RFC 8686
>
> Title:  Application-Layer Traffic Optimization (ALTO)
> Cross‑Domain Server Discovery
> Author: S. Kiesel,
> M. Stiemerling
> Status: Standards Track
> Stream: IETF
> Date:   February 2020
> Mailbox:ietf-a...@skiesel.de,
> mls.i...@gmail.com
> Pages:  34
> Updates/Obsoletes/SeeAlso:   None
>
> I-D Tag:draft-ietf-alto-xdom-disc-06.txt
>
> URL:https://www.rfc-editor.org/info/rfc8686
>
> DOI:10.17487/RFC8686
>
> The goal of Application-Layer Traffic Optimization (ALTO) is to
> provide guidance to applications that have to select one or several
> hosts from a set of candidates capable of providing a desired
> resource.  ALTO is realized by a client-server protocol.  Before an
> ALTO client can ask for guidance, it needs to discover one or more
> ALTO servers that can provide suitable guidance.
>
> In some deployment scenarios, in particular if the information about
> the network topology is partitioned and distributed over several ALTO
> servers, it may be necessary to discover an ALTO server outside of
> the ALTO client's own network domain, in order to get appropriate
> guidance.  This document details applicable scenarios, itemizes
> requirements, and specifies a procedure for ALTO cross-domain server
> discovery.
>
> Technically, the procedure specified in this document takes one
> IP address or prefix and a U-NAPTR Service Parameter (typically,
> "ALTO:https") as parameters. It performs DNS lookups (for NAPTR
> resource records in the "in-addr.arpa." or "ip6.arpa." trees) and
> returns one or more URIs of information resources related to that IP
> address or prefix.
>
> This document is a product of the Application-Layer Traffic Optimization
> Working Group of the IETF.
>
> This is now a Proposed Standard.
>
> STANDARDS TRACK: This document specifies an Internet Standards Track
> protocol for the Internet community, and requests discussion and
> suggestions
> for improvements.  Please refer to the current edition of the Official
> Internet Protocol Standards (https://www.rfc-editor.org/standards) for
> the
> standardization state and status of this protocol.  Distribution of this
> memo is unlimited.
>
> This announcement is sent to the IETF-Announce and rfc-dist lists.
> To subscribe or unsubscribe, see
>   https://www.ietf.org/mailman/listinfo/ietf-announce
>   https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist
>
> For searching the RFC series, see https://www.rfc-editor.org/search
> For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk
>
> Requests for special distribution should be addressed to either the
> author of the RFC in question, or to rfc-edi...@rfc-editor.org.  Unless
> specifically noted otherwise on the RFC itself, all RFCs are for
> unlimited distribution.
>
>
> The RFC Editor Team
> Association Management Solutions, LLC
>
>
> ___
> alto mailing list
> alto@ietf.org
> https://www.ietf.org/mailman/listinfo/alto
>
> - End forwarded message -
>
> ___
> alto mailing list
> alto@ietf.org
> https://www.ietf.org/mailman/listinfo/alto
>
___
alto 

[alto] WGLC for draft-ietf-alto-cdni-request-routing-alto-09

[Vijay Gurbani]

All: Jan and I will like to start WGLC for
draft-ietf-cdni-request-routing-alto-09.  The WGLC period will run from
Mon,
Feb 3 2020 to Wed, Feb 19 2020.

This email is also being cross-posted to the CDNI working group.

We will like to have one WG list member from ALTO and one WG list member
from
CDNI review this draft in depth.  Please send Jan and me an email if you
are willing
review the draft as part of WGLC.

In addition, we will like general reviews of the draft from both ALTO and
CDNI WGs.

Thank you.
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] I-D Action: draft-ietf-alto-incr-update-sse-18.txt

[Vijay Gurbani]

Dear Jensen and Richard: Very well.  I will look at the modifications and
start the roll out next week to move the work ahead.
Thank you for attending to this.
Cheers,
- vijay

On Thu, Jan 23, 2020 at 5:35 PM Jensen Zhang 
wrote:

> Dear Vijay, Jan and ALTO WG,
>
> After some good discussions with Richard, we worked together and finished
> the latest revision (-18) of the SSE document. The revision addresses
> issues from Vijay's and my previous feedbacks [1][2] with updates as listed
> below.
>
> - Clarified terminologies
>   - Defined Substeam-ID and Data-ID in Section 3 before they are first
> used in Section 6
>   - Updated section 6.1 and section 6.2 to make the format of data type
> SubstreamID clear
> - Extended examples
>   - Added a new example to illustrate how SSE provides updates for the
> ALTO resource returning a multipart response
> - Updated recommendations in the consideration section
>   - Renamed Section 10.1 to "Considerations for SSE Text Formatting and
> Processing" and moved it to the end of Section 10
>   - According to Vijay's comment, rewrote the considerations for SSE text
> formatting and processing from both viewpoints of the client and the server
> - Fixed nits and accepted rewording suggestions from WG reviews
>
> As Richard suggested, I was added as a contributor to the latest revision.
> Thanks, Richard!
>
> We would like to say the current SSE document is ready to go. If you have
> any suggestions, please feel free to tell us. Any feedback will be welcomed.
>
> [1] https://mailarchive.ietf.org/arch/msg/alto/-6AhxLa8o409o2k2gv5fXd9-6g4
> [2] https://mailarchive.ietf.org/arch/msg/alto/C9_tS44bz7kq84Z3cpZZkMeUDFc
>
> Cheers,
> Jensen
>
> On Thu, Jan 23, 2020 at 6:00 PM Y. Richard Yang  wrote:
>
>> Dear ALTO group,
>>
>> Thanks to the wonderful guidance and feedback from many, in particular,
>> our chair, Luis, and others, we have made one pass of the draft and are
>> pretty happy about the document. Jensen will send a summary of changes
>> shortly. Although it is past the last call, if you do see any issues or
>> have any suggestions on edit, we, of course, welcome them.
>>
>> Cheers,
>> Richard
>>
>> On Thu, Jan 23, 2020 at 5:51 PM  wrote:
>>
>>>
>>> A New Internet-Draft is available from the on-line Internet-Drafts
>>> directories.
>>> This draft is a work item of the Application-Layer Traffic Optimization
>>> WG of the IETF.
>>>
>>> Title   : ALTO Incremental Updates Using Server-Sent
>>> Events (SSE)
>>> Authors : Wendy Roome
>>>   Y. Richard Yang
>>> Filename: draft-ietf-alto-incr-update-sse-18.txt
>>> Pages   : 54
>>> Date: 2020-01-23
>>>
>>> Abstract:
>>>The Application-Layer Traffic Optimization (ALTO) [RFC7285] protocol
>>>provides network related information, called network information
>>>resources, to client applications so that clients can make informed
>>>decisions in utilizing network resources.  For example, an ALTO
>>>server can provide network and cost maps so that an ALTO client can
>>>use the maps to determine the costs between network endpoints when
>>>choosing communicating endpoints.
>>>
>>>However, the ALTO protocol does not define a mechanism to allow an
>>>ALTO client to obtain updates to the information resources, other
>>>than by periodically re-fetching them.  Because some information
>>>resources (e.g., the aforementioned maps) may be large (potentially
>>>tens of megabytes), and because only parts of the information
>>>resources may change frequently (e.g., only some entries in a cost
>>>map), complete re-fetching can be extremely inefficient.
>>>
>>>This document presents a mechanism to allow an ALTO server to push
>>>updates to ALTO clients, to achieve two benefits: (1) updates can be
>>>immediate, in that the ALTO server can send updates as soon as they
>>>are available; and (2) updates can be incremental, in that if only a
>>>small section of an information resource changes, the ALTO server can
>>>send just the changes.
>>>
>>>
>>>
>>> The IETF datatracker status page for this draft is:
>>> https://datatracker.ietf.org/doc/draft-ietf-alto-incr-update-sse/
>>>
>>> There are also htmlized versions available at:
>>> https://tools.ietf.org/html/draft-ietf-alto-incr-update-sse-18
>>> https://datatracker.ietf.org/doc/html/draft-ietf-alto-incr-update-sse-18
>>>
>>> A diff from the previous version is available at:
>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-alto-incr-update-sse-18
>>>
>>>
>>> Please note that it may take a couple of minutes from the time of
>>> submission
>>> until the htmlized version and diff are available at tools.ietf.org.
>>>
>>> Internet-Drafts are also available by anonymous FTP at:
>>> ftp://ftp.ietf.org/internet-drafts/
>>>
>>> ___
>>> alto mailing list
>>> alto@ietf.org
>>> 

Re: [alto] Expiration impending:

[Vijay Gurbani]

Authors: This draft is about to expire.  While resurrecting it is easy, I
will note that there has not been much discussion on the WGLC review [1]
and the chair review [2] from the author team.

Could the author team please attend to the reviews as soon as possible?  Or
let us know when to expect a revision.  Thank you for your work in making
sure that the remaining WG items are completed.

[1] https://mailarchive.ietf.org/arch/msg/alto/C9_tS44bz7kq84Z3cpZZkMeUDFc
[2] https://mailarchive.ietf.org/arch/msg/alto/-6AhxLa8o409o2k2gv5fXd9-6g4

- vijay

On Mon, Jan 20, 2020 at 6:42 AM IETF Secretariat <
ietf-secretariat-re...@ietf.org> wrote:

> The following draft will expire soon:
>
> Name: draft-ietf-alto-incr-update-sse
> Title:ALTO Incremental Updates Using Server-Sent Events (SSE)
> State:I-D Exists
> Expires:  2020-01-24 (in 3 days, 19 hours)
>
>
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] Chair review of draft-ietf-alto-incr-update-sse-17

[Vijay Gurbani]

Very well, please do file a request for agenda items once the email goes
out for Vancouver. Thanks.

On Wed, Jan 8, 2020, 7:06 AM Hans Seidel  wrote:

> Hi Vijay,
>
> perfect. I am looking forward to present in Vancouver. Among
> implementation insights, we also happily share information about lessons
> learned and rolling out ALTO with partners.
>
> I will file an agenda request for the Vancouver session once asked for on
> the list.
>
> Thanks,
> Hans
> On 07.01.20 17:35, Vijay Gurbani wrote:
>
> Dear Hans: Thank you for your email.  At this point, I am interested in
> getting as much information about the implementation of the Internet-Draft
> as possible in preparation for moving the work ahead in the WG.  Certainly,
> I will be happy to allocate you some agenda time in Vancouver to document
> any lessons learned on implementing alto-sse.  If you are interested,
> please let me know.
>
> If anyone else on the list has any implementation of alto-sse, please let
> me know as well.
>
> Thanks,
> - vijay
>
> On Tue, Jan 7, 2020 at 10:26 AM Hans Seidel  wrote:
>
>> Hi Vijay,
>>
>> let me answer this question for Ingmar. Currently implemented is the JSON
>> merge patch feature. JSON patch is on our roadmap. We aim for a release
>> that is fully compatible with the latest draft prior to the Vancouver IETF
>> which I also plan to attend. Once the RFC is published, we are going to use
>> SSE in production with our partners.
>>
>> If you or somebody on the list has an ALTO implementation and is
>> interested in running tests, feel free to contact us.
>>
>> If you like to know more, feel free to ask. We also happily give further
>> insights in our SSE implementation, or our ALTO implementation in general
>> in Vancouver. If you or the list is interested in specific parts, please
>> let us know and we prepare some slides for Vancouver.
>>
>
>
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] Chair review of draft-ietf-alto-incr-update-sse-17

[Vijay Gurbani]

Dear Hans: Thank you for your email.  At this point, I am interested in
getting as much information about the implementation of the Internet-Draft
as possible in preparation for moving the work ahead in the WG.  Certainly,
I will be happy to allocate you some agenda time in Vancouver to document
any lessons learned on implementing alto-sse.  If you are interested,
please let me know.

If anyone else on the list has any implementation of alto-sse, please let
me know as well.

Thanks,
- vijay

On Tue, Jan 7, 2020 at 10:26 AM Hans Seidel  wrote:

> Hi Vijay,
>
> let me answer this question for Ingmar. Currently implemented is the JSON
> merge patch feature. JSON patch is on our roadmap. We aim for a release
> that is fully compatible with the latest draft prior to the Vancouver IETF
> which I also plan to attend. Once the RFC is published, we are going to use
> SSE in production with our partners.
>
> If you or somebody on the list has an ALTO implementation and is
> interested in running tests, feel free to contact us.
>
> If you like to know more, feel free to ask. We also happily give further
> insights in our SSE implementation, or our ALTO implementation in general
> in Vancouver. If you or the list is interested in specific parts, please
> let us know and we prepare some slides for Vancouver.
>
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] Chair review of draft-ietf-alto-incr-update-sse-17

[Vijay Gurbani]

Dear Ingmar: This is great information, thanks.
Did you implement both JSON patch and JSON merge patch?
Thanks,
- vijay

On Mon, Jan 6, 2020 at 2:50 PM Ingmar Poese 
wrote:

> Hi Danny,
>
> We (BENOCS) have implemented the Alto SSE, but are lacking a partner to
> speak it to in production scale.
>
> In our testing environment it seems to work fine (even with production
> data).
>
> I was unable to attend Singapore, but will be available in vancouver (and
> possibly madrid) to chat/present the research.
>
> Best,
> Ingmar
>
> Am 6. Jan. 2020, 19:56, um 19:56, Danny Alex Lachos Perez <
> dlachos...@gmail.com> schrieb:
> >Hello Vijay,
> >Happy new year!!!
> >
> >Just a quick comment to your question about implementations of ALTO-SSE
> >
> >There is a related work "Steering Hyper-Giants’ Traffic at Scale" [0]
> >where
> >ALTO is used as a northbound interface in a *real operational
> >environment
> >at scale*.
> >The authors mention the SSE extension (but I am not sure if this
> >extension
> >was also tested).
> >
> >Best regards,
> >
> >Danny Lachos
> >
> >[0]
> >https://mailarchive.ietf.org/arch/msg/alto/h7QJRu47NbTvfcnW2fveFqCBRdw
> >
> >On Mon, Jan 6, 2020 at 4:32 PM Vijay Gurbani 
> >wrote:
> >
> >> All: Happy new year.
> >>
> >> In preparation of moving alto-incr-update-sse ahead, I have performed
> >a
> >> chair review of the work.  Overall, the document is well written,
> >mature,
> >> and considers various design tradeoffs.  This is fairly mature work,
> >and we
> >> should move it out of the WG following the resolution to the review
> >below
> >> and an additional review by Jensen Zhang [1].
> >>
> >> --- Begin chair review
> >>
> >> I am curious --- are there any known implementations of alto-sse?
> >>
> >> MAJOR
> >> -S10.1: This is an important discussion.  However, this discussion is
> >> written primarily from a viewpoint of an ALTO client, but if I
> >understand
> >> it correctly, it should be written from the viewpoint of an ALTO
> >stream
> >> server since it is the stream server that is generating the event
> >since
> >> that is the source that should be told to behave conservatively.
> >Should
> >> this section be re-written to exhort the stream server to send out
> >full
> >> cost maps in chunked format, where each chunk is at most 2,000
> >octets?
> >> That way, the clients are not overwhelmed.  Thoughts?
> >>
> >> MINOR
> >> S3: It is rather unfortunate that one of the services is named
> >“Stream
> >> Control Service” as this may be conflated by the uninitiated reader
> >with
> >> the Stream Control Transmission Protocol (SCTP) service, a transport
> >layer
> >> protocol.  Clearly, that is not the intent here.  However, I am
> >loathe to
> >> suggest a new naming scheme this late in the document publication
> >phase, so
> >> perhaps the best we can do now is to add a note explicitly
> >disassociating
> >> Stream Control Service of ALTO from SCTP.  Perhaps something like:
> >s/from
> >> the update stream./from the update stream. (Note that the Stream
> >Control
> >> Service in ALTO has no association with the similarly named Stream
> >Control
> >> Transmission Protocol [RFC4960].)/
> >>
> >> S4: The phrase “Using existing techniques wherever possible,” implies
> >that
> >> you have used other, perhaps new techniques at other places.  Is that
> >the
> >> case?  If so, please enumerate the new techniques; if not, perhaps
> >reword
> >> as s/Using existing techniques wherever possible,/Using existing
> >> techniques,/
> >>
> >> -S4.2.1: “This document adopts the JSON merge patch message format to
> >> encode incremental changes, but uses a different transport
> >mechanism.” ==>
> >> Not sure how to interpret this.  Since alto-sse uses the HTTP PATCH
> >method
> >> to affect incremental updates, it uses the same “transport mechanism”
> >> (i.e., TLS).  Perhaps you meant “, but uses a different HTTP
> >method,
> >> i.e., it uses POST instead of PATCH (details in Section 5).”?
> >>
> >> -S4.2.1, page 10: s/, and (3) assigns a new tag to the network map:/,
> >(3)
> >> leaves “PID3” unmodified, and (4) assigns a new tag to the network
> >map:/
> >>
> >> -S6.1: Is there so

[alto] Chair review of draft-ietf-alto-incr-update-sse-17

[Vijay Gurbani]

All: Happy new year.

In preparation of moving alto-incr-update-sse ahead, I have performed a
chair review of the work.  Overall, the document is well written, mature,
and considers various design tradeoffs.  This is fairly mature work, and we
should move it out of the WG following the resolution to the review below
and an additional review by Jensen Zhang [1].

--- Begin chair review

I am curious --- are there any known implementations of alto-sse?

MAJOR
-S10.1: This is an important discussion.  However, this discussion is
written primarily from a viewpoint of an ALTO client, but if I understand
it correctly, it should be written from the viewpoint of an ALTO stream
server since it is the stream server that is generating the event since
that is the source that should be told to behave conservatively.  Should
this section be re-written to exhort the stream server to send out full
cost maps in chunked format, where each chunk is at most 2,000 octets?
That way, the clients are not overwhelmed.  Thoughts?

MINOR
S3: It is rather unfortunate that one of the services is named “Stream
Control Service” as this may be conflated by the uninitiated reader with
the Stream Control Transmission Protocol (SCTP) service, a transport layer
protocol.  Clearly, that is not the intent here.  However, I am loathe to
suggest a new naming scheme this late in the document publication phase, so
perhaps the best we can do now is to add a note explicitly disassociating
Stream Control Service of ALTO from SCTP.  Perhaps something like: s/from
the update stream./from the update stream. (Note that the Stream Control
Service in ALTO has no association with the similarly named Stream Control
Transmission Protocol [RFC4960].)/

S4: The phrase “Using existing techniques wherever possible,” implies that
you have used other, perhaps new techniques at other places.  Is that the
case?  If so, please enumerate the new techniques; if not, perhaps reword
as s/Using existing techniques wherever possible,/Using existing
techniques,/

-S4.2.1: “This document adopts the JSON merge patch message format to
encode incremental changes, but uses a different transport mechanism.” ==>
Not sure how to interpret this.  Since alto-sse uses the HTTP PATCH method
to affect incremental updates, it uses the same “transport mechanism”
(i.e., TLS).  Perhaps you meant “..., but uses a different HTTP method,
i.e., it uses POST instead of PATCH (details in Section 5).”?

-S4.2.1, page 10: s/, and (3) assigns a new tag to the network map:/, (3)
leaves “PID3” unmodified, and (4) assigns a new tag to the network map:/

-S6.1: Is there some magic about the numbers “1” and “2” assigned to
substream IDs?  In other words, must substream IDs begin with 1 and
monotonically increase?  If so, state that.  If not, then state that
substream IDs must begin with a random number between [1, 10] and
monotonically increase from there on for each new substream.  That is, if
the first substream ID is 6, then subsequent substream IDs from the client
should monotonically increase from this starting value.  (I will let the
protocol designers come up with the exact text to impart this.)

NITS
-S5, page 16: s/this design allows/this document allows/
(Overworked use of “design”: “...flexible protocol design, this design…”).

-S10.1: s/single character array./character array./

-S10.1: s/client computer/client/

--- End of chair review

Additionally, the work has also been reviewed by Jensen [1].

Authors, please attend to the comments indicated in this review and
Jensen's review and release a new version in order to move the work forward..

[1] https://mailarchive.ietf.org/arch/msg/alto/C9_tS44bz7kq84Z3cpZZkMeUDFc

Thank you.

- vijay
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] End of WGLC for update-sse; need reviews.

[Vijay Gurbani]

Jensen: Excellent.  Thank you!

On Fri, Dec 13, 2019 at 9:04 AM Jensen Zhang 
wrote:

> Hi Vijay and WG,
>
> I am reviewing the latest revision of SSE. I will post my review by
> tonight.
>
> Thanks,
> Jensen
>
>
> On Fri, Dec 13, 2019 at 10:01 AM Vijay Gurbani 
> wrote:
>
>> Folks: The WGLC ended for update-sse on Dec 8 [1].  However, we have had
>> absolutely no discussion on the mailing list about this draft after it was
>> posted for WGLC.
>>
>> I am shepherding this draft, and as such, I will need at least one, and
>> perhaps two, members from the WG who are not associated with the draft to
>> perform an indepth review of this draft.  I will review it as well as part
>> of shepherding.
>>
>> Please send me an email indicating that you will like to review this
>> draft, and please let me know when to expect the review by.
>>
>> Thank you.
>>
>> [1]
>> https://mailarchive.ietf.org/arch/msg/alto/hHM_bC1CfwygcxTTm96zBbj7gmo
>> ___
>> alto mailing list
>> alto@ietf.org
>> https://www.ietf.org/mailman/listinfo/alto
>>
>
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

[alto] End of WGLC for update-sse; need reviews.

[Vijay Gurbani]

Folks: The WGLC ended for update-sse on Dec 8 [1].  However, we have had
absolutely no discussion on the mailing list about this draft after it was
posted for WGLC.

I am shepherding this draft, and as such, I will need at least one, and
perhaps two, members from the WG who are not associated with the draft to
perform an indepth review of this draft.  I will review it as well as part
of shepherding.

Please send me an email indicating that you will like to review this draft,
and please let me know when to expect the review by.

Thank you.

[1] https://mailarchive.ietf.org/arch/msg/alto/hHM_bC1CfwygcxTTm96zBbj7gmo
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

[alto] Draft 106 meeting minutes posted

[Vijay Gurbani]

All: The draft meeting minutes from the Singapore IETF have been posted;
please see https://datatracker.ietf.org/doc/minutes-106-alto/

Please let the chairs know of any discrepancies in the minutes.

Also, someone volunteered to review path-vector for the WG, but I could not
catch the name.  Whoever volunteered, please get in touch with the chairs.

Thanks,

- vijay
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

[alto] IMPORTANT: Please upload slides

[Vijay Gurbani]

All: Only two presenters have uploaded their slides for ALTO.

For those who have not, please do so immediately; neither Jan or I are at
the IETF and we will not be attending the meeting online either (due to
time differences and other commitments).  As such, we want to ensure that
the initial version of the slide has been uploaded on the datatracker so we
can approve of it.  Subsequent updates to the same slide show will not need
our approval.

It is early morning in Singapore as I am sending this email, so we have a
small window of time where if you upload the initial version of the slides,
either Jan or I will be able to approve it right away.

Please do so.

Thanks,

- vijay
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] IETF 106 ANI Nov. 20 side meeting slides

[Vijay Gurbani]

Richard: You can hang the slides off the main IETF ALTO meetings material
page; just submit them using the datatracker and Jan or I will approve it.
That way, they will be archived and available in posterity.

Also, if you (or someone who attended the meeting as well) post any notes
on the mailing list summarizing the outcome, that would be great!

Thanks,

- vijay

On Wed, Nov 20, 2019 at 3:33 AM Y. Richard Yang  wrote:

> Dear all,
>
> It was a wonderful meeting this morning. Some asked for the slides and
> here is a link, for now, to the slides:
> https://www.dropbox.com/sh/8xamtujadex7idl/AAAujFZxfVZnpMVGNk3Yu5t5a?dl=0
>
> We will place the slides at a more stable location soon after this ietf.
>
> Thank you so much to the wonderful speakers and the active engagement of
> many both during and after the meeting.
>
> Cheers,
> Richard, Sabine, Borje, Farni, and Kai
>
> --
> --
>  =
> | Y. Richard Yang|
> | Professor of Computer Science   |
> | http://www.cs.yale.edu/~yry/|
>  =
> ___
> alto mailing list
> alto@ietf.org
> https://www.ietf.org/mailman/listinfo/alto
>
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

[alto] Sabine Randriamasy and Borje Ohlman temporary chairs for ALTO on Thu

[Vijay Gurbani]

All: Since neither Jan or I could be in Singapore, Sabine and Borje have
volunteered to serve as temporary chairs for the ALTO meeting in IETF 106.
Jan and I appreciate them stepping in.

To make matters easier, all authors presenting, please upload a PDF version
of your slides using the datatracker login as described in [1].  That way,
Jan or I can approve the materials right away without authors having to
bother Sabine and Borje for last minute uploads.

Thanks,

- vijay

[1] https://mailarchive.ietf.org/arch/msg/alto/yjmTfhEhim5OmHplBr-B19lXjDI
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

[alto] Please upload your materials

[Vijay Gurbani]

All: In preparation for our meeting on Thu, please upload your materials in
PDF format.  If you have a datatracker login, please login and upload your
slides.  The first time you do so, it will ask the chairs to confirm; once
that is done, you will be able to upload incremental versions without chair
confirmation.

If you do not have a datatracker login, please do get one by going to
datatracker.ietf.org/  Once you are there, at the top left, there is a row
of options, one of which is "User".  Select it and from the dropdown menu,
select "New Account".

Cheers,

- vijay
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] ALTO Meeting Agenda Update

[Vijay Gurbani]

Jensen, Done.
Cheers,
- vijay

On Wed, Nov 13, 2019 at 1:29 PM Jensen Zhang 
wrote:

> Hi Vijay,
>
> After some discussion with other speakers and WG members, we propose
> the following change to the meeting agenda. Could you help to update the
> agenda?
>
> 1550 - 1600 10" Chair slides / Agenda bash  Chairs
> 1601 - 1616 15" ALTO performance metrics [1]R. Yang
> 1617 - 1632 15" Unified properties for ALTO [2] S.
> Randriamasy
> 1633 - 1648 15" ALTO Extension: Path vector [3] K. Gao
> 1649 - 1659 10" CDNI footprint and capabilities [4] R. Yang
> 1700 - 1709  9" Using ALTO to determine service edge [5]L.
> Contreras
> 1710 - 1720 10" Extending ALTO by using BGP communities [6] L.
> Contreras
>
> [1] https://datatracker.ietf.org/doc/draft-ietf-alto-performance-metrics/
> [2] https://datatracker.ietf.org/doc/draft-ietf-alto-unified-props-new/
> [3] https://datatracker.ietf.org/doc/draft-ietf-alto-path-vector/
> [4]
> https://datatracker.ietf.org/doc/draft-ietf-alto-cdni-request-routing-alto/
> [5] https://datatracker.ietf.org/doc/draft-contreras-alto-service-edge/
> [6] No draft yet
>
> Thanks,
> Jensen
>
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

[alto] New WGLC of draft-ietf-alto-incr-update-sse-17

[Vijay Gurbani]

All: draft-ietf-alto-incr-update-sse has been in WGLC for a while.  Going
back to resurrect it's state, I see that -11 was WGLC'd on June 20, 2018
and that WGLC ended on Jul 4, 2018 [1].  After that the draft has changed
various times and has been discussed during the Dec 2018 virtual interim
[2], and IETF 104 [3].  The minutes for IETF 104 [3] indicate that the
chairs were to issue another WGLC, but that never happened, until now.

Therefore, please consider this email as a second WGLC for
draft-ietf-alto-incr-update-sse.  The WGLC lasts from today (Nov 14, 2019)
to Dec 8, 2019.  I have extended the WGLC beyond the customary two weeks to
account for the IETF 106 meeting next week.

It will be great if at least two people could indicate their willingness to
perform a WGLC on -17.  Please send Jan and me an email to this effect.

[1] https://mailarchive.ietf.org/arch/msg/alto/NNrG6P7MjRW1GwYbIJFUDi1089k
[2]
https://datatracker.ietf.org/doc/minutes-interim-2018-alto-01-201812110600/
[3] https://datatracker.ietf.org/doc/minutes-104-alto/

Thank you all for your patience as we move the pending work ahead.

Have a productive IETF 106.

Cheers,

- vijay
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

[alto] Draft ALTO WG agenda for Singapore

[Vijay Gurbani]

All: The draft WG agenda for Singapore is at
https://datatracker.ietf.org/meeting/106/materials/agenda-106-alto-00

If anyone sent a request that is not reflected in the agenda, please let
Jan and me know.

Cheers,

- vijay
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] Reminder: Agenda requests for Singapore IETF

[Vijay Gurbani]

All: So far Jan and I have received only one agenda request.  Based on
this, it will be a very quick meeting :-)  If you'd like to change
that...please send Jan and me an agenda request using the template shown
below as soon as you can.

The draft WG agendas are due on Wed (Nov-6).

Thanks.

On Thu, Oct 31, 2019 at 9:35 AM Vijay Gurbani 
wrote:

> Folks: If you have sent me or Jan an agenda request, then please resend as
> I have not received any yet.
>
> The draft WG agenda is due next week Wed.  Please see [1] for the template
> to send agenda requests for the Singapore IETF.
>
> [1] https://mailarchive.ietf.org/arch/msg/alto/YPUVSGUbNv2o16LW-E2KCZ2nKyE
>
> Cheers,
>
> - vijay
>
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto