Re: [Tsv-art] Nomcom candidates (including Transport AD)
On Wed, Jun 2, 2021 at 3:21 AM Zaheduzzaman Sarker wrote: > Thanks Martin for putting out your well compiled thoughts. It is even > better that you are willing to standing for another term. > > > > Even though my experience is short I could not agree more with your > message here. (Let’s see what I say after me term ends ). Sure, I can > also share my experience and discuss with any interested person. > "Term". He said, "term". Who's going to tell him? :D Best, Spencer
Comments on ohttp WG and technical proposal
a) WG: I think there should be first substantial discussion about the subject matter on the mailing list (ohttp) before proceeding on a WG request for this work. b) Draft: Neither the charter text, nor draft-thomson-http-oblivious provide a (to me) good persuasive high level explanation or justification for the use-case. Something as easy as "A client who does not want its source-address be traceable by a target-resource needs a mechanism to orchestrate the following:" client <-> proxy-resource <-protected-leg-> request-resource <-> target-resource and discussion of the questions arising from the model. Such as what expectations against the proxy-resource are necessary to make this useful at all. c) Concept: Except for the likely (absent better text i can only guess) business cases of the proponents of the WG, who from their perspective may not be interested in a broader solution but want to build something constrained to just http, i for once think it would be lot more useful for the IETF to work on such a solution with more generality. For example, i think we could have with comparable standardization effort such an orchestration resulting in a transparent transport (TCP) connection between client and target-resource, allowing the scheme to be used for any protocol across that connection, and not only for the exchange of http messages between client and target-resource. Such work might then of course be better suited for a TSV WG or maybe an INT WG han i guess an ART WG where ohttp might end up in if it get chartered. d) I am guessing that there is the assumption that a generic transport/TCP connection connection model will have specific downsides such as more round-trips for packet exchanges, but that comparison is really important to document, and i am no even sure if it holds true, because if the proposed solution can deliver at e.g.: 0 additional round-trips an HTTP get request from the client to the target resource, than so could that AFAIK simply be a TCP message. Cheers Toerless -- --- t...@cs.fau.de
Comments on ohttp WG and technical proposal
a) WG: I think there should be first substantial discussion about the subject matter on the mailing list (ohttp) before proceeding on a WG request for this work. b) Draft: Neither the charter text, nor draft-thomson-http-oblivious provide a (to me) good persuasive high level explanation or justification for the use-case. Something as easy as "A client who does not want its source-address be traceable by a target-resource needs a mechanism to orchestrate the following:" client <-> proxy-resource <-protected-leg-> request-resource <-> target-resource and discussion of the questions arising from the model. Such as what expectations against the proxy-resource are necessary to make this useful at all. c) Concept: Except for the likely (absent better text i can only guess) business cases of the proponents of the WG, who from their perspective may not be interested in a broader solution but want to build something constrained to just http, i for once think it would be lot more useful for the IETF to work on such a solution with more generality. For example, i think we could have with comparable standardization effort such an orchestration resulting in a transparent transport (TCP) connection between client and target-resource, allowing the scheme to be used for any protocol across that connection, and not only for the exchange of http messages between client and target-resource. Such work might then of course be better suited for a TSV WG or maybe an INT WG han i guess an ART WG where ohttp might end up in if it get chartered. d) I am guessing that there is the assumption that a generic transport/TCP connection connection model will have specific downsides such as more round-trips for packet exchanges, but that comparison is really important to document, and i am no even sure if it holds true, because if the proposed solution can deliver at e.g.: 0 additional round-trips an HTTP get request from the client to the target resource, than so could that AFAIK simply be a TCP message. Cheers Toerless
