Skip to main content

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 04)
Type Last Call Review
Team ART Area Review Team (artart)
Deadline 2022-10-17
Requested 2022-09-19
Authors Murray Kucherawy
I-D last updated 2022-10-05
Completed reviews Artart Last Call review of -03 by Pete Resnick (diff)
Genart Last Call review of -03 by Vijay K. Gurbani (diff)
Secdir Last Call review of -03 by Watson Ladd (diff)
Dnsdir Last Call review of -03 by Patrick Mevzek (diff)
Assignment Reviewer Pete Resnick
State Completed
Request 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 04)
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.