Re: [alto] Zaheduzzaman Sarker's Discuss on draft-ietf-alto-new-transport-17: (with DISCUSS and COMMENT)

[Zaheduzzaman Sarker <[e-mail]>]

On Wed, Nov 29, 2023 at 12:41 PM <[e-mail]> wrote:

> Hi Zahed,
>
> Thanks for the comments! Please see the responses inline. I already have
> the updates in place but would like to submit a new revision after you
> review the proposed texts.
>
> Best,
>
> Kai
>
>
> -----Original Messages-----
> *From:* "Zaheduzzaman Sarker" <[e-mail]>
> *Send time:* Tuesday, 11/28/2023 20:02:44
> *To:* "Kai GAO" <[e-mail]>
> *Cc:* "The IESG" <[e-mail]>, [e-mail],
> [e-mail], [e-mail], "Kai Gao" <
> [e-mail]>
> *Subject:* Re: [alto] Zaheduzzaman Sarker's Discuss on
> draft-ietf-alto-new-transport-17: (with DISCUSS and COMMENT)
>
> Hello,
>
> Thanks for addressing the comments. The -19 version looks improved.
>
> Some more reflections below.
>
> //Zahed
>
> On Tue, Nov 21, 2023 at 4:09 PM Kai GAO <[e-mail]> wrote:
>
>> Hi Zaheduzzaman,
>>
>> We are sorry for the late reply -- the mail was blocked by the spam
>> detector. Please see our responses inline.
>>
>> Best,
>> Kai
>>
>> On Thu, Oct 26, 2023 at 6:56 PM Zaheduzzaman Sarker via Datatracker <
>> [e-mail]> wrote:
>>
>>> Zaheduzzaman Sarker has entered the following ballot position for
>>> draft-ietf-alto-new-transport-17: Discuss
>>>
>>> When responding, please keep the subject line intact and reply to all
>>> email addresses included in the To and CC lines. (Feel free to cut this
>>> introductory paragraph, however.)
>>>
>>>
>>> Please refer to
>>> https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
>>> for more information about how to handle DISCUSS and COMMENT positions.
>>>
>>>
>>> The document, along with other ballot positions, can be found here:
>>> https://datatracker.ietf.org/doc/draft-ietf-alto-new-transport/
>>>
>>>
>>>
>>> ----------------------------------------------------------------------
>>> DISCUSS:
>>> ----------------------------------------------------------------------
>>>
>>> Thanks for working on this specification.
>>>
>>> I have following points which I want to discuss further -
>>>
>>> - I understand this new transport is supposed to take advantages of
>>> HTTP/2 and
>>> HTTP/3 features and have backward compatibility with HTTP/1.x (x=1,
>>> likely). My
>>> take is, if I want to server ALTO server over HTTP2/ or HTTP/3 I would
>>> use this
>>> new transport. Now if I also want to also support HTTP1.x for whatever
>>> reasons
>>> then I have issue, should this new transport is sufficient to support
>>> all the
>>> HTTP versions up to HTTP/3? if yes, then why this does specification not
>>> update
>>> or even obsolete rfc8895? if the answer is NO, does that mean I need to
>>> implement both this specification and rfc8895 for HTTP1.1? This relation
>>> is not
>>> explicitly defined in this current draft, which it should.
>>>
>>> [KAI] Thanks for the comment. Yes, the new transport is sufficient to
>> support all HTTP
>> versions up to HTTP/3. The relationship between new transport and RFC8895
>> is also
>> raised by the IoT telechat review by Wesley Eddy. Our understanding is
>> that new
>> transport is not a replacement of ALTO/SSE, and these two extensions can
>> be combined
>> (see the introduction of -18 for more complete discussions).
>>
>
> This looks better in -19 version. Thanks
>
>>
>> - I am not convinced that incremental update actually reduces storage at
>>> ALTO
>>> server, how is that so? I don't think there is an strict requirement
>>> that all
>>> the ALTO clients need to be updated to the recent version to be
>>> functional (as
>>> described in this specification), that means unless the serve is sure
>>> that all
>>> the clients are updated to certain version it has to keep the update
>>> versions.
>>> As storage reduction is a motivation for the transport requirement this
>>> motivation need to be well described to derive the requirement.
>>>
>>
>> [KAI] The "reduced storage" is compared to the case where the server
>> stores the contents
>> of each version. It is a motivation to use incremental updates (which
>> applies to RFC 8895
>> as well) and we consider incremental updates as one motivation for the
>> new transport.
>> Does this make sense?
>>
>
> The draft still just mentions this as a statement. I think it would be
> better if it is clear that the comparison is done with the case where the
> server stores the contents of the each version.
>
>
> [KAI] Got it. The proposed text is:
>
> NEW:
>       Incremental updates only maintain and transfer
>       the "diff" upon changes.  Thus, it is more efficient than storing
>       and transferring the full updates, especially when the change of
>       an ALTO resource is minor.
>

LGTM.

>
>
>
>>
>>
>>> - I didn't find any explanation of how the "Concurrent, non-blocking
>>> update
>>> transmission" requirement is meet by the new transport. is this solved
>>> by the
>>> use of HTTP/3 with uses QUIC and does not have HOL blocking within a
>>> connection? Or is this addressed by multiple concurrent HTTP connection
>>> to the
>>> ALTO server? This need to be understood better and we should define what
>>> actually "Concurrent, non-blocking update transmission" means in this
>>> context
>>> of fetching updates.
>>>
>>>
>> [KAI] The requirement basically requires that incremental updates can be
>> transmitted
>> at the same time (concurrent) and the transmission of one update will not
>> be blocked
>> by the transmission of another update. This can be realized by 1)
>> multiple HTTP
>> connections, or 2) HTTP/3 using multiple streams. This is compared with
>> RFC 8895
>> where SSE multiplexes the updates in a single sequence. You make a good
>> point that
>> we should clarify how this can be done with new transport. We will add a
>> paragraph to
>> Sec 2.1 and upload a revision soon.
>>
>>
>>> - The encoding or data type of "updates graph (ug)" and "version" is not
>>> defined. The example uses numeric numbers which is easy to understand
>>> with
>>> incremental values. However, unless and otherwise this data type is
>>> defined
>>> then it is up to the implementers to select that and which will lead to
>>> interoperability issues. or may be I am missing something here, that is
>>> why I
>>> need to discuss the intention here.
>>>
>>>
>> [KAI] The data type of the version tag (the one held by the client) is a
>> string (JSONString)
>> but the "version" used to compute the URLs is a sequence number
>> (JSONNumber), both
>> specified in Sec 6.2.
>>
>
> do you mean "UpdatesGraphSummary" ? can we put the inline ref to the
> section where version datatype is defined to avoid confusion?
>
>
> [KAI] The proposed texts are added to the "Updates graph" and "Version"
> entries in Sec 2.2.
>
> NEW: ... Encoding of a updates graph is specified in Section 6.1.
>
> NEW: ... Version is encoded as a JSONNumber, as specified in Section 6.1.
>

Better now.

>
>>
>>> -  Here we are composing URIs from the ug , that tells me without proper
>>> encoding on ug defined there might be some internationalization issues
>>> (see
>>> rfc6365). Has there been any thoughts or discussions on this encoding and
>>> potential issues?
>>>
>>>
>> [KAI] Good point. According to RFC 7285 (the base ALTO protocol), the
>> contents
>> of the ALTO maps only allow ASCII characters. I think this document
>> should have
>> the same restrictions.
>>
>
> have you mentioned this in -19 version? if not then please write the
> restriction.
>
> [KAI] I checked the charset for JSON (e.g. RFC 4627). Seems that the
> encoding is unicode (and UTF-8 by default). In that case, there is only one
> potential risk that a tips-view-uri may contain international characters,
> as other parts of the constructed URLs are all ASCII. In Sec 6.2, we
> require tips-view-uri to follow RFC 3986 which only uses ASCII characters
> for the URL. Our proposal is to add a text in Sec 6.2:
>
> NEW:
>
> The field [tips-view-uri] MUST contain only ASCII characters. If the
> original URL contains international characters (e.g., in the domain name),
> they MUST be properly encoded into the ASCII format (e.g., using the
> "urlencode" function).
>

I think we need to hint on "who" is going to convert them using that
function.

//Zahed


>
>
> //Zahed
>
>
>
>
>>
>>
>>> and I am also supporting Roman's discuss.
>>>
>>>
>>> ----------------------------------------------------------------------
>>> COMMENT:
>>> ----------------------------------------------------------------------
>>>
>>> I think my other AD colleagues have already identified nits and typos.
>>>
>>>
>>>
>>> _______________________________________________
>>> alto mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/alto
>>>
>>