Return-Path: X-Original-To: gen-art@ietfa.amsl.com Delivered-To: gen-art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 869F13A0A10; Thu, 12 Mar 2020 08:22:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.11 X-Spam-Level: X-Spam-Status: No, score=-3.11 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-1.463, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29ZJlb1E3NKr; Thu, 12 Mar 2020 08:22:36 -0700 (PDT) Received: from mail-vs1-f54.google.com (mail-vs1-f54.google.com [209.85.217.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE04B3A07AA; Thu, 12 Mar 2020 08:22:35 -0700 (PDT) Received: by mail-vs1-f54.google.com with SMTP id k188so3910167vsc.8; Thu, 12 Mar 2020 08:22:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=T6O90Gr5F7y/BgKzh4XkBlmBSm6u5FbK1FJH0+p68QY=; b=LK0Lu4jeO+U1yBZsY9NoRUkj2kFn7XTtlxBAsmOrSow0JNCJk9EOPLZ3KRfTWryRcB CyR9jGCoC0x0zx94pDYHLhjBuSuMzGau9ogCdIrIshF1bzDh+FvAKLgVHPjT1/eHm6Sr huBL2VGvrF0++ECzntNwCuy41mytPey4P/uJCGG5pQvRxEkFHuv+BcNn8XS+3QIwv/Um JzqGFELT2Cq/cItNYw8zB0pghnqWBw8Wkcsh6XaILeznoSi15EH5PlO7h5B3UhmoHK5e Mx+KaruxYa382Avy8dNRpTuQ5hyY003bIhxmpyHMj7GQKkjAPhtXAUQ7Xk6zrSwK9reH ma8w== X-Gm-Message-State: ANhLgQ07LVOjXtmyxFxueFDgK31UKhkXQnaWrXIBcofdm0WoOWAH75F0 S/28ubT9YXgE6ocyALjxILOLqWtO1QKy8vXm0lw= X-Google-Smtp-Source: =?utf-8?q?ADFU+vtGYZ2xtimB4NTVxWlXmBAdltQncBtqgYwoGj9o?= =?utf-8?q?nBbDh5WnLciUikgMbMqRRERiK8N9bpbCzGEBx9MO7BwQo3E=3D?= X-Received: by 2002:a05:6102:48d:: with SMTP id n13mr2272585vsa.102.1584026554689; Thu, 12 Mar 2020 08:22:34 -0700 (PDT) MIME-Version: 1.0 References: <5e67b794.1c69fb81.19f6a.288f@mx.google.com> <9EF09587-736C-4CF1-B00E-4EDCF94B43D3@cooperw.in> In-Reply-To: <9EF09587-736C-4CF1-B00E-4EDCF94B43D3@cooperw.in> From: "Y. Richard Yang" Date: Thu, 12 Mar 2020 11:22:23 -0400 Message-ID: To: Alissa Cooper Cc: General Area Review Team , IETF ALTO , draft-ietf-alto-incr-update-sse.all@ietf.org, elwynd , last-call@ietf.org Content-Type: multipart/alternative; boundary="0000000000001b6d5c05a0a9ece9" Archived-At: Subject: Re: [Gen-art] Genart last call review of draft-ietf-alto-incr-update-sse-20 X-BeenThere: gen-art@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "GEN-ART: General Area Review Team" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2020 15:22:39 -0000 --0000000000001b6d5c05a0a9ece9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Ack, Alissa. Thanks! Richard On Wed, Mar 11, 2020 at 8:59 PM Alissa Cooper wrote: > Elwyn, thanks for your review. Richard, thanks for your response. I > entered a No Objection ballot. > > Alissa > > > On Mar 10, 2020, at 3:24 PM, Y. Richard Yang wrote: > > Dear Elwyn, > > Thank you so much for the additional comment! Sure we will add the text, > and make clear on the nature and use of tag. It looks that the upload sit= e > is opened again, and we will upload a new version as soon as it will not > lead to confusion of other reviews. > > Richard > > On Tue, Mar 10, 2020 at 11:51 AM elwynd wrote: > >> Hi, Richard. >> >> Sorry I was a bit rushed last night and should have said a bit more. >> >> I think adding some text about how consistency is maintained would be a >> good solution. As a non-expert in ALTO I was not really aware of the >> significance of the tag field when I started readig the draft. Explaini= ng >> the nature of the tag field and making sure that it is clear that the ol= d >> value of the tag field in an update MUST match the value of the tag fiel= d >> as known by the client as the key indicator of state consistency would b= e a >> considerable improvement. >> >> Cheers, >> Elwyn >> >> >> >> Sent from Samsung tablet. >> >> >> -------- Original message -------- >> From: "Y. Richard Yang" >> Date: 10/03/2020 04:25 (GMT+00:00) >> To: Elwyn Davies >> Cc: alto@ietf.org, draft-ietf-alto-incr-update-sse.all@ietf.org, >> gen-art@ietf.org, last-call@ietf.org >> Subject: Re: Genart last call review of draft-ietf-alto-incr-update-sse-= 20 >> >> 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 < >> noreply@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. >> >> (2) One can consider that the messages consist of substreams (resources)= . >> Each substream is total ordered as well. >> >> (3) The only remaining case is that substreams can have dependencies: fo= r >> example a cost map can depend on a network map. The design requires that >> the updates to such dependencies are ordered correctly. >> >> One can see that the consistency model can be weakened: from total >> serialization to causal consistency. We plan to design such a weaker (wi= th >> less head of line blocking of total order) using http/2. >> >> I like this comment. How about that we add a realized consistency model >> paragraph in the overview? What do you think? >> >> >> >>> Minor issues: >>> >>> Nits/editorial comments: >>> Abstract: the abstract is too long; I would suggest deleting the second >>> sentence of the first paragraph and the whole of the second paragraph. >>> Ths >>> would leave sufficient information to explain what the document propose= s >>> but >>> omits the rationale which is not necessary for outlining the contents. >>> The >>> deleted text would be usefully incorporated into s1. >> >> >> Okay. >> >> >>> >>> Abstract, para 3: s/s ction/section/ >> >> >> Thanks. Will fix. >> >> >>> >>> s1: The key role of Server-Sent Events in this proposal is not >>> introduced here >>> (and isn't mentioned in the Abstract). In the process SSE needs to be >>> expanded >>> on first use (currently right at the end of the section) and a pointer >>> to the >>> document that defines SSE [SSE] >> >> >> Okay. >> >> >>> >>> s1, last para: The reference to Section 13 should come right at the end >>> - and >>> the last two sections are (no longer) the last sectons: s/last two >>> sections/Sections 11 and 12/ >> >> >> Thanks a lot for identifying this. Will fix. >> >> >>> >>> s2 et seq: I am unsure of the rationale for defining a set of special >>> terms and >>> not capitalizing them on every occurrence. >> >> >> We feel that this is a style preference. We intended that the terms in >> Sec 2 are like keywords of a book. Capitalizing them on each occurrence >> appears to be a bit too much, for personal style. We prefer to keep this >> style, but do agree that some other ALTO documents use all capitalizatio= n. >> >> >>> >>> s2: There is quite a lot of terminology imported from RFC 7285 . This >>> should >>> be mentioned. >>> >> >> Good catch. Will add a sentence at the beginning. >> >> >>> s3: A pointer to the SSE document would be useful [SSE]. >>> >> >> Yes. Will do. >> >> >>> s3.4: It would be better to use the expanded form of SSE in the first >>> paragraph >>> rather than waiting till the 2nd para. >> >> >> Sure. Will do. >> >> >>> >>> s4: An explanation in advance of the format of the lines delineated b= y >>> **.... >>> ** would be desirable. >>> >> >> Sure. >> >> >>> s5.1, next to last para: s/ So there is no ambiguous decoding/ So ther= e >>> is no >>> ambiguity when decoding/ >>> >> >> Good revision and will do. >> >> >>> s5.1, last para: s/id/data-id/ >> >> >> Good catch, and will fix. >> >> >>> >>> s6.3, last para: s/will uses/will use/ >> >> >> Thanks. Will fix. >> >> >>> >>> s6,5, "incremental changes": s/Section Section6.3/Section 6.3/ >> >> >> Thanks. Will fix. >> >> >>> >>> s6.5, "remove": Stating that the client SHOULD ignore this if it >>> present is >>> potentially problematic. If it is there it is a syntax error - should >>> the >>> message be ignored and potentailly flagged as an error? >> >> >> The overall design strategy of alto is to ignore unknown fields to allow >> incremental deployment=E2=80=94a kind of future proof of a future versio= n by a >> legacy old version. But in this case, I agree that it is a known error a= nd >> it is a good clarification. We will flag it as an error. >> >> >>> >>> s7.6, last para: s/our modular/the modular/ >> >> >> Thanks. Will fix. >> >> >>> >>> s13/s13.1:Empty sections are not desirable Please combine the two >>> titles and >>> remove s13.1 . >>> >> >> Okay. >> >> Thanks again! >> >> Richard >> > > > -- > -- > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > | Y. Richard Yang | > | Professor of Computer Science | > | http://www.cs.yale.edu/~yry/ | > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art > > > -- Richard --0000000000001b6d5c05a0a9ece9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Ack, Alissa. Thanks!
Richard

=
On Wed, Mar 11, 2020 at 8:59 PM Aliss= a Cooper <alissa@cooperw.in>= wrote:
Elwyn, thanks for your review. Richar= d, thanks for your response. I entered a No Objection ballot.

Alissa


=
On Mar 10, 2020, at 3:24 P= M, Y. Richard Yang <yry@cs.yale.edu> wrote:

Dear Elwyn,

<= /div>
Thank you so much for the additional comment! Sure we will add th= e text, and make clear on the nature and use of tag. It looks that the uplo= ad site is opened again, and we will upload a new version as soon as it wil= l not lead to confusion of other reviews.

Richard
<= /div>

<= div dir=3D"ltr" class=3D"gmail_attr">On Tue, Mar 10, 2020 at 11:51 AM elwyn= d <elwynd@goo= glemail.com> wrote:
Hi, Richard.

Sorry I was a bit rushed last night and should have said a bit more.=C2= =A0=C2=A0

I think adding= some text about how consistency is maintained would be a good solution.=C2= =A0 As a non-expert in ALTO I was not really aware of the significance of t= he tag field when I started readig the draft.=C2=A0 Explaining the nature o= f the tag field and making sure that it is clear that the old value of the = tag field in an update MUST match the value of the tag field as known by th= e client as the key indicator of state consistency would be a considerable = improvement.

Cheers,
Elwyn



Sent from Sa= msung tablet.


-------- Original message --------=
From: "Y. Richard Yang" <yry@cs.yale.edu>=C2=A0
=
Date: 10/03/2020 04:25 (GMT+00:00)
To: Elwyn Davies <elwynd@dial.pipex.co= m>=C2=A0
Cc:=C2=A0alto@ietf.org,=C2=A0<= a href=3D"mailto:draft-ietf-alto-incr-update-sse.all@ietf.org" target=3D"_b= lank">draft-ietf-alto-incr-update-sse.all@ietf.org,=C2=A0<= a href=3D"mailto:gen-art@ietf.org" target=3D"_blank">gen-art@ietf.org,<= span>=C2=A0l= ast-call@ietf.org
Subject: Re: Genart last call review of dra= ft-ietf-alto-incr-update-sse-20

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 <= noreply@ietf.org&= gt; wrote:
Reviewer: Elwyn Davies
Review resul= t: Almost Ready

I am the assigned Gen-ART reviewer for this draft. T= he General Area
Review Team (Gen-ART) reviews all IETF documents being p= rocessed
by the IESG for the IETF Chair.=C2=A0 Please treat these commen= ts just
like any other last call comments.

For more information, = please see the FAQ at

<https://trac.ietf.org/= trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-alto-incr-upda= te-sse-20
Reviewer: Elwyn Davies
Review Date: 2020-03-09
IETF LC E= nd Date: 2020-03-06
IESG Telechat date: 2020-03-12

Summary:
Al= most ready.=C2=A0 There are a few editorial issues, but I am not sure that<= br>
Major issues:
I am unsure whether this mechanism is proof against= loss of messages or
reordering=C2=A0 of messags.=C2=A0 Although there a= re state tags, it does not appear to
have any way to ensure that the sta= te to which the updates will be applied in
the client are identical to t= he state that the updates were generated from.=C2=A0=C2=A0If
I am wrong,= it would be useful (IMO) to explain how the proposal avoids getting
upd= ates that don't apply to the state in the client.

Good comment! A short a= nswer is that the design should have no consistency problems.=C2=A0

More details:=C2=A0

(1) This design is based on http/1.= x as transport, which provides a single, reliable, in-order serialization o= f update messages: m1, m2, m3, ...
The transport wil= l guarantee that the messages will be delivered lossless, in order.

(2) One can consider that the m= essages consist of substreams (resources). Each substream is total ordered = as well.=C2=A0

(3)= The only remaining case is that substreams can have dependencies: for exam= ple a cost map can depend on a network map. The design requires that the up= dates to such dependencies are ordered correctly.
One can see that the consistency model can be wea= kened: from total serialization to causal consistency. We plan to design su= ch a weaker (with less head of line blocking of total order) using http/2.<= /div>

I like this comment. How= about that we add a realized consistency model paragraph in the overview? = What do you think?



Minor issues= :

Nits/editorial comments:
Abstract: the abstract is too long; I = would suggest deleting the second
sentence of the first paragraph and th= e whole of the second paragraph.=C2=A0 Ths
would leave sufficient inform= ation to explain what the document proposes but
omits the rationale whic= h is not necessary for outlining the contents.=C2=A0 =C2=A0The
deleted t= ext would be usefully incorporated into s1.
<= br>
Okay.



Abstract, para 3: s/s ction/section/

Thanks. Will fix.



s1:=C2=A0 The key role of Server-Sen= t Events in this proposal is not introduced here
(and isn't mentione= d in the Abstract).=C2=A0 In the process SSE needs to be expanded
on fir= st use (currently right at the end of the section) and a pointer to the
= document that defines SSE [SSE]

Okay.


=
s1, last para: The reference to Section 13 should come right at the end= - and
the last two sections are (no longer) the last sectons: s/last tw= o
sections/Sections 11 and 12/

<= div dir=3D"auto">Thanks a lot for identifying this. Will fix.



s2 et seq: I am unsure of the = rationale for defining a set of special terms and
not capitalizing them = on every occurrence.

We feel that this is a style preference. We intended that the terms in = Sec 2 are like keywords of a book. Capitalizing them on each occurrence app= ears to be a bit too much, for personal style. We prefer to keep this style= , but do agree that some other ALTO documents use all capitalization.
=



s2:=C2=A0 There is qui= te a lot of terminology imported from RFC 7285 .=C2=A0 This should
be me= ntioned.

Good= catch. Will add a sentence at the beginning.


s3: A pointer to the SSE document would be useful = [SSE].

Yes. W= ill do.


s3.4: It woul= d be better to use the expanded form of SSE in the first paragraph
rathe= r than waiting till the 2nd para.

<= div dir=3D"auto">Sure. Will do.



s4:=C2=A0 An explanation in advance=C2=A0 of the format of t= he lines delineated by **....
** would be desirable.

Sure.

s5.1, next to last para:=C2=A0 s/ So there is n= o ambiguous decoding/ So there is no
ambiguity when decoding/

Good revision and will = do.


s5.1, last para: = s/id/data-id/

Goo= d catch, and will fix.

=

s6.3, last para: s/will uses/will use/

Thanks. Will fix.

=


s6,5, "incremental changes": s/Sec= tion Section6.3/Section 6.3/

Thanks. Will fix.



s6.5, "remove":=C2=A0 Stating that the client SHOULD= ignore this if it present is
potentially problematic.=C2=A0 If it is th= ere it is a syntax error - should the
message be ignored and potentailly= flagged as an error?

The overall design strategy of alto is to ignore unknown fields to all= ow incremental deployment=E2=80=94a kind of future proof of a future versio= n by a legacy old version. But in this case, I agree that it is a known err= or and it is a good clarification. We will flag it as an error.



s7.6, last para: s/our modul= ar/the modular/

T= hanks. Will fix.



= s13/s13.1:Empty sections are not desirable=C2=A0 Please combine the two tit= les and
remove s13.1 .

Okay.=C2=A0

Thanks again!

Richard


--=C2=A0
--=C2=A0
= =C2=A0=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
| Y. Richard Yang <yry@cs.yale.edu> =C2=A0 |
| Professor of Computer Science =C2=A0 = =C2=A0 =C2=A0 |
|=C2=A0= http://www.cs.yale.edu/~yry/=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2= =A0|
=C2=A0=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D
_______________________________________________=
Gen-art mailing list
Gen-art@ietf.org
https://= www.ietf.org/mailman/listinfo/gen-art

--
Richard
--0000000000001b6d5c05a0a9ece9--