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 On Tue, Apr 21, 2015 at 4:39 PM, Stephen Farrell <[email protected]> wrote: > > 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
