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. On 21/04/15 21:36, Sean Turner wrote: > 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 > > > On Apr 20, 2015, at 19:48, Stephen Farrell <[email protected]> wrote: > >> >> 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. >> >> On 21/04/15 00:42, joel jaeggli wrote: >>> On 4/20/15 4:08 PM, Stephen Farrell wrote: >>>> >>>> >>>> On 20/04/15 23:59, Barry Leiba wrote: >>>>>> 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. >>>>> >>>>> 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. >>>> >>>> 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 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 >>> >>>> 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.) >>> >>> 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. >>> >>>> S. >>>> >>>> >>>>> >>>>> b >>>>> >>>>> _______________________________________________ >>>>> Uta mailing list >>>>> [email protected] >>>>> https://www.ietf.org/mailman/listinfo/uta >>>>> >>>> >>> >>> >> >> _______________________________________________ >> Uta mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/uta > > _______________________________________________ > Uta mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/uta > _______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
