Re: [alto] Tsvart early review of draft-ietf-alto-oam-yang-06

[Jensen Zhang <[e-mail]>]

Hi Spencer,

Many thanks for your comments. See my answers inline.


On Fri, Mar 24, 2023 at 4:15 PM Spencer Dawkins via Datatracker <
[e-mail]> 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