Re: Evolving Documents (nee "Living Documents") side meeting at IETF105.)

[john heasley <[e-mail]>]

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.