Re: [Uta] draft-ietf-uta-xmpp downref

[Sean Turner <[e-mail]>]

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 <[e-mail]> 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
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/uta
>>>> 
>>> 
>> 
>> 
> 
> _______________________________________________
> Uta mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/uta