Hi Spencer, Many thanks for your comments. See my answers inline.
On Fri, Mar 24, 2023 at 4:15 PM Spencer Dawkins via Datatracker < [email protected]> wrote: > Reviewer: Spencer Dawkins > Review result: Ready > > I didn't have any questions on the document as written, and it's worth > adding > that I'm not a YANG person and was still able to follow the document and > the > process it describes. > > I did have one question, which might be out of scope for this document. > > I didn't see a mention of APLNs for TLS, and, perhaps more importantly, I > don't > see a mention of ALPNs, QUIC, or UDP parameters for HTTP/3 over QUIC. Yes, this document does not define anything about HTTP/3. Because the WG has not received any experience with implementing ALTO over HTTP/3. But the draft-ietf-alto-new-transport work is pushing efforts in this domain. It is valuable to consider APLNs and HTTP/3 for future extensions. At this moment, we just need to make sure the current proposed model will not close the door. Once we have enough practical experience, we can add new "augment"s to the current model to support HTTP/3-related parameters. > It looks > like this document is expecting to use NAPTR records, but I thought web > servers > used RR records to provide ALPN names. The discovery approach of using NAPTR records is proposed by RFC 8686. We support this first because it has been already a standard. But I agree that HTTPS RR would be a better option if we are going to provide ALPNs. Once it becomes a standard, we will be happy to add it. > My apologies if my question isn't > helpful, but is it expected that this document would also cover > configuration > of ALTO servers listening over HTTP/3? > > I don't have strong opinions to cover HTTP/3 in this document. But we will open the door for it for future module extensions. Thanks, Jensen
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
