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
