Wed, Jul 17, 2019 at 11:40:42AM +0100, Stephen Farrell: > > Hiya, > > On 17/07/2019 01:46, john heasley wrote: > > Thus that BGP over TLS RFC does not need to be updated as TLS evolves or > > TLS RFCs come/go, nor does it need to make recommendations about TLS > > itself - something that the authors may not be qualified to comment about. > > That is already true. Simply refer to BCP195 instead of > RFC7525 and you get that bit. BCP numbers are static? An RFC that supersedes 7525 and becomes BCP will also be 195? I see no indication of this in 2026: thus I assume it will receive a new number. What have I missed? > I understand the desire for more quickly moving things > but IMO changing too quickly also has downsides so I'm > ok with RFC7525 being the latest instance of BCP195 and > for that RFC needing to be updated or the BCP having > another RFC added to it for TLS1.3 (hopefully in the not > too distant). I am not; recommendations, esp. for security topics, need to move near the speed of blackops, not at RFC speed - or worse, BCP speed, which I perceive to be even slower and carry more weight. I feel the same for other technologies, security just has more inherent urgency. The RFC itself says " Community knowledge about the strength of various algorithms and feasible attacks can change quickly, and experience shows that a Best Current Practice (BCP) document about security is a point-in-time statement. Readers are advised to seek out any errata or updates that apply to this document." > I'd be against github-hosted evolving, living or dying > documents. Github is ok for drafts as we do now, but even > today leads to too much off-list discussion and decision > making in my experience. An SCM that is publicly available, of which I do not expect debate. Which and where, I expect will be debated ad nauseam. > That said, I do like the idea of a WG nominating a draft > (or set of drafts with additional commentary) as the > current interop draft, but I think I'd be against such an > artefact being a long-lived thing to which e.g. RFCs may > normatively refer. Think of it as a library or compatibility library.
