Hi Authors,
In addition to Qin's questions/comments below, here are some additional notes
from my reading of the draft. Thank you.
* Instead of "work flow", kindly suggest using "workflow" (there are a few
instances in the draft)
* "Section 4.1 Transport Queue Operations: An ALTO client creates a
transport queue using the HTTP POST method". Could this increase the exposure
of ALTO service to a potential DoS attack? E.g., in the case that multiple
non-legit clients allocate queues for the purpose of consuming additional
memory/compute resources from the system. Is there a need to mention it in
Section 10 to ensure implementations provide safety measures against this
potential threat?
* Section 4.2: instead of "structure of incremental updates queue will be
specified", suggest "the structure of the incremental updates queue will be
specified"
* Section 5.1:
* While the acronym CRUD might be known in the community, suggest
defining it the first time it is used:
* Instead of "Among the CRUD operations", suggest "Among the create,
read, update, and delete (CRUD) operations"
* Instead of "an incremental updates queue supports only", suggest "an
incremental updates queue only supports"
* In Section 6.1:
* Suggest adding RFC reference next to SETTINGS_ENABLE_PUSH so reader
can look up the definition. So intead of "SETTINGS_ENABLE_PUSH", suggest
"SETTINGS_ENABLE_PUSH [RFC7540]"
* Instead of "PUSH_PROMISE", suggest "PUSH_PROMISE [RFC7540]"
* Regarding this requirement "The server MUST maintain the last entry
pushed to the client (and hence per client, per connection state)"
* Will it scale?
* Can we add a note on scalability (e.g., scalability can be
addressed by adding multiple ALTO servers)?
As with Peng, I also think this version is maturing so I would support the
adoption as we continue to provide and address all the feedback.
Jordi
________________________________
From: alto <[email protected]> on behalf of Qin Wu
<[email protected]>
Sent: Wednesday, June 8, 2022 11:36
To: [email protected] <[email protected]>
Subject: Re: [alto] WG adoption call for draft-schott-alto-new-transport-01
WARNING: This email originated from outside of Qualcomm. Please be wary of any
links or attachments, and do not enable macros.
Hi, authors:
I have read the latest version of ALTO transport, here is a few clarification
questions and comments:
1. What is the relationship between HTTP/2 connection and Transport queue? one
to one?
Will information resources share the same transport queue?
2. What is the relationship between transport queue and incremental update
queue? one to one mapping?
3. Will receivers share the same incremental update queue? or each receiver can
join different incremental update queue? For the former case, how does new
receiver know
or discover the existing incremental update queue? Information resource will
provide hints for the receiver or the client?
4. How incremental push update is different from incremental update?
5. In Figure 2 should 'sq/rs' be 'tq/rs'?
6. Individual update is not present in the figure 2? would it be nice to
clarify the
relation between incremental update and individual update? Is incremental
udpate shared by multiple receivers?
7. Should this draft need to update RFC7285 since it introduce new
functionalities such as transport queue, incremental update queue, receiver set?
8. Is there any open issues section to track issue tickets?
-Qin (without chair hat)
发件人: alto [mailto:[email protected]] 代表 Qin Wu
发送时间: 2022年5月31日 19:11
收件人: [email protected]
主题: [alto] WG adoption call for draft-schott-alto-new-transport-01
Hi folks,
This begins a 2 week WG Adoption Call for the following draft:
https://datatracker.ietf.org/doc/draft-schott-alto-new-transport/
Please indicate your support or objections by June 15th, 2022.
Authors, please respond to the list indicating whether you are aware of any IPR
that applies to this draft.
Thanks,
-Qin/Med
_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto
