Howdy Pete,
On Wed, Oct 5, 2022 at 11:20 AM Pete Resnick via Datatracker <noreply@xxxxxxxx> wrote:
[...]
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.
This is preserved verbatim from RFC 3967. I don't have any particular examples in mind. Perhaps someone who contributed to the original might recall. I've Cc'd Scott Bradner.
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.
Done.
Section 4.2:
Such documents are added to the "Downref Registry".
I would add "described in section 7."
Done.
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
Done.
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.
Done.
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.
Thanks, I'll add the reference. I don't know that there's much of a difference to describe; they seem to be complementary.
I'll have a new version up shortly.
-MSK
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
