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 >> >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
