Re: [Last-Call] [Gen-art] Genart last call review of draft-ietf-httpbis-http2bis-06

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Dan, thank you for your review. I have entered a No Objection ballot for this document.

Lars


> On 2021-11-22, at 18:06, Dan Romascanu via Datatracker <noreply@xxxxxxxx> wrote:
> 
> Reviewer: Dan Romascanu
> Review result: Ready with Issues
> 
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair.  Please treat these comments just
> like any other last call comments.
> 
> For more information, please see the FAQ at
> 
> <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
> 
> Document: draft-ietf-httpbis-http2bis-06
> Reviewer: Dan Romascanu
> Review Date: 2021-11-22
> IETF LC End Date: 2021-11-26
> IESG Telechat date: Not scheduled for a telechat
> 
> Summary:
> 
> This document is Ready from a GenART point of view, with a number of minor
> issues which I recommend to be clarified before approval.
> 
> Major issues:
> 
> Minor issues:
> 
> 1. It seems to me that a better clarification of the issues related to backward
> compatibility is needed. RFC 7540 included the following sentence in the
> Abstract:
> 
>> This specification is an alternative to, but does not obsolete, the
>   HTTP/1.1 message syntax.  HTTP's existing semantics remain unchanged.
> 
> Why was this taken out?
> 
> 2. I noticed changes in Section 5.5 that describes the mechanisms for extending
> HTTP/2.
> 
> RFC 7540
> 
>> Extensions that could change the semantics of existing protocol
>   components MUST be negotiated before being used.  For example, an
>   extension that changes the layout of the HEADERS frame cannot be used
>   until the peer has given a positive signal that this is acceptable.
>   In this case, it could also be necessary to coordinate when the
>   revised layout comes into effect.  Note that treating any frames
>   other than DATA frames as flow controlled is such a change in
>   semantics and can only be done through negotiation.
> 
> draft-ietf-httpbis-http2bis-06
> 
>> Extensions SHOULD avoid changing protocol elements defined in this
>   document or elements for which no extension mechanism is defined.
>   This includes changes to the layout of frames, additions or changes
>   to the way that frames are composed into HTTP messages (Section 8.1),
>   the definition of pseudo-header fields, or changes to any protocol
>   element that a compliant endpoint might treat as a connection error
>   (Section 5.4.1).
> 
>   An extension that changes existing elements MUST be negotiated before
>   being used.  For example, an extension that changes the layout of the
>   HEADERS frame cannot be used until the peer has given a positive
>   signal that this is acceptable.  In this case, it could also be
>   necessary to coordinate when the revised layout comes into effect.
>   For example, treating frames other than DATA frames as flow
>   controlled requires a change in semantics that both endpoints need to
>   understand, so this can only be done through negotiation.
> 
> This seems to me like a change as the SHOULD recommendation is dropped. Is this
> just editorial, or is it rather a more substantive change that should be
> mentioned in Appendix B.
> 
> 3.  RFC 7540 included a section (9.1.2) about the 421 Status Code, including
> description of behavior of clients and proxies. This was eliminated in the new
> version, which includes only one reference to servers that do not wish clients
> to reuse connections. Was the rest of former section 9.1.2 considered
> unnecessary? Why?
> 
> 4. Should not be [RFC7540] be a Normative Reference? It is referred to around
> 20 times in the document. The discussion about priority signaling in 5.3 seems
> to require reading text from RFC 7540 that was not taken in this document. Also
> in Section 5.5
> 
>> Registries
>   for managing these extension points are defined in Section 11 of
>   [RFC7540].
> 
> Nits/editorial comments:
> 
> 
> 
> _______________________________________________
> Gen-art mailing list
> Gen-art@xxxxxxxx
> https://www.ietf.org/mailman/listinfo/gen-art

Attachment: signature.asc
Description: Message signed with OpenPGP

-- 
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux