On Sat, Oct 16, 2021 at 1:29 PM Michael Richardson <mcr+ietf@xxxxxxxxxxxx> wrote:
Are we having a problem getting downrefs identified early enough, or are
things okay?
My impression is that idnits and the datatracker are catching these a high percentage of the time. In my time on the IESG (a measly 1.5 years) I haven't managed to catch a document that failed to call out a downref.
I also wonder if we shouldn't have a process to attempt to clean the downref
registry out, but reclassifying the documents. The repeated MD5 and HMAC
document listed as examples seem like good datapoints. (MD5 might be
Historic, but HMAC is still awesome)
That's an interesting idea, but I think it's perhaps an effort separate from this one.
} At a minimum, authors/editors of source documents need to secure freely
} available copies of the target documents for use by all anticipated reviewers
} during the source document's life cycle, which includes working group
} participants, any member of the community that chooses to participate in Last
} Call discussions, area review teams, IANA expert reviewers, and members of
} the IESG.
It seems to me, if this requirement is to be taken seriously, that either the
DT or some other resource needs to contain notes on how to obtain the
references.
That'll be different for every source of the references, right? I'm not sure how we could do that programmatically for all cases.
Really how you go about getting it is somewhat orthogonal to the point we're trying to address with this update, which is: If you're going to make a normative reference to something access to which is restricted, that has to be resolved somehow before it goes to the IESG; we (and any other reviewers, e.g., the review teams) need the referenced material to be able to do our jobs.
So I am reacting the word "At a minium", and I don't think we are even
getting to that minimum. There are a bunch of specifications that aren't
just transitioning from some legacy specification to an RFC, but which we are
allocating numbers/etc. for entities which make it very difficult to read their
documents. I think that we should be doing more than the minimum here.
What do you suggest in terms of text changes here to address what you're talking about?
} Appendix A. Changes Since RFC8067
} The following are the changes in this document relative to the prior state of BCP 97:
}
} o Apply erratum #2793.
https://www.rfc-editor.org/info/rfc8067
doesn't mention any errata.
RFC 8067 was the last document added to the cluster that currently makes up BCP 97, so this is a list of changes since that milestone. I didn't mean to imply that this erratum applies to that RFC.
-MSK
