Last Call Review of draft-ietf-lamps-rfc6712bis-07
review-ietf-lamps-rfc6712bis-07-artart-lc-allocchio-2024-10-21-00
Request | Review of | draft-ietf-lamps-rfc6712bis |
---|---|---|
Requested revision | No specific revision (document currently at 09) | |
Type | Last Call Review | |
Team | ART Area Review Team (artart) | |
Deadline | 2024-10-23 | |
Requested | 2024-10-09 | |
Authors | Hendrik Brockhaus , David von Oheimb , Mike Ounsworth , John Gray | |
I-D last updated | 2024-10-21 | |
Completed reviews |
Tsvart Last Call review of -07
by Lars Eggert
(diff)
Genart Last Call review of -07 by Meral Shirazipour (diff) Secdir Last Call review of -07 by Charlie Kaufman (diff) Artart Last Call review of -07 by Claudio Allocchio (diff) Opsdir Last Call review of -07 by Mohamed Boucadair (diff) Httpdir Last Call review of -07 by Lucas Pardue (diff) |
|
Assignment | Reviewer | Claudio Allocchio |
State | Completed | |
Request | Last Call review on draft-ietf-lamps-rfc6712bis by ART Area Review Team Assigned | |
Posted at | https://mailarchive.ietf.org/arch/msg/art/8JlAvippscKLuBSzMdlLkI7u6Ls | |
Reviewed revision | 07 (document currently at 09) | |
Result | Almost ready | |
Completed | 2024-10-21 |
review-ietf-lamps-rfc6712bis-07-artart-lc-allocchio-2024-10-21-00
Good morning, I'm the assigned reviewer from the ARTART area. This draft is almost ready but I have some suggestions before it is published. 1) as any document "updating" a series of previous RFCs, ensuring an easy and crystal clear reading of it compared to the other documents being obsoleted or updated is tricky. I generally suggest some further detailed wording, or a detailed dedicated "updates and obsolets" section where it is clearly listed which sections of the previous documents are affected: something like * RFCxxxx section x.y.z, <text> is obsoleted etc... 2) clarification about the use of the wide range of HTTP protocol options (section 3.8). "SHOULD" is inappropriate normative here --> "should". Furthermore, it may be more useful to create a list of suggested HTTP features to use or mandatory HTTP features to use, so that all implementation try to stick with it, instead of just suggesting not to use the not needed HTTP parts. 3) section 3.6 examples: https instead of http ? 4) section 4: shall we suggest also "what to do" (a coherent behaviour) when we hit implementations with an old non standard approach in transferring CMP over HTTP? all the rest is ok for me. all the best Claudio