Re: [alto] [Last-Call] Genart last call review of draft-ietf-alto-incr-update-sse-20

[Y. Richard Yang]

Hi Ben,

Just an update that we have submitted -21 and will upload -22 tomorrow (we
submitted -22 twice but somehow it did not post; we will take the
opportunity of waiting for one day to proofread the document and upload by
the end of Friday for you to check if the revision handles your review,
which is exceedingly valuable.

Richard

On Sun, Mar 15, 2020 at 12:09 AM Benjamin Kaduk  wrote:

> On Tue, Mar 10, 2020 at 12:25:12AM -0400, Y. Richard Yang wrote:
> > Dear Elwyn,
> >
> > Thanks a lot for the review! Please see inline below.
> >
> > On Mon, Mar 9, 2020 at 8:45 PM Elwyn Davies via Datatracker <
> > nore...@ietf.org> wrote:
> >
> > > Reviewer: Elwyn Davies
> > > Review result: Almost Ready
> > >
> > > I am the assigned Gen-ART reviewer for this draft. The General Area
> > > Review Team (Gen-ART) reviews all IETF documents being processed
> > > by the IESG for the IETF Chair.  Please treat these comments just
> > > like any other last call comments.
> > >
> > > For more information, please see the FAQ at
> > >
> > > .
> > >
> > > Document: draft-ietf-alto-incr-update-sse-20
> > > Reviewer: Elwyn Davies
> > > Review Date: 2020-03-09
> > > IETF LC End Date: 2020-03-06
> > > IESG Telechat date: 2020-03-12
> > >
> > > Summary:
> > > Almost ready.  There are a few editorial issues, but I am not sure that
> > >
> > > Major issues:
> > > I am unsure whether this mechanism is proof against loss of messages or
> > > reordering  of messags.  Although there are state tags, it does not
> appear
> > > to
> > > have any way to ensure that the state to which the updates will be
> applied
> > > in
> > > the client are identical to the state that the updates were generated
> > > from.  If
> > > I am wrong, it would be useful (IMO) to explain how the proposal avoids
> > > getting
> > > updates that don't apply to the state in the client.
> > >
> >
> > Good comment! A short answer is that the design should have no
> consistency
> > problems.
> >
> > More details:
> >
> > (1) This design is based on http/1.x as transport, which provides a
> single,
> > reliable, in-order serialization of update messages: m1, m2, m3, ...
> > The transport will guarantee that the messages will be delivered
> lossless,
> > in order.
>
> I did not remember getting the impression that it was required to use
> HTTP/1.x transport with this specification, as I attempted to note in my
> ballot, SSE is not HTTP/1.x-specific.  If the intent is to only allow the
> usage of HTTP/1.x with HTTP/2 (or HTTP/3) left to future work, I think that
> (e.g.) the end of Section 3.3 needs to be more explicit about this.
>
> -Ben
>
-- 
Richard
___
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

[alto] Protocol Action: 'Application-Layer Traffic Optimization (ALTO) Cost Calendar' to Proposed Standard (draft-ietf-alto-cost-calendar-21.txt)

[The IESG]

The IESG has approved the following document:
- 'Application-Layer Traffic Optimization (ALTO) Cost Calendar'
  (draft-ietf-alto-cost-calendar-21.txt) as Proposed Standard

This document is the product of the Application-Layer Traffic Optimization
Working Group.

The IESG contact persons are Mirja Kühlewind and Magnus Westerlund.

A URL of this Internet Draft is:
https://datatracker.ietf.org/doc/draft-ietf-alto-cost-calendar/





Technical Summary

   This document is an extension to the base ALTO protocol (RFC 7785).  It 
   extends the ALTO cost information service such that applications decide 
   not only 'where' to connect, but also 'when'.  This is useful for 
applications
   that need to perform bulk data transfer and would like to schedule these
   transfers during an off-peak hour, for example.

Working Group Summary

   The work has been discussed extensively in the WG over the years, and the
   WG feels that the document is ready to for publication.

Document Quality

   Cost calendar is a well-know extension within the working group, having been
   first presented as an individual document on Jul 4, 2014 (individual -00
   version).  It was subsequently adopted as WG item on Jul 28, 2016.
   The work has been reviewed by at least four key WG members in the past.
   Post WGLC, version -06 of the document added a beefed up Security 
   Consideration and a new Operations Consideration section to the draft.
   Key members of the WG reviewed the latest version of the draft including 
these 
   two sections.

  The draft was presented to the IESG and balloted on 2018-12-04.  This 
balloting
  brought the draft back to the WG due to an IPR related issue leading to a 
second 
  WGLC.

   There is one known implementation, authored by the editor of the draft.

Personnel

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

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

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

[internet-drafts]

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-21.txt
Pages   : 57
Date: 2020-03-19

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.  This document presents a
   mechanism to allow an ALTO server to push updates to ALTO clients, to
   achieve two benefits: (1) updates can be incremental, in that if only
   a small section of an information resource changes, the ALTO server
   can send just the changes; and (2) updates can be immediate, in that
   the ALTO server can send updates as soon as they are available.



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-21
https://datatracker.ietf.org/doc/html/draft-ietf-alto-incr-update-sse-21

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-alto-incr-update-sse-21


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