Re: [Uta] draft-ietf-uta-xmpp downref

[joel jaeggli <[e-mail]>]

On 4/20/15 3:41 PM, Barry Leiba wrote:
>>> It was pointed out to me that RFC4949 as a normative
>>> reference here is a downref, and I didn't call that
>>> out during the IETF LC for this document. (Sorry about
>>> that.) Oddly, 4949 hasn't previously been added to the
>>> downref registry. [1]
>>
>> That surprises me, given that RFC 4949 is already a normative reference from
>> draft-ietf-uta-tls-bcp as well as RFC 6749 and RFC 7489 (both of which are
>> standards-track).
> 
> It surprised me too.  We missed it for uta-tls-bcp and 6749 (OAuth).
> 7489 (DMARC) is not Standards Track.
> 
>>> 2. I re-do the IETF LC just for this point and we put 4949
>>>     into [1] so this won't be a deal for other drafts in
>>>     future
>>
>> Someone needs to blaze this path, so it might as well be us.
> 
> That's my preference,  It's a small delay, less than two weeks... then
> we add 4949 to the downref registry and we're set for the future.
> 
> While Joel might like to ignore the process, we can't; RFC 3967 (BCP
> 97) is explicit:

To wit, I am not ignoring the process.

   Once a specific down reference to a particular document has been
   accepted by the community (e.g., has been mentioned in several Last
   Calls), an Area Director may waive subsequent notices in the Last
   Call of down references to it.  This should only occur when the same
   document (and version) are being referenced and when the AD believes
   that the document's use is an accepted part of the community's
   understanding of the relevant technical area.  For example, the use
   of MD5 [RFC1321] and HMAC [RFC2104] is well known among
   cryptographers.

>    For Standards Track or BCP documents requiring normative reference to
>    documents of lower maturity, the normal IETF Last Call procedure will
>    be issued, with the need for the downward reference explicitly
>    documented in the Last Call itself.  Any community comments on the
>    appropriateness of downward references will be considered by the IESG
>    as part of its deliberations.
> 
> I think we should change that and allow us to do the right thing
> without having to be, as Peter puts it, process sticklers.  I will be
> happy to AD-sponsor 3967bis, if anyone would like to write it and deal
> with the discussion.  I think no one benefits from this second last
> call.
> 
> But we do have a BCP in which we, as a community, set up this process,
> and until it's changed we have to follow it, at least when we notice
> that it's needed.
> 
> Sigh.
> 
> Barry
>