Re: Last Call: <draft-leiba-3967upd-downref-00.txt> (Updating when Standards Track Documents may Refer Normatively to Documents at a Lower Level) to Best Current Practice

[Barry Leiba <[e-mail]>]

> I broadly in favour of this change, but I have a few comments.

Thanks, Brian.

> First, a minor suggestion on the text itself:
>
> OLD:
>    The responsible AD should
>    still check for downrefs before sending out the last call notice, but
>    any need to repeat a last call if this has not been done is at the
>    discretion of the IESG.
> NEW:
>    The responsible AD should
>    still check for downrefs before sending out the last call notice, but
>    if an undetected downref is noticed during last call or IESG review,
>    any need to repeat the last call is at the discretion of the IESG.

Yes, that reflects the intent and is more explicitly clear.  I like the change.

> Second,
>
>>    there are no related security
>>    considerations.
>
> That bothers me a tiny bit. A missed downref could have security implications.

I agree, but I contend that this doesn't make it any more likely that
we'll miss a downref.  In fact, this change is only operable when we
*don't* miss it -- it simply gives the IESG judgment on whether last
call needs to be repeated when we catch it.  And the Security ADs will
certainly have a say in that, if they think that broader review of the
downref is warranted for security checking.

> Third, I believe that in addition to this procedural change, there is a
> little work needed on the ecosystem:
>
> 1. Make the downref registry an intrinsic part of the data tracker. I mean that
> each document listed at https://trac.tools.ietf.org/group/iesg/trac/wiki/DownrefRegistry
> would instead be tagged as 'downref allowed' in the tracker, with appropriate GUI
> support for the IESG to apply this tag.
>
> 2. Enhance idnits slightly to check this tag when it detects a downref.
> A downref to a 'downref allowed' document would be a warning, and a downref
> to a non-downref-allowed document would be an error.

I agree that those would be excellent changes, and I'll ask Ben, as
sponsoring AD, to send that request up to the tools team.  I don't
gather than you're asking that the document be held for that, correct?

The change you suggest above is in my working copy for the next draft revision.

Barry