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

From: Stephen Farrell <[email-masked]>
Date: Mon, 20 Apr 2015 23:02:04 +0100

Hiya,

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]

So, the choices are:

1. make 4949 an informative reference (possible I think but
   a teeny bit ickky)
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

Authors/chairs/WG: if you don't tell me you prefer #1 above,
I'll assume #2 and re-start the IETF LC for this one tomorrow.

For IESG folks: if it's ok, I suggest you continue your
evaluations and we can handle this via me putting on a DISCUSS.
If that's bad somehow, just tell me and we can defer the doc
until the next telechat.

Cheers,
S.

[1] https://trac.tools.ietf.org/group/iesg/trac/wiki/DownrefRegistry

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Mon, 20 Apr 2015 16:18:09 -0600

> that.) Oddly, 4949 hasn't previously been added to the

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).

> 1. make 4949 an informative reference (possible I think but

A quick look at 
http://www.arkko.com/tools/allstats/citations-rfc4949.html reveals that 
most of the standards-track RFCs that cite RFC 4949 do so 
informationally. So there's plenty of precedent. (It does seem to me, 
however, that you really need to understand the cited glossary in order 
to know what various terms mean in a given spec.)

>     into [1] so this won't be a deal for other drafts in

I had assumed this would not be an issue given the RFCs cited above, but 
I suppose there's always a first time for someone to be a process 
stickler. :-)

> I'll assume #2 and re-start the IETF LC for this one tomorrow.

Someone needs to blaze this path, so it might as well be us.

> If that's bad somehow, just tell me and we can defer the doc

Whatever works for the IESG. :-)

Peter

-- 
Peter Saint-Andre
https://andyet.com/

---

From: joel jaeggli <[email-masked]>
Date: Mon, 20 Apr 2015 15:21:08 -0700

>    into [1] so this won't be a deal for other drafts in

3. look at precident,

http://datatracker.ietf.org/doc/rfc4949/referencedby/

decide that it's within your power to approve the downref and add it to
the registry

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 20 Apr 2015 23:22:42 +0100

> decide that it's within your power to approve the downref and add it to

That'd work for me, if the IESG are ok with it. Barry has a
DISCUSS so we'll discuss it anyway.

S.

---

From: Barry Leiba <[email-masked]>
Date: Mon, 20 Apr 2015 18:41:11 -0400

> 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.

> 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:

   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

---

From: joel jaeggli <[email-masked]>
Date: Mon, 20 Apr 2015 15:51:10 -0700

> While Joel might like to ignore the process, we can't; RFC 3967 (BCP

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.

---

From: Barry Leiba <[email-masked]>
Date: Mon, 20 Apr 2015 18:59:34 -0400

>    of MD5 [RFC1321] and HMAC [RFC2104] is well known among

The problem is that as far as I can find, it hasn't been mentioned in
*any* last calls.  I'm bummed: as I said, I don't think that doing
this helps anyone, and that we should change BCP 97 forthwith.

b

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 21 Apr 2015 00:08:44 +0100

> this helps anyone, and that we should change BCP 97 forthwith.

I think Joel's argument is that 4949 has been "accepted by
the community" in that RFC6749 is 2.5 years old and nobody
noticed. The "several last calls" above is just an example
in the text also.

I can buy into that. (If we go with that I'd say we can add
4949 to the downref registry with the oauth draft as the
referring draft and leave the LC date blank.)

S.

> 
> b
> 
> _______________________________________________
> Uta mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/uta
>

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Mon, 20 Apr 2015 17:10:32 -0600

> referring draft and leave the LC date blank.)

Hey, I'll let you sitting ADs figure out the process, but from my 
perspective another 2 weeks isn't the end of the world. :-)

Peter

-- 
Peter Saint-Andre
https://andyet.com/

---

From: Barry Leiba <[email-masked]>
Date: Mon, 20 Apr 2015 19:38:18 -0400

> referring draft and leave the LC date blank.)

Hm.  I can buy that also -- I hadn't thought of it as an example, but
it's certainly clear that it's an accepted reference.

Let's do it; I'll clear my DISCUSS.

Barry

---

From: joel jaeggli <[email-masked]>
Date: Mon, 20 Apr 2015 16:42:14 -0700

> noticed. The "several last calls" above is just an example

I think community understanding of the document can be understood in
terms of cititations inclusive of normative and informative references
other than simply dowrefs. 4949 is a glossary, many documents of various
levels refer to it informatively and the contents were or have passed
into common understanding in the decade since publication.

The existence of previous documents with downref's  to the document may
be evidence of an omission (probably is) but in the context of a
document with a decade long service life with numerous citations, is
also more evidence that it has passed into common understanding. as with
the question of whether rfc 20 is actually at a lower maturity level or
not or even if that matters, the latitude to decide when downrefs are to
be waived is invested in the IESG.

consider in this case the context  in which it is being used

2.  Terminology

   Various security-related terms are to be understood in the sense
   defined in [RFC4949].

this is not an original turn of phrase

I could cite others but:

https://www.rfc-editor.org/rfc/rfc6029.txt

https://tools.ietf.org/html/rfc6749

https://www.google.com/webhp?sourceid=chrome-instant&ion=1&espv=2&ie=UTF-8#q=various%20security-related%20terms%20are%20to%20be%20understood%20in%20the%20sense%20defined%20in%20%5brfc4949%5d

etc

> referring draft and leave the LC date blank.)

personally I think the evidence for the document being fine to cite  for
the purpose of defining the word attack certificate confidentiality
encryption etc is there.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 21 Apr 2015 00:48:53 +0100

Top quoting: thanks all - let's do that. I'll add to the
downref registry before the telechat unless someone else
on the IESG yells.

Cheers,
S.

---

From: Leif Johansson <[email-masked]>
Date: Tue, 21 Apr 2015 09:04:46 +0200

> I'll assume #2 and re-start the IETF LC for this one tomorrow.

I prefer #2

---

From: Sean Turner <[email-masked]>
Date: Tue, 21 Apr 2015 16:36:41 -0400

Note that 4949 has already been called out in a downref when you requested the IETF LC for the OAuth v2 draft ;)

https://www.ietf.org/mail-archive/web/ietf-announce/current/msg09796.html

spt

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 21 Apr 2015 21:39:13 +0100

Ha! Okey dokey, so I just need to put it in the list.
That does sound entirely like the kind of thing I'd
forget.

Well spotted,
S.

---

From: Barry Leiba <[email-masked]>
Date: Tue, 21 Apr 2015 17:01:07 -0400

I had looked at that, but missed it, because there were two last
calls.  The first (which I looked at) did not include the downrefs.
The second, the following day, did -- it was a revised last call to
add the downrefs.

So we're even more covered than I'd thought.  Life is good.

Barry

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Tue, 21 Apr 2015 16:45:18 -0500

Hi, Barry,

On Tue, Apr 21, 2015 at 4:01 PM, Barry Leiba <[email-masked]>
wrote:

> <https://www.ietf.org/mail-archive/web/ietf-announce/current/msg09796.html>
>

That's the rumor I keep starting :-)

Spencer