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

Ack, Alissa. Thanks!

Richard

On Wed, Mar 11, 2020 at 8:59 PM Alissa Cooper <alissa@cooperw.in> 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 <yry@cs.yale.edu> 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 site
> 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 <elwynd@googlemail.com> 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.  Explaining
>> the nature of 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 the client as the key indicator of state consistency would be a
>> considerable improvement.
>>
>> Cheers,
>> Elwyn
>>
>>
>>
>> Sent from Samsung tablet.
>>
>>
>> -------- Original message --------
>> From: "Y. Richard Yang" <yry@cs.yale.edu>
>> Date: 10/03/2020 04:25 (GMT+00:00)
>> To: Elwyn Davies <elwynd@dial.pipex.com>
>> 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
>>>
>>> <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
>>>
>>> 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: for
>> 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 (with
>> 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 proposes
>>> 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 capitalization.
>>
>>
>>>
>>> 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 by
>>> **....
>>> ** would be desirable.
>>>
>>
>> Sure.
>>
>>
>>> s5.1, next to last para:  s/ So there is no ambiguous decoding/ So there
>>> 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—a kind of future proof of a future version by a
>> legacy old version. But in this case, I agree that it is a known error and
>> 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
>>
>
>
> --
> --
>  =====================================
> | Y. Richard Yang <yry@cs.yale.edu>   |
> | Professor of Computer Science       |
> | http://www.cs.yale.edu/~yry/        |
>  =====================================
>
> _______________________________________________
> Gen-art mailing list
> Gen-art@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art
>
>
> --
Richard