Re: Things that used to be clear (was Re: Evolving Documents (nee "Living Documents") side meeting at IETF105.)

[Keith Moore <[e-mail]>]

On 7/10/19 2:32 PM, Phillip Hallam-Baker wrote:

> I agree with much of this discussion but I have come to a very 
> different perspective:
>
> * Internet Standard status means nothing more than the fact that the 
> legacy deployment is sufficiently large that further development of 
> the specification is no longer feasible.
> * Internet Standard status is not necessarily a desirable condition.
>
> * Internet Standard status will be reached regardless of whether the 
> documents are good or not.

Without arguing about the above, I would be okay with a single level + 
periodic review (say, once every 2 years) resulting in an applicability 
note on the RFC Editor's page for that RFC.   The applicability note 
would note interoperability issues, deployment level, identify known 
significant bugs and technical omissions, and make deployment 
recommendations.   (whether suitable for widespread deployment or not, 
perhaps only in specific corner cases, perhaps legacy use only, perhaps 
a recommendation to discontinue use or transition to a different protocol).

If we did things that way then maybe also task the WG that produced the 
RFC with doing interop tests (or arranging for them) within 2 years of 
publication.   We desperately need the feedback loop.

> One of the sad parts of the development of the Web is that HTTP became 
> a standard in early 1993. By the time we had a team able to start 
> getting the protocols into shape, legacy deployment was already 
> constraining development. If people recall, Simon Spero proposed an 
> HTTP-NG that is remarkably close to QUIC given that over twenty years 
> separate them. We couldn't deploy because there was too much legacy.

He wasn't the only one who saw the need.   What I've come to realize is 
that conditions change over time.   Sometimes those conditions 
facilitate improving or transitioning away from legacy protocols, 
sometimes they don't.   The trick is to recognize when conditions 
facilitate useful change and take advantage of that.

> We need to stop being so dogmatic about IETF process. It is not like 
> it is working for us now or has worked well in the past. I propose a 
> different approach
>
> 1) Keep the two standards process levels but drop the notion that 
> Internet Standard means the work is finished and will never change. 
> Specifications that are being used by real people will always need 
> some level of maintenance. Maybe not a great deal but some. Add an 
> additional status LEGACY to describe the specs that are in widespread 
> use, have been superseded but are not going to go away for decades if 
> ever. IPv4 would be a good candidate for LEGACY as it will always be 
> with us just as the 6502 microprocessor will always be with us in 
> standard cell. Even if that is after 0.0.0.0/0 <http://0.0.0.0/0> has 
> been declared (reserved for private use).
>
> 2) Recognize the fact that HTTP/1.1, TLS/1.2, PKIX etc are now 
> Internet Standards. They may not be perfect, the implementations may 
> not be fully interoperable but anyone who wants to make a Web browser 
> (for example) is going to have to support those specs for a 
> considerable time to come. Declaring TLS/1.2 an Internet Standard does 
> not mean ending development of TLS/1.3, it is merely recognizing the 
> situation.

I would not support that, but I would support writing an applicability 
statement about each of them saying essentially what you've said above - 
they have these known problems but implementing them in browsers is for 
the time being a practical necessity.

> 3) Establish a maintenance WG in each area that is the place for 
> continuing incremental development of standards. The Security area has 
> LAMPS. I think that instead of the 'do the work, shut the WG' model 
> applying to every WG in IETF, the maintenance groups should act as 
> standing committees for very limited updates.

That strikes me as an invitation to disaster unless somehow groups can 
be made to avoid constantly doing new work of dubious value, and also 
avoid mission creep.    We are producing too many RFCs of dubious value 
as it is, and IESG is already taxed reviewing the drafts.

Keith