[alto] Genart last call review of draft-ietf-alto-incr-update-sse-20

[Elwyn Davies via Datatracker <[e-mail]>]

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.

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.

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

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]

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/

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

s2:  There is quite a lot of terminology imported from RFC 7285 .  This should
be mentioned.

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

s3.4: It would be better to use the expanded form of SSE in the first paragraph
rather than waiting till the 2nd para.

s4:  An explanation in advance  of the format of the lines delineated by **....
** would be desirable.

s5.1, next to last para:  s/ So there is no ambiguous decoding/ So there is no
ambiguity when decoding/

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

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

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

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?

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

s13/s13.1:Empty sections are not desirable  Please combine the two titles and
remove s13.1 .