Last Call Review of draft-kucherawy-bcp97bis-03
review-kucherawy-bcp97bis-03-artart-lc-resnick-2022-10-05-00
| Request | Review of | draft-kucherawy-bcp97bis |
|---|---|---|
| Requested revision | No specific revision (document currently at 05) | |
| Type | IETF Last Call Review | |
| Team | ART Area Review Team (artart) | |
| Deadline | 2022-10-17 | |
| Requested | 2022-09-19 | |
| Authors | Murray Kucherawy | |
| I-D last updated | 2026-02-05 (Latest revision 2024-05-08) | |
| Completed reviews |
Artart IETF Last Call review of -03
by Pete Resnick
(diff)
Genart IETF Last Call review of -03 by Vijay K. Gurbani (diff) Secdir IETF Last Call review of -03 by Watson Ladd (diff) Dnsdir IETF Last Call review of -03 by Patrick Mevzek (diff) |
|
| Assignment | Reviewer | Pete Resnick |
| State | Completed | |
| Request | IETF Last Call review on draft-kucherawy-bcp97bis by ART Area Review Team Assigned | |
| Posted at | https://mailarchive.ietf.org/arch/msg/art/QJSdon6w_O3Qf-_WG3fvxFhQvyA | |
| Reviewed revision | 03 (document currently at 05) | |
| Result | Almost ready | |
| Completed | 2022-10-05 |
review-kucherawy-bcp97bis-03-artart-lc-resnick-2022-10-05-00
There is nothing ART specific with which I have concerns.
That said, my comments on section 5 and 6 I really think need to be dealt with
before I would say this document is "Ready". The other items are strictly
editorial:
Section 2:
* There are exceptional procedural or legal reasons that force the
target of the normative reference to be an informational or
historical RFC or to be at a lower standards level than the
referring document.
I think your example needs an example, as I have no idea what one of these
procedural and particularly legal reasons might be.
Section 4.1:
Such
decisions should be noted in the document shepherd writeup [RFC4858]
so the IESG is aware at the time of its review why the annotation is
absent.
I suggest moving this out to the last paragraph of the section and amplify a
bit:
When the document is prepared to submit to the IESG for approval, a
document shepherd writeup [RFC4858] is normally written. This writeup
should contain a description of any downrefs that appear in the
document and should make particular note of any downref that is not
identified by an annotation in the References section.
Section 4.2:
Such documents are added to the "Downref Registry".
I would add "described in section 7."
This procedure is not to be used if the proper step is to move the
document to which the reference is being made into the appropriate
category. It is not intended as an easy way out of normal process.
Rather, the procedure is intended for dealing with specific cases
where putting particular documents into the required category is
problematic and unlikely ever to happen.
s/category/status/g
Section 5 as written doesn't make sense anymore. First, the downref model
doesn't only apply to "published Standards-Track RFCs at lower maturity
levels"; it also applies to Informational and Experimental documents. But the
rest is simply repetitive with the last paragraph of 4.2. If you need to keep
any of the last paragraph of section 5, edit it into the last paragraph of
section 4.2, or replace it. Otherwise, I would strike the entire section at
this point.
Section 6 seems to be an update or replacement of RFC 2026 section 7. At the
very least, a reference in this document is in order and a description of the
difference between the two is warranted. I would explicitly call out that this
document updates 2026 section 7.