Skip to main content

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