Re: BCP97bis

["Murray S. Kucherawy" <[e-mail]>]

On Sat, Oct 16, 2021 at 1:29 PM Michael Richardson <[e-mail]>
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