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